Spécification YAML pour les vues sémantiques¶
Les vues sémantiques sont des objets de niveau schéma qui définissent des concepts métier sur vos données, facilitant ainsi l’interrogation et l’analyse des données par les utilisateurs à l’aide d’une terminologie métier. Vous pouvez utiliser la spécification YAML pour créer une vue sémantique dans Cortex Analyst ou utiliser la procédure stockée SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML pour créer une vue sémantique à partir d’une spécification YAML.
Vue d’ensemble¶
Les vues sémantiques sont l’approche recommandée pour définir la sémantique métier dans Snowflake. Elles sont des objets de niveau schéma qui s’intègrent au système de privilèges, aux mécanismes de partage et au catalogue de métadonnées de Snowflake.
Note
Les fichiers YAML du modèle sémantique hérité (stockés dans des zones de préparation) peuvent toujours être utilisés avec Cortex Analyst pour la rétrocompatibilité, mais nous vous recommandons d’utiliser les vues sémantiques pour les nouvelles implémentations.
Les avantages des vues sémantiques par rapport aux modèles sémantiques hérités sont les suivants :
Intégration native de Snowflake : Objets de niveau schéma avec prise en charge complète du RBAC, du partage et du catalogue
Fonctionnalités avancées : Prise en charge des métriques dérivées et des modificateurs d’accès (public/privé)
Meilleure gouvernance : Intégration aux systèmes de privilèges et de partage de Snowflake
Gestion simplifiée : Gestion des fichiers YAML dans les zones de préparation non nécessaire
Format YAML¶
Les vues sémantiques peuvent prendre une spécification YAML pour définir leur comportement, permettant des définitions lisibles et en texte brut.
La syntaxe générale d’une spécification YAML de vue sémantique est :
Important
Les vues sémantiques ne requièrent pas les champs join_type ou relationship_type qui étaient utilisés dans les modèles sémantiques hérités. Le type de relation est automatiquement déduit des données.
Concepts clés¶
Tables¶
Les tables logiques représentent des entités commerciales (telles que des clients, des commandes ou des produits) et sont mappées à des tables de bases de données physiques. Chaque table logique peut définir :
Table de base : Nom entièrement qualifié de la table physique
Clé principale : Colonnes qui identifient les lignes de manière unique
Synonymes : Noms alternatifs de la table
Description : Explication commerciale conviviale de ce que représente la table
Dimensions¶
Les dimensions représentent des attributs catégoriques qui fournissent du contexte pour l’analyse. Elles répondent aux questions « qui », « quoi », « où » et « quand ». Les dimensions peuvent être :
Dimensions ordinaires : Valeurs textuelles ou numériques, ou autres valeurs catégorielles
Dimensions temporelles : Colonnes de date ou d’horodatage avec traitement spécial basé sur le temps
Propriétés des dimensions¶
expr: expression SQL pour calculer la valeur de la dimensionsynonyms: Termes alternatifs que les utilisateurs peuvent utiliserunique: Si les valeurs sont uniques à travers les lignesis_enum: Si la dimension possède un ensemble fixe de valeurscortex_search_service: Cortex Search Service facultatif pour la recherche sémantique
Propriétés facultatives pour les dimensions physiques¶
Ces champs sont facultatifs, mais recommandés pour produire des résultats de meilleure qualité à partir d’une recherche de vues sémantiques.
synonymsUne liste d’autres termes/expressions utilisés pour désigner cette dimension. Doit être unique parmi tous les synonymes de ce modèle sémantique.
descriptionBrève description de cette dimension. Incluez des informations qui fournissent un contexte utile, comme les données que représente cette dimension.
uniqueUne valeur booléenne qui indique que cette dimension a des valeurs uniques.
sample_valuesExemples de valeurs de cette colonne, le cas échéant. Ajoutez toute valeur susceptible d’être référencée dans les questions des utilisateurs.
is_enumUne valeur booléenne. Si
True, les valeurs du champsample_valuessont considérées comme la liste complète des valeurs possibles, et le modèle ne choisit que parmi ces valeurs lors du filtrage sur cette colonne.cortex_search_serviceSpécifie le service Cortex Search Service à utiliser pour cette dimension. Elle contient les domaines suivants :
service: Le nom du Cortex Search Service.literal_column: (facultatif) La colonne du Cortex Search Service qui contient les valeurs littérales.database: (facultatif) La base de données dans laquelle se trouve le Cortex Search Service. La valeur par défaut est la base de données debase_table.schema: (facultatif) Le schéma dans lequel le Cortex Search Service est situé. La valeur par défaut est le schéma debase_table.
cortex_search_serviceremplace le champcortex_search_service_name, qui ne pouvait spécifier que le nom.cortex_search_service_nameest obsolète.
Propriétés facultatives pour les dimensions temporelles¶
Ces champs sont facultatifs, mais recommandés pour produire des résultats de meilleure qualité à partir d’une recherche de vues sémantiques.
synonymsUne liste d’autres termes/expressions utilisés pour faire référence à cette dimension temporelle. Doit être unique parmi tous les synonymes de ce modèle sémantique.
descriptionBrève description de cette dimension. Incluez des informations qui fournissent un contexte utile, comme le fuseau horaire que cette dimension utilise comme point de référence.
unique:Une valeur booléenne qui indique que cette colonne a des valeurs uniques.
sample_values:Exemples de valeurs de cette colonne, le cas échéant. Ajoutez toutes les valeurs susceptibles d’être référencées dans les questions des utilisateurs.
Faits¶
Les faits sont des attributs quantitatifs au niveau des lignes qui représentent des événements commerciaux ou des transactions spécifiques. Les faits permettent de capturer les réponses à la question « combien » au niveau le plus fin, comme dans le cas de montants des ventes, de quantités achetées ou de coûts à l’échelon individuel.
Les faits interviennent généralement dans la vue sémantique comme des concepts « de support » facilitant la construction des dimensions et des métriques.
Les propriétés des faits sont les suivantes :
expr: expression SQL pour calculer la valeur du faitaccess_modifier: Définissez cette propriété surprivate_accesspour masquer le fait des requêtes (utile pour les calculs intermédiaires)data_type: Type de données du fait
Métriques¶
Les métriques sont des mesures quantifiables de performances métier, calculées en agrégeant des faits ou d’autres colonnes à l’aide de fonctions telles que SUM, AVG et COUNT.
Deux types de métriques :
Métriques au niveau de la table : Scopées à une table logique spécifique, agrégation des données au sein de cette table
Métriques dérivées : Métriques au niveau de la vue qui combinent les métriques de plusieurs tables
Propriétés des métriques¶
expr: expression SQL avec fonction d’agrégationaccess_modifier: Définissez cette propriété surprivate_accesspour masquer le fait des requêtes (utile pour les calculs intermédiaires)synonyms: Termes alternatifs pour la métrique
Propriétés facultatives des métriques¶
Si vous voulez spécifier les dimensions qui doivent être non additionnées pour la métrique, utilisez les champs suivants :
non_additive_dimensionsSpécifie les dimensions auxquelles la métrique ne doit pas être agrégée.
tableNom de la table logique contenant la dimension.
dimensionNom de la dimension.
sort_directionOrdre de tri pour la dimension non additionnée. Vous pouvez spécifier l’une des valeurs suivantes :
ascending: Trier les valeurs de dimension par ordre croissant.descending: Trier les valeurs de dimension par ordre décroissant.
Par défaut :
ascendingnull_orderIndique si les valeurs NULLs sont triées avant ou après les valeurs non NULL. Vous pouvez spécifier l’une des valeurs suivantes :
first: les valeurs NULLs sont triées avant les valeurs non NULL.last: les valeurs NULLs sont triées après les valeurs non NULL.
Par défaut : Dépend de la valeur dans le champ
sort_direction(ascendingoudescending) ; consultez les notes d’utilisation dans la documentation ORDER BY.
Note
Étant donné que les lignes sont triées par les dimensions non additionnées, l’ordre dans lequel vous spécifiez les dimensions est important. Ceci est similaire à l’ordre dans lequel vous spécifiez les colonnes dans la clause ORDER BY.
L’exemple suivant spécifie que la métrique
m_account_balancene peut pas être agrégée par les dimensionsyear_dimetmonth_dim:S’il existe plusieurs chemins de relation entre deux tables logiques spécifiques dans une vue sémantique, utilisez le champ suivant pour spécifier le chemin de relation à utiliser :
using_relationships-
Spécifie le nom de la relation à utiliser pour joindre les tables logiques lors du calcul de la métrique.
Métriques dérivées¶
Les métriques dérivées sont des métriques de niveau vue qui ne sont pas liées à une table spécifique. Elles peuvent combiner les métriques de plusieurs tables ou effectuer des calculs sur l’ensemble de la vue.
Exemple de métrique dérivée :
Relations¶
Les relations définissent la manière dont les tables logiques sont jointes entre elles. Chaque relation spécifie :
left_table: Table contenant la clé étrangèreright_table: Table référencéerelationship_columns: Paires de colonnes sur lesquelles joindre, commeleft_columnetright_column
Le type de relation (une à une, plusieurs à une) est automatiquement déduit des données et des définitions de clés primaires.
Note
Contrairement aux modèles sémantiques hérités, les vues sémantiques ne nécessitent pas de spécifications join_type ou relationship_type explicites. Celles-ci sont déterminées automatiquement.
Filters¶
Les filtres définissent des conditions de filtrage couramment utilisées qui peuvent être référencées par leur nom. Cela permet de garantir une logique de filtrage cohérente entre les requêtes.
Exemple :
Requêtes vérifiées¶
Les requêtes vérifiées sont des exemples de questions accompagnées des requêtes SQL correspondantes. Elles aident Cortex Analyst à comprendre comment répondre à des questions similaires et servent de documentation aux utilisateurs.
Propriétés :
question: Question en langage naturelsql: requête SQL qui répond à la questionverified_by: Personne facultative ayant vérifié que la requête est correcteverified_at: Horodatage facultatif lorsque vérifiéeuse_as_onboarding_question: Indicateur facultatif pour afficher ceci sous forme de suggestion aux utilisateurs
Modificateurs d’accès¶
Les vues sémantiques prennent en charge les modificateurs d’accès pour les faits et les métriques, ce qui vous permet de contrôler la visibilité :
public_access(par défaut) : Visible et interrogeable par les utilisateursprivate_access: Masqué des requêtes, utilisé uniquement pour les calculs intermédiaires
Exemple :
Instructions personnalisées dans Cortex Analyst¶
Vous pouvez utiliser des commandes SQL pour fournir des instructions personnalisées dans la définition de la vue sémantique. Ces instructions expliquent comment les requêtes sont générées et comment les questions sont classées. Ces instructions ne font pas partie de la spécification YAML, mais sont définies à l’aide de la commande CREATE SEMANTIC VIEW.
Pour plus d’informations, voir Fournir des instructions personnalisées pour Cortex Analyst.
Exemple de YAML de vue sémantique¶
Voici un exemple complet de spécification YAML de vue sémantique :
Création d’une vue sémantique à partir de YAML¶
Pour créer une vue sémantique à partir d’une spécification YAML, utilisez la procédure stockée SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML.
Pour plus d’informations, voir Création d’une vue sémantique à partir d’une spécification YAML.
Obtention de YAML à partir d’une vue sémantique¶
Pour exporter une vue sémantique au format YAML, utilisez la fonction SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW.
Pour plus d’informations, voir Obtenir la spécification YAML pour une vue sémantique.
Différences par rapport aux modèles sémantiques hérités¶
Si vous effectuez une migration à partir de fichiers YAML du modèle sémantique hérité vers des vues sémantiques, notez ces principales différences :
Fonctionnalité |
Modèles sémantiques hérités |
Vues sémantiques |
|---|---|---|
Stockage |
Fichiers YAML dans les zones de préparation |
Objets de niveau schéma dans la base de données |
Privilèges |
Contrôle d’accès basé sur les rôles |
Intégration RBAC Snowflake complète |
Partage |
Partage de fichiers manuel |
Partage Snowflake natif |
Type de jointure |
Nécessite |
Déduit automatiquement |
Métriques dérivées |
Non pris en charge |
Entièrement prise en charge |
Modificateurs d’accès |
Non pris en charge |
|
Instructions personnalisées |
Dans un fichier YAML |
Défini via des commandes SQL |
Lors de la conversion d’un modèle sémantique hérité en une vue sémantique :
Supprimez
join_typeetrelationship_typedes relationsEnvisagez d’utiliser des métriques dérivées pour les calculs au niveau des vues
Ajoutez
access_modifieraux faits/métriques que vous souhaitez rendre privésDéplacez les instructions personnalisées vers la commande SQL CREATE SEMANTIC VIEW
