Relationship Inheritance

While attribute inheritance receives the most attention in EER discussions, relationship inheritance is equally fundamental and often more impactful in practice. When a supertype participates in a relationship, that relationship automatically applies to all its subtypes—a powerful mechanism that profoundly affects how we model associations, enforce constraints, and query connected data.

Consider the implications: if 'Employee' has a 'WORKS_IN' relationship with 'Department', then every Manager, Engineer, Contractor, and any other Employee subtype automatically participates in that relationship. You don't define the relationship again for each subtype—it flows through the hierarchy just as attributes do.

This page explores the complete mechanics of relationship inheritance, from basic propagation rules to complex scenarios involving cardinality constraints, participation constraints, and relationship attributes. Understanding these concepts is essential for any database professional designing semantically rich hierarchical schemas.

Relationship inheritance is the mechanism by which a subtype automatically participates in all relationships defined for its supertype (and ancestor supertypes). This follows directly from the IS-A semantic: if 'Manager IS-A Employee' and 'Employee WORKS_IN Department', then 'Manager WORKS_IN Department'.

The Formal Definition:

Let S be a supertype with relationship set R_S = {r₁, r₂, ..., rₙ} representing all relationships in which S participates. Let T be a subtype of S with its own local relationship set R_T = {t₁, t₂, ..., tₘ}. Then:

• Every instance of T can participate in all relationships in R_S (inherited relationships)
• Every instance of T can also participate in relationships in R_T (local relationships)
• The complete relationship participation set of T is R_S ∪ R_T

Crucially, inherited relationships are not copies—they are the same relationships. When you query the WORKS_IN relationship, you find employee-department pairs regardless of whether the employee is a Manager, Engineer, or any other subtype.

The Participation Principle:

When a supertype participates in a relationship, every subtype instance IS a supertype instance, and therefore CAN participate in that relationship. The inheritance is about capability and constraint, not about mandatory participation (which is governed separately by participation constraints).

Example: Banking System

ACCOUNT (supertype)
  ├── CheckingAccount (subtype)
  ├── SavingsAccount (subtype)
  └── InvestmentAccount (subtype)

Relationship: ACCOUNT ---OWNED_BY---> CUSTOMER

The OWNED_BY relationship is defined at the ACCOUNT level. Automatically:

• Every CheckingAccount can be owned by a Customer
• Every SavingsAccount can be owned by a Customer
• Every InvestmentAccount can be owned by a Customer

You don't create separate CHECKING_OWNED_BY, SAVINGS_OWNED_BY relationships. The single OWNED_BY relationship serves all account types through inheritance.

When relationships are inherited, their cardinality constraints propagate as well. This propagation follows specific rules that maintain semantic consistency while allowing appropriate flexibility.

Basic Cardinality Propagation:

If a supertype relationship has cardinality C₁:C₂, subtypes inherit this same constraint. The cardinality applies to subtype instances when they participate in the relationship.

Example:

EMPLOYEE ---MANAGES(0..1)---> PROJECT
           (one employee manages at most one project)

Subtypes (Manager, Engineer, Analyst) all inherit this constraint:

• A Manager can manage at most one project
• An Engineer can manage at most one project
• An Analyst can manage at most one project

The constraint is unified—it's not per-subtype but across the entire hierarchy.

The Tightening Principle:

Just as with attribute constraints, relationship cardinality constraints can be tightened (made more restrictive) in subtypes but never loosened. This ensures that any assumption valid for the supertype remains valid for all subtypes.

Valid Tightening Examples:

Supertype: EMPLOYEE ---ASSIGNED_TO(0..*)---> PROJECT
           (employees can be assigned to any number of projects)

Subtype: INTERN ---ASSIGNED_TO(0..1)---> PROJECT
         (interns can only be assigned to at most one project)

This is valid because 0..1 is a subset of 0..*. Any intern satisfies the supertype constraint while meeting the stricter subtype constraint.

Invalid Loosening (Prohibited):

Supertype: EMPLOYEE ---ASSIGNED_TO(1..3)---> PROJECT
           (employees must be assigned to 1-3 projects)

Subtype: MANAGER ---ASSIGNED_TO(0..10)---> PROJECT
         (INVALID: managers could have zero, exceeding max)

