Barker's Notation¶

ThinkERD uses Barker's Notation. This page explains the core concepts of Barker's Notation, how it differs from other notations, and how it is specifically applied in ThinkERD.

Why Barker's Notation?¶

There are several ERD notations available, but ThinkERD's choice of Barker's Notation is deliberate.

Notation Comparison¶

Feature	Barker's Notation	IE Notation (Crow's Foot)	UML Class Diagram
Relationship expression	Cardinality + optionality integrated into the line itself	Symbols at line endpoints	Text numbers (0..*, 1..1)
Identifying/Non-identifying	Instantly distinguished by solid/dashed lines	Requires separate indicator	No distinction
Optionality	Directly expressed on the line (mandatory/optional)	Requires separate markers	Text-only
Subtypes	Natively supported (nested boxes)	Requires separate notation	Expressed as inheritance
Readability	⭐⭐⭐ High — grasped at a glance	⭐⭐ Moderate	⭐ Text-dependent
Large-scale ERDs	⭐⭐⭐ Meaning conveyed by line shape alone	⭐⭐ Small symbols are hard to distinguish	⭐ Gets complex

The advantage of Barker's Notation

"You can tell the meaning just by looking at the line shape." Whether it's solid or dashed, whether the end forks or not — you can instantly determine if it's an identifying relationship, 1:N, mandatory, or optional. This advantage is overwhelming in large-scale ERDs with hundreds of entities.

Entity Representation¶

In Barker's Notation, entities are represented as rounded rectangles.

Components¶

┌─────────────────────────┐
│       Customer          │  ← Entity name (top)
├─────────────────────────┤
│ # Customer No           │  ← PK (# marker + UID Bar)
│ * Customer Name         │  ← Mandatory attribute (* marker)
│ * Email                 │
│ ○ Phone                 │  ← Optional attribute (○ marker)
│ ○ Remarks               │
└─────────────────────────┘

Attribute Markers¶

Marker	Meaning	Description
#	Primary Key	Unique identifier for the entity
*	Mandatory	NOT NULL — must have a value
○	Optional	NULL allowed — may be empty

UID Bar¶

PK columns are visually emphasized with a vertical bar (UID Bar) on the left side of the entity. For composite PKs, the UID Bar spans across multiple columns.

Relationship Line Representation¶

The most distinctive feature of Barker's Notation is that all meaning is embedded in the relationship line itself.

1. Identifying vs Non-Identifying Relationships¶

Relationship Type	Line Style	Meaning	Example
Identifying	━━ Solid	FK is part of PK. Cannot exist without parent	Order Item → Order
Non-identifying	┅┅ Dashed	FK is a regular attribute. Can exist independently	Employee → Department

Decision criterion: "Can the child entity exist meaningfully without the parent?"

No → Identifying relationship (solid) — Order Item is meaningless without Order
Yes → Non-identifying relationship (dashed) — Employee can exist without Department

2. Cardinality¶

End Symbol	Meaning	Read as
─ Single line	One	"one..."
─< Forked line (Crow's Foot)	Many	"multiple..."

3. Optionality (Mandatory/Optional)¶

Distinguished by whether the end segment of the relationship line is solid or dashed:

End Segment	Meaning	Read as
━━ Solid segment	Mandatory	"must have"
┅┅ Dashed segment	Optional	"may not have"

4. Comprehensive Reading Examples¶

Customer — Order Relationship¶

Customer ┅┅┅┅─────< Order

Reading:

Customer → Order direction: "One customer may have multiple orders" (optional, 1:N)
Order → Customer direction: "One order must belong to one customer" (mandatory, N:1)

Order — Order Item Relationship (Identifying)¶

Order ━━━━━━━< Order Item

Reading:

Solid line = Identifying relationship → Order Item cannot exist without Order
Crow's Foot = 1:N → One order has multiple items
Both sides mandatory → An order must have items

Subtype Representation¶

Barker's Notation natively supports subtypes. Sub-types are represented as nested boxes within the supertype entity.

┌───────────── Employee ──────────────┐
│ # Employee No                       │
│ * Name                              │
│ * Employee Type Code (Discriminator)│
│ ┌──────────┐ ┌──────────┐ ┌──────┐ │
│ │ Permanent│ │ Contract │ │Intern│ │
│ │  (PERM)  │ │  (CONT)  │ │(INTL)│ │
│ └──────────┘ └──────────┘ └──────┘ │
└─────────────────────────────────────┘

→ Subtype details: Subtypes

Exclusive Arc¶

A constraint where only one of two relationships can be active is represented by an arc symbol between the relationship lines.

         ┌─── Credit Card
Payment ──┤ ⌒ (XOR)
         └─── Bank Transfer

→ Exclusive Arc details: Exclusive Arcs

FAQ¶

How does Barker's Notation differ from IE (Crow's Foot) notation?

The biggest difference is the expression of optionality. IE notation adds circles (○) or bars (|) at line endpoints, while Barker's Notation expresses it through solid/dashed segments of the line itself. Barker's Notation is more intuitive and provides higher readability in large-scale ERDs.

Our team has been using IE notation — is it hard to switch?

The core concepts (entities, relationships, cardinality) are identical. The only differences are line shapes and markers. Most data modelers adapt within 1–2 hours.

Is Barker's Notation also used for physical models?

In ThinkERD, both logical and physical modes use Barker's Notation. In physical mode, entity and attribute names switch to table/column names, but the relationship line notation remains the same.