Snowflake Data Clean Rooms: Installed objects¶

SAMOOHA_BY_SNOWFLAKE¶

This database contains all of the core functionality and application logic used to create and manage clean rooms. This database has the following schemas:

ADMIN schema

This schema contains app-level details such as the following:

• Patches applied (version, commands).

• Version information (number).

APP_SCHEMA schema

This schema contains functions and procedures that are necessary to facilitate all the clean room flows. Key details include:

• Encrypt and decrypt functions.

• Clean room procedures that you use with the developer APIs and clean rooms UI to create, install, and work with clean rooms.

TEMPLATES schema

This schema contains the Snowflake-provided SQL Jinja templates.

These pre-built templates offer ready-to-use SQL queries for secure data collaboration within Snowflake Data Clean Rooms. They leverage Jinja templating for customization, allowing you to tailor queries to specific data sharing scenarios.

SAMOOHA_BY_SNOWFLAKE_LOCAL_DB¶

This database is created by the clean rooms UI during the Snowflake installation process. It is local to your account. It is not an application, but does contain application logic.

This database has two types of data:

• The developer APIs that you and the clean rooms UI use to create and manage clean rooms.

• Intermediate datasets owned by you that get saved to the PUBLIC schema during flows such as identity resolution. For example, the output tables from LiveRamp’s resolution and transcoding process are saved to the PUBLIC schema and joined to the view that gets linked to the clean room by the clean rooms UI.

The database has the following schemas:

ADMIN schema

This schema contains information necessary to operate certain clean room features associated with the account, such as:

• Using Cross-Cloud Auto-Fulfillment to collaborate across regions or cloud platforms.

• Clean room metadata updates needed to register clean rooms from developer APIs to the clean rooms UI.

• Versioning of the current procedures associated with the functioning of the clean rooms UI with the Snowflake account.

• Tasks and streams that listen to changes in the set of clean room shares that are shared back from collaborators, and to enable/disable clean rooms as needed based on the changes.

CONSUMER/CONSUMER_INIT schema

This schema contains procedures necessary to operate clean room installation or consumer features associated with the account, such as:

• Shared clean room listing details needed for requesting Cross-Cloud Auto-Fulfillment clean rooms.

• Features related to using join/column policies and registering a database in a clean room.

• Support for installing and editing a clean room, running analyses, and viewing templates that have been added.

ID_HUB schema

This schema contains procedures and intermediate tables associated with the identity hub.

INFORMATION_SCHEMA schema

Like all Snowflake databases, this database contains the INFORMATION_SCHEMA schema (“Data dictionary”), which consists of a set of system-defined views and table functions that provide extensive metadata information about the objects created in your account.

LIBRARY schema

This schema contains procedures necessary to enable clean room connectors and features that apply to both provider and consumers, such as the following:

• Setting up Ads connector procedures that facilitate integration with ID hubs and external tables.

• Registering database procedures to control Cross-Cloud Auto-Fulfillment enablement or disablement.

• Applying patches, unregistering databases, and updating clean room records.

PROVIDER schema

This schema contains data or information related to activation (streams and procedures), saved analysis reports, meta information related to connectors configured on the Snowflake Data Clean Rooms accounts, and clean room records created by the account.

PUBLIC schema

This schema contains the developer APIs that you and the clean rooms UI use to create and manage clean rooms. It also contains intermediate datasets owned entirely by you that get saved to the PUBLIC schema during flows such as identity resolution. For example, the output tables from LiveRamp’s resolution and transcoding process are saved to the PUBLIC schema and joined to the view that gets linked to the clean room by the clean rooms UI.

This schema has the following tables:

• CLEANROOM_RECORD: This table includes the status of a clean room (created, deleted) along with the user and timestamp of the last update. If the update was done in the clean rooms UI, the user is the service account user. If the update was done in Snowsight using the developer APIs, the user is the actual user who called the API. The clean room database name can be customized in this table.

• CONNECTOR_CONFIGURATION: This table is the list of configured connectors in the account.

• REPORTS: This table includes the list of reports saved by the consumer in the clean rooms UI. Top-level results from standard reports are saved in the table.

• HORIZONTAL_ANALYSIS_<report ID>: Output of analyses executed with the SQL Query template and custom templates executed in the clean rooms UI.

This database has three shares that get created from it:

• SAMOOHA_INTERNAL_GOVERNANCE_SUMMARY SHARE_NAV2: This share contains views on the GOVERNACE_SUMMARY and ACTIVATION tables in the PUBLIC schema. This gets shared with any providers who have created clean rooms installed by this account, and is used to share governance information and provider activations back.

• SAMOOHA_INTERNAL_LOGS_SHARE_NAV2: This share is on the LOG_EVENTS table and is primarily used to share logs on how ID resolution procedures are progressing back to Snowflake, given they use third-party native apps. No PII or data is ever shared back, only the success/failure of the third-party app APIs used for transcoding/resolution.

• SAMOOHA_INTERNAL_PROVIDER_METADATA_NAV2: This share is on two tables, ADMIN.METADATA_UPDATE_REQUESTS, which is used to send registration requests from the API to the UI, and ADMIN.RESOURCE_MONITOR_USAGE, which is only used by managed accounts to log usage.

SAMOOHA_CLEANROOM_cleanroom ID¶

Each clean room has an associated database that includes all the details of that clean room, including any templates installed, request logs, LAF status, and much more.

SAMOOHA_CLEANROOM_REQUESTS_clean room ID¶

This is a database on the provider side and a share on the consumer side. It corresponds to the share that gets sent back from a consumer to the provider of a clean room as part of the consumer clean room installation process. This database contains information on all the requests raised by the consumer against the clean room and is used to keep track of the differential privacy budget usage by the consumer.

SAMOOHA_CLEANROOM_CONSUMER_clean room ID¶

This database is installed in consumer accounts only. It is used to share objects such as the secure view of the consumer data to the clean room, and consumer column/join policies if applied. It has the following table:

• SAMOOHA_CLEANROOM_CONSUMER_clean room ID.SHARED.REQUESTS. This table shows the consumer exactly which query was attempting to run, where PROPOSED_QUERY is the query rendered from the consumer’s template.

SAMOOHA_SAMPLE_DATABASE¶

This database contains sample datasets that you can use in your clean room.