This violates the inheritance contract. Code expecting at least one project assignment for any Employee would break for Managers with zero projects.

Participation constraints (total vs. partial participation) also propagate through inheritance hierarchies, with nuanced behavior that reflects the semantic differences between these constraint types.

Total Participation Inheritance:

If a supertype has TOTAL participation in a relationship, all subtype instances MUST participate in that relationship. This is the stronger constraint and propagates absolutely.

EMPLOYEE ===WORKS_IN===> DEPARTMENT
(double line = total participation: every employee must work in a department)

For all subtypes (Manager, Engineer, Contractor):

• Every Manager must work in some department
• Every Engineer must work in some department
• Every Contractor must work in some department

There are no exceptions—the total participation is inherited fully.

Partial Participation and Subtype Strengthening:

If a supertype has PARTIAL participation, subtypes inherit the ability to participate but not the requirement. However, subtypes CAN strengthen this to total participation:

EMPLOYEE ---PARTICIPATES_IN---> TRAINING_PROGRAM
(single line = partial: not all employees are required to participate)

  └── NEW_HIRE ===PARTICIPATES_IN===> TRAINING_PROGRAM
      (strengthened to total: all new hires MUST participate)

This is valid because requiring participation is stricter than allowing it. Any NEW_HIRE that participates satisfies the EMPLOYEE constraint (which merely allows participation), and the NEW_HIRE-specific constraint ensures they all do participate.

Invalid Weakening:

EMPLOYEE ===REPORTS_TO===> MANAGER
(total: every employee must have a manager)

  └── EXECUTIVE ---REPORTS_TO---> MANAGER
      (INVALID: cannot weaken to partial)

If all Employees must report to someone, Executives (being Employees) cannot be exempted. To model executives who don't report to anyone, you'd need to restructure the hierarchy.

While subtypes inherit all supertype relationships, they can also have their own local relationships that don't exist at the supertype level. This is the relationship equivalent of local attributes—associations that only make sense for a specific subtype.

When to Use Subtype-Specific Relationships:

1. Domain Specificity: The relationship only applies to the subtype's domain
2. Different Cardinality Needs: The relationship requires cardinality not applicable to other subtypes
3. Different Participating Entities: The related entity only interacts with this subtype
4. Distinct Semantic Meaning: The relationship means something different for this subtype

Relationship Placement Guidelines:

Placing relationships at the correct hierarchy level follows similar principles to attribute placement:

Place at Supertype Level When:

• The relationship applies to ALL subtypes without exception
• The same cardinality constraints work for all subtypes
• Queries commonly need to traverse the relationship for any subtype
• The relationship represents a fundamental aspect of 'being' that type

Place at Subtype Level When:

• The relationship only makes sense for specific subtypes
• Different subtypes would need different cardinality constraints
• The related entity is subtype-specific
• The relationship represents specialized behavior, not core identity

The Litmus Test:

"Can every instance of the supertype meaningfully participate in this relationship?"

If yes → define at supertype If no → define at the appropriate subtype(s)

Relationships often carry their own attributes—descriptive properties of the association itself, not of either participating entity. When relationships are inherited, these relationship attributes also propagate, with specific semantic implications.

Relationship Attribute Inheritance:

If a supertype relationship R has attributes {a, b, c}, subtype instances participating in R also have access to these attributes. The attributes describe the relationship instance, and since the relationship is inherited, so are its descriptive properties.

Example:

