table dérivée

Utilisation

view: my_view {
derived_table: { ... }
}

Hiérarchie Afficher le fichier view derived_table

Valeur par défaut Aucun

Définition

Une table dérivée peut être traitée comme une table normale dans votre base de données. Vous pouvez créer l'un des types de tables dérivées suivants:

• Une table dérivée native définie à l'aide du paramètre explore_source
• Une table dérivée de SQL utilisant une requête SQL brute que vous définissez à l'aide du paramètre sql

Certains cas particuliers ne permettent pas l'utilisation du paramètre sql. Dans ce cas, Looker accepte les paramètres suivants pour définir une requête SQL pour les PDT :

create_process

sql_create

Avec les paramètres sql, create_process ou sql_create, vous définissez toujours la table dérivée avec une requête SQL. Elles sont donc toutes considérées comme des tables dérivées SQL.

Le paramètre derived_table démarre une section de LookML dans laquelle vous définissez le mode de calcul d'une table dérivée, les index ou les clés qu'elle doit utiliser et le moment où elle doit être régénérée.

Les tables dérivées peuvent être des tables dérivées temporaires calculées ponctuellement à mesure que les utilisateurs leur demandent des données, ou il peut s'agir de tables dérivées persistantes qui sont conservées sur votre base de données à l'aide d'une stratégie de persistance.

Si votre administrateur a activé la fonctionnalité expérimentale des PDT incrémentiels et que votre dialect est compatible, vous pouvez utiliser des PDT incrémentiels dans votre projet. Un PDT incrémentiel est créé de manière incrémentielle en ajoutant des données récentes à la table, au lieu de la reconstruire entièrement. Pour en savoir plus, consultez la page de documentation sur les PDT incrémentiels.

Pour en savoir plus sur les tables dérivées, consultez la page de documentation Tables dérivées dans Looker.

Examples

Créez une table dérivée customer_order_facts native avec le paramètre explore_source:

view: customer_order_facts {
  derived_table: {
    explore_source: order {
      column: customer_id { field: order.customer_id }
      column: lifetime_orders { field: order.count }
      column: lifetime_spend { field: order.total_spend }
    }
  }
}

Créez une table dérivée de customer_order_facts avec le paramètre sql:

view: customer_order_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,
        COUNT(*) AS lifetime_orders,
        SUM(total) AS lifetime_spend
      FROM
        order
      GROUP BY
        customer_id ;;
  }
}

Éléments à prendre en compte

Évitez de trop utiliser les tables dérivées pour créer des solutions SQL pures

Les utilisateurs qui maîtrisent particulièrement le SQL utilisent souvent des tables dérivées pour résoudre des problèmes liés à des requêtes SQL complexes, dont les résultats peuvent alors être présentés aux utilisateurs. Même s'il est parfois nécessaire de le faire, il peut également passer à côté de la nature modulaire et réutilisable de LookML, ce qui peut conduire les utilisateurs à explorer leurs données de façon rigide.

Nous vous suggérons de réfléchir à l'objectif sous-jacent de votre requête SQL, puis de convertir cette logique en LookML au lieu de copier et coller les requêtes existantes dans une table dérivée. Si vous avez besoin d'aide pour créer des analyses qui ne s'appuient pas sur des tables dérivées, les analystes de l'assistance Looker sont là pour vous aider avec les bonnes pratiques.

Dialectes de base de données compatibles avec les tables dérivées

Dialectes de base de données pris en charge pour les tables dérivées temporaires

Pour que Looker prenne en charge les tables dérivées dans votre projet, votre dialecte de base de données doit également les prendre en charge. Le tableau suivant indique les dialectes compatibles avec les tables dérivées de la dernière version de Looker:

Dialectes de base de données compatibles avec les tables dérivées persistantes

Pour que Looker prenne en charge les tables PDT dans votre projet, votre dialecte de base de données doit également les prendre en charge.

Pour prendre en charge tout type de tables dérivées persistantes (basées sur LookML ou SQL), le dialecte doit être compatible avec les écritures dans la base de données, entre autres. Certaines configurations de base de données en lecture seule ne permettent pas le fonctionnement de la persistance (le plus souvent, des bases de données d'instances dupliquées de substitution à chaud Postgres). Dans ce cas, vous pouvez utiliser des tables dérivées temporaires à la place.

Le tableau suivant présente les dialectes compatibles avec les tables dérivées SQL persistantes de la dernière version de Looker:

Pour prendre en charge les tables dérivées natives persistantes (qui ont des requêtes basées sur LookML), le dialecte doit également être compatible avec une fonction LDD CREATE TABLE. Voici la liste des dialectes compatibles avec les tables dérivées natives (basées sur LookML) de la dernière version de Looker:

Les disques persistants ne sont pas compatibles avec les connexions Snowflake qui utilisent OAuth.

Dialectes de base de données pris en charge pour les augmentations de tables PDT

Pour que Looker accepte les PDT incrémentiels dans votre projet Looker, votre dialecte de base de données doit accepter les commandes LDD (langage de définition de données) qui permettent de supprimer et d'insérer des lignes.

Le tableau suivant présente les dialectes compatibles avec les PDT incrémentiels dans la dernière version de Looker: