Inheritance Hierarchy

An inheritance hierarchy is the complete structure formed by all supertype-subtype relationships in a data model. While we've examined individual inheritance relationships, real-world domains require careful organization of entire type systems—potentially involving dozens of types arranged across multiple levels with various constraints and specialization paths.

The design of an inheritance hierarchy has profound implications for schema maintainability, query performance, and the ability to accurately capture domain semantics. A well-designed hierarchy enables elegant modeling, efficient queries, and smooth schema evolution. A poorly designed hierarchy becomes a maintenance burden, forces awkward workarounds, and obscures rather than clarifies domain semantics.

This page explores the structural aspects of inheritance hierarchies: how to determine appropriate depth and breadth, when trees become lattices, how to combine specialization and generalization effectively, and the design patterns that distinguish well-crafted hierarchies from problematic ones.

An inheritance hierarchy can be characterized by several structural properties that shape its behavior and usability.

Key Structural Dimensions:

Depth: The number of levels from the root supertype to the deepest subtype. Deeper hierarchies have more intermediate types, enabling fine-grained classification but adding complexity.

Breadth: The average number of subtypes per supertype. Broader hierarchies have more sibling types at each level, representing more parallel specialization paths.

Topology: The overall shape—whether a strict tree (single parent per node) or a lattice (multiple parents allowed, enabling multiple inheritance).

Root Structure: Single-rooted (one ultimate supertype) vs. multi-rooted (multiple independent hierarchies that may intersect through multiple inheritance).

Hierarchy Metrics Example:

                    FINANCIAL_PRODUCT (depth=0)
                    /         |          
           LOAN(d=1)     DEPOSIT(d=1)   INVESTMENT(d=1)
           /    \           |    
    MORTGAGE  PERSONAL   SAVINGS  CD    STOCK  BOND  FUND
      (d=2)    (d=2)      (d=2)  (d=2)   (d=2) (d=2) (d=2)

Metrics for this hierarchy:

• Depth: 2 (three levels: 0, 1, 2)
• Breadth at level 0: 1 (root only)
• Breadth at level 1: 3 (LOAN, DEPOSIT, INVESTMENT)
• Breadth at level 2: 7 (all leaf types)
• Fanout: Maximum 3 (INVESTMENT→3 children)
• Balance: Reasonably balanced (all leaves at depth 2)
• Topology: Tree (no multiple inheritance shown)

This is a well-structured hierarchy: moderate depth enables clear classification without excessive complexity, and balanced breadth makes the hierarchy easy to understand.

Inheritance hierarchies can have two fundamental topologies: trees and lattices. The choice between them significantly impacts modeling expressiveness, implementation complexity, and query behavior.

Tree Topology (Single Inheritance):

• Each type has at most one direct supertype
• Forms a strict tree structure
• Every type has exactly one inheritance path to the root
• No multiple inheritance

           ROOT
          / | 
         A  B  C
        /|  |  |
       D E  F  G H

Lattice Topology (Multiple Inheritance Possible):

• Types can have multiple direct supertypes
• Forms a lattice (directed acyclic graph)
• Some types have multiple inheritance paths
• Enables modeling of entities that belong to multiple classifications

           ROOT
          / | 
         A  B  C
          \|/  |
           D   E
            \ /
             F

When to Use Tree Hierarchies:

• The domain has clear, single-dimension classification
• Each entity naturally falls into one category path
• Implementation simplicity is prioritized
• Tools and ORM frameworks require tree structure
• Team familiarity with multiple inheritance is low

When to Use Lattice Hierarchies:

• The domain has multiple orthogonal classification dimensions
• Entities genuinely belong to multiple categories simultaneously
• The alternative is significant attribute/relationship duplication
• Query patterns benefit from multiple inheritance paths
• The team has expertise managing multiple inheritance complexity

Domain: Academic Course Catalog

Classification Dimensions:
1. By Department: CS, Math, Physics, Chemistry, ...
2. By Level: Undergraduate, Graduate, Doctoral
3. By Delivery: In-Person, Online, Hybrid
4. By Duration: Full-Semester, Half-Semester, Intensive

Question: Can we use a tree, or do we need a lattice?

Analysis:

Option A: Force Tree Structure
COURSE
└── CS_COURSE
    └── CS_UNDERGRADUATE
        └── CS_UNDERGRAD_INPERSON
            └── CS_UNDERGRAD_INPERSON_FULLSEM
            
Problem: 4 dimensions × multiple values each = 
         potentially hundreds of leaf types!
         Adding a dimension multiplies the types.

Option B: Lattice with Multiple Inheritance
COURSE (root)
├── CS_COURSE, MATH_COURSE, ... (by dept)
├── UNDERGRAD_COURSE, GRAD_COURSE, ... (by level)
├── INPERSON_COURSE, ONLINE_COURSE, ... (by delivery)
└── FULLSEM_COURSE, HALFSEM_COURSE, ... (by duration)

