Study guide
5.2 Conceptual, Logical, and Physical Data Models and Data Management
TOGAF Enterprise Architecture Practitioner OGEA-103
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Mechanics & Foundation Overview
1.1 OGEA-103 Exam Structure, Gradient Scoring & Open-Book Strategy 1.2 The TOGAF Standard 10th Edition Structure & Core Concepts 1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains 1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
2 Chapter 2: Preliminary Phase & Establishing the EA Capability
2.1 Preliminary Phase Objectives, Inputs, and Activities 2.2 Scope of the Enterprise and Defining the Architecture Footprint 2.3 Establishing Architecture Governance, Frameworks, and Tools
3 Chapter 3: Architecture Vision & Stakeholder Management (Phase A)
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition 3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map 3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation 3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
4 Chapter 4: Business Architecture (Phase B)
4.1 Phase B Objectives, Steps, and Business Modeling Approaches 4.2 Business Capabilities, Capability Mapping, and Assessment 4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping 4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
5 Chapter 5: Information Systems Architectures — Data Architecture (Phase C)
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles 5.2 Conceptual, Logical, and Physical Data Models and Data Management 5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
6 Chapter 6: Information Systems Architectures — Application Architecture (Phase C)
6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First 6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration 6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
7 Chapter 7: Technology Architecture (Phase D)
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles 7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling 7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models
8 Chapter 8: Opportunities and Solutions (Phase E)
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation 8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition 8.3 Transition Architectures, Incremental Delivery, and Dependency Analysis 8.4 Architecture Roadmap Development and Trade-Off Analysis 8.5 Business Transformation Readiness Assessment and Risk Management
9 Chapter 9: Migration Planning (Phase F)
9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment 9.2 Business Value Assessment, Cost-Benefit Analysis, and Risk/Feasibility Scoring 9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
10 Chapter 10: Implementation Governance (Phase G)
10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off 10.2 Architecture Contracts: Purpose, Types, Timing, and Stakeholder Commitments 10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists
11 Chapter 11: Architecture Change Management (Phase H) & Requirements Management
11.1 Phase H Objectives, Drivers of Architecture Change, and Value Monitoring 11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes 11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle 11.4 Requirements Management: Central Role, Traceability, Mid-Phase Discovery, and Scope Conflict
12 Chapter 12: Architecture Governance, Boards, and Dispensations
12.1 Architecture Governance Framework, Organizational Roles, and RACI Matrix 12.2 Architecture Board Structure, Federation, Responsibilities, and Meeting Operations 12.3 Compliance Assessment, Dispensation Process, Expiration, and Remediation Tracking 12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts
13 Chapter 13: Architecture Content Framework & Architecture Repository
13.1 The TOGAF Content Framework and Enterprise Metamodel 13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs) 13.3 Architectural Views, Viewpoints, Stakeholder Concerns, and ISO/IEC/IEEE 42010 13.4 The Enterprise Continuum and the TOGAF 10 Architecture Repository
14 Chapter 14: EA Capability, Tailoring, and Iteration
14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration 14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement 14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures 14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
5.2 Conceptual, Logical, and Physical Data Models and Data Management
Key Takeaways Explain This Topic AI
Enterprise Architecture operates across three levels of data abstraction: Conceptual Data Models (business entities and subject areas), Logical Data Models (normalized entities, attributes, and business rules), and Physical Data Models (database schemas and storage mechanisms).
Conceptual and Logical data models fall squarely under Enterprise Architecture governance to establish shared business vocabularies and canonical schemas, whereas Physical Data Models are typically delegated to implementation teams unless constrained by cross-cutting non-functional requirements.
Master Data Management (MDM) identifies, aggregates, cleanses, and synchronizes core non-transactional business entities (Customer, Product, Vendor, Asset) into an authoritative 'Golden Record' to eliminate siloed duplication.
Master data architectures are deployed through four primary patterns: Registry (federated indexing), Consolidation (analytical reporting hub), Coexistence (synchronized bidirectional hub), and Centralized (single authoritative operational system).
Enterprise data security classification (Public, Internal, Confidential, Restricted/PII) combined with data sovereignty regulations (such as GDPR and HIPAA) dictate mandatory geographical, storage, and lifecycle constraints.
Last updated: October 2026
5.2 Conceptual, Logical, and Physical Data Models and Data Management
Data modeling is the foundational technique used in Phase C Data Architecture to describe, structure, and govern information assets. On the TOGAF Enterprise Architecture Practitioner examination, candidates must demonstrate a nuanced understanding of the three levels of data abstraction, recognize the boundary separating enterprise architecture from implementation engineering, and understand data management patterns such as Master Data Management (MDM) and regulatory sovereignty.
The Three Levels of Data Abstraction
To balance high-level strategic alignment with technical precision, enterprise data architecture employs three distinct tiers of data modeling:
1. Conceptual Data Model (CDM)
Primary Purpose : Establishes a shared business vocabulary and high-level structural understanding of enterprise information for business executives, domain owners, and enterprise architects.
Content : Represents major Subject Areas and core Business Entities (such as Customer , Account , Product , Agreement , and Claim ) along with the fundamental business relationships connecting them (e.g., "Customer holds Account", "Claim references Policy").
Technology Independence : Completely independent of software packages, database management systems (DBMS), data storage paradigms (relational, document, graph), and implementation technologies.
ADM Context : Directly translates the business concepts identified during Phase B (Information Mapping and Business Capability Assessment) into structured architectural constructs.
2. Logical Data Model (LDM)
Primary Purpose : Defines the detailed structure, relationships, business rules, and attributes of enterprise data to guide system integration and software development.
Content : Fully normalized data entities (typically adhering to 3rd Normal Form or domain-driven entity boundaries), entity attributes, business keys (natural keys), foreign key relationships, and cardinality constraints (1:1, 1:N, M:N).
Technology Independence : Independent of any specific database vendor (such as Oracle, PostgreSQL, MongoDB, or Snowflake) and hardware platform, but structured with sufficient precision to define canonical message schemas (JSON Schema, XML Schema), API payload contracts, and enterprise data exchange standards.
ADM Context : Forms the core technical deliverable of Phase C Data Architecture. It defines the canonical information model that bridges business functions with application interfaces.
3. Physical Data Model (PDM)
Primary Purpose : Specifies the exact technical implementation of data structures optimized for specific database platforms, storage engines, and performance profiles.
Content : Physical database tables, columns, physical data types (VARCHAR2, INT4, TIMESTAMP), primary key constraints, foreign key indexes, secondary indexes (B-Tree, GIN, Hash), partitioning schemes, sharding keys, tablespaces, and storage parameters.
Technology Independence : Completely dependent on the target technology platform and hardware environment.
The Enterprise Architecture Boundary: Where Does EA Stop?
In practice, enterprise-level data architecture focuses primarily on conceptual and logical data models ; TOGAF's Phase C data artifacts include Conceptual Data and Logical Data diagrams.
Physical Data Models belong almost exclusively to the domain of Solution Architecture , database administration, and software engineering during system design and Phase G (Implementation Governance). An enterprise architect who spends weeks designing individual database table indexes or defining column length constraints is operating outside the proper level of enterprise abstraction—a classic anti-pattern frequently tested on the practitioner exam.
Critical Exceptions Where Physical Concerns Become EA Concerns
While physical schemas are generally delegated, physical data architecture becomes an enterprise architecture concern when it intersects with cross-cutting non-functional requirements (NFRs) or enterprise-level constraints:
Ultra-Low Latency and High Throughput : When global systems require multi-region distributed databases with sub-millisecond replication (e.g., active-active CockroachDB or AWS Spanner clusters) to meet core business continuity goals.
Regulatory Data Sovereignty : When physical data residency laws dictate that data must physically reside within specific geographic national borders.
Enterprise Storage Standardization : When an enterprise establishes a strategic standard mandating cloud-native managed databases and decommissioning on-premises relational databases to reduce total cost of ownership (TCO).
Comparison of Data Modeling Levels
The following table outlines the architectural distinctions across the three modeling tiers:
Modeling Dimension Conceptual Data Model (CDM) Logical Data Model (LDM) Physical Data Model (PDM)
Primary Audience Business Executives, Domain Leaders, Enterprise Architects Data Architects, System Analysts, Integration Engineers Database Administrators, Software Developers, Cloud Engineers
Scope & Breadth Enterprise-wide or Major Line of Business Enterprise Domain or Functional Capability Specific Software System or Database Instance
Entity Detail High-level business entities only Normalized entities with full attribute lists Physical tables, collections, views, and schemas
Key Constructs Subject areas and high-level relationships Business keys, foreign keys, cardinalities Primary keys, foreign keys, indexes, clustering keys
Technology Dependency Completely technology-neutral Platform-neutral; software-independent Vendor-specific (e.g., PostgreSQL, Oracle, MongoDB)
Primary TOGAF Artifact Data Entity / Business Function Matrix Data Entity / Application Matrix, Canonical Schemas Database DDL Scripts, Storage Configurations (Phase G)
Governance Level Governed by Architecture Board & Data Owners Governed by Domain Data Architects & Stewards Governed by Project Engineering Teams & DBAs
Master Data Management (MDM) and the Golden Record
In complex enterprises, data is fragmented across dozens of disparate transactional systems. A customer may be recorded in an e-commerce platform, a retail point-of-sale system, a CRM database, and an ERP billing engine—frequently with conflicting names, addresses, and identifiers. Master Data Management (MDM) is the architectural discipline that defines, consolidates, and manages the core non-transactional entities of an organization.
Understanding Data Categories
Master Data : The core business entities that provide context to business transactions (such as Customer , Product , Supplier , Location , and Chart of Accounts ). Master data is characterized by high reuse across multiple systems and relatively low update frequency.
Transactional Data : Records of business operations and events (such as Sales Orders , Invoices , Credit Card Charges , and Shipments ). Characterized by high transaction volume, time-stamped entries, and operational immutability once finalized.
Reference Data : Semi-static classification tables and standardized code sets (such as ISO Country Codes , Currency Codes , State Abbreviations , and Unit of Measure tables).
The Golden Record (Single Version of the Truth)
The Golden Record is the single, authoritative, cleansed, and deduplicated master record for an entity. When master data is federated across multiple operational platforms, the MDM system applies probabilistic matching algorithms, survivorship rules (e.g., "Trust CRM for phone numbers, but trust Billing for physical addresses"), and data enrichment to assemble the definitive Golden Record.
Core MDM Architectural Patterns
Practitioners must evaluate four distinct MDM deployment patterns based on enterprise trade-offs:
Registry Pattern :
How it Works : The MDM hub stores only an index of global identifiers and cross-system pointers. Source systems retain their original data. Queries search the registry to retrieve federated records from source systems.
Trade-offs : Highly non-intrusive, rapid implementation, and lowest capital cost; however, provides read-only search capabilities and does not clean up data within source systems.
Consolidation Pattern :
How it Works : Source systems periodically push their master data via batch or streaming pipelines into a central MDM hub. The hub consolidates, cleanses, and dedupes the data for enterprise analytics and reporting.
Trade-offs : Excellent for business intelligence, data warehouses, and reporting; however, operational source systems do not receive cleansed master records and continue operating with fragmented data.
Coexistence Pattern :
How it Works : Master data is created in source systems, synchronized into a central MDM hub where the Golden Record is generated, and updates are synchronized bidirectionally back to all participating operational systems.
Trade-offs : Harmonizes operational and analytical environments while maintaining legacy autonomy; however, introduces high integration complexity and potential distributed synchronization conflicts.
Centralized (Transactional) Pattern :
How it Works : Master data is authored, updated, and validated exclusively within the central MDM hub. Operational applications must call the MDM hub via APIs or services to interact with master entities.
Trade-offs : Guarantees highest data quality, complete transactional integrity, and zero duplication; however, requires substantial organizational change and poses a potential single point of failure.
Data Classification, Security, and Lifecycle Management
Enterprise data architecture must incorporate security and regulatory controls into the logical model through formal classification schemas:
Public : Information approved for unrestricted public distribution (e.g., marketing brochures, press releases). Loss or disclosure presents zero risk.
Internal : Standard operational business data intended for internal staff (e.g., corporate policies, organizational charts, intranet content). Unauthorized disclosure causes minor disruption.
Confidential : Sensitive business data whose unauthorized disclosure could cause financial, competitive, or operational damage (e.g., vendor contracts, unannounced product pricing, financial forecasts).
Restricted / Regulated : Highly sensitive data subject to statutory legal penalties, including Personally Identifiable Information (PII), Protected Health Information (PHI), and Payment Card Data (PCI-DSS). Requires mandatory encryption at rest, encryption in transit, strict role-based access control (RBAC), and immutable audit logging.
The Enterprise Data Lifecycle
Data architecture governs information across six explicit lifecycle phases:
Acquisition / Creation : Initial capture via user interfaces, external feeds, or IoT sensors.
Ingestion & Storage : Validation, encryption, and persistence in structured/unstructured repositories.
Processing & Enrichment : Normalization, business rule execution, and analytical transformation.
Dissemination & Sharing : Distribution via APIs, event streams, or ETL pipelines.
Archival : Migration of cold data to low-cost, immutable, compliant storage tiers.
Destruction & Purging : Cryptographic erasure or physical destruction adhering to statutory retention schedules.
Data Sovereignty and Cross-Border Constraints
Modern cloud-based data architectures operate in a heavily regulated global environment. Enterprise architects must account for Data Sovereignty —the legal concept that digital data is subject to the laws and governance of the geographic jurisdiction where it is physically located or where the subject resides:
European Union GDPR : Imposes strict extraterritorial mandates regarding the processing of EU citizen data, requiring valid legal transfer mechanisms (such as Standard Contractual Clauses), enforcing data minimization, and granting the "Right to be Forgotten".
US HIPAA / HITECH : Mandates strict technical and administrative safeguards for electronic health records, including dedicated audit logs and business associate agreements.
Geopolitical Residency Laws : Multiple nations (including Canada, Germany, India, and China) enforce localized residency mandates requiring citizen financial, health, or personal data to be stored exclusively on physical servers located within national borders.
Architectural Impact : These constraints prevent architects from deploying a single, centralized global database. Instead, architects must design partitioned multi-region topologies, deploy regionalized cloud tenants, implement bring-your-own-key (BYOK) encryption schemes, and use localized data pipelines.
Common Exam Traps & Pitfalls
Trap 1: Placing Physical DDL Design in Enterprise Architecture : Exam questions often present scenarios where an enterprise architect is spending weeks tuning database indexing algorithms or writing SQL scripts. The correct architectural assessment is that this represents an anti-pattern; physical design belongs to Solution Architecture and engineering teams.
Trap 2: Confusing Master Data with High-Volume Transaction Data : A distracter option may classify customer invoices, clickstream logs, or sales transactions as "Master Data". These are transactional records that reference master data entities.
Trap 3: Overlooking Data Sovereignty in Cloud Migrations : In cloud migration scenarios, proposing to consolidate all global regional databases into a single centralized US-based cloud data lakehouse without addressing international data privacy regulations will receive zero points. Legal sovereignty overrides architectural simplicity.