Jaco van der Laan

Structure vs Content in Model Versioning

15/09/2025  ·  Model Versioning

‹ ›

1. The Distinction

  • Structure versioning deals with the shape of the data: tables, columns, relationships, and schemas.
  • Content versioning deals with the meaning of the data: business rules, filters, derivations, and how values are interpreted.

Both are equally important:

  • Structure changes affect how systems read/write the data.
  • Content changes affect how the same data values should be understood.

2. Structure Versioning

  • The platform’s physical core (historization + integration layers) is a superset of all structures ever modeled.
    • Columns and tables are never dropped physically.
    • Instead, they are logically hidden in views when no longer part of a DDA version.
  • Each exposure schema (pub_v1, pub_v2, …) reflects the exact structure of a given DDA version.
  • A stable alias (pub) always points to the latest version so consumers can migrate at their own pace.

Example: If a column customer_status is renamed to status_code in DDA v2, the physical integration table will keep both.

  • pub_v1.customer view exposes customer_status.
  • pub_v2.customer view exposes status_code.
  • The stable alias pub.customer points to status_code by default.

3. Content Versioning

  • Content is produced by integration queries, which apply business rules and mappings.
  • Rules may change between DDA versions:
    • Filters applied differently (e.g. only “active” agreements in v2, all agreements in v1).
    • Values classified differently (e.g. new categories introduced).
    • Records may move to a different table altogether.

By default, the platform always applies the latest content rules.
Older semantics can be reproduced by re-running integration with an older DDA version parameter.

Example: In v1, inactive contracts are included. In v2, they are excluded.

  • The physical table still contains both.
  • Integration queries decide whether to expose them based on the DDA version chosen.
  • By default, consumers see the v2 interpretation.

4. Inbound vs Outbound DDA

  • Inbound (Source IDS):
    • Each delivered table comes with metadata specifying its DDA version.
    • Process log captures this at table level.
    • Integration queries map old structures/content → latest semantics.
  • Outbound (Exposure IDS):
    • Views are organized per DDA version schema (structure).
    • By default, all content semantics follow the latest rules.
    • For reproducibility, older semantics can be requested via snapshot_id.

5. Snapshots & Reproducibility

  • snapshot_id ties together:
    • reporting_date
    • delivery_entity
    • source_delivery_number
    • source_DDA_version
    • exposure_DDA_version
  • Stored in a snapshot registry with the exact technical and functional PITs.
  • Exposure views can join this registry to reproduce exactly what was seen under a given DDA structure and content definition.

6. Why This Matters

  • Consumers can continue to use old structures until they migrate (structure stability).
  • Business users always see the most up-to-date content definitions unless explicitly asking for older semantics.
  • Analysts can reproduce past results by querying with a snapshot_id, ensuring auditability.
  • Sources can transition gradually, even delivering some tables/columns in new DDA versions and others in older ones.

In short:

  • Structure = what you see in the schema.
  • Content = what the data actually means.
  • Both are versioned, but handled differently:
    • Structure through views & schemas.
    • Content through integration queries & snapshot_ids.