A specific course inherits from each dimension:
CS_101: inherits CS_COURSE + UNDERGRAD_COURSE + 
        INPERSON_COURSE + FULLSEM_COURSE

Verdict: LATTICE is clearly better for this domain.
Multiple orthogonal classification dimensions = lattice.

The depth of an inheritance hierarchy—the number of levels from root to deepest leaf—has significant implications for modeling precision, implementation complexity, and query performance.

Shallow Hierarchies (1-2 levels):

Advantages:

• Simple to understand and implement
• Few joins needed for full entity retrieval
• Easier to query at any level
• Less risk of mid-hierarchy changes affecting many types

Disadvantages:

• May lack precision for complex domains
• Common attributes among subtypes can't be factored into intermediate types
• May require more attributes at the root level (cluttering the supertype)
• Classification appears 'flat' even when domain has natural layers

Deep Hierarchies (4+ levels):

Advantages:

• Very precise classification
• Maximum opportunity to factor common attributes/relationships to shared ancestors
• Can model subtle distinctions between closely related types

Disadvantages:

• Complex to understand holistically
• Many joins for polymorphic queries
• Changes to mid-level types cascade to many descendants
• Risk of 'over-classification'—types that add little value

The 'Meaningful Addition' Test:

For each level in your hierarchy, ask: "Does this level add meaningful semantic distinction?"

Good intermediate level:

VEHICLE → MOTOR_VEHICLE → CAR → SEDAN

Each level adds real distinction: has motor, is for personal transport, is enclosed passenger car.

Questionable intermediate level:

PRODUCT → SELLABLE_PRODUCT → INVENTORIED_PRODUCT → SHIPPABLE_PRODUCT → BOOK

If all products are sellable, inventoried, and shippable, these intermediate levels add no distinction.

The breadth of a hierarchy level—the number of sibling subtypes under a single supertype—affects both comprehensibility and the physical schema structure.

Narrow Branching (2-4 subtypes per supertype):

Advantages:

• Easy to enumerate and understand all subtypes
• Binary or trinary classifications are natural to reason about
• Type discriminator columns have few distinct values
• UI dropdowns and forms are manageable

Disadvantages:

• May require more depth to capture the same domain richness
• Can result in artificial intermediate types
• Some domains genuinely have many peer categories

Original: ACCOUNT with 15 direct subtypes

ACCOUNT
├── Checking
├── Savings
├── MoneyMarket
├── CertificateOfDeposit
├── IndividualRetirement
├── RothIRA
├── 401k
├── 529Plan
├── PersonalLoan
├── AutoLoan
├── Mortgage
├── HELOC
├── CreditCard
├── StockBrokerage
└── MutualFund

Problem: 15 siblings is too many to comprehend at once

Restructured: Intermediate types reduce breadth

ACCOUNT
├── DEPOSIT_ACCOUNT
│   ├── Checking
│   ├── Savings
│   ├── MoneyMarket
│   └── CertificateOfDeposit
├── RETIREMENT_ACCOUNT
│   ├── IndividualRetirement
│   ├── RothIRA
│   ├── 401k
│   └── 529Plan
├── LOAN_ACCOUNT
│   ├── PersonalLoan
│   ├── AutoLoan
│   ├── Mortgage
│   └── HELOC
├── CREDIT_ACCOUNT
│   └── CreditCard
└── INVESTMENT_ACCOUNT
    ├── StockBrokerage
    └── MutualFund

Result: 
- Root level: 5 subtypes (manageable)
- Each intermediate: 2-4 subtypes (comfortable)
- Total types: 20 (5 new intermediates) but clearer
- Added semantic structure: deposit vs loan vs investment

Wide Branching (7+ subtypes per supertype):

Advantages:

• Keeps hierarchy shallow (fewer levels)
• All subtypes are visible together (no hunting through sub-levels)
• Direct mapping to physical discriminator column

Disadvantages:

• Harder to comprehend all options at once
• May hide potential intermediate classifications
• Suggests the supertype might be too broad/abstract

Symptoms of Excessive Breadth:

1. Grouping Hints: Subtypes' names suggest natural groups (all 'X_Loan' types together)
2. Shared Local Attributes: Multiple siblings share attributes not in the supertype
3. Shared Relationships: Multiple siblings have identical relationship patterns
4. Constraint Patterns: Siblings share constraints that differ from other siblings

When you see these symptoms, consider introducing intermediate types to:

• Group related siblings under shared ancestors
• Factor common attributes and relationships up to the intermediate
• Make the natural domain structure explicit

Inheritance hierarchies can be constructed through two complementary processes: specialization (top-down) and generalization (bottom-up). Understanding which process drives hierarchy formation helps explain its structure and guides evolution.

Specialization-Driven Hierarchies:

Build from general to specific. Start with a broad concept and identify specialized variants.

Process:

1. Identify the general supertype (e.g., EMPLOYEE)
2. Identify distinguishing specialized categories (Manager, Engineer, Analyst)
3. Add subtype-specific attributes and relationships
4. Further specialize if needed (Engineer → SoftwareEngineer, HardwareEngineer)

