Hub

A Hub stores each business key of a business object once, with its hash key Hub_HK, in a table of the Raw Vault layer. Use it as the anchor that Links and Satellites reference. After each load, the result view shows one row per business key and the load that first delivered it.

Sources and relationships

A Hub reads Stages, RawVault Composites and Store Entities of a linked Data Store project, in one or more dataflows. It has no relationships of its own. Other model objects use it in two ways:

• Relationship to the Hub: Link, Driving Key Link, Hierarchical Link, Same As Link, Satellite, Multi-Active Satellite, Record Tracking Satellite, Effectivity Satellite and Non-Historized Satellite, and their Business Vault counterparts.
• Dataflow source: Current View, History View, PIT, BusinessVault Composite, Vault Out and the Business Vault types.

Create a Hub

• With the wizard: open the menu of a Stage, RawVault Composite or Store Entity, choose Automate and then Create Hub. Its steps are Create Model Object, Create Dataflow, Map Selected Business Keys and Add to View. See Create a Model Object with the wizard.
  
• Manually: create a model object of type Hub in the Raw Vault layer, create a dataflow set, add the source model object and map the terms. Mark at least one term as business key.

A Hub holds only business keys and Default Terms. Validation reports an error for any other term.

Properties

• Implementation Type: Permanent only, a table that keeps its rows from load to load.
• 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. Available since Generator 2.3.
• Deduplication Method and Sort Order within Partition, per dataflow.

Platform-specific properties are listed under Platform differences.

Default Terms

• Hub_HK: hash of the business keys and primary key of the table. See How biGENIUS-X builds hash values.
• BG_LoadTimestamp: the load that inserted the business key.
• BG_SourceSystem: the source system of the row; empty unless you map it.
• BG_DataQuality_ID, BG_ErrorCount and BG_ErrorDescription: hidden terms of the data quality objects.

The business keys form a unique constraint of the table.

Generated objects

These are the names on Microsoft SQL Server for the Hub load_customer_hub with one dataflow:

• Loaders are stored procedures; the Hub 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.
• With several dataflows, all objects except the table and the result view exist once per dataflow. Their names carry the dataflow name, for example RDV_HUB_load_customer_hub_Dataflow1_Loader.
• The table script inserts the unknown-member row: business key 0 (text terms Unknown), a Hub_HK of zeros, BG_SourceSystem Unknown and BG_LoadTimestamp 1900-01-01. The result view hides this row. Link rows with an empty foreign key reference it.
• 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_HUB_load_customer_hub -> _Result
_Result -> _Delta (keys already stored)

The delta view keeps the rows whose Hub_HK is not in the result view. The loader inserts them with the load timestamp. A Hub loader never updates or deletes rows. With the optional objects, _Deduplication sits between _Source and _Hashing, and _HashingLoader fills _HashingTable before the delta view reads it.

Example

The Hub load_customer_hub on Microsoft SQL Server reads the Stage CUSTOMER. CUSTOMER_ID is the business key. The loads deliver these keys:

• Load 1 on 2026-10-28 08:00: customers 1 and 2.
• Load 2 on 2026-10-29 08:00: customers 1, 2 and 3.
• Load 3 on 2026-10-30 08:00: the same keys as load 2.

Check the result

Query the result view, here in the schema rv:

SELECT CUSTOMER_ID, Hub_HK, BG_LoadTimestamp
FROM rv.RDV_HUB_load_customer_hub_Result
ORDER BY CUSTOMER_ID;

This is the result after load 3, with Hub_HK shortened to its first four bytes:

CUSTOMER_ID  Hub_HK      BG_LoadTimestamp
1            0xE91FE173  2026-10-28 08:00
2            0x21ED4C7A  2026-10-28 08:00
3            0x2064F80F  2026-10-29 08:00

• Load 2 inserted only customer 3, so customers 1 and 2 keep the timestamp of load 1.
• Load 3 inserted no row.
• The table holds a fourth row, the unknown-member row with CUSTOMER_ID 0.

With two dataflows, each dataflow loader inserts only the keys that are not yet stored. For example, when the first dataflow delivers customers 1 and 2 and the second one customers 2 and 7, the Hub stores customer 2 once.

Platform differences

• Snowflake: names are in capitals, and the loader is a stored procedure. The load control task LC_RDV_HUB_<model object name> 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_HUB_<model object name>_Loader. The properties File Format, Optimization Method, Optimization Method Columns and Use Sequential Dataflow Execution apply.
• Databricks dbt and Snowflake dbt: the Hub becomes the dbt models rdv_hub_<model object name>_source and rdv_hub_<model object name>. The model rdv_hub_<model object name>_result exists only when Create Result Views is true; the default on dbt is false. Load Caching is not available. File Format and the optimization properties apply on Databricks dbt.
• 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, for example PARTITION BY HASH (CUSTOMER_ID) PARTITIONS 4. Table Compression, Tablespace Table, Tablespace Index, Create Table Statistics and Parallel Degree of Statistics Calculation also apply.

Limitations

• A Hub has at least one business key, no relationships and no terms other than business keys and Default Terms.
• A dataflow that delivers the same business key twice in one load makes the loader fail. On Microsoft SQL Server the message is Violation of PRIMARY KEY constraint 'PK_RDV_HUB_<model object name>'. Deduplication Method Distinct or Partition removes such duplicates before hashing.
• A Hub keeps no history. Satellites store the descriptive data of its keys.

Related articles

• Previous: Stage, RawVault Composite, Store Entity
• Next: Link, Satellite
• Reference: Hub_HK, Implementation Type (Model Object), Load Caching (Model Object), Custom Singleton Values (Model Object), Deduplication Method (Dataflow), Sort Order within Partition (Dataflow), Create Result Views (Project)
• See also: How biGENIUS-X builds hash values, Create a Model Object with the wizard, Model a Data Vault Solution