Loading learning content...
In 1976, Peter Chen published a paper that would fundamentally change how we design databases. His Entity-Relationship Model introduced a visual notation that could bridge the gap between informal requirements and formal database schemas. Nearly fifty years later, ER diagrams remain the most widely used tool for conceptual database design.
The genius of ER diagrams lies in their balance. They're precise enough to capture essential semantics yet simple enough for non-technical stakeholders to understand. They provide a shared language where database architects and business analysts can meet, discuss, and agree on how data should be structured.
In this page, we'll master ER diagrams from their theoretical foundations to practical application, understanding not just how to draw them but why each element exists and what it communicates.
By the end of this page, you will be able to read, create, and evaluate Entity-Relationship diagrams. You'll understand Chen notation (the original ER notation), modern variations like Crow's Foot, and how to apply ER modeling to real-world domains. You'll also learn to recognize when a diagram accurately captures requirements and when it needs refinement.
The Problem Chen Solved
Before the Entity-Relationship model, database designers faced a communication problem. Relational theory, introduced by Codd in 1970, was mathematically rigorous but intimidating to non-technical users. Network and hierarchical models were complex, with navigation-oriented semantics that obscured business meaning.
Designers needed a way to document data requirements that could:
Peter Chen's 1976 paper, "The Entity-Relationship Model—Toward a Unified View of Data," addressed all four requirements.
The Key Innovation
Chen's insight was to focus on semantic concepts rather than implementation constructs. Instead of thinking in terms of tables, pointers, or records, designers think in terms of:
These concepts are natural for humans to discuss. When a business analyst says "Customers place Orders," this maps directly to an ER model: Customer (entity), Order (entity), places (relationship).
Chen's paper has been cited over 10,000 times and influenced virtually every database textbook and tool. Its durability speaks to its effectiveness—the core concepts remain unchanged because they capture something fundamental about how humans understand data.
Why Visualization Matters
Humans are visual creatures. We can absorb and understand diagrams far faster than equivalent textual descriptions. A well-constructed ER diagram allows stakeholders to:
ER diagrams function as shared reference points during design discussions. When a diagram sits on a whiteboard or screen, everyone looks at the same thing. Misunderstandings surface when someone points at a relationship and says, "Wait, I thought that was one-to-many, not many-to-many."
This visualization advantage compounds over the lifetime of a system. New team members onboard faster when they can study a diagram. Maintenance developers understand impact before making changes. Documentation remains current if models are updated alongside code.
ER diagrams use a small set of graphical elements to represent conceptual constructs. Understanding these elements deeply is prerequisite to all ER modeling.
Entities (Rectangles)
An entity is represented by a rectangle containing the entity's name. The name should be a singular noun (Customer, not Customers) that describes what one instance of this entity represents.
Entities represent distinct, identifiable things in the domain. The key test: Can we talk about individual instances separately? "The customer John Smith" versus "Customer #12847" are both valid references to entity instances.
There are two types of entities:
Strong Entities: Have a primary key that uniquely identifies instances from their own attributes. They exist independently.
Weak Entities: Cannot be uniquely identified by their own attributes alone; they depend on a related strong entity. Represented with a double-lined rectangle.
Example: A Room might be a weak entity whose identity depends on the Building it's in. Room 101 in Building A is different from Room 101 in Building B.
Relationships (Diamonds)
A relationship is represented by a diamond containing the relationship name, connected by lines to the participating entities. The name should be a verb or verb phrase describing how entities are associated.
Relationship lines connect to entities, and annotations on these lines show cardinality (how many instances of each entity participate) and participation (whether participation is mandatory or optional).
Relationships can connect:
| Component | Symbol | Represents | Example |
|---|---|---|---|
| Entity | Rectangle | A distinguishable thing in the domain | Customer, Order, Product |
| Weak Entity | Double Rectangle | Entity dependent on another for identity | Room (depends on Building) |
| Relationship | Diamond | Association between entities | 'places' between Customer and Order |
| Attribute | Oval | Property of an entity or relationship | Name, Price, OrderDate |
| Key Attribute | Underlined Oval | Uniquely identifies entity instances | CustomerID, ISBN |
| Multivalued Attribute | Double Oval | Attribute with multiple values per entity | Phone Numbers, Skills |
| Derived Attribute | Dashed Oval | Computed from other attributes | Age (derived from BirthDate) |
| Composite Attribute | Oval with sub-ovals | Attribute composed of sub-attributes | Address (Street, City, Zip) |
Attributes (Ovals)
An attribute is represented by an oval connected to its entity or relationship. Attributes describe properties that we want to store.
Attribute types in ER diagrams:
Simple Attributes: Atomic values that cannot be meaningfully subdivided. Name, Price, Date.
Composite Attributes: Attributes comprising multiple components. Address decomposes into Street, City, State, Zip. Shown as an oval with connected sub-ovals.
Key Attributes: Attributes that uniquely identify entity instances. Shown underlined. An entity may have multiple candidate keys, but we designate one as primary.
Multivalued Attributes: Attributes that can have multiple values for a single entity. A Person might have multiple PhoneNumbers. Shown with double ovals.
Derived Attributes: Attributes computed from other data rather than stored directly. Age derived from BirthDate. Shown with dashed ovals.
During conceptual design, we capture all attribute types to understand the data fully. During logical design, we'll handle multivalued and composite attributes specially.
If you find yourself wanting to give an attribute its own attributes, or if an attribute relates to other things, it's probably an entity. For example, if 'Department' starts needing DepartmentName, DepartmentBudget, and DepartmentLocation, Department is an entity, not an attribute of Employee.
Cardinality and participation constraints describe the rules governing how entity instances can participate in relationships. These constraints are essential to capturing accurate semantics.
Cardinality Constraints
Cardinality specifies how many instances of one entity can be associated with instances of another entity. The three fundamental cardinalities are:
One-to-One (1:1)
Each instance of Entity A relates to at most one instance of Entity B, and vice versa.
Example: In a company where each department has exactly one manager and each manager manages exactly one department: Department ↔ Manager is 1:1.
One-to-Many (1:N)
Each instance of Entity A can relate to many instances of Entity B, but each instance of B relates to at most one instance of A.
Example: A Department has many Employees, but each Employee belongs to one Department. Department → Employee is 1:N.
Many-to-Many (M:N)
Each instance of Entity A can relate to many instances of Entity B, and vice versa.
Example: Students enroll in Courses, and Courses have many Students. Student ↔ Course is M:N.
In Chen notation, cardinality is shown by labels (1, N, M) near the entity connections. In Crow's Foot notation, symbols at line endings show cardinality directly.
| Cardinality | Entity A Perspective | Entity B Perspective | Real-World Example |
|---|---|---|---|
| One-to-One (1:1) | At most one B per A | At most one A per B | Person ↔ Passport (each person has one passport) |
| One-to-Many (1:N) | Many B per A | At most one A per B | Mother → Children (many children, one mother each) |
| Many-to-Many (M:N) | Many B per A | Many A per B | Authors ↔ Books (authors write many books, books have many authors) |
Participation Constraints
Participation specifies whether an entity instance must participate in a relationship. There are two types:
Total Participation (Mandatory)
Every instance of the entity must participate in the relationship. Represented by a double line connecting entity to relationship.
Example: Every Employee must work in some Department. Employee has total participation in the "works in" relationship.
Partial Participation (Optional)
Instances of the entity may or may not participate. Represented by a single line.
Example: An Employee might or might not have a Mentor. Employee has partial participation in the "mentored by" relationship.
Participation constraints have real implications for database design. Total participation becomes NOT NULL constraints and referential integrity requirements. Partial participation allows NULL foreign keys.
Combining Cardinality and Participation
These constraints combine to give precise relationship semantics:
| Constraint | Meaning |
|---|---|
| 1..1 (one, mandatory) | Exactly one related instance required |
| 0..1 (one, optional) | At most one related instance, may be none |
| 1..* (many, mandatory) | At least one related instance required |
| 0..* (many, optional) | Any number including zero |
Example: "Every Order must have exactly one Customer" → Order has (1..1) participation with Customer on the Order side.
"A Customer may have many Orders or none" → Customer has (0..*) participation with Order on the Customer side.
A common mistake is reading cardinality backwards. In 'Customer places Order' with 1:N cardinality, the '1' is at the Customer end (one customer per order) and the 'N' is at the Order end (many orders per customer). Always verify which end each symbol refers to.
Two notations dominate ER diagram practice: Chen notation (the original) and Crow's Foot notation (an industry adaptation). Understanding both is essential for professional database work.
Chen Notation
Chen notation uses distinct shapes for different constructs:
Strengths of Chen notation:
Weaknesses:
Crow's Foot Notation
Crow's Foot notation evolved from practical industry use:
Combinations:
Which Should You Use?
Both notations express the same concepts; the choice depends on context:
Learning: Start with Chen notation. The distinct shapes for each concept build strong mental models.
Stakeholder Communication: Chen's explicit relationship diamonds help non-technical audiences.
Industry Practice: Most commercial tools default to Crow's Foot. Learn it for professional work.
Large Models: Crow's Foot is more compact, fitting more of the model on screen.
Documentation: Match the notation used in your organization for consistency.
Hybrid Approaches
Many practitioners use hybrid approaches:
The key is consistency within a project and ensuring all stakeholders can read the notation you choose.
Whatever notation you prefer, know your tools. ERD tools like Lucidchart, draw.io, MySQL Workbench, and pgModeler each have defaults and options. Spend time learning tool-specific features rather than fighting against them.
The basic ER model covers most modeling needs, but complex domains require additional constructs. The Enhanced Entity-Relationship (EER) model extends basic ER with concepts borrowed from object-oriented modeling.
Specialization and Generalization
Real-world entities often form hierarchies. An Employee might be specialized into Manager, Engineer, or Analyst. A Vehicle generalizes Car, Truck, and Motorcycle.
Specialization (top-down): Define subtypes based on distinguishing characteristics of some entities. Not all Employees are Managers—Managers have additional attributes like TeamSize and ManagerialLevel.
Generalization (bottom-up): Recognize that distinct entities share common features and create a supertype. Car and Truck both have attributes like LicensePlate, Make, and Model—generalize into Vehicle.
EER uses triangular symbols (or 'isa' notation) to show these hierarchies. The subtype inherits all attributes and relationships of the supertype.
Specialization Constraints
Disjointness: Can an instance belong to multiple subtypes?
Completeness: Must every supertype instance belong to a subtype?
These constraints have implementation implications—determining table structures during logical design.
| Constraint Type | Symbol | Meaning | Example |
|---|---|---|---|
| Disjoint | d | Subtypes are mutually exclusive | Person is Undergraduate or Graduate, not both |
| Overlapping | o | Subtypes can overlap | Employee can be Manager and Consultant |
| Total | double line | Every supertype instance is in some subtype | Every Payment is Cash, Credit, or Check |
| Partial | single line | Some supertype instances may not be in any subtype | Some Products are not in any product category |
Union Types (Categories)
A union type (or category) is a subtype with multiple possible supertypes. Unlike specialization where one supertype has subtypes, here one subtype has multiple supertypes.
Example: A BankAccount can be owned by either a Person or a Company. Owner is a union type drawing from both Person and Company supertypes.
Categories are represented by a unique union symbol (usually ∪) connecting multiple supertypes to a subtype.
Aggregation
Sometimes a relationship itself participates in another relationship. Aggregation treats a relationship as a higher-level entity.
Example: An Employee works on a Project (Works-On relationship). A Manager monitors the Works-On engagement. The Monitors relationship connects Manager to the Works-On relationship itself.
Aggregation is shown by enclosing the lower relationship and its entities in a box, then treating that box as an entity in the higher relationship.
When to Use EER
Not every model needs EER constructs. Use them when:
For simpler domains, basic ER often suffices. Adding EER constructs to models that don't need them creates unnecessary complexity.
EER hierarchies present implementation choices during logical design. A specialization can become multiple tables (one per subtype), a single table with type discriminator and NULL columns, or a combination. The EER model captures the semantics; implementation strategy is decided later.
Let's walk through constructing an ER diagram for a concrete scenario, demonstrating the process from requirements to completed diagram.
Scenario: University Course Registration System
Requirements gathered from stakeholders:
Step 1: Identify Entities
Scan requirements for nouns representing things we want to store data about:
For Semester: Do we need to store semester-specific data (start date, end date)? If yes, it's an entity. If it's just a label like "Fall 2024", it might be an attribute of Enrollment. Let's assume it's an attribute for simplicity.
Step 2: Identify Relationships
Look for verbs connecting entities:
Step 3: Determine Cardinalities
For each relationship, ask the cardinality questions:
Enrolls (Student:Course)
Teaches (Instructor:Course)
Belongs_To (Course:Department)
Works_In (Instructor:Department)
Step 4: Identify Relationship Attributes
Some relationships have their own attributes:
Enrolls has:
These attributes belong to the relationship, not to either entity—each Student-Course pair can have different Semester and Grade values.
Step 5: Determine Participation
Step 6: Draw the Diagram
With all constructs identified, create the diagram:
Your first draft won't be perfect. Review with stakeholders, find missing elements, and refine. Discovery of new requirements during diagramming is normal and valuable—it's better to find gaps now than after implementation.
Creating ER diagrams is one skill; reading and evaluating them is another. Database professionals often review diagrams created by others, and developing a critical eye helps identify problems early.
Reading an ER Diagram
Approach an unfamiliar ER diagram systematically:
Survey the entities — Get the big picture. What things does this model track? How many entities exist? This gives domain context.
Examine key attributes — For each entity, what uniquely identifies it? Are keys sensible for the domain?
Trace relationships — Follow the connections. Read them as sentences: "One Customer places many Orders." Do they make sense?
Check cardinalities — Verify that cardinalities match domain reality. A 1:1 relationship should genuinely be 1:1.
Note participation — Which participations are mandatory? Are these requirements accurate?
Look for special constructs — Weak entities, relationship attributes, ternary relationships, EER hierarchies.
Evaluation Checklist
When reviewing an ER diagram for quality, check:
Common Problems to Watch For
Fan Traps
A fan trap occurs when a model has ambiguous paths between entities. If Entity A relates to Entity B (1:N) and also relates to Entity C (1:N), but B and C also relate, which path should be used?
Example: Bank Branch has many Employees and many Accounts. But which employees work on which accounts? The relationship is ambiguous without additional structure.
Chasm Traps
A chasm trap occurs when a path between entities is lost due to optional participation. If A relates to B (partial) and B relates to C (partial), some A instances may have no path to C, even when one logically should exist.
Resolution: Add direct relationships where needed, or reconsider participation constraints.
Missing Temporal Aspects
Business domains often have time-varying relationships. An Employee works in a Department—but what if they change departments? Do we need history?
If historical tracking matters, the model needs to capture time explicitly, often by converting relationships to entities (Employment with start/end dates).
Overly Detailed Attributes
At the conceptual level, avoid operational or implementation details:
These can be added during logical/physical design.
Never review an ER diagram alone. Different perspectives catch different issues. Have stakeholders verify that the model matches their understanding. Have technical reviewers check for structural problems. Two hours of review prevents months of rework.
ER diagrams are indispensable tools for database design, providing a visual language that bridges business understanding and technical implementation. Let's consolidate what we've learned:
What's Next:
With a solid understanding of ER diagram notation and construction, we now need to sharpen our skills in the first critical modeling task: identifying entities. Entity identification is both an art and a science—the next page will provide techniques, heuristics, and practice in recognizing what should (and shouldn't) be modeled as an entity.
You now possess a comprehensive understanding of Entity-Relationship diagrams—their history, components, notations, and construction process. You can read, create, and evaluate ER diagrams at a professional level. Next, we'll master the skill of identifying entities from ambiguous requirements.