Cardinality in ER Modeling

Entity-Relationship diagrams would be straightforward if everyone used the same notation. Unfortunately, the database industry has developed multiple competing notation systems, each with its own symbols, conventions, and visual vocabulary. When you move between organizations, academic resources, or modeling tools, you encounter different notations—sometimes dramatically different.

This diversity isn't arbitrary. Each notation evolved to address specific needs: Chen's original notation emphasized theoretical elegance, Crow's Foot prioritized intuitive readability, UML sought integration with object-oriented modeling, and Min-Max notation aimed for mathematical precision. Understanding these trade-offs helps you appreciate why different contexts prefer different notations.

Fluency in multiple notations is essential for professional database work. You'll read academic papers in Chen notation, collaborate with enterprise architects using Crow's Foot, review UML diagrams from software developers, and encounter tool-specific variations everywhere. This page equips you with the vocabulary to navigate this notational landscape with confidence.

Peter Chen introduced the Entity-Relationship model in his seminal 1976 paper. His notation, now called Chen notation or original ER notation, remains the foundation taught in computer science courses and appears in most academic textbooks.

Cardinality in Chen Notation:

Cardinality is expressed using numbers (1, N, or M) placed near the respective entities:

[ENTITY_A]───1───<RELATIONSHIP>───N───[ENTITY_B]

Reading Convention:

• The number near ENTITY_A tells how many ENTITY_A instances can relate to one ENTITY_B
• Wait—conventions vary! Some texts reverse this.

Clarifying the ambiguity:

There are two conventions for reading Chen notation cardinality:

Convention 1 (Near-side reading): The number indicates how many of the NEAR entity participate with one FAR entity.

• 1 near A means: one A per B
• N near B means: many B per A

Convention 2 (Far-side reading): The number indicates how many of the FAR entity associate with one NEAR entity.

• 1 near A means: each A associates with one B
• N near B means: each B associates with potentially many... (this gets confusing)

The most common convention (and the one we use):

[DEPARTMENT]───1───<EMPLOYS>───N───[EMPLOYEE]
          ↑                     ↑
  One department           Many employees
   can employ...            can work in...

Read as: One department employs many employees.

Participation Constraints in Chen Notation:

• Single line = Partial participation (optional)
• Double line = Total participation (mandatory)

[DEPARTMENT]────────<EMPLOYS>════════[EMPLOYEE]
              ↑                    ↑
          Single line          Double line
       (partial: dept          (total: every
        may have no            employee must
        employees)             have a dept)

Complete Chen Diagram Example:

                 ┌──────────┐
                 │  name    │
                 └────┬─────┘
                      │
┌──────────────┐      │      ┌──────────────┐
│  DEPARTMENT  │──────1──────<  EMPLOYS  >──────N──────│   EMPLOYEE   │
└──────┬───────┘             └──────────────┘         └───────┬───────┘
       │                                                       │
   ┌───┴───┐                                              ┌────┴────┐
   │dept_id│                                              │emp_id   │
   └───────┘                                              │(underln)│
  (underlined = PK)                                       └─────────┘

Crow's Foot notation, also called Information Engineering (IE) notation, is perhaps the most widely used notation in industry practice. Developed in the 1980s, it emphasizes visual intuition: the symbols look like their meaning, making diagrams immediately readable even without training.

Reading Crow's Foot Diagrams:

The key insight: look at the symbol at the FAR END from where you're reading.

[DEPARTMENT] ||──────────⅄| [EMPLOYEE]
              ↑             ↑
        (at dept end)  (at employee end)

Reading from DEPARTMENT: Look at the symbol near EMPLOYEE → crow's foot with bar (⅄|) Meaning: One department relates to ONE OR MANY employees.

Reading from EMPLOYEE: Look at the symbol near DEPARTMENT → double bar (||) Meaning: One employee relates to ONE AND ONLY ONE department.

Combined reading: "A department has one or many employees; an employee belongs to exactly one department." This is a 1:N relationship.

Representing All Cardinality Types:

One-to-One (1:1):

[PERSON] ||──────────|| [PASSPORT]

Each person has exactly one passport; each passport belongs to exactly one person.

One-to-Many (1:N):

[CUSTOMER] ||──────────⅄| [ORDER]

Each customer has one or many orders; each order belongs to exactly one customer.

Many-to-Many (M:N):

[STUDENT] ⅄|──────────⅄| [COURSE]

Each student enrolls in one or many courses; each course has one or many students.

Note on optionality: The above assume total participation. For optional:

[EMPLOYEE] |○──────────○⅄ [PROJECT]

Each employee may work on zero or many projects; each project may have zero or many employees.

Entity Representation in Crow's Foot:

Unlike Chen, entities include attributes inside the box:

┌─────────────────────┐
│      EMPLOYEE       │
├─────────────────────┤
│ PK  employee_id     │
│     name            │
│     email           │
│ FK  department_id   │
└─────────────────────┘

Common conventions:

• PK = Primary Key
• FK = Foreign Key
• UK = Unique Key
• NN = Not Null
• Bold or underlined text for primary keys

Relationships are lines connecting boxes—no separate relationship symbol (unlike Chen's diamonds).

Min-Max notation, also called structural notation or (min,max) notation, takes a mathematical approach: explicitly stating the minimum and maximum cardinality as an ordered pair. This notation is unambiguous but requires understanding the convention for interpretation.

Basic Syntax:

[ENTITY]──(min,max)──<RELATIONSHIP>──(min,max)──[ENTITY]

The (min,max) pair specifies:

• min: The minimum number of times an entity participates in the relationship
• max: The maximum number of times an entity participates in the relationship
• N or * denotes unbounded (no maximum)

Example:

[DEPARTMENT]──(0,N)──<EMPLOYS>──(1,1)──[EMPLOYEE]
              ↑                  ↑

Interpretation:

• The (0,N) near DEPARTMENT means: From the DEPARTMENT's perspective, it participates with 0 to N employees. (A department can have zero employees or many.)
• The (1,1) near EMPLOYEE means: From the EMPLOYEE's perspective, each employee participates with exactly 1 department. (Every employee must belong to exactly one department.)

Representing All Cardinality Types:

One-to-One (1:1):

[PERSON]──(1,1)──<HAS>──(1,1)──[PASSPORT]

Each person has exactly one passport (1,1); each passport belongs to exactly one person (1,1).

One-to-Many (1:N):

[DEPARTMENT]──(1,N)──<EMPLOYS>──(1,1)──[EMPLOYEE]

Each department has 1 to N employees; each employee belongs to exactly one department.

Many-to-Many (M:N):

[STUDENT]──(0,N)──<ENROLLS>──(0,N)──[COURSE]

Each student enrolls in 0 to N courses; each course has 0 to N students.

Note the flexibility:

[TEAM]──(5,11)──<HAS_MEMBER>──(1,3)──[PLAYER]

Each team has 5 to 11 players; each player belongs to 1 to 3 teams.

This expresses specific cardinality constraints impossible in basic Chen or Crow's Foot notation!

Advantages of Min-Max Notation:

1. Precision: Express exact ranges (2,5) not possible in other notations
2. Unambiguous: Numbers are clearer than remembered symbols
3. Mathematical: Aligns with formal specification approaches
4. Combined information: Participation (min) and cardinality (max) in one symbol

Disadvantages:

1. Verbosity: More text to read than symbolic notations
2. Convention confusion: Which end describes which entity varies
3. Less visual: Numbers don't create an immediate mental picture like crow's feet
4. Rare in tools: Many ER tools default to Crow's Foot; Min-Max support varies

Unified Modeling Language (UML) is not strictly an ER notation—it's a software modeling standard. However, UML Class Diagrams are frequently used to model database schemas, especially in object-oriented development contexts where the same diagram serves both application and database design.

UML Class Diagram Basics:

┌─────────────────────────┐
│       «entity»          │
│        Employee         │
├─────────────────────────┤
│ - employeeId: int       │
│ - name: String          │
│ - salary: decimal       │
├─────────────────────────┤
│ + getSalary(): decimal  │
│ + promote(): void       │
└─────────────────────────┘

Three compartments:

1. Name: Class/entity name (with optional stereotype like «entity»)
2. Attributes: Data fields with visibility (+public, -private) and types
3. Operations: Methods (less relevant for database modeling, often omitted)

For database modeling, the third compartment is typically removed, leaving just name and attributes.

UML Multiplicity:

UML uses multiplicity at association ends:

[Employee] ────────────── [Department]
    1..*                        1

Multiplicity Syntax:

Reading Convention: The multiplicity at an end indicates how many of THAT class can associate with one instance of the OTHER class.

[Employee]──────────[Department]
    0..*                1
    ↑                   ↑
Many employees      One department
per department      per employee

UML Association Types:

UML distinguishes several association types relevant to ER modeling:

Association (plain line):

[Employee]────────[Project]

General relationship, semantic meaning determined by context.

Aggregation (hollow diamond):

[Department]◇────────[Employee]

'Has-a' relationship; parts can exist independently of whole.

Composition (filled diamond):

[Order]◆────────[OrderItem]

Strong 'owns' relationship; parts cannot exist without whole.

For database modeling:

• Composition often implies ON DELETE CASCADE
• Aggregation implies weaker coupling (SET NULL or RESTRICT)
• The diamond is placed at the 'whole' end

IDEF1X (Integration Definition for Information Modeling) is a data modeling technique developed in the 1980s, standardized by NIST. It's widely used in government, defense, and large enterprise contexts, particularly in the United States. While less common in startup environments, understanding IDEF1X is valuable for working with legacy systems and government contracts.

IDEF1X Diagram Example:

┌─────────────────┐          ┌──────────────────┐
│   DEPARTMENT    │          │     EMPLOYEE     │
├─────────────────┤          ├──────────────────┤
│ department_id   │══════════●│ employee_id     │
│ name            │          │ name             │
│ location        │          │ department_id(FK)│
└─────────────────┘          └──────────────────┘
                   ↑          ↑
               Solid line   Filled dot
              (identifying   (many side)
               or not)       

Key Differences from Other Notations:

1. Entity shape matters: Square corners = independent; rounded = dependent
2. Line style matters: Solid = identifying relationship; dashed = non-identifying
3. Filled dot at 'many' end instead of crow's foot
4. No relationship name: The line implies the relationship; naming is optional
5. Primary key migration: IDEF1X explicitly shows PK inheritance in dependent entities

Identifying vs. Non-Identifying Relationships:

This is IDEF1X's distinctive contribution to data modeling:

Identifying Relationship (solid line):

• Child entity cannot be uniquely identified without parent
• Parent's PK becomes part of child's PK
• Example: LINE_ITEM cannot be identified without ORDER

┌─────────────┐         ╭─────────────╮
│   ORDER     │════════●│  LINE_ITEM  │
├─────────────┤         ├─────────────┤
│ order_id    │         │ order_id(PK)│  ← PK inherited from parent
│ order_date  │         │ line_num(PK)│  ← Plus local discriminator
└─────────────┘         │ product_id  │
                        ╰─────────────╯
                        (rounded corners = dependent)

Non-Identifying Relationship (dashed line):

• Child has its own independent identity
• Parent's PK is just a foreign key, not part of child's PK
• Example: EMPLOYEE references DEPARTMENT but has own identity

┌─────────────┐         ┌─────────────┐
│ DEPARTMENT  │- - - - ●│  EMPLOYEE   │
├─────────────┤         ├─────────────┤
│ dept_id     │         │ emp_id(PK)  │  ← Own PK
│ name        │         │ dept_id(FK) │  ← Just a reference
└─────────────┘         └─────────────┘
          (dashed = non-identifying)

With multiple notations available, how do you choose which to use? The answer depends on context, audience, tooling, and organizational standards.

Decision Framework:

1. Check organizational standards Many organizations mandate specific notations. Check before creating diagrams.

2. Consider your tools Your modeling tool may default to a notation:

• MySQL Workbench → Crow's Foot variant
• ERD Plus → Chen
• Enterprise Architect → UML or IDEF1X
• Lucidchart → Crow's Foot
• draw.io → Multiple options

3. Know your audience

• Developers often prefer UML (familiar from OO design)
• DBAs typically prefer Crow's Foot (industry standard)
• Academics expect Chen (textbook standard)
• Mixed audience → Crow's Foot (most accessible)

4. Match complexity to notation

• Simple schemas: Any notation works
• Complex constraints: Min-Max or UML multiplicity
• Dependency emphasis: IDEF1X
• Conceptual overview: Chen (attribute ovals clarify structure)

Being able to translate between notations is essential when working with diverse teams, tools, or documentation sources. Here's a systematic approach to translation:

Translation Process:

Step 1: Identify the source notation Look for distinctive markers:

• Diamonds → Chen
• Crow's feet (⅄) → Crow's Foot
• (0,N) style → Min-Max
• • and 0..* → UML
• Filled dots and dashed lines → IDEF1X

Step 2: Extract the semantic meaning For each relationship, determine:

• Which entities participate?
• What is the cardinality? (1:1, 1:N, or M:N)
• What is the participation? (optional or mandatory, each side)
• Are there relationship attributes?

Step 3: Render in target notation Apply the target notation's symbols to the semantic meaning.

Translation Example:

Source (Chen):

[STUDENT]────N────<ENROLLS>────M────[COURSE]
                      │
                  ┌───┴───┐
                  │ grade │
                  └───────┘

Semantic extraction:

• Entities: STUDENT, COURSE
• Cardinality: M:N (many students per course, many courses per student)
• Participation: Not specified (assume partial/optional)
• Relationship attribute: grade

Target (Crow's Foot):

┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│   STUDENT   │         │  ENROLLMENT │         │   COURSE    │
├─────────────┤         ├─────────────┤         ├─────────────┤
│ student_id  │⅄○──────||│ student_id  │||──────○⅄│ course_id   │
│ name        │         │ course_id   │         │ title       │
└─────────────┘         │ grade       │         └─────────────┘
                        └─────────────┘

Note: M:N becomes two 1:N relationships through a junction table. The relationship attribute (grade) moves to the junction table.

Target (Min-Max):

[STUDENT]──(0,N)──<ENROLLS>──(0,N)──[COURSE]
                      │
                   {grade}

Target (UML):

[Student] *─────────────────* [Course]
           \               /
            \             /
          0..*         0..*
              \       /
               \     /
          ┌────────────────┐
          │   Enrollment   │
          ├────────────────┤
          │ grade: String  │
          └────────────────┘
              (Association Class)

UML handles M:N with relationship attributes using an association class—a class attached to the association line.

We have thoroughly explored the landscape of ER and data modeling notations. Let's consolidate the essential takeaways:

What's Next:

With cardinality types (1:1, 1:N, M:N) and notation styles now mastered, we complete this module by exploring minimum cardinality—the often-overlooked constraint that specifies whether participation is mandatory or optional. This final piece completes your cardinality toolkit for comprehensive relationship modeling.