top of page
Search

Modeling Dependent Child Entities in Data Vault 2.0

  • Writer: Rhys Hanscombe
    Rhys Hanscombe
  • Feb 18
  • 2 min read

A frequent modeling question in Data Vault 2.0 is how to handle dependent child entities—business elements that are tied to a parent but are not standalone concepts.


A recent forum discussion examined a real-world example: modeling a Manufacturer linked to a Department. This post summarizes the key insights and best practices.


The Scenario: Manufacturer Linked to Department

A community member initially suggested adding the Manufacturer ID directly to the LINK table connecting departments and vendors.

  • The question: Should Manufacturer have its own hub?

  • Could it go in the link itself, or in a satellite?


This scenario typifies dependent children in Data Vault: they exist only in the context of a parent and do not represent a standalone business entity.


Expert Guidance: Keep Links Stateless

Another member emphasized:

  • Links should remain stateless.

  • Avoid placing dependent keys directly in a link if they change over time.

  • Options:

    • Create a hub if the concept is independent.

    • Use a Link Satellite with effectivity columns for tracking changes.


Since Manufacturer is not a standalone concept, a hub is inappropriate.


Recommended Approach: Link Satellite

The forum consensus was to place Manufacturer ID in a Link Satellite (e.g., SAT_DEPT_MFG) with effectivity dates to track changes over time if needed.

  • A Data Vault expert clarified:

    • Dependent keys are permanent relationship components.

    • They do not contribute to the Link Hash Key (HK) unless they are part of the unit of work.

    • Effectivity satellites should track relationship status, not descriptive attributes.

  • In this case, a deletion flag from the source removed the need for an effectivity satellite because change tracking was unnecessary.


Hash Key Considerations

A critical question: Does the dependent key contribute to the Link Hash Key?

  • A Data Vault instructor confirmed:

    • Dependent keys that define the unit of work must be included in the Link HK to preserve grain.

    • Correct Link HK structure in this scenario:

DEPT_BK + VENDOR_BK + BRAND_BK + MFG_NO

  • It's important to follow hash string formatting conventions for consistency.


Key Takeaways

  1. Dependent child entities do not require a hub unless they are standalone business concepts.

  2. Link satellites are used if you need to track changes over time.

  3. Include dependent keys in the Link HK if they define the unit of work.

  4. Effectivity satellites are only needed when the relationship changes and the source does not provide deletion flags.

  5. Keep links stateless; do not mix descriptive attributes with relationship tracking.


By following these guidelines, you preserve the integrity of the link and maintain clarity in your Data Vault model.


Join the Discussion

This blog is based on a real Data Vault 2.0 forum thread. Questions like “how to model a dependent child” arise frequently in enterprise implementations.


👉 Read the full discussion and contribute your experiences on the Data Community forum: Modeling a Dependent Child

bottom of page