Effectivity Satellite

An Effectivity Satellite stores the begin and end of the effectivity of a Hub's business keys, as the source delivers them, with their history. Use it when the source states from when to when a business object is in effect, for example the validity period of a loyalty card. After each load, the result view shows every version of these dates with its technical validity.

Sources and relationships

An Effectivity Satellite reads Stages, RawVault Composites and Store Entities of a linked Data Store project, in one or more dataflows. It has exactly one relationship to a Hub, and its foreign-key terms must be mapped. Instead of descriptive terms it carries the Default Terms BG_Effectivity_Begin and BG_Effectivity_End. Current View, History View, their Business Vault counterparts, BusinessVault Composite, Vault Out and the Business Vault types can read it. A PIT does not reference it.

Create the model object

• With the wizard: open the menu of a Stage, RawVault Composite or Store Entity, choose Automate and then Create Effectivity Satellite. Its steps are Create Model Object, Create Dataflow, Create Relations, Map Foreign Key Terms and Add to View. See Create a Model Object with the wizard.
• Manually: create a model object of type Effectivity Satellite in the Raw Vault layer, add a relationship to the Hub, create a dataflow set, add the source model object and map the foreign-key terms.

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 Hub key 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:

• false (default): the end that the source delivered.
• true, with BG_Effectivity_End mapped: the BG_Effectivity_Begin of the next row of the same Hub key, ordered by BG_Effectivity_Begin, and End of Universe for the last row. The calculated end replaces the mapped one, and validation reports warning ID-20004. See BG_Effectivity_End.

Properties

• Calculate Effectivity End From Begin: false (default) or true, see Historization.
• Implementation Type: Permanent only.
• Foreign Key Mode: whether the table gets a foreign key to the Hub table. With Create Disabled, the default, it is created and disabled.
• Load Caching: empty (default) or Hashing, which stores the hashing view in a table before the loader runs.
• Increment Management Type: Auto (default) or User, for an incremental load with BG_IncrementalFilter. See Configure an incremental load.
• Excluded from Delta Detection: terms that are stored but do not start a new version.
• Deduplication Method and Sort Order within Partition, per dataflow.
• Use Embryo Loader, on the relationship: inserts the Hub keys that the Hub does not hold yet.

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

Default Terms

• Hub_HK: the key of the Hub row, calculated from the foreign-key terms.
• BG_Effectivity_Begin and BG_Effectivity_End: the begin and end of the effectivity.
• BG_ValidFromTimestamp: start of the version. With Hub_HK it forms the primary key.
• BG_ValidToTimestamp: end of the version.
• BG_RowHash: hash of the effectivity terms, compared with the current version.
• BG_IncrementalFilter: source term for an incremental load; not stored in the table.
• 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.

Generated objects

These are the names on Microsoft SQL Server for an Effectivity Satellite with one dataflow. <model object name> stands for the name of the model object:

• Loaders are stored procedures; the Effectivity 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 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 has no unknown-member row.

With the default settings, a load runs this chain:

sources -> _Source -> _Hashing -> _Delta -> _Loader
_Loader -> RDV_ESAT_<model object name> -> _Result
_Result -> _Delta (current versions)

The delta view keeps the source rows whose Hub_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. _Deduplication sits between _Source and _Hashing, _HashingTable after _Hashing, and _Increment filters _Source.

Example

The Effectivity Satellite load_loyaltycard_esat on Microsoft SQL Server reads the Stage LOYALTYCARD and has a relationship to the Hub common_loyaltycard. It maps BG_Effectivity_Begin to VALID_FROM and BG_Effectivity_End to VALID_TO. Calculate Effectivity End From Begin and Persist Validity are false. The loads deliver these cards:

• Load 1 on 2026-10-28 08:00: cards 501 and 502, both valid from 2026-01-01 to 2026-12-31.
• Load 2 on 2026-10-29 08:00: the same, and the new card 503, 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: the same rows as load 3.

Check the result

Query the result view with the business key of the Hub, here in the schema p2:

SELECT h.LOYALTYCARD_ID,
       s.BG_Effectivity_Begin, s.BG_Effectivity_End,
       s.BG_ValidFromTimestamp, s.BG_ValidToTimestamp
FROM p2.RDV_ESAT_load_loyaltycard_esat_Result AS s
JOIN p2.RDV_HUB_common_loyaltycard_Result AS h
  ON h.Hub_HK = s.Hub_HK
ORDER BY h.LOYALTYCARD_ID, s.BG_ValidFromTimestamp;

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

CARD  Begin       End         ValidFrom         ValidTo
501   2026-01-01  2026-12-31  2026-10-28 08:00  2026-10-30 08:00
501   2027-01-01  2027-12-31  2026-10-30 08:00  9999-12-31 00:00
502   2026-01-01  2026-12-31  2026-10-28 08:00  2026-10-30 08:00
502   2026-01-01  2026-10-30  2026-10-30 08:00  9999-12-31 00:00
503   2026-10-29  2027-10-28  2026-10-29 08:00  9999-12-31 00:00

• Load 3 changed the dates of cards 501 and 502. Each got a second version, and the first one ended at the load timestamp.
• Loads 2 and 4 added no version for unchanged cards.

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. A load control 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_ESAT_<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 Effectivity Satellite becomes the dbt models rdv_esat_<model object name>_source and rdv_esat_<model object name>. The model rdv_esat_<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 Satellite has exactly one relationship, to a Hub.
• 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

• Previous: Hub
• Next: Configure an incremental load
• Reference: BG_Effectivity_Begin, BG_Effectivity_End, Calculate Effectivity End From Begin (Model Object), Hub_HK, BG_RowHash, Persist Validity (Project), Create Result Views (Project), Excluded from Delta Detection (Model Object), Foreign Key Mode (Model Object)
• See also: Effectivity Link Satellite, Satellite, Change detection and historization, Embryo Loader, Create a Model Object with the wizard