There are several ERD notations, which is confusing at first — but what you'll actually read and write at work is almost always crow's foot (IE). This guide spends most of its length making sure you know every crow's foot symbol without gaps, then compares Chen (the one from school) and Barker (the one in Oracle documents) on the same example.
Why several notations exist takes two sentences: academia (Chen, 1970s) invented the concepts, and then working tools reshaped them into something that fits on a screen (IE). That's why the diagrams you studied and the diagrams you work with look different.
Crow's foot notation explained
The main event. In IE (Information Engineering) notation there are exactly two things to learn: the symbols at the ends of the line, and the kinds of line. Master these and you can read any ERD put in front of you.
ERD cardinality symbols cheat sheet
First, a reframe: the marks at the line ends aren't arrows. They're cardinality symbols — counts. There are only three parts:
| Symbol | Meaning |
|---|---|
bar | |
one |
circle ○ |
zero (optional) |
| crow's foot (three prongs) | many (N) |
On a real line, these parts appear two at a time. The reading order is the whole trick: the inner symbol (toward the middle of the line) is the minimum, and the symbol touching the entity is the maximum. Only four combinations exist:
||exactly one — that row must exist, exactly once.○|zero or one — may be absent; at most one.|<one or many (1..N) — at least one must exist.○<zero or many (0..N) — none, one, or many.
The two kinds of line
The line itself carries meaning too. A solid line is an identifying relationship: the parent's key becomes part of the child's primary key, as in an order item whose PK is the composite (order_id, product_id). A dashed line is non-identifying: the parent's key is referenced as a plain FK column, like posts referencing members through member_id — the most common shape in practice.
When you're starting out, reading the end symbols correctly matters before the solid/dashed distinction does. The distinction becomes relevant the day you design composite keys.
Reading drill 1: how is a 1:N relationship written?
Time to practice on the forum database. The line between members and posts looks like this:
MEMBER ||──────○< POSTStart at the member end. From a post's point of view, its member is || — exactly one. At the other end, from a member's point of view, posts are ○< — zero or many. Put together: "every post belongs to exactly one member; a member may have no posts or many." That's the standard shape of the everyday 1:N relationship.
Reading drill 2: when the minimum changes
Orders and order items look slightly different:
ORDER ||──────|< ORDER_ITEMThe order-item end is |<, not ○<. The minimum is one, not zero. Read: "an order item belongs to exactly one order, and an order must have at least one item." A business rule — no empty orders — encoded in a single symbol. Miss the difference between ○< and |< and that rule silently disappears from the picture.
Reading drill 3: zero or one
A shape you'll meet in one-to-one territory, like members and profiles:
MEMBER ||──────○| PROFILEThe profile end is ○| — zero or one. "A member may have no profile, and never more than one."
Reading drill 4: when a dashed line joins in
This time, read the line style along with the ends. Posts and members drawn with a dashed line:
MEMBER ||- - - - ○< POSTThe end symbols match drill 1, so the counts are the same. What changed is the dashed line — a non-identifying relationship. You can now read one level deeper: "posts reference the member's key as a regular column (member_id), and that column is not part of the post's primary key." Had the line been solid, member_id would be part of the post's PK. One line style, a different key design.
Reading drill 5: what many-to-many actually looks like
Finally, the shape many-to-many takes in real diagrams. Posts and tags in N:M are usually drawn with a junction table in the middle:
POST ||──────○< POST_TAGS >○──────|| TAGRead each side of the junction table separately: one post has zero or many post_tags rows, and one tag also has zero or many. Two 1:N relationships combine into "a post has many tags, a tag has many posts." When you see this hourglass shape in a diagram, read it as a resolved many-to-many.
If you got through all five drills, you've now read every combination IE will show you. What remains is repetition on real diagrams — and the forum walkthrough in How to Draw an ERD picks up exactly there.
Three misreadings to watch for
While we're at it, the misreadings that show up most often in design reviews:
Reading the symbols as arrows. The crow's foot looks like an arrowhead, so people read it as "data flows this way." It isn't direction — it's count. The forked side simply means many.
Swapping minimum and maximum. Read ○< as "at most zero" and the whole relationship flips. The inner symbol is always the minimum, the one touching the entity the maximum. When in doubt, check the symbol touching the entity first.
Confusing cardinality with FK placement. In "one member : N posts," the FK (member_id) always lives on the N side — the posts table. If a diagram seems to show the FK on the one side, suspect you've read the relationship backwards before suspecting the diagram.
Chen notation: the one from school
If you remember drawing diamonds and ellipses in a database course, that was Chen notation. For exam season, the symbols in one table:
| Chen symbol | Meaning |
|---|---|
| rectangle | entity |
| diamond | relationship |
| ellipse | attribute |
| underlined ellipse | key attribute |
| double ellipse | multi-valued attribute |
| 1, N, M on lines | cardinality |
As a teaching structure it's genuinely good: the relationship is its own shape, so the skeleton of the model — entities connected by relationships — is visible. That's also why it shows up in exams.
The reason industry doesn't use it comes from the same structure. A diamond per relationship and an ellipse per attribute means a thirty-table schema produces hundreds of shapes. The screen can't hold it, and there's nowhere to record implementation details like data types and constraints. So unless an assignment specifically requires Chen, drawing in IE is the working default.
The mapping from Chen to IE is mechanical. The diamond (relationship) becomes a line between two tables, the 1 and N on the line become the end symbols, and the ellipses (attributes) become column rows inside the table box. None of the concepts get thrown away — only the drawing changes.
Barker notation: the one in Oracle documents
One more you may encounter: Barker notation, in Oracle-lineage documents and older design papers. Like IE it uses a crow's foot for many, but it expresses optionality by splitting the line — half dashed (optional), half solid (mandatory) — and names the relationship in both directions. You'll rarely draw it, but being able to read it means old design documents won't throw you.
The same relationship in all three notations
Faster than comparing in words: here's "one member : N posts" drawn all three ways.
The information is identical. What differs is the cost of drawing and the cost of reading. IE is the most compact, Chen the most explanatory, and Barker sits somewhere between.
Why practice converged on crow's foot
Most working ERD tools default to IE, for the reasons above: the diagram survives growth to dozens of tables on boxes and lines alone, and the table box has room for columns, types and keys — so the diagram doubles as an implementation document. Mermaid's erDiagram uses the same crow's foot system, and so do the free online ERD tools. Learn it once and it transfers across tools.
FAQ
I learned Chen notation in school — why does industry use crow's foot?
Industry settled on crow's foot for space and tooling reasons. Chen draws a diamond per relationship and an ellipse per attribute, so thirty tables already overwhelm a screen. Crow's foot carries the same information with just table boxes and lines, stays readable on large schemas, and most working ERD tools adopted it — making it the de facto standard. The concepts you learned with Chen transfer as they are; only the symbols change.
What's the difference between dashed and solid lines in an ERD?
The difference is whether the relationship is identifying. A solid line (identifying) means the parent's key becomes part of the child's primary key — the classic case is an order item whose PK is (order_id, product_id). A dashed line (non-identifying) means the parent's key is referenced as a regular FK column, like member_id on a posts table, which covers most relationships in practice.
What does the direction of the ERD arrow mean?
The marks at the end of a crow's foot line aren't arrows showing direction — they're cardinality symbols showing counts. The three-pronged fork means many (N), and a short bar means one. If you read them as arrows showing data flow, you'll read the relationship backwards, so read each end as the count on that table's side.
How do you draw a many-to-many (N:M) relationship?
Many-to-many is drawn with a crow's foot at both ends. But since relational databases can't store N:M directly, the implementation resolves it into a junction table holding both keys, split into two 1:N relationships. That's why real-world ERDs more often show the junction table (like post_tags) than a bare N:M line.
The whole guide compresses into four sentences. The end symbols are counts, not arrows. Inner is minimum, entity side is maximum. The combinations are ||, ○|, |<, ○< — four and no more. Solid is identifying, dashed is non-identifying. Keep those four in mind and you can read any ERD.
More important than memorizing the symbols is reading them repeatedly. And one more thing: you don't need to know the symbols perfectly to get started. Paste DDL into WorksCove ERD and the relationship lines come out drawn in crow's foot — reading that diagram against the cheat sheet in this guide is good practice in itself.