Record Tracking Business Link Satellite

A Record Tracking Business Link Satellite records in which loads the rows of a Link or Business Link appeared in its source, in a Business Vault table. Use it to track a set of relationships that a business rule selects, for example the loyalty cards that are in effect, and to see in which loads a relationship was missing. After each load, the result view shows one row per Link row and load with its BG_Appearance value.

A Record Tracking Business Link Satellite works like a Record Tracking 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

A Record Tracking 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. 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 Record Tracking Business Link 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 Record Tracking Business Link Satellite in the Business Vault layer, add a relationship to the Link or Business Link, create a dataflow set, add the source model object and map the foreign-key terms.

You do not map BG_Appearance. The source view sets it to 1 for every Link row that the source delivers. The dataflow's filter decides which Link rows count as delivered.

Loading behavior

Every load inserts one row for each Link row that the source delivers, with the load timestamp as BG_ValidFromTimestamp and BG_Appearance 1. A row is valid until the next row of the same Link_HK. Delete Detection Method decides what happens to a Link row that the source does not deliver:

• FullSet (default): the delta view compares the source rows with the rows of the latest load in the table, by Link_HK. A Link row of that load that is missing from the source gets a row with BG_Appearance 0. It gets such a row in every load until the source delivers it again.
• None: there is no delta view. The loader inserts the delivered Link rows only, so a missing Link row gets no row.

Properties

• Delete Detection Method: FullSet (default) or None, see Loading behavior.
• Implementation Type: Permanent only.
• Foreign Key Mode: whether the table gets a foreign key to the Link 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.
• Deduplication Method and Sort Order within Partition, per dataflow.
• Use Embryo Loader, on the relationship: inserts the Link keys that the Link or Business Link does not hold yet.

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

Default Terms

• Link_HK: the key of the Link row, calculated from the foreign-key terms. With BG_ValidFromTimestamp it forms the primary key.
• BG_Appearance: 1 when the load delivered the Link row, 0 when it was missing.
• BG_ValidFromTimestamp: the load timestamp of the row.
• BG_ValidToTimestamp: the start of the next row of the same Link row.
• BG_LoadTimestamp and BG_SourceSystem: the load that inserted the row and its source system, empty unless you map it.
• DrivingKeyLink_HK: a Default Term of the type. On a Link or Business Link, the table has no such column.
• BG_DataQuality_ID, BG_ErrorCount and BG_ErrorDescription: hidden terms of the data quality objects.

A Record Tracking Business Link Satellite has no BG_RowHash and no BG_IncrementalFilter.

Generated objects

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

• Loaders are stored procedures; the satellite table and the hashing table are tables; all other objects are views.
• The delta view exists only with Delete Detection Method FullSet.
• 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.

With the default settings, a load runs this chain:

Raw Vault _Result views -> _Source -> _Hashing -> _Delta
_Delta -> _Loader -> BDV_RLSAT_load_rtblsat -> _Result
_Result -> _Delta (rows of the latest load)

The source view reads the result views of its sources and sets BG_Appearance to 1. The delta view joins the hashed source rows with the rows of the latest load in the result view, by Link_HK. Delivered Link rows keep BG_Appearance 1, and Link rows found only in the result view get 0. The loader inserts all rows of the delta view with the load timestamp. With None, the loader reads _Hashing directly.

Example

The Record Tracking Business Link Satellite load_rtblsat 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. Its filter keeps the current versions whose BG_Effectivity_End lies after their BG_LoadTimestamp. Its Delete Detection Method is FullSet, and Persist Validity is false. The Raw Vault and then the Business Vault load four times:

• Load 1 on 2026-10-28 08:00: cards 501 and 502 are in effect until 2026-12-31.
• Load 2 on 2026-10-29 08:00: card 503 of customer 3 is new and in effect.
• Load 3 on 2026-10-30 08:00: card 501 is renewed until 2027-12-31. Card 502 now ends on 2026-10-30, before this load, so the filter drops it.
• 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,
       s.BG_Appearance, s.BG_ValidFromTimestamp,
       s.BG_ValidToTimestamp
FROM p3b.BDV_RLSAT_load_rtblsat_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  BG_Appearance  ValidFrom         ValidTo
501   1              2026-10-28 08:00  2026-10-29 08:00
501   1              2026-10-29 08:00  2026-10-30 08:00
501   1              2026-10-30 08:00  2026-10-31 08:00
501   1              2026-10-31 08:00  9999-12-31 00:00
502   1              2026-10-28 08:00  2026-10-29 08:00
502   1              2026-10-29 08:00  2026-10-30 08:00
502   0              2026-10-30 08:00  2026-10-31 08:00
502   0              2026-10-31 08:00  9999-12-31 00:00
503   1              2026-10-29 08:00  2026-10-30 08:00
503   1              2026-10-30 08:00  2026-10-31 08:00
503   1              2026-10-31 08:00  9999-12-31 00:00

• Every load inserted a row for each delivered card, also when nothing changed.
• Card 502 was missing in loads 3 and 4, and each of these loads inserted a row with BG_Appearance 0.

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 type of BG_Appearance differs per platform, see BG_Appearance.
• Snowflake: names are in capitals, and the loader is a stored procedure. The load control task LC_BDV_RLSAT_<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_RLSAT_<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_rlsat_<model object name>_source and bdv_rlsat_<model object name>. The model bdv_rlsat_<model object name>_result exists only when Create Result Views is true; the default on dbt is false. Load Caching 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

• A Record Tracking Business Link Satellite has exactly one relationship, to a Link or Business Link.
• 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 Increment Management Type are not available.

Release differences

• Generator 2.0: Delete Detection Method is available.
• Generator 2.2: Use Embryo Loader and Persist Validity are available.

Related articles

• Previous: Business Link, Link
• Reference: BG_Appearance, Link_HK, Delete Detection Method (Model Object), Persist Validity (Project), Create Result Views (Project), Foreign Key Mode (Model Object), Load Caching (Model Object)
• See also: Record Tracking Link Satellite, Record Tracking Satellite, Embryo Loader, Create a Model Object with the wizard