Comprehensive Guide to Enterprise Data Architecture and Data Modeling

1. Data Architecture Context Diagram

Enterprise architecture comprises business, data, application, and technology architectures; data architecture’s primary goal is to manage data effectively and to govern the systems that store and use that data.

Because most organizations possess more data than any individual can comprehend, data must be described at multiple abstraction levels to support decision‑making.

The most detailed data‑architecture artifact is the enterprise data model, which defines data names, attributes, metadata, entities, relationships, and business rules.

This chapter examines data‑architecture deliverables (models, definitions, data flows), activities (formation, deployment, realization), and behaviors (collaboration, mindset, skills).

2. Business Drivers

Typical business drivers for data architecture include leveraging emerging technologies for strategic advantage, translating business needs into data/app requirements, managing complex information across the enterprise, aligning business and IT, and supporting transformation and adaptability.

Key outcomes are data storage and processing requirements and designs that meet current and future data needs.

3. Enterprise Data Architecture

Enterprise data architecture consists of the enterprise data model and data flows.

3.1 Enterprise Data Model

The enterprise data model captures an organization’s understanding of data entities, attributes, and relationships. It includes conceptual, logical, and physical models, linking definitions horizontally (associations) and vertically (hierarchies).

Modeling approaches include top‑down, bottom‑up, or hybrid methods; a combined approach is often recommended.

Conceptual model diagram:

Domain model diagram:

3.2 Data Flow

Data flow records data lineage and can be visualized with a two‑dimensional matrix or flow diagram.

3.2.1 Two‑Dimensional Matrix Data Flow

3.2.2 Data Flow Diagram

4. Measurement Metrics

Common metrics for enterprise data architecture include architecture acceptance rate, implementation trends, and business value; these are usually part of overall project satisfaction surveys and are measured annually.

Metrics detail:

Architecture standard acceptance rate – degree of alignment with established architecture.

Implementation trends – reuse/replace/discard ratios and project delivery efficiency.

Business value – agility improvement, quality, operational quality, and environmental improvement.

5. Key Concepts / Tools / Methods

5.1 Relationships Between Enterprise Architectures

Enterprise architecture types (business, data, application, technology) influence each other and are not isolated.

5.2 Zachman Framework

The Zachman framework provides a matrix of six interrogatives (What, How, Where, Who, When, Why) across rows of transformation stages, helping to capture different stakeholder perspectives.

6. Data Modeling and Design Context Diagram

Data modeling discovers, analyzes, and formalizes data requirements using data models.

Models help organizations understand data assets; the primary output is not a database but a shared understanding.

Common modeling patterns: relational, multidimensional, object‑oriented, fact, time‑series, and NoSQL.

Each pattern can be expressed as conceptual, logical, and physical models, comprising entities, relationships, facts, keys, and attributes.

7. Business Drivers for Modeling

Drivers include providing a common data glossary, capturing detailed data/system information, serving as a communication tool, and offering a basis for customization, integration, or replacement.

Good data modeling reduces support costs and enables reuse for future requirements.

8. Activities

1. Planning Data Modeling: assess needs, define standards, and decide storage.

2. Building Data Models: iterative process using forward or reverse engineering.

Forward engineering starts from requirements → conceptual → logical → physical (DDL statements).

Reverse engineering records existing databases: physical → logical → conceptual.

For detailed steps, refer to DMBOK.

3. Reviewing Data Models: continuous improvement, evaluation, and formal release.

4. Maintaining Data Models: keep models up‑to‑date; reverse‑engineer physical models to ensure consistency with logical models; many tools can auto‑compare differences.

9. Measurement Indicators

Organizations can create a scorecard for data‑model evaluation using the illustrated table.

10. Core Data‑Modeling Concepts

10.1 Entity, Relationship, Attribute, Domain

10.1.1 Entity

An entity is a distinguishable thing that carries information; it can be thought of as answering who/what/when/where/why/how.

Terminology varies by model level: concept (conceptual), entity (logical), table (physical).

10.1.2 Relationship

Relationships link entities and capture interactions at conceptual, logical, and physical levels; they have cardinality (1:1, 1:N, N:M) and arity (unary, binary, ternary).

10.1.3 Attribute

Attributes describe entity properties; identifiers (keys) can be simple, composite, surrogate, candidate, primary, super, or alternate.

10.1.4 Domain

A domain defines the complete set of permissible values for an attribute.

10.2 Common Data‑Modeling Methods

10.2.1 Relational Modeling

Relational modeling organizes data to minimize redundancy and is well‑suited for operational systems; the classic notation uses three‑line symbols to indicate cardinality.

10.2.2 Dimensional Modeling

Dimensional modeling optimizes data for large‑scale query and analysis, using fact tables (numeric measures) and dimension tables (descriptive attributes) with defined granularity.

Fact table – stores measurable values such as amount or transaction count.

Dimension table – stores descriptive attributes like user or region.

Granularity – defines the level of detail for each fact row.

10.2.3 NoSQL Modeling

NoSQL (Not Only SQL) focuses on storage rather than query language, with four main types: document, key‑value, column‑family, and graph databases.

10.3 Model Levels

10.3.1 Conceptual Model (CDM)

Describes high‑level business entities and relationships across domains.

10.3.2 Logical Model (LDM)

Provides detailed, technology‑agnostic specifications to support specific use cases.

10.3.3 Physical Model (PDM)

Maps logical designs to concrete technical solutions, considering hardware, software, and network constraints.

10.4 Normalization

Normalization applies rules to transform complex business data into well‑structured schemas, eliminating redundancy and ensuring consistency. Common normal forms include 1NF (atomic values), 2NF (full‑key dependency), and 3NF (no transitive dependencies); higher forms (4NF, 5NF) are rarely needed.

11. Data‑Modeling and Design Quality Management

11.1 Development Standards

Standards define deliverables, naming conventions, metadata capture, tool usage, review processes, version control, and prohibited practices to ensure data‑model quality.

11.2 Review Process

Cross‑functional expert panels evaluate models, aiming for consensus and practical, high‑quality designs.

11.3 Versioning and Integration

Changes to models are tracked with clear “why, what, how, when, who, where” documentation and approved by data architects.

11.4 Industry Data Models

Pre‑built industry models (e.g., healthcare, telecom, finance) can be purchased or obtained from standards bodies, then customized to fit organizational needs.

11.5 Database Design Best Practices (PRISM)

Principles include Performance & Ease of Use, Reusability, Integrity, Security, and Maintainability, guiding architects to build valuable, secure, and cost‑effective data solutions.