Chen notation vs crow's foot vs UML: ERD notations compared

Every ER diagram carries the same cargo: which tables exist, which columns link them, and the how many rule on each connection. A notation is just the drawing dialect for that last part - and there are exactly three you'll run into: Chen, crow's foot, and UML class diagrams.

Same schema, three dialects. Learn to read one relationship in each, and no diagram can slow you down again.

The example every notation has to carry

One rule, stated in the cheat sheet's shorthand:

users ||--o{ orders

Each order belongs to exactly one user; a user can have zero or many orders - backed by a foreign key orders.user_id → users.id that's nullable precisely because the ring allows zero. If a notation can't say that at a glance, it costs more than it buys. (The symbol-by-symbol reading lives in the crow's foot notation cheat sheet.)

Chen: the 1976 original

Peter Chen's paper gave ER diagrams their name, and his notation makes relationships the star of the drawing:

• Rectangles are entities - users, orders.
• Diamonds are relationships - drawn between the entities and named: places.
• Ovals are attributes, hanging off their entity, primary key underlined.
• Cardinality is written as bare numbers beside the line: 1 toward users, N toward orders.

The diamond earns its board space when the relationship itself has data - places can carry ordered_on without any new table. That's also why many-to-many feels at home in Chen: one diamond, no junction table in sight.

Why practice moved on anyway: ovals don't scale. A ten-column table means ten ovals, and a forty-table schema becomes wallpaper. Chen survives where the audience expects it - textbooks, papers, and system-design exams.

Crow's foot: the working default

Crow's foot keeps Chen's boxes and deletes the ceremony. Attributes move into rows inside the box, the named diamond disappears, and the cardinality shrinks to four little endings drawn straight on the line - tick means one, foot means many, ring means optional.

Two consequences worth noticing:

1. The relationship loses its name. The foreign key column (user_id) is the relationship; naming it again would be noise.
2. Many-to-many gets resolved, not drawn. Chen draws the diamond; crow's foot makes you put a junction table in the middle - which is the honest answer anyway, since the junction is what you'll build in SQL.

That legibility is why it won. A crow's foot diagram reads out loud one line at a time, which is exactly what a review needs - the five-step FigJam walkthrough is built on that habit.

UML class diagram: the coder's dialect

UML boxes look like crow's foot boxes - rows of typed attributes - but the conventions come from object-oriented modeling, not databases:

• Cardinality is written as multiplicity numbers at the line's ends: 1 at the User end, 0..* at the Order end. The number describes the far end, so you read across the line - the same walk-the-line habit as crow's foot, wearing numbers instead of symbols.
• Attributes are camelCase (userId, not user_id), because UML is drawn by and for people looking at code.
• Classes can carry methods, and arrows show navigability - ideas ER diagrams deliberately leave out.
• A relationship with data of its own becomes an association class - the UML answer to Chen's diamond.

You'll meet UML in architecture docs, Java and C# teams, and CS courses - often drawn by the same people who own the code, which is why the attribute names look like the DTOs.

Side by side

	Chen	Crow's foot	UML
Entities	rectangles	boxes with column rows	classes with typed attributes
Relationships	named diamonds	symbols on the line	lines with multiplicity
Cardinality	1, N, M beside the line	tick / foot / ring endings	1, 0..*, 1..* at the ends
Attributes	ovals hanging off	rows inside the box	typed rows (+ methods)
Many-to-many	one diamond, no junction	junction table in the middle	association class
Where you'll meet it	textbooks, papers, exams	team sketches, most ERD tools	architecture docs, OO code

Which one should you draw?

Match the dialect to the audience:

• Sketching with a team - crow's foot. It reads out loud, and the review is the point.
• Writing a paper or sitting an exam - Chen. It's the dialect your reader was graded on.
• Documenting a codebase - UML, so the diagram and the DTOs share a vocabulary.

And the part none of them change: the discipline underneath. Entities before columns, keys that keep the lines truthful, cardinality you can read as an English sentence - that's database schema design basics, and it's identical in all three dialects. Notation is presentation. Picking the one your audience reads beats arguing about it.

Frequently asked questions

Is a UML class diagram an ER diagram?

Not quite. A UML class models behavior - attributes plus methods; an ERD models data - tables, keys, constraints. The vocabularies overlap enough that teams translate between them, but you hand an ERD to a DBA and a class diagram to a developer.

Is Chen notation still used?

In textbooks, papers and exams - constantly. In day-to-day product work, crow's foot won, mostly because ovals don't scale. Tools offering "Chen support" usually mean the diamond shape, not the full 1976 spec.

What notation does FigSchema use?

Crow's foot - the four line endings, drawn on the relationship as you connect two exact columns. It's the dialect that reads fastest in a review, which is when diagrams earn their keep.

Read all three, draw one

Reading the dialects is a party trick; drawing a diagram that survives the design review is the actual skill. If you sketch in FigJam, FigSchema draws crow's foot for you - drag between two exact columns, pick the cardinality, and the symbols stay truthful while the diagram moves. Free, and offline.