Types d’objets pris en charge dans DCM Projects¶

L’instruction DEFINE est une commande spéciale utilisée exclusivement dans les fichiers de définition DCM project. Sa syntaxe est similaire à celle de la commande CREATE OR ALTER, mais avec les différences clés suivantes :

L’ordre et l’emplacement des instructions DEFINE n’ont pas d’importance. Snowflake collecte et trie toutes les instructions de tous les fichiers de définition pendant l’exécution du projet.
Si vous supprimez une instruction DEFINE qui a été précédemment déployée, Snowflake supprime l’objet correspondant la prochaine fois que vous déployez le projet. La même chose s’applique aux instructions GRANT etATTACH qui sont supprimées après avoir été précédemment déployées.
Seul un sous-ensemble de types d’objets Snowflake est pris en charge.
Tous les objets doivent être définis avec un nom pleinement qualifié (database.schema.object_name).
Les références à d’autres objets doivent utiliser des noms pleinement qualifiés.

Les types d’objets suivants sont pris en charge de manière native dans les fichiers de définition DCM Projects avec les instructions DEFINE, GRANT ou ATTACH.

Base de données
Schéma
<label-dcm_projects_object_type_table> Table
Vue (sécurisée)
:ref:`<label-dcm_projects_object_type_dynamic_table>Table dynamique `
<label-dcm_projects_object_type_task> Task
Format de fichier
Zone de préparation interne
Fonction SQL
Fonction de métrique des données
Entrepôt
Rôle, rôle de base de données
<label-dcm_projects_object_type_grant> Grant
Balise
Politique d’authentification

Base de données¶

Limites :

Toutes les limitations CREATE OR ALTER DATABASE s’appliquent, y compris :

Renommage de la base de données

Schéma¶

Limites :

Toutes les limitations CREATE OR ALTER SCHEMA s’appliquent, y compris :

Renommage du schéma

Table¶

Limites :

Toutes les limitations CREATE OR ALTER TABLE s’appliquent, y compris :

Renommage de tables
Renommage de colonnes
Réorganisation de colonnes
Modification des types de colonnes en types incompatibles
Ajout de l’optimisation de la recherche à une table ou à des colonnes
Ajout de balises et de politiques à une table ou à des colonnes

Vue¶

Limites :

Toutes les limitations CREATE OR ALTER VIEW s’appliquent, y compris :

Renommage de vues
Réorganisation de colonnes

Table dynamique¶

Changements pris en charge :

Sans actualisation complète :

Entrepôt
Décalage ciblé

Avec une réinitialisation ou une actualisation complète :

Actualiser le mode
Tout changement du corps, y compris :
- Supprimer des colonnes
- Ajout de colonnes à la fin

Arguments immuables :

INITIALIZE

Limites :

Toutes les limitations CREATE OR ALTER DYNAMIC TABLE s’appliquent, y compris :

Réorganisation de colonnes
Renommage de tables dynamiques

Tâche¶

Lorsque des modifications de définition sont déployées pour une tâche déjà démarrée, Snowflake suspend automatiquement cette tâche (ou sa tâche racine) temporairement, applique la modification, puis la reprend à nouveau.

Les tâches nouvellement déployées sont suspendues par défaut.

Limites :

Toutes les limitations CREATE OR ALTER TASK s’appliquent.

Format de fichier¶

Limites :

Toutes les limitations CREATE OR ALTER FILE FORMAT s’appliquent.

Zone de préparation interne¶

Changements pris en charge :

Table de répertoire
Commentaire

Attributs immuables :

Type de chiffrement

Limites :

Toutes les limitations CREATE OR ALTER STAGE s’appliquent.

Fonction SQL¶

Limites :

Toutes les limitations CREATE OR ALTER FUNCTION s’appliquent.

Fonction de métrique des données¶

Les fonctions de métrique des données (DMFs) vous permettent de définir des attentes en matière de qualité des données et de joindre ces attentes à des tables. Vous pouvez sélectionner des DMFs existantes ou écrire vos propres fonctions de métrique des données définies par l’utilisateur (UDMFs). Vous pouvez ensuite les joindre à des tables, des vues et des tables dynamiques avec une relation plusieurs-à-plusieurs. Pour plus d’informations, voir Utiliser SQL pour configurer des fonctions de métrique des données.

