3.5 Naming Standards & Modeling Best Practices

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:

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

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.