Business Driving Key Link

A Business Driving Key Link is a Business Vault link with a second hash key, DrivingKeyLink_HK, calculated from the relationships marked as driving key. Use it when a business rule derives from Raw Vault data which relationship a driving key has, for example the job function of an employee. After each load, the table holds every relationship that the source delivered, each with the load that first delivered it.

A Business Driving Key Link works like a Driving Key Link. It differs in its sources, its layer, its relationship targets and the BDV_ prefix of its objects. It is available since Generator 2.0.

Sources and relationships

A Business Driving Key Link reads the result views of Raw Vault objects, in one or more dataflows: Hubs, all Link types, PITs, RawVault Composites, Current Views, History Views and the satellite types Satellite, Link Satellite, Effectivity Satellite, Effectivity Link Satellite, Record Tracking Link Satellite, Non-Historized Satellite (no article yet) and Non-Historized Link Satellite. It also reads BusinessVault Composites.

It has at least two relationships to Hubs or Business Hubs. The relationship property Driving Key marks the driving side; its default is true, so set it to false on the other relationships. The foreign-key terms are the business keys of the Business Driving Key Link. Business Current View, Business History View, Business PIT and Vault Out can read it as a source.

Create the model object

• With the wizard: open the menu of a Raw Vault Hub, Link, PIT, Current View, History View or satellite, or of a BusinessVault Composite. Choose Automate and then Create Business Driving Key Link. Multi-Active Satellites and Record Tracking Satellites do not offer it. Its steps are Create Model Object, Create Dataflow, Create Relations Driving, Define Role Driving, Create Relations Not Driving, Define Role Not Driving, Map Foreign Key Terms and Add to View. The relation steps are described in Wizard step - Create Relations Driving or Not Driving. See Create a Model Object with the wizard.
• Manually: create a model object of type Business Driving Key Link in the Business Vault layer, add a relationship to each Hub or Business Hub and set Driving Key, create a dataflow set, add the source model object and map the foreign-key terms.

A Business Driving Key Link holds only foreign-key terms and Default Terms. Validation reports an error for any other term.

Properties

• Implementation Type: Permanent only.
• Foreign Key Mode: whether the table gets foreign keys to the Hub tables. With Create Disabled, the default, they are created and disabled.
• Load Caching: empty (default) or Hashing, which stores the hashing view in a table before the loader runs.
• Custom Singleton Values: values of the unknown-member row.
• Deduplication Method and Sort Order within Partition, per dataflow.
• Driving Key, per relationship: true (default) or false.
• Use Embryo Loader, per relationship: inserts business keys that the Hub or Business Hub does not hold yet. See Embryo Loader.

Default Terms

• Link_HK: hash of the business keys of all relationships and primary key of the table.
• DrivingKeyLink_HK: hash of the business keys of the driving relationships. With one driving relationship to a Hub, it equals that Hub's key.
• DVLINK_ForeignKey_Identity: names one hash-key column per relationship, <Hub name>_<role>_HK, with the key of the related Hub row.
• BG_LoadTimestamp and BG_SourceSystem: the load that inserted the row and its source system, empty unless you map it.
• BG_DataQuality_ID, BG_ErrorCount and BG_ErrorDescription: hidden terms of the data quality objects.

See How biGENIUS-X builds hash values.

Generated objects

These are the names on Microsoft SQL Server for the Business Driving Key Link load_bdkl with one dataflow:

• Loaders are stored procedures; the Business Driving Key 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, for example BDV_BDKLNK_load_bdkl_Dataflow1_HashingTable.
• The table script inserts the unknown-member row with hash keys of zeros. The result view hides it.
• When no other model object has a relationship to the Business Driving Key Link, its result view shows only the latest row per DrivingKeyLink_HK.
• 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_BDKLNK_load_bdkl -> _Result
_Result -> _Delta (key combinations in the result view)

The source view reads the result views of its sources. The hashing view calculates Link_HK, DrivingKeyLink_HK and one Hub key per relationship. 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 the table keeps the earlier relationship of a driving key as well. 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 tables.

Example

