Driving Key Link

A Driving Key Link is a Link with a second hash key, DrivingKeyLink_HK, calculated from the relationships marked as driving key. Use it when one side of a relationship decides which relationship is current, for example an employee who has exactly one job function at a time. A Link Satellite on the Driving Key Link then closes the previous relationship of the employee when a new one arrives.

Sources and relationships

A Driving Key Link reads Stages, RawVault Composites and Store Entities of a linked Data Store project, in one or more dataflows. It has at least two relationships to 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 Driving Key Link.

Link Satellites, Record Tracking Link Satellites, Effectivity Link Satellites reference a Driving Key Link. PIT, Current View, History View, BusinessVault Composite, Vault Out and the Business Vault types can read it as a source.

Create the model object

• With the wizard: open the menu of a Stage, RawVault Composite or Store Entity, choose Automate and then Create Driving Key Link. Its steps are Create Model Object, Create Dataflow, Create Multiple Relations Driving, Define Roles, Create Multiple Relations Not Driving, Define Roles, Map Foreign Key Terms and Add to View. The two relation steps are described in Wizard step - Create Multiple Relations Driving or Not Driving. See Create a Model Object with the wizard.
• Manually: create a model object of type Driving Key Link in the Raw Vault layer, add a relationship to each Hub and set Driving Key, create a dataflow set, add the source model object and map the foreign-key terms.

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 does not hold yet.

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 Driving Key Link load_dkl with one dataflow:

• Loaders are stored procedures; the 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 RDV_DKLNK_load_dkl_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 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:

sources -> _Source -> _Hashing -> _Delta -> _Loader
_Loader -> RDV_DKLNK_load_dkl -> _Result
_Result -> _Delta (key combinations already stored)

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. The Driving Key Link itself never updates or deletes rows: it keeps the earlier relationship as well. Its Link Satellites store which relationship is current:

• The Link Satellite carries DrivingKeyLink_HK next to Link_HK.
• Its row hash includes the business keys of the relationships that are not driving.
• Its validity ends per DrivingKeyLink_HK. A new relationship of the same driving key therefore ends the version of the previous relationship.

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 Driving Key Link load_dkl on Microsoft SQL Server reads the Stage EMPLOYEE. Its relationship to the Hub common_employee (role EMPLOYEE) is driving; the one to the Hub common_jobfunction (role jobfunction) is not. The Link Satellite load_employee_dklsat_1 stores MANAGER_ID and other employee data. The loads deliver these rows:

• Load 1 on 2026-10-28 08:00: employee 101 with job function 10, employees 102 and 103 with job function 20 and manager 101.
• Load 2 on 2026-10-29 08:00: employee 102 moves to job function 30, employee 103 gets manager 102, and employee 104 is new with job function 10 and manager 102.

Check the result

Query the Driving Key Link, here in the schema rv:

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 rv.RDV_DKLNK_load_dkl_Result
ORDER BY EMPLOYEE_ID, BG_LoadTimestamp;

This is the result after load 2, 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

Then query the Link Satellite with the keys of the Driving Key Link:

SELECT l.FK_common_employee_EMPLOYEE_EMPLOYEE_ID AS EMPLOYEE_ID,
       l.FK_common_jobfunction_jobfunction_JOBFUNCTION_ID AS JOB_ID,
       s.MANAGER_ID, s.BG_ValidFromTimestamp, s.BG_ValidToTimestamp
FROM rv.RDV_LSAT_load_employee_dklsat_1_Result AS s
JOIN rv.RDV_DKLNK_load_dkl_Result AS l ON l.Link_HK = s.Link_HK
ORDER BY EMPLOYEE_ID, s.BG_ValidFromTimestamp;

This is the Link Satellite after load 2, with the column names shortened:

EMPLOYEE_ID  JOB_ID  MANAGER_ID  ValidFrom         ValidTo
101          10      NULL        2026-10-28 08:00  9999-12-31 00:00
102          20      101         2026-10-28 08:00  2026-10-29 08:00
102          30      101         2026-10-29 08:00  9999-12-31 00:00
103          20      101         2026-10-28 08:00  2026-10-29 08:00
103          20      102         2026-10-29 08:00  9999-12-31 00:00
104          10      102         2026-10-29 08:00  9999-12-31 00:00

• Employee 102 has two rows in the Driving Key Link with the same DrivingKeyLink_HK. The result view shows both, because the Link Satellite has a relationship to the Driving Key Link.
• In the Link Satellite, the version with job function 20 ends at load 2, when job function 30 starts. Only one version per employee is open.
• Employee 103 keeps job function 20; the new manager starts a new version of the same relationship.

Platform differences

• Snowflake: names are in capitals, and the loader is a stored procedure. The load control task LC_RDV_DKLNK_<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 RDV_DKLNK_<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 Driving Key Link becomes the dbt models rdv_dklnk_<model object name>_source and rdv_dklnk_<model object name>. The model rdv_dklnk_<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 Driving Key Link has at least two relationships and no terms other than foreign keys and Default Terms.
• The Driving Key Link alone does not show which relationship is current. Its Link Satellite shows it.
• 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.2: Use Embryo Loader is available.
• Generator 2.3: Custom Singleton Values is available.
• Generator 2.4: Link Satellites of a Driving Key Link end their versions per DrivingKeyLink_HK.
• 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
• Next: Link Satellite
• 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: Link, Embryo Loader, How biGENIUS-X builds hash values, Create a Model Object with the wizard, Model a Data Vault Solution