Skip to content
  • There are no suggestions because the search field is empty.

Vault Out

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

A Vault Out is a model object type of the Business Vault layer that combines Raw Vault and Business Vault objects into one output for later layers. Use it as the source of Mart objects in a Vault and Mart project or of another Vault Out. With Implementation Type Virtual you get views only; with Cached you also get a table that each load fills again.

Available since Generator 2.2. A Mart Out cannot read a Vault Out, and a Data Mart project cannot import one as a linked object.

Sources and consumers

A Vault Out reads every Raw Vault and Business Vault model object type except RawVault Composite, for example Hub, Satellite, PIT, Current View, BusinessVault Composite and Business Hub. It can also read another Vault Out.

These model objects can read a Vault Out:

When a Mart Composite or Mart Hierarchy Flatten reads a BusinessVault Composite, validation reports warning ID-21002. Read the data through a Vault Out instead; in a Vault and Mart project the Mart objects accept a Vault Out as source.

Data Connections lists a Vault Out for export. A Data Mart project cannot use that export: its import offers no model object to add.

A Vault Out has no relationships.

Create a Vault Out

A Vault Out has exactly one dataflow. Join several sources in its dataflow set, or combine dataflow sets with a set operator.

Properties

  • Implementation Type: Virtual (default) or Cached. Virtual creates views only, so the result view reads the sources at query time. Cached adds a table and a loader. The loader empties the table and inserts all rows again on every load.
  • Deduplication Method, set per dataflow: None (default), Distinct or Partition. Distinct removes rows that are equal in all terms. Partition keeps one row per business key, the first one by Sort Order within Partition.
  • Sort Order within Partition, set per dataflow: the order that decides which row Partition keeps, for example VERSION_NUMBER DESC.

Edit Term offers the Business Key flag on Vault Out terms. Only Partition uses it. Without business keys, Partition partitions by all terms that are not Default Terms, which removes the same rows as Distinct, and validation shows warning ID-10051.

Default Terms

The wizard maps neither of them.

Generated objects

These are the names on Microsoft SQL Server for a Vault Out customer_vo:

RoleGenerated namePurpose
SourceBDV_VO_customer_vo_SourceJoins the sources
DeduplicationBDV_VO_customer_vo_DeduplicationRemoves duplicates
StorageBDV_VO_customer_voTable
LoaderBDV_VO_customer_vo_LoaderReloads the table
ResultBDV_VO_customer_vo_ResultQuery view
  • The loader is a stored procedure and the table is a table; all other objects are views.
  • The deduplication view exists only with Distinct or Partition.
  • The table and the loader exist only with Cached. Load control runs the loader after the loaders of the sources.
  • The result view reads the table with Cached, otherwise the deduplication or source view.
sources -> _Source -> _Deduplication (Distinct or Partition)
Cached:  last view -> _Loader -> BDV_VO_customer_vo -> _Result
Virtual: last view -> _Result

Example

The Vault Out customer_vo on Microsoft SQL Server joins the Hub common_customer (s1) and its Satellite (s2) on Hub_HK. The dataflow set filter s2.BG_ValidToTimestamp = '9999-12-31' keeps the current Satellite versions. Implementation Type is Cached, Deduplication Method is None, and the Default Terms are not mapped. A second Vault Out customer_virtual_vo has the same dataflow with Implementation Type Virtual. The results below show the timestamps shortened.

The first Raw Vault load delivers customer 1 with an old version in Basel and a current version in Zurich, and customer 2 in Bern. After the Vault Out loader ran at 2026-04-01 06:00, query the result view, here in the schema bv:

SELECT CUSTOMER_ID, CUSTOMER, ADDRESS_LINE1, BG_LoadTimestamp,
       BG_SourceSystem
FROM bv.BDV_VO_customer_vo_Result
ORDER BY CUSTOMER_ID;
CUSTOMER_ID  CUSTOMER  ADDRESS_LINE1  BG_LoadTimestamp  BG_SourceSystem
1            Meier     Zurich         2026-04-01 06:00  NULL
2            Huber     Bern           2026-04-01 06:00  NULL

The next Raw Vault load moves customer 2 to Thun and adds customer 3 in Chur. Until the Vault Out loader runs again, customer_vo still shows the rows above. customer_virtual_vo shows the change at once, without a loader:

CUSTOMER_ID  CUSTOMER  ADDRESS_LINE1  BG_LoadTimestamp  BG_SourceSystem
1            Meier     Zurich         NULL              NULL
2            Huber     Thun           NULL              NULL
3            Keller    Chur           NULL              NULL

The Vault Out loader at 2026-05-01 06:00 reports 3 inserted rows. Then customer_vo returns:

CUSTOMER_ID  CUSTOMER  ADDRESS_LINE1  BG_LoadTimestamp  BG_SourceSystem
1            Meier     Zurich         2026-05-01 06:00  NULL
2            Huber     Thun           2026-05-01 06:00  NULL
3            Keller    Chur           2026-05-01 06:00  NULL

Every row carries the timestamp of the last load, because the loader writes all rows again.

Platform differences

  • Snowflake: names are in upper case, and the table is transient. The loader overwrites the table, and the load control task LC_BDV_VO_<MODEL OBJECT NAME>_TASK calls it; a Virtual Vault Out has no task. The dataflow properties Use Stream and Warehouse Placeholder Variable Name apply.
  • Databricks and Fabric Lakehouse: table and view names are in lower case. The loader is the notebook BDV_VO_<model object name>_Loader and overwrites the table. The properties File Format, Optimization Method and Optimization Method Columns apply.
  • Databricks dbt and Snowflake dbt: the generator creates the dbt models bdv_vo_<model object name>_source (view, with the deduplication inside), bdv_vo_<model object name> (table, only with Cached) and bdv_vo_<model object name>_result (view). There is no loader. On Databricks dbt, File Format, Optimization Method and Optimization Method Columns apply.
  • Oracle: the properties Partition Clause, Table Compression, Create Table Statistics, Parallel Degree of Statistics Calculation, Tablespace Table and Tablespace Index apply to the table.

Limitations

  • A Vault Out has exactly one dataflow, at least one term that is not a Default Term, and no relationships.
  • Implementation Type Permanent and Deduplication Method Condensing fail validation.
  • A Cached Vault Out keeps no history: each load replaces all rows.
  • Mart Out cannot read a Vault Out, and a Data Mart project cannot import one.

Related articles