Relationships & FK¶

Defining Relationships between entities automatically creates FK columns and displays relationship lines on the canvas. ThinkERD visualizes relationships using Barker's Notation.

Relationship Lines — cardinality and optionality in Barker's Notation

Creating Relationships¶

Basic Method¶

Drag the PK column handle from the source entity
Connect to the target entity
The behavior differs based on where you connect:

Connection Target	Behavior	Result
Target column handle	Converts that column to FK	Existing column becomes FK
Target entity surface	Auto-creates FK column (based on source PK)	Auto-named e.g., `CUST_NO`

FK Name Conflicts

If a column with the same name already exists, suffixes like _2, _3 are automatically added.

Validation¶

The following conditions are validated when creating relationships:

The source entity must have a PK defined
Self-referencing relationships are supported (e.g., Employee → Manager)
Validation failures are communicated via toast notifications

Barker's Notation Details¶

Barker's Notation expresses type, cardinality, and optionality of relationships through the shape of the relationship line itself.

Identifying vs Non-Identifying Relationships¶

Relationship Type	Line Style	Meaning	Example
Identifying	Solid line	FK is part of PK — cannot exist without parent	Order Item cannot exist without Order
Non-identifying	Dashed line	FK is a regular attribute — can exist independently	Employee is related to Department but independent

Choosing between identifying vs non-identifying

"Can the child exist without the parent?" → No → Identifying relationship
"Does the child have independent meaning?" → Yes → Non-identifying relationship
In practice, non-identifying relationships are more commonly used

Cardinality¶

Expresses the numerical relationship.

Symbol	Meaning	Read as
Crow's Foot	Many side	"multiple..."
Single line	One side	"one..."

Practical Examples¶

Relationship	Reading	Meaning
Customer ──< Order	1:N	One customer can have multiple orders
Order ──< Order Item	1:N	One order contains multiple items
Employee ──○ Employee	1:N (self-ref)	One employee can have multiple subordinates

Optionality¶

Expresses whether participation is mandatory or optional. In Barker's Notation, this is distinguished by markers at the ends of the relationship line.

Symbol	Meaning	Example
Solid segment	Mandatory	An order must always have a customer
Dashed segment	Optional	An employee may not have a department

Full Notation Summary¶

Relationship	Line Type	Cardinality	Optionality	Meaning
Customer → Order	Dashed	1:N	Customer side optional	A customer may have no orders
Order → Customer	Dashed	N:1	Order side mandatory	An order must belong to a customer
Order → Order Item	Solid	1:N	Both mandatory	Order Item cannot exist without Order

Relationship Patterns¶

1:N Relationship (Most Common)¶

Customer ──────< Order
(PK: CUST_NO)  (FK: CUST_NO)

M:N Relationship (Using Bridge Entity)¶

M:N relationships are not directly represented; instead, they are decomposed into two 1:N relationships via a bridge (associative) entity.

Student ──< Enrollment >── Course
             (Student_No FK, Course_Code FK)

Self-Referencing Relationship¶

Represents hierarchical structures within the same entity.

Employee ──○ Employee
(PK: EMP_NO, FK: MGR_EMP_NO)

Used for org charts, category hierarchies, menu trees, etc.
Relationship lines are distributed across the entity's 4 corners to avoid visual overlap

Relationship Line Routing¶

Relationship lines are automatically routed using orthogonal paths (Manhattan Routing).

Lines are automatically recalculated when entities are moved
Rounded corners improve readability
Lines automatically reroute to avoid passing through entities

Editing & Deleting Relationships¶

Editing¶

Right-click on a relationship line → Edit to modify relationship properties:

Change cardinality (1:1, 1:N)
Toggle identifying/non-identifying
Change optionality (mandatory/optional)

Deleting¶

Right-click on a relationship line → Delete. A confirmation dialog is shown before deletion.

FK Columns

Deleting a relationship does not automatically remove the FK column. Remove it manually if needed.

Exclusive Arcs — Constraint where only one of multiple relationships can be active
Subtypes — Supertype–subtype entity relationships