Entity Relationships in Code - Data Modeling for Low-Level Design | OneNoughtOne

System Design (LLD)Data Modeling for LLD

Data Modeling for Low-Level Design

LevelIntermediate

Duration90 mins

TopicData Modeling for LLD

1 / 4

Entity Relationships in Code

The Bridge Between Data and Behavior

Every software system is fundamentally about data and the relationships between data. A user owns orders. An order contains products. A product belongs to categories. These relationships seem simple when drawn on a whiteboard, but translating them into clean, maintainable, performant code is one of the most challenging aspects of low-level design.

The way you model entity relationships in code has profound implications:

Performance: Poor relationship modeling causes N+1 queries, unnecessary joins, and memory bloat
Maintainability: Tight coupling between entities creates ripple effects when requirements change
Correctness: Broken invariants in relationship handling lead to data corruption
Testability: Overly complex relationship structures make unit testing nearly impossible

This page establishes the foundational concepts of entity relationship modeling—the mental framework that separates engineers who fight their data model from those who leverage it.

What You Will Learn

By the end of this page, you will understand: (1) What entity relationships are and why code-level modeling differs from database modeling, (2) The fundamental types of relationships and their characteristics, (3) How to represent relationships in object-oriented code, (4) The responsibilities that relationships create, and (5) Common pitfalls that lead to unmaintainable systems.

What Are Entity Relationships?

An entity is a distinct object in your domain that has identity and can exist independently. In an e-commerce system: User, Order, Product, Category, Address—these are all entities. Each has a unique identity (usually an ID) and maintains state that changes over time.

An entity relationship describes how entities are connected—the association between them that reflects real-world connections:

A User places Orders
An Order contains OrderItems
An OrderItem references a Product
A Product belongs to Categories

These relationships aren't just conceptual—they impose constraints, define navigation paths, and determine how your system queries and manipulates data.

Relationship Characteristics

•Cardinality — How many entities on each side of the relationship? One-to-one? One-to-many? Many-to-many?
•Directionality — Is the relationship navigable in one direction or both? Can you go from Order to User and from User to Orders?
•Ownership — Which entity 'owns' the relationship? Who is responsible for its lifecycle?
•Optionality — Is the relationship required or optional? Can an Order exist without a User?
•Referential Integrity — What happens when a related entity is deleted? Cascade? Restrict? Set null?

Database vs Code Relationships

Database relationships are expressed through foreign keys and join tables. Code relationships are expressed through object references and collections. These are fundamentally different representations of the same conceptual relationship—and the translation between them is where complexity arises.

The Object-Relational Impedance Mismatch

One of the most fundamental challenges in software engineering is the object-relational impedance mismatch—the disconnect between how relational databases and object-oriented programming languages represent data and relationships.

Relational databases think in terms of:

Tables as flat structures with rows and columns
Foreign keys pointing to primary keys in other tables
Joins to combine data from multiple tables
Set-based operations on collections of rows

Object-oriented code thinks in terms of:

Objects with encapsulated state and behavior
Object references (pointers) to related objects
Navigation through object graphs
Operations on individual objects or small collections

This mismatch creates friction at every interaction point between your code and your database.

Object-Relational Impedance Mismatch
Aspect	Relational Model	Object Model	Conflict
Identity	Primary key equality	Reference equality or equals()	Same data may create different objects
Relationships	Foreign keys (integers)	Object references (pointers)	Must explicitly load and attach objects
Inheritance	Not natively supported	Core language feature	Table-per-class or table-per-hierarchy trade-offs
Encapsulation	All columns visible	Private state, public interface	ORM must bypass encapsulation to hydrate
Navigation	Requires explicit joins	Follow references directly	Lazy loading vs eager loading decisions
Granularity	Fixed table/column structure	Fine-grained object composition	May require multiple tables or single table with nulls

Why This Matters for Relationship Modeling:

When you model a relationship like 'Order contains OrderItems' in code:

The database stores order_id as a foreign key in the order_items table
The code expects Order to have a List<OrderItem> property that contains actual OrderItem objects

Bridging this gap requires decisions:

When do you load the OrderItems? On Order load? On demand? Never?
How do you keep the in-memory collection synchronized with the database?
What if the same OrderItem is referenced from multiple places in memory?

Every relationship modeling decision carries implications for these bridging questions.

The Leaky Abstraction

No ORM fully hides the relational model. At some point, you will need to understand what SQL is generated, how joins are performed, and why that innocent-looking property access triggered 47 database queries. The impedance mismatch is managed, never eliminated.

Representing Relationships in Code

In object-oriented languages, entity relationships are represented through object references and collections. Understanding these representations is fundamental to effective data modeling.

Single-valued associations (to-one relationships):

When Entity A relates to exactly one Entity B, you represent this with a direct object reference:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// One-to-One: User has exactly one UserProfile
class User {
  private id: string;
  private email: string;
  private profile: UserProfile; // Direct object reference
  
  getProfile(): UserProfile {
    return this.profile;
  }
  
