Er Diagram Notation Symbols and Their Meanings Explained

When you're designing a database, every shape and line on your ER diagram carries meaning. A square means one thing, a diamond means another, and the line connecting them tells a whole story about how your data relates. Get those ER diagram notation symbols and meanings wrong, and your entire database design falls apart before you write a single query. This guide walks you through each symbol, what it represents, and how to use them correctly so your diagrams actually communicate what you intend.

What does an ER diagram actually show?

An Entity-Relationship diagram (ERD) is a visual blueprint of a database. It maps out entities (things you store data about), attributes (details describing those things), and relationships (how those things connect). Think of it as a map before you build the road system. You wouldn't start constructing highways without a plan, and you shouldn't build a database without an ER diagram.

ER diagrams exist because text-based database descriptions are hard to follow. When a team of developers, analysts, and stakeholders need to agree on a database structure, a diagram makes that conversation much easier.

What are the main ER diagram notation styles?

Before you learn the symbols, you need to know there are multiple notation standards. The symbols you use depend on which notation your team or tool follows. The most common ones are:

Chen notation the original style introduced by Peter Chen in 1976. Uses geometric shapes for entities, relationships, and attributes.
Crow's Foot notation (also called Martin notation or IE notation) popular in modern database tools like MySQL Workbench and Lucidchart. Uses lines with special endpoints to show cardinality.
UML class diagram notation borrowed from software engineering, sometimes used for database modeling.
Bachman notation an older style you'll see in legacy documentation.

Most teams today use either Chen or Crow's Foot notation, so those are what this article focuses on.

What do the basic entity and relationship shapes mean?

Entities

An entity represents a real-world object or concept you want to store data about a customer, a product, an order, a classroom.

Chen notation: Entities are drawn as rectangles. A weak entity (one that depends on another entity for identification) uses a double rectangle.
Crow's Foot notation: Entities are drawn as rectangles divided into sections the top section holds the entity name, and the sections below list attributes.

Relationships

A relationship describes how two entities interact with each other. For example, a customer "places" an order, or a student "enrolls in" a course.

Chen notation: Relationships are drawn as diamonds or rhombuses placed on the connecting line between two entities. A weak relationship uses a double diamond.
Crow's Foot notation: Relationships are represented by the connecting line itself between entities, with endpoint symbols showing the nature of the relationship. No diamond shape is used.

Attributes

Attributes are properties that describe an entity. A "Customer" entity might have attributes like name, email, and phone number.

Chen notation: Attributes are ovals connected to their entity by a line. An attribute that serves as a primary key has its name underlined. A multi-valued attribute uses a double oval. A derived attribute (calculated from other attributes, like age from birthdate) uses a dashed oval.
Crow's Foot notation: Attributes are listed as text rows inside the entity rectangle. Primary key attributes are typically marked with "PK" and shown at the top.

What do cardinality and participation symbols mean?

Cardinality answers the question: "How many instances of Entity B can be associated with one instance of Entity A?" This is where most beginners get confused, so pay close attention.

Chen notation cardinality

In Chen notation, cardinality is usually written as a number or letter on the relationship line near each entity:

1 one (and only one)
N many (one or more)
M many (used on the other side of a many-to-many relationship)

So a line labeled "1" on one side and "N" on the other means a one-to-many relationship one department has many employees.

Crow's Foot notation cardinality

Crow's Foot uses line-end symbols to show cardinality. These are the core symbols you need to memorize:

Single line (||) exactly one (mandatory one)
Circle with line (o|) zero or one (optional one)
Crow's foot (>| or three-pronged fork) one or more (mandatory many)
Circle with crow's foot (o<) zero or more (optional many)

The single line side of a relationship always faces the "one" side. The crow's foot always faces the "many" side.

Participation constraints

Participation tells you whether every instance of an entity must participate in a relationship.

Total participation (Chen: double line) every instance must be involved. Every employee must belong to a department.
Partial participation (Chen: single line) some instances may not be involved. Not every customer has placed an order yet.

In Crow's Foot notation, total participation is shown with the mandatory symbol (single line or ||), while partial participation uses the optional symbol (circle with line).

Understanding the difference between cardinality and participation in large-scale systems prevents costly redesigns later.

What do the different relationship types look like?

One-to-One (1:1)

Each instance of Entity A relates to exactly one instance of Entity B, and vice versa. Example: each country has one capital city.

Chen: "1" on both sides of the relationship diamond
Crow's Foot: single line (||) on both ends of the connecting line

One-to-Many (1:N)

Each instance of Entity A relates to multiple instances of Entity B, but each B relates to only one A. Example: one author writes many books.

Chen: "1" on the one side, "N" on the many side of the diamond
Crow's Foot: single line (||) on the one side, crow's foot on the many side

Many-to-Many (M:N)

Multiple instances of Entity A relate to multiple instances of Entity B. Example: students enroll in many courses, and courses have many students.