Pour joindre des fonctions de métrique des données, vous devez d’abord ajouter une DATA_METRIC_SCHEDULE à chaque définition de table, table dynamique ou définition de vue. Par exemple : DATA_METRIC_SCHEDULE = TRIGGER_ON_CHANGES. La planification TRIGGER_ON_CHANGES n’est pas disponible pour les vues.

Les noms des attentes définies par l’utilisateur doivent être uniques pour chaque projet et chaque élément joint.

La définition des attentes est facultative, mais recommandée lors de la jointure de DMFs à des colonnes de table. Les DMFs jointes sans attentes définies ne sont pas prises en compte lors de l’exécution de EXECUTE DCM PROJECT <my_project> TEST ALL.

Changements pris en charge :

Définition de UDMFs (fonctions de métrique des données définies par l’utilisateur)
Joindre des DMFs et UDMFs système à des tables, des vues ou des tables dynamiques à l’intérieur et à l’extérieur d’un DCM project
Définition des attentes en matière de données pour les colonnes de table

Exemple :

Exemple de définition d’une UDMF :

DEFINE DATA METRIC FUNCTION DCM_DEMO.TESTS.INVENTORY_SPREAD(
  TABLE_NAME TABLE(
    COLUMN_VALUE number
  )
)
  RETURNS number
AS
$$
  SELECT
    MAX(COLUMN_VALUE) - MIN(COLUMN_VALUE)
  FROM
    TABLE_NAME
  WHERE
    COLUMN_VALUE IS NOT NULL
$$;

Exemple de jointure d’une DMF système à une attente :

ATTACH DATA METRIC FUNCTION SNOWFLAKE.CORE.MIN
  TO TABLE DCM_PROJECT_{{db}}.RAW.INVENTORY
  ON (IN_STOCK)
  EXPECTATION MIN_10_ITEMS_INVENTORY (value > 10);

Exemple de jointure d’une UDMF à une attente :

ATTACH DATA METRIC FUNCTION DCM_DEMO.TESTS.INVENTORY_SPREAD
  TO TABLE DCM_PROJECT_{{db}}.RAW.INVENTORY
  ON (IN_STOCK)
  EXPECTATION EVEN_ITEM_INVENTORY (VALUE < 50);

Pour voir toutes les DMFs système disponibles, interrogez SHOW DATA METRIC FUNCTIONS IN DATABASE SNOWFLAKE.

Entrepôt¶

Attributs immuables :

INITIALLY_SUSPENDED

Limites :

Toutes les limitations CREATE OR ALTER WAREHOUSE s’appliquent.

Rôle et rôle de base de données¶

Types non pris en charge :

Rôle de l’application

Grant¶

Tout comme chaque objet ne peut être défini qu’une seule fois dans un DCM Projects, chaque relation privilège-bénéficiaire ne peut être définie qu’une seule fois dans tous les DCM Projects.

Lors de la suppression d’une instruction GRANT OWNERSHIP qui a été précédemment déployée, le DCM Projects tente d’utiliser le rôle de propriétaire actuel pour accorder à nouveau la propriété au propriétaire de l’DCM project. Si le rôle de propriétaire du projet ne détient pas le rôle de propriétaire de l’objet, la propriété doit alors être transférée manuellement en dehors du DCM Projects.

DCM Projects est uniquement au courant des attributions qui ont été définies et déployées via DCM Projects. Les attributions ajoutées en dehors du DCM Projects coexistent, et le DCM Projects ne les supprime pas.

Types GRANT non pris en charge :

Attributions APPLICATIONROLE
Attributions CALLER

Balise¶

Attributs non pris en charge :

Propager

Limites :

Toutes les limitations CREATE OR ALTER TAG s’appliquent.

Politique d’authentification¶

Limites :

Toutes les limitations CREATE OR ALTER AUTHENTICATION POLICY s’appliquent.

Joindre des balises, des politiques de masquage et des politiques d’accès aux lignes (non prises en charge)¶

Les balises, les politiques de masquage et les politiques d’accès aux lignes ne peuvent pas être ajoutées aux définitions des colonnes des tables DCM Projects.

Vous pouvez joindre manuellement des politiques de masquage et d’accès aux lignes en dehors du DCM Projects. Les définitions DCM Projects des objets de tables ignorent toutes les politiques de masquage ou d’accès aux lignes jointes. Elles ne sont pas révoquées par le redéploiement des définitions de table, même si ces définitions ne contiennent pas les politiques.