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 :

  • Many-to-one relationships and one-to-one relationships: Relationships work like foreign key constraints.

    Supposons que la table logique table_1 identifie col_1 en tant que clé principale :

    TABLES (
  table_1 AS my_table_1 PRIMARY KEY (col_1)
  ...
    Copy

    Lorsque vous définissez une relation comme table_2 (col_2) REFERENCES table_1 (col_1), col_1 doit être une clé principale, et col_2 doit servir de clé étrangère :

    • Si plusieurs lignes dans table_2 utiliser la même valeur dans col_2, vous créez une relation plusieurs-à-un à partir de table_2 dans table_1.

      For example, orders (o_custkey) REFERENCES customers (c_custkey) creates a many-to-one relationship from orders to customers (many orders can belong to one customer with the key c_custkey).

    • Si chaque ligne de table_2 a une valeur unique dans col_2, vous créez une relation « un à un » de table_2 à table_1.

      Par exemple, customer_details_extended (e_custkey) REFERENCES customer_details (c_custkey) crée une relation un à un de customer_details_extended à customer_details (une ligne de détails étendus pour un client appartient à une ligne de détails de client avec la clé c_custkey).

  • Validations performed on one-to-one relationships:

    • Row-level expressions can refer to other row-level expressions at the same (or lower) granularity.

      Par exemple, customer_details et customer_details_extended ont une relation « un à un », où une ligne de customer_details est liée à une ligne dans customer_details_extended. Une expression au niveau des lignes dans chacune de ces tables fait référence à un client spécifique. Chacune peut faire référence directement aux autres dans les expressions au niveau des lignes, car les expressions au niveau des lignes ont la même granularité.

      En tant que corollaire, une expression de niveau ligne sur customer_details ne peut pas référencer une métrique ou une agrégation d’une expression de niveau ligne sur customer_details_extended (et vice versa).

    • Les expressions de niveau agrégé doivent faire référence à des expressions au niveau des lignes de la même granularité en utilisant un seul agrégat.

      Par exemple, les expressions de niveau agrégé sur customer_details ou customer_details_extended doivent utiliser un seul agrégat lors de la référence à l’autre entité. En outre, les métriques sur customer_details et customer_details_extended doivent se référer directement à d’autres métriques sur les deux entités, sans aucune agrégation.

    Ces règles s’appliquent que la relation entre les entités soit définie comme customer_details REFERENCES customer_details_extended ou customer_details_extended REFERENCES customer_details.

  • 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.

    Notez que les relations un à un respectent la transitivité lorsqu’elles interagissent avec d’autres relations un à un et plusieurs à un :

    • Si les tables logiques customers et customer_details ont une relation un à un et des tables logiques customer_details et customer_details_extended ont une relation un à un, les tables logiques customers et customer_details_extended sont automatiquement déduites comme ayant une relation « un à un » et sont traitées comme telles lors de la validation.

    • Si les tables logiques customers et customer_details ont une relation un à un et les tables logiques customer_details et regions ont une relation plusieurs-à-un, on suppose que customers passe de plusieurs-à-un à regions, ce qui donne aux customers une granularité supérieure aux regions lors de la validation de l’expression.

  • 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.

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 :

  • Basic aggregation: A metric that is not a derived metric must use an aggregate function.

    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