Skip to content
Contact us Go to Customer Portal
  • There are no suggestions because the search field is empty.

RawVault Composite

Applies to
Platform: Microsoft SQL Server · Snowflake · Snowflake dbt · Databricks · Databricks dbt · Fabric Lakehouse · Fabric Warehouse · Oracle
Architecture: Data Vault

A RawVault Composite prepares source data with joins, filters and expressions in the Raw Vault layer, as a view or as a table reloaded per load. Use it when Hubs, Links or satellites need data that no single Stage delivers in the right shape, for example one Stage filtered or two Stages joined. The Raw Vault objects then read it like a Stage.

Earlier versions of this article spelled the type "Raw Vault Composite".

Sources and relationships

A RawVault Composite reads Stages, Store Entities of a linked Data Store project and other RawVault Composites. It has exactly one dataflow, with one or more dataflow sets, and no relationships. Its terms are the columns it delivers, at least one besides the Default Terms. Hubs, Links, all Raw Vault satellite types, Reference Tables, other RawVault Composites and the Business Driving Key Link can read it.

Create the model object

Add join, filter and term expressions in the dataflow set.

Implementation types

  • Virtual (default): the composite is a view over its sources. A query always shows the current content of the sources, and there is no loader.
  • Cached: the composite has a table. Its loader empties the table and inserts all rows of the source view, with the load timestamp as BG_LoadTimestamp. A query shows the content of the last load.

Properties

The project property Create Result Views also applies.

Default Terms

  • BG_LoadTimestamp: with Cached, the load that filled the table. With Virtual, empty unless you map it.
  • BG_SourceSystem: the source system, empty unless you map it.

Generated objects

These are the names on Microsoft SQL Server. <model object name> stands for the name of the model object:

RoleGenerated namePurpose
SourceRDV_RC_<model object name>_SourceJoins, filters and maps
DeduplicationRDV_RC_<model object name>_DeduplicationRemoves duplicate rows
LoaderRDV_RC_<model object name>_LoaderReloads the table
StorageRDV_RC_<model object name>Composite table
ResultRDV_RC_<model object name>_ResultQuery view
  • The loader is a stored procedure and the composite table is a table; the other objects are views.
  • The loader and the table exist only with Implementation Type Cached.
  • The deduplication view exists only with a Deduplication Method other than None.
  • The result view exists only with Create Result Views.
  • The table has no primary key and no unknown-member row.

The chain depends on the implementation type:

Virtual: sources -> _Source -> _Result
Cached:  sources -> _Source -> _Loader -> RDV_RC_<model object name>
         RDV_RC_<model object name> -> _Result

With Virtual, the result view reads the source view. With Cached, it reads the table. _Deduplication sits after _Source.

Example

Two RawVault Composites on Microsoft SQL Server read the Stage CUSTOMER and map CUSTOMER_ID and CUSTOMER: load_virtual_rvc with Implementation Type Virtual and load_cached_rvc with Cached. The Stage receives these customers:

  • Load 3 on 2026-10-30 08:00: customers 1 Contoso Group and 3 Northwind. The loader of load_cached_rvc runs.
  • Next, the Stage receives the data of load 4: customers 1, 2 Fabrikam AG and 3. The loader of load_cached_rvc has not run yet.

Check the result

Query both result views, here in the schema p2:

SELECT 'virtual' AS IMPL, CUSTOMER_ID, CUSTOMER, BG_LoadTimestamp
FROM p2.RDV_RC_load_virtual_rvc_Result
UNION ALL
SELECT 'cached', CUSTOMER_ID, CUSTOMER, BG_LoadTimestamp
FROM p2.RDV_RC_load_cached_rvc_Result
ORDER BY IMPL DESC, CUSTOMER_ID;

This is the result before the loader of load 4 runs, with the timestamps shortened:

IMPL     CUSTOMER_ID  CUSTOMER       BG_LoadTimestamp
virtual  1            Contoso Group  NULL
virtual  2            Fabrikam AG    NULL
virtual  3            Northwind      NULL
cached   1            Contoso Group  2026-10-30 08:00
cached   3            Northwind      2026-10-30 08:00
  • The virtual composite already shows customer 2 from the new Stage data. Its BG_LoadTimestamp is empty because the dataflow does not map it.
  • The cached composite shows the content of load 3. After its loader runs for load 4, it holds customers 1, 2 and 3.

Platform differences

  • Snowflake: names are in capitals, and the loader of a cached composite is a stored procedure. A load control task calls it. The dataflow properties Use Stream and Warehouse Placeholder Variable Name apply.
  • Databricks and Fabric Lakehouse: table and view names are in lowercase, and the loader of a cached composite is the notebook RDV_RC_<model object name>_Loader. The properties File Format, Optimization Method and Optimization Method Columns apply.
  • Databricks dbt and Snowflake dbt: the RawVault Composite becomes the dbt model rdv_rc_<model object name>_source, and with Cached also rdv_rc_<model object name>. The model rdv_rc_<model object name>_result exists only when Create Result Views is true; the default on dbt is false.
  • Fabric Warehouse: the same objects as on Microsoft SQL Server, deployed by notebooks.
  • Oracle: names are in capitals, and the loader of a cached composite is a PL/SQL package. Partition Clause adds its text to the CREATE TABLE statement. Table Compression, the tablespaces and the statistics properties also apply.

Limitations

  • A RawVault Composite has exactly one dataflow and no relationships. Validation reports an error otherwise.
  • Implementation Type Permanent is not available. An index on a virtual composite raises a validation warning.
  • A dataflow that reads the composite itself, directly or through other composites, raises a validation error.

Related articles