Notation: Visual Language for Specialization Hierarchies

The concepts of specialization—supertypes, subtypes, inheritance, local attributes, discriminators, and constraints—need a visual language to communicate effectively with stakeholders. Just as architects use blueprints and musicians use sheet music, database designers use ER diagrams with specialized notation to express complex data structures.

Different notational systems exist, each with strengths and contexts where they're preferred. Mastery of notation enables you to read any EER diagram you encounter, write diagrams that others can understand, and translate between notational styles when working across different organizations or tools.

Several notational systems are widely used for ER and EER diagrams. Each has its origins, strengths, and typical usage contexts.

Major Notational Systems:

Which to Learn?

For comprehensive understanding, focus on:

1. Chen Notation — The theoretical foundation; still dominant in textbooks and academia
2. IE/Crow's Foot — The practical standard; most ER tools support it
3. UML — Increasingly important; bridges database and software design

This page covers all three in detail, with specific focus on how each represents specialization constructs.

Chen notation, developed by Peter Chen in his seminal 1976 paper, uses explicit geometric shapes for each construct. For specialization (added in EER extensions), the notation is precise and unambiguous.

Core Symbols:

Chen Notation Elements Explained:

The Circle (Specialization Symbol):

• Contains a lowercase letter indicating disjointness constraint:
  • 'd' = Disjoint — An entity can be in AT MOST one subtype
  • 'o' = Overlapping — An entity can be in MULTIPLE subtypes

The Lines (Participation Constraint):

• Single line from supertype to circle = Partial participation (entity may not belong to any subtype)
• Double line from supertype to circle = Total participation (entity MUST belong to at least one subtype)

The Direction:

• Lines flow from supertype → circle → subtypes
• Sometimes a 'U' or '⊂' symbol is added to indicate 'is-a' direction

Complete Chen Notation Example:

                           EMPLOYEE
                               |
                         ══════╪══════ (double line = total)
                               |
                              (d)       (circle with 'd' = disjoint)
                          / | 
                         /  |  
                  MANAGER  ENGINEER  SALESPERSON

This diagram says: Every employee is EXACTLY ONE of Manager, Engineer, or Salesperson (total and disjoint).

Information Engineering (IE) notation, often called Crow's Foot due to its cardinality symbols, is widely used in industry and supported by most database design tools. It represents specialization more compactly than Chen notation.

Key IE Notation Symbols for Specialization:

IE Notation Variations:

Different tools implement IE notation slightly differently:

Variant 1: Triangle Symbol (Common)

    EMPLOYEE
        ▽
       /|
      / | 
 MANAGER ENGINEER SALES

Variant 2: Half-Circle with Constraint (ERwin/PowerDesigner)

    EMPLOYEE
        ⌒ (d)
       /|
      / | 
 MANAGER ENGINEER SALES

Variant 3: Exclusive Arc (Some Tools)

    EMPLOYEE ────○───┐
                    ├─── MANAGER
                    ├─── ENGINEER  
                    └─── SALES
    (The '○' or arc indicates exclusive subtypes)

Discriminator Notation in IE:

The discriminator attribute is often shown near the specialization symbol:

    EMPLOYEE
        ▽ [job_type]
       /|
      / | 
 MANAGER ENGINEER SALES

This indicates job_type is the discriminator that determines subtype membership.

Unified Modeling Language (UML) is the standard modeling language for object-oriented systems. Its class diagram notation adapts naturally to EER specialization because object-oriented inheritance and database specialization share fundamental concepts.

UML Specialization Symbols:

UML Constraint Notation:

UML uses constraint labels in curly braces to specify specialization constraints:

Combined constraints:

• {complete, disjoint} — Every object is in exactly one subclass
• {complete, overlapping} — Every object is in at least one subclass
• {incomplete, disjoint} — Object is in at most one subclass, possibly none
• {incomplete, overlapping} — Object can be in any number of subclasses (0 to all)

Specialization constraints—disjoint vs. overlapping, total vs. partial—are critical semantic information. Each notation system has specific ways to express these constraints.

The Four Constraint Combinations:

Visual Reference for All Four Combinations:

The discriminator (also called defining attribute or type indicator) specifies which attribute determines subtype membership. Different notations represent this with varying degrees of explicitness.

Chen Notation: The discriminator is typically shown as a label near the specialization circle:

      EMPLOYEE
         |
        (d)
         |←── job_type [discriminator label]
        /|
       / | 
    MANAGER ENGINEER SALES
      ↓       ↓       ↓
   'MGR'   'ENG'   'SALES' [discriminator values]

IE Notation: Shown in brackets near the inheritance symbol:

    VEHICLE
       ▽ [vehicle_type]
      /|
   CAR TRUCK MOTORCYCLE

UML Notation: Added as a constraint or note:

┌──────────┐
│ VEHICLE  │
├──────────┤        {discriminator = vehicle_type}
│ vehicle_ │───────────────────┐
│   type   │                   │
└────┬─────┘                   │
     │                         │
     ├────────────────────────────────┐
     ▽                         ▽      ▽
 ┌───────┐                 ┌───────┐ ┌──────────┐
 │  CAR  │                 │ TRUCK │ │MOTORCYCLE│
 └───────┘                 └───────┘ └──────────┘

Discriminator Values:

Some notation styles also show which discriminator value maps to which subtype:

ACCOUNT
   │
  (d) [account_type]
   │
   ├── SAVINGS      ← 'SAV'
   ├── CHECKING     ← 'CHK' 
   └── INVESTMENT   ← 'INV'

This clarifies both:

1. What attribute is the discriminator (account_type)
2. What values map to which subtypes ('SAV' → SAVINGS, etc.)

Real-world models often have multi-level specialization hierarchies. Notation must clearly convey multiple inheritance levels, potentially with different constraints at each level.

Key Observations:

1. Each level can have different constraints:

   • Level 1: Disjoint (person is employee OR customer, not both)
   • Level 2: Disjoint (employee is manager OR technical)
   • Level 3: Overlapping (technical can be engineer AND scientist)

2. Each level has its own specialization symbol:

   • Don't merge multiple levels into one symbol
   • Each symbol specifies constraints for that level only

3. Attributes accumulate:

   • ENGINEER has: person_id, name, dob (from PERSON) + emp_id, hire_date (from EMPLOYEE) + specialty (from TECHNICAL) + tech_stack (local)

Reading Multi-Level Diagrams:

When reading complex hierarchies:

1. Start at the root and trace each path
2. At each node, accumulate inherited attributes
3. At each constraint symbol, note the applicable constraints
4. Continue until reaching leaf subtypes