Conceptual, Logical, and Physical Data Modeling
A tool to draw ER diagrams.
More tools 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