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.

    Suppose that the logical table table_1 identifies col_1 as a primary key:

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

    When you define a relationship as table_2 (col_2) REFERENCES table_1 (col_1), col_1 must be a primary key, and col_2 must serve as a foreign key:

    • If multiple rows in table_2 use the same value in col_2, you’re creating a many-to-one relationship from table_2 to 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).

    • If each row in table_2 has a unique value in col_2, you’re creating a one-to-one relationship from table_2 to table_1.

      For example, customer_details_extended (e_custkey) REFERENCES customer_details (c_custkey) creates a one-to-one relationship from customer_details_extended to customer_details (one row of extended details for a customer belongs to one row of customer details with the key 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.

      For example, customer_details and customer_details_extended have a one-to-one relationship, where one row in customer_details is related to one row in customer_details_extended. A row-level expression on each of these tables refers to one specific customer. Each can refer directly to the other in row-level expressions because the row-level expressions are at the same granularity.

      As a corollary, a row-level expression on customer_details cannot reference a metric or aggregation of a row-level expression on customer_details_extended (and vice versa).

    • Aggregate-level expressions must refer to row-level expressions at the same granularity using a single aggregate.

      For example, aggregate-level expressions on customer_details or customer_details_extended must use a single aggregate when referencing the other entity. In addition, metrics on customer_details and customer_details_extended should refer to other metrics on the two entities directly, without any aggregation.

    These rules apply whether the relationship between the entities is defined as customer_details REFERENCES customer_details_extended or 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.

    Note that one-to-one relationships respect transitivity when interacting with other one-to-one and many-to-one relationships:

    • If logical tables customers and customer_details have a one-to-one relationship and logical tables customer_details and customer_details_extended have a one-to-one relationship, logical tables customers and customer_details_extended are automatically inferred to have a one-to-one relationship and are treated as such during validation.

    • If logical tables customers and customer_details have a one-to-one relationship and logical tables customer_details and regions have a many-to-one relationship, customers is inferred to be transitively many-to-one to regions, which gives customers a higher granularity than regions during expression validation.

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

  • 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