Comment Snowflake valide les vues sémantiques

Snowflake vérifie qu’il respecte un ensemble de règles de validation lorsque vous définissez une vue sémantique. Ces règles garantissent que votre modèle sémantique est bien formé et qu’il fonctionnera correctement.

Ces règles sont expliquées dans les sections suivantes :

Règles de validation générales

Les règles suivantes s’appliquent aux vues sémantiques en général :

  • Éléments requis : une vue sémantique doit définir au moins une dimension ou une métrique.

    Par exemple, votre vue sémantique TPC-H a besoin d’au moins une dimension (comme customer_name) ou d’une métrique (comme order_average_value).

  • Clés primaires et étrangères : dans les définitions des clés primaires et étrangères, vous devez utiliser des colonnes physiques de la table de base ou des expressions définies dans les tables logiques qui font directement référence à une colonne de la table de base (par exemple, t1.fact AS t1.col).

    Par exemple, dans le schéma TPC-H, vous pouvez utiliser c_custkey comme clé primaire de la table customer et o_custkey comme clé étrangère de la table orders. c_custkey et o_custkey sont des colonnes des tables de base physiques.

  • Références aux alias de tables : lorsque vous faites référence à des tables dans des relations ou des expressions, vous devez utiliser les alias qui ont été définis pour elles.

    Par exemple, si vous définissez l’alias de table orders AS snowflake_sample_data.tpch.orders_table, vous devez utiliser l’alias de table orders (et non orders_table) dans la définition de vos métriques.

    Si vous ne spécifiez pas d’alias pour une table logique, vous devez utiliser le nom de la table logique dans toutes les expressions.

Règles de validation des relations

Les règles suivantes s’appliquent aux relations définies dans les vues sémantiques :

  • Relations plusieurs à un : les relations fonctionnent comme des contraintes de clé étrangère.

    Par exemple, lorsque vous définissez une relation comme orders (o_custkey) REFERENCES customers (c_custkey), vous créez une relation plusieurs à un de orders à customers (plusieurs commandes pouvant appartenir à un seul client), où c_custkey doit être une clé primaire.

  • Relations transitives : Snowflake déduit automatiquement les relations indirectes.

    Par exemple, si vous définissez une relation entre line_items et orders et une autre relation entre orders et customer, Snowflake comprend qu’il existe également une relation entre line_items et customer.

  • Pas de relations circulaires : vous ne pouvez pas définir de relations circulaires, même par le biais de chemins transitifs.

    Par exemple, vous ne pouvez pas définir une relation de orders à customer et une autre relation de customer à orders.

  • Pas d’autoréférences : actuellement, une table ne peut pas faire référence à elle-même (comme dans une hiérarchie de responsables d’employés où les employés peuvent faire référence à d’autres employés en tant que responsables).

  • Restrictions relatives aux relations multichemins : vous pouvez définir des relations multiples entre deux tables, mais certaines limitations s’appliquent.

    Par exemple, si line_items est liée à orders par l’intermédiaire de order_key et d’une autre colonne, ces tables ne peuvent pas faire référence aux expressions sémantiques l’une de l’autre.

    Note

    S’il existe plusieurs chemins qui peuvent être utilisés pour joindre deux tables, vous devez définir des tables logiques et des relations distinctes pour chaque chemin. Pour plus d’informations, voir Définition de différentes tables logiques pour différents chemins qui joint deux tables.

  • Restrictions relatives aux relations individuelles : les relations un à un sont soumises à des limitations.

    Par exemple, supposons que vous définissiez une relation orders(id) REFERENCES order_summary, où id est une clé primaire ou a des valeurs uniques dans orders. order_summary ne peut pas faire référence à des expressions sémantiques présentes dans orders, mais orders peut faire référence à des expressions sémantiques présentes dans order_summary.

Règles de validation des expressions

Les règles suivantes s’appliquent aux expressions sémantiques utilisées dans les faits, les dimensions et les métriques :

Règles générales concernant les expressions

