Lesson 2 — Reference Data: Structures, Sources, and Controlled Change
Reference Data seems simple because many examples are short code lists. Chapter 10 expects a richer understanding: Reference Data can express mappings, hierarchies, and formal semantic relationships, and seemingly small changes can affect many downstream systems.
What Reference Data does
Reference Data provides controlled values used to classify or characterize other information or to relate internal values to external standards. It normally has lower volume and volatility than Master Data, but “less volatile” never means “unchanging.”
It also does not normally require entity resolution. You are governing values and their meanings, not deciding whether two customer records represent one person.
Four structures
1. List
The simplest form is a governed value set, often code plus description and definition.
Example: - A = Active - I = Inactive - P = Pending
Use a list when the requirement is simply to control allowed values.
2. Cross-reference
A cross-reference translates between alternate representations of the same concepts.
Example:
- USPS TN ↔ FIPS 47
- ISO alpha-2 US ↔ ISO alpha-3 USA ↔ numeric 840
A cross-reference is not entity matching. It maps representations of a controlled concept.
3. Taxonomy
A taxonomy organizes classification concepts into hierarchy or levels of specificity.
Example: Product → Electronics → Computers → Laptops.
The deciding clue is parent-child classification, not merely a list of values.
4. Ontology
An ontology represents richer formal concepts and relationships beyond one hierarchy. It can express multiple relationship types and semantic meaning among concepts.
The exam distinction is not “ontology = very large taxonomy.” Ask whether the requirement needs a richer semantic model, not just hierarchy.
Sources and type families
Reference Data can be: - internal/proprietary values maintained by the enterprise; - external industry/standards-body code sets; - geographic or administrative classifications; - computational or other governed domain sets.
A common distractor is “Reference Data always comes from outside the organization.” It does not.
Reference Metadata
A mature Reference set should be understandable and maintainable. Useful Metadata includes: - definition and meaning; - source/originating authority; - owner or steward; - version and effective dates; - update frequency/schedule; - consumers and usage; - status/deprecation; - mappings and hierarchy relationships; - history-retention requirements.
Without this context, a central list may exist but still be difficult to govern.
Fit-for-purpose granularity
More detail is not automatically better. Imagine an enterprise classification with 500 highly specific status values. Specialists can use it accurately, but casual users repeatedly choose the wrong code.
The better design may be related governed lists or views at different granularities, with mappings that preserve enterprise meaning. Forcing every consumer to use the most detailed set can reduce Data Quality.
Controlled change
Reference changes can affect validation, integration logic, reports, regulatory outputs, contracts, and analytics. Even when an external authority publishes the new code set, your organization still needs to manage the internal impact.
The core flow is:
Request → identify stakeholders → identify impact → decide/approve → update → communicate/inform.
Impact analysis comes before implementation.
Planned vs ad hoc change
A scheduled annual industry-code release is a planned change. An unexpected local request to add or restructure values is ad hoc and may need stronger case-specific review.
Row-level vs structural change
Changing one description is different from changing granularity, hierarchy, mappings, or schema. Structural changes can break downstream logic even when individual values remain valid.
Example
An industry body reorganizes a classification from 4 levels to 6. The source is authoritative, but the enterprise should not silently replace the current hierarchy. It should identify affected systems/reports, assess mappings and history, approve the rollout, set an effective date, update controlled values, and communicate the change.
Stop and check
If three applications disagree about country codes, choose Reference Data cross-reference and governance. If three applications may contain records for the same customer, choose Master Data entity resolution.
Source anchor: pp. 334–339, 353–357.