ER Diagram Symbols and Notation Explained

Every ER diagram states the same facts: the entities, their attributes, and how many rows on one side can match rows on the other. Notation is the grammar. Three families cover nearly everything you will meet: Chen, crow's foot, and UML class diagrams. Schema tools add a fourth layer of key badges, and that is what developers read daily.

Chen notation

Chen notation, published in 1976, is conceptual: it draws the model, not the tables.

• Entity: rectangle.
• Weak entity: double rectangle; it depends on another entity for identity.
• Relationship: diamond with a verb inside.
• Identifying relationship: double diamond linking a weak entity to its owner.
• Attribute: ellipse attached by a line. Key attribute: name underlined.
• Multivalued attribute: double ellipse. Derived attribute: dashed ellipse.
• Cardinality: 1, N or M written beside each entity.
• Participation: double line means mandatory, single line optional.

Chen is clear while the model is small. Twenty attributes around one rectangle become a starburst, and join tables have no natural shape, which is why tools moved to crow's foot.

Crow's foot notation

Crow's foot draws entities as boxes with their columns and puts the information at the ends of each line.

• Two bars, ||: one and only one.
• Circle and bar, o|: zero or one.
• Bar and foot, |{: one or many.
• Circle and foot, o{: zero or many.

Read each end in two layers. The symbol closest to the box is the maximum: a bar means one, the foot means many. The symbol outside it is the minimum: a bar means at least one, a circle means zero is allowed.

So customers ||——o{ orders says: at the orders end the foot means many and the circle means zero, so one customer places zero or many orders. At the customers end the bars mean exactly one, so every order belongs to one customer. The marker describes rows at its own end per one row at the other; a foot on orders does not mean orders is a large table.

An arrowhead is not a cardinality marker. It usually points from the referenced table to the referencing one, showing where the foreign key lives. Direction and cardinality are separate facts, and a complete diagram states both.

UML class diagram notation

UML class diagrams describe classes and associations, not tables. They matter because many teams design an object model first.

• Class: a box with name, attributes and operations compartments.
• Association: a solid line with a multiplicity at each end.
• Multiplicities: 1, 0..1, *, 1..*, 0..*. These map closely to crow's foot: 0..* is zero or many, 1..* is one or many.
• Aggregation: hollow diamond at the whole; the part can exist alone.
• Composition: filled diamond; the part cannot exist without the whole.
• Generalization: hollow triangle pointing at the parent class.
• Association class: a class attached by a dashed line, holding attributes of the relationship such as a grade on an enrollment.

The diamonds have no direct relational equivalent. A composition often becomes ON DELETE CASCADE, an aggregation a nullable foreign key, and neither adds a constraint the database understands by itself. Read the multiplicities, which do translate, and treat the diamonds as design intent.

How table-style ERDs show PK, FK and unique

Most schema tools drop the ellipses and diamonds. A table is a box with a column list, and three badges carry the constraints.

• PK marks part of the primary key. Two or three PK badges in one box mean a composite key and should be read as one key.
• FK marks a reference to another table. This is the child side of the edge.
• U marks a UNIQUE constraint. A U on a foreign key is the usual sign of a one-to-one.
• PK and FK on the same column is normal in a join table.

Nullability matters as much as the badges. An FK marked NOT NULL means every child row must have a parent, fixing the minimum at the parent end. A nullable FK allows an orphan by design, so the parent end becomes zero or one.

Reading cardinality labels

Tools that avoid markers print a label: 1:1, 1:N, N:1 or M:N. Read it from left to right across the two tables.

• 1:N: one row on the left matches many on the right; the foreign key sits on the right.
• N:1: the same relationship seen from the other side.
• 1:1: a foreign key with a UNIQUE constraint, or two tables sharing a primary key.
• M:N: a conceptual shortcut; the physical schema always has a join table underneath.

Min-max labels such as 0..1 and 1..* say more than 1 and N because they state the minimum. A plain N usually means zero or more, but only the schema knows for certain: a foreign key never requires a parent to have children.

A worked example in both notations

Take customers and orders. customers has id and email; orders has id, customer_id and placed_at. The foreign key is orders.customer_id, declared NOT NULL.

In Chen notation, draw a rectangle labeled customers, a diamond labeled places, and a rectangle labeled orders. The line to the diamond carries 1; the line from the diamond carries N. Attributes hang off the rectangles, with id underlined in both. The relationship has no attributes here, because placed_at belongs to the order as a thing, not to the act of placing it.

In crow's foot, draw one line from customers to orders, || at the customers end and o{ at the orders end. Read both ways: one customer places zero or many orders; each order is placed by exactly one customer.

Make customer_id nullable and one marker changes. The orders end stays o{, the customers end becomes o|: an order can exist with no customer, as in guest checkout. Nothing else moves. The marker and the schema must agree; when they do not, trust the schema.

CREATE TABLE customers (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email TEXT NOT NULL UNIQUE
);

CREATE TABLE orders (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  customer_id BIGINT NOT NULL REFERENCES customers(id),
  placed_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

ERDGenerator keeps the crow's-foot convention of one edge per relationship: the edge is labeled 1:N with the column pair id → customer_id, and an arrowhead marks the referencing end. It is the same statement as the crow's foot line, with the prongs replaced by a label.

Common mistakes

• Putting the crow's foot on the wrong end. The foot belongs where many rows live, which is the child holding the foreign key.
• Reading a foot as 'this table has many rows'. Cardinality is relative to one row on the other side.
• Ignoring the minimum. |{ and o{ both mean many; only the outer symbol says whether zero is allowed.
• Drawing M:N as a bare line, which hides the join table and its uniqueness rule.
• Treating UML aggregation and composition as key types. They become delete rules or nullable foreign keys, not new constraints.
• Mixing Chen, crow's foot and UML symbols in one diagram. Each is coherent alone; together they read as decoration.

Which notation should I use?

Crow's foot for schemas that will become tables: it shows keys, nullability and delete direction, and it fits on a screen. Chen for explaining the model to people who do not read DDL. UML when the model is genuinely object-oriented. Pick one per diagram.

What does the circle in crow's foot mean?

Zero. It is the minimum, not the maximum: o| is zero or one, o{ is zero or many. A circle never means the table itself is optional.

Is an arrow the same as a crow's foot?

No. An arrowhead marks the direction of the foreign key, pointing at the table that stores the reference. Crow's feet state cardinality. A good diagram shows both because they answer different questions.

Why does the same relationship look different in two tools?

Each tool exposes a subset: 1:N plus a column pair, ||——o{, or 1 and 0..* beside a UML association. Translate the ends rather than the shapes, and the drawings say the same thing.