Conceptual, Logical, and Physical Data Modeling


A toolarrow-up-right to draw ER diagrams.

More toolsarrow-up-right for data modeling.


Conceptual Data Model

Start with the business perspective. Focus on identifying the main entities (things your business cares about) and their relationships without worrying about technical details.

Key steps:

  • Interview stakeholders to understand business requirements

  • Identify major entities (Customer, Product, Order, etc.)

  • Define high-level relationships between entities

  • Use simple entity-relationship diagrams with just entity names and relationship lines

  • Validate with business users to ensure you've captured their domain correctly

Example: A retail business might have entities like Customer, Product, Order, and Payment, with relationships showing that customers place orders containing products.

Primary tools:

  • Entity-Relationship Diagrams (ERD) - Simple notation with just entities (rectangles) and relationships (diamonds or lines)

  • UML Class Diagrams - Simplified version showing just class names and associations

  • Crow's Foot Notation - Basic version with just entity boxes and relationship lines

Characteristics at this stage:

  • Very simple diagrams with minimal detail

  • No attributes shown (or just key attributes)

  • Focus on "what" entities exist and how they relate

  • Can be drawn on whiteboards or simple diagramming tools

Tools: Lucidchart, draw.io, Visio, or even PowerPoint

Logical Data Model

Expand the conceptual model by adding attributes and more detailed relationships while remaining database-agnostic.

Key steps:

  • Add attributes to each entity (Customer has name, email, phone)

  • Define primary keys for each entity

  • Specify cardinality of relationships (one-to-many, many-to-many)

  • Normalize the data to eliminate redundancy (usually to 3rd normal form)

  • Add foreign keys to show how entities connect

  • Define data types conceptually (text, number, date) rather than specific database types

Example: Customer entity gets attributes like CustomerID (primary key), FirstName, LastName, Email, while Order entity gets OrderID, CustomerID (foreign key), OrderDate.

Primary tools:

  • Enhanced ER Diagrams (EER) - Full ERD with all attributes, primary keys, foreign keys

  • Crow's Foot Notation - Complete version showing all attributes and cardinality markers (crow's feet, single lines, circles)

  • IDEF1X - Integration Definition for Information Modeling

  • UML Class Diagrams - With full attributes, keys, and multiplicity notation

  • Barker's Notation - Oracle's notation style

Characteristics at this stage:

  • All entities have complete attribute lists

  • Primary keys marked (often underlined or with PK label)

  • Foreign keys identified (often with FK label)

  • Cardinality shown (1:1, 1:N, M:N)

  • Normalization applied

Tools: ERwin, PowerDesigner, Oracle SQL Developer Data Modeler, MySQL Workbench, ER/Studio

Physical Data Model

Transform the logical model into a database-specific implementation with all technical details.

Key steps:

  • Choose specific data types for your target database (VARCHAR(50), INT, DATETIME)

  • Add indexes for performance optimization

  • Define constraints (NOT NULL, CHECK constraints, unique constraints)

  • Consider denormalization for performance if needed

  • Add technical columns (created_date, updated_date, version numbers)

  • Design for specific database features (partitioning, compression)

Primary tools:

  • Database-specific ERDs - Same notations as logical but with technical details

  • DDL Scripts (Data Definition Language) - The actual CREATE TABLE statements

  • Database Designer Tools - Built into database platforms

Characteristics at this stage:

  • Specific data types (VARCHAR(100), INT, TIMESTAMP)

  • Indexes defined and shown

  • Constraints detailed (CHECK, DEFAULT, NOT NULL)

  • Triggers, stored procedures noted

  • Physical storage considerations (tablespaces, partitions)

Tools:

  • Database-specific: SQL Server Management Studio, pgAdmin, Oracle SQL Developer

  • Universal: ERwin, PowerDesigner, DbSchema, DBeaver

  • Code-first: Migration scripts in frameworks like Entity Framework, Django ORM, Alembic

Best practices across all levels:

  • Work iteratively - don't try to perfect one level before moving to the next

  • Maintain traceability between levels so changes can flow up and down

  • Use consistent naming conventions throughout

  • Document business rules and assumptions

  • Validate each level with appropriate stakeholders (business users for conceptual, analysts for logical, developers/DBAs for physical)

The key is to let each model serve its purpose: conceptual for communication with business users, logical for analysis and design, and physical for actual implementation.

Last updated