CREATE MATERIALIZED VIEW¶

Syntaxe¶

CREATE [ OR REPLACE ] [ SECURE ] MATERIALIZED VIEW [ IF NOT EXISTS ] <name>
  [ COPY GRANTS ]
  ( <column_list> )
  [ <col1> [ WITH ] MASKING POLICY <policy_name> [ USING ( <col1> , <cond_col1> , ... ) ]
           [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' , ... ] ) ]
  [ , <col2> [ ... ] ]
  [ COMMENT = '<string_literal>' ]
  [ [ WITH ] ROW ACCESS POLICY <policy_name> ON ( <col_name> [ , <col_name> ... ] ) ]
  [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' , ... ] ) ]
  [ CLUSTER BY ( <expr1> [, <expr2> ... ] ) ]
  AS <select_statement>

Paramètres requis¶

name

Spécifie l’identificateur de la vue ; il doit être unique pour le schéma dans lequel la vue est créée.

De plus, l’identificateur doit commencer par un caractère alphabétique et ne peut pas contenir d’espaces ou de caractères spéciaux à moins que toute la chaîne d’identificateur soit délimitée par des guillemets doubles (p. ex. "My object"). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

Pour plus de détails, voir Exigences relatives à l’identificateur.

select_statement

Spécifie la requête utilisée pour créer la vue. Cette requête sert de texte/définition pour la vue. Cette requête est affichée dans les résultats de SHOW VIEWS et SHOW MATERIALIZED VIEWS.

Il existe des limites liées à select_statement. Pour plus de détails, voir :

• Notes sur l’utilisation.

• Limitations relatives à la création de vues matérialisées.

Paramètres facultatifs¶

column_list :

Si vous ne souhaitez pas que les noms de colonne de la vue soient identiques à ceux de la table sous-jacente, vous pouvez inclure une liste de colonnes dans laquelle vous spécifiez les noms de colonne. (Vous n’avez pas besoin de spécifier les types de données des colonnes.)

Si vous incluez une clause CLUSTER BY pour la vue matérialisée, vous devez inclure la liste des noms de colonnes.

MASKING POLICY = policy_name

Spécifie la politique de masquage à définir sur une colonne.

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.

string_literal

Spécifie un commentaire pour la vue. Le littéral de chaîne doit être entre guillemets simples. (Le littéral de chaîne ne doit pas contenir de guillemets simples, sauf s’ils sont échappés.)

Par défaut : aucune valeur.

expr#

Spécifie une expression sur laquelle baser l’opération de clustering de la vue matérialisée. En règle générale, l’expression est le nom d’une colonne dans la vue matérialisée.

Pour plus d’informations sur le clustering des vues matérialisées, voir Vues matérialisées et clustering. Pour plus d’informations sur le clustering en général, voir : Qu’est-ce que le clustering de données ?.

SECURE

Indique que la vue est sécurisée. Pour plus d’informations sur les vues sécurisées, voir Utilisation de vues sécurisées.

Par défaut : aucune valeur (la vue n’est pas sécurisée)

COPY GRANTS

Si vous remplacez une vue existante à l’aide de la clause OR REPLACE, la vue de remplacement conserve les autorisations d’accès de la vue d’origine. Ce paramètre copie tous les privilèges, sauf OWNERSHIP, de la vue existante vers la nouvelle vue. La nouvelle vue n’autorise pas les attributions futures définies pour le type d’objet dans le schéma. Par défaut, le rôle qui exécute l’instruction CREATE MATERIALIZED VIEW possède la nouvelle table.

Si le paramètre n’est pas inclus dans l’instruction CREATE VIEW, la nouvelle vue n’hérite pas des privilèges d’accès explicites accordés sur la vue d’origine, mais des attributions futures définies pour le type d’objet dans le schéma.

Notez que l’opération de copie des attributions s’effectue de manière atomique avec l’instruction CREATE VIEW (c’est-à-dire dans la même transaction).

Par défaut : aucune valeur (les attributions ne sont pas copiées)

ROW ACCESS POLICY policy_name ON ( col_name [ , col_name ... ] )

Spécifie la politique d’accès aux lignes à définir sur la vue matérialisée.

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 de détails sur la spécification des balises dans une instruction, voir Quotas de balises pour les objets et les colonnes.

Notes sur l’utilisation¶

• La création d’une vue matérialisée nécessite un privilège CREATE MATERIALIZED VIEW sur le schéma et un privilège SELECT sur la table de base. Pour plus d’informations sur les privilèges et les vues matérialisées, voir Privilèges sur le schéma d’une vue matérialisée.

• Lorsque vous choisissez un nom pour la vue matérialisée, notez qu’un schéma ne peut pas contenir une table et une vue portant le même nom. Une instruction CREATE [ MATERIALIZED ] VIEW produit une erreur si une table portant le même nom existe déjà dans le schéma.

• Lorsque vous spécifiez select_statement, notez ce qui suit :

  • Vous ne pouvez pas spécifier une clause HAVING ou une clause ORDER BY.

  • Si vous incluez une clause CLUSTER BY pour la vue matérialisée, vous devez inclure la clause column_list.

  • Si vous faites référence à la table de base plus d’une fois dans select_statement, utilisez le même qualificatif pour toutes les références à la table de base.

    Par exemple, n’utilisez pas un mélange de base_table, schema.base_table et database.schema.base_table dans la même select_statement. Choisissez plutôt l’une de ces formes (par exemple database.schema.base_table), et utilisez-la de manière cohérente dans l’ensemble de select_statement.

  • Ne pas interroger les objets de flux dans l’instruction SELECT. Les flux ne sont pas conçus pour servir d’objets sources pour les vues ou les vues matérialisées.

• Certains noms de colonnes ne sont pas autorisés dans les vues matérialisées. Si un nom de colonne n’est pas autorisé, vous pouvez définir un alias pour la colonne. Pour plus de détails, voir Gestion des noms de colonnes non autorisés dans les vues matérialisées.

• Si la vue matérialisée interroge des tables externes, vous devez actualiser les métadonnées de niveau fichier pour les tables externes afin de refléter les modifications apportées à l’emplacement de stockage dans le Cloud référencé, y compris les fichiers nouveaux, mis à jour et supprimés.

  Vous pouvez actualiser les métadonnées d’une table externe automatiquement à l’aide du service de notification d’événements de votre service de stockage dans le Cloud en utilisant des instructions ALTER EXTERNAL TABLE … REFRESH.

• Les vues matérialisées comportent un certain nombre d’autres restrictions. Pour plus de détails, voir Limitations relatives à la création de vues matérialisées et Travailler avec des vues matérialisées : limites.

• Les définitions de vue ne sont pas mises à jour si le schéma de la table source sous-jacente est modifié de sorte que la définition de vue ne soit plus valide. Par exemple :

  • Une vue est créée à partir d’une table de base et une colonne est ensuite supprimée de cette table de base.

  • La table de base de la vue matérialisée est supprimée.

  Dans ces cas, la requête de la vue renvoie une erreur qui inclut la raison pour laquelle la vue a été invalidée. Par exemple :

  Failure during expansion of view 'MV1':
    SQL compilation error: Materialized View MV1 is invalid.
    Invalidation reason: DDL Statement was executed on the base table 'MY_INVENTORY'.
    Marked Materialized View as invalid.
  

  Dans ce cas, vous pouvez procéder comme suit :

  • Si la table de base a été supprimée et que vous vous trouvez dans la période de conservation des données pour Time Travel, vous pouvez annuler la suppression de la table de base pour que la vue matérialisée soit à nouveau valide.

  • Utilisez la commande CREATE OR REPLACE MATERIALIZED VIEW pour créer la vue.

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

• Utiliser OR REPLACE équivaut à utiliser DROP MATERIALIZED VIEW sur la vue matérialisée existante, puis à créer une nouvelle vue avec le même nom.

  Les instructions CREATE OR REPLACE <objet> sont atomiques. En d’autres termes, lorsqu’un objet est remplacé, l’ancien objet est supprimé et le nouvel objet est créé dans une seule transaction.

  Cela signifie que toutes les requêtes simultanées à l’opération CREATE OR REPLACE MATERIALIZED VIEW utilisent soit l’ancienne soit la nouvelle version de la vue matérialisée.

• Lors de la création d’une vue matérialisée avec une politique de masquage sur une ou plusieurs colonnes de la vue matérialisée ou une politique d’accès aux lignes ajoutée à la vue matérialisée, 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 vue matérialisée protégée par une politique d’accès aux lignes.

Exemples¶

Créer une vue matérialisée dans le schéma actif, avec un commentaire, qui sélectionne toutes les lignes d’une table :

CREATE MATERIALIZED VIEW mymv
    COMMENT='Test view'
    AS
    SELECT col1, col2 FROM mytable;

Copy

Pour plus d’exemples, voir les exemples dans Travailler avec des vues matérialisées.