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

History View

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

A History View shows every version of the satellites of a Hub or Link with its validity, as a view in the Raw Vault layer. Use it as a query layer or as the source of Business Vault objects and marts that need the history of a business key. The view has no table and no loader, so it always reflects the last load.

Sources and relationships

A History View has exactly one dataflow with one dataflow set and no relationships. The dataflow set contains:

The satellites can be Satellites, Link Satellites, Effectivity Satellites and Effectivity Link Satellites. Business Vault types, BusinessVault Composite and Vault Out can read a History View.

Create the model object

There is no wizard. Create a model object of type History View in the Raw Vault layer, create a dataflow set, add the source model objects and map the terms you want to show: usually the hash key and business keys of the Hub or Link and the descriptive terms of the satellites. You do not write join expressions; the generator builds the joins. A filter expression of the dataflow set is added to the view.

How the view builds the history

  • With a PIT: the view returns one row per row of the PIT result view, with its BG_ValidFromTimestamp and BG_ValidToTimestamp. It joins the Hub or Link on the PIT key and each satellite table on the satellite key and BG_ValidFromTimestamp that the PIT row references. A satellite without a version at that point contributes the values of its unknown-member row.
  • Without a PIT: the view returns one row per version of the satellite result view, with the validity of that version, joined with the Hub or Link result view on the key.

Properties

Default Terms

Generated objects

On Microsoft SQL Server, a History View generates one object, the view RDV_History_<model object name>, where <model object name> stands for the name of the model object. Its target object role is Result.

  • There is no source view, loader or table, and no unknown-member row.
  • The view exists also when the project property Create Result Views is false.
  • It reads the PIT result view, the Hub or Link result view and, with a PIT, the satellite tables or, without a PIT, the satellite result view.

A load does not run the view. It shows the data after these objects are loaded:

Hub or Link, satellites -> PIT (optional)
  -> RDV_History_<model object name>

Example

The History View based_on_customer_hub_with_pit_rhv on Microsoft SQL Server reads the PIT customer_based_on_hub, the Hub load_customer_hub and the two Satellites of the PIT. load_customer_sat holds the customer name, and load_caching_hashing holds the address. The view maps CUSTOMER_ID, CUSTOMER, ZIP_CODE and other terms. Persist Validity is false. The loads deliver these customers:

  • Load 1 on 2026-10-28 08:00: customer 1 Contoso Ltd with ZIP code 8001 and customer 2 Fabrikam AG with 10117.
  • Load 2 on 2026-10-29 08:00: customer 1 is renamed to Contoso Group, and customer 3 Northwind with 1010 arrives.
  • Load 3 on 2026-10-30 08:00: customer 1 moves to ZIP code 8005.
  • Load 4 on 2026-10-31 08:00: no change.

Check the result

Query the view, here in the schema p2:

SELECT CUSTOMER_ID, CUSTOMER, ZIP_CODE,
       BG_ValidFromTimestamp, BG_ValidToTimestamp
FROM p2.RDV_History_based_on_customer_hub_with_pit_rhv
ORDER BY CUSTOMER_ID, BG_ValidFromTimestamp;

This is the result after load 4, with the column names and timestamps shortened:

ID  CUSTOMER       ZIP_CODE  ValidFrom         ValidTo
1   Contoso Ltd    8001      2026-10-28 08:00  2026-10-29 08:00
1   Contoso Group  8001      2026-10-29 08:00  2026-10-30 08:00
1   Contoso Group  8005      2026-10-30 08:00  9999-12-31 00:00
2   Fabrikam AG    10117     2026-10-28 08:00  9999-12-31 00:00
3   Northwind      1010      2026-10-29 08:00  9999-12-31 00:00
  • Customer 1 has three rows: one per point in time of the PIT. Each row combines the name and the ZIP code valid at that time.
  • The last row of each customer is valid until the End of Universe.

Platform differences

  • Snowflake: names are in capitals. The dataflow property Warehouse Placeholder Variable Name applies.
  • Databricks and Fabric Lakehouse: the view name is in lowercase.
  • Databricks dbt and Snowflake dbt: the History View becomes the dbt model rdv_history_<model object name>.
  • Fabric Warehouse: the same view as on Microsoft SQL Server, deployed by notebooks.
  • Oracle: names are in capitals.

Limitations

  • A History View holds exactly one Hub, Link, Hierarchical Link or Driving Key Link, and at most one PIT. Without a PIT it holds exactly one satellite. Validation reports an error otherwise.
  • When the view maps the DrivingKeyLink_HK of a Driving Key Link, it cannot read a PIT.
  • A History View does not read Multi-Active, Record Tracking or Non-Historized satellites.

Related articles