  updateProfile(profile: UserProfile): void {
    this.profile = profile;
    this.profile.setUser(this); // Maintain bidirectional consistency
  }
}
 
class UserProfile {
  private id: string;
  private bio: string;
  private avatarUrl: string;
  private user: User; // Back-reference for bidirectional navigation
  
  setUser(user: User): void {
    this.user = user;
  }
}
 
// Many-to-One: Order belongs to exactly one User
class Order {
  private id: string;
  private user: User; // Many orders can reference the same user
  private orderDate: Date;
  
  getUser(): User {
    return this.user;
  }
}

Collection-valued associations (to-many relationships):

When Entity A relates to multiple instances of Entity B, you represent this with a collection type:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// One-to-Many: User has many Orders
class User {
  private id: string;
  private email: string;
  private orders: Order[] = []; // Collection of related objects
  
  getOrders(): ReadonlyArray<Order> {
    return [...this.orders]; // Return defensive copy
  }
  
  addOrder(order: Order): void {
    if (!this.orders.includes(order)) {
      this.orders.push(order);
    }
  }
  
  removeOrder(order: Order): void {
    const index = this.orders.indexOf(order);
    if (index > -1) {
      this.orders.splice(index, 1);
    }
  }
}
 
// One-to-Many: Order has many OrderItems
class Order {
  private id: string;
  private items: OrderItem[] = [];
  
  // Encapsulate collection modification
  addItem(product: Product, quantity: number): OrderItem {
    const item = new OrderItem(this, product, quantity);
    this.items.push(item);
    return item;
  }
  
  getItems(): ReadonlyArray<OrderItem> {
    return [...this.items];
  }
  
  getTotal(): Money {
    return this.items.reduce(
      (sum, item) => sum.add(item.getSubtotal()),
      Money.ZERO
    );
  }
}

Collection Choice Guidelines

•Array/List — Use when order matters or duplicates are allowed. Most common for ordered relationships like 'items in an order'.
•Set — Use when uniqueness is guaranteed and order doesn't matter. Good for 'tags on a product' or 'roles of a user'.
•Map — Use when you frequently look up by a key property. 'Order items by product ID' for quick access.
•Sorted collections — Use when you always need sorted results. Consider performance impact of maintaining sort order.

Uni-directional vs Bi-directional Relationships

One of the most impactful decisions in relationship modeling is directionality—whether the relationship can be navigated from one direction, or from both.

Uni-directional relationships: Only one entity holds a reference to the other.

Bi-directional relationships: Both entities hold references to each other, allowing navigation in either direction.

Uni-directional

•Simpler — Only one side manages the relationship
•Less memory — Only one reference stored
•Easier to test — Less setup required for tests
•Clear ownership — Obvious which side owns the relationship
•Limited navigation — Can only traverse in one direction

Bi-directional

•Flexible navigation — Traverse in either direction
•Richer queries — Access related data from any starting point
•Complex consistency — Both sides must stay synchronized
•Memory overhead — References stored on both sides
•Circular reference risk — Can cause issues with serialization

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Uni-directional: Only Order knows about OrderItems
class Order {
  private items: OrderItem[] = [];
  // Order can find its items, but OrderItem doesn't know its Order
}
 
class OrderItem {
  private productId: string;
  private quantity: number;
  // No reference back to Order - simpler, but can't navigate backwards
}
 
// Bi-directional: Both sides know about each other
class Order {
  private items: OrderItem[] = [];
  
  addItem(product: Product, quantity: number): OrderItem {
    const item = new OrderItem(this, product, quantity);
    this.items.push(item);
    return item;
  }
  
  // Internal method for OrderItem to use during removal
  _removeItem(item: OrderItem): void {
    const index = this.items.indexOf(item);
    if (index > -1) this.items.splice(index, 1);
  }
}
 
class OrderItem {
  private order: Order; // Back-reference to parent
  private product: Product;
  private quantity: number;
  
  constructor(order: Order, product: Product, quantity: number) {
    this.order = order;  // Establish back-reference at construction
    this.product = product;
    this.quantity = quantity;
  }
  
  getOrder(): Order {
    return this.order;
  }
  
  remove(): void {
    this.order._removeItem(this); // Coordinate with parent
  }
}

The Pragmatic Default

Start with uni-directional relationships and add the back-reference only when you genuinely need it. Many relationships work perfectly well with navigation in only one direction. Adding bidirectionality 'just in case' creates synchronization complexity that you'll need to maintain forever.

Relationship Ownership and Responsibility

Every relationship has an owner—the entity responsible for managing the relationship's lifecycle. Understanding ownership is critical for maintaining data integrity and preventing subtle bugs.

The Owner's Responsibilities:

Creating and establishing the relationship
Maintaining consistency between related entities
Defining cascade behavior (what happens when the owner is deleted)
Ensuring the relationship's invariants are preserved

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// Order OWNS its OrderItems - it controls their lifecycle
class Order {
  private id: string;
  private items: OrderItem[] = [];
  private status: OrderStatus;
  
