Catégories :

Table, vue et séquence DDL

CREATE MATERIALIZED VIEW

Crée une nouvelle vue matérialisée dans le schéma actuel/spécifié, en fonction d’une requête d’une table existante, et remplit la vue avec des données.

Pour plus de détails, voir Travailler avec des vues matérialisées.

Voir aussi :

ALTER MATERIALIZED VIEW , DROP MATERIALIZED VIEW , SHOW MATERIALIZED VIEWS , DESCRIBE MATERIALIZED VIEW

Dans ce chapitre :

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> [ ... ] ]
  [ [ WITH ] ROW ACCESS POLICY <policy_name> ON ( <col_name> [ , <col_name> ... ] ) ]
  [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' , ... ] ) ]
  [ COMMENT = '<string_literal>' ]
  [ 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 :

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.

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.

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)

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.

  • 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 en faisant référence à une colonne spécifique dans une table source et la colonne est ensuite détruite de la table.

    • Une vue est créée à l’aide de SELECT * à partir d’une table et toute colonne est ensuite détruite de la table.

    Dans l’un ou l’autre de ces scénarios, l’interrogation de la vue renvoie une erreur.

  • Si une table source d’une vue matérialisée est détruite, l’interrogation de la vue renvoie l’erreur suivante : Materialized View <nom_vue> is invalid.

  • 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. Autrement dit, lorsque l’objet est remplacé, la suppression de l’ancien objet et la création du nouvel objet sont traitées en 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;

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

Revenir au début