What is a data model diagram?
A data model diagram is a visual representation of the data structures, entities, attributes, and relationships within a system or domain. Data model diagrams exist at three levels of abstraction: conceptual (business entities and their relationships, for stakeholder communication), logical (entities with attributes and cardinality, database-agnostic), and physical (actual tables, columns, data types, and indexes for a specific database engine).
Data model diagrams are used in database design, application architecture, data integration planning, compliance documentation, and system onboarding. The Entity-Relationship Diagram (ERD) is the most widely used notation for logical data models, using entities, attributes, and cardinality symbols to represent data structures that translate directly to relational database schemas.
The three levels of data modeling
| Level | Audience | Shows | Does not show |
|---|---|---|---|
| Conceptual | Business stakeholders, domain experts | Main business entities and high-level relationships. No attributes or data types. | Attributes, keys, data types, cardinality detail |
| Logical | Data architects, developers | Entities with attributes, primary and foreign keys, cardinality (one-to-many, many-to-many). Database-agnostic. | Specific data types, indexes, storage parameters |
| Physical | DBAs, implementation engineers | Tables, columns, exact data types (VARCHAR(255), BIGINT), indexes, constraints, partitioning — for a specific database engine. | Business meaning (implicit in column names and constraints) |
Cardinality notation: Crow's Foot
Crow's Foot notation is the most widely used cardinality notation for data model diagrams. Each end of a relationship line carries two symbols: one for minimum cardinality (optionality) and one for maximum cardinality (multiplicity).
| Symbol | Meaning | Example reading |
|---|---|---|
| | Exactly one (mandatory) | An Order must belong to exactly one Customer |
O | Zero (optional) | A Customer may have zero Orders |
< | Many | A Customer may have many Orders |
|| | One and only one | Mandatory, non-repeating |
O< | Zero or many | Optional, repeating |
|< | One or many | Mandatory, repeating (at least one) |
O| | Zero or one | Optional, non-repeating |
Example: e-commerce data model prompt
Use this prompt in flow-chart.io to generate a logical data model for an e-commerce system:
Logical data model for an e-commerce system. Entities: Customer (CustomerID PK, Email, Name, CreatedAt), Order (OrderID PK, CustomerID FK, OrderDate, Status, TotalAmount), OrderItem (OrderItemID PK, OrderID FK, ProductID FK, Quantity, UnitPrice), Product (ProductID PK, Name, Description, Price, StockQty, CategoryID FK), Category (CategoryID PK, Name, ParentCategoryID FK self-referential). Relationships: Customer one-to-many Orders; Order one-to-many OrderItems; Product one-to-many OrderItems; Category one-to-many Products; Category self-referential (parent category to child categories). Use Crow's Foot notation.
When to use each data model type
- Conceptual model during requirements: Confirm with business stakeholders that the right entities and relationships are captured before any schema design begins. A conceptual model communicates without technical jargon.
- Logical model during design: Design the schema for developer and DBA review before implementation. The logical model serves as the blueprint for CREATE TABLE statements and migration scripts.
- Physical model during implementation and documentation: Document the actual schema for onboarding, audit, and migration planning. Physical models are specific to a database engine and change when storage strategy changes.
- Any level for data integration: When connecting systems, a data model diagram clarifies which tables each system owns and how they map to each other.
- Logical or physical model for refactoring: Before restructuring a database, a diagram of the current state reveals normalization issues, missing constraints, and inefficient relationships.
Frequently asked questions
- What is the difference between a conceptual, logical, and physical data model?
- Conceptual models show main business entities and relationships — no attributes or data types — for stakeholder communication. Logical models add attributes, cardinality, and keys while remaining database-agnostic, for data architects. Physical models are implementation-specific: exact column names, data types, indexes, and constraints for a specific database engine.
- What is the difference between a data model diagram and an ERD?
- An ERD is the most common notation for drawing logical data model diagrams, using rectangles for entities, ovals for attributes, diamonds for relationships, and cardinality symbols on connecting lines. "Data model diagram" is broader and includes conceptual models, dimensional models (star schemas), and document models for NoSQL. In practice, when engineers say "data model diagram" they usually mean an ERD or table diagram with foreign key relationships.
- How do I show cardinality in a data model diagram?
- Crow's Foot notation (the most common) uses symbols at line ends: a single vertical line for "one", a circle for "zero", and a crow's foot (three-pronged fork) for "many". Combined: |O means zero or one, || means exactly one, O< means zero or many, |< means one or many. Specify cardinality in your flow-chart.io prompt: "Customer has zero or many Orders; each Order belongs to exactly one Customer."
- When should I use a data model diagram?
- Use a conceptual data model during requirements to confirm entities with stakeholders. Use a logical data model during design as a schema blueprint. Use a physical data model for implementation documentation and migration planning. Use any level for data integration planning (mapping systems) or database refactoring (identifying normalization issues).
- What is the difference between a data model and a schema?
- A data model is an abstract design of data structures, relationships, and rules — independent of any technology. A schema is the concrete implementation of a data model in a specific database: the CREATE TABLE statements, column definitions, indexes, and constraints. The data model is the design; the schema is the implementation.
- What export formats are available for data model diagrams?
- flow-chart.io exports data model diagrams as SVG (for technical documentation in Confluence, Notion, or GitHub wikis), PNG at 2× and 4× resolution (for design documents and slides), PDF (for architecture review packages), and JSON (re-importable scene graph for future editing). All exports are derived from the editable scene graph — not screen captures.
- How do I model many-to-many relationships in a data model diagram?
- Resolve many-to-many relationships using a junction table (associative entity). Draw the junction table as a separate entity with foreign keys pointing to both related entities. For example, Student and Course resolve to an Enrollment table with StudentID and CourseID as a composite primary key, plus relationship-specific attributes like EnrollmentDate and Grade. In Crow's Foot notation, draw one-to-many lines from Student to Enrollment and from Course to Enrollment.