Les règles suivantes s’appliquent aux expressions sémantiques en général :

  • Types d’expression : les dimensions et les faits sont des expressions de niveau ligne (non agrégées), tandis que les métriques sont des expressions de niveau agrégat.

    Par exemple, customer_name est une dimension (de niveau ligne), tandis que order_average_value est une métrique (de niveau agrégat).

  • Association à une table : chaque expression sémantique doit être associée à une table.

    Par exemple, customer_name doit être défini comme customer.customer_name et order_average_value comme orders.order_average_value.

  • Références à la même table : les expressions peuvent faire référence aux colonnes de la table de base ou à d’autres expressions de la même table logique en utilisant des noms qualifiés ou non.

    Par exemple, dans la table orders, vous pouvez définir orders.shipping_month comme suit :

    • MONTH(o_shipdate) (en utilisant le nom de colonne non qualifié)

    • MONTH(orders.o_shipdate) (en utilisant le nom qualifié)

  • Limitations relatives aux tables croisées : les expressions ne peuvent pas faire référence aux colonnes de la table de base d’autres tables ou à des expressions de tables logiques non liées.

    Par exemple, customer.customer_name ne peut pas faire directement référence à une expression de la table orders, sauf s’il existe une relation entre elles. Pour travailler avec des données à l’échelle de plusieurs tables, vous devez :

    1. Définir les relations entre les tables logiques (par exemple, entre customer et orders par l’intermédiaire de c_custkey).

    2. Définir un fait sur la table source (par exemple, orders.total_value).

    3. Faire référence à ces expressions à partir d’une table logique connectée (par exemple, customer.order_value peut faire référence à orders.total_value).

  • Résolution des noms : si une expression sémantique et une colonne portent le même nom, les références à ce nom sont résolues en fonction de l’expression sémantique.

    Par exemple, si vous définissez une dimension region et qu’il existe également une colonne region, region dans les expressions renvoie à la dimension, et non à la colonne. Une exception est faite lorsqu’une expression fait référence au même nom dans sa définition (par exemple, customer.c_name AS customers.c_name). La référence renvoie à la colonne, plutôt qu’à l’expression de définition elle-même.

  • Cycles de référence d’expressions : vous ne pouvez pas créer de références circulaires entre les expressions.

    Par exemple, vous ne pouvez pas définir customer.total_value par rapport à orders.customer_value puis définir orders.customer_value par rapport à customer.total_value.

  • Cycles de référence de tables : vous ne pouvez pas créer de références circulaires entre les tables logiques dans les définitions d’expressions.

    Par exemple, vous ne pouvez pas définir customer.total_value par rapport à orders.customer_value puis définir orders.customer_count par rapport à customer.c_custkey.

  • Utilisation de la fonction : vous pouvez utiliser des fonctions scalaires comme YEAR* / DAY* / WEEK* / MONTH / QUARTER dans les dimensions, mais les fonctions de table ne sont pas autorisées.

Règles pour les expressions de niveau ligne (dimensions et faits)

Les règles suivantes s’appliquent aux expressions de niveau ligne dans les dimensions et les faits :

  • Références à la même table : une expression de niveau ligne peut faire directement référence aux colonnes de sa propre table.

    Par exemple, customers.customer_name peut être défini directement comme customers.c_name.

  • Granularité égale ou inférieure : une expression de niveau ligne peut faire directement référence à d’autres expressions de niveau ligne de granularité égale ou inférieure.

    Par exemple, orders.order_details peut faire référence à customer.customer_name parce que customer se situe à un niveau de granularité inférieur à orders (un client peut avoir plusieurs commandes).

  • Références à une granularité supérieure : lors du référencement d’expressions de niveau ligne à une granularité supérieure, une expression de niveau ligne doit utiliser l’agrégation.

    Par exemple, customer.total_orders doit utiliser COUNT(orders.o_orderkey) parce que orders a une granularité plus élevée que customer (un client peut avoir plusieurs commandes).

  • Références agrégées : une dimension telle que orders.order_type ne peut pas faire référence à une métrique telle que orders.order_average_value, mais customer.customer_segment peut faire référence à orders.order_average_value parce que customer se situe à un niveau de granularité inférieur à celui des commandes.

Règles pour les expressions de niveau agrégat (métriques)

Les règles suivantes s’appliquent aux expressions de niveau agrégat dans les métriques :

  • Agrégation de base : une métrique doit utiliser une fonction d’agrégation.

    Par exemple, orders.order_average_value doit utiliser AVG(orders.o_totalprice).

  • Granularité égale ou inférieure : lorsqu’elle fait référence à des expressions de niveau ligne à une granularité égale ou inférieure, une métrique doit utiliser un seul agrégat.

    Par exemple, orders.total_value peut utiliser SUM(line_items.discounted_price) parce que line_items a une granularité inférieure à celle des commandes.

  • Références à une granularité supérieure : lorsqu’elle fait référence à des expressions de niveau ligne à une granularité supérieure, une métrique doit utiliser l’agrégation imbriquée.

    Par exemple, customer.average_order_value doit utiliser AVG(SUM(orders.o_totalprice)) parce que orders est à une granularité plus élevée que customer.

  • Autres références agrégées : une métrique peut faire directement référence à d’autres métriques de granularité égale ou inférieure sans agrégation.

    Par exemple, orders.profit_margin peut être défini comme orders.total_revenue / orders.total_cost sans agrégation supplémentaire. Cependant, lorsqu’on se réfère à des métriques à une granularité plus élevée, une agrégation est nécessaire.

Règles pour les métriques de la fonction de fenêtre

Ces règles s’appliquent aux métriques de la fonction de fenêtre :

  • Les métriques de fonction de fenêtre ne peuvent pas être utilisées par des calculs au niveau des lignes (faits et dimensions).

  • Les métriques de fonction de fenêtre ne peuvent pas être utilisées dans les définitions d’autres métriques.

Langage: Français