  // Order controls item creation - items can't exist outside an order
  addItem(product: Product, quantity: number): OrderItem {
    if (this.status !== OrderStatus.DRAFT) {
      throw new Error("Cannot modify a finalized order");
    }
    
    // Check if product already in order - business rule enforcement
    const existing = this.items.find(i => i.getProductId() === product.id);
    if (existing) {
      existing.incrementQuantity(quantity);
      return existing;
    }
    
    const item = new OrderItem(this, product, quantity);
    this.items.push(item);
    return item;
  }
  
  // Order controls item removal
  removeItem(item: OrderItem): void {
    if (this.status !== OrderStatus.DRAFT) {
      throw new Error("Cannot modify a finalized order");
    }
    
    const index = this.items.indexOf(item);
    if (index === -1) {
      throw new Error("Item not found in this order");
    }
    
    this.items.splice(index, 1);
  }
  
  // When order is deleted, items go with it (cascade)
  delete(): void {
    this.items.length = 0; // Clear all items
    // ORM/repository handles actual database deletion
  }
}
 
// OrderItem is OWNED - it doesn't control its own lifecycle
class OrderItem {
  private order: Order;
  private productId: string;
  private quantity: number;
  private unitPrice: Money;
  
  // Private constructor - can only be created through Order
  constructor(order: Order, product: Product, quantity: number) {
    this.order = order;
    this.productId = product.id;
    this.quantity = quantity;
    this.unitPrice = product.currentPrice;
  }
  
  // Item can request removal, but Order makes the decision
  requestRemoval(): void {
    this.order.removeItem(this);
  }
}

Ownership Patterns by Relationship Type
Relationship	Owner	Owned	Cascade Behavior
Order → OrderItems	Order	OrderItem	Delete order → delete items
User → Orders	User	Order	Delete user → keep orders (archive) or cascade
Product → Categories	Neither (association)	Neither	Delete product → remove from category only
Company → Departments → Employees	Company → Departments	Departments → Employees	Hierarchical cascade down the chain

The Orphan Problem

