Loading learning content...
Notation is the visual language of data modeling. Just as spoken languages vary across regions, EER notation varies across academic traditions, industry tools, and organizational standards. A Principal Engineer must be fluent in multiple notations—able to read diagrams from any source and produce diagrams appropriate for any audience.
This page provides mastery-level coverage of specialization constraint notation across:
Beyond simply recognizing symbols, you'll understand:
Mastering notation transforms your ability to communicate complex designs—whether to academics, developers, database administrators, or business stakeholders.
By the end of this page, you will fluently read and write specialization constraints in all major notation systems, understand the historical evolution and rationale behind each, translate designs between notations, and make informed notation choices for your audience.
Peter Chen's original Entity-Relationship model (1976) was later extended to support specialization/generalization, creating Extended ER (EER). This notation is dominant in academic textbooks and database theory courses.
Historical Context:
Chen's original ER notation used rectangles for entities, diamonds for relationships, and ovals for attributes. The EER extensions added:
Key Notation Elements:
1. The Specialization Circle
2. Constraint Letters Inside the Circle
3. Line Style (Superclass to Circle)
4. Specialization Direction
123456789101112131415161718192021222324252627
CHEN NOTATION: Total + Disjoint Specialization════════════════════════════════════════════════ ┌───────────────────┐ │ Account │ │ │ │ • account_id │ │ • balance │ │ • open_date │ └─────────┬─────────┘ ║ ← DOUBLE LINE = Total Participation ║ (Every account MUST be specialized) ╔═╗ ║d║ ← 'd' in circle = Disjoint ╚═╝ (Each account in exactly ONE subclass) │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Checking │ │ Savings │ │MoneyMrkt │ ├──────────┤ ├──────────┤ ├──────────┤ │overdraft │ │ int_rate │ │ int_rate │ │ _limit │ │ │ │ min_bal │ └──────────┘ └──────────┘ └──────────┘ Reading: "Every Account is exactly one of: Checking, Savings, or MoneyMarket"| Element | Notation | Meaning |
|---|---|---|
| Disjoint constraint | 'd' inside circle | Mutually exclusive subclasses |
| Overlapping constraint | 'o' inside circle | Non-exclusive subclasses |
| Total participation | Double line (═══) | Every entity must be specialized |
| Partial participation | Single line (───) | Specialization is optional |
| Specialization circle | Circle/oval connecting classes | Represents the 'is-a' relationship |
| Subclass connection | Lines from circle to subclasses | Shows the subclass entities |
UML (Unified Modeling Language) is the dominant standard in software engineering and object-oriented design. UML class diagrams incorporate EER concepts using a distinct notation that integrates with broader software modeling.
Historical Context:
UML emerged in the mid-1990s from the work of Grady Booch, Ivar Jacobson, and James Rumbaugh. It unified various OO modeling approaches and became an OMG (Object Management Group) standard. UML's generalization notation aligns with object-oriented inheritance.
Key Notation Elements:
1. Generalization Arrow
2. Constraint Annotations
3. Abstract Class Notation
4. Generalization Set
12345678910111213141516171819202122232425262728
UML NOTATION: Complete + Disjoint (Total + Disjoint)════════════════════════════════════════════════════ ┌─────────────────────────┐ │ *Account* │ ← Italics = Abstract class ├─────────────────────────┤ (cannot be instantiated directly) │ - accountId: Integer │ │ - balance: Decimal │ │ - openDate: Date │ ├─────────────────────────┤ │ + deposit(amt: Decimal) │ │ + withdraw(amt: Decimal)│ └────────────┬────────────┘ △ │ │ {complete, disjoint} │ ← Constraint annotation ┌─────────────┼─────────────┐ │ │ │┌─────────┴─────────┐ ┌─┴───────────┐ ┌────┴────────────┐│ CheckingAccount │ │SavingsAccount│ │MoneyMarketAccount│├───────────────────┤ ├─────────────┤ ├──────────────────┤│- overdraftLimit │ │- interestRate│ │- interestRate ││ │ │ │ │- minimumBalance │└───────────────────┘ └─────────────┘ └──────────────────┘ Reading: "Account is an abstract class that must be instantiated as exactly one of CheckingAccount, SavingsAccount, or MoneyMarketAccount"| Annotation | Meaning | Chen Equivalent |
|---|---|---|
| {disjoint} | Entity in at most one subclass | 'd' in circle |
| {overlapping} | Entity may be in multiple subclasses | 'o' in circle |
| {complete} | Every entity must be in a subclass | Double line (total) |
| {incomplete} | Entity may not be in any subclass | Single line (partial) |
| {complete, disjoint} | Exactly one subclass required | Double line + 'd' |
| {incomplete, overlapping} | Zero to many subclasses | Single line + 'o' |
Be aware of default assumptions: In UML, if no constraint is specified, many tools assume {incomplete, disjoint}. In Chen notation, the absence of a double line implies partial, but disjoint/overlapping must usually be specified. Always make constraints explicit to avoid ambiguity.
Crow's Foot notation (also called IE - Information Engineering notation) is widely used in industry, particularly in database design tools. It's named after the three-pronged symbol (resembling a crow's foot) used to indicate 'many' in cardinality.
Historical Context:
Crow's Foot notation evolved from Clive Finkelstein and James Martin's Information Engineering methodology in the 1970s-80s. It was designed for practical database design and is less focused on conceptual modeling than Chen notation.
Specialization in Crow's Foot:
Crow's Foot notation wasn't originally designed for specialization/generalization, so different tools have added these capabilities inconsistently. Common approaches include:
1. Category/Subtype Symbols
2. Arc Notation
3. Discriminator Attribute
12345678910111213141516171819202122232425262728
CROW'S FOOT: Exclusive (Disjoint) Subtypes════════════════════════════════════════════ ┌──────────────────┐ │ ACCOUNT │ ├──────────────────┤ │ PK account_id │ │ balance │ │ D account_type │ ← 'D' indicates Discriminator └────────┬─────────┘ │ ◯ ← Subtype circle/symbol ╱│╲ ╱ │ ╲ ╱ │ ╲ ╳───────╳ ← Arc with X marks = EXCLUSIVE (Disjoint) ╱ │ ╲ ╱ │ ╲ ┌───────────┴┐ ┌───┴───────┐ ┌┴───────────────┐ │ CHECKING │ │ SAVINGS │ │ MONEY_MARKET │ ├────────────┤ ├───────────┤ ├────────────────┤ │ FK acct_id │ │FK acct_id │ │ FK acct_id │ │ overdraft │ │int_rate │ │ int_rate │ │ _limit │ │ │ │ min_balance │ └────────────┘ └───────────┘ └────────────────┘ Reading: ACCOUNT is exclusively (disjoint) one of: CHECKING, SAVINGS, or MONEY_MARKET The 'account_type' discriminator determines which subtype applies.Crow's Foot notation for specialization is not standardized. ERwin, Oracle Data Modeler, MySQL Workbench, Lucidchart, and draw.io all use slightly different symbols. Always consult the specific tool's documentation and include a legend in your diagrams when sharing across tools or teams.
The textbook "Fundamentals of Database Systems" by Elmasri and Navathe is one of the most widely used database textbooks globally. Its EER notation is a refined version of Chen's approach and is standard in academic curricula.
Key Characteristics:
Elmasri & Navathe notation closely follows Chen but with some refinements:
1. Circle Representation
2. Constraint Representation
3. Participation Representation
4. Direction Indication
5. Attribute Inheritance
123456789101112131415161718192021222324252627282930313233343536
ELMASRI & NAVATHE: Standard Notation═════════════════════════════════════ ┌─────────────┐ │ VEHICLE │◄──── Superclass (rectangle) │ │ │ VehicleID │◄──── Key attribute (underlined or marked) │ Make │ │ Model │ │ Year │ └──────┬──────┘ ║ ◄──── Double line = Total participation ║ (every vehicle must be specialized) ╭─╮ │d│ ◄──── 'd' = Disjoint constraint ╰─╯ (vehicle is exactly one type) │ ┌─────────────────┼─────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ CAR │ │ TRUCK │ │ SUV │ │ │ │ │ │ │ │Num_Doors│ │Max_Load │ │Num_Seats│ │ Trunk │ │Axles │ │AWD_Type │ │ Size │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ Subclass-specific attributes (local to each subclass) INTERPRETATION:- VEHICLE is superclass with shared attributes (VehicleID, Make, Model, Year)- CAR, TRUCK, SUV are subclasses with their own local attributes- Total + Disjoint: Every vehicle is exactly one of CAR, TRUCK, or SUV- CAR inherits VehicleID, Make, Model, Year and adds Num_Doors, TrunkSize| Element | Symbol | Description |
|---|---|---|
| Superclass | Rectangle at top | Entity with inherited attributes |
| Subclass | Rectangle below | Entity with local + inherited attributes |
| Specialization circle | Circle with d/o | Connects super to sub |
| Disjoint | 'd' in circle | Mutually exclusive |
| Overlapping | 'o' in circle | Non-exclusive |
| Total | Double line | All entities specialized |
| Partial | Single line | Some entities unspecialized |
| Defining attribute | Attribute name near circle | Attribute that determines subclass |
In practice, you'll encounter diagrams in various notations and need to translate designs between tools and audiences. Here's a systematic approach to notation translation.
Translation Principles:
Common Translation Challenges:
| Constraint | Chen/E&N | UML | Crow's Foot |
|---|---|---|---|
| Disjoint | 'd' in circle | {disjoint} | Arc/X across lines |
| Overlapping | 'o' in circle | {overlapping} | No arc |
| Total | Double line ═══ | {complete} | Mandatory symbol or noted |
| Partial | Single line ─── | {incomplete} | Optional symbol or noted |
| Superclass | Rectangle above | Class with hollow △ pointing to it | Entity with lines to subtypes |
| Subclass | Rectangle below | Class with line to △ | Subtype entity |
| Discriminator | Defining attribute noted | Generalization set name | 'D' attribute marker |
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576
SAME SPECIALIZATION IN THREE NOTATIONS═══════════════════════════════════════ Semantic Description:"Every Payment must be exactly one type: Cash, Credit, or Debit. Cash has received_amount; Credit has card_number, exp_date; Debit has card_number, pin_verified." ───────────────────────────────────────────────────────────────── CHEN/ELMASRI NOTATION: ┌─────────────┐ │ PAYMENT │ │ payment_id │ │ amount │ │ pay_date │ └──────┬──────┘ ║ (d) ← Total (double line) + Disjoint ('d') │ ┌───────┼───────┐ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │ CASH │ │CREDIT│ │ DEBIT│ │recvd │ │card# │ │card# │ │ _amt │ │expiry│ │pin_ok│ └──────┘ └──────┘ └──────┘ ───────────────────────────────────────────────────────────────── UML NOTATION: ┌─────────────────────┐ │ «abstract» │ ← Abstract indicates Total │ Payment │ ├─────────────────────┤ │ - paymentId: Long │ │ - amount: Decimal │ │ - payDate: Date │ └──────────┬──────────┘ △ │ {complete, disjoint} │ ┌───────────┼───────────┐ │ │ │┌─────┴─────┐ ┌───┴────┐ ┌────┴────┐│CashPayment│ │CreditPmt│ │DebitPmt │├───────────┤ ├────────┤ ├─────────┤│-recvdAmt │ │-cardNum│ │-cardNum ││ │ │-expDate│ │-pinOk │└───────────┘ └────────┘ └─────────┘ ───────────────────────────────────────────────────────────────── CROW'S FOOT NOTATION: ┌─────────────────┐ │ PAYMENT │ ├─────────────────┤ │PK payment_id │ │ amount │ │ pay_date │ │D pay_type ◄────┼──── Discriminator marker └────────┬────────┘ │ ◯ ╱│╲ ─X─X─ ← Arc with X = Exclusive (Disjoint) ╱ │ ╲ Total implied by mandatory ╱ │ ╲ relationship symbols ┌─────┴─┐ ┌┴────┐ ┌┴─────┐ │ CASH │ │CREDIT│ │DEBIT │ │recv_amt│ │card#│ │card# │ │ │ │exp │ │pin_ok│ └───────┘ └─────┘ └──────┘Remember: notation is a communication tool, not an end in itself. If your audience understands the design, the notation has served its purpose. When in doubt, add text annotations to clarify constraints, especially when using tools that don't fully support your desired notation.
Selecting the appropriate notation depends on your audience, tool constraints, and modeling goals. Here's guidance for common scenarios:
Academic Settings:
Software Engineering Teams:
Database Administration:
Business Stakeholders:
Mixed Audiences:
| Context | Recommended Notation | Reasoning |
|---|---|---|
| University coursework | Chen/Elmasri & Navathe | Matches textbooks and exams |
| Software design docs | UML | Integrates with class diagrams, sequence diagrams |
| Database design specs | Crow's Foot (ERwin style) | Maps directly to DDL, tool forward engineering |
| Executive presentation | Simplified with labels | Focus on concepts, not symbols |
| Cross-functional teams | UML with legends | Balance between rigor and accessibility |
| Version-controlled docs | PlantUML or Mermaid | Text-based, diff-friendly |
Mastering specialization constraint notation enables clear communication across academia, industry, and diverse stakeholder groups. Let's consolidate the essential knowledge:
| Constraint | Chen | UML | Crow's Foot |
|---|---|---|---|
| Disjoint | 'd' | {disjoint} | Arc/X |
| Overlapping | 'o' | {overlapping} | No arc |
| Total | ═══ (double) | {complete} | Mandatory |
| Partial | ─── (single) | {incomplete} | Optional |
You now possess fluency in reading and writing specialization constraints across all major notation systems. You can translate between notations, choose appropriate representations for your audience, and communicate complex hierarchies clearly. Next, we explore Business Rule Modeling—capturing real-world constraints in EER designs.