Multi-Active Satellite
Applies to
Platform: Microsoft SQL Server · Snowflake · Snowflake dbt · Databricks · Databricks dbt · Fabric Lakehouse · Fabric Warehouse · Oracle
Architecture: Data Vault
A Multi-Active Satellite stores several active rows per business key of a Hub, told apart by BG_Sequence, and their history in a table of the Raw Vault layer. Use it when a key has a set of equal-ranking values at the same time, such as the phone numbers of an employee. After each load, the result view shows every version of each key's set with its validity.
Sources and relationships
A Multi-Active 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. Vault Out and the Business Vault types can read it; Current View, History View, PIT and BusinessVault Composite do not accept it as a source.
Create a Multi-Active Satellite
- With the wizard: open the menu of a Stage, RawVault Composite or Store Entity, choose Automate and then Create Multi-Active Satellite. Its steps are Create Model Object, Create Dataflow, Create Relations, Map Foreign Key Terms, Map Selected Terms and Add to View. See Create a Model Object with the wizard.
- Manually: create a model object of type Multi-Active Satellite in the Raw Vault layer, add a relationship to the Hub, create a dataflow set, add the source model object and map the terms.
In both cases, map BG_Sequence to a source term that identifies the row within the set, for example a phone number ID or a ROW_NUMBER() expression. Validation reports an error when it is not mapped.
Historization
The loader compares the whole set of a key with the current set. When any row of the set is new, changed or missing, the loader inserts all rows that the source delivers for that key as a new version. The new set starts at the load timestamp and the previous set ends there, all its rows at once. An unchanged set adds no version, and the loader never deletes or updates rows.
- The row hash
BG_RowHashof each row covers the descriptive terms.BG_Sequence, foreign keys, Default Terms and the terms listed in Excluded from Delta Detection are not part of it. - The internal term
BG_MAS_HubDifferenceFoundmarks the keys whose set differs. - With Persist Validity
false, the result view calculatesBG_ValidToTimestampfor the whole set; withtrue, the table stores it.
Properties
- Implementation Type:
Permanentonly. - 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) orUser, for an incremental load withBG_IncrementalFilter. See Configure an incremental load. - Custom Singleton Values: values of the unknown-member row.
- 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 Hub keys that the Hub does not hold yet.
The project properties Persist Validity and Create Result Views also apply. Version Valid From Term is not available.
Default Terms
Hub_HK: the key of the Hub row, calculated from the foreign-key terms.BG_Sequence: identifies the row within the set. WithHub_HKandBG_ValidFromTimestampit forms the primary key.BG_ValidFromTimestampandBG_ValidToTimestamp: start and end of the set's version.BG_RowHash: hash of the descriptive terms of the row.BG_IncrementalFilter: source term for an incremental load; not stored in the table.BG_LoadTimestampandBG_SourceSystem: the load that inserted the row and its source system, empty unless you map it.BG_MAS_HubDifferenceFound: internal, hidden in source and target.BG_DataQuality_ID,BG_ErrorCountandBG_ErrorDescription: hidden terms of the data quality objects.
Generated objects
These are the names on Microsoft SQL Server for the Multi-Active Satellite load_mas with one dataflow:
| Role | Generated name | Purpose |
|---|---|---|
| Source | RDV_MAS_load_mas_Source | Reads the sources |
| Deduplication | RDV_MAS_load_mas_Deduplication | Removes duplicate rows |
| Hashing | RDV_MAS_load_mas_Hashing | Calculates the hash keys |
| HashingStorage | RDV_MAS_load_mas_HashingTable | Stores the hashed rows |
| HashingLoader | RDV_MAS_load_mas_HashingLoader | Fills the hashing table |
| IncrementSource | RDV_MAS_load_mas_IncrementSource | Finds the new increment |
| Increment | RDV_MAS_load_mas_Increment | Stores the increments |
| EmbryoLoader | RDV_MAS_load_mas_EmbryoLoader | Adds missing Hub keys |
| Delta | RDV_MAS_load_mas_Delta | Selects changed sets |
| Loader | RDV_MAS_load_mas_Loader | Inserts the new sets |
| Storage | RDV_MAS_load_mas | Multi-Active Satellite table |
| Result | RDV_MAS_load_mas_Result | Query view with validity |
- Loaders are stored procedures; the Multi-Active 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 TypeAuto. - 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
Hub_HKof zeros andBG_Sequence0. The result view hides it. - There are no versioning or row-condensing views.
With the default settings, a load runs this chain:
sources -> _Source -> _Hashing -> _Delta -> _Loader _Loader -> RDV_MAS_load_mas -> _Result _Result -> _Delta (current sets)
The delta view joins the source rows with the current set of each key by BG_Sequence. When any row hash differs or a sequence exists on one side only, it marks the key and keeps all source rows of that key. The loader inserts them with the load timestamp as BG_ValidFromTimestamp. With the optional objects, _Deduplication sits before _Hashing, _HashingTable after it, and _Increment filters _Source.
Example
The Multi-Active Satellite load_mas on Microsoft SQL Server reads the Stage PHONENUMBER, filtered on employee phone numbers. It has a relationship to the Hub common_employee, and BG_Sequence is mapped to PHONENUMBER_ID. Persist Validity is false. The loads deliver these numbers:
- Load 1 on 2026-10-28 08:00: employee 101 has the mobile number 1 (+41 79 111 11 11) and the office number 2 (+41 44 222 22 22); employee 102 has the mobile number 3 (+49 151 333 33 33).
- Load 2 on 2026-10-29 08:00: the office number 2 of employee 101 changes to +41 44 222 22 99.
- Load 3 on 2026-10-30 08:00: number 2 of employee 101 is no longer delivered.
Check the result
Query the result view with the business key from the Hub, here in the schema rv:
SELECT h.EMPLOYEE_ID, m.BG_Sequence, m.PHONE_NUMBER,
m.BG_ValidFromTimestamp, m.BG_ValidToTimestamp
FROM rv.RDV_MAS_load_mas_Result AS m
JOIN rv.RDV_HUB_common_employee_Result AS h ON h.Hub_HK = m.Hub_HK
ORDER BY h.EMPLOYEE_ID, m.BG_ValidFromTimestamp, m.BG_Sequence;
This is the result after load 3, split into two blocks with the column names shortened:
EMPLOYEE_ID SEQ PHONE_NUMBER ValidFrom 101 1 +41 79 111 11 11 2026-10-28 08:00 101 2 +41 44 222 22 22 2026-10-28 08:00 101 1 +41 79 111 11 11 2026-10-29 08:00 101 2 +41 44 222 22 99 2026-10-29 08:00 101 1 +41 79 111 11 11 2026-10-30 08:00 102 3 +49 151 333 33 33 2026-10-28 08:00
EMPLOYEE_ID SEQ ValidFrom ValidTo 101 1 2026-10-28 08:00 2026-10-29 08:00 101 2 2026-10-28 08:00 2026-10-29 08:00 101 1 2026-10-29 08:00 2026-10-30 08:00 101 2 2026-10-29 08:00 2026-10-30 08:00 101 1 2026-10-30 08:00 9999-12-31 00:00 102 3 2026-10-28 08:00 9999-12-31 00:00
- Load 2 changed one number of employee 101 and inserted the whole set again, also the unchanged mobile number 1.
- Load 3 dropped number 2; the new set holds only number 1, and the set of load 2 ended at load 3.
- Employee 102 kept the set of load 1.
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_RDV_MAS_<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
RDV_MAS_<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 Multi-Active Satellite becomes the dbt models
rdv_mas_<model object name>_sourceandrdv_mas_<model object name>. The modelrdv_mas_<model object name>_resultexists 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_RowHashinto groups of terms that are hashed separately. Partition Clause adds its text to theCREATE 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 Multi-Active Satellite has exactly one relationship to a Hub, and
BG_Sequencemust be mapped. Business keys raise a validation warning. - Multi-version loading is not available.
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: a new, changed or missing sequence replaces the whole set of the key, and the previous set ends as a whole. Excluded from Delta Detection is available.
Related articles
- Previous: Hub
- Reference: BG_Sequence, BG_MAS_HubDifferenceFound, BG_RowHash, Excluded from Delta Detection (Model Object), Persist Validity (Project), Create Result Views (Project), Custom Singleton Values (Model Object), Hash Group Size (Model Object), Foreign Key Mode (Model Object)
- See also: Satellite, Change detection and historization, Embryo Loader, Create a Model Object with the wizard