EMPLOYEE ---WORKS_IN---> DEPARTMENT
           ├── StartDate (when employment in department began)
           ├── EndDate (when employment ended, if applicable)
           └── Role (the employee's role in that department)

All Employee subtypes inherit WORKS_IN with all three attributes:

• A Manager works in a department with StartDate, EndDate, Role
• An Engineer works in a department with StartDate, EndDate, Role
• The relationship attributes are identical regardless of subtype

Subtype-Specific Relationship Attributes:

When a subtype defines its own local relationship, it can specify relationship attributes that are unique to that association.

Example:

MANAGER ---SUPERVISES---> EMPLOYEE
           ├── Since (when supervision began)
           ├── EvaluationSchedule (performance review frequency)
           └── MentoringFocus (specific area of mentorship)

SALES_REP ---MANAGES---> CLIENT_ACCOUNT  
           ├── AssignmentDate
           ├── QuotaOverride (special quota for this account)
           └── AccountTier (bronze, silver, gold)

These relationship attributes are entirely independent—MANAGES.QuotaOverride has no equivalent in SUPERVISES, and vice versa. Each relationship defines exactly the attributes that describe instances of that specific association.

Complex Scenario: Same Entity, Different Relationships:

Sometimes different subtypes relate to the same entity through different relationships with different attributes:

ENGINEER ---CONTRIBUTES_TO---> PROJECT
           ├── JoinDate
           ├── CodeLinesWritten
           └── TechnicalRole (Backend, Frontend, etc.)

MANAGER ---OVERSEES---> PROJECT
           ├── AssignmentDate
           ├── BudgetResponsibility
           └── StakeholderContact

An Engineer contributes code; a Manager oversees resources. Same PROJECT entity, but fundamentally different relationships with different semantics and different attributes.

One of the most powerful consequences of relationship inheritance is polymorphic querying—the ability to traverse relationships at the supertype level while seamlessly including all subtype instances. This capability is essential for building flexible, maintainable applications.

The Power of Polymorphic Queries:

When you query an inherited relationship through the supertype, you automatically get results that include all subtype instances, without explicitly naming or knowing about those subtypes.

Query Pattern Implications:

1. Supertype Queries Are Inclusive: Querying through Employee includes all subtypes
2. Subtype Queries Are Exclusive: Querying through Engineer gets only engineers
3. Relationship Attributes Available Either Way: StartDate, Role are accessible regardless of query level
4. Local Attributes Require Subtype Query: Engineer.ProgrammingLanguage requires querying Engineer, not Employee

The Join Semantics:

When joining through an inherited relationship:

• FROM Employee e JOIN Department d includes all subtypes
• The join condition (typically foreign key) is resolved at the supertype level
• Subtype-specific columns aren't available without explicit subtype access

Performance Considerations:

Polymorphic queries may require the database to:

• Scan multiple physical tables (if using table-per-type inheritance mapping)
• Apply union operations internally
• Use polymorphic identity columns to filter

The specific performance profile depends on the physical mapping strategy (covered in a later page).

Real-world domains often present complex relationship inheritance scenarios that require careful analysis. Let's examine several common patterns and their solutions.

Scenario 1: Relationship Specialization

Sometimes a subtype needs a specialized version of a supertype relationship—same related entity, but different constraints or semantics.

Problem:

EMPLOYEE ---USES---> EQUIPMENT (partial, any equipment)

FIELD_ENGINEER needs: USES specific safety equipment (total, certified equipment only)

Solution Approaches:

Approach A: Strengthened Inherited Relationship

• FIELD_ENGINEER strengthens USES to total participation
• Add constraints on which EQUIPMENT records FIELD_ENGINEER can reference
• Maintains single relationship with subtype-specific constraints

Approach B: Separate Subtype Relationship

• FIELD_ENGINEER ---USES_CERTIFIED---> CERTIFIED_EQUIPMENT (new subtype of EQUIPMENT)
• More explicit modeling but increases schema complexity
• FIELD_ENGINEER still inherits generic USES from EMPLOYEE

Scenario 2: Role-Based Relationship Participation

An entity may participate in different relationships depending on which subtype role it inhabits.

Setup:

PERSON
 ├── STUDENT
 └── FACULTY

COURSE ---TAKEN_BY---> STUDENT
COURSE ---TAUGHT_BY---> FACULTY

Challenge: A person who is both a STUDENT and FACULTY (e.g., PhD student who also teaches) participates in BOTH relationships.

Analysis:

• When viewed as STUDENT: can take courses
• When viewed as FACULTY: can teach courses
• Same PERSON instance, different relationship participation through different subtype identities
• This is valid and expected in overlapping subtype scenarios

Query Implications:

-- Find all courses a person is involved with (either taking or teaching)
SELECT c.CourseId, c.Name, 'Taking' as Role
FROM Course c JOIN Student s ON c.CourseId = s.TakenCourseId
WHERE s.PersonId = @personId
UNION
SELECT c.CourseId, c.Name, 'Teaching' as Role  
FROM Course c JOIN Faculty f ON c.CourseId = f.TaughtCourseId
WHERE f.PersonId = @personId;