Snowflake Data Clean Rooms : détails d’installation¶

ADMIN¶

Ce schéma contient toutes les tables ou vues nécessaires à l’administration de l’application. Vous pouvez l’utiliser pour suivre les versions des applications, les correctifs et les déploiements. Les principaux détails incluent :

• Informations sur la version (numéro)

• Correctifs appliqués (version, commandes)

APP SCHEMA¶

Ce schéma contient des fonctions et des procédures nécessaires pour faciliter tous les flux de salle blanche. Les principaux détails incluent :

• Fonctions de cryptage et de décryptage.

• Procédures de salle blanche que vous utilisez avec les APIs du développeur et une application Web pour créer, installer et travailler avec des salles blanches.

TEMPLATES¶

Ce schéma contient les modèles Jinja SQL standard qui peuvent être utilisés pour exécuter des analyses à l’aide des APIs du développeur ou de l’application Web.

Ces modèles prédéfinis offrent des requêtes SQL prêtes à l’emploi pour une collaboration sécurisée des données au sein de Snowflake Data Clean Rooms. Ils exploitent les modèles Jinja pour la personnalisation, vous permettant d’adapter les requêtes à des scénarios de partage de données spécifiques.

ADMIN¶

Ce schéma contient les informations nécessaires au fonctionnement de certaines fonctionnalités de salle blanche associées au compte, telles que :

• L’utilisation de l’exécution automatique inter-cloud pour collaborer entre régions ou plateformes cloud.

• Les mises à jour des métadonnées de la salle blanche nécessaires pour enregistrer les salles blanches auprès des APIs du développeur à l’application Web.

• La gestion des versions des procédures actuelles associées au fonctionnement de l’application Web avec le compte Snowflake.

• Les tâches et les flux qui écoutent les changements dans l’ensemble des partages de salles blanches qui sont renvoyés par les collaborateurs, et qui activent/désactivent les salles blanches si nécessaire en fonction des changements.

CONSUMER/CONSUMER_INIT¶

Ce schéma contient les procédures nécessaires pour faire fonctionner l’installation de la salle blanche ou les fonctionnalités grand public associées au compte, telles que :

• Les détails de la liste des salles blanches partagées nécessaires pour demander des salles blanches d’exécution automatique inter-cloud.

• Les fonctionnalités liées à l’utilisation des politiques de jointure/colonne et à l’enregistrement d’une base de données dans une salle blanche.

• La prise en charge de l’installation et de la modification d’une salle blanche, de l’exécution d’analyses et de la visualisation des modèles qui ont été ajoutés.

ID_HUB¶

Ce schéma contient des procédures et des tables intermédiaires associées au hub d’identité.

INFORMATION_SCHEMA¶

Comme toutes les bases de données Snowflake, cette base de données contient le schéma INFORMATION_SCHEMA (« Dictionnaire de données »), qui consiste en un ensemble de vues définies par le système et de fonctions de table qui fournissent de nombreuses informations de métadonnées sur les objets créés dans votre compte.

LIBRARY¶

Ce schéma contient les procédures nécessaires pour activer les connecteurs et les fonctionnalités de salle blanche qui sont applicables à la fois au fournisseur et aux consommateurs, telles que :

• La mise en place de procédures de connecteurs d’annonces facilitant l’intégration avec des hubs d’ID et des tables externes.

• L’enregistrement des procédures de base de données pour contrôler l’activation ou la désactivation de l’exécution automatique inter-cloud.

• L’application de correctifs, l’annulation d’enregstrement de bases de données et la mise à jour des enregistrements de salle blanche.

PROVIDER¶

Ce schéma contient des données ou des informations relatives aux activations (flux et procédures pour faciliter les activations des fournisseurs), des rapports d’analyse enregistrés, des méta-informations relatives aux connecteurs configurés sur les comptes Snowflake Data Clean Rooms et enregistrements de salle blanche créés par le compte.

PUBLIC¶

Ce schéma contient les APIs du développeur que vous et l’application Web utilisez pour créer et gérer des salles blanches. Il contient également des ensembles de données intermédiaires entièrement détenus par vous qui sont enregistrés dans le schéma PUBLIC lors de flux tels que la résolution d’identité. Par exemple, les tables de sortie de la résolution de LiveRamp et le processus de transcodage sont enregistrés dans le schéma PUBLIC et joints à la vue qui est liée à la salle blanche par l’application Web.

Ce schéma contient les tables suivantes :

• CLEANROOM_RECORD : ce tableau inclut le statut d’une salle blanche (créée, supprimée) ainsi que l’utilisateur et l’horodatage de la dernière mise à jour. Si la mise à jour a été effectuée dans l’application Web, l’utilisateur est l’utilisateur du compte de service. Si la mise à jour a été effectuée dans Snowsight en utilisant les APIs du développeur, l’utilisateur est l’utilisateur réel qui a appelé l’API. Le nom de la base de données de la salle blanche peut être personnalisé dans cette table.

• CONNECTOR_CONFIGURATION : ce tableau est la liste des connecteurs configurés dans le compte.

• REPORTS : ce tableau inclut la liste des rapports enregistrés par le consommateur dans l’application Web. Les résultats de niveau supérieur des rapports standard sont enregistrés dans le tableau.

• HORIZONTAL_ANALYSIS_<report ID> : résultat des analyses exécutées avec le modèle de requête SQL et les modèles personnalisés exécutés dans l’application Web.

La base de données possède trois partages qui sont créés à partir de celle-ci :

• SAMOOHA_INTERNAL_GOVERNANCE_SUMMARY SHARE_NAV2 : ce partage contient des vues sur le GOVERNACE_SUMMARY et les tables ACTIVATION dans le schéma PUBLIC. Il est partagé avec tous les fournisseurs qui ont créé des salles blanches installées par ce compte, et est utilisé pour partager les informations de gouvernance et les activations des fournisseurs.

• SAMOOHA_INTERNAL_LOGS_SHARE_NAV2 : ce partage est présenté sur la table LOG_EVENTS et est principalement utilisée pour partager des journaux sur la façon dont les procédures de résolution des ID progressent vers Snowflake, étant donné qu’elles utilisent des applications natives tierces. Aucune PII ou donnée n’est jamais communiquée en retour, seulement le succès ou l’échec des APIs des applications tierces utilisées pour le transcodage/la résolution.

• SAMOOHA_INTERNAL_PROVIDER_METADATA_NAV2 : ce partage est présentée sur deux tables, ADMIN.METADATA_UPDATE_REQUESTS, qui est utilisée pour les APIs du développeur et les demandes d’enregistrement d’applications Web et ADMIN.RESOURCE_MONITOR_USAGE, qui n’est utilisée que par les comptes gérés pour enregistrer l’utilisation.