explore_source

Cette page fait référence au paramètre explore_source, qui est un sous-paramètre de derived_table.

explore_source peut également être un sous-paramètre de test, décrit sur la page de documentation du paramètre test.

Utilisation

derived_table: customer_order_facts {
  explore_source:  orders {
    column:  customer_id {
      field:  orders.customer_id
    }
    column:  order_amount {
      field:  orders.sale_price
    }
    column:  item_qty {
      field:  orders.number_items
    }
    derived_column:  average_item_price {
      sql:  order_amount / item_qty  ;;
    }
    timezone:  "America/Los_Angeles"
  }
}
Hiérarchie
view
derived_table
explore_source
Valeur par défaut
Aucun

Acceptation
Identifiant de l'exploration à partir de laquelle la table dérivée native est dérivée, ainsi que des sous-paramètres définissant la table dérivée native.

Définition

Il existe deux façons de créer une table dérivée, que vous pouvez utiliser comme une table normale dans votre base de données : les tables dérivées natives, qui sont définies à l'aide de paramètres LookML, et les tables dérivées basées sur SQL, qui sont définies à l'aide d'instructions de requête SQL.

Le paramètre explore_source est utilisé pour les tables dérivées natives. Dans ce paramètre, vous définissez les colonnes à inclure dans une table dérivée native, les filtres à appliquer à la table dérivée native, si vous souhaitez limiter ou trier les lignes de la table dérivée native, et si vous souhaitez convertir les champs temporels de la table dérivée native dans un autre fuseau horaire.

Définir une table dérivée native

Vous pouvez utiliser différents paramètres dans un tableau dérivé natif, dont beaucoup sont facultatifs. La syntaxe permettant de définir une table dérivée native est la suivante :

explore_source: identifier {
  bind_all_filters: yes
  column: identifier {
    field: field_name
  }
  derived_column: identifier {
    sql: SQL expression ;;
  }
  expression_custom_filter: [custom filter expression]
  filters: [field_name_1: "string", field_name_2: "string", ...]
  limit: number
  sorts: [field_name_1: asc | desc, field_name_2: asc | desc, ...]
  timezone: "string"
}

Le tableau suivant fournit des informations sur chaque paramètre que vous pouvez utiliser pour définir une table dérivée native :

Nom du paramètre Description Exemple
bind_filters Transmet un filtre de la requête d'exploration à la sous-requête de la table dérivée native. Pour configurer ce paramètre, utilisez le sous-paramètre from_field afin de spécifier un champ défini dans la vue Tableau dérivée native ou accessible dans l'exploration à laquelle la table dérivée native est jointe. Lors de l'exécution, tous les filtres sur le from_field de l'exploration sont transmis au to_field de la sous-requête de la table dérivée native. Pour obtenir un exemple, consultez la section Utiliser bind_filters.

Avec bind_filters, notez les points suivants :
  • Le filtre d'exécution doit faire partie d'une vue jointe à la même exploration que la table dérivée native.
  • La table dérivée native ne peut pas être transformée en table dérivée persistante (PDT).

• Le paramètre explore_source peut comporter le sous-paramètre bind_all_filters ou le sous-paramètre bind_filters, mais pas les deux. 
bind_filters: {
  to_field: users.created_date
  from_field: user_dt.filter_date
}
bind_all_filters Transmet tous les filtres de la requête d'exploration à la sous-requête de la table dérivée native. Pour configurer ce paramètre, spécifiez bind_all_filters: yes dans le explore_source de la table dérivée native. Pour obtenir un exemple, consultez la section Utiliser bind_filters.

Avec bind_all_filters: yes, notez les points suivants :
  • Le filtre d'exécution doit faire partie d'une vue jointe à la même exploration que la table dérivée native.
  • La table dérivée native ne peut pas être transformée en PDT.
  • La table dérivée native ne peut être jointe qu'à l'exploration spécifiée dans le paramètre explore_source de la table dérivée native. En effet, bind_all_filters doit mapper les champs filtrés de l'exploration avec les champs de la table dérivée native.
  • Le paramètre explore_source peut comporter le sous-paramètre bind_all_filters ou le sous-paramètre bind_filters, mais pas les deux.
 bind_all_filters: yes
