Crow’s Foot Notation — ER Diagram Cardinality Explained

What Is Crow’s Foot Notation?

Crow’s foot notation is the graphical standard for showing how many records on each side of a relationship can exist in a relational database. Gordon Everest introduced it in his 1976 IEEE paper “Basic Data Structure Models Explained with a Common Example,” presented at the Fifth Texas Conference on Computing Systems in Austin, Texas (Wikipedia, Redgate). Everest originally called the symbol an “inverted arrow” or “fork.” The term “crow’s foot” emerged through academic and industry use over the following decade.

The notation spread through ICL, CACI consultancy, and later Oracle UK before becoming the default in most modern database design tools. Today, the relational database market is valued at $74 billion (2024) and projected to reach $84 billion in 2025 at a 13.3% annual growth rate (The Business Research Company, 2025). In that context, reading a crow’s foot diagram is a baseline skill for database professionals, not an advanced one.

You’ll also hear it called “chicken foot notation” or “IE notation” (after the Information Engineering methodology). James Martin and Clive Finkelstein popularized it through their information engineering frameworks in the 1980s, which helped cement it as the industry default.

The Crow’s Foot Symbols

Three primitive symbols make up the entire crow’s foot vocabulary. The outer symbol (furthest from the entity box) indicates maximum cardinality. The inner symbol indicates minimum cardinality, meaning whether at least one record must exist. You read both together to get the full picture of what a relationship allows.

These combine in pairs to produce four cardinality labels. The inner symbol is closest to the entity; the outer symbol is next:

The two combinations you’ll see most often day-to-day are “zero or many” and “one and only one.” Together they describe a standard optional one-to-many relationship, the backbone of most relational schemas. Worth knowing those two cold before the others.

Relationship Types in Crow’s Foot Notation

Three relationship types cover every scenario in a relational schema. One-to-many is the most common by far, appearing in patterns like customers to orders, posts to comments, and users to sessions. Many-to-many relationships can’t be modeled with a single foreign key — they require a junction table to resolve into two one-to-many relationships. One-to-one comes up less often, but it has clear use cases in schema decomposition.

One-to-One (1:1)

A single bar on both ends of the line. Each record in table A relates to exactly one record in table B, and vice versa.

Example: A users table and a user_profiles table, where each user has exactly one profile and each profile belongs to exactly one user. The foreign key (user_profiles.user_id) references users.id with a UNIQUE constraint to enforce the one-to-one cardinality. This pattern is useful when you want to keep large or rarely-accessed columns in a separate table without polluting the main entity.

One-to-Many (1:N)

A single bar on one end, a crow’s foot on the other. One record in table A relates to many records in table B, but each record in B relates to exactly one record in A.

Example: A users table and an orders table. One user can place many orders, but each order belongs to exactly one user. The foreign key (orders.user_id) references users.id. This is the most common relationship type in relational databases, and the one you’ll design most frequently.

Many-to-Many (N:M)

A crow’s foot on both ends. Many records in table A relate to many records in table B.

Example: A products table and a tags table. One product can have many tags, and one tag can apply to many products. Many-to-many relationships can’t be represented by a single foreign key, so they require a junction table (also called a join table or associative entity), such as product_tags, with foreign keys to both products and tags.

Optionality: Mandatory vs. Optional

The inner symbol at each line end determines whether the relationship is required. Get this right and your schema rejects invalid data at the database level. Get it wrong and you’ll find orphaned records and broken joins in production.

• Mandatory ( | ) — a record must exist on that side. In SQL, this is a NOT NULL constraint on the foreign key column.
• Optional ( ○ ) — a record may or may not exist. The foreign key column allows NULL, so the relationship is optional.

Here’s a concrete example. An orders table might have an optional coupon_id foreign key. An order can exist without a coupon, so coupon_id is nullable. In crow’s foot notation, the coupons end of the line shows a circle (zero-or-one) rather than a bar (exactly one).

Compare that to orders.user_id, which is mandatory: every order must belong to a user. That end gets a bar, and the column gets NOT NULL. Same relationship line, but the inner symbols at each end tell completely different stories about what the schema will enforce.

How to Read Crow’s Foot Notation Step by Step

Reading a crow’s foot diagram becomes automatic after a few practice runs. Here’s the five-step process that works for any ER diagram, regardless of the tool or schema complexity.

1. Look at both ends of the line. Each end carries two symbols. The outer symbol shows maximum cardinality; the inner shows minimum cardinality (optionality).
2. Read the maximum cardinality. A single vertical line means “at most one.” Three diverging lines (the crow’s foot) means “many.” A crow’s foot at the orders end means one customer can have many orders.
3. Read the minimum cardinality. A bar next to the entity means mandatory (NOT NULL foreign key). A circle means optional (nullable foreign key).
4. Combine both symbols for the full label. Bar + crow’s foot = one or more. Circle + crow’s foot = zero or more. Bar + bar = exactly one. Circle + bar = zero or one.
5. Find the foreign key direction. The FK column always lives on the “many” side — the table with the crow’s foot. That table has a foreign key column referencing the primary key of the “one” side.

How SQL Designer Uses Crow’s Foot Notation

When you draw a relationship line in SQL Designer between a foreign key column and the primary key it references, crow’s foot notation is applied automatically based on the column constraints:

• The referenced (parent) side always shows a single bar — one record is referenced
• The referencing (child) side shows a crow’s foot — many records can hold the same FK value
• If the FK column is NOT NULL, the child end shows a mandatory crow’s foot (one-or-many)
• If the FK column allows NULL, the child end shows an optional crow’s foot (zero-or-many)

The result is a complete, readable ER diagram using standard crow’s foot notation, ready to share with your team or embed in technical documentation.