The Business Driving Key Link load_bdkl on Microsoft SQL Server reads the current versions of the Link Satellite load_employee_dklsat_1, joined with its Driving Key Link load_dkl. The dataflow filters on BG_ValidToTimestamp of End of Universe, so it delivers one job function per employee. The relationship to the Hub common_employee (role EMPLOYEE) is driving; the one to the Hub common_jobfunction (role JOBFUNCTION) is not. The Raw Vault and then the Business Driving Key Link load four times:

• Load 1 on 2026-10-28 08:00: employee 101 with job function 10, employees 102 and 103 with job function 20.
• Load 2 on 2026-10-29 08:00: employee 102 moves to job function 30, and employee 104 is new with job function 10.
• Loads 3 and 4 on 2026-10-30 and 2026-10-31 08:00: no change of job function.

Check the result

Query the table, here in the schema p3b. The filter on Link_HK leaves out the unknown-member row:

SELECT FK_common_employee_EMPLOYEE_EMPLOYEE_ID AS EMPLOYEE_ID,
       FK_common_jobfunction_JOBFUNCTION_JOBFUNCTION_ID AS JOB_ID,
       Link_HK, DrivingKeyLink_HK, BG_LoadTimestamp
FROM p3b.BDV_BDKLNK_load_bdkl
WHERE Link_HK <> 0x00
ORDER BY EMPLOYEE_ID, BG_LoadTimestamp;

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

EMPLOYEE_ID  JOB_ID  Link_HK     DrivingKeyLink_HK  BG_LoadTimestamp
101          10      0xF5A3FB96  0x6348AE9A         2026-10-28 08:00
102          20      0x7253958A  0x8887BDD9         2026-10-28 08:00
102          30      0xBF5A86A3  0x8887BDD9         2026-10-29 08:00
103          20      0x30ED23FA  0x9D4E8CB4         2026-10-28 08:00
104          10      0x542F37C7  0x01656192         2026-10-29 08:00

• Employee 102 has two rows with the same DrivingKeyLink_HK: job function 20 from load 1 and job function 30 from load 2.
• Loads 3 and 4 inserted no row.

No other model object has a relationship to the Business Driving Key Link, so its result view shows the latest row per DrivingKeyLink_HK:

SELECT FK_common_employee_EMPLOYEE_EMPLOYEE_ID AS EMPLOYEE_ID,
       FK_common_jobfunction_JOBFUNCTION_JOBFUNCTION_ID AS JOB_ID,
       BG_LoadTimestamp
FROM p3b.BDV_BDKLNK_load_bdkl_Result
ORDER BY EMPLOYEE_ID;

EMPLOYEE_ID  JOB_ID  BG_LoadTimestamp
101          10      2026-10-28 08:00
102          30      2026-10-29 08:00
103          20      2026-10-28 08:00
104          10      2026-10-29 08:00

Platform differences

• Snowflake: names are in capitals, and the loader 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 is the notebook BDV_BDKLNK_<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 Business Driving Key Link becomes the dbt models bdv_bdklnk_<model object name>_source and bdv_bdklnk_<model object name>. The model bdv_bdklnk_<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. The tablespaces and the statistics properties apply.

Limitations

• A Business Driving Key Link has at least two relationships and no terms other than foreign keys and Default Terms.
• A dataflow that delivers the same key combination 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.0: the Business Driving Key Link type and its wizard are available.
• Generator 2.2: Use Embryo Loader is available.
• Generator 2.3: Custom Singleton Values is available.
• Generator 2.4.1: with Load Caching Hashing and several dataflows, each dataflow has its own hashing table, named with the dataflow.

Related articles

• Previous: Hub, Business Hub, Driving Key Link
• Next: Business Current View, Business PIT
• Reference: DrivingKeyLink_HK, Link_HK, DVLINK_ForeignKey_Identity, Driving Key (Relationship), Foreign Key Mode (Model Object), Load Caching (Model Object), Custom Singleton Values (Model Object), Create Result Views (Project)
• See also: Business Link, Embryo Loader, How biGENIUS-X builds hash values, Create a Model Object with the wizard, Model a Data Vault Solution