Types of Entity-Relationship Diagrams

ER diagrams come in multiple notations. The three you will see most often are:

1. Crow’s Foot (Information Engineering) - compact, industry-friendly boxes and relationship symbols.
2. Chen - classic academic style with entities (rectangles), relationships (diamonds), and attributes (ovals).
3. IDEF1X - standards-driven (DoD/US Gov origins) with rich semantics for keys and identifying relationships.

Unifying business rule used below: “An OFFICE is assigned to employees.” Read bidirectionally: an office can have zero or many employees; each employee belongs to exactly one office.

• Cardinality (max): “crow’s foot” = many; single bar = one.
• Optionality (min): open circle = zero allowed; bar = at least one.
• Identifying vs. Non-identifying (IDEF1X): solid line = identifying; dashed = non-identifying.
• Chen relationship: diamond with role/verb phrase; can carry attributes.

Crow’s Foot

• Pros: Compact, readable, widely supported in CASE tools; easy to map to relational schemas.
• Cons: Less explicit about attribute metadata; deep semantics (e.g., relationship attributes) are implied rather than drawn.

Chen

• Pros: Attributes and relationship attributes are first-class citizens; great for pedagogy and early discovery.
• Cons: Can become visually dense on larger models; not the dominant industry handoff format.

IDEF1X

• Pros: Clear key semantics; distinguishes identifying vs. non-identifying; good for large, governed programs.
• Cons: Steeper learning curve; fewer commercial teams use it day-to-day; diagrams may look cryptic to newcomers.

• Concept teaching / stakeholder elicitation: Chen.
• General commercial design and documentation: Crow’s Foot.
• Standards-heavy enterprise / regulated domains: IDEF1X.

• Leaving modality ambiguous (forgetting whether a relationship is optional vs. mandatory).
• Modeling many-to-many without an intersection entity (junction table).
• Omitting natural keys and constraints (UNIQUES) when you adopt surrogate keys.
• Over-normalizing early (hurts usability) or under-normalizing late (hurts integrity).

Given the business rule above, a typical relational mapping is:

-- Entities
CREATE TABLE office (
  office_id   NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  office_code VARCHAR2(20) UNIQUE NOT NULL,
  name        VARCHAR2(100) NOT NULL
);

CREATE TABLE employee (
  employee_id NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  office_id   NUMBER NOT NULL,
  last_name   VARCHAR2(60) NOT NULL,
  first_name  VARCHAR2(60) NOT NULL,
  CONSTRAINT fk_employee_office
    FOREIGN KEY (office_id) REFERENCES office(office_id)
);

-- Business rule checks
-- 1) Each employee must belong to exactly one office → NOT NULL + FK on employee.office_id
-- 2) An office may have zero or many employees → no extra constraint on office
  

IDEF1X variant (identifying): If EMPLOYEE identity depends on OFFICE, you could model a composite key:

CREATE TABLE employee_identifying (
  office_id   NUMBER NOT NULL,
  employee_no NUMBER NOT NULL,
  last_name   VARCHAR2(60) NOT NULL,
  first_name  VARCHAR2(60) NOT NULL,
  CONSTRAINT pk_emp_ident PRIMARY KEY (office_id, employee_no),
  CONSTRAINT fk_emp_ident_office
    FOREIGN KEY (office_id) REFERENCES office(office_id)
);
  

• Crow’s Foot: OFFICE ||───O< EMPLOYEE → mandatory one on the EMPLOYEE→OFFICE side; optional many on the OFFICE→EMPLOYEE side.
• Chen: OFFICE - <assign> - EMPLOYEE with (1) and (N) markers and participation (total/partial) shown by line styles or adornments.
• IDEF1X: Solid line = identifying; dashed = non-identifying. Parent→child determines key migration and PK composition.

• All three notations express the same logical truths; they differ in how they convey cardinality, optionality, and keys.
• Choose a notation that fits your audience, toolchain, and governance requirements.
• As models grow, prefer concise notations for communication (Crow’s Foot) and reserve detailed ones (Chen/IDEF1X) for pedagogy or standards.