Skip to content

Subtypes

Subtypes are a core element of Barker's Notation that represent supertype–subtype relationships within entities. When a single entity can be classified into multiple types, each type is defined as a subtype.

Concept

In the real world, data often shares common attributes while differing by type. Subtypes model these relationships precisely.

Employee
├── Permanent — Base salary, pay grade
├── Contract — Contract period, contract amount
└── Intern — University, major
Common: Employee No, Name, Department / Differences: Type-specific attributes

Payment
├── Credit Card — Card number, expiration date
├── Bank Transfer — Bank code, account number
└── Mobile Pay — Service code, auth key
Common: Payment No, Amount, Date / Differences: Method-specific attributes

Account
├── Checking — Daily withdrawal limit
├── Savings — Interest rate, maturity date
└── Installment — Monthly payment, installment count

Defining Subtypes

  1. Right-click on the supertype entity → Define Subtype
  2. Configure in the subtype dialog:
Field Description Example
Discriminator The Discriminator Column that distinguishes subtypes EMP_TYPE_CD
Subtype Items Add sub-types Permanent, Contract, Intern
Discriminator Value Identification value for each item PERM, CONT, INTERN

Visual Representation

Subtypes are displayed as nested boxes within the supertype entity. Each subtype item is automatically distinguished by a unique color.

Subtype Visualization Screen showing nested subtype boxes distinguished by color within the supertype entity

Color Palette

ThinkERD automatically assigns 8 preset colors. Colors can be changed manually.

Order Color Order Color
1st 🟢 Green 5th 🟠 Orange
2nd 🔵 Blue 6th 🔴 Red
3rd 🟣 Indigo 7th 🟤 Brown
4th 🟪 Purple 8th ⚫ Gray

Interactions

Action Description
Move Drag subtype boxes within the entity
Resize Drag box corners to resize
Edit Double-click to modify subtype settings
Select Click to select individual subtypes

Inclusion Mode

Defines the relationship between subtype items.

Mode Meaning Example
Exclusive (default) Items are mutually exclusive. Belongs to only one type An employee can be only permanent, contract, or intern
Inclusive Overlap allowed. Can belong to multiple types simultaneously An employee can be both Manager and Trainer

Physical Model Conversion Strategies

Subtypes are a logical model concept, so a physical strategy must be chosen when converting to an actual database.

Strategy Structure Pros Cons
Single Table All subtypes in one table No JOINs needed, simple queries Many NULL columns
Separate Tables Each subtype in its own table Each table is clean Common attributes duplicated, complex supertype queries
Super + Sub Tables Common table + type-specific tables Normalized, flexible JOINs required

Selection Criteria

  • If subtypes have few unique attributes → Single Table (Simple, most cases)
  • If subtypes have many unique attributes → Super + Sub Tables (Normalized)
  • If each subtype needs to be managed independently → Separate Tables

Practical Recommendation

In most real-world projects, the Single Table strategy is the most commonly used. It's simple to implement, performs well, and the burden of NULL columns is usually not significant in practice.

Subtypes vs Exclusive Arcs

Criterion Subtypes Exclusive Arcs
What it represents One entity having multiple types One entity connecting to only one of several others
Structure Nested within the supertype entity Arc symbol between relationship lines
Visual Boxes inside an entity Arc between relationship lines
Example Employee → Payment → Credit Card or Bank Transfer
Decision question "What type is this entity?" "Where does this entity connect?"