When the owner of a relationship is deleted, what happens to owned entities? In a database, foreign key constraints prevent orphans. In code, garbage collection handles memory, but logical orphans (entities that should have been deleted but weren't) cause data corruption. Always define explicit cascade behavior.

Composition vs Aggregation

Two fundamental types of ownership patterns emerge in relationship modeling: Composition and Aggregation. Understanding the difference is crucial for correct lifecycle management.

Composition (strong ownership):

Parts cannot exist independently of the whole
Whole is responsible for part creation and destruction
Parts have no identity outside the whole
Deleting the whole automatically deletes all parts

Aggregation (weak ownership):

Parts can exist independently
Whole references parts but doesn't control their lifecycle
Parts may be shared between multiple wholes
Deleting the whole leaves parts intact

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
// COMPOSITION: Order and OrderItems
// OrderItems cannot exist without an Order
// Deleting Order deletes all its OrderItems
class Order {
  private items: OrderItem[] = [];
  
  // Factory method ensures OrderItem is always created with Order
  addItem(product: Product, qty: number): OrderItem {
    const item = new OrderItem(product, qty); // No standalone creation
    this.items.push(item);
    return item;
  }
  
  // When Order is deleted, items cease to exist
}
 
// AGGREGATION: ShoppingCart and Products
// Products exist independently of any cart
// Multiple carts can reference the same product
// Deleting cart doesn't affect products
class ShoppingCart {
  private items: Map<Product, number> = new Map(); // References, not ownership
  
  addProduct(product: Product, quantity: number): void {
    // Product exists independently - we just reference it
    const current = this.items.get(product) || 0;
    this.items.set(product, current + quantity);
  }
  
  removeProduct(product: Product): void {
    this.items.delete(product); // Product still exists, just no longer in cart
  }
  
  clear(): void {
    this.items.clear(); // Products unaffected
  }
}
 
// MIXED: Team and Members
// Team 'contains' Members (aggregation - members exist independently)
// But Team 'owns' the Membership records (composition)
class Team {
  private memberships: TeamMembership[] = []; // Composition - we own these
  
  addMember(user: User, role: Role): TeamMembership {
    // User exists independently (aggregation)
    // But TeamMembership is created/destroyed with Team (composition)
    const membership = new TeamMembership(this, user, role);
    this.memberships.push(membership);
    return membership;
  }
}
 
class TeamMembership {
  // Join entity - composed by Team, aggregates User
  constructor(
    private team: Team,    // Owner (composition)
    private user: User,    // Reference (aggregation)
    private role: Role
  ) {}
}

How to Choose: Composition vs Aggregation

•Does the part have meaning outside the whole? If a LineItem means nothing without an Invoice, use composition. If a Product exists in the catalog regardless of carts, use aggregation.
•Does the part have an independent identity? If users reference the part directly (by ID), it likely should exist independently. Use aggregation.
•Can the part belong to multiple wholes? An Employee can be in multiple Teams—use aggregation. An OrderItem belongs to exactly one Order—use composition.
•What happens when the whole is deleted? If parts should be deleted too, composition. If parts should remain, aggregation.

Maintaining Relationship Invariants

Every relationship has invariants—rules that must always hold true for the system to be in a valid state. Maintaining these invariants is one of the most challenging aspects of relationship modeling.

Common relationship invariants:

A bidirectional relationship must be consistent from both sides
Composition must ensure parts are never orphaned
Uniqueness constraints must be enforced in collections
Business rules must be applied at relationship boundaries

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
// Invariant: Bidirectional consistency
// If Order.items contains an OrderItem, that OrderItem.order must equal this Order
 
class Order {
  private items: OrderItem[] = [];
  
  addItem(item: OrderItem): void {
    if (item.getOrder() !== null && item.getOrder() !== this) {
      throw new Error("Item already belongs to another order");
    }
    
    if (!this.items.includes(item)) {
      this.items.push(item);
      item._setOrder(this); // Maintain bidirectional consistency
    }
  }
  
  removeItem(item: OrderItem): void {
    const index = this.items.indexOf(item);
    if (index > -1) {
      this.items.splice(index, 1);
      item._setOrder(null); // Maintain bidirectional consistency
    }
  }
}
 
class OrderItem {
  private order: Order | null = null;
  
  getOrder(): Order | null {
    return this.order;
  }
  
  // Internal method - should not be called directly by application code
  _setOrder(order: Order | null): void {
    this.order = order;
  }
}
 
// Invariant: Uniqueness constraint
// A user cannot have duplicate roles
 
class User {
  private roles: Set<Role> = new Set(); // Set enforces uniqueness
  
  addRole(role: Role): boolean {
    if (this.roles.has(role)) {
      return false; // Already has role
    }
    this.roles.add(role);
    return true;
  }
  
  hasRole(role: Role): boolean {
    return this.roles.has(role);
  }
}
 
// Invariant: Business rule at relationship boundary
// An order can only have items if total doesn't exceed credit limit
 
class Order {
  private items: OrderItem[] = [];
  private customer: Customer;
  
  addItem(product: Product, quantity: number): OrderItem {
    const itemTotal = product.price.multiply(quantity);
    const newTotal = this.getTotal().add(itemTotal);
    
    if (newTotal.exceeds(this.customer.creditLimit)) {
      throw new CreditLimitExceededError(
        this.customer.creditLimit,
        newTotal
      );
    }
    
    const item = new OrderItem(this, product, quantity);
    this.items.push(item);
    return item;
  }
}

The Consistency Window

Between the moment you call item.setOrder(order) and order.addItem(item), the relationship is in an inconsistent state. If an exception occurs between these two calls, your data is corrupted. Always design relationship modifications to be atomic—either both sides update or neither does.

Common Pitfalls in Relationship Modeling

Even experienced engineers fall into these relationship modeling traps. Understanding them helps you avoid costly redesigns.

Anti-patterns to Avoid

•Exposing mutable collections — Returning this.items directly allows callers to bypass your encapsulation. Always return immutable views or defensive copies.
•Forgetting bidirectional synchronization — Adding an item to a collection without updating the item's back-reference creates inconsistent state.
•Over-fetching relationships — Loading every related entity eagerly when you only need IDs causes massive performance problems.
•Circular dependencies — A → B → C → A relationship cycles make initialization order impossible and create memory leaks in some languages.
•Relationship logic scattered across codebase — Modifying relationships in multiple places makes invariant checking impossible.
•Treating all relationships as bidirectional — Many relationships only need navigation in one direction. Bidirectionality adds complexity worth avoiding.
•Ignoring transaction boundaries — Relationship changes that span multiple aggregates require careful transaction management.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// ❌ ANTI-PATTERN: Exposing mutable collection
class Order {
  public items: OrderItem[] = []; // Direct access bypasses invariants
}
 
// External code can do this:
order.items.push(new OrderItem(...)); // Bypasses validation!
order.items.length = 0; // Clears order without business logic!
 
// ✅ CORRECT: Encapsulate collection access
class Order {
  private items: OrderItem[] = [];
  
  getItems(): ReadonlyArray<OrderItem> {
    return this.items; // TypeScript prevents mutation
  }
  
  addItem(product: Product, qty: number): OrderItem {
    // All invariants checked here
    this.validateCanModify();
    this.validateCreditLimit(product, qty);
    
    const item = new OrderItem(this, product, qty);
    this.items.push(item);
    return item;
  }
}
 
// ❌ ANTI-PATTERN: Inconsistent bidirectional update
class Team {
  addMember(user: User): void {
    this.members.push(user);
    // Forgot to call user.joinTeam(this)!
    // Now user.getTeams() won't include this team
  }
}
 
// ✅ CORRECT: Atomic bidirectional update
class Team {
  addMember(user: User): void {
    if (!this.members.includes(user)) {
      this.members.push(user);
      user._addTeam(this); // Internal method maintains consistency
    }
  }
}

Summary: Entity Relationships in Code

Entity relationship modeling is the foundation of effective data layer design. The decisions you make here ripple through your entire system—affecting performance, maintainability, and correctness.

Key Takeaways

•Entity relationships define system structure — They determine how data flows, how queries are structured, and how changes propagate.
•The impedance mismatch is real — Object references and foreign keys represent the same concept differently. This gap requires constant bridging.
•Directionality is a key decision — Start unidirectional; add bidirectionality only when navigation truly requires it.
•Ownership defines lifecycle — The owner controls creation, deletion, and cascade behavior. Ambiguous ownership causes bugs.
•Composition vs aggregation matters — Know whether parts can exist independently. This determines your delete strategy.
•Invariants must be protected — Encapsulate collection access and ensure atomic updates to prevent inconsistent states.
•Avoid common pitfalls — Mutable collection exposure, forgotten synchronization, and over-fetching are the primary killers.

What's next:

Now that we understand the conceptual foundations of entity relationships, the next page dives deep into the specific relationship types: one-to-one, one-to-many, and many-to-many. We'll examine implementation patterns, performance characteristics, and common design decisions for each type.

Foundation Established

You now understand the fundamental concepts of entity relationship modeling: what relationships are, how they're represented in code, directionality, ownership, composition vs aggregation, and invariant maintenance. Next, we'll apply these concepts to specific relationship types.

1 / 4

Loading learning content...

System Design (LLD)Data Modeling for LLD

Data Modeling for Low-Level Design

LevelIntermediate

Duration90 mins

TopicData Modeling for LLD

1 / 4

Entity Relationships in Code

The Bridge Between Data and Behavior

The way you model entity relationships in code has profound implications:

Performance: Poor relationship modeling causes N+1 queries, unnecessary joins, and memory bloat
Maintainability: Tight coupling between entities creates ripple effects when requirements change
Correctness: Broken invariants in relationship handling lead to data corruption
Testability: Overly complex relationship structures make unit testing nearly impossible

This page establishes the foundational concepts of entity relationship modeling—the mental framework that separates engineers who fight their data model from those who leverage it.

What You Will Learn

What Are Entity Relationships?

An entity relationship describes how entities are connected—the association between them that reflects real-world connections:

A User places Orders
An Order contains OrderItems
An OrderItem references a Product
A Product belongs to Categories

These relationships aren't just conceptual—they impose constraints, define navigation paths, and determine how your system queries and manipulates data.

Relationship Characteristics

•Cardinality — How many entities on each side of the relationship? One-to-one? One-to-many? Many-to-many?
•Directionality — Is the relationship navigable in one direction or both? Can you go from Order to User and from User to Orders?
•Ownership — Which entity 'owns' the relationship? Who is responsible for its lifecycle?
•Optionality — Is the relationship required or optional? Can an Order exist without a User?
•Referential Integrity — What happens when a related entity is deleted? Cascade? Restrict? Set null?

Database vs Code Relationships

The Object-Relational Impedance Mismatch

Relational databases think in terms of:

Tables as flat structures with rows and columns
Foreign keys pointing to primary keys in other tables
Joins to combine data from multiple tables
Set-based operations on collections of rows

Object-oriented code thinks in terms of:

Objects with encapsulated state and behavior
Object references (pointers) to related objects
Navigation through object graphs
Operations on individual objects or small collections

This mismatch creates friction at every interaction point between your code and your database.

Object-Relational Impedance Mismatch
Aspect	Relational Model	Object Model	Conflict
Identity	Primary key equality	Reference equality or equals()	Same data may create different objects
Relationships	Foreign keys (integers)	Object references (pointers)	Must explicitly load and attach objects
Inheritance	Not natively supported	Core language feature	Table-per-class or table-per-hierarchy trade-offs
Encapsulation	All columns visible	Private state, public interface	ORM must bypass encapsulation to hydrate
Navigation	Requires explicit joins	Follow references directly	Lazy loading vs eager loading decisions
Granularity	Fixed table/column structure	Fine-grained object composition	May require multiple tables or single table with nulls

Why This Matters for Relationship Modeling:

When you model a relationship like 'Order contains OrderItems' in code:

The database stores order_id as a foreign key in the order_items table
The code expects Order to have a List<OrderItem> property that contains actual OrderItem objects

Bridging this gap requires decisions:

When do you load the OrderItems? On Order load? On demand? Never?
How do you keep the in-memory collection synchronized with the database?
What if the same OrderItem is referenced from multiple places in memory?

Every relationship modeling decision carries implications for these bridging questions.

The Leaky Abstraction

Representing Relationships in Code

In object-oriented languages, entity relationships are represented through object references and collections. Understanding these representations is fundamental to effective data modeling.

Single-valued associations (to-one relationships):

When Entity A relates to exactly one Entity B, you represent this with a direct object reference:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// One-to-One: User has exactly one UserProfile
class User {
  private id: string;
  private email: string;
  private profile: UserProfile; // Direct object reference
  
  getProfile(): UserProfile {
    return this.profile;
  }
  
  updateProfile(profile: UserProfile): void {
    this.profile = profile;
    this.profile.setUser(this); // Maintain bidirectional consistency
  }
}
 
class UserProfile {
  private id: string;
  private bio: string;
  private avatarUrl: string;
  private user: User; // Back-reference for bidirectional navigation
  
  setUser(user: User): void {
    this.user = user;
  }
}
 
// Many-to-One: Order belongs to exactly one User
class Order {
  private id: string;
  private user: User; // Many orders can reference the same user
  private orderDate: Date;
  
  getUser(): User {
    return this.user;
  }
}

Collection-valued associations (to-many relationships):

When Entity A relates to multiple instances of Entity B, you represent this with a collection type:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// One-to-Many: User has many Orders
class User {
  private id: string;
  private email: string;
  private orders: Order[] = []; // Collection of related objects
  
  getOrders(): ReadonlyArray<Order> {
    return [...this.orders]; // Return defensive copy
  }
  
  addOrder(order: Order): void {
    if (!this.orders.includes(order)) {
      this.orders.push(order);
    }
  }
  
  removeOrder(order: Order): void {
    const index = this.orders.indexOf(order);
    if (index > -1) {
      this.orders.splice(index, 1);
    }
  }
}
 
// One-to-Many: Order has many OrderItems
class Order {
  private id: string;
  private items: OrderItem[] = [];
  
  // Encapsulate collection modification
  addItem(product: Product, quantity: number): OrderItem {
    const item = new OrderItem(this, product, quantity);
    this.items.push(item);
    return item;
  }
  
  getItems(): ReadonlyArray<OrderItem> {
    return [...this.items];
  }
  
  getTotal(): Money {
    return this.items.reduce(
      (sum, item) => sum.add(item.getSubtotal()),
      Money.ZERO
    );
  }
}

Collection Choice Guidelines

•Array/List — Use when order matters or duplicates are allowed. Most common for ordered relationships like 'items in an order'.
•Set — Use when uniqueness is guaranteed and order doesn't matter. Good for 'tags on a product' or 'roles of a user'.
•Map — Use when you frequently look up by a key property. 'Order items by product ID' for quick access.
•Sorted collections — Use when you always need sorted results. Consider performance impact of maintaining sort order.

Uni-directional vs Bi-directional Relationships

One of the most impactful decisions in relationship modeling is directionality—whether the relationship can be navigated from one direction, or from both.

Uni-directional relationships: Only one entity holds a reference to the other.

Bi-directional relationships: Both entities hold references to each other, allowing navigation in either direction.

Uni-directional

•Simpler — Only one side manages the relationship
•Less memory — Only one reference stored
•Easier to test — Less setup required for tests
•Clear ownership — Obvious which side owns the relationship
•Limited navigation — Can only traverse in one direction

Bi-directional

•Flexible navigation — Traverse in either direction
•Richer queries — Access related data from any starting point
•Complex consistency — Both sides must stay synchronized
•Memory overhead — References stored on both sides
•Circular reference risk — Can cause issues with serialization

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Uni-directional: Only Order knows about OrderItems
class Order {
  private items: OrderItem[] = [];
  // Order can find its items, but OrderItem doesn't know its Order
}
 
class OrderItem {
  private productId: string;
  private quantity: number;
  // No reference back to Order - simpler, but can't navigate backwards
}
 
// Bi-directional: Both sides know about each other
class Order {
  private items: OrderItem[] = [];
  
  addItem(product: Product, quantity: number): OrderItem {
    const item = new OrderItem(this, product, quantity);
    this.items.push(item);
    return item;
  }
  
  // Internal method for OrderItem to use during removal
  _removeItem(item: OrderItem): void {
    const index = this.items.indexOf(item);
    if (index > -1) this.items.splice(index, 1);
  }
}
 
class OrderItem {
  private order: Order; // Back-reference to parent
  private product: Product;
  private quantity: number;
  
  constructor(order: Order, product: Product, quantity: number) {
    this.order = order;  // Establish back-reference at construction
    this.product = product;
    this.quantity = quantity;
  }
  
  getOrder(): Order {
    return this.order;
  }
  
  remove(): void {
    this.order._removeItem(this); // Coordinate with parent
  }
}

The Pragmatic Default

Relationship Ownership and Responsibility

Every relationship has an owner—the entity responsible for managing the relationship's lifecycle. Understanding ownership is critical for maintaining data integrity and preventing subtle bugs.

The Owner's Responsibilities:

Creating and establishing the relationship
Maintaining consistency between related entities
Defining cascade behavior (what happens when the owner is deleted)
Ensuring the relationship's invariants are preserved

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// Order OWNS its OrderItems - it controls their lifecycle
class Order {
  private id: string;
  private items: OrderItem[] = [];
  private status: OrderStatus;
  
  // Order controls item creation - items can't exist outside an order
  addItem(product: Product, quantity: number): OrderItem {
    if (this.status !== OrderStatus.DRAFT) {
      throw new Error("Cannot modify a finalized order");
    }
    
    // Check if product already in order - business rule enforcement
    const existing = this.items.find(i => i.getProductId() === product.id);
    if (existing) {
      existing.incrementQuantity(quantity);
      return existing;
    }
    
    const item = new OrderItem(this, product, quantity);
    this.items.push(item);
    return item;
  }
  
  // Order controls item removal
  removeItem(item: OrderItem): void {
    if (this.status !== OrderStatus.DRAFT) {
      throw new Error("Cannot modify a finalized order");
    }
    
    const index = this.items.indexOf(item);
    if (index === -1) {
      throw new Error("Item not found in this order");
    }
    
    this.items.splice(index, 1);
  }
  
  // When order is deleted, items go with it (cascade)
  delete(): void {
    this.items.length = 0; // Clear all items
    // ORM/repository handles actual database deletion
  }
}
 
// OrderItem is OWNED - it doesn't control its own lifecycle
class OrderItem {
  private order: Order;
  private productId: string;
  private quantity: number;
  private unitPrice: Money;
  
  // Private constructor - can only be created through Order
  constructor(order: Order, product: Product, quantity: number) {
    this.order = order;
    this.productId = product.id;
    this.quantity = quantity;
    this.unitPrice = product.currentPrice;
  }
  
  // Item can request removal, but Order makes the decision
  requestRemoval(): void {
    this.order.removeItem(this);
  }
}

Ownership Patterns by Relationship Type
Relationship	Owner	Owned	Cascade Behavior
Order → OrderItems	Order	OrderItem	Delete order → delete items
User → Orders	User	Order	Delete user → keep orders (archive) or cascade
Product → Categories	Neither (association)	Neither	Delete product → remove from category only
Company → Departments → Employees	Company → Departments	Departments → Employees	Hierarchical cascade down the chain

The Orphan Problem

Composition vs Aggregation

Two fundamental types of ownership patterns emerge in relationship modeling: Composition and Aggregation. Understanding the difference is crucial for correct lifecycle management.

Composition (strong ownership):

Parts cannot exist independently of the whole
Whole is responsible for part creation and destruction
Parts have no identity outside the whole
Deleting the whole automatically deletes all parts

Aggregation (weak ownership):

Parts can exist independently
Whole references parts but doesn't control their lifecycle
Parts may be shared between multiple wholes
Deleting the whole leaves parts intact

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
// COMPOSITION: Order and OrderItems
// OrderItems cannot exist without an Order
// Deleting Order deletes all its OrderItems
class Order {
  private items: OrderItem[] = [];
  
  // Factory method ensures OrderItem is always created with Order
  addItem(product: Product, qty: number): OrderItem {
    const item = new OrderItem(product, qty); // No standalone creation
    this.items.push(item);
    return item;
  }
  
  // When Order is deleted, items cease to exist
}
 
// AGGREGATION: ShoppingCart and Products
// Products exist independently of any cart
// Multiple carts can reference the same product
// Deleting cart doesn't affect products
class ShoppingCart {
  private items: Map<Product, number> = new Map(); // References, not ownership
  
  addProduct(product: Product, quantity: number): void {
    // Product exists independently - we just reference it
    const current = this.items.get(product) || 0;
    this.items.set(product, current + quantity);
  }
  
  removeProduct(product: Product): void {
    this.items.delete(product); // Product still exists, just no longer in cart
  }
  
  clear(): void {
    this.items.clear(); // Products unaffected
  }
}
 
// MIXED: Team and Members
// Team 'contains' Members (aggregation - members exist independently)
// But Team 'owns' the Membership records (composition)
class Team {
  private memberships: TeamMembership[] = []; // Composition - we own these
  
  addMember(user: User, role: Role): TeamMembership {
    // User exists independently (aggregation)
    // But TeamMembership is created/destroyed with Team (composition)
    const membership = new TeamMembership(this, user, role);
    this.memberships.push(membership);
    return membership;
  }
}
 
class TeamMembership {
  // Join entity - composed by Team, aggregates User
  constructor(
    private team: Team,    // Owner (composition)
    private user: User,    // Reference (aggregation)
    private role: Role
  ) {}
}

How to Choose: Composition vs Aggregation

•Does the part have meaning outside the whole? If a LineItem means nothing without an Invoice, use composition. If a Product exists in the catalog regardless of carts, use aggregation.
•Does the part have an independent identity? If users reference the part directly (by ID), it likely should exist independently. Use aggregation.
•Can the part belong to multiple wholes? An Employee can be in multiple Teams—use aggregation. An OrderItem belongs to exactly one Order—use composition.
•What happens when the whole is deleted? If parts should be deleted too, composition. If parts should remain, aggregation.

Maintaining Relationship Invariants

Common relationship invariants:

A bidirectional relationship must be consistent from both sides
Composition must ensure parts are never orphaned
Uniqueness constraints must be enforced in collections
Business rules must be applied at relationship boundaries

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
// Invariant: Bidirectional consistency
// If Order.items contains an OrderItem, that OrderItem.order must equal this Order
 
class Order {
  private items: OrderItem[] = [];
  
  addItem(item: OrderItem): void {
    if (item.getOrder() !== null && item.getOrder() !== this) {
      throw new Error("Item already belongs to another order");
    }
    
    if (!this.items.includes(item)) {
      this.items.push(item);
      item._setOrder(this); // Maintain bidirectional consistency
    }
  }
  
  removeItem(item: OrderItem): void {
    const index = this.items.indexOf(item);
    if (index > -1) {
      this.items.splice(index, 1);
      item._setOrder(null); // Maintain bidirectional consistency
    }
  }
}
 
class OrderItem {
  private order: Order | null = null;
  
  getOrder(): Order | null {
    return this.order;
  }
  
  // Internal method - should not be called directly by application code
  _setOrder(order: Order | null): void {
    this.order = order;
  }
}
 
// Invariant: Uniqueness constraint
// A user cannot have duplicate roles
 
class User {
  private roles: Set<Role> = new Set(); // Set enforces uniqueness
  
  addRole(role: Role): boolean {
    if (this.roles.has(role)) {
      return false; // Already has role
    }
    this.roles.add(role);
    return true;
  }
  
  hasRole(role: Role): boolean {
    return this.roles.has(role);
  }
}
 
// Invariant: Business rule at relationship boundary
// An order can only have items if total doesn't exceed credit limit
 
class Order {
  private items: OrderItem[] = [];
  private customer: Customer;
  
  addItem(product: Product, quantity: number): OrderItem {
    const itemTotal = product.price.multiply(quantity);
    const newTotal = this.getTotal().add(itemTotal);
    
    if (newTotal.exceeds(this.customer.creditLimit)) {
      throw new CreditLimitExceededError(
        this.customer.creditLimit,
        newTotal
      );
    }
    
    const item = new OrderItem(this, product, quantity);
    this.items.push(item);
    return item;
  }
}

The Consistency Window

Common Pitfalls in Relationship Modeling

Even experienced engineers fall into these relationship modeling traps. Understanding them helps you avoid costly redesigns.

Anti-patterns to Avoid

•Exposing mutable collections — Returning this.items directly allows callers to bypass your encapsulation. Always return immutable views or defensive copies.
•Forgetting bidirectional synchronization — Adding an item to a collection without updating the item's back-reference creates inconsistent state.
•Over-fetching relationships — Loading every related entity eagerly when you only need IDs causes massive performance problems.
•Circular dependencies — A → B → C → A relationship cycles make initialization order impossible and create memory leaks in some languages.
•Relationship logic scattered across codebase — Modifying relationships in multiple places makes invariant checking impossible.
•Treating all relationships as bidirectional — Many relationships only need navigation in one direction. Bidirectionality adds complexity worth avoiding.
•Ignoring transaction boundaries — Relationship changes that span multiple aggregates require careful transaction management.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// ❌ ANTI-PATTERN: Exposing mutable collection
class Order {
  public items: OrderItem[] = []; // Direct access bypasses invariants
}
 
// External code can do this:
order.items.push(new OrderItem(...)); // Bypasses validation!
order.items.length = 0; // Clears order without business logic!
 
// ✅ CORRECT: Encapsulate collection access
class Order {
  private items: OrderItem[] = [];
  
  getItems(): ReadonlyArray<OrderItem> {
    return this.items; // TypeScript prevents mutation
  }
  
  addItem(product: Product, qty: number): OrderItem {
    // All invariants checked here
    this.validateCanModify();
    this.validateCreditLimit(product, qty);
    
    const item = new OrderItem(this, product, qty);
    this.items.push(item);
    return item;
  }
}
 
// ❌ ANTI-PATTERN: Inconsistent bidirectional update
class Team {
  addMember(user: User): void {
    this.members.push(user);
    // Forgot to call user.joinTeam(this)!
    // Now user.getTeams() won't include this team
  }
}
 
// ✅ CORRECT: Atomic bidirectional update
class Team {
  addMember(user: User): void {
    if (!this.members.includes(user)) {
      this.members.push(user);
      user._addTeam(this); // Internal method maintains consistency
    }
  }
}

Summary: Entity Relationships in Code

Entity relationship modeling is the foundation of effective data layer design. The decisions you make here ripple through your entire system—affecting performance, maintainability, and correctness.

Key Takeaways

•Entity relationships define system structure — They determine how data flows, how queries are structured, and how changes propagate.
•The impedance mismatch is real — Object references and foreign keys represent the same concept differently. This gap requires constant bridging.
•Directionality is a key decision — Start unidirectional; add bidirectionality only when navigation truly requires it.
•Ownership defines lifecycle — The owner controls creation, deletion, and cascade behavior. Ambiguous ownership causes bugs.
•Composition vs aggregation matters — Know whether parts can exist independently. This determines your delete strategy.
•Invariants must be protected — Encapsulate collection access and ensure atomic updates to prevent inconsistent states.
•Avoid common pitfalls — Mutable collection exposure, forgotten synchronization, and over-fetching are the primary killers.

What's next:

Foundation Established

1 / 4