column Désigne une colonne à inclure dans explore_source. Ce paramètre comporte un sous-paramètre field. 
column: cust_id {
  field: orders.customer_id
}
derived_column Désigne une colonne dans le paramètre explore_source avec une expression de l'espace de noms des colonnes internes. Faute de regroupement SQL à ce stade, l'agrégation d'expressions SQL est ici impossible. Les fonctions de fenêtrage SQL peuvent être très utiles dans ce paramètre. Ce paramètre comporte un sous-paramètre sql. 
derived_column: average_order {
  sql: order_amount / item_qty ;;
}
dev_filters Ajouté dans la version 21.12 Spécifie les filtres que Looker applique uniquement aux versions de développement de la table dérivée. Cela est utile aux développeurs LookML lorsqu'ils testent des tables dérivées en mode Développement. Le paramètre dev_filters permet à Looker de créer des versions filtrées plus petites de la table afin qu'un développeur LookML puisse itérer et tester la table sans attendre la création de la table complète après chaque modification. Looker n'applique dev_filters qu'aux versions de développement de la table dérivée, et non à la version de production de la table interrogée par vos utilisateurs. Pour en savoir plus sur l'utilisation des tables dérivées en mode Développement, consultez la page de documentation Tables dérivées dans Looker. Pour obtenir un exemple, consultez la section Créer des filtres pour le mode Développement sur cette page. dev_filters: [orders.created_date: "90 days", orders.products: "sweaters"]
expression_custom_filter Le cas échéant, spécifie une expression de filtre personnalisée sur une requête explore_source. expression_custom_filter: ${orders.status} = "pending" ;;
filters Ajoute éventuellement un filtre à une requête explore_source. Placez le nom du champ à filtrer entre crochets, au format view_name.field_name, suivi de : et de la ou des valeurs sur lesquelles le champ doit être filtré. Les filtres sont ajoutés à la clause WHERE du code SQL généré par la table dérivée native. filters: [products.department: "sweaters"]
limit  Le cas échéant, définit la limite de lignes de la requête. limit: 10
sorts Le cas échéant, définit le type de tri de ce explore_source. Placez le nom du champ à trier entre crochets, au format view_name.field_name, suivi de : et de asc ou desc pour indiquer si le champ doit être trié par ordre croissant ou décroissant. Vous pouvez trier les résultats selon plusieurs champs en ajoutant plusieurs paires nom de champ/mot clé séparées par des virgules. sorts: [products.brand: asc, products.name: asc]
timezone Définit le fuseau horaire de la requête explore_source. Pour les tables dérivées non persistantes, définissez le fuseau horaire sur "query_timezone" afin d'utiliser automatiquement le fuseau horaire de la requête en cours d'exécution. Si aucun fuseau horaire n'est spécifié, la requête explore_source n'effectue aucune conversion de fuseau horaire, mais utilise le fuseau horaire de la base de données. Pour obtenir la liste des fuseaux horaires acceptés, consultez la page des valeurs timezone.

L'IDE suggère automatiquement la valeur du fuseau horaire lorsque vous saisissez le paramètre timezone dans l'IDE. L'IDE affiche également la liste des valeurs de fuseau horaire acceptées dans le panneau d'aide rapide.		 timezone: "America/Los_Angeles"

Exemples

Les définitions suivantes fournissent des exemples de base de tables dérivées natives.

Créez une table dérivée native user_order_facts :

view: user_order_facts {
  derived_table: {
    explore_source: order_items {
      column: user_id {
        field: order_items.user_id
      }
      column: lifetime_number_of_orders {
        field: order_items.order_count
      }
      column: lifetime_customer_value {
        field: order_items.total_revenue
      }
    }
  }
  # Define the view's fields as desired
  dimension: user_id {
    hidden: yes
  }
  dimension: lifetime_number_of_orders {
    type: number
  }
  dimension: lifetime_customer_value {
    type: number
  }
}

Vous pouvez ajouter des filtres pour créer une table dérivée native user_90_day_facts :

view: user_90_day_facts {
  derived_table: {
    explore_source: order_items {
      column: user_id {
        field: order_items.user_id
      }
      column: number_of_orders_90_day {
        field: order_items.order_count
      }
      column: customer_value_90_day {
        field: order_items.total_revenue
      }
      filters: [order_items.created_date: "90 days"]
    }
  }
  # Add define view's fields as desired
  dimension: user_id {
    hidden: yes
  }
  dimension: number_of_orders_90_day {
    type: number
  }
  dimension: customer_value_90_day {
    type: number
  }
}

Créer des filtres pour le mode Développement

Il arrive qu'une table dérivée native soit très longue à générer, ce qui peut être frustrant si vous testez de nombreuses modifications en mode Développement. Dans ce cas, vous pouvez utiliser dev_filters pour créer des versions de développement plus petites d'une table dérivée native :

view: e_faa_pdt {
  derived_table: {
  ...
    datagroup_trigger: e_faa_shared_datagroup
    explore_source: flights {
      dev_filters: [flights.event_date: "90 days"]
      filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
      column: id {}
      column: airport_name {}
      column: event_date {}
    }
  }
...
}

Cet exemple inclut un paramètre dev_filters qui filtre les données des 90 derniers jours et un paramètre filters qui filtre les données des deux dernières années pour l'aéroport de Yucca Valley. Le paramètre dev_filters fonctionne parallèlement au paramètre filters afin que tous les filtres soient appliqués à la version de développement de la table. Si dev_filters et filters spécifient tous les deux des filtres pour la même colonne, dev_filters est prioritaire pour la version de développement de la table. Dans cet exemple, la version de développement de la table filtrera les données des 90 derniers jours pour l'aéroport de Yucca Valley.

Si une table dérivée native comprend le paramètre dev_filters, la table de développement ne peut pas être utilisée en tant que version de production, car la version de développement dispose d'un jeu de données abrégé. Dans ce cas, après avoir terminé le développement de la table et avant de déployer vos modifications, vous pouvez exclure par commentaire le paramètre dev_filters, puis interroger la table en mode Développement. Looker générera alors une version complète de la table qui pourra être utilisée pour la production lorsque vous déploierez vos modifications. Pour en savoir plus sur l'utilisation des tables de développement en production, consultez la page de documentation Tables dérivées dans Looker.

Notez que l'inverse est vrai : si vous disposez d'une table dérivée native avec le paramètre dev_filters et que vous l'interrogez en mode Développement, Looker peut utiliser la table de production pour répondre à votre requête en mode Développement. Cette affirmation est vraie, sauf si vous modifiez la définition de la table, puis interrogez la table en mode Développement. Dans ce cas, Looker créera une table de développement pour répondre à la requête.

Transmettre des filtres à une table dérivée native

Lorsque vous incluez une table dérivée native dans une exploration, vous pouvez prendre des filtres d'exécution de l'exploration et les appliquer à la requête de la table dérivée native. Pour ce faire, ajoutez le paramètre bind_all_filters ou bind_filters à la explore_source de la table dérivée native.

Lorsque vous transmettez des filtres d'exécution d'une exploration à une sous-requête de table dérivée native, le filtre d'exécution doit se trouver dans une vue jointe à la même exploration que la table dérivée native. De plus, comme la table dérivée native doit se régénérer au moment de l'exécution pour intégrer les filtres d'exécution de l'exploration, elle ne peut pas être une table dérivée persistante (PDT).

Utiliser bind_all_filters

Le moyen le plus simple de transmettre des filtres d'une exploration à une sous-requête de table dérivée native consiste à spécifier bind_all_filters: yes dans le paramètre explore_source de la table dérivée native. Vous transmettez ainsi tous les filtres d'exécution d'une exploration à la sous-requête de la table dérivée native.

Une table dérivée native avec bind_all_filters: yes doit être jointe à la même exploration que celle spécifiée dans le paramètre explore_source de la table dérivée native. Si vous souhaitez utiliser la table dérivée native dans une autre exploration, appliquez plutôt le paramètre bind_filters, comme décrit dans la section Utiliser bind_filters.

Voici le code LookML d'une table dérivée native avec bind_all_filters: yes :


view: top_10_simple_item_names {
  view_label: "Top 10s"
  derived_table: {
    explore_source: order_items {
      column: total_sale_price {
        field: order_items.total_sale_price
      }
      column: item_name {
        field: products.item_name
      }
      derived_column: rank {
        sql: RANK() OVER (ORDER BY total_sale_price DESC) ;;
      }
      bind_all_filters: yes
      sorts: [order_items.total_sale_price: desc]
      timezone: "query_timezone"
      limit: 10
    }
  }
  dimension: item_name {
    group_label: "Simple Example"
  }
  dimension: rank {
    type: number
    group_label: "Simple Example"
  }
  dimension: item_name_ranked {
    group_label: "Simple Example"
    order_by_field: rank
    type: string
    sql: ${rank} || ') ' || ${item_name} ;;
  }
}

Dans la vue de la table dérivée native, explore_source est défini sur order_items. Voici le code LookML pour l'exploration order_items dans laquelle la table dérivée native est jointe à l'exploration :

explore: order_items {
  ...
  join: top_10_simple_item_names {
    type: inner
    relationship: many_to_one
    sql_on: ${products.item_name} = ${top_10_simple_item_names.item_name} ;;
  }
}

Pour voir cet exemple en action, consultez le post de la communauté [Bloc analytique] – Croiser par Top X – Présentation de bind_all_filters: yes.

Utiliser bind_filters

Le sous-paramètre bind_filters de explore_source transmet un filtre spécifique de la requête d'exploration à la sous-requête de la table dérivée native :

  • to_field correspond au champ de la table dérivée native auquel le filtre est appliqué. to_field doit être un champ de explore_source sous-jacent.
  • from_field spécifie le champ de l'exploration à partir de laquelle obtenir le filtre, si l'utilisateur indique un filtre lors de l'exécution.

Lors de l'exécution, tous les filtres sur le from_field de l'exploration sont transmis au to_field de la sous-requête de la table dérivée native.

Le code LookML suivant montre une table dérivée native avec bind_filters. Avec cette configuration, Looker prendra n'importe quel filtre appliqué au champ filtered_lookml_dt.filter_date dans l'exploration et l'appliquera au champ users.created_date dans la table dérivée native.

derived_table: {
  explore_source: order_items {
    bind_filters: {
      to_field: users.created_date
      from_field: filtered_lookml_dt.filter_date
    . . .
    }
  }
}

Éléments à prendre en compte

Utiliser un seul paramètre explore_source

Chaque tableau dérivé natif n'accepte qu'un seul paramètre explore_source. Les paramètres explore_source suivants ne généreront pas d'erreurs de validation LookML, mais ils remplaceront les paramètres explore_source précédents.

Pour créer des colonnes à partir de champs de différentes vues, commencez par joindre les différentes vues dans la même exploration. Utilisez ensuite cette exploration pour explore_source.

Utiliser des instructions include pour référencer des champs

Lorsque vous créez une table dérivée native, vous devez inclure le fichier contenant la définition de l'exploration. Pour ce faire, la meilleure solution consiste à définir l'exploration dans un fichier séparé, comme décrit dans la documentation sur la création de fichiers Explore.

Si vous créez un fichier Explore distinct :

  • Le fichier de vue de la table dérivée native doit inclure le fichier de l'exploration. Exemple :
    • include: "/explores/order_items.explore.lkml"
  • Le fichier de l'exploration doit inclure les fichiers de vue dont il a besoin. Exemple :
    • include: "/views/order_items.view.lkml"
    • include: "/views/users.view.lkml"
  • Le modèle doit inclure le fichier de l'exploration. Exemple :
    • include: "/explores/order_items.explore.lkml"