ALTER VIEW¶
Modifie les propriétés d’une vue existante. Actuellement, les seules opérations prises en charge sont les suivantes :
Renommage d’une vue.
Conversion (entrante ou sortante) d’une vue sécurisée.
Ajout, écrasement ou suppression d’un commentaire pour une vue.
Notez que vous ne pouvez pas utiliser cette commande pour changer la définition d’une vue. Pour modifier la définition de la vue, vous devez détruire la vue, puis la recréer.
- Voir aussi :
Syntaxe¶
ALTER VIEW [ IF EXISTS ] <name> RENAME TO <new_name>
ALTER VIEW [ IF EXISTS ] <name> SET COMMENT = '<string_literal>'
ALTER VIEW [ IF EXISTS ] <name> UNSET COMMENT
ALTER VIEW [ IF EXISTS ] <name> SET SECURE
ALTER VIEW [ IF EXISTS ] <name> SET CHANGE_TRACKING = { TRUE | FALSE }
ALTER VIEW <name> UNSET SECURE
ALTER VIEW <name> dataMetricFunctionAction
ALTER VIEW [ IF EXISTS ] <name> dataGovnPolicyTagAction
Où :
dataMetricFunctionAction ::= SET DATA_METRIC_SCHEDULE = { '<num> MINUTE' | 'USING CRON <expr> <time_zone>' | 'TRIGGER_ON_CHANGES' } | UNSET DATA_METRIC_SCHEDULE | { ADD | DROP } DATA METRIC FUNCTION <metric_name> ON ( <col_name> [ , ... ] ) [ , <metric_name_2> ON ( <col_name> [ , ... ] ) ] | MODIFY DATA METRIC FUNCTION <metric_name> ON ( <col_name> [ , ... ] ) { SUSPEND | RESUME } [ , <metric_name_2> ON ( <col_name> [ , ... ] ) { SUSPEND | RESUME } ]dataGovnPolicyTagAction ::= { SET TAG <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' ... ] | UNSET TAG <tag_name> [ , <tag_name> ... ] } | { ADD ROW ACCESS POLICY <policy_name> ON ( <col_name> [ , ... ] ) | DROP ROW ACCESS POLICY <policy_name> | DROP ROW ACCESS POLICY <policy_name> , ADD ROW ACCESS POLICY <policy_name> ON ( <col_name> [ , ... ] ) | DROP ALL ROW ACCESS POLICIES } | { SET AGGREGATION POLICY <policy_name> [ ENTITY KEY ( <col_name> [, ... ] ) ] [ FORCE ] | UNSET AGGREGATION POLICY } | ADD [ COLUMN ] [ IF NOT EXISTS ] <col_name> <col_type> [ [ WITH ] MASKING POLICY <policy_name> [ USING ( <col1_name> , <cond_col_1> , ... ) ] ] [ [ WITH ] PROJECTION POLICY <policy_name> ] [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' , ... ] ) ] | { { ALTER | MODIFY } [ COLUMN ] <col1_name> SET MASKING POLICY <policy_name> [ USING ( <col1_name> , <cond_col_1> , ... ) ] [ FORCE ] | UNSET MASKING POLICY } | { { ALTER | MODIFY } [ COLUMN ] <col1_name> SET PROJECTION POLICY <policy_name> [ FORCE ] | UNSET PROJECTION POLICY } | { ALTER | MODIFY } [ COLUMN ] <col1_name> SET TAG <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' ... ] , [ COLUMN ] <col2_name> SET TAG <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' ... ] | { ALTER | MODIFY } [ COLUMN ] <col1_name> UNSET TAG <tag_name> [ , <tag_name> ... ] , [ COLUMN ] <col2_name> UNSET TAG <tag_name> [ , <tag_name> ... ]
Paramètres¶
name
Indique l’identifiant de la vue à modifier. Si l’identificateur contient des espaces ou des caractères spéciaux, toute la chaîne doit être délimitée par des guillemets doubles. Les identificateurs entre guillemets doubles sont également sensibles à la casse.
RENAME TO new_name
Indique le nouvel identifiant de la vue ; doit être unique pour le schéma.
Pour plus de détails, voir Exigences relatives à l’identificateur.
Vous pouvez déplacer l’objet vers une autre base de données et/ou un autre schéma tout en renommant éventuellement l’objet. Pour ce faire, spécifiez une valeur
new_name
qualifiée qui inclut le nouveau nom de la base de données et/ou du schéma sous la formedb_name.schema_name.object_name
ouschema_name.object_name
, respectivement.Note
La base de données et/ou le schéma de destination doivent déjà exister. En outre, un objet portant le même nom ne peut pas déjà exister dans le nouvel emplacement ; sinon, l’instruction renvoie une erreur.
Le déplacement d’un objet vers un schéma d’accès géré est interdit sauf si le propriétaire de l’objet (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur l’objet) est également propriétaire du schéma cible.
Lorsqu’un objet est renommé, les autres objets qui le référencent doivent être mis à jour avec le nouveau nom.
SET ...
Spécifie la propriété à définir pour la vue :
SECURE
Spécifie une vue comme sécurisée.
CHANGE_TRACKING = TRUE | FALSE
Spécifie d’activer ou de désactiver le suivi des modifications sur la table.
TRUE
active le suivi des modifications sur la vue et répercute le paramètre sur toutes les tables sous-jacentes.FALSE
désactive le suivi des modifications sur la vue et répercute le paramètre sur toutes les tables sous-jacentes.
COMMENT = 'string_literal'
Ajoute un commentaire ou écrase un commentaire existant pour la vue.
Note
Vous devez définir chaque propriété de vue individuellement.
UNSET ...
Spécifie la propriété à désactiver pour la vue, qui est rétablie à la valeur par défaut :
SECURE
COMMENT
Lors de la réinitialisation d’une propriété, spécifiez seulement le nom ; si vous spécifiez une valeur pour la propriété, vous obtiendrez une erreur.
Note
Vous devez réinitialiser chaque propriété de vue individuellement.
Actions de la fonction de métrique des données (dataMetricFunctionAction
)¶
DATA_METRIC_SCHEDULE ...
Spécifie la planification de l’exécution périodique de la fonction de métrique des données.
'num MINUTE'
Spécifie un intervalle (en minutes) de temps d’attente inséré entre les exécutions de la fonction de métrique des données. Accepte uniquement les entiers positifs.
Prend également en charge la syntaxe
num M
.Pour les fonctions de métrique des données, utilisez l’une des valeurs suivantes :
5
,15
,30
,60
,720
ou1440
.'USING CRON expr time_zone'
Spécifie une expression cron et un fuseau horaire pour l’exécution périodique de la fonction de métrique des données. Prend en charge un sous-ensemble de la syntaxe standard de l’utilitaire cron.
Pour une liste de fuseaux horaires, voir la Liste des fuseaux horaires de la base de données tz.
L’expression cron se compose des champs suivants et l’intervalle périodique doit être d’au moins 5 minutes :
# __________ minute (0-59) # | ________ hour (0-23) # | | ______ day of month (1-31, or L) # | | | ____ month (1-12, JAN-DEC) # | | | | _ day of week (0-6, SUN-SAT, or L) # | | | | | # | | | | | * * * * *
Les caractères spéciaux suivants sont acceptés :
*
Caractère générique. Spécifie toute occurrence du champ.
L
Signifie « dernier ». Lorsqu’il est utilisé dans le champ du jour de la semaine, il vous permet de spécifier des constructions telles que « le dernier vendredi » (« 5L ») d’un mois donné. Dans le champ du mois, il spécifie le dernier jour du mois.
/{n}
Indique l’instance n d’une unité de temps donnée. Chaque quanta de temps est calculé indépendamment. Par exemple, si
4/3
est spécifié dans le champ du mois, la fonction de métrique des données est planifiée pour avril, juillet et octobre (c’est-à-dire tous les 3 mois, à partir du 4e mois de l’année). Le même calendrier est maintenu les années suivantes. En d’autres termes, la fonction de métrique des données n’est pas planifiée pour être exécutée en janvier (3 mois après l’exécution d’octobre).
Note
L’expression cron est actuellement évaluée par rapport au fuseau horaire spécifié. La modification de la valeur du paramètre TIMEZONE pour le compte (ou la définition de la valeur au niveau de l’utilisateur ou de la session) ne modifie pas le fuseau horaire de la fonction de métrique des données.
L’expression cron définit tous les moments d’exécution valides de la fonction de métrique des données. Snowflake tente d’exécuter une fonction de métrique des données en fonction de cette planification ; toutefois, tout moment d’exécution valide est ignoré si une exécution précédente n’a pas été terminée avant le début du moment d’exécution valide suivant.
Lorsqu’un jour de mois et un jour de semaine spécifiques sont inclus dans l’expression cron, la fonction de métrique des données est planifiée les jours correspondant au jour du mois ou au jour de la semaine. Par exemple,
DATA_METRIC_SCHEDULE = 'USING CRON 0 0 10-20 * TUE,THU UTC'
planifie une fonction de métrique des données à 0AM entre le 10e et le 20e jour du mois ainsi que le mardi ou le jeudi en dehors de ces dates.La granularité de temps la plus courte en cron est la minute.
Si une fonction de métrique des données est reprise pendant la minute définie dans son expression cron, la première exécution planifiée de la fonction de métrique des données est la prochaine occurrence de l’instance de l’expression cron. Par exemple, si une fonction de métrique des données planifiée pour s’exécuter quotidiennement à minuit (
USING CRON 0 0 * * *
) est reprise à minuit + 5 secondes (00:00:05
), la première exécution de la fonction de métrique des données est planifiée pour la prochaine fois qu’il sera minuit.
'TRIGGER_ON_CHANGES'
Spécifie que la DMF s’exécute lorsqu’une opération DML modifie la table, comme l’insertion d’une nouvelle ligne ou la suppression d’une ligne.
Vous pouvez spécifier
'TRIGGER_ON_CHANGES'
pour les objets suivants :Tables dynamiques
Tables externes
Tables Apache Iceberg™
Tables ordinaires
Tables temporaires
Tables transitoires
Les modifications apportées à la table à la suite du reclustering ne déclenchent pas l’exécution de la DMF.
{ ADD | DROP } DATA METRIC FUNCTION metric_name
Identificateur de la fonction de métrique des données à ajouter à la table ou à la vue ou à supprimer dans la table ou la vue.
ON ( col_name [ , ... ] )
Colonnes de table ou de vue auxquelles associer la fonction de métrique des données. Les types de données des colonnes doivent correspondre aux types de données des colonnes spécifiées dans la définition de la fonction de métrique des données.
[ , metric_name_2 ON ( col_name [ , ... ] ) [ , ... ] ]
Fonctions de métrique des données supplémentaires à ajouter à la table ou à la vue. Utilisez une virgule pour séparer chaque fonction de métrique des données et ses colonnes spécifiées.
MODIFY DATA METRIC FUNCTION metric_name
Identificateur de la fonction de métrique des données à modifier.
ON ( col_name [ , ... ] ) { SUSPEND | RESUME }
Suspend ou reprend la fonction de métrique des données sur les colonnes spécifiées. Lorsqu’une fonction de métrique des données est définie pour une table ou une vue, la fonction de métrique des données est automatiquement incluse dans la planification.
SUSPEND
supprime la fonction de métrique des données du calendrier.RESUME
ramène une fonction de métrique des données suspendue dans le calendrier.
[ , metric_name_2 ON ( col_name [ , ... ] ) [ , ... ] { SUSPEND | RESUME } ]
Fonctions de métrique des données supplémentaires à suspendre ou à reprendre. Utilisez une virgule pour séparer chaque fonction de métrique des données et ses colonnes spécifiées.
Pour des détails sur les conditions de contrôle d’accès pour ces actions, voir Privilèges des DMF.
Politique de gouvernance des données et actions de balises (dataGovnPolicyTagAction
)¶
TAG tag_name = 'tag_value' [ , tag_name = 'tag_value' , ... ]
Spécifie le nom de la balise et la valeur de la chaîne de la balise.
La valeur de la balise est toujours une chaîne de caractères et le nombre maximum de caractères pour la valeur de la balise est 256.
Pour plus d’informations sur la spécification des balises dans une instruction, voir Quotas de balises pour les objets et les colonnes.
policy_name
Identificateur de la politique ; doit être unique pour votre schéma.
Les clauses suivantes s’appliquent à tous les types de tables qui prennent en charge les politiques d’accès aux lignes, notamment les tables, les vues et les tables d’événements. Pour simplifier, les clauses font simplement référence à la « table ».
ADD ROW ACCESS POLICY policy_name ON (col_name [ , ... ])
Ajoutez la politique d’accès aux lignes à la table.
Au moins un nom de colonne doit être spécifié. Des colonnes supplémentaires peuvent être spécifiées en séparant chaque nom de colonne par une virgule. Utilisez cette expression pour ajouter une politique d’accès aux lignes à la fois à une table d’événements et à une table externe.
DROP ROW ACCESS POLICY policy_name
Supprime une politique d’accès aux lignes de la table.
Utilisez cette clause pour supprimer la politique de la table.
DROP ROW ACCESS POLICY policy_name, ADD ROW ACCESS POLICY policy_name ON ( col_name [ , ... ] )
Supprime la politique d’accès aux lignes définie sur la table et ajoute une politique d’accès aux lignes pour la même table en une seule instruction SQL.
DROP ALL ROW ACCESS POLICIES
Supprime toutes les associations de politique d’accès aux lignes d’une table.
Cette expression est utile lorsqu’une politique d’accès aux lignes est détruite d’un schéma avant de détruire la politique d’une table d’événements. Utilisez cette expression pour supprimer les associations de politiques d’accès aux ligne de la table.
SET AGGREGATION POLICY policy_name
[ ENTITY KEY (col_name [ , ... ]) ] [ FORCE ]
Attribue une politique d’agrégation à la table.
Utilisez le paramètre ENTITY KEY facultatif pour définir les colonnes qui identifient de manière unique une entité dans la table. Pour plus d’informations, voir Mise en œuvre de la protection de la confidentialité au niveau de l’entité à l’aide de politiques d’agrégation.
Utilisez le paramètre facultatif FORCE pour remplacer atomiquement une politique d’agrégation existante par la nouvelle politique d’agrégation.
UNSET AGGREGATION POLICY
Détache une politique d’agrégation de la table.
{ ALTER | MODIFY } [ COLUMN ] ...
USING ( col_name , cond_col_1 ... )
Spécifie les arguments à passer dans l’expression SQL de la politique de masquage conditionnelle.
La première colonne de la liste spécifie la colonne pour les conditions de la politique de masquage ou de tokenisation des données et doit correspondre à la colonne à laquelle la politique de masquage est définie.
Les colonnes supplémentaires spécifient les colonnes à évaluer pour déterminer s’il faut masquer ou tokeniser les données de chaque ligne du résultat de la requête lorsqu’une requête est effectuée sur la première colonne.
Si la clause USING est omise, Snowflake traite la politique de masquage conditionnelle comme une politique de masquage normale.
FORCE
Remplace une politique de masquage ou de projection actuellement définie sur une colonne par une politique différente dans une seule instruction.
Notez que l’utilisation du mot-clé
FORCE
avec une politique de masquage exige que le type de données de la politique dans l’instruction ALTER TABLE (c’est-à-dire STRING) corresponde au type de données de la politique de masquage actuellement définie sur la colonne (c’est-à-dire STRING).Si aucune politique de masquage n’est actuellement définie sur la colonne, la spécification de ce mot-clé n’a aucun effet.
Pour plus de détails, voir : Remplacez une politique de masquage sur une colonne ou Remplacement d’une politique de projection.
Notes sur l’utilisation : Généralités¶
Le déplacement d’une vue vers un schéma d’accès géré (utilisant la syntaxe ALTER VIEW … RENAME TO) est interdit sauf si le propriétaire de la vue (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur la vue) est également propriétaire du schéma cible.
Pour les politiques de masquage :
La clause
USING
et le mot-cléFORCE
sont tous deux facultatifs ; ils ne sont pas nécessaires pour définir une politique de masquage sur une colonne. La clauseUSING
et le mot-cléFORCE
peuvent être utilisés séparément ou ensemble. Pour plus de détails, voir :Une seule politique de masquage qui utilise des colonnes conditionnelles peut être appliquée à plusieurs tables, à condition que la structure des colonnes de la table corresponde aux colonnes spécifiées dans la politique.
Lorsque vous modifiez une ou plusieurs colonnes de la table avec une politique de masquage ou la table elle-même avec une politique d’accès aux lignes, utilisez la fonction POLICY_CONTEXT pour simuler une requête sur la ou les colonnes protégées par une politique de masquage et la table protégée par une politique d’accès aux lignes.
Une seule politique de masquage qui utilise des colonnes conditionnelles peut être appliquée à plusieurs vues, à condition que la structure des colonnes de la vue corresponde aux colonnes spécifiées dans la politique.
Pour les politiques d’accès aux lignes :
Snowflake prend en charge l’ajout et la suppression des politiques d’accès aux lignes dans une seule instruction SQL.
Par exemple, pour remplacer une politique d’accès aux lignes déjà définie sur une table par une politique différente, il faut d’abord détruire la politique d’accès aux lignes, puis ajouter la nouvelle politique d’accès aux lignes.
Pour une ressource donnée (c’est-à-dire une table ou une vue), pour
ADD
ouDROP
une politique d’accès aux lignes, vous devez disposer du privilège APPLY ROW ACCESS POLICY sur le schéma, ou du privilège OWNERSHIP sur la ressource et du privilège APPLY sur la ressource de la politique d’accès aux lignes.Une table ou une vue ne peut être protégée que par une seule politique d’accès aux lignes à la fois. L’ajout d’une politique échoue si le corps de la politique fait référence à une colonne de table ou de vue qui est protégée par une politique d’accès aux lignes ou à la colonne protégée par une politique de masquage.
De même, l’ajout d’une politique de masquage à une colonne de table échoue si le corps de la politique de masquage fait référence à une table qui est protégée par une politique d’accès aux lignes ou une autre politique de masquage.
Les politiques d’accès aux lignes ne peuvent pas être appliquées aux vues système ou aux fonctions de table.
Comme pour les autres opérations DROP <objet>, Snowflake renvoie une erreur en cas de tentative de destruction d’une politique d’accès aux lignes d’une ressource à laquelle aucune politique d’accès aux lignes n’a été ajoutée.
Si un objet possède à la fois une politique d’accès aux lignes et une ou plusieurs politiques de masquage, la politique d’accès aux lignes est évaluée en premier.
Concernant les métadonnées :
Attention
Les clients doivent s’assurer qu’aucune donnée personnelle (autre que pour un objet utilisateur), donnée sensible, donnée à exportation contrôlée ou autre donnée réglementée n’est saisie comme métadonnée lors de l’utilisation du service Snowflake. Pour plus d’informations, voir Champs de métadonnées dans Snowflake.
Notes sur l’utilisation : Fonctions de métrique des données¶
- Ajoutez une DMF à une table :
Avant d’ajouter une fonction de métrique des données à une table, procédez comme suit :
Définissez la planification d’exécution de la fonction de métrique des données. Pour plus de détails, voir DATA_METRIC_SCHEDULE.
Configurez la table d’événements dans laquelle stocker les résultats de l’appel auprès de la fonction de métrique des données. Pour plus de détails, voir Afficher les résultats de la DMF.
Assurez-vous que la table ou la vue n’est pas accordée à un partage, car vous ne pouvez pas définir de fonction de métrique des données sur une table ou une vue partagée.
En outre :
Vous pouvez ajouter une fonction de métrique des données à une table, une table externe, une vue ou une vue matérialisée. Vous ne pouvez définir de fonction de métrique des données sur aucun autre type de table tel qu’une table dynamique.
Lorsque vous spécifiez une colonne, Snowflake utilise la position ordinale. Si vous renommez une colonne après avoir ajouté une fonction de métrique des données à la table ou à la vue, l’association de la fonction de métrique des données à la colonne reste valide.
Une seule fonction de métrique des données de ce type peut être ajoutée à une colonne. Par exemple, une fonction de métrique des données NULL_COUNT ne peut pas être ajoutée à deux reprises à une même colonne.
Si vous supprimez une colonne après avoir ajouté une fonction de métrique des données qui fait référence à la colonne, Snowflake ne peut pas évaluer la fonction de métrique des données.
La référence à une colonne virtuelle n’est pas prise en charge.
- Supprimez une DMF dans une table :
Abandonnez la fonction de métrique des données de la table avant d’utiliser la commande DROP FUNCTION pour supprimer la fonction de métrique des données du système.
Vous pouvez utiliser la fonction DATA_METRIC_FUNCTION_REFERENCES pour identifier les objets de table et de vue pour lesquels une fonction de métrique des données est définie.
- Planification d’une DMF
Il faut dix minutes pour que la planification prenne effet une fois qu’elle a été définie.
De même, une fois que la DMF est désactivé, il faut dix minutes pour que les modifications apportées à la planification prennent effet. Pour plus d’informations, voir Planifiez l’exécution de vos DMFs.
Exemples¶
Renommer la vue view1
en view2
:
ALTER VIEW view1 RENAME TO view2;
Convertir une vue en vue sécurisée :
ALTER VIEW view1 SET SECURE;
Rétablir une vue sécurisée en vue normale :
ALTER VIEW view1 UNSET SECURE;
Appliquez une politique de masquage de sécurité au niveau des colonnes à une colonne de vue :
-- single column ALTER VIEW user_info_v MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask_v; -- multiple columns ALTER VIEW user_info_v MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask_v , COLUMN dob SET MASKING POLICY dob_mask_v ;
Annulez une politique de masquage de sécurité au niveau des colonnes depuis une colonne de vue :
-- single column ALTER VIEW user_info_v modify column ssn_number unset masking policy; -- multiple columns ALTER VIEW user_info_v modify column ssn_number unset masking policy , column dob unset masking policy ;
L’exemple suivant ajoute une politique d’accès aux lignes sur une vue. Après avoir défini les politiques, vous pouvez vérifier en contrôlant Information Schema.
alter view v1 add row access policy rap_v1 on (empl_id);
L’exemple suivant détruit une politique d’accès aux lignes d’une vue. Vérifiez que les politiques ont été détruites en interrogeant Information Schema.
alter view v1 drop row access policy rap_v1;
L’exemple suivant montre comment combiner l’ajout et la destruction de politiques d’accès aux lignes dans une seule instruction SQL pour une vue. Vérifiez les résultats en contrôlant Information Schema.
alter view v1 drop row access policy rap_v1_version_1, add row access policy rap_v1_version_2 on (empl_id);