Non-Historized Satellite

A Non-Historized Satellite stores the descriptive data of each Hub key once, without row hash and validity, in a table of the Raw Vault layer. Use it for data that does not change after it arrives, such as the details of a sales transaction. After each load, the result view shows one row per loaded Hub key with the load that inserted it.

A Non-Historized Satellite works like a Non-Historized Link Satellite, but it belongs to a Hub instead of a Link. Available since Generator 2.4.

Sources and relationships

A Non-Historized Satellite reads Stages and 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. BusinessVault Composite, Vault Out and the Business Vault types can read it; Current View, History View and PIT do not accept it.

Create the model object

• With the wizard: open the menu of a Stage, RawVault Composite or Store Entity, choose Automate and then Create Non-Historized 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 Non-Historized 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 and the descriptive terms.

Loading behavior

The Non-Historized Satellite loads each Hub key once. Later rows for the same Hub key are not loaded, even when their values differ. The loader only inserts rows; it never updates or deletes them. With an incremental load, a row whose BG_IncrementalFilter is not above the stored increment is not read, in this or a later load.

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.
• 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.

Persist Validity and Version Valid From Term do not apply.

Default Terms

• Hub_HK: the key of the Hub row, calculated from the foreign-key terms, and primary key of the table.
• BG_LoadTimestamp: the load that inserted the row.
• BG_SourceSystem: the 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.

There is no BG_RowHash, BG_ValidFromTimestamp or BG_ValidToTimestamp.

Generated objects

These are the names on Microsoft SQL Server for the Non-Historized Satellite load_nsat with one dataflow:

• Loaders are stored procedures; the satellite table, the increment table and the hashing 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.
• With several dataflows, all objects except the table, the result view and the increment table exist once per dataflow, with the dataflow name in their names.

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

_IncrementSource -> _Loader -> _Increment (new increment)
sources + _Increment -> _Source -> _Hashing -> _Delta
_Delta -> _Loader -> RDV_NHSAT_load_nsat -> _Result
_Result -> _Delta (Hub keys already stored)

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. The delta view keeps the rows whose Hub_HK is not in the result view, and the loader inserts them. Without an incremental load, the chain starts at _Source.

Example

The Non-Historized Satellite load_nsat on Microsoft SQL Server reads the Stage SALESTRANSACTION. It has a relationship to the Hub common_salestransaction, whose business keys are TRANSACTION_ID and TRANSACTION_LINE_NO. BG_IncrementalFilter is mapped to TRANSACTION_TIME, with Increment Management Type Auto. QUANTITY and TRANSACTION_TIME are mapped as descriptive terms. The loads deliver these transaction lines:

• Load 1 on 2026-11-09 08:00: transaction 1001, line 1 with quantity 2 and line 2 with quantity 1, both with transaction time 2026-11-09 07:00.
• Load 2 on 2026-11-10 08:00: 1001 line 1 again, now with quantity 3 and transaction time 2026-11-10 07:00. The new transaction 1002 arrives with line 1, quantity 4 and transaction time 2026-11-10 07:30.
• Load 3 on 2026-11-11 08:00: the rows of load 2 again, and the new transaction 1003 with line 1, quantity 1 and transaction time 2026-11-09 06:00.

Check the result

Query the result view with the business keys of the Hub, here in the schema rawvault:

SELECT h.TRANSACTION_ID, h.TRANSACTION_LINE_NO AS LINE_NO,
       s.QUANTITY, s.TRANSACTION_TIME AS TX_TIME,
       s.BG_LoadTimestamp
FROM rawvault.RDV_NHSAT_load_nsat_Result AS s
JOIN rawvault.RDV_HUB_common_salestransaction_Result AS h
  ON h.Hub_HK = s.Hub_HK
ORDER BY h.TRANSACTION_ID, h.TRANSACTION_LINE_NO;

This is the result after load 3:

TRANSACTION_ID  LINE_NO  QUANTITY  TX_TIME           BG_LoadTimestamp
1001            1        2.000     2026-11-09 07:00  2026-11-09 08:00
1001            2        1.000     2026-11-09 07:00  2026-11-09 08:00
1002            1        4.000     2026-11-10 07:30  2026-11-10 08:00

• 1001 line 1 keeps quantity 2 from load 1. Its row from load 2 was read, but its Hub key was already stored.
• 1002 line 1 is a new Hub key and was loaded in load 2.
• Load 3 inserted no row. No transaction time of load 3 lies above the stored increment 2026-11-10 07:30, so the source view reads none of its rows.

Platform differences

• Snowflake: names are in capitals, and the loader is a stored procedure. The load control task LC_RDV_NHSAT_<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 RDV_NHSAT_<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 rdv_nhsat_<model object name>_source and rdv_nhsat_<model object name>. The second model is the table and inserts only Hub keys that it does not hold yet. The model rdv_nhsat_<model object name>_result is generated 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

• A Non-Historized Satellite has exactly one relationship to a Hub. Business keys raise a validation warning.
• Corrections of an already loaded Hub key do not reach the table. A Satellite stores changing data with its history.
• On Microsoft SQL Server, a dataflow that delivers the same Hub key twice in one load makes the loader fail with a primary key violation.

Related articles

• Previous: Hub
• Next: Configure an incremental load
• Reference: Hub_HK, BG_IncrementalFilter, Foreign Key Mode (Model Object), Load Caching (Model Object)
• See also: Satellite, Non-Historized Link Satellite, Non-Historized Business Satellite, Embryo Loader, Create a Model Object with the wizard