Characteristics:

• Clear 'is-a' relationships flowing downward
• Subtypes add detail to a well-understood supertype
• Often driven by business categorization needs
• Discriminator concepts are usually explicit in domain language

Generalization-Driven Hierarchies:

Build from specific to general. Start with concrete types and identify shared abstractions.

Process:

1. Model concrete entities independently (Checking, Savings, MoneyMarket)
2. Observe common attributes (AccountNumber, Balance, OpenDate)
3. Observe common relationships (OwnedBy Customer)
4. Create supertype (DepositeAccount) to hold shared elements
5. Factor common elements up to supertype

Characteristics:

• Supertypes emerge from discovered commonalities
• Often used when evolving existing schemas
• Reveals latent domain structure
• May uncover unexpected abstractions

Mixed Hierarchies (Common in Practice):

Real hierarchies often combine both processes:

Specialization: ACCOUNT → LOAN_ACCOUNT → specific loans
Generalization: After adding AutoLoan, MortgageLoan, discovered SECURED_LOAN abstraction

          ACCOUNT
             |
       LOAN_ACCOUNT
             |
      SECURED_LOAN (generalized from below)
         /    
   AutoLoan   MortgageLoan (specialized from above)

As domains evolve, inheritance hierarchies must evolve with them. Hierarchy refactoring involves restructuring the type system without losing data or breaking applications. This is one of the most challenging aspects of schema management.

Common Refactoring Operations:

1. Extract Supertype (Generalization)

Create a new intermediate supertype from common elements of existing siblings.

Before:

VEHICLE
├── Car (has EngineType, FuelCapacity)
└── Truck (has EngineType, FuelCapacity)
└── Bicycle (no engine)

After:

VEHICLE
├── MOTORIZED_VEHICLE (has EngineType, FuelCapacity)
│   ├── Car
│   └── Truck
└── HUMAN_POWERED_VEHICLE
    └── Bicycle

2. Add Subtype

The most common refactoring—adding a new specialized type.

Key Considerations:

• Which supertype is the new type's parent?
• What local attributes does it add?
• Does it steal entities from existing siblings? (May require data migration)
• Do existing queries need to handle the new type?

Migration Pattern:

-- 1. Add new subtype table
CREATE TABLE NewSubtype (...);

-- 2. Update type discriminator column if using single table
ALTER TABLE Supertype MODIFY TypeDiscriminator 
    CHECK (TypeDiscriminator IN (..., 'NewSubtype'));

-- 3. Migrate data if splitting from existing subtype
INSERT INTO NewSubtype (SELECT ... FROM OldSubtype WHERE condition);
DELETE FROM OldSubtype WHERE condition;

-- 4. Update application code to handle new type

3. Remove Subtype

Deleting a type from the hierarchy. Less common but necessary when domain simplifies.

Key Considerations:

• What happens to existing instances?
  • Migrate to sibling subtype?
  • Migrate to supertype (lose specialization)?
  • Delete entirely?
• Foreign key references to the subtype?
• Application code referencing the subtype?

Professional database architects follow established best practices when designing inheritance hierarchies. These guidelines, derived from decades of collective experience, help avoid common pitfalls and produce maintainable schemas.

Principle 1: Model the Domain, Not the Implementation

Design the hierarchy to accurately capture domain semantics, not to optimize for a particular physical mapping strategy. Physical optimization can come later; semantic accuracy is harder to retrofit.

Principle 2: Balance Precision and Complexity

More precise classification is always possible—you could create arbitrary fine-grained distinctions. But every type has a cost: schema complexity, query joins, code paths, and maintenance burden. Balance precision against cost:

Good: EMPLOYEE → FULL_TIME, PART_TIME, CONTRACTOR (clear, meaningful distinction)

Excessive: EMPLOYEE → FULL_TIME_WEEKDAY_MORNING_REGULAR_OFFICE_BENEFITED_... (too fine)

Principle 3: Design for Polymorphic Access Patterns

Ask: "What queries will run against this hierarchy?" Common patterns include:

1. Polymorphic reads: Query all subtypes through supertype (common)
2. Type-specific reads: Query one specific subtype (common)
3. Mixed writes: Insert different subtypes through same code path (occasional)
4. Type discovery: Determine specific subtype of a general reference (occasional)

Design your hierarchy so the most common query patterns are efficient.

Principle 4: Stable Core, Flexible Periphery

Keep the core hierarchy structure (root, major intermediate types) stable. Design for evolution at the leaf level where changes have less impact:

  [STABLE CORE]                    [FLEXIBLE EDGE]
                              
FINANCIAL_PRODUCT ─────────────── (new products added here)
├── DEPOSIT_ACCOUNT ──────────── (new deposit types here)
├── LOAN_ACCOUNT ─────────────── (new loan types here)
└── INVESTMENT_ACCOUNT ───────── (new investment types here)