Data Modeling and Governance: Associations, Tags, and Metadata
What this domain tests
This domain is about the meaning layered on top of views: relationships between them, classification labels, and the descriptive metadata that makes a virtual model usable and auditable.
Associations
An association declares that a field in one view relates to a field in another, with a cardinality of 1:1, 1:N or N:M and optional role names for each end. Associations are documentation and modeling artifacts - they do not enforce referential integrity and do not block inserts or deletes. They inform catalog browsing, suggest join conditions and make the model legible to consumers who never open a join view.
Tags
Tags are labels attached to databases, views or individual columns. They can be grouped by tag type or category (for example PII, domain, sensitivity) and are used for search, classification and governance reporting. A tag on a column is metadata only; if a policy engine consumes that tag, the tag becomes operationally significant and must be maintained deliberately.
Metadata and lineage
Every element carries descriptions, a business name and documentation. VDP tracks dependencies, which produces lineage - where a field originates - and impact analysis - what breaks if a base view changes. This is the mechanism to consult before renaming, retyping or dropping anything.
Worked example
A customer view and an orders view must be linked, and the customer's tax identifier must be flagged as sensitive. Reasoning: create an association from customer.id to orders.customer_id with cardinality 1:N (one customer, many orders) and role names so both directions read clearly; tag the tax identifier column with the PII tag type; then run impact analysis on the customer view to list every derived view and published service that would be affected by a change. Note that the association alone does not guarantee join correctness - the join view still states the condition explicitly.
Traps that cost marks
- Expecting an association to enforce a foreign key at query time.
- Assuming tags propagate down the lineage to derived views; they are attached per element.
- Reading lineage backwards when asked what a base view depends on versus what depends on it.
- Deleting a tag type that policies reference, which silently unclassifies columns.