Crow’s Foot Notation: Read, Model, and Communicate ER Diagrams

Crow’s Foot is a compact ERD notation used by data modelers, DBAs, and application teams to describe how data fits together. It emphasizes entities (things we store), their attributes (columns), and the relationships between them (cardinality and optionality). This page explains the symbols, shows real examples, and highlights common design choices, so your diagrams are consistent and easy to read on desktop or mobile.

• Entity (table): A rectangle with the entity name; attributes are listed inside. Primary keys are often underlined or flagged “PK”; foreign keys may be flagged “FK”.
• Relationship line: Connects two entities. The end markers communicate both cardinality and optionality:
  • Cardinality: a single bar “|” means “one”; a “crow’s foot” (three-pronged) means “many”.
  • Optionality: an open circle “○” means “zero allowed”; a bar “|” means “must exist”.
  Read each end independently, for example:
  • |—< (one to many, mandatory on the “one” side)
  • ○—< (zero-to-many)
  • |—| (exactly one to exactly one)
• Identifying vs. non-identifying: Some styles use a solid line when the child’s PK includes the parent FK (identifying), and a dashed line when the child has its own PK (non-identifying). Pick a convention and use it consistently.

1. Entities & Attributes
   Entities are nouns such as Customer, Order, or Publication. Attributes are the columns stored about each entity (e.g., CustomerID, Email, CreatedAt). In Crow’s Foot, attributes are listed inside the entity box, no separate ovals as in Chen notation.
2. Relationships
   Use the line ends to show one-to-one (1:1), one-to-many (1:M), and, conceptually many-to-many (M:N). In physical design, M:N is implemented via an associative entity (junction table) that becomes two 1:M relationships.

A crow’s foot marks the “many” side of a relationship. In the diagram below, one AUTHOR can write many PUBLICATION rows.

1:1 is less common. It’s used to separate rarely-used or sensitive attributes, or to enforce a one-row extension of a base entity. Each EDITION has exactly one RANK, and vice versa.

1:M is the workhorse of relational design. One AUTHOR can have many PUBLICATIONs; each PUBLICATION has one and only one AUTHOR.

Conceptually, a publisher can produce many publications and a publication can be produced by many publishers. Physically, model this with an associative entity (here: EDITION) that captures the pairing-and any attributes of the pairing (e.g., format, print run).

Multivalued facts-e.g., a Student with several Courses and independent Hobbies-create cartesian combinations if stored in a single table. Fourth Normal Form (4NF) removes that redundancy by decomposing into separate relations so each independent multivalued set is modeled on its own (e.g., StudentCourse and StudentHobby). Crow’s Foot diagrams make these dependencies concrete: each independent set becomes its own entity with a clean 1:M link.

• Name entities in singular (Order, not Orders). Keep attribute names consistent and descriptive.
• Choose stable primary keys; avoid embedding meaning in identifiers.
• Show optionality explicitly (○ vs |). Don’t leave “nullable vs. required” to guesswork.
• Resolve M:N with an associative entity; put relationship attributes there (e.g., role, effective dates).
• Keep diagrams focused: split very large models into subject areas and link them with navigation notes.

• Mixing notations (e.g., Chen-style ovals) inside a Crow’s Foot diagram.
• Omitting optionality, leading to different interpretations by engineering and analytics teams.
• Leaving M:N unimplemented in the physical model; always introduce the junction table.
• Storing multivalued lists in a single attribute instead of modeling them as related rows.

1. List the core entities and their key attributes.
2. Sketch relationships with cardinality and optionality at both ends.
3. Identify any conceptual M:N; introduce associative entities.
4. Review with stakeholders; refine names, keys, and constraints.