3.5 Naming Standards & Modeling Best Practices

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

3.5 Naming Standards & Modeling Best Practices

Key Takeaways Explain This Topic AI

Consistent enterprise naming standards apply across conceptual, logical, and physical models to reduce integration friction.

The Prime-Modifier-Class structure organizes names logically, ending with a standard Class Word derived from ISO/IEC 11179.

Model verification is a technical check for completeness and syntax, whereas model validation confirms alignment with business requirements.

Data models are rich metadata sources that should be cataloged in a repository to support downstream impact analysis and data lineage.

Last updated: July 2026

Enterprise Naming Standards

Enterprise Naming Standards are formal guidelines established to ensure that data entities, attributes, tables, and columns are named consistently, clearly, and unambiguously across an entire organization. In many enterprises, data models are built by fragmented project teams, leading to inconsistencies where the same data element is named differently (e.g., Client_Identifier , Cust_ID , or Party_Num ). Standardizing names reduces integration friction, enables automated Metadata Harvesting , and ensures that data models serve as a reliable foundation for data integration and governance.

The Prime-Modifier-Class Name Structure

A widely accepted best practice in data modeling is the Prime-Modifier-Class naming convention. This structure organizes names logically by breaking them down into three distinct parts:

Prime Word : The primary noun representing the business concept or subject area (e.g., Customer , Employee , Product , Order ). The prime word establishes the context of the data element.

Modifier Word : One or more qualifiers that refine the prime word to make it specific (e.g., Hire in Employee_Hire_Date or Billing in Customer_Billing_Address ). Multiple modifiers can be used if necessary, but they should be kept to a minimum to maintain readability.

Class Word (Representation Term) : A generic word that identifies the property or category of data represented by the attribute. The class word must always be placed at the very end of the attribute name as a suffix (e.g., Date in Order_Placement_Date ).

Class Words (ISO/IEC 11179)

The ISO/IEC 11179 metadata registry standard outlines the classification, definition, and naming of data elements. A core element of this standard is the use of Class Words (also called representation terms or domain words). Class words define the physical and logical characteristics of a data element. Enforcing a strict list of approved class words prevents modelers from using vague suffixes like _VAL , _INFO , or _DATA .

Commonly approved class words and their meanings include:

Identifier (ID) : A unique value used to locate or identify a specific instance of an entity (e.g., Customer_Identifier ).

Date : A calendar day, month, and year (e.g., Order_Ship_Date ).

Amount : A monetary value (e.g., Transaction_Payment_Amount ).

Quantity : A non-monetary numeric count (e.g., Inventory_Stock_Quantity ).

Name : A textual label for a person, place, or thing (e.g., Product_Brand_Name ).

Code : A shorthand system representation or classification code (e.g., Postal_State_Code ).

Percent : A ratio or rate expressed as a percentage (e.g., Interest_Rate_Percent ).

Text (TX/Description) : Free-form narrative or description (e.g., Customer_Feedback_Text ).

Time : A specific point in time or duration (e.g., Process_Duration_Time ).

Class Word Logical Suffix Example attribute name Physical Abbreviation Example
Identifier Identifier Customer_Identifier CUST_ID
Date Date Employee_Hire_Date EMP_HIRE_DT
Amount Amount Product_Retail_Amount PROD_RTL_AMT
Quantity Quantity Order_Line_Quantity ORD_LN_QTY
Code Code Transaction_Status_Code TXN_STAT_CD
Percent Percent Discount_Rate_Percent DSCNT_RT_PCT
Model Verification vs. Model Validation

Quality management in data modeling is split into two distinct activities: Model Verification and Model Validation .

Model Verification ("Did We Build the Model Right?")

Verification is a technical audit process. It checks whether the model conforms to the organization's modeling standards, syntax rules, and physical constraints. It is typically performed by a lead data architect or through automated validation tools. Key verification tasks include:

Checking that all tables have primary keys defined.

Verifying that all relationship lines resolve to valid primary-key-to-foreign-key constraints (ensuring there are no orphan tables or unresolved relationships).

Ensuring that data types are assigned to all attributes and that they are compatible across keys.

Confirming that all table and column names conform to enterprise naming standards and length limits.

Resolving circular relationships or redundant paths in physical database designs.

Model Validation ("Did We Build the Right Model?")

Validation is a business-focused audit process. It checks whether the model accurately represents the business requirements, business rules, and real-world processes of the stakeholders. It is typically performed during joint application design (JAD) sessions with business analysts, data stewards, and subject matter experts. Key validation tasks include:

Conducting walk-throughs of logical and conceptual models with business users to confirm understanding.

Verifying that cardinality constraints (one-to-one, one-to-many, many-to-many) match actual business rules (e.g., confirming that a customer can have multiple billing addresses).

Ensuring that business definitions are written, clear, and complete for every entity and attribute.

Validating that the model contains all the fields and relationships necessary to support business processes and downstream reports.

Metadata Integration & Repository Management

Data models are rich repositories of Metadata . They capture the structures, business rules, and technical definitions of an enterprise's data assets. To maximize their value, data models must be cataloged and integrated into the wider enterprise metadata ecosystem.

Data Modeling Repository (Model Catalog) : Completed data models should be stored in a centralized data modeling repository. This system supports version control, model comparison, and collaboration among modeling teams.

Enterprise Metadata Repository : The metadata captured in data models (such as table structures, attribute definitions, and relationship logic) should be exported and integrated into the Enterprise Metadata Repository . This allows the definitions in the data models to automatically populate the Business Glossary .

Data Lineage and Impact Analysis : Integrating models with the metadata repository enables the tracking of Data Lineage (how data flows from source databases, through integration pipelines, into data warehouses and downstream reports). If an architect proposes changing a database column's structure, the lineage metadata enables Impact Analysis , quickly identifying which integration jobs, ETL processes, and BI dashboards will be broken by the change.

CDMP Exam Tips and Pitfalls

Verification vs. Validation : Candidates often confuse these two terms. Remember: Verification is about syntax, keys, abbreviations, and rules (technical). Validation is about business rules, user approval, definitions, and requirements (business).

ISO/IEC 11179 Class Words : The exam may ask which component of a naming standard defines the property of a data element. The answer is the Class Word . Note that class words are typically placed as the suffix (at the end) of the logical attribute name (e.g., Birth_Date , where Date is the class word).

Physical Abbreviations : Physical column names should always be derived from logical names using an approved enterprise abbreviation glossary (such as translating Quantity to QTY or Identifier to ID ). Hand-crafting physical names without checking the glossary violates modeling best practices.