Loading learning content...
Every discipline has its visual notation—architects use floor plans, electrical engineers use circuit diagrams, and database designers use Entity-Relationship diagrams. These visual languages work because they compress complex information into standardized symbols that practitioners can instantly recognize and reason about.
An ER diagram consists of a finite set of components: entities, attributes, relationships, cardinalities, and constraints. Each has a precise visual representation and semantic meaning. Mastering these components means you can both read any ER diagram you encounter and create diagrams that clearly communicate your database designs.
This page is your comprehensive reference to ER diagram components. We'll examine each element in depth: what it means, how it's drawn, when to use it, and how different notation styles represent it.
By the end of this page, you will understand every component of ER diagrams—entities, attributes (simple, composite, derived, multivalued, key), relationships, cardinality ratios, and participation constraints. You'll be able to read diagrams in multiple notation styles and choose appropriate symbols for your own models.
An entity represents a distinguishable thing in the real world that the database will track. Entities can be concrete (Person, Product, Building) or abstract (Appointment, Transaction, Policy). The key criterion is that instances of the entity can be uniquely identified and independently exist.
| Notation Style | Regular Entity Symbol | Weak Entity Symbol | Notes |
|---|---|---|---|
| Chen notation | Rectangle | Double rectangle | Most explicit; weak entities visually distinct |
| Crow's foot (IE) | Rectangle | Rectangle (contextual) | Weak entities inferred from identifying relationships |
| IDEF1X | Square-cornered box | Rounded-corner box | Dependent entities have rounded corners |
| UML Class Diagrams | Class box with name compartment | Stereotype «weak» | Uses object-oriented class notation |
Regular entities vs. weak entities:
Regular (strong) entities have an attribute or combination of attributes that uniquely identifies each instance. A Customer entity might have CustomerID; each customer has a unique ID regardless of their relationships to other entities.
Weak entities cannot be uniquely identified by their own attributes alone. They depend on a related owner entity for identification. Consider:
Weak entities always have a total participation in an identifying relationship with their owner entity—they cannot exist without that relationship.
Ask: 'Can this entity be uniquely identified by its own attributes alone?' If the answer is no—if you need to know 'which Order' or 'which Building' to identify it—you likely have a weak entity. Weak entities are extremely common: line items, room numbers, transaction details, dependent persons.
Entity naming conventions:
Professional ER diagrams follow consistent naming rules:
Attributes are properties that describe entities (or relationships). They represent the data values associated with each instance. A Customer entity might have attributes like Name, Email, PhoneNumber, and DateOfBirth.
Attributes come in several varieties, each with specific semantics and notation:
| Attribute Type | Chen Notation Symbol | Description |
|---|---|---|
| Simple attribute | Oval connected to entity | Basic attribute, no special marking |
| Composite attribute | Oval with sub-ovals connected | Parent oval branches to component ovals |
| Multivalued attribute | Double oval | Double ellipse border indicates multiple values |
| Derived attribute | Dashed oval | Dashed border indicates computed value |
| Key attribute | Underlined name in oval | Underline distinguishes identifying attributes |
| Composite key | Multiple underlined ovals | Multiple attributes together form the key |
Composite vs. simple: when to decompose?
Should Address be one attribute or a composite of Street, City, State, PostalCode, Country? The answer depends on your query requirements:
A general rule: decompose if components will be independently accessed, validated, or queried. Keep simple if always treated as a unit.
Multivalued attributes and normalization:
Multivalued attributes like PhoneNumbers are conceptually convenient but create implementation challenges. In relational design, they typically become:
At the conceptual level, showing multivalued attributes is correct and informative. The implementation decision comes later.
Derived attributes in conceptual models:
Including derived attributes clarifies that these values exist in the domain, even though they're computed. Showing Age (derived from DateOfBirth) documents that age is a meaningful concept. The implementation—whether stored and maintained or computed on-demand—is a later decision.
In crow's foot and many modern notations, attributes are listed inside entity rectangles rather than as external ovals. Key attributes are marked with 'PK' (primary key). This notation is more compact but loses some semantic richness—composite and derived attributes may not be visually distinguished. Use the notation your tools and organization prefer, but understand the underlying concepts.
Relationships represent associations among entities. They capture how entities in a database connect to each other. Understanding relationships—their names, degrees, attributes, and constraints—is essential to building accurate ER models.
| Notation Style | Standard Symbol | Identifying Relationship | Notes |
|---|---|---|---|
| Chen notation | Diamond connected by lines | Double diamond | Relationship names written inside diamond |
| Crow's foot (IE) | Line between entities | Solid line to dependent | Cardinality shown at line ends |
| IDEF1X | Line between entities | Solid line vs dashed line | Different line styles indicate identifying vs non-identifying |
| UML | Association line | Composition diamond | Navigation arrows optional; multiplicities at ends |
Relationship degree (arity):
The degree of a relationship is the number of entity types participating:
Binary relationships dominate in real models. Ternary relationships are occasionally necessary when the combination of three entities has meaning not captured by pairwise relationships. Higher-arity relationships are almost never used.
Relationship attributes:
Relationships can have their own attributes that don't logically belong to either participating entity:
In Chen notation, relationship attributes are ovals connected to the relationship diamond. In crow's foot notation, if the relationship has attributes, it often gets promoted to an associative entity (a rectangle connected by relationships to both participants).
Relationship names should read naturally as verb phrases between entity names. 'Customer PLACES Order' reads smoothly. 'Customer ORDER_RELATIONSHIP Order' does not. Some designers also add an inverse reading: 'Order IS_PLACED_BY Customer.' Choose names that domain experts would use when describing their business.
Identifying vs. non-identifying relationships:
An identifying relationship connects a weak entity to its owner. The weak entity's primary key includes the owner's key. In Chen notation, this is shown as a double diamond connected to a double rectangle.
A non-identifying relationship connects entities that are independently identifiable. The foreign key is present but not part of the receiving entity's primary key.
This distinction is crucial for key design and cascade behavior in the physical model.
Cardinality ratio (also called cardinality constraint or mapping cardinality) specifies the maximum number of entity instances that can participate in a relationship. It answers: 'For one instance of Entity A, how many instances of Entity B can be related?'
| Ratio | Meaning | Example | Implementation Note |
|---|---|---|---|
| 1:1 (One-to-One) | Each A relates to at most one B; each B relates to at most one A | Person HAS Passport; Employee HAS ParkingSpot | Foreign key can go on either side; often merged tables |
| 1:N (One-to-Many) | Each A can relate to many B; each B relates to at most one A | Department EMPLOYS Employees; Customer PLACES Orders | Foreign key on the 'many' side pointing to 'one' side |
| M:N (Many-to-Many) | Each A can relate to many B; each B can relate to many A | Student ENROLLS_IN Course; Author WRITES Book | Junction/bridge table required in relational design |
Cardinality notation styles:
Different ER notations represent cardinality differently:
Chen notation:
Crow's foot (Information Engineering):
Min-max notation (ISO):
UML multiplicities:
Cardinality is always read FROM one entity TO another. In 'Department EMPLOYS Employee (1:N)', read: 'One Department employs Many Employees' AND 'One Employee is employed by One Department.' The ratio describes BOTH directions. Beginners often misread cardinality by only considering one direction.
While cardinality specifies the maximum number of relationships, participation constraints specify whether relationships are mandatory or optional. Participation answers: 'Must every instance of this entity participate in this relationship?'
| Type | Also Called | Meaning | Example |
|---|---|---|---|
| Total participation | Mandatory, Existence dependency | Every entity instance MUST participate in the relationship | Every OrderLine MUST belong to an Order; an OrderLine cannot exist without an Order |
| Partial participation | Optional | Entity instances MAY but don't have to participate | An Employee MAY manage other Employees; not every employee is a manager |
Notation for participation:
Chen notation:
Crow's foot notation:
Min-max notation:
Examples with participation:
Department EMPLOYS Employee
Order CONTAINS OrderLine
Customer PLACES Order
Participation constraints capture business rules. 'Every employee must be assigned to exactly one department' is a total participation rule. 'A department may have zero employees' (perhaps during reorganization) is a partial participation rule. Get these rules from domain experts, not from assumptions.
Combining cardinality and participation:
Full relationship semantics require both cardinality and participation. Consider Employee WORKS_FOR Department:
This gives us:
Read: 'Each Employee works for exactly one Department; each Department has zero to many Employees.'
Weak entity participation:
Weak entities always have total participation in their identifying relationship. An OrderLine cannot exist without an Order. A Room cannot exist without a Building. This is inherent to the concept of weak entities—they depend on their owner for existence and identification.
Beyond basic binary relationships, ER modeling supports several special relationship patterns that capture more complex real-world semantics.
Recursive relationship detail:
Recursive relationships require role names to clarify which role each entity instance plays:
Without role names, the diagram is ambiguous. Role names are placed on the relationship lines near the entity.
Cardinality in recursive relationships:
Ternary relationship detail:
Ternary relationships capture situations where binary relationships lose information:
The ternary SUPPLIES(Supplier, Part, Project) captures this three-way association directly. Cardinality in ternary relationships specifies: 'Given instances of two entities, how many of the third can relate?'
Use ternary relationships only when the three-way combination has meaning that pair-wise relationships cannot capture. If binary relationships suffice (possibly with a junction entity), prefer them—ternary relationships are harder to read and implement. But don't force binaries if they lose information.
As introduced in the history page, multiple ER notations exist. Here's a practical comparison to help you work with whichever notation your organization or tools use:
| Element | Chen | Crow's Foot | IDEF1X | UML |
|---|---|---|---|---|
| Entity | Rectangle | Rectangle | Rectangle | Class box |
| Weak Entity | Double rectangle | Rectangle + context | Rounded rectangle | «weak» stereotype |
| Attribute | Oval connected | Listed inside entity | Listed inside entity | Listed in class |
| Key attribute | Underlined in oval | PK marker | Marked specifically | «PK» or {id} |
| Relationship | Diamond | Line only | Line only | Association line |
| Cardinality | 1/N labels | Crow's feet symbols | Cardinality markers | Multiplicities (1..*) |
| Participation | Single/double line | O/| at ends | Solid/dashed line | 0..* vs 1..* |
| Relationship attribute | Oval on diamond | Associative entity | Associative entity | Association class |
Practical guidance:
Learn Chen notation first: Its explicitness helps build conceptual understanding. Once you truly understand what each element means, translating to other notations is mechanical.
Use crow's foot in practice: Industry tools predominantly support it. Your colleagues and clients will likely expect it.
Be notation-fluent: A professional database designer should read any common notation. Don't be the person who can't understand a diagram because it uses unfamiliar symbols.
Be consistent within a project: Don't mix notations in the same diagram or document set. Choose one and stick with it.
Include a legend: For any diagram that will be shared, include a notation key/legend. Never assume readers know your notation style.
Your ER diagramming tool often determines notation. ERwin uses crow's foot. Lucidchart supports multiple notations. MySQL Workbench uses its own variant. Draw.io lets you choose. Pick tools that support your organizational standards, or adapt to what your tools offer.
You now understand the complete set of components that comprise ER diagrams. These building blocks combine to express arbitrarily complex data models. Let's consolidate the key elements:
What's Next:
With the component vocabulary mastered, we'll next explore the Modeling Process—the step-by-step methodology for creating ER diagrams from requirements. You'll learn how to systematically identify entities, define relationships, and capture constraints to build complete, accurate conceptual models.
You now have comprehensive knowledge of ER diagram components. You can identify and describe entities, attributes, relationships, cardinalities, and participation constraints in any common notation. This vocabulary is essential for both creating your own ER diagrams and understanding diagrams created by others. Next, we'll put these components to use in a systematic modeling methodology.