Study guide
6.1 Master vs Reference Data
DAMA Certified Data Management Professional CDMP
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & DMBoK Framework
1.1 CDMP Exam Details & Strategy 1.2 The DMBoK Framework 1.3 Data Management Organization & Roles
2 Chapter 2: Data Governance (Part A)
2.1 Data Governance Principles & Drivers 2.2 Operating Models & Structures 2.3 Policies, Standards, and Procedures
3 Chapter 2: Data Governance (Part B)
2.4 Data Stewardship 2.5 Governance Metrics & Implementation
4 Chapter 3: Data Modeling and Design (Part A)
Section 3.1: Conceptual, Logical, and Physical Models Section 3.2: ERD Notations & Relational Modeling Section 3.3: Normalization
5 Chapter 3: Data Modeling and Design (Part B)
3.4 Dimensional Modeling 3.5 Naming Standards & Modeling Best Practices
6 Chapter 4: Data Quality (Part A)
Section 4.1: Data Quality Dimensions Section 4.2: Data Quality Policy & Rules Section 4.3: DMAIC & DQ Improvement Lifecycle
7 Chapter 4: Data Quality (Part B)
4.4 Root-Cause Analysis & Remediation 4.5 DQ Metrics, Tools, and Reporting
8 Chapter 5: Metadata Management (Part A)
5.1 Business, Technical, and Operational Metadata 5.2 Metadata Lineage & Impact Analysis 5.3 Repository Architectures
9 Chapter 5: Metadata Management (Part B)
5.4 Standards and Semantics 5.5 Metadata Governance & Integration
10 Chapter 6: Master and Reference Data Management
6.1 Master vs Reference Data 6.2 MDM Repository Architectures 6.3 Match-Merge & Identity Resolution 6.4 Reference Data Governance & Standards
11 Chapter 7: Data Warehousing and Business Intelligence
7.1 DW Architectures: Inmon vs Kimball 7.2 Data Warehousing Storage & Load Patterns 7.3 BI Delivery & OLAP 7.4 Data Marts & Enterprise Data Warehouses
12 Chapter 8: Data Architecture
8.1 Enterprise Data Architecture & Zachman Framework 8.2 Data Flow Diagrams & Value Chains 8.3 Architecture Frameworks & Standards
13 Chapter 9: Document and Content Management
9.1 Records Management & ECM 9.2 Retention, Disposal, and E-Discovery 9.3 ARMA GARP Principles & Taxonomies
14 Chapter 10: Data Integration and Interoperability
Section 10.1: Integration Patterns & Technologies Section 10.2: Replication & Virtualization Section 10.3: Canonical Models & Integration Standards
15 Chapter 11: Data Security
Section 11.1: Security Principles: CIA Triad & Privacy Section 11.2: Access Control & Encryption Section 11.3: Security Regulations & Standards
16 Chapter 12: Data Storage and Operations
Section 12.1: Database Technologies & DBA Roles Section 12.2: Backup, Recovery, and High Availability Section 12.3: Performance Tuning & Operations
17 Chapter 13: Big Data and Data Science
13.1 Big Data V's & Technologies
18 Chapter 14: Data Ethics
14.1 DMBoK Data Ethics Framework
19 Chapter 15: Data Management Process and Maturity
15.1 Maturity Assessment Frameworks
6.1 Master vs Reference Data
Key Takeaways Explain This Topic AI
Master data represents the business nouns (parties, products, locations, assets) that provide context to transactional events.
Reference data represents relatively static, low-volume codes (e.g., country codes, status codes) used exclusively to classify other data.
The DAMA DMBoK2 party domain strictly distinguishes between a Party (the person or organization) and a Role (e.g., customer, vendor, employee) to prevent duplication.
Reference data changes have a global impact and require formal change control, unlike highly volatile transactional records.
Last updated: July 2026
Core Concepts of Shared Data
In data management, data is classified into several key categories. Transaction data represents the execution of business processes (e.g., sales orders, invoices, bank deposits) and is highly volatile. However, transactional records cannot stand alone; they depend on context to be meaningful. This context is provided by Master Data and Reference Data . Together, these two categories are known as shared data because they are utilized across multiple systems and processes throughout the enterprise.
Master Data represents the core business entities that participate in transactions. These entities are the "nouns" of the enterprise: who (customers, employees, suppliers), what (products, services, assets), and where (locations, offices, geographic regions). Master data is typically persistent, non-transactional, and spans multiple business units. It represents the structural backbone of the organization, and having a single, trusted source for this data is crucial for accurate business operations and reporting.
Reference Data is a subset of master data (or a closely related cousin) that is used exclusively to classify, categorize, or characterize other data. Unlike master data, reference data is relatively static and is structured as code lists, lookup tables, or hierarchies. Examples include country codes, currency codes, state/province abbreviations, standard industrial classifications, and transaction status codes. Reference data defines the permissible values that other attributes can take, thereby enforcing data quality and consistency at the database level.
Comparing Master and Reference Data
To understand their unique governance and technical requirements, it is essential to compare Master Data and Reference Data across key operational dimensions:
Dimension Master Data Reference Data
Volume High volume (thousands to millions of records, such as customer or product profiles). Low volume (dozens to hundreds of records, such as country or status codes).
Volatility Moderate to high volatility. Master data records are updated frequently as customers move, product lines evolve, or suppliers change. Low volatility. Reference codes are highly static and changes are rare, often driven by external standards.
Structure Complexity Highly complex, containing deep attributes, parent-child relationships, and network graphs (e.g., party relationships). Simple structure, typically consisting of a code, a description, and perhaps a parent identifier for hierarchies.
Primary Focus Entity resolution, deduplication, and establishing a single golden record. Code mapping, translation across systems, and aligning with industry standards.
Governance Scope Managed by specific business domain data stewards (e.g., Product Steward, Customer Steward). Managed centrally by a data governance committee or enterprise reference data stewards.
Master Data Domains
The Data Management Association ( DAMA ) Data Management Body of Knowledge ( DMBoK2 ) identifies four primary master data domains:
1. The Party Domain
The Party Domain is one of the most critical concepts in the DAMA DMBoK2. A Party is any individual or organization of interest to the enterprise. DAMA makes a strict distinction between a "Party" and the "Role" that party plays.
Party : A unique person or organization (e.g., Jane Doe, Acme Corporation).
Role : The business relationship that the party has with the enterprise. A single party can simultaneously play multiple roles, such as being a Customer , a Vendor , an Employee , and a Shareholder .
If an organization manages "Customers" and "Vendors" in separate, siloed databases without a central Party model, they cannot recognize when a vendor is also a customer, leading to duplicated data, credit risk exposure, and compliance failures (such as violation of privacy laws like GDPR).
2. The Product / Asset Domain
The Product Domain encompasses the goods, services, or assets offered by the organization, as well as the internal physical and digital assets used to run the business.
Products : Goods and services sold to customers. This domain is highly hierarchical, spanning from product categories down to individual Stock Keeping Units ( SKUs ).
Assets : Physical equipment, software licenses, machinery, and facilities. In asset-intensive industries (e.g., manufacturing, utilities), asset master data is managed via Enterprise Asset Management ( EAM ) systems.
3. The Location Domain
The Location Domain deals with physical addresses, geographic coordinates, facilities, and regional hierarchies. It is crucial for logistics, taxation, marketing, and sales territory management. Location master data must handle formatting standards (such as postal address validation standards like USPS or international standards) and geographic information system (GIS) mapping.
4. The Financial / Agreement Domain
This domain covers the structures used to track financial performance and contracts. It includes:
Chart of Accounts ( CoA ): The structured list of general ledger accounts.
Cost Centers and Departments : Organizational units used for budgeting and expense tracking.
Agreements / Contracts : Master records of legal agreements, terms of service, and vendor contracts.
Reference Data Definitions and Categories
Reference data categorizes other data elements. It is divided into two primary categories based on its source and scope of usage:
Internal Reference Data
Internal Reference Data consists of codes and classifications defined and used solely within the boundaries of a single organization. Examples include internal department codes, product status codes (e.g., "Draft", "Approved", "Retired"), employee classification tiers, and cost allocation codes. While internal reference data is defined locally, it still requires formal governance to prevent different business units from creating conflicting code sets for the same concepts.
External Reference Data
External Reference Data consists of codes and classifications created, published, and maintained by external standardizing bodies or authorities. Examples include:
Geographic Standards : ISO country codes, state/province abbreviations.
Industry Classifications : Standard Industrial Classification (SIC) codes, North American Industry Classification System (NAICS) codes.
Financial Standards : SWIFT codes, currency codes.
Using external reference data minimizes the integration burden when exchanging data with external business partners and regulatory agencies.
Reference Data Structures and Complexity
While simple reference data consists of a basic list of codes and their corresponding descriptions (e.g., active/inactive flags), reference data can also exhibit complex structural patterns:
Hierarchical Reference Data : In this structure, codes are arranged in parent-child relationships. For example, NAICS codes are structured hierarchically, where a 2-digit code represents a broad economic sector, a 3-digit code represents a subsector, and a 6-digit code represents a specific industry.
Multidimensional Reference Data : This structure represents relationships between multiple reference tables. For example, a postal code reference table may link a zip code to a specific city, state, country, and timezone. Understanding these structural variations is key to designing reference database schemas and managing their integration across systems.
DAMA Exam Traps and Study Tips
Shared Data vs. Transactional Data : The exam frequently tests your ability to classify data elements. A sales transaction is not master data, but the customer ID and product ID referenced in that transaction are master data, and the state code or payment method code are reference data.
Party vs. Role : Remember that "Customer" is a role, not a party. DAMA strongly advocates for a unified Party model to support master data management.
Reference Data Volatility : Do not assume reference data is completely static. It does change (e.g., countries split, currencies change, new industry codes are introduced), but the changes are infrequent and must go through a formal governance lifecycle to prevent downstream system failures.