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 (commeorder_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 tablecustomer
eto_custkey
comme clé étrangère de la tableorders
.c_custkey
eto_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 tableorders
(et nonorders_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 deorders
à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
etorders
et une autre relation entreorders
etcustomer
, Snowflake comprend qu’il existe également une relation entreline_items
etcustomer
.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 decustomer
à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 deorder_key
et d’une autre colonne, ces tables ne peuvent pas faire référence aux expressions sémantiques l’une de l’autre.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 dansorders
.order_summary
ne peut pas faire référence à des expressions sémantiques présentes dansorders
, maisorders
peut faire référence à des expressions sémantiques présentes dansorder_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 queorder_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 commecustomer.customer_name
etorder_average_value
commeorders.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éfinirorders.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 tableorders
, sauf s’il existe une relation entre elles. Pour travailler avec des données à l’échelle de plusieurs tables, vous devez :Définir les relations entre les tables logiques (par exemple, entre
customer
etorders
par l’intermédiaire dec_custkey
).Définir un fait sur la table source (par exemple,
orders.total_value
).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 colonneregion
,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éfinirorders.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éfinirorders.customer_count
par rapport àcustomer.c_custkey.
Utilisation de fonctions : vous pouvez utiliser des fonctions scalaires telles que YEAR* / DAY* / WEEK* / MONTH / QUARTER dans les dimensions, mais les fonctions de table ne sont pas autorisées. Les fonctions de fenêtre sont autorisées dans les dimensions et les faits, mais pas dans les métriques.
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 commecustomers.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 quecustomer
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 utiliserCOUNT(orders.o_orderkey)
parce queorders
a une granularité plus élevée quecustomer
(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 queorders.order_average_value
, maiscustomer.customer_segment
peut faire référence àorders.order_average_value
parce quecustomer
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 utiliserAVG(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 utiliserSUM(line_items.discounted_price)
parce queline_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 utiliserAVG(SUM(orders.o_totalprice))
parce queorders
est à une granularité plus élevée quecustomer
.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 commeorders.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.