6.1 Master vs Reference Data

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:

---

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

1. 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.
2. 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.
3. 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.