Database Management SystemCategories (Union Types)

Categories and Union Types in EER Modeling

LevelAdvanced

Duration60 mins

TopicCategories (Union Types)

1 / 5

Category Definition

When One Superclass Isn't Enough

Throughout our study of Enhanced Entity-Relationship modeling, we've explored powerful abstraction mechanisms—specialization for breaking a superclass into subtypes, and generalization for combining common features into a parent entity. These constructs handle scenarios where entities share a single, unified hierarchical path.

But what happens when an entity needs to draw its identity from one of several unrelated entity types? Consider these real-world scenarios:

A bank account can be owned by a Person OR a Company—two fundamentally different entity types
A property can be owned by an Individual, a Corporation, OR a Government Agency
A vehicle can be registered to a Citizen OR an Organization

These situations require a modeling construct that traditional specialization/generalization cannot elegantly express. Enter the Category, also known as a Union Type—one of the most sophisticated and frequently misunderstood constructs in EER modeling.

What You Will Learn

By the end of this page, you will understand what categories are, why they exist as a distinct modeling construct, how they differ fundamentally from specialization/generalization, and when to apply them in real-world database design scenarios.

The Category Concept

A category (or union type) is a subclass that represents the collection of objects that are the union of the defining superclasses. Unlike specialization where subtypes share a common supertype, a category has multiple superclasses from different entity types, and each instance of the category is a member of exactly one of those superclasses.

Formal Definition:

A category C is a subset of the union of n defining superclasses {S₁, S₂, ..., Sₙ} such that:

C ⊆ (S₁ ∪ S₂ ∪ ... ∪ Sₙ)

Crucially, for any instance c in C:

c ∈ Sᵢ for exactly one i where 1 ≤ i ≤ n

This means each entity in the category comes from one and only one of the superclasses, never multiple simultaneously.

The Union Type Terminology

The term 'union type' comes from set theory—a category represents the union of multiple entity sets. In programming language terms, it's analogous to a discriminated union or tagged union, where a value can be one of several distinct types, but you must always know which type it currently is.

The Critical Distinction:

In shared superclass (specialization/generalization):

All subtypes inherit from the same superclass
The superclass exists as a unified entity type
Every instance of a subtype IS an instance of the superclass

In category (union type):

The category has multiple different superclasses
These superclasses are typically unrelated entity types
Each category instance inherits from exactly one superclass
The category itself is a collector of related but distinct entities

Converting Mermaid diagram...

Why Categories Are Necessary

To understand why categories exist, consider a scenario that cannot be adequately modeled using only specialization and generalization.

The Vehicle Registration Problem:

A Department of Motor Vehicles (DMV) system must track vehicle registrations. Vehicles can be registered to:

Individual persons (with attributes: SSN, name, address, driver's license number)
Companies (with attributes: company ID, name, address, registration number)
Government agencies (with attributes: agency ID, name, jurisdiction, contact person)

The key observations:

PERSON, COMPANY, and GOVERNMENT_AGENCY are fundamentally different entity types
They share almost no common attributes (name and address are superficial similarities)
A vehicle is registered to exactly one of these, never multiple
The REGISTRATION relationship needs a unified reference to the owner

The Generalization Trap

A common mistake is attempting to model this as generalization—creating an artificial 'REGISTRANT' superclass from which PERSON, COMPANY, and GOVERNMENT_AGENCY inherit. This is semantically incorrect because these entity types exist independently with their own identities and relationships. A PERSON doesn't 'become' a registrant; they simply happen to register a vehicle.

Why Alternative Approaches Fail:

Approach 1: Multiple Relationships

VEHICLE --owned_by_person--> PERSON
VEHICLE --owned_by_company--> COMPANY  
VEHICLE --owned_by_govt--> GOVERNMENT_AGENCY

Problems:

Requires complex constraint: exactly one must be non-null
Queries become complex with UNION/COALESCE logic
Adding new owner types multiplies relationships
No unified way to reference 'the owner'

Approach 2: Artificial Generalization

OWNER (artificial superclass)
  ├── PERSON
  ├── COMPANY
  └── GOVERNMENT_AGENCY

Problems:

Semantically incorrect—these aren't subtypes of a common concept
Forces unrelated entities into false hierarchy
PERSON has independent existence beyond being an 'owner'
Pollutes entity type semantics

Approach 3: Generic Entity

OWNER (entity_type, entity_id, name, address, ...)

Problems:

Loses type-specific attributes and constraints
No referential integrity to source entities
Violates normalization principles
Denormalized attribute handling nightmare

Modeling Approaches Comparison
Approach	Semantic Correctness	Query Simplicity	Extensibility	Referential Integrity
Multiple Relationships	✓ Correct	✗ Complex	✗ Poor	✓ Strong
Artificial Generalization	✗ Incorrect	✓ Simple	✓ Good	✓ Strong
Generic Entity	✗ Incorrect	~ Medium	✓ Good	✗ Weak
Category (Union Type)	✓ Correct	✓ Simple	✓ Good	✓ Strong

Category Characteristics

Categories exhibit several distinctive characteristics that set them apart from other EER constructs. Understanding these characteristics is essential for correct category design and implementation.

Defining Characteristics of Categories

•Multiple Heterogeneous Superclasses — Unlike shared subclass where one subtype inherits from multiple related supertypes (shared superclass), a category collects from fundamentally different, unrelated entity types.
•Mutual Exclusivity of Membership — Each category instance belongs to exactly one defining superclass. An OWNER is either a PERSON or a COMPANY or a GOVERNMENT_AGENCY—never a combination.
•Selective Inheritance — Since an instance inherits from only one superclass, it inherits only that superclass's attributes and relationships, not all superclass attributes.
•Subtype of the Union — The category is a subtype of the union of its superclasses. This means not all superclass instances need to participate in the category.
•Surrogate Key Typically Required — Because different superclasses have different key attributes, categories often require their own surrogate identifier.

Category vs. Multiple Inheritance

In object-oriented programming, multiple inheritance allows an object to inherit from multiple parent classes simultaneously. Categories are fundamentally different—a category instance inherits from exactly one superclass at any time. The 'multiple' aspect refers to the category having multiple possible superclasses, not an instance inheriting from multiple simultaneously.

The Superclass-Subclass Direction:

In specialization/generalization, the inheritance direction is:

Superclass → Subclass (top-down or bottom-up)

In categories, the direction is inverted conceptually:

Multiple Superclasses → Category (union collectsion)

This reversal is why categories are sometimes called inverted generalization. Instead of abstraction going upward from specific to general, categories collect from multiple general types into a unified specific role.

Converting Mermaid diagram...

Category Notation in EER Diagrams

EER diagrams use a specific notation to represent categories that distinguishes them from specialization/generalization hierarchies. Understanding this notation is crucial for reading and creating EER diagrams correctly.

Category Notation Elements
Element	Symbol	Description
Category symbol	Circle with 'U' (∪)	Represents the union operation that defines the category
Superclass connections	Lines to circle	Each defining superclass connects to the union symbol
Category entity	Rectangle below ∪	The category (subclass) entity that results from the union
Total constraint	Double line to category	All superclass instances must participate in category
Partial constraint	Single line to category	Not all superclass instances must participate

Standard EER Category Diagram Structure:

    [PERSON]          [COMPANY]        [GOVERNMENT_AGENCY]
        \                 |                   /
         \                |                  /
          \               |                 /
           \              |                /
            \             |               /
             ============(∪)=============    ← Union symbol
                          |
                          | (single or double line)
                          |
                     [OWNER]           ← Category entity
                          |
                          |
                     <OWNS>            ← Can participate in relationships
                          |
                     [VEHICLE]

The key distinguishing features:

Union symbol (∪) instead of specialization circle (○ or ●)
Arrows point toward the category from superclasses (reverse of specialization)
Category entity appears below the union symbol
Category can have its own attributes and relationships

Reading the Diagram Direction

In specialization, read top-to-bottom: 'VEHICLE can be specialized into CAR, TRUCK, or MOTORCYCLE.' In categories, read bottom-to-top collection: 'OWNER is the union of entities from PERSON, COMPANY, or GOVERNMENT_AGENCY.' The visual flow represents the semantic difference.

Notation Variations Across Standards:

Different textbooks and CASE tools may use variations:

Standard/Tool	Category Symbol	Superclass Connection
Elmasri & Navathe	∪ in circle	Lines to circle
Chen (Extended)	U-shaped arc	Arc connects superclasses
UML	{union} stereotype	Dashed lines to subclass
ERwin	Category entity type	CAT relationship
Oracle Designer	Subtype cluster	Arc with 'U' label

Regardless of notation, the semantics remain consistent: a category collects instances from multiple unrelated superclasses into a unified entity type.

Real-World Category Examples

Categories appear naturally in many real-world database scenarios. Examining concrete examples helps solidify understanding of when and why to use this construct.

Account Holder Category

In a banking system, accounts can be held by different types of legal entities:

Superclasses:

INDIVIDUAL: SSN, first_name, last_name, date_of_birth, address
CORPORATION: tax_id, corporate_name, incorporation_date, state
TRUST: trust_id, trust_name, creation_date, trustee_name
ESTATE: estate_id, deceased_name, executor_name, court_case_number

Category: ACCOUNT_HOLDER

holder_id (surrogate key)
holder_since
credit_score
risk_classification

Why Category?

These are fundamentally different legal entities
They have completely different identification systems (SSN vs Tax ID vs Trust ID)
Each has unique regulatory requirements
An account has exactly ONE holder type (not a person AND a trust)

Converting Mermaid diagram...

Category vs. Specialization: Making the Right Choice

One of the most common modeling errors is choosing between category and specialization incorrectly. This decision fundamentally affects your schema's semantic accuracy and implementation complexity.

The Key Question:

Ask yourself: Do the entity types have independent existence with fundamentally different identities, or are they variations of a single conceptual entity?

Use Specialization When

•Subtypes are variations of the same concept
•There is a clear IS-A relationship (Employee IS-A Person)
•Subtypes share a meaningful common supertype
•Supertype has substantial shared attributes
•Instances can potentially belong to multiple subtypes (overlapping)
•You're refining a general concept into specific types

Use Category When

•Entity types are fundamentally different concepts
•There is a ROLE relationship (Person plays role of Owner)
•Superclasses would be artificial if created
•Superclasses share few meaningful attributes
•Instances belong to exactly one superclass (always disjoint)
•You're collecting unrelated entities for a common purpose

The 'Artificial Superclass' Test

If creating a superclass feels forced or artificial—if you can't give it a natural, meaningful name—you probably need a category instead. 'REGISTRANT' as a superclass for PERSON, COMPANY, and GOVERNMENT_AGENCY feels artificial. But 'EMPLOYEE' as a superclass for MANAGER, ENGINEER, and ANALYST feels natural—that's proper specialization.

Quick Reference: Specialization vs. Category
Scenario	Recommended Construct	Reasoning
Student, Faculty, Staff as people	Specialization of PERSON	All are variations of human individuals with shared Person attributes
Person, Company as account holders	Category → ACCOUNT_HOLDER	Fundamentally different legal entity types playing same role
Checking, Savings, Investment accounts	Specialization of ACCOUNT	All are variations of financial accounts with shared Account attributes
Vehicle, Building, Artwork as insured items	Category → INSURED_ITEM	Unrelated asset types being insured for same purpose
Hourly, Salaried, Commission employees	Specialization of EMPLOYEE	All are variations of employment compensation structure
Person, Organization as event sponsors	Category → SPONSOR	Fundamentally different entity types sponsoring events

Common Misconceptions About Categories

Categories are frequently misunderstood, leading to incorrect models and implementation errors. Let's address the most common misconceptions.

Misconceptions to Avoid

•Misconception: Categories are just generalization in reverse — While visually similar in reverse, the semantics are fundamentally different. Generalization creates shared abstraction; categories create unified collection without shared abstraction.
•Misconception: An instance can belong to multiple superclasses — Never. Category membership is always mutually exclusive. An OWNER is exactly ONE of: PERSON, COMPANY, or GOVERNMENT—never multiple.
•Misconception: All superclass instances must be in the category — Not necessarily. A PERSON can exist without being an OWNER in the banking system. Total vs. partial participation rules apply.
•Misconception: Categories inherit all attributes from all superclasses — An instance inherits only from its ONE superclass. An OWNER that is a PERSON has person attributes; an OWNER that is a COMPANY has company attributes.
•Misconception: Categories can be replaced by multiple foreign keys — While technically possible, this loses referential integrity, complicates queries, and makes constraint enforcement difficult.

The Inheritance Asymmetry

A crucial insight: In specialization, a STUDENT inherits ALL Person attributes because every Student IS a Person. In a category, an OWNER that happens to be a PERSON inherits Person attributes, but an OWNER that is a COMPANY inherits Company attributes instead—never both. This selective inheritance is a defining characteristic.

Correct Mental Model:

Think of a category as a role-playing mechanism. Different entity types can play the same role (owner, sponsor, borrower) without losing their distinct identities. The category captures the role, and which entity type fills that role varies per instance.

[PERSON: John Smith] ──plays role of──> [OWNER for Account A]
[COMPANY: Acme Corp] ──plays role of──> [OWNER for Account B]
[TRUST: Smith Family Trust] ──plays role of──> [OWNER for Account C]

Each OWNER is a distinct instance, referencing exactly one superclass instance that fills the owner role for a specific context.

Summary: Understanding Categories

We've established a solid foundation for understanding categories (union types) in EER modeling. Let's consolidate the key insights:

Key Takeaways

•Categories model union of different entity types — When fundamentally different, unrelated entities need to play a common role, categories provide the correct semantic construct.
•Mutual exclusivity is fundamental — Every category instance belongs to exactly one superclass, never multiple. This distinguishes categories from overlapping specialization.
•Categories are NOT reversed generalization — The semantic meaning differs: generalization abstracts commonality upward; categories collect diversity into a unified role.
•Selective inheritance applies — Instances inherit only from their specific superclass, not from all superclasses in the category definition.
•The artificial superclass test — If creating a common superclass feels forced, you need a category. Natural superclass concepts indicate proper specialization.
•Categories represent role-playing — Think of categories as capturing a role that different entity types can play without losing their independent identity.

What's Next:

Now that we understand what categories are and when to use them, we'll explore selective inheritance in depth—examining exactly how attribute and relationship inheritance works when an instance can only inherit from one of multiple possible superclasses. This understanding is crucial for correct category implementation.

Page Complete

You now understand the fundamental concept of categories (union types) in EER modeling. You can identify when categories are appropriate versus specialization, and you understand the key characteristics that define this powerful modeling construct. Next, we'll dive deep into how selective inheritance works within categories.

1 / 5

Loading learning content...

Database Management SystemCategories (Union Types)

Categories and Union Types in EER Modeling

LevelAdvanced

Duration60 mins

TopicCategories (Union Types)

1 / 5

Category Definition

When One Superclass Isn't Enough

But what happens when an entity needs to draw its identity from one of several unrelated entity types? Consider these real-world scenarios:

A bank account can be owned by a Person OR a Company—two fundamentally different entity types
A property can be owned by an Individual, a Corporation, OR a Government Agency
A vehicle can be registered to a Citizen OR an Organization

What You Will Learn

The Category Concept

Formal Definition:

A category C is a subset of the union of n defining superclasses {S₁, S₂, ..., Sₙ} such that:

C ⊆ (S₁ ∪ S₂ ∪ ... ∪ Sₙ)

Crucially, for any instance c in C:

c ∈ Sᵢ for exactly one i where 1 ≤ i ≤ n

This means each entity in the category comes from one and only one of the superclasses, never multiple simultaneously.

The Union Type Terminology

The Critical Distinction:

In shared superclass (specialization/generalization):

All subtypes inherit from the same superclass
The superclass exists as a unified entity type
Every instance of a subtype IS an instance of the superclass

In category (union type):

The category has multiple different superclasses
These superclasses are typically unrelated entity types
Each category instance inherits from exactly one superclass
The category itself is a collector of related but distinct entities

Converting Mermaid diagram...

Why Categories Are Necessary

To understand why categories exist, consider a scenario that cannot be adequately modeled using only specialization and generalization.

The Vehicle Registration Problem:

A Department of Motor Vehicles (DMV) system must track vehicle registrations. Vehicles can be registered to:

Individual persons (with attributes: SSN, name, address, driver's license number)
Companies (with attributes: company ID, name, address, registration number)
Government agencies (with attributes: agency ID, name, jurisdiction, contact person)

The key observations:

PERSON, COMPANY, and GOVERNMENT_AGENCY are fundamentally different entity types
They share almost no common attributes (name and address are superficial similarities)
A vehicle is registered to exactly one of these, never multiple
The REGISTRATION relationship needs a unified reference to the owner

The Generalization Trap

Why Alternative Approaches Fail:

Approach 1: Multiple Relationships

VEHICLE --owned_by_person--> PERSON
VEHICLE --owned_by_company--> COMPANY  
VEHICLE --owned_by_govt--> GOVERNMENT_AGENCY

Problems:

Requires complex constraint: exactly one must be non-null
Queries become complex with UNION/COALESCE logic
Adding new owner types multiplies relationships
No unified way to reference 'the owner'

Approach 2: Artificial Generalization

OWNER (artificial superclass)
  ├── PERSON
  ├── COMPANY
  └── GOVERNMENT_AGENCY

Problems:

Semantically incorrect—these aren't subtypes of a common concept
Forces unrelated entities into false hierarchy
PERSON has independent existence beyond being an 'owner'
Pollutes entity type semantics

Approach 3: Generic Entity

OWNER (entity_type, entity_id, name, address, ...)

Problems:

Loses type-specific attributes and constraints
No referential integrity to source entities
Violates normalization principles
Denormalized attribute handling nightmare

Modeling Approaches Comparison
Approach	Semantic Correctness	Query Simplicity	Extensibility	Referential Integrity
Multiple Relationships	✓ Correct	✗ Complex	✗ Poor	✓ Strong
Artificial Generalization	✗ Incorrect	✓ Simple	✓ Good	✓ Strong
Generic Entity	✗ Incorrect	~ Medium	✓ Good	✗ Weak
Category (Union Type)	✓ Correct	✓ Simple	✓ Good	✓ Strong

Category Characteristics

Categories exhibit several distinctive characteristics that set them apart from other EER constructs. Understanding these characteristics is essential for correct category design and implementation.

Defining Characteristics of Categories

•Multiple Heterogeneous Superclasses — Unlike shared subclass where one subtype inherits from multiple related supertypes (shared superclass), a category collects from fundamentally different, unrelated entity types.
•Mutual Exclusivity of Membership — Each category instance belongs to exactly one defining superclass. An OWNER is either a PERSON or a COMPANY or a GOVERNMENT_AGENCY—never a combination.
•Selective Inheritance — Since an instance inherits from only one superclass, it inherits only that superclass's attributes and relationships, not all superclass attributes.
•Subtype of the Union — The category is a subtype of the union of its superclasses. This means not all superclass instances need to participate in the category.
•Surrogate Key Typically Required — Because different superclasses have different key attributes, categories often require their own surrogate identifier.

Category vs. Multiple Inheritance

The Superclass-Subclass Direction:

In specialization/generalization, the inheritance direction is:

Superclass → Subclass (top-down or bottom-up)

In categories, the direction is inverted conceptually:

Multiple Superclasses → Category (union collectsion)

Converting Mermaid diagram...

Category Notation in EER Diagrams

Category Notation Elements
Element	Symbol	Description
Category symbol	Circle with 'U' (∪)	Represents the union operation that defines the category
Superclass connections	Lines to circle	Each defining superclass connects to the union symbol
Category entity	Rectangle below ∪	The category (subclass) entity that results from the union
Total constraint	Double line to category	All superclass instances must participate in category
Partial constraint	Single line to category	Not all superclass instances must participate

Standard EER Category Diagram Structure:

    [PERSON]          [COMPANY]        [GOVERNMENT_AGENCY]
        \                 |                   /
         \                |                  /
          \               |                 /
           \              |                /
            \             |               /
             ============(∪)=============    ← Union symbol
                          |
                          | (single or double line)
                          |
                     [OWNER]           ← Category entity
                          |
                          |
                     <OWNS>            ← Can participate in relationships
                          |
                     [VEHICLE]

The key distinguishing features:

Union symbol (∪) instead of specialization circle (○ or ●)
Arrows point toward the category from superclasses (reverse of specialization)
Category entity appears below the union symbol
Category can have its own attributes and relationships

Reading the Diagram Direction

Notation Variations Across Standards:

Different textbooks and CASE tools may use variations:

Standard/Tool	Category Symbol	Superclass Connection
Elmasri & Navathe	∪ in circle	Lines to circle
Chen (Extended)	U-shaped arc	Arc connects superclasses
UML	{union} stereotype	Dashed lines to subclass
ERwin	Category entity type	CAT relationship
Oracle Designer	Subtype cluster	Arc with 'U' label

Regardless of notation, the semantics remain consistent: a category collects instances from multiple unrelated superclasses into a unified entity type.

Real-World Category Examples

Categories appear naturally in many real-world database scenarios. Examining concrete examples helps solidify understanding of when and why to use this construct.

Account Holder Category

In a banking system, accounts can be held by different types of legal entities:

Superclasses:

INDIVIDUAL: SSN, first_name, last_name, date_of_birth, address
CORPORATION: tax_id, corporate_name, incorporation_date, state
TRUST: trust_id, trust_name, creation_date, trustee_name
ESTATE: estate_id, deceased_name, executor_name, court_case_number

Category: ACCOUNT_HOLDER

holder_id (surrogate key)
holder_since
credit_score
risk_classification

Why Category?

These are fundamentally different legal entities
They have completely different identification systems (SSN vs Tax ID vs Trust ID)
Each has unique regulatory requirements
An account has exactly ONE holder type (not a person AND a trust)

Converting Mermaid diagram...

Category vs. Specialization: Making the Right Choice

One of the most common modeling errors is choosing between category and specialization incorrectly. This decision fundamentally affects your schema's semantic accuracy and implementation complexity.

The Key Question:

Ask yourself: Do the entity types have independent existence with fundamentally different identities, or are they variations of a single conceptual entity?

Use Specialization When

•Subtypes are variations of the same concept
•There is a clear IS-A relationship (Employee IS-A Person)
•Subtypes share a meaningful common supertype
•Supertype has substantial shared attributes
•Instances can potentially belong to multiple subtypes (overlapping)
•You're refining a general concept into specific types

Use Category When

•Entity types are fundamentally different concepts
•There is a ROLE relationship (Person plays role of Owner)
•Superclasses would be artificial if created
•Superclasses share few meaningful attributes
•Instances belong to exactly one superclass (always disjoint)
•You're collecting unrelated entities for a common purpose

The 'Artificial Superclass' Test

Quick Reference: Specialization vs. Category
Scenario	Recommended Construct	Reasoning
Student, Faculty, Staff as people	Specialization of PERSON	All are variations of human individuals with shared Person attributes
Person, Company as account holders	Category → ACCOUNT_HOLDER	Fundamentally different legal entity types playing same role
Checking, Savings, Investment accounts	Specialization of ACCOUNT	All are variations of financial accounts with shared Account attributes
Vehicle, Building, Artwork as insured items	Category → INSURED_ITEM	Unrelated asset types being insured for same purpose
Hourly, Salaried, Commission employees	Specialization of EMPLOYEE	All are variations of employment compensation structure
Person, Organization as event sponsors	Category → SPONSOR	Fundamentally different entity types sponsoring events

Common Misconceptions About Categories

Categories are frequently misunderstood, leading to incorrect models and implementation errors. Let's address the most common misconceptions.

Misconceptions to Avoid

•Misconception: Categories are just generalization in reverse — While visually similar in reverse, the semantics are fundamentally different. Generalization creates shared abstraction; categories create unified collection without shared abstraction.
•Misconception: An instance can belong to multiple superclasses — Never. Category membership is always mutually exclusive. An OWNER is exactly ONE of: PERSON, COMPANY, or GOVERNMENT—never multiple.
•Misconception: All superclass instances must be in the category — Not necessarily. A PERSON can exist without being an OWNER in the banking system. Total vs. partial participation rules apply.
•Misconception: Categories inherit all attributes from all superclasses — An instance inherits only from its ONE superclass. An OWNER that is a PERSON has person attributes; an OWNER that is a COMPANY has company attributes.
•Misconception: Categories can be replaced by multiple foreign keys — While technically possible, this loses referential integrity, complicates queries, and makes constraint enforcement difficult.

The Inheritance Asymmetry

Correct Mental Model:

[PERSON: John Smith] ──plays role of──> [OWNER for Account A]
[COMPANY: Acme Corp] ──plays role of──> [OWNER for Account B]
[TRUST: Smith Family Trust] ──plays role of──> [OWNER for Account C]

Each OWNER is a distinct instance, referencing exactly one superclass instance that fills the owner role for a specific context.

Summary: Understanding Categories

We've established a solid foundation for understanding categories (union types) in EER modeling. Let's consolidate the key insights:

Key Takeaways

•Categories model union of different entity types — When fundamentally different, unrelated entities need to play a common role, categories provide the correct semantic construct.
•Mutual exclusivity is fundamental — Every category instance belongs to exactly one superclass, never multiple. This distinguishes categories from overlapping specialization.
•Categories are NOT reversed generalization — The semantic meaning differs: generalization abstracts commonality upward; categories collect diversity into a unified role.
•Selective inheritance applies — Instances inherit only from their specific superclass, not from all superclasses in the category definition.
•The artificial superclass test — If creating a common superclass feels forced, you need a category. Natural superclass concepts indicate proper specialization.
•Categories represent role-playing — Think of categories as capturing a role that different entity types can play without losing their independent identity.

What's Next:

Page Complete

1 / 5