Business Satellite

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

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

Sources and relationships

A Business 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 Hub or Business Hub, and its foreign-key terms must be mapped. Business PIT, Business Current View, Business History View and Vault Out can read it.

Create the model object

• With the wizard: open the menu of a Raw Vault Hub, Link or satellite, or of a BusinessVault Composite. Choose Automate and then Create Business 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 Business Satellite in the Business Vault layer, add a relationship to the Hub or Business Hub, create a dataflow set, add the source model object and map the foreign-key terms and the descriptive terms.

Historization

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

• The row hash covers the descriptive terms. Business keys, foreign keys, Default Terms and the terms listed in Excluded from Delta Detection are not part of it. See BG_RowHash.
• With Persist Validity false, the result view calculates BG_ValidToTimestamp from the next version. With true, the table stores it and the loader closes the previous version.
• With a Version Valid From Term, the Business Satellite loads the versions that the source delivers, for example from a History View. See Configure a multi-version load.

See Change detection and historization.

Properties

• 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.
• Custom Singleton Values: values of the unknown-member row.
• Excluded from Delta Detection: terms that are stored but do not start a new version.
• Version Valid From Term, per dataflow model object.
• Deduplication Method and Sort Order within Partition, per dataflow.
• Use Embryo Loader, on the relationship: inserts keys that the Hub or Business 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_ValidFromTimestamp: start of the version. With Hub_HK it forms the primary key.
• BG_ValidToTimestamp: end of the version; a table column only with Persist Validity.
• BG_RowHash: hash of the descriptive terms, compared with the current version.
• BG_LoadTimestamp and BG_SourceSystem: the load that inserted the row and its source system, empty unless you map it.
• BG_IncrementalFilter: source term for an incremental load; not stored in the table.
• 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 a Business Satellite with one dataflow. <model object name> stands for the name of the model object:

• Loaders are stored procedures; the Business 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 Hub_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_SAT_<model object name> -> _Result
_Result -> _Delta (current versions)

The source view reads the result views of its sources. The delta view keeps the 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. With a Version Valid From Term, _Versioning and _RowCondensing prepare the source versions, and the loader takes BG_ValidFromTimestamp from the source. _Deduplication sits before _Hashing, _HashingTable after it, and _Increment filters _Source.

Example

The Business Satellite mvl_with_multiple_historized_dataflowset_objects on Microsoft SQL Server has a relationship to the Hub load_customer_hub. It reads the History View based_on_customer_hub_with_pit_rhv of the customers, joined with the Satellite common_customer. Its Version Valid From Term is the BG_ValidFromTimestamp of the History View, and its dataflow uses Deduplication Method Partition. Persist Validity is false.

The Raw Vault was loaded four times, from 2026-10-28 to 2026-10-31 at 08:00. Customer 1 was renamed from Contoso Ltd to Contoso Group in load 2 and moved to ZIP code 8005 in load 3. Customer 3 arrived in load 2. The Business Satellite then loads twice:

• First load on 2026-10-31 09:00, with an empty table.
• Second load on 2026-10-31 10:00, with no change in the Raw Vault.

Check the result

Query the result view with the business key from the Hub, here in the schemas p3b and p3:

SELECT h.CUSTOMER_ID, s.CUSTOMER, s.ZIP_CODE,
       s.BG_ValidFromTimestamp, s.BG_ValidToTimestamp,
       s.BG_LoadTimestamp
FROM p3b.BDV_SAT_mvl_with_multiple_historized_dataflowset_objects_Result
  AS s
JOIN p3.RDV_HUB_load_customer_hub_Result AS h ON h.Hub_HK = s.Hub_HK
ORDER BY h.CUSTOMER_ID, s.BG_ValidFromTimestamp;

This is the result after the second load, split into two blocks with the column names shortened:

CUSTOMER_ID  CUSTOMER       ZIP_CODE  ValidFrom
1            Contoso Ltd    8001      2026-10-28 08:00
1            Contoso Group  8001      2026-10-29 08:00
1            Contoso Group  8005      2026-10-30 08:00
2            Fabrikam AG    10117     2026-10-28 08:00
3            Northwind      1010      2026-10-29 08:00

CUSTOMER_ID  ValidFrom         ValidTo           BG_LoadTimestamp
1            2026-10-28 08:00  2026-10-29 08:00  2026-10-31 09:00
1            2026-10-29 08:00  2026-10-30 08:00  2026-10-31 09:00
1            2026-10-30 08:00  9999-12-31 00:00  2026-10-31 09:00
2            2026-10-28 08:00  9999-12-31 00:00  2026-10-31 09:00
3            2026-10-29 08:00  9999-12-31 00:00  2026-10-31 09:00

• The first load inserted all five versions of the History View at once. Each version keeps the start from the History View; BG_LoadTimestamp shows the Business Vault load.
• The second load 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_SAT_<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_SAT_<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 Satellite becomes the dbt models bdv_sat_<model object name>_source and bdv_sat_<model object name>. The model bdv_sat_<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 Satellite has exactly one relationship, to a Hub or Business Hub. Business keys on a Business Satellite raise a validation warning.
• With a Version Valid From Term, a Business Satellite allows one dataflow, one dataflow set and no aggregation.
• A dataflow delivers at most one row per Hub key and load. Two rows with different values for a new key 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

• Previous: Business Hub, Hub, History View
• Next: Business PIT, Configure a multi-version load
• Reference: BG_RowHash, BG_ValidFromTimestamp, BG_ValidToTimestamp, Excluded from Delta Detection (Model Object), Version Valid From Term (Dataflow 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