ER Diagram Notation Guide: Crow's Foot, Chen, and UML Compared
The same relationship can be drawn three different ways depending on the notation. Knowing crow's foot, Chen, and UML lets you read any ER diagram and choose the clearest for your audience.
An entity relationship diagram can be drawn in several notations, and they look different enough that a diagram in one can be hard to read if you only know another. The three you will encounter are crow's foot, which dominates modern database work; Chen's notation, the original academic form with diamonds for relationships; and UML class notation, favored by software teams who already model in UML. Each expresses the same underlying ideas - entities, attributes, and the cardinality and modality of relationships - but with different symbols.
This guide explains all three, focusing on how each shows the two facts that matter most: how many of one entity relate to how many of another, and whether the relationship is optional or mandatory. You can draw any of them in Atlas Diagram Studio at /diagrams; the ERD tool at /diagram-tools/erd-tool defaults to crow's foot, and for UML-style modeling the UML diagram tool at /diagram-tools/uml-diagram provides class notation. Knowing the mapping between them lets you read any diagram and pick the clearest form for your readers.
Crow's foot notation
Crow's foot is the notation most database professionals use, prized because it packs both cardinality and modality into compact symbols at the ends of each line. The symbols read like a small vocabulary: a bar means one, the three-pronged crow's foot means many, and a circle means zero or optional. They combine in pairs at each line end, so a bar-and-crow's-foot reads as one-or-many while a circle-and-crow's-foot reads as zero-or-many. Reading both ends of a line gives a complete sentence about the relationship.
Its strength is precision without clutter. A single line between Customer and Order, with a bar on the customer end and a circle-crow's-foot on the order end, says exactly that each order has one customer and a customer may have zero or many orders, with no separate labels needed. That density is why crow's foot is the default for real database design and why the ERD tool uses it. The main learning curve is memorizing the four end-symbols, after which every diagram becomes instantly readable.
Chen notation
Chen notation is the original ER notation from the 1976 paper that introduced entity relationship modeling, and it looks quite different. Entities are rectangles, but relationships are diamonds placed on the line between entities, and attributes are drawn as ovals connected to their entity by lines. Cardinality is written as labels - 1 and N, or 1 and M - on the connecting lines rather than encoded in the line ends. The result is more spread out and explicit, with every element getting its own shape.
Chen's explicitness makes it excellent for teaching and for conceptual modeling, because the diamonds force you to name each relationship as a verb - a Customer places an Order - and the oval attributes make the structure very legible for beginners. Its weakness is density: because attributes and relationships each get their own shapes, Chen diagrams grow large quickly and become unwieldy for a real database with dozens of tables. Most teams learn ER modeling with Chen and then switch to crow's foot for production work.
Choosing a notation for your audience
No notation is universally best; the right one depends on who reads the diagram and why. This guide maps common situations to the notation that serves them.
- Production database design: crow's foot, for compact, precise cardinality that scales to many tables.
- Teaching ER modeling to beginners: Chen, whose diamonds and ovals make every element explicit.
- A software team already modeling in UML: UML class notation, so the ERD matches their other diagrams.
- Conceptual modeling with business stakeholders: crow's foot or Chen, avoiding UML's software-specific conventions.
- A mixed audience of engineers and non-engineers: crow's foot, with relationship lines labeled in plain language.
- Documentation that sits beside class diagrams: UML notation for visual consistency across the doc set.
- Whatever you choose, stay consistent across a project so readers learn one visual language.
UML class notation for data models
UML class notation, borrowed from software modeling, represents entities as class boxes with the name at the top and attributes listed below, and relationships as associations whose multiplicity is written as numbers or ranges near each end - 1, 0..1, or the asterisk that means many. It is the natural choice for teams who already draw class diagrams, because a data model in UML sits comfortably beside the rest of their design documentation and uses symbols they already know.
The multiplicities carry the same information as crow's foot symbols, just written differently: 1 to asterisk is one-to-many, 0..1 marks an optional single reference, and asterisk to asterisk is a many-to-many that still needs resolving with an association class - UML's equivalent of a junction table. If your organization standardizes on UML, model your data in it using the UML diagram tool at /diagram-tools/uml-diagram; the guide comparing ER diagrams and class diagrams goes deeper on how the two overlap and differ. Whichever notation you adopt, the underlying discipline of entities, keys, and cardinality is identical.