Business Link
Applies to
Platform: Microsoft SQL Server · Snowflake · Snowflake dbt · Databricks · Databricks dbt · Fabric Lakehouse · Fabric Warehouse · Oracle
Architecture: Data Vault
A Business Link stores each key combination that it reads from the Raw Vault once, with its hash key Link_HK, in a table of the Business Vault layer. Use it for a relationship that a business rule derives from Raw Vault data, such as the cashier, item and loyalty card of a sales transaction. After each load, the result view shows one row per key combination and the load that first delivered it.
A Business Link works like a Link. It differs in its sources, its layer, its relationship targets and the BDV_ prefix of its objects.
Sources and relationships
A 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 and Hierarchy Flattens. It has one or more relationships to Hubs or Business Hubs. The foreign-key terms of the relationships are the business keys of the Business Link.
Business Link Satellites, Record Tracking Business Link Satellites, Effectivity Business Link Satellites, Non-Historized Business Link Satellites reference a Business 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 or satellite, or of a BusinessVault Composite. Choose Automate and then Create Business Link. Its steps are Create Model Object, Create Dataflow, Create Multiple Relations, Define Roles, Map Foreign Key Terms and Add to View. See Create a Model Object with the wizard.
- Manually: create a model object of type Business Link in the Business Vault layer, add a relationship to each Hub or Business Hub, create a dataflow set, add the source model object and map the foreign-key terms.
A Business Link holds only foreign-key terms and Default Terms. Validation reports an error for any other term; descriptive data goes into a Business Link Satellite.
Properties
- Implementation Type:
Permanentonly. - 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.
- Use Embryo Loader, per relationship: inserts business keys that the related Hub or Business Hub does not hold yet.
Default Terms
Link_HK: hash of the business keys of all relationships and primary key of the table. See How biGENIUS-X builds hash values.DVLINK_ForeignKey_Identity: names one hash-key column per relationship,<Hub name>_<role>_HK. It holds the key of the related Hub row.BG_LoadTimestamp: the load that inserted the row.BG_SourceSystem: the source system of the row; empty unless you map it.BG_DataQuality_ID,BG_ErrorCountandBG_ErrorDescription: hidden terms of the data quality objects.
When all foreign-key terms of a nullable relationship are NULL, the Business Link stores 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 Business Link load_blnk with one dataflow:
| Role | Generated name | Purpose |
|---|---|---|
| Source | BDV_LNK_load_blnk_Source | Reads the sources |
| Deduplication | BDV_LNK_load_blnk_Deduplication | Removes duplicate rows |
| Hashing | BDV_LNK_load_blnk_Hashing | Calculates the hash keys |
| HashingStorage | BDV_LNK_load_blnk_HashingTable | Stores the hashed rows |
| HashingLoader | BDV_LNK_load_blnk_HashingLoader | Fills the hashing table |
| EmbryoLoader | BDV_LNK_load_blnk_EmbryoLoader | Adds missing Hub keys |
| Delta | BDV_LNK_load_blnk_Delta | Selects new key combinations |
| Loader | BDV_LNK_load_blnk_Loader | Inserts the new rows |
| Storage | BDV_LNK_load_blnk | Business Link table |
| Result | BDV_LNK_load_blnk_Result | Query view |
- Loaders are stored procedures; the 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 and foreign keys
0. The result view hides it. - With Foreign Key Mode
Create Disabled, the table script adds a foreign key per relationship and disables 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_LNK_load_blnk -> _Result _Result -> _Delta (key combinations already stored)
The source view reads the result views of its sources. The hashing view calculates Link_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. 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 Link load_blnk on Microsoft SQL Server reads the BusinessVault Composite load_salestransaction_virtual_bcmp, a view of sales transactions. It has relationships to the Hubs common_employee, common_item and common_loyaltycard, with the roles EMPLOYEE, ITEM and LOYALTYCARD. The composite delivers these transactions:
- Load 1 on 2026-10-28 08:00: cashier 101 sells item 2 to loyalty card 501.
- Load 2 on 2026-10-29 08:00: the same transaction, and cashier 102 sells item 3 to card 503.
- Loads 3 and 4 on 2026-10-30 and 2026-10-31 08:00: the same transactions as load 2.
Check the result
Query the result view, here in the schema p3b:
SELECT FK_common_employee_EMPLOYEE_EMPLOYEE_ID AS EMPLOYEE_ID,
FK_common_item_ITEM_ITEM_ID AS ITEM_ID,
FK_common_loyaltycard_LOYALTYCARD_LOYALTYCARD_ID
AS LOYALTYCARD_ID,
BG_LoadTimestamp
FROM p3b.BDV_LNK_load_blnk_Result
ORDER BY BG_LoadTimestamp;
This is the result after load 4:
EMPLOYEE_ID ITEM_ID LOYALTYCARD_ID BG_LoadTimestamp 101 2 501 2026-10-28 08:00 102 3 503 2026-10-29 08:00
- Load 2 inserted only the new combination of cashier 102, item 3 and card 503.
- Loads 3 and 4 inserted no row.
- The table holds a third row, the unknown-member row.
Platform differences
- Snowflake: names are in capitals, and the loader is a stored procedure. The load control task
LC_BDV_LNK_<model object name>_TASKcalls 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_LNK_<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 ModeNone. - Databricks dbt and Snowflake dbt: the Business Link becomes the dbt models
bdv_lnk_<model object name>_sourceandbdv_lnk_<model object name>. The modelbdv_lnk_<model object name>_resultexists 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 TABLEstatement. Table Compression, the tablespaces and the statistics properties also apply. - Foreign Key Mode
Create Enforcedexists only on Microsoft SQL Server and Oracle.
Limitations
- A Business Link has at least one relationship and at least one business key, and no terms other than foreign keys and Default Terms.
- A Business Link keeps no history and no validity. Business Link Satellites store the descriptive data and its history.
- 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.
Related articles
- Previous: Business Hub, Hub, BusinessVault Composite
- Next: Business Link Satellite
- Reference: Link_HK, DVLINK_ForeignKey_Identity, Foreign Key Mode (Model Object), Load Caching (Model Object), Custom Singleton Values (Model Object), Behaviour for Nulled Business Keys in Links (Project), Create Result Views (Project)
- See also: Link, Business Driving Key Link, Embryo Loader, How biGENIUS-X builds hash values, Create a Model Object with the wizard