Direct answer
An ER diagram is a visual model of the entities a system stores, their attributes, and the relationships between them. It helps a team agree on data structure before building or changing a relational database.
Summary
Read an entity relationship diagram in three passes. First identify the entities, such as Customer, Order, and Product. Then inspect their attributes and keys. Finally trace each relationship and read its minimum and maximum cardinality. The notation may change, but the model must still explain what the system stores, how records are identified, and which business rules connect them.
- Entity
- a person, object, event, role, or concept the system records.
- Attribute
- a fact stored about an entity.
- Relationship
- an association between entities.
- Cardinality
- how many instances may or must participate.
- Key
- an attribute or attribute set that identifies or references a record.
What is an ER diagram?
ER diagram means entity relationship diagram. You may also see ERD, E-R diagram, entity-relationship diagram, ER model, or database ER diagram. Each name describes a visual model that connects the important things in a data domain. A commerce model may contain Customer, Order, Product, and Order Item. A learning system may contain Student, Course, and Enrollment.
Peter Chen introduced the entity-relationship model and a diagramming technique for database design in a 1976 paper. Modern tools use several notations and often show tables and columns rather than the original ovals and diamonds. The purpose remains the same: make the structure and meaning of data visible before those decisions are buried in application code or database definitions.
Read the record for Peter Chen’s original entity-relationship model paper.
What an ER diagram is for
Use an ER diagram when a team needs to design or understand a relational database. It can also support migration discussions, data ownership reviews, and domain explanations. This shared view creates a place to question assumptions. Does an order exist without a customer? May a product belong to several categories? Must every asset have one owner? Those questions are easier to resolve before implementation.
An ERD is not the database itself and does not prove that a design is correct. It may omit indexes, permissions, triggers, partitioning, storage choices, and application behavior. Treat it as a model with a declared scope. A high-level model helps a mixed audience discuss concepts; a physical model helps engineers discuss tables, columns, data types, and constraints.
The four parts of an ER diagram
Entities
An entity is something the system needs to distinguish and store facts about. Name entity types with clear singular nouns, such as Customer or Invoice. Each row or instance is one particular customer or invoice. A strong entity has enough identifying information to stand on its own. A weak entity depends on an owner entity for its identity or existence, as an Order Item depends on an Order.
Attributes
Attributes describe an entity. Customer may have customer_id, name, and email; Order may have order_id, placed_at, and status. Decide whether each value is required, whether it can repeat, and whether it belongs to this entity. A value that can occur several times, such as multiple phone numbers, often deserves a related entity rather than a repeating field.
Relationships
A relationship states how entity types are associated. Name it so the model reads as a sentence. A Customer places an Order. An Order contains an Order Item. An Order Item references a Product. Clear verbs expose vague or overloaded connections. If two entities have more than one relationship, label each one separately.
Cardinality and participation
Cardinality says how many instances can be connected. One-to-one links one instance on each side. One-to-many links one parent to several children. Many-to-many allows several instances on both sides and normally becomes an associative entity or junction table in a relational schema. Minimum cardinality also matters: zero means optional participation, while one means the relationship is required.
Symbols and notation
Do not read a model by shape alone. First find the legend or identify the notation. The same concept can look different in Chen, Crow’s Foot, and table-style models. Keep one notation within a diagram unless a visible legend explains the mix.
Classic notation
In Chen notation, rectangles represent entities, ovals represent attributes, diamonds represent relationships, and lines show participation. Variants use doubled shapes for weak entities, identifying relationships, or multivalued attributes. This notation is useful when the conceptual meaning of the domain matters more than table implementation.
Crow’s Foot notation
Crow’s Foot notation usually places attributes inside entity boxes and puts cardinality marks at relationship endpoints. A bar represents one, a circle represents zero or optional, and the three-pronged foot represents many. Read both ends. A circle plus foot means zero or many; a bar plus foot means one or many.
Table or physical notation
A physical diagram often resembles a database schema. Each box is a table, each row is a column, and labels mark primary keys, foreign keys, nullability, or data types. Relationship lines usually connect a foreign key to the key it references. This view is closer to implementation but may hide the plain-language business rule unless relationships are named.
Primary keys, foreign keys, and integrity
A primary key uniquely identifies a row. It can be one column or a combination of columns, and its values must be unique and not null. A foreign key requires a value to match a referenced key in another table, which maintains referential integrity between the related tables. A physical relational design should make both roles visible.
Check PostgreSQL’s official explanation of primary and foreign key constraints.
A many-to-many relationship needs special attention. If an Order contains many Products and a Product can appear in many Orders, use Order Item as the associative entity. It holds references to Order and Product plus facts about that pairing, such as quantity and price at purchase. This turns one ambiguous many-to-many relationship into two clear one-to-many relationships.
Conceptual, logical, and physical ER models
Conceptual model
A conceptual model shows the main entities and relationships in language a broad audience can discuss. It answers what the domain contains and how its major concepts connect. Keep implementation details out unless they affect the decision.
Logical model
A logical model adds attributes, identifiers, cardinality, and normalization decisions without committing to one database product. It should be detailed enough to test business rules and translate into a relational schema.
Physical model
A physical model describes the planned or existing database implementation. It may include actual table and column names, data types, primary and foreign keys, nullability, and product-specific details. MySQL Workbench, for example, can forward-engineer a physical model into SQL or reverse-engineer an existing database into a model.
Review MySQL Workbench’s official forward- and reverse-engineering guide.
How to read an ER diagram
Start with the title, scope note, and legend. Identify the central entities and describe each in one sentence. Next find the primary key for each entity and scan the attributes. Then follow one relationship at a time, reading the verb and both cardinality endpoints. Turn the line into a business rule: one Customer may place zero or many Orders; every Order belongs to exactly one Customer.
Test the rule with edge cases. Does a customer exist before an order? Could an order contain no items? Is the same product allowed twice in one order? What happens when a referenced record is removed? The model may reveal the intended rule, but the database constraints and application behavior decide what is actually enforced.
A practical ER diagram example
Consider a small shop with Customer, Order, Order Item, and Product. Customer uses customer_id as its primary key. Order uses order_id and stores customer_id as a foreign key. Product uses product_id. Order Item references both order_id and product_id and stores quantity and unit_price.
The model reads as four rules. One Customer may place many Orders, while each Order belongs to one Customer. One Order contains one or more Order Items. Each Order Item references one Product. One Product may appear in many Order Items. Order Item resolves the many-to-many relationship between Order and Product. It also preserves facts that belong to the purchase rather than the product itself.
This simplified diagram still needs decisions. Is a guest checkout allowed? Can quantity be zero? Should an order keep the historical unit price if the product price changes? Is product deletion allowed after purchase? Record those rules beside the model, then express enforceable parts as constraints and test the rest in application behavior.
A short ER diagram workflow
Begin with a bounded question, not a blank canvas. Write several real scenarios and list the nouns that must retain data. Merge synonyms, separate values from entities, and give each remaining entity a stable identity. Add relationships as plain-language verbs, then state minimum and maximum participation at both ends.
Add only attributes needed for the current decision. Resolve many-to-many relationships with associative entities when moving toward a relational design. Review the model with both a domain expert and an implementer. Finally compare the diagram with sample records or the live schema, and version it beside the code or database changes it explains.
When a database already exists, reverse engineering can create a useful starting view, but generated structure does not explain every business rule or naming choice. Add scope, relationship names, and notes after import. A diagram that merely mirrors tables can still leave readers unsure why the structure exists.
Common ER diagram mistakes
The most damaging mistake is drawing relationships without their business rules. A line between Customer and Order is incomplete until readers know the verb, cardinality, and optionality. Other problems include inconsistent names, several values in one attribute, and entities without identifiers. Mixing conceptual and physical detail without a legend also causes confusion.
Do not force the whole organization onto one canvas. Split a large model by bounded context or audience and keep a small overview that shows how the parts connect. Avoid decorative color that competes with the notation. For a published diagram, provide a complete text equivalent of the important entities and relationships so readers do not depend on the image alone.
Use the W3C guidance for accessible complex images and diagrams.
ERD, schema, UML, or data flow?
Choose an ER diagram to explain stored data and relationships. Choose a database schema view when implementation details such as tables, columns, and constraints are the main subject. Choose UML when you need to model broader software structure or behavior. Choose a data flow diagram when the question is how data moves between people, processes, and stores. These diagrams can complement one another, but they answer different questions.
Frequently asked questions
The letters ER stand for entity relationship. ERD, E-R diagram, ER model, and entity-relationship diagram are common variants. They describe a visual model of entities, their attributes, and the relationships between them.
The symbols depend on the notation. Classic models commonly use rectangles for entities, ovals for attributes, diamonds for relationships, and lines for participation. Crow’s Foot notation places attributes in entity boxes and uses endpoint marks for zero, one, and many. Check the legend before interpreting an unfamiliar model.
No. An ER diagram is a model of entities and relationships and can stay conceptual or logical. A database schema defines implemented structures such as tables, columns, types, and constraints. A physical ER diagram may closely resemble the schema, but the two artifacts still have different roles.
EER means enhanced or extended entity-relationship model. It adds concepts such as subtypes, supertypes, inheritance, categories, or more detailed constraints to the basic ER model. Some tools also use EER as their general name for a database modeling diagram. Check the tool’s definition before assuming a specific notation.
Yes. Database modeling tools can reverse-engineer tables, keys, and relationships into a diagram. The result documents implemented structure, but you should still add scope, relationship names, and business-rule notes. Generated diagrams cannot infer every intention behind the schema.
Model one small domain
Choose one workflow with three to six entities. Write a sentence for each relationship, add minimum and maximum cardinality at both ends, and identify every entity’s key. Test the model with one normal case and two edge cases. If the team cannot read the rules aloud without guessing, revise the names or notation before adding more detail.