Chen: "M" on one side, "N" on the other side of the diamond
Crow's Foot: crow's foot symbols on both ends of the connecting line

In actual relational databases, many-to-many relationships are resolved using a junction table (also called an associative entity or bridge table). The ER diagram should reflect this during the physical design phase.

What do specialized symbols mean in ER diagrams?

Beyond the basics, several specialized symbols appear in more detailed ER diagrams:

Weak entity (double rectangle): An entity that can't be uniquely identified by its own attributes alone. It depends on a "strong" or owner entity. Example: an order line item that only makes sense in the context of an order.
Identifying relationship (double diamond): The relationship between a weak entity and its owner entity.
Composite attribute: An attribute that breaks into sub-attributes. Example: "address" breaks into street, city, state, zip. In Chen notation, connected with a smaller oval branching off.
Multi-valued attribute (double oval): An attribute that can hold multiple values. Example: a person with multiple phone numbers.
Derived attribute (dashed oval): A value calculated from other stored data. Example: age derived from date of birth.
Total specialization (double line to circle): In generalization/specialization hierarchies, every superclass instance must belong to a subclass.
Partial specialization (single line to circle): A superclass instance may or may not belong to any subclass.

How do I read a real ER diagram with these symbols?

Let's put it together with a practical example. Imagine a simple library database:

A Member entity (rectangle) has attributes like MemberID (underlined as primary key in Chen notation, or marked PK in Crow's Foot), Name, and Email. A Book entity has BookID, Title, and ISBN. A Borrow relationship connects them.

In Chen notation, you'd see: Member (rectangle) Borrow (diamond) Book (rectangle), with "M" near Member and "N" near Book, indicating a many-to-many relationship. Attributes hang off each entity as ovals.

In Crow's Foot notation, the same structure shows Member and Book as rectangles with attributes listed inside. The connecting line has a crow's foot at both ends (or near both ends), showing many-to-many. Mandatory or optional symbols tell you whether a member must have borrowed a book to exist in the system.

Getting comfortable reading these diagrams is a skill that improves with practice. As you work through best practices for database normalization, you'll start spotting design patterns quickly.

What are the most common mistakes people make with ER diagram symbols?

Mixing notation styles. Using Chen diamonds alongside Crow's Foot line endings confuses everyone. Pick one standard and stick with it throughout your diagram.
Confusing cardinality with participation. Cardinality is about "how many" (one or many). Participation is about "must or may" (mandatory or optional). They answer different questions.
Forgetting weak entities. If an entity can't exist without its parent, it needs a double rectangle and an identifying relationship. Skipping this leads to flawed primary key designs.
Overcrowding diagrams. Cramming 20 entities into one diagram makes it unreadable. Break large systems into smaller, focused sub-diagrams.
Ignoring attribute types. Not marking primary keys, multi-valued attributes, or derived attributes creates ambiguity. The next person to read your diagram will guess wrong.
Not labeling relationships. An unlabeled line between "Customer" and "Product" could mean "buys," "reviews," "wishes for," or anything else. Always add a clear verb phrase.

Which ER notation should I use for my project?

There's no single right answer, but here's a practical breakdown:

Use Chen notation if you're teaching, learning, or presenting conceptual models to a non-technical audience. The shapes are intuitive and self-explanatory.
Use Crow's Foot notation if you're building an actual database and working with tools like MySQL Workbench, Microsoft Visio, dbdiagram.io, or Lucidchart. It's more compact and widely supported.
Use UML notation if your team already uses UML for software design and wants consistency across documentation.

Whatever you choose, make sure everyone on the team agrees before you start drawing. Document your notation choice at the top of your diagram or in your project's style guide.

If you're working on a large project, reviewing advanced cardinality notation for large-scale systems will help you handle complex scenarios like ternary relationships and recursive associations.

Quick reference: ER diagram symbol cheat sheet

Here's a summary you can reference while working:

Rectangle Entity (Chen & Crow's Foot)
Double rectangle Weak entity (Chen)
Diamond Relationship (Chen)
Double diamond Identifying relationship (Chen)
Oval Attribute (Chen)
Double oval Multi-valued attribute (Chen)
Dashed oval Derived attribute (Chen)
Underlined text Primary key attribute
|| Exactly one (Crow's Foot)
o| Zero or one (Crow's Foot)
crow's foot One or more (Crow's Foot)
o< Zero or more (Crow's Foot)
Double line Total participation (Chen)
Single line Partial participation (Chen)

For a deeper look at the foundational research behind ER modeling, the original paper by Peter Chen remains a solid reference.

Next step: Practice with a real scenario

Pick a system you know well a bookstore, a gym membership system, a food delivery app and sketch out an ER diagram using at least five entities. Label every symbol correctly using one notation standard. Share it with a colleague and ask if they can read it without explanation. If they can, your notation is working. If they can't, refine your labels and symbols until the diagram speaks for itself.