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

Business Link Satellite

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

A Business Link Satellite stores descriptive data of a Link's or Business Link's rows, read from the Raw Vault, with its history in a Business Vault table. Use it for attributes of a relationship that a business rule calculates or combines from Raw Vault data. After each load, the result view shows every version of each Link row with its validity.

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

Sources and relationships

A Business Link Satellite 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 exactly one relationship to a Link or Business Link, and its foreign-key terms must be mapped. The foreign-key terms are the business keys of the Link's Hubs. Business PIT, Business Current View, Business History View and Vault Out can read it.

Create the model object

Historization

The loader inserts a new version of a Link row when its row hash BG_RowHash differs from the current version. The new version starts at the load timestamp, the previous version ends there, and the current version ends at End of Universe. An unchanged row adds no version, and the loader never deletes or updates rows.

Properties

The project properties Persist Validity and Create Result Views also apply.

Default Terms

Generated objects

These are the names on Microsoft SQL Server for the Business Link Satellite load_blsat with one dataflow:

RoleGenerated namePurpose
SourceBDV_LSAT_load_blsat_SourceReads the sources
DeduplicationBDV_LSAT_load_blsat_DeduplicationRemoves duplicate rows
MultiVersionBDV_LSAT_load_blsat_VersioningCombines the source versions
HashingBDV_LSAT_load_blsat_HashingCalculates the hash keys
HashingStorageBDV_LSAT_load_blsat_HashingTableStores the hashed rows
HashingLoaderBDV_LSAT_load_blsat_HashingLoaderFills the hashing table
RowCondensingBDV_LSAT_load_blsat_RowCondensingMerges equal versions
IncrementSourceBDV_LSAT_load_blsat_IncrementSourceFinds the new increment
IncrementBDV_LSAT_load_blsat_IncrementStores the increments
EmbryoLoaderBDV_LSAT_load_blsat_EmbryoLoaderAdds missing Link keys
DeltaBDV_LSAT_load_blsat_DeltaSelects new versions
LoaderBDV_LSAT_load_blsat_LoaderInserts the new versions
StorageBDV_LSAT_load_blsatBusiness Link Satellite table
ResultBDV_LSAT_load_blsat_ResultQuery view with validity
  • Loaders are stored procedures; the Business Link Satellite table, the hashing table and the increment table are tables; all other objects are views.
  • The deduplication view exists only with a Deduplication Method other than None.
  • The versioning and row-condensing views exist only with a Version Valid From Term.
  • The hashing table and hashing loader exist only with Load Caching Hashing.
  • The increment table exists only with an incremental load, that is, when a dataflow maps BG_IncrementalFilter; the increment source view only with Increment Management Type Auto.
  • The embryo loader exists only when Use Embryo Loader is true on the relationship. It runs before the loader.
  • The result view exists only with Create Result Views; without it, Persist Validity must be true.
  • 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 a Link_HK of zeros. The result view hides it.

With the default settings, a load runs this chain:

Raw Vault _Result views -> _Source -> _Hashing -> _Delta
_Delta -> _Loader -> BDV_LSAT_load_blsat -> _Result
_Result -> _Delta (current versions)

The source view reads the result views of its sources. The delta view keeps the rows whose Link_HK and BG_RowHash do not match a current version in the result view. The loader inserts them with the load timestamp as BG_ValidFromTimestamp. The optional objects sit in the same places as in a Business Satellite: _Deduplication and _Versioning before _Hashing, _HashingTable or _RowCondensing after it, and _Increment filters _Source.

Example

The Business Link Satellite load_blsat on Microsoft SQL Server reads the Current View based_on_hub_with_pit_rcv, which shows the current data of each customer. It has a relationship to the Link single_customer_hub_lnk, whose only relationship is to the customer Hub. Its descriptive terms include CUSTOMER and ZIP_CODE. Persist Validity is false. The Raw Vault and then the Business Link Satellite load four times:

  • Load 1 on 2026-10-28 08:00: customer 1 Contoso Ltd with ZIP code 8001 and customer 2 Fabrikam AG with ZIP code 10117.
  • Load 2 on 2026-10-29 08:00: customer 1 is renamed to Contoso Group, and customer 3 Northwind with ZIP code 1010 is new.
  • Load 3 on 2026-10-30 08:00: customer 1 moves to ZIP code 8005.
  • Load 4 on 2026-10-31 08:00: no change.

Check the result

Query the result view with the foreign key of the Link, here in the schemas p3b and p3:

SELECT l.FK_load_customer_hub_CUSTOMER_CUSTOMER_ID AS CUSTOMER_ID,
       s.CUSTOMER, s.ZIP_CODE,
       s.BG_ValidFromTimestamp, s.BG_ValidToTimestamp
FROM p3b.BDV_LSAT_load_blsat_Result AS s
JOIN p3.RDV_LNK_single_customer_hub_lnk_Result AS l
  ON l.Link_HK = s.Link_HK
ORDER BY CUSTOMER_ID, s.BG_ValidFromTimestamp;

This is the result after load 4, with the column names shortened:

CUSTOMER_ID  CUSTOMER       ZIP_CODE  ValidFrom         ValidTo
1            Contoso Ltd    8001      2026-10-28 08:00  2026-10-29 08:00
1            Contoso Group  8001      2026-10-29 08:00  2026-10-30 08:00
1            Contoso Group  8005      2026-10-30 08:00  9999-12-31 00:00
2            Fabrikam AG    10117     2026-10-28 08:00  9999-12-31 00:00
3            Northwind      1010      2026-10-29 08:00  9999-12-31 00:00
  • Each change of customer 1 in the Current View started a new version and ended the previous one.
  • Load 4 inserted no row.

Platform differences

  • Persist Validity is true by default on Snowflake, Snowflake dbt, Databricks, Databricks dbt, Fabric Lakehouse and Fabric Warehouse, and false on Microsoft SQL Server and Oracle.
  • Snowflake: names are in capitals, and the loader is a stored procedure. The load control task LC_BDV_LSAT_<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_LSAT_<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 Link Satellite becomes the dbt models bdv_lsat_<model object name>_source and bdv_lsat_<model object name>. The model bdv_lsat_<model object name>_result exists only when Create Result Views is true; the default on dbt is false. Load Caching, Increment Management Type 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. Hash Group Size splits the input of BG_RowHash into groups of terms. 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 Business Link Satellite has exactly one relationship, to a Link or Business Link. Business keys on a Business Link Satellite raise a validation warning.
  • With a Version Valid From Term, a Business Link Satellite allows one dataflow, one dataflow set and no aggregation.
  • A dataflow delivers at most one row per Link row and load. Two rows with different values for a new Link row make the loader fail with a primary key violation.

Release differences

  • Generator 2.2: Increment Management Type, Use Embryo Loader and Persist Validity are available.
  • Generator 2.3: Custom Singleton Values is available, and Hash Group Size on Oracle.
  • Generator 2.4: Excluded from Delta Detection is available.

Related articles