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

Hierarchical Business Link

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

A Hierarchical Business Link stores parent-child pairs of one Hub or Business Hub, read from the Raw Vault, in a table of the Business Vault layer. Use it for a hierarchy that a business rule derives from Raw Vault data, such as employees and their managers. After each load, the result view shows one row per pair and the load that first delivered it.

A Hierarchical Business Link works like a Hierarchical Link. It differs in its sources, its layer, its relationship targets and the BDV_ prefix of its objects.

Sources and relationships

A Hierarchical Business Link reads the result views of Raw Vault objects, in one or more dataflows: Hubs, all Link types, all satellite types, Current Views and History Views. It also reads BusinessVault Composites. It has exactly two relationships, both to the same Hub or Business Hub, with roles such as employee and manager. The foreign-key terms are the business keys of the Hierarchical Business Link. See Use parent-child relationships.

Business Current View, Business History View and Vault Out can read it as a source.

Create the model object

Properties

Default Terms

When the parent key is NULL, for example for an employee without a manager, the hash key of that relationship is zeros, the key of the Hub's unknown-member row. See Behaviour for Nulled Business Keys in Links.

Generated objects

These are the names on Microsoft SQL Server for the Hierarchical Business Link load_bhlnk with one dataflow:

RoleGenerated namePurpose
SourceBDV_HLNK_load_bhlnk_SourceReads the sources
DeduplicationBDV_HLNK_load_bhlnk_DeduplicationRemoves duplicate rows
HashingBDV_HLNK_load_bhlnk_HashingCalculates the hash keys
HashingStorageBDV_HLNK_load_bhlnk_HashingTableStores the hashed rows
HashingLoaderBDV_HLNK_load_bhlnk_HashingLoaderFills the hashing table
EmbryoLoaderBDV_HLNK_load_bhlnk_EmbryoLoaderAdds missing Hub keys
DeltaBDV_HLNK_load_bhlnk_DeltaSelects new pairs
LoaderBDV_HLNK_load_bhlnk_LoaderInserts the new rows
StorageBDV_HLNK_load_bhlnkHierarchical Business Link table
ResultBDV_HLNK_load_bhlnk_ResultQuery view
  • Loaders are stored procedures; the Hierarchical Business Link table and the hashing table are tables; all other objects are views.
  • The deduplication view exists only with a Deduplication Method other than None.
  • The hashing table and hashing loader exist only with Load Caching Hashing. The delta view then reads the hashing table.
  • The embryo loader exists only when Use Embryo Loader is true on a relationship. It runs before the loader.
  • With several dataflows, all objects except the table and the result view exist once per dataflow, with the dataflow name in their names.
  • The table script inserts the unknown-member row with hash keys of zeros. The result view hides it.
  • The result view always exists, independent of Create Result Views.

With the default settings, a load runs this chain:

Raw Vault _Result views -> _Source -> _Hashing -> _Delta
_Delta -> _Loader -> BDV_HLNK_load_bhlnk -> _Result
_Result -> _Delta (pairs already stored)

The source view reads the result views of its sources. The hashing view calculates Link_HK and the Hub key of each role. The delta view keeps the rows whose Link_HK is not in the result view, and the loader inserts them with the load timestamp. The loader never updates or deletes rows, so a pair that the source no longer delivers stays. With the optional objects, _Deduplication sits between _Source and _Hashing, _HashingLoader fills _HashingTable before the delta view reads it, and _EmbryoLoader writes missing keys to the Hub table.

Example

The Hierarchical Business Link load_bhlnk on Microsoft SQL Server reads the Hierarchical Link load_employee_hlnk of the Raw Vault. Its two relationships go to the Hub common_employee, with the roles employee and manager. The Raw Vault and then the Hierarchical Business Link load four times:

  • Load 1 on 2026-10-28 08:00: employee 101 without a manager, employees 102 and 103 with manager 101.
  • Load 2 on 2026-10-29 08:00: employee 104 with manager 102 is new.
  • Load 3 on 2026-10-30 08:00: employee 103 gets manager 102.
  • Load 4 on 2026-10-31 08:00: no change.

Check the result

Query the result view, here in the schema p3b:

SELECT FK_common_employee_employee_EMPLOYEE_ID AS EMPLOYEE_ID,
       FK_common_employee_manager_EMPLOYEE_ID AS MANAGER_ID,
       common_employee_manager_HK AS manager_HK, BG_LoadTimestamp
FROM p3b.BDV_HLNK_load_bhlnk_Result
ORDER BY EMPLOYEE_ID, BG_LoadTimestamp;

This is the result after load 4, with hash keys shortened to their first four bytes:

EMPLOYEE_ID  MANAGER_ID  manager_HK  BG_LoadTimestamp
101          NULL        0x00000000  2026-10-28 08:00
102          101         0x6348AE9A  2026-10-28 08:00
103          101         0x6348AE9A  2026-10-28 08:00
103          102         0x8887BDD9  2026-10-30 08:00
104          102         0x8887BDD9  2026-10-29 08:00
  • Employee 101 has no manager, so the manager key is zeros.
  • The new manager of employee 103 added a second pair in load 3. The first pair stays.
  • Load 4 inserted no row.

Platform differences

  • Snowflake: names are in capitals, and the loader is a stored procedure. The load control task LC_BDV_HLNK_<model object name>_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 is the notebook BDV_HLNK_<model object name>_Loader. The properties File Format, Optimization Method, Optimization Method Columns and Use Sequential Dataflow Execution apply. Fabric Lakehouse allows only Foreign Key Mode None.
  • Databricks dbt and Snowflake dbt: the Hierarchical Business Link becomes the dbt models bdv_hlnk_<model object name>_source and bdv_hlnk_<model object name>. The model bdv_hlnk_<model object name>_result exists only when Create Result Views is true; the default on dbt is false. Load Caching and Use Embryo Loader are not available.
  • Fabric Warehouse: the same objects as on Microsoft SQL Server, deployed by notebooks.
  • Oracle: names are in capitals, and the loader 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.
  • Foreign Key Mode Create Enforced exists only on Microsoft SQL Server and Oracle.

Limitations

  • A Hierarchical Business Link has exactly two relationships to the same Hub or Business Hub and no terms other than foreign keys and Default Terms. Validation reports an error otherwise.
  • A Hierarchical Business Link holds one level, the direct parent.
  • A dataflow that delivers the same pair twice in one load makes the loader fail with a primary key violation. A Deduplication Method removes such duplicates before hashing.

Release differences

  • Generator 2.2: Use Embryo Loader is available.
  • Generator 2.3: Custom Singleton Values is available.

Related articles