Data Vault Link Satellite Stored Procedure
Purpose
Section titled “Purpose”This code-generation template creates a SQL Server stored procedure that loads a Data Vault Link Satellite table from a Persistent Staging Area (PSA) — the physical counterpart to the Link Satellite view template.
A Link Satellite is a Satellite hanging off a Link rather than a Hub — it stores descriptive attributes about a relationship over time.
Motivation
Section titled “Motivation”The load semantics are the same as a Hub Satellite: detect changes by comparing row checksums, insert only changed rows, preserve full history without duplicates. What differs is the parent key — the surrogate key here is hashed from the combined business keys of the Link, not from a single Hub’s business key.
Applicability
Section titled “Applicability”- SQL Server family databases; the template uses Microsoft SQL (T-SQL) syntax.
Design Pattern
Section titled “Design Pattern”- Data Vault Satellite (applied to a Link)
Schema Type
Section titled “Schema Type”Output Type
Section titled “Output Type”Implementation guidelines
Section titled “Implementation guidelines”This template is intended to be assigned to Data Object Mappings whose target is a Link Satellite Data Object.
The generated procedure mirrors the Hub Satellite load with one structural difference: the parent surrogate key is built by hashing all business-key components that define the Link, not just a single Hub’s business key. Everything else — the load-window control, the row-checksum comparison, the change-detection via LAG — is identical.
For the loading semantics in detail, see Data Vault Satellite Stored Procedure. The standard Link-Satellite load applies when you want all attributes versioned by the inscription timestamp — that is, history is preserved per arrival, and the relationship’s attribute timeline grows monotonically.
If your Link Satellite tracks an attribute that ends a relationship (for example, a contract being terminated), consider the Driving Key variant instead.
Considerations and consequences
Section titled “Considerations and consequences”- The same considerations as the Hub Satellite template apply — MD5 hashing, idempotency, single-source mapping per procedure.
- This template assumes the Link’s business-key definition holds every component of the relationship. If your Link includes additional non-key attributes you want to drive change detection on, model them as Data Item Mappings; they participate in the row checksum.
Extensions
Section titled “Extensions”The conventions auditTrailIdColumn, inscriptionTimeStampColumn, inscriptionRecordIdColumn, changeDataColumn, checksumColumn, sourceTimestampColumn, and controlFramework* must all be defined on the project.