Data Vault Satellite

Table of Contents

How satellite updates work
Options in the Satellite dialog
Checks that involve satellites
Target table layout for satellites
Tips for satellites
Satellites on multi-source hubs
Parent business keys on the satellite feed

A Satellite stores the descriptive, time-varying attributes that belong to a Hub or a Link. Classic examples are customer name and address details, product descriptions and categories, order status history, etc.

In Data Vault 2.0, satellites are insert-only. When any of the tracked attributes changes for a given parent (hub or link), a new row is inserted with the new values and the current load date. Old rows are kept, giving you a complete history.

How satellite updates work

When data is loaded for a satellite, the generated pipeline:

Reads the parent business keys from this satellite’s record source (so it can compute the parent hash key), plus the satellite attributes and the record source indicator.
Calculates the parent hash key using the same logical business keys defined on the parent hub.
Does not require the satellite feed to be listed as a hub record source. Hub and satellite loads are independent (Data Vault 2.0): only the parent identity columns must be present on the satellite feed (by default with the same names as the hub business keys).
Compares the incoming data against the existing rows in the satellite table.
Detects real changes by comparing the actual attribute values (not just the presence of the parent key).
Inserts only the rows that are new for that parent key or that contain different attribute values.
Adds the batch load date to every inserted row.

Because the comparison looks at the attribute values themselves, you do not get duplicate "no-change" rows in the satellite. This keeps history clean and query performance good.

Options in the Satellite dialog

Option Description

Option	Description
Name	The name of this satellite definition. Used as the default physical table name if you do not specify one.
Physical table name	The actual table name in the target Data Vault database. Leave blank to use the Name.
Description	Business description of the satellite and the kind of information it holds.
Default record source	The Data Vault Source that feeds this satellite. Required.
Store record source indicator	When checked (default), the satellite table includes the model record-source column and load pipelines write the feed’s source indicator into it. Uncheck for VaultSpeed-style mono-source satellites that omit the source-indicator column from the physical table. The catalog feed binding is still required. Hubs and links always store record source.
Parent hub	Select the Hub this satellite describes (for normal hub satellites). Choose either a parent hub or a parent link, not both.
Parent link	Select the Link this satellite describes (for satellites that hold relationship-level attributes). Choose either a parent link or a parent hub, not both.
Parent key source fields (tab)	For hub satellites only: optional ordered list of columns on this satellite’s record source that supply the parent hub hash inputs. Length and order match the hub’s multipartite vault keys or, for composite hub business keys, the ordered source parts (not the composed vault BK column name). Leave empty to default from the hub (vault key names, or hub-mapped parts for the satellite record source when known). This is not a re-definition of hub keys — only where the values sit on this one feed. The satellite table does not store hub business-key text. Link satellites configure parent keys on the link’s source mappings instead. Use Load from hub mapping to fill defaults.
Attributes	The list of descriptive columns whose changes you want to track. Each attribute has: * Column name (in both source and target). * Optional description. * Data type, length, and precision (used for DDL and loading). * "Include in CDC" – normally left checked. Uncheck it for columns that should not trigger a new satellite row when they change (for example audit columns or fields added later that you do not want to version). The Load from source button on the Attributes tab is very useful. It populates the list from the referenced source, automatically excluding primary key fields and any driving key. You can then delete columns you do not want to historize or adjust lengths and the "Include in CDC" flag. If you leave the attributes list empty, the plugin will include all non-key, non-driving-key fields from the source. The model check will warn you about this so you can decide whether it is intentional.
Multi-active satellite	Check this box when more than one active record can exist for the same parent key at the same moment in time. A common example is multiple current phone numbers or email addresses for a customer.
Driving key	Required when Multi-active is checked. This is the additional column that, together with the parent hash key and load date, makes each row unique (for example the phone number type or the email address itself).
Driving key source field	Source column that supplies the driving key value. Renamed to the driving key column in the update pipeline and stored in the target satellite table.
Integration mode (Options tab)	Controls how Hop loads this satellite. Hop managed (default) generates DDL and update pipelines. External read-only skips generation — use when dbt or another tool loads the table; Business Vault still reads history from metadata. Custom pipelines runs your own `.hpl` paths. See Data Vault integration modes.

Name

The name of this satellite definition. Used as the default physical table name if you do not specify one.

Physical table name

The actual table name in the target Data Vault database. Leave blank to use the Name.

Description

Business description of the satellite and the kind of information it holds.

Default record source

The Data Vault Source that feeds this satellite. Required.

Store record source indicator

When checked (default), the satellite table includes the model record-source column and load pipelines write the feed’s source indicator into it. Uncheck for VaultSpeed-style mono-source satellites that omit the source-indicator column from the physical table. The catalog feed binding is still required. Hubs and links always store record source.

Parent hub

Select the Hub this satellite describes (for normal hub satellites). Choose either a parent hub or a parent link, not both.

Parent link

Select the Link this satellite describes (for satellites that hold relationship-level attributes). Choose either a parent link or a parent hub, not both.

Parent key source fields (tab)

For hub satellites only: optional ordered list of columns on this satellite’s record source that supply the parent hub hash inputs. Length and order match the hub’s multipartite vault keys or, for composite hub business keys, the ordered source parts (not the composed vault BK column name). Leave empty to default from the hub (vault key names, or hub-mapped parts for the satellite record source when known). This is not a re-definition of hub keys — only where the values sit on this one feed. The satellite table does not store hub business-key text. Link satellites configure parent keys on the link’s source mappings instead. Use Load from hub mapping to fill defaults.

Attributes

The list of descriptive columns whose changes you want to track.

Each attribute has: * Column name (in both source and target). * Optional description. * Data type, length, and precision (used for DDL and loading). * "Include in CDC" – normally left checked. Uncheck it for columns that should not trigger a new satellite row when they change (for example audit columns or fields added later that you do not want to version).

The Load from source button on the Attributes tab is very useful. It populates the list from the referenced source, automatically excluding primary key fields and any driving key. You can then delete columns you do not want to historize or adjust lengths and the "Include in CDC" flag.

If you leave the attributes list empty, the plugin will include all non-key, non-driving-key fields from the source. The model check will warn you about this so you can decide whether it is intentional.

Multi-active satellite

Check this box when more than one active record can exist for the same parent key at the same moment in time. A common example is multiple current phone numbers or email addresses for a customer.

Driving key

Required when Multi-active is checked. This is the additional column that, together with the parent hash key and load date, makes each row unique (for example the phone number type or the email address itself).

Driving key source field

Source column that supplies the driving key value. Renamed to the driving key column in the update pipeline and stored in the target satellite table.

Integration mode (Options tab)

Controls how Hop loads this satellite. Hop managed (default) generates DDL and update pipelines. External read-only skips generation — use when dbt or another tool loads the table; Business Vault still reads history from metadata. Custom pipelines runs your own .hpl paths. See Data Vault integration modes.

Checks that involve satellites

The Check model button will report problems such as:

The satellite is not attached to any hub or link.
No attributes are defined (and therefore all non-key fields from the source will be used).
One or more attributes have no name.
The referenced parent hub or link does not exist in the model.
Source-to-target type mismatches for explicit attributes, auto-attributes (when the attribute list is empty), and the driving key when multi-active mode is enabled.

Type validation compares each mapped source column to the satellite target column definition. Errors are raised for incompatible types or when the source is wider than the target. Warnings cover stored-metadata drift from the live source schema.

On SQL Server, vault string columns are created as VARCHAR with a UTF-8 collation so Unicode attributes store correctly without NVARCHAR. Model lengths stay character-oriented (e.g. attribute length 50). Generated vault DDL multiplies those lengths by three (VARCHAR(150)) because SQL Server measures UTF-8 VARCHAR(n) in bytes. Model check uses the same capacity rule (effectiveStringCapacity), so a source that reports 50 characters (typical NVARCHAR(50)) or a physical width that still fits in 150 bytes does not fail against model length 50. Catalog/CRM staging CREATE does not apply the vault ×3 expansion (character lengths stay as modeled). Detailed type checking still warns when source NVARCHAR maps to target VARCHAR because sort order can differ. ORDER BY risks on string keys are mitigated automatically by applying the same bridge COLLATE (preferring the source collation) on target and hub source SQL ORDER BY when live collations/types differ.

Satellite update pipelines Sort Rows the source stream after the parent hash is calculated in Hop (the merge key is not present in source SQL). The target leg is ordered only by SQL ORDER BY (no second Sort Rows).

These checks help you avoid generating pipelines that would fail or produce unexpected results.

Target table layout for satellites

The layout that drives DDL and loading usually contains:

The parent hash key column (the hash key name is taken from the parent hub definition).
The satellite attribute columns, in the order you listed them (or all qualifying source columns if the list is empty). Length and precision information from the source definition is used when available so you get realistic column types.
The record source column (only when Store record source indicator is enabled).
The load date column.

The same attribute list that is used for change detection is also used for the target table and the final load, so what you see in the dialog is what ends up in the database.

When Store record source indicator is off, the feed does not need a static or column-based source indicator for this satellite alone. If the same catalog source also feeds a hub or link, that consumer still requires an indicator.

Tips for satellites

Use Load from source and then review the list. Remove columns that are not interesting for history (for example large free-text fields or technical IDs that never change).
The "Include in CDC" flag is powerful. Use it to ignore columns that would otherwise cause unnecessary new rows (last-updated timestamps from the source, for example).
For multi-active satellites, be clear about what the driving key represents. It becomes part of the uniqueness rule for the satellite.
Attach satellites to links when the descriptive information truly belongs to the relationship rather than to one of the participating hubs.
When the parent hub is fed by multiple record sources, it is common and recommended to create a separate satellite definition for each source (even if they track the same attributes). This keeps the incoming data, record source values, and change history cleanly separated per origin system while still describing the same parent hub.

If this satellite feed can introduce a parent business key that is not yet in the hub, use Also load parent hub… on the satellite dialog or an orphan policy other than PASS. See Orphan handling.

Satellites on multi-source hubs

If your hub definition lists several record sources, you will normally also create multiple satellites (one per source) that all point to the same parent hub. Each satellite only needs to reference the Data Vault Source that is relevant to it. This pattern gives you clean per-source history while keeping the hub itself as a single unified business key table.

You can also attach a satellite to a feed that is not used to load the hub (for example a multi-table source query that joins hub keys with descriptive attributes). The hub still loads from its own sources; the satellite only needs the parent business key columns on its feed so the same parent hash key can be computed.

Parent business keys on the satellite feed

The hub defines vault business keys and, for composite keys, ordered source parts. The parent hash uses the same delimiter / suffix / casing rules as hub loads (from the model configuration).
Multipartite hub keys: by default the satellite feed exposes columns with those vault names (for example customer_id). If names differ, list source columns on the Parent key source fields tab in hub key order (for example cust_no for hub key customer_id).
Composite hub keys (single vault column on the hub): list N source part columns in hub part order (for example num_seq_bkcc_bk, num_seq_bk). Do not require a composed burger_bk column on the satellite feed. Leave the list empty to default from the hub mapping when the sat record source is also a hub source (or when the hub definition carries default part names).
Do not put satellite-only source column names on the hub Keys tab — that tab is only for sources that load the hub.
Independent satellite feeds (multi-table composite queries, other models that only reference the hub) are expected; the sat feed need not be a hub record source.
See Composite hub business keys for storage vs hash rules.