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

Effectivity Business Link Satellite

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

An Effectivity Business Link Satellite stores the effectivity begin and end of Link or Business Link rows, read from the Raw Vault, with their history. Use it when a business rule takes or derives the periods in which relationships are in effect, for example the period in which a loyalty card belongs to a customer. After each load, the result view shows every version of these dates with its technical validity.

An Effectivity Business Link Satellite works like an Effectivity Link Satellite, not like a Business Link Satellite. It differs from the Raw Vault type in its sources, its layer, its relationship targets and the BDV_ prefix of its objects.

Sources and relationships

An Effectivity 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. It has exactly one relationship to a Link or Business Link. Its foreign-key terms are the business keys of the Link's Hubs, and they must be mapped. Instead of descriptive terms it carries the Default Terms BG_Effectivity_Begin and BG_Effectivity_End. Business Current View, Business History View and Vault Out can read it.

Create the model object

After either way, map BG_Effectivity_Begin to the source term with the start date, and BG_Effectivity_End to the source term with the end date.

Historization

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

Calculate Effectivity End From Begin decides which BG_Effectivity_End the result view shows when BG_Effectivity_End is mapped:

  • false (default): the end that the source delivered.
  • true: the BG_Effectivity_Begin of the next row of the same Link_HK, ordered by BG_Effectivity_Begin, and End of Universe for the last row. Validation reports warning ID-20004, because the mapped end is overwritten in the result view. See BG_Effectivity_End.

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 Effectivity Business Link Satellite load_incremental_belsat with one dataflow:

RoleGenerated namePurpose
IncrementSourceBDV_ELSAT_load_incremental_belsat_IncrementSourceFinds the new increment
IncrementBDV_ELSAT_load_incremental_belsat_IncrementStores the increments
SourceBDV_ELSAT_load_incremental_belsat_SourceReads the sources
DeduplicationBDV_ELSAT_load_incremental_belsat_DeduplicationRemoves duplicate rows
HashingBDV_ELSAT_load_incremental_belsat_HashingCalculates the hash keys
HashingStorageBDV_ELSAT_load_incremental_belsat_HashingTableStores the hashed rows
HashingLoaderBDV_ELSAT_load_incremental_belsat_HashingLoaderFills the hashing table
EmbryoLoaderBDV_ELSAT_load_incremental_belsat_EmbryoLoaderAdds missing Link keys
DeltaBDV_ELSAT_load_incremental_belsat_DeltaSelects new versions
LoaderBDV_ELSAT_load_incremental_belsat_LoaderInserts the new versions
StorageBDV_ELSAT_load_incremental_belsatEffectivity Business Link Satellite table
ResultBDV_ELSAT_load_incremental_belsat_ResultQuery view with validity
  • Loaders are stored procedures; the satellite table, the hashing table and the increment table are tables; all other objects are views.
  • 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 deduplication view exists only with a Deduplication Method other than None.
  • The hashing table and hashing loader exist only with Load Caching Hashing.
  • 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 has no unknown-member row.

The example object loads incrementally, so a load runs this chain:

_IncrementSource -> _Loader -> _Increment (new increment)
Raw Vault _Result views + _Increment -> _Source -> _Hashing
_Hashing -> _Delta -> _Loader -> BDV_ELSAT_load_incremental_belsat
BDV_ELSAT_load_incremental_belsat -> _Result
_Result -> _Delta (current versions)

The loader first stores the new increment, the highest BG_IncrementalFilter of the source. The source view reads the rows between the previous and the new increment from the result views of its sources. The delta view keeps the rows whose Link_HK and BG_RowHash do not match a current version, and the loader inserts them with the load timestamp as BG_ValidFromTimestamp. Without an incremental load, the chain starts at _Source.

Example

The Effectivity Business Link Satellite load_incremental_belsat on Microsoft SQL Server has a relationship to the Link common_loyaltycard_customer between loyalty cards and customers. It reads the Effectivity Link Satellite load_loyaltycard_elsat of the Raw Vault, joined with that Link, and maps both effectivity terms from it. BG_IncrementalFilter is mapped to the BG_LoadTimestamp of load_loyaltycard_elsat, with Increment Management Type Auto. Calculate Effectivity End From Begin and Persist Validity are false. The Raw Vault and then the Business Vault load four times:

  • Load 1 on 2026-10-28 08:00: card 501 of customer 1 and card 502 of customer 2, both valid from 2026-01-01 to 2026-12-31.
  • Load 2 on 2026-10-29 08:00: card 503 of the new customer 3, valid from 2026-10-29 to 2027-10-28.
  • Load 3 on 2026-10-30 08:00: card 501 is renewed from 2027-01-01 to 2027-12-31, and card 502 ends on 2026-10-30.
  • Load 4 on 2026-10-31 08:00: no change.

Check the result

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

SELECT l.FK_common_loyaltycard_LOYALTYCARD_LOYALTYCARD_ID AS CARD,
       l.FK_load_customer_hub_CUSTOMER_CUSTOMER_ID AS CUSTOMER,
       s.BG_Effectivity_Begin, s.BG_Effectivity_End,
       s.BG_ValidFromTimestamp, s.BG_ValidToTimestamp
FROM p3b.BDV_ELSAT_load_incremental_belsat_Result AS s
JOIN p3.RDV_LNK_common_loyaltycard_customer_Result AS l
  ON l.Link_HK = s.Link_HK
ORDER BY CARD, s.BG_ValidFromTimestamp;

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

CARD  CUSTOMER  Begin       End         ValidFrom         ValidTo
501   1         2026-01-01  2026-12-31  2026-10-28 08:00  2026-10-30 08:00
501   1         2027-01-01  2027-12-31  2026-10-30 08:00  9999-12-31 00:00
502   2         2026-01-01  2026-12-31  2026-10-28 08:00  2026-10-30 08:00
502   2         2026-01-01  2026-10-30  2026-10-30 08:00  9999-12-31 00:00
503   3         2026-10-29  2027-10-28  2026-10-29 08:00  9999-12-31 00:00
  • Load 3 changed the dates of the Link rows of cards 501 and 502. Each got a second version, and the first one ended at the load timestamp.
  • Each load read only the rows that the Effectivity Link Satellite had stored since the previous increment. Load 4 found none and 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. With true, the table stores BG_ValidToTimestamp.
  • The data types of the effectivity terms differ per platform, see BG_Effectivity_Begin.
  • Snowflake: names are in capitals, and the loader is a stored procedure. The load control task LC_BDV_ELSAT_<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_ELSAT_<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 satellite becomes the dbt models bdv_elsat_<model object name>_source and bdv_elsat_<model object name>. The model bdv_elsat_<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. 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

  • An Effectivity Business Link Satellite has exactly one relationship, to a Link or Business Link.
  • An unmapped BG_Effectivity_Begin raises a validation error.
  • A term other than the Default Terms, business keys and foreign keys raises a validation error. Business keys raise a validation warning.
  • Custom Singleton Values, Version Valid From Term and Hash Group Size are not available.

Release differences

  • Generator 2.2: Increment Management Type, Use Embryo Loader and Persist Validity are available.
  • Generator 2.4: Excluded from Delta Detection is available.

Related articles