source_exploration

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 sur les paramètres test.

Utilisation

:

Hiérarchie Afficher le fichier view derived_table explore_source

Valeur par défaut Aucun Acceptation Identifiant de la table Explorer à partir de laquelle la table dérivée native est dérivée, plus les sous-paramètres qui définissent 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 s'il s'agissait d'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 quelles colonnes seront incluses 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 horaires de la table dérivée native en fuseaux horaires différents.

CONSEIL: Le moyen le plus simple de créer une table dérivée native consiste à utiliser une exploration pour créer la requête souhaitée, puis à sélectionner l'option Get LookML. Looker génère la table dérivée LookML pour la requête, que vous pouvez copier dans un fichier d'affichage de votre projet LookML. Pour en savoir plus, consultez la page Créer des tables dérivées natives.

Définir une table dérivée native

Vous pouvez utiliser divers paramètres dans une table dérivée native, dont beaucoup sont facultatifs. Vous trouverez ci-dessous la syntaxe permettant de définir une table dérivée, ainsi que des informations supplémentaires sur chaque paramètre.

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"
}

Où :

Nom du paramètre	Description	Exemple
bind_filters	Transmettre un filtre de la requête "Explorer" à la sous-requête de table dérivée native. Pour le configurer, utilisez le sous-paramètre from_field afin de spécifier un champ défini dans la vue de table dérivée native ou accessible dans la section "Explorer" à laquelle la table native native est jointe. Au moment de l'exécution, tous les filtres de from_field dans l'exploration seront transmis à to_field dans la sous-requête de table dérivée native. Pour obtenir un exemple, consultez cette section ci-dessous. Remarque concernant bind_filters : • Le filtre d'exécution doit se trouver dans une vue jointe à la même table "Explore" 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 avoir 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 Explorer dans la sous-requête de table dérivée native. Pour le configurer, spécifiez bind_all_filters: yes dans le explore_source de la table dérivée native. Pour obtenir un exemple, consultez cette section ci-dessous. Remarque concernant bind_all_filters: yes : • Le filtre d'exécution doit se trouver dans une vue jointe à la même table "Explore" que la table dérivée native. • La table dérivée native ne peut pas être convertie en PDT. • La table dérivée native ne peut être jointe que dans l'onglet "Explorer" spécifié 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 la fonction Explorer aux champs de la table dérivée native. • Le paramètre explore_source peut avoir le sous-paramètre bind_all_filters ou le sous-paramètre bind_filters, mais pas les deux.	bind_all_filters: yes
column	Spécifie une colonne à inclure dans explore_source. Comporte un sous-paramètre field.	column: cust_id {   field: orders.customer_id }
derived_column	Spécifie une colonne de explore_source avec une expression dans l'espace de noms des colonnes intérieures. 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. Comporte un sous-paramètre sql.	derived_column: average_order {   sql: order_amount / item_qty ;; }
dev_filters	ADDED 21.12 Spécifie les filtres que Looker applique uniquement aux versions de développement de la table dérivée. Cette fonctionnalité est utile pour les 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 que la table soit entièrement créée après chaque modification. Looker applique dev_filters uniquement 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. Consultez la page de documentation Tables dérivées dans Looker pour en savoir plus sur l'utilisation des tables dérivées en mode développement, ainsi que 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	Spécifie éventuellement une expression de filtre personnalisée sur une requête explore_source.	expression_custom_filter:   ${orders.status} = "pending" ;;
filters	(Facultatif) Ajoute un filtre à une requête explore_source. Placez le nom du champ à filtrer entre crochets. Utilisez le format view_name.field_name, puis : et les 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	Spécifie la limite du nombre de lignes pour la requête (facultatif).	limit: 10
sorts	Spécifie un tri pour cette propriété (explore_source). Placez le nom du champ sur lequel vous souhaitez le trier, entre crochets. Utilisez le format view_name.field_name, puis :, asc ou desc, afin d'indiquer si le champ doit être trié par ordre croissant ou décroissant. Vous pouvez effectuer un tri sur plusieurs champs en ajoutant plusieurs paires nom/champ séparées par une virgule.	sorts: [products.brand: asc, products.name: asc]
timezone	Définit le fuseau horaire pour 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. Consultez la page Valeurs timezone pour obtenir la liste des fuseaux horaires acceptés. L'IDE suggère automatiquement la valeur de 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"

Examples

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

Créez une table dérivée native de 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 user_90_day_facts native:

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

Dans certains cas, la création de la table dérivée native que vous créez prend beaucoup de temps, ce qui peut prendre beaucoup de temps 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 et de l'aéroport de la Yucca Valley. Le paramètre dev_filters fonctionne conjointement avec le 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 des filtres pour la même colonne, les dev_filters sont prioritaires 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 comporte le paramètre dev_filters, la table de développement ne peut pas être utilisée comme version de production, car la version de développement contient un ensemble de données abrégé. Si tel est le cas, vous pouvez mettre en commentaire le paramètre dev_filters une fois que vous avez terminé de développer la table et avant de déployer vos modifications, 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 Tables dérivées dans Looker.

Notez que la situation inverse est vraie. Si vous avez une table dérivée native avec le paramètre dev_filters et que vous l'interrogez en mode de développement, Looker peut utiliser la table de production pour répondre à votre requête en mode de développement. Cela est vrai, sauf si vous modifiez la définition de la table, puis interrogez la table en mode de développement. Looker créera alors une table de développement pour répondre à la requête.

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

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

Lorsque vous transmettez des filtres d'exécution d'une requête Explorer à 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 table Explorer que la table dérivée native. De plus, étant donné que la table dérivée native doit être régénérée au moment de l'exécution afin d'intégrer les filtres d'exécution de la fonction Explorer, la table dérivée native ne peut pas être une table dérivée persistante (PDT).

Utiliser un fichier de cookie (bind_all_filters)

Le moyen le plus simple de transmettre des filtres d'une requête Explorer à 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. Cette action transmet tous les filtres d'exécution d'une tâche Explorer dans la sous-requête de 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, utilisez plutôt le paramètre bind_filters, comme décrit dans cette section.

Voici le style 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 native de la table dérivée ci-dessus, explore_source est order_items. Voici le LookML de la section order_items Explorer à laquelle la table dérivée native est jointe:

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 un exemple à l'œuvre, consultez l'article de la communauté [Analytic Block] – Pivot by Top X – Présentation de bind_all_filters: yes.

Utiliser un fichier de cookie (bind_filters)

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

• to_field est le champ de la table dérivée native à laquelle le filtre est appliqué. to_field doit être un champ de la propriété explore_source sous-jacente.
• from_field spécifie le champ dans l'exploration à partir duquel le filtre doit être obtenu, si l'utilisateur spécifie un filtre au moment de l'exécution.

Au moment de l'exécution, tous les filtres de from_field dans l'exploration seront transmis à to_field dans la sous-requête de table dérivée native.

Le LookML ci-dessous présente une table dérivée native avec bind_filters. Avec cette configuration, Looker utilise tout filtre appliqué au champ filtered_lookml_dt.filter_date dans l'onglet "Explorer" et l'applique au champ users.created_date de 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

Utilisez un seul paramètre explore_source

Chaque table dérivée native n'accepte qu'un seul paramètre explore_source. Les paramètres explore_source suivants n'entraîneront pas d'erreurs de validation LookML, mais remplaceront les paramètres explore_source précédents.

Pour créer des colonnes à partir de champs dans différentes vues, associez d'abord les différentes vues dans la même vue. puis utilisez "Explorer" pour explore_source.

Utiliser les instructions include pour activer les champs de référence

Lorsque vous créez une table dérivée native, vous devez inclure le fichier contenant la définition de la fonction Explorer. Pour ce faire, le meilleur moyen est de définir Explorer dans un fichier Explorer distinct, comme décrit dans la documentation sur la création de fichiers Explorer.

Si vous créez un fichier Explorer distinct:

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