Lesson 3	ER Diagram Notations
Objective	Compare Crow's Foot, Chen, and IDEF1X notation and interpret the same relationship in each.

Crow's Foot, Chen, and IDEF1X ER Diagrams

Crow's Foot, Chen, and IDEF1X are three established ways to represent entities and relationships. They emphasize different information and use different symbols. A symbol's meaning belongs to its notation: a diamond in Chen is not the same as a small parent-end diamond in IDEF1X.

These notation families are distinct from conceptual, logical, and physical levels of design. Choose the level of detail and the notation separately. This lesson uses one business rule throughout:

An OFFICE may have zero, one, or many EMPLOYEEs.
Every EMPLOYEE belongs to exactly one OFFICE.

For the key-based examples, each employee has an independent employee_id. The office assignment is mandatory, but it does not identify the employee.

1. Crow's Foot: Read the Relationship Endpoints

Crow's Foot: double bars beside OFFICE mean exactly one office per employee; a circle and crow's foot beside EMPLOYEE mean zero or many employees per office. — Read each endpoint as the number of instances at that end related to one instance at the opposite end.

The double bars beside OFFICE mean exactly one office for each employee. The circle and crow's foot beside EMPLOYEE mean zero or many employees for each office. The maximum cardinality is 1:N; the circle supplies the additional fact that an office may have no employees.

Crow's Foot diagrams can list attributes and key annotations inside entity boxes. This overview omits them to keep the relationship symbols prominent. Line-style conventions can vary between tools, so include a legend rather than assuming every solid or dashed line has the same meaning.

2. Chen: Separate Relationships from Entities

Chen notation: OFFICE connects to an assigns diamond with a single line labeled 1; the diamond connects to EMPLOYEE with double lines labeled N. Office participation is partial; employee participation is total. — The 1:N labels express maximum cardinality. Single and double connecting lines express partial and total participation.

Chen notation represents entity types as rectangles and relationship types as diamonds. Attributes can be drawn as ovals attached to entities or relationships; they are omitted in this small comparison.

The single line on the OFFICE side permits partial participation: an office need not participate in an assignment. The double line on the EMPLOYEE side requires total participation: every employee participates. Together with the 1:N labels, this means each employee has exactly one office and an office may have many employees.

Do not add Crow's Foot circles or bars to this convention. Chen-style diagrams also have variants, including explicit minimum/maximum labels; state which convention a diagram uses.

3. IDEF1X: Make Key Dependency Explicit

IDEF1X mandatory non-identifying relationship: a dashed line from OFFICE ends in an unmarked filled dot at EMPLOYEE. employee_id is the employee primary key; office_id is a required foreign key outside that primary key. — The assignment is mandatory but non-identifying. The employee's primary key does not include the office key.

In this IDEF1X example, the dashed line denotes a non-identifying relationship. The filled dot marks the child end; with no cardinality annotation, the parent may have zero, one, or many children. No optional-parent diamond appears at OFFICE, so every employee must reference exactly one office.

An optional non-identifying relationship would add a small diamond at the parent end, allowing a child to have no parent for that relationship. That would change our business rule. A solid identifying relationship would instead require the parent's key to form part of the child's primary key. Mandatory participation and identifying dependency are different decisions.

Keep the Symbol Systems Separate

Notation	What to inspect	Meaning in this example
Crow's Foot	Endpoint combinations	Exactly one office; zero or many employees
Chen	1:N labels and single/double lines	Partial office participation; total employee participation
IDEF1X	Dashed line, child dot, and parent optionality	Mandatory office reference outside the employee primary key

Strengths and Trade-offs

Crow's Foot: compact endpoint symbols make relational diagrams easy to scan. Detailed attribute or key information can still be included when needed.
Chen: a separate relationship diamond makes relationships and their attributes explicit. Drawing many attribute ovals can make a large diagram crowded.
IDEF1X: explicit key dependency supports detailed data modeling, but readers need to understand its relationship and cardinality conventions.

Choose the notation your audience can read and your modeling tools support. Use a required standard when one applies; otherwise favor consistent diagrams and an explicit legend. No notation is restricted to a particular industry, and none is automatically the best choice for every project.

Relational Database Design

Map the Shared Rule to Tables

The following simple schema uses an independent employee key, matching the IDEF1X non-identifying diagram. The CREATE TABLE statements can be used in SQLite with foreign-key enforcement enabled before a transaction using PRAGMA foreign_keys = ON;. Other platforms may require different setup or type choices. IDs are supplied by the application in this teaching example.

CREATE TABLE office (
    office_id INTEGER PRIMARY KEY,
    office_code VARCHAR(20) NOT NULL UNIQUE,
    office_name VARCHAR(100) NOT NULL
);

CREATE TABLE employee (
    employee_id INTEGER PRIMARY KEY,
    office_id INTEGER NOT NULL,
    employee_name VARCHAR(100) NOT NULL,
    CONSTRAINT fk_employee_office
        FOREIGN KEY (office_id) REFERENCES office(office_id)
);

NOT NULL requires an office_id; the foreign key requires that office to exist. Repeated employee.office_id values permit many employees per office. Nothing here requires every office to have an employee. The diagram omits office_code to focus on the relationship; the SQL adds it as a separate business identifier.

A different identifying design: if employee numbers are unique only within an office, the child key could be PRIMARY KEY (office_id, employee_no), with office_id also referencing OFFICE. That changes the identity rule and would require an identifying IDEF1X relationship. It is not merely a cosmetic alternative to the diagram above.

Common Pitfalls

Copying a symbol from one notation into another without explaining it.
Confusing mandatory participation with a parent's key being part of the child's key.
Inferring minimum participation from the label 1:N alone.
Treating a conceptual M:N relationship as an error. It can be valid conceptually; a relational implementation normally resolves it with an associative table.
Assuming a diagram enforces a rule. Constraints and other implementation mechanisms must enforce the documented requirements.

Read the Rule Back to a Stakeholder

For each diagram, ask: Can an office have no employees? Yes. Can one employee have two offices in this model? No. Can an employee exist without an office assignment? No. Does office_id identify an employee? No: employee_id is the independent identifier in the illustrated logical design.

All three diagrams communicate the same participation and cardinality rules. IDEF1X also makes the selected key dependency explicit. Understanding the business rules first lets you check the drawing instead of guessing from its appearance.

This module primarily uses Crow's Foot notation. The next lesson covers entities, attributes, and keys. For additional comparison, see IDEF1X, Crow's Foot, and Chen models.

Notation reference: IDEF1X method definition.