Study guide
Section 3.1: Conceptual, Logical, and Physical Models
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
Section 3.1: Conceptual, Logical, and Physical Models
Key Takeaways Explain This Topic AI
Enterprise data modeling moves progressively from Conceptual (business concepts, no attributes or keys) to Logical (detailed attributes and keys, DBMS-independent) to Physical (database-specific schemas, columns, data types, indexes, and constraints).
Conceptual data models are targeted at business leaders and architects for scoping, Logical models are targeted at analysts and developers for structuring rules, and Physical models are targeted at DBAs and developers for implementation.
An attribute in a Logical model maps to a column in a Physical model, an entity maps to a table, and a primary identifier maps to a primary key constraint.
Last updated: July 2026
Understanding the Data Modeling Abstraction Spectrum
Data modeling is the process of discovering, analyzing, and documenting data requirements in a structured form. The Data Management Body of Knowledge (DAMA-DMBOK2) defines Data Modeling and Design as the analysis, design, and implementation of data structures that support the organization's business strategy. To bridge the gap between high-level business goals and low-level physical implementation, data professionals use three distinct levels of abstraction: Conceptual Data Models (CDMs) , Logical Data Models (LDMs) , and Physical Data Models (PDMs) .
Each model serves a specific purpose, targets a unique audience, and exhibits a different level of detail. The progression through these levels represents a structured refinement process where business concepts are translated into logical structures, which are then instantiated in a database management system (DBMS).
Characteristic Conceptual Data Model (CDM) Logical Data Model (LDM) Physical Data Model (PDM)
Primary Purpose Align business concepts and scoping Document business rules and structure Implement database structures and schemas
Target Audience Business leaders, Executives, Architects System analysts, Data modelers, Developers Database Administrators (DBAs), DB Engineers
Technology Dependency Fully technology-independent Technology-independent (DBMS-agnostic) Technology-dependent (specific DBMS)
Key Components Business entities, High-level relationships Entities, Attributes, Keys, Cardinalities Tables, Columns, Data types, Indexes, Constraints
Degree of Detail Low (no attributes or data types) Medium-High (fully detailed attributes) High (physical storage parameters included)
- Normalization Not applicable Generally Normalized (3NF) Optimized (Normalized or Denormalized)
- The Conceptual Data Model (CDM)
The Conceptual Data Model provides a high-level, business-oriented view of the enterprise's data requirements. It represents the scope of the business domain and is used to establish common terminology and concepts. The primary goal of a CDM is to align business stakeholders on the definitions of critical business entities and how they relate to one another.
Key Characteristics of CDMs:
Business Language : Written in plain, non-technical business terminology.
High Abstraction : Contains only critical business entities and their relationships.
No Attributes : Attributes (fields) and data types are explicitly excluded at this stage to prevent stakeholders from getting bogged down in low-level details.
No Keys : Identifiers are conceptually recognized, but no physical primary or foreign keys are defined.
Many-to-Many Relationships : Many-to-many (N:M) relationships are permitted and left unresolved, as they accurately represent business realities (e.g., "A Student can enroll in many Courses, and a Course can have many Students").
For example, an Enterprise Conceptual Data Model (ECDM) is a sub-type of conceptual model that spans the entire organization. It establishes a common business vocabulary, aligning different departments on terms like "Customer" vs "Account."
The Logical Data Model (LDM)
The Logical Data Model is a detailed, formal representation of the organization's data requirements. It refines the Conceptual Data Model by adding attributes, identifying keys, and defining precise business rules. While the LDM is highly detailed, it remains database-independent and technology-independent . It describes what the data is, not how it will be stored physically.
Key Characteristics of LDMs:
Entities and Attributes : Every entity is clearly defined, and all its attributes (e.g., Customer First Name , Customer Email Address ) are mapped.
Keys and Identifiers :
Primary Keys (PKs) : The unique identifier for each instance of an entity.
Alternate Keys (AKs) : Candidate keys that are not selected as the primary key but must remain unique (e.g., Social Security Number or Email Address ).
Foreign Keys (FKs) : Defined conceptually to show how entities link to one another.
Cardinality and Optionality : Precise relationships are specified, indicating whether a relationship is one-to-one (1:1), one-to-many (1:N), or many-to-many (N:M).
Normalization : The LDM is typically normalized to Third Normal Form (3NF) to eliminate data redundancy and ensure data integrity.
Resolution of Many-to-Many Relationships : Many-to-many relationships must be resolved by introducing an associative entity (also known as a junction or intersection table) that contains foreign keys pointing to both parent entities.
The Physical Data Model (PDM)
The Physical Data Model is a representation of the actual database implementation. It translates the Logical Data Model into a schema optimized for a specific database technology (e.g., PostgreSQL, Oracle, Snowflake, MongoDB). The PDM is highly technology-dependent, reflecting the physical storage capabilities, hardware constraints, and performance requirements of the chosen target platform.
Key Characteristics of PDMs:
Tables and Columns : Entities become physical tables , and attributes become columns with specific, physical data types (e.g., VARCHAR(50) , NUMBER(10,2) , TIMESTAMP ).
Keys and Constraints :
Primary keys, foreign keys, and unique keys are implemented as physical constraints.
Referential Integrity (RI) : Constraints (e.g., ON DELETE CASCADE or ON DELETE RESTRICT ) are declared to maintain consistent relations between parent and child tables.
Check Constraints : Non-null constraints and validation checks are configured.
Database Objects : Includes physical database structures such as indexes (e.g., B-tree, Bitmap) to speed up queries, views for security and ease of access, and partition keys to manage large volumes of data.
Performance Optimization : Unlike the LDM, which is strictly normalized, the PDM may incorporate denormalization (e.g., pre-joining tables, duplicating columns) to meet stringent performance or latency service level agreements (SLAs).
Semantic Mappings and Terminology Shift
As a data model progresses from conceptual to physical, the terminology changes to reflect the transition from business requirements to physical database constructs. Data management professionals must master these mappings for the CDMP exam:
Logical Model Term (Entity-Relationship) Physical Model Term (Relational DB) Physical Model Term (Object-Oriented/Non-Relational)
- Entity Table (or Relation) Class / Document Collection
- Attribute Column (or Field) Property / Attribute
- Instance (or Occurrence) Row (or Tuple / Record) Object / Document
- Primary Identifier Primary Key Object ID / Key
- Relationship Foreign Key Constraint Reference / Embedded Link
- Governance and Life-Cycle Management of Data Models
Data models are not static files; they are vital metadata assets that must be governed throughout their life-cycle. Organizations should manage models using a central Data Model Repository or a metadata repository that supports version control.
Forward Engineering : The process of generating a physical database schema (DDL - Data Definition Language) directly from a logical or physical data model.
Reverse Engineering : The process of importing an existing physical database schema into a modeling tool to generate a physical and/or logical model.
Model Integration : Ensuring that project-specific data models align with the broader Enterprise Conceptual Data Model to maintain structural alignment and semantic consistency across the enterprise.
CDMP Exam Trap Alert
Many candidates incorrectly assume that a Logical Data Model must include data types. In DAMA terminology, a true logical model defines business attributes and their logical domains (e.g., "Text," "Date," or "Numeric range") but does not specify physical database-specific data types (e.g., NVARCHAR2(255) or INT64 ). Physical data types are strictly the domain of the Physical Data Model. If an exam question asks where a "VARCHAR" or "indexing strategy" is first defined, the answer is always the Physical Data Model.