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

Business History View

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

A Business History View shows every version of the satellites of a Hub or Link with its validity, as a view in the Business Vault layer. It works like a History View and can also read Business Vault Hubs, Links, satellites and Business PITs. Use it to give marts or Vault Out the history of raw and business data in one view.

Sources and relationships

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

The satellites can be Satellites, Link Satellites, Business Satellites, Business Link Satellites and the four Effectivity satellite types. Vault Out can read a Business History View.

Create the model object

There is no wizard. Create a model object of type Business History View in the Business 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 or Business PIT: the view returns one row per row of its 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 Business History View generates one object, the view BDV_History_<model object name> in the Business Vault schema, 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 or Business 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)
  -> BDV_History_<model object name>

Example

The Business History View based_on_hub_single_satellite_without_pit_bhv on Microsoft SQL Server reads the Hub common_item and its Satellite common_item, without a PIT. It maps ITEM_ID, DESCRIPTION, SALES_PRICE and other terms. Persist Validity is false. The loads deliver these items:

  • Load 1 on 2026-10-28 08:00: item 1 Burger menu for 15.00, item 2 Burger for 12.50 and item 3 Fries for 4.50.
  • Load 2 on 2026-10-29 08:00: no change.
  • Load 3 on 2026-10-30 08:00: the Burger costs 13.00.
  • Load 4 on 2026-10-31 08:00: no change.
  • Load 4 on 2026-10-31 08:00: no change.

Check the result

Query the view, here in the Business Vault schema p2b:

SELECT ITEM_ID, DESCRIPTION, SALES_PRICE,
       BG_ValidFromTimestamp, BG_ValidToTimestamp
FROM p2b.BDV_History_based_on_hub_single_satellite_without_pit_bhv
ORDER BY ITEM_ID, BG_ValidFromTimestamp;

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

ITEM_ID  DESCRIPTION  SALES_PRICE  ValidFrom         ValidTo
1        Burger menu  15.00        2026-10-28 08:00  9999-12-31 00:00
2        Burger       12.50        2026-10-28 08:00  2026-10-30 08:00
2        Burger       13.00        2026-10-30 08:00  9999-12-31 00:00
3        Fries        4.50         2026-10-28 08:00  9999-12-31 00:00
  • Without a PIT, each row is one version of the Satellite with its validity. The new price of item 2 ended the first version at load 3.
  • Loads 2 and 4 added no rows.

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 Business History View becomes the dbt model bdv_history_<model object name>.
  • Fabric Warehouse: the same view as on Microsoft SQL Server, deployed by notebooks.
  • Oracle: names are in capitals.

Limitations

  • A Business History View holds exactly one Hub, Link or Business Vault counterpart, and at most one PIT or Business 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 or Business Driving Key Link, it cannot read a PIT or Business PIT.
  • A Business History View does not read Multi-Active, Record Tracking or Non-Historized satellites.

Related articles