Disjoint vs Overlapping Constraints - Constraints on Specialization | OneNoughtOne

0/278

Database Management SystemsEnhanced ER (EER)

Constraints on Specialization

LevelIntermediate

Duration75 mins

TopicEnhanced ER (EER)

1 / 5

Disjoint vs Overlapping Constraints

The Fundamental Question of Subclass Membership

When we model the real world using Enhanced Entity-Relationship (EER) diagrams, we frequently encounter situations where entities of a superclass can be classified into multiple specialized subclasses. But here arises a fundamental question that shapes the entire structure of our data model: Can an entity belong to multiple subclasses simultaneously, or must it belong to exactly one?

This seemingly simple question has profound implications for database schema design, constraint enforcement, query patterns, and application logic. The answer determines whether we model with disjoint (also called exclusive) constraints or overlapping (also called inclusive) constraints.

Consider an organization tracking its personnel. Every person might be classified as either an Employee or a Contractor—but never both. This is a disjoint scenario. However, in an academic context, a person might simultaneously be a Student and a TeachingAssistant—an overlapping scenario.

The distinction between these two constraint types is not merely academic—it fundamentally affects:

How we structure tables in the physical database
What integrity constraints we enforce
How insert, update, and delete operations behave
What queries are valid and efficient
How application code interacts with the database

What You Will Master

By the end of this page, you will deeply understand disjoint and overlapping constraints, be able to identify which applies to any real-world scenario, know the formal definitions and notation, understand the implementation implications, and recognize the design tradeoffs involved.

Disjoint Constraint: Exclusive Subclass Membership

A disjoint constraint (also known as an exclusiveness constraint or disjointness constraint) specifies that the subclasses of a specialization are mutually exclusive. This means that any entity from the superclass can belong to at most one subclass within the specialization.

Formal Definition:

Given a superclass C with a specialization defining subclasses S₁, S₂, ..., Sₙ, a disjoint constraint specifies:

∀i, j where i ≠ j: Sᵢ ∩ Sⱼ = ∅

In plain language: The intersection of any two distinct subclasses is always the empty set. No entity can exist in more than one subclass.

Intuitive Understanding:

Think of disjoint subclasses as mutually exclusive categories. If you're sorting objects into labeled boxes, each object goes into exactly one box (or no box at all, depending on participation constraints). An object cannot be in multiple boxes simultaneously.

This constraint reflects real-world scenarios where classifications are inherently exclusive—a transaction is either a deposit or a withdrawal, a vehicle is either a motorcycle or a car, a course is either undergraduate or graduate level.

The 'd' Notation

In standard EER notation, a disjoint constraint is indicated by placing the letter 'd' (for 'disjoint') inside the circle that connects the superclass to its subclasses. Some notations use 'disjoint' written out, while others use symbols like × or a circled d. Always verify the notation convention being used in your context.

Canonical Examples of Disjoint Specialization:

Payment Types: A Payment entity can be specialized into CashPayment, CreditCardPayment, DebitCardPayment, CryptocurrencyPayment. Each payment is exactly one type—you cannot pay with both cash and credit card in a single payment entity.
Vehicle Classification: A Vehicle can be specialized into Motorcycle, Car, Truck, Bus. A vehicle is manufactured as exactly one of these types (ignoring unusual hybrid vehicles).
Employee Categories: In some organizations, an Employee is classified as either FullTime or PartTime. These categories are mutually exclusive based on employment contract terms.
Account Types: A BankAccount might be specialized into CheckingAccount, SavingsAccount, MoneyMarketAccount—each account is opened as exactly one type.
Transaction Types: A Transaction is either a Deposit, Withdrawal, Transfer, or Fee. Each transaction record represents exactly one operation type.

Disjoint Constraint: Key Properties and Implications
Property	Description	Implementation Impact
Mutual Exclusivity	Entity can belong to at most one subclass	Discriminator column with CHECK constraint
Classification Determinism	Entity's subclass membership is unambiguous	Single-table inheritance or class table inheritance
Query Simplicity	Subclass membership checks are straightforward	Simple WHERE clauses, no multi-table joins for type
Insert Validation	Insert into one subclass automatically excludes others	Trigger or application logic enforces exclusivity
Update Semantics	Changing subclass requires leaving old, entering new	Atomic update of discriminator; cascade to subclass tables

Overlapping Constraint: Inclusive Subclass Membership

An overlapping constraint (also known as an inclusiveness constraint or non-disjoint constraint) specifies that the subclasses of a specialization are not mutually exclusive. An entity from the superclass can belong to multiple subclasses simultaneously.

Formal Definition:

Given a superclass C with a specialization defining subclasses S₁, S₂, ..., Sₙ, an overlapping constraint permits:

∃i, j where i ≠ j: Sᵢ ∩ Sⱼ ≠ ∅ is allowed

In plain language: The intersection of two or more subclasses may be non-empty. An entity can exist in multiple subclasses at the same time.

Intuitive Understanding:

Think of overlapping subclasses as non-exclusive roles or capabilities. A person might wear multiple hats—they're simultaneously a manager, a mentor, and a team member. A product might simultaneously be classified as 'Electronics', 'Portable', and 'Rechargeable'.

Overlapping constraints model real-world situations where entities naturally fit into multiple categories based on different orthogonal characteristics.

The 'o' Notation

In standard EER notation, an overlapping constraint is indicated by placing the letter 'o' (for 'overlapping') inside the circle that connects the superclass to its subclasses. Some notations use 'overlapping' written out, while others simply leave the constraint unmarked (treating overlapping as the default). Always verify notation conventions.

Canonical Examples of Overlapping Specialization:

University Roles: A Person in a university can be specialized into Student, Faculty, Staff, Alumnus. A graduate student who teaches could simultaneously be a Student and Faculty (as a teaching assistant). A professor who takes a continuing education course might be both Faculty and Student.
Product Categories: A Product might be specialized into Electronic, Portable, Rechargeable, WaterResistant. A smartphone belongs to all four categories simultaneously.
Project Roles: A TeamMember might be specialized into Developer, Tester, Designer, Analyst. In agile teams, individuals often hold multiple roles—a developer might also be a tester.
Insurance Policies: A Customer might have specializations LifeInsured, HealthInsured, PropertyInsured, VehicleInsured. Many customers hold multiple types of insurance simultaneously.
Media Classifications: A MediaItem might be specialized into Educational, Entertainment, Documentary, Fiction. A historical drama might be both Educational and Entertainment.

Overlapping Constraint: Key Properties and Implications
Property	Description	Implementation Impact
Non-Exclusivity	Entity can belong to multiple subclasses	Multiple flags/junction tables needed
Classification Combination	Entity may have any combination of subclass memberships	2^n possible combinations for n subclasses
Query Complexity	Membership checks may require multiple conditions	OR conditions, multiple joins, or bitmap columns
Insert Flexibility	Insert can specify membership in multiple subclasses	Multiple subclass table inserts or flag updates
Update Semantics	Add/remove subclass membership independently	Independent operations on each subclass table

Deep Comparative Analysis: Disjoint vs Overlapping

Understanding the differences between disjoint and overlapping constraints is crucial for correct data modeling. Let's examine these differences across multiple dimensions:

1. Semantic Dimension: What Does the Constraint Mean?

Disjoint: Categories are mutually exclusive. Membership in one category automatically precludes membership in others. The categories partition the superclass (if total) or partition a subset of the superclass (if partial).
Overlapping: Categories are independent characteristics. Membership in one category has no bearing on membership in others. Each category can be evaluated independently.

2. Mathematical Dimension: Set-Theoretic Properties

Disjoint: For all pairs of subclasses, Sᵢ ∩ Sⱼ = ∅. The subclasses form a partition (if total) or a partial partition (if partial) of the superclass.
Overlapping: Sᵢ ∩ Sⱼ ≠ ∅ is permitted for any pair. The subclasses may have arbitrary overlaps, including complete containment of one within another (though this is usually a modeling error).

3. Cardinality Dimension: How Many Subclasses Can an Entity Belong To?

Disjoint: An entity belongs to zero or one subclass (partial participation) or exactly one subclass (total participation).
Overlapping: An entity belongs to zero to n subclasses (partial participation) or one to n subclasses (total participation), where n is the number of subclasses.

Disjoint: When to Use

•Mutually Exclusive Types: The entity's 'type' is a fundamental, singular characteristic
•Discriminator-Based: A single attribute determines the subclass
•State Machines: Entity moves between states but occupies only one at a time
•Physical Reality: Object's physical nature prevents multiple classifications
•Business Rules: Policy dictates exclusive categorization

Overlapping: When to Use

•Role-Based: Entity can hold multiple roles simultaneously
•Multi-Dimensional: Multiple orthogonal classification axes
•Tagging Systems: Entity has multiple applicable tags
•Feature Sets: Entity possesses combination of features
•Temporal Evolution: Classifications that can be acquired over time

Common Modeling Mistake

A frequent error is modeling what should be overlapping as disjoint (or vice versa) based on current business practice rather than inherent constraints. Ask: 'Is there something about the nature of these categories that makes them mutually exclusive, or is it just that we currently happen not to have entities in multiple categories?' If it's the latter, and the situation might change, consider overlapping.

Notation Systems and Standards

Different notation systems have evolved for representing disjoint and overlapping constraints in EER diagrams. Understanding these notations is essential for reading diagrams from various sources and communicating designs to diverse audiences.

1. Chen Notation (Extended)

In Chen's original EER notation (and its many extensions):

A circle or semicircle connects the superclass to its subclasses
The letter 'd' inside the circle indicates disjoint
The letter 'o' inside the circle indicates overlapping
Some variants use a filled circle for disjoint and an empty circle for overlapping

2. (min, max) Notation

Some notations use minimum and maximum cardinalities:

(0, 1) on the superclass-to-subclass relationship implies disjoint (at most one subclass)
(0, n) on the superclass-to-subclass relationship implies overlapping (any number)

3. UML Class Diagram Notation

In UML, which incorporates EER concepts:

{disjoint} constraint text annotation near the generalization arrows
{overlapping} constraint text annotation (or {incomplete, overlapping} for partial overlapping)
{complete, disjoint} indicates total participation with disjoint subclasses

4. Barker Notation (Oracle)

In Barker notation (used in Oracle Designer tools):

Exclusive arcs with different symbols
Exclusive subtypes shown with special arc symbols
Non-exclusive subtypes shown without exclusivity markers

Notation Comparison

DISJOINT SPECIALIZATION (Chen Notation):
 
           ┌─────────┐
           │ Vehicle │
           └────┬────┘
                │
               (d)      ← 'd' indicates DISJOINT
           ┌────┴────┐
      ┌────┴────┐ ┌──┴──────┐
      │   Car   │ │  Truck  │
      └─────────┘ └─────────┘
 
OVERLAPPING SPECIALIZATION (Chen Notation):
 
         ┌─────────┐
         │  Person │
         └────┬────┘
              │
             (o)      ← 'o' indicates OVERLAPPING
         ┌────┴────┐
    ┌────┴────┐ ┌──┴──────┐
    │ Student │ │ Faculty │
    └─────────┘ └─────────┘

Notation Comparison Reference
Notation System	Disjoint Symbol	Overlapping Symbol	Context
Chen Extended	'd' in circle	'o' in circle	Academic, textbooks
Elmasri & Navathe	'd' in circle or 'd' notation	'o' in circle	Database textbooks
UML	{disjoint} annotation	{overlapping} annotation	Software engineering, OOP
Barker (Oracle)	Exclusive arc	No arc marker	Oracle Designer tools
IE (Crow's Foot)	Exclusion arc	No exclusion arc	Industry tools (ERwin, etc.)

Implementation Strategies in Relational Databases

Translating disjoint and overlapping constraints from conceptual EER models to concrete relational database schemas requires careful consideration of implementation strategies. Each constraint type favors different physical designs.

Implementation Strategies for Disjoint Specialization:

Strategy 1: Single Table with Discriminator Column

All subclasses are merged into a single table. A discriminator column indicates which subclass each row belongs to. Columns specific to one subclass contain NULL for rows of other subclasses.

CREATE TABLE Vehicle (
    vehicle_id INT PRIMARY KEY,
    vehicle_type VARCHAR(20) NOT NULL CHECK (vehicle_type IN ('Car', 'Truck', 'Bus')),
    make VARCHAR(50),
    model VARCHAR(50),
    -- Car-specific columns
    num_passengers INT,
    -- Truck-specific columns
    cargo_capacity DECIMAL,
    -- Bus-specific columns
    route_number VARCHAR(10)
);

Advantages: Simple queries, no joins for polymorphic access Disadvantages: NULL pollution, wasted space, complex constraints

Strategy 2: Class Table Inheritance (Separate Tables)

One table for the superclass, separate tables for each subclass. Subclass tables have foreign keys to the superclass.

CREATE TABLE Vehicle (
    vehicle_id INT PRIMARY KEY,
    make VARCHAR(50),
    model VARCHAR(50)
);

CREATE TABLE Car (
    vehicle_id INT PRIMARY KEY REFERENCES Vehicle(vehicle_id),
    num_passengers INT
);

CREATE TABLE Truck (
    vehicle_id INT PRIMARY KEY REFERENCES Vehicle(vehicle_id),
    cargo_capacity DECIMAL
);

Enforcing Disjointness: Requires triggers or application logic to prevent a vehicle_id from appearing in multiple subclass tables.

Disjoint Enforcement
SQL (Trigger)
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
-- Trigger to enforce disjoint constraint in class table inheritance
-- This trigger prevents an entity from being in multiple subclass tables
 
CREATE OR REPLACE FUNCTION enforce_vehicle_disjoint()
RETURNS TRIGGER AS $$
BEGIN
    -- Check if this vehicle_id already exists in another subclass table
    IF TG_TABLE_NAME = 'car' THEN
        IF EXISTS (SELECT 1 FROM truck WHERE vehicle_id = NEW.vehicle_id) OR
           EXISTS (SELECT 1 FROM bus WHERE vehicle_id = NEW.vehicle_id) THEN
            RAISE EXCEPTION 'Disjoint constraint violated: Vehicle % already belongs to another subclass', NEW.vehicle_id;
        END IF;
    ELSIF TG_TABLE_NAME = 'truck' THEN
        IF EXISTS (SELECT 1 FROM car WHERE vehicle_id = NEW.vehicle_id) OR
           EXISTS (SELECT 1 FROM bus WHERE vehicle_id = NEW.vehicle_id) THEN
            RAISE EXCEPTION 'Disjoint constraint violated: Vehicle % already belongs to another subclass', NEW.vehicle_id;
        END IF;
    ELSIF TG_TABLE_NAME = 'bus' THEN
        IF EXISTS (SELECT 1 FROM car WHERE vehicle_id = NEW.vehicle_id) OR
           EXISTS (SELECT 1 FROM truck WHERE vehicle_id = NEW.vehicle_id) THEN
            RAISE EXCEPTION 'Disjoint constraint violated: Vehicle % already belongs to another subclass', NEW.vehicle_id;
        END IF;
    END IF;
    
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;
 
-- Apply trigger to all subclass tables
CREATE TRIGGER check_car_disjoint BEFORE INSERT OR UPDATE ON car
    FOR EACH ROW EXECUTE FUNCTION enforce_vehicle_disjoint();
    
CREATE TRIGGER check_truck_disjoint BEFORE INSERT OR UPDATE ON truck
    FOR EACH ROW EXECUTE FUNCTION enforce_vehicle_disjoint();
    
CREATE TRIGGER check_bus_disjoint BEFORE INSERT OR UPDATE ON bus
    FOR EACH ROW EXECUTE FUNCTION enforce_vehicle_disjoint();

Implementation Strategies for Overlapping Specialization:

Strategy 1: Multiple Flag Columns

Add boolean flag columns for each subclass membership in the superclass table:

CREATE TABLE Person (
    person_id INT PRIMARY KEY,
    name VARCHAR(100),
    is_student BOOLEAN DEFAULT FALSE,
    is_faculty BOOLEAN DEFAULT FALSE,
    is_staff BOOLEAN DEFAULT FALSE
);

Advantages: Simple, compact, fast membership checks Disadvantages: Limited subclass-specific columns, CHECK constraints for dependencies

Strategy 2: Separate Subclass Tables (Junction Style)

Separate tables for each subclass, allowing multiple rows per entity:

CREATE TABLE Person (
    person_id INT PRIMARY KEY,
    name VARCHAR(100)
);

CREATE TABLE Student (
    person_id INT PRIMARY KEY REFERENCES Person(person_id),
    student_id VARCHAR(20),
    enrollment_date DATE
);

CREATE TABLE Faculty (
    person_id INT PRIMARY KEY REFERENCES Person(person_id),
    department VARCHAR(50),
    hire_date DATE
);

A person can appear in any combination of subclass tables.

Strategy 3: Role Table with Many-to-Many

For highly dynamic overlapping scenarios:

CREATE TABLE PersonRole (
    person_id INT REFERENCES Person(person_id),
    role_type VARCHAR(20),
    PRIMARY KEY (person_id, role_type)
);

This fully normalizes role memberships but loses subclass-specific attributes.

Choosing an Implementation

The choice of implementation strategy depends on factors beyond just disjoint vs overlapping: query patterns (polymorphic vs specific), update frequency, subclass-specific attributes, storage constraints, and ORM compatibility. A Principal Engineer evaluates all factors and may use different strategies for different specializations in the same model.

Decision Framework: Diagnosing Real-World Scenarios

When analyzing a real-world domain to determine whether to model specialization as disjoint or overlapping, apply this systematic decision framework:

Step 1: Identify the Classification Basis

Ask: What distinguishes one subclass from another?

If the distinction is a single discriminating attribute with mutually exclusive values (e.g., payment_type = 'cash' | 'credit' | 'debit'), lean toward disjoint.
If entities are classified along multiple independent dimensions (e.g., roles, features, capabilities), lean toward overlapping.

Step 2: Apply the 'Can It Be Both?' Test

For each pair of subclasses, ask: Can a single real-world entity meaningfully be both simultaneously?

If NEVER (physically impossible or logically contradictory): Disjoint
If POSSIBLE (even if rare in practice): Consider Overlapping
If COMMON (entities frequently belong to multiple): Definitely Overlapping

Step 3: Consider Temporal Dynamics

Ask: Do entities transition between subclasses over time, or accumulate memberships?

Transition (entity moves from one subclass to another): Often Disjoint (state machine semantics)
Accumulation (entity gains additional classifications): Often Overlapping (role acquisition)

Step 4: Examine Business Rules

Ask: Are there explicit policies that mandate exclusivity?

If policy enforces exclusivity (e.g., regulatory requirement, legal distinction): Disjoint
If exclusivity is just current practice (could change): Consider future flexibility

Step 5: Evaluate Implementation Complexity

Consider:

How many subclasses are there?
How many subclass-specific attributes exist?
What are the dominant query patterns?

Sometimes overlapping is conceptually correct but practically complex; design decisions may involve tradeoffs.

Decision Framework: Diagnostic Questions
Question	Disjoint Indicator	Overlapping Indicator
Single discriminating value?	Yes, one value determines subclass	No, multiple criteria apply
Can entity be in 2+ subclasses?	Never, physically/logically impossible	Yes, common or occasional
Transition or accumulation?	Entity moves between states	Entity gains additional roles
Policy-mandated exclusivity?	Yes, regulatory or legal	No, or only current practice
Simple single-axis classification?	Yes, one dimension	No, multi-dimensional

When In Doubt

If you're unsure whether to model as disjoint or overlapping, overlapping is the safer default. It's more flexible—you can always add application logic to enforce disjointness if needed, but converting from disjoint to overlapping later often requires schema changes. However, if your analysis clearly indicates disjointness, model it explicitly for clarity and constraint enforcement.

Case Study: E-Commerce User Classification

Let's apply our decision framework to a realistic e-commerce scenario, walking through the analysis step by step.

Scenario: An e-commerce platform needs to model users. Stakeholders have identified the following user categories:

Buyer: Users who purchase products
Seller: Users who list and sell products (marketplace model)
Affiliate: Users who earn commissions by referring buyers
Admin: Platform administrators with system access

Step 1: Classification Basis Analysis

Are these categories determined by a single discriminating attribute?

No—these represent roles a user might have, based on their activities and permissions. A user might purchase items (Buyer), also run a shop (Seller), participate in the affiliate program (Affiliate), and have admin privileges (Admin). These are independent roles.

Step 2: 'Can It Be Both?' Test

Can a user be both Buyer AND Seller? Yes (common in marketplaces like Etsy, eBay)
Can a user be both Buyer AND Affiliate? Yes (buy products AND earn referral commissions)
Can a user be both Seller AND Admin? Yes (platform employee who also runs a shop)
Can a user be all four? Possible (though rare)

Verdict from this test: Overlapping

Step 3: Temporal Dynamics

Do users transition or accumulate?

A new user starts as Buyer (makes first purchase)
Later applies to become Seller (opens shop)—adds role, doesn't replace
Joins affiliate program—adds another role
Gets promoted to Admin—adds another role

This is accumulation, not transition. Confirms: Overlapping

Step 4: Business Rules

Are there any policies mandating exclusivity?

Legal: In some jurisdictions, admins might be prohibited from being sellers (conflict of interest). This could be a constraint but not a fundamental exclusivity—it's a business rule on top of an overlapping model.
General: No inherent exclusivity requirements.

No inherent disjointness. Overlapping, with possible subset constraints.

E-Commerce User Model
SQL Schema
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
-- Overlapping Specialization Implementation for E-Commerce Users
 
-- Superclass table
CREATE TABLE platform_user (
    user_id SERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    display_name VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    last_login_at TIMESTAMP
);
 
-- Buyer subclass (overlapping)
CREATE TABLE buyer (
    user_id INT PRIMARY KEY REFERENCES platform_user(user_id) ON DELETE CASCADE,
    shipping_address TEXT,
    preferred_payment_method VARCHAR(50),
    loyalty_points INT DEFAULT 0
);
 
-- Seller subclass (overlapping)
CREATE TABLE seller (
    user_id INT PRIMARY KEY REFERENCES platform_user(user_id) ON DELETE CASCADE,
    shop_name VARCHAR(100) NOT NULL,
    shop_description TEXT,
    commission_rate DECIMAL(5,2) DEFAULT 10.00,
    verified_at TIMESTAMP,
    payout_account VARCHAR(255)
);
 
-- Affiliate subclass (overlapping)
CREATE TABLE affiliate (
    user_id INT PRIMARY KEY REFERENCES platform_user(user_id) ON DELETE CASCADE,
    affiliate_code VARCHAR(20) UNIQUE NOT NULL,
    commission_percent DECIMAL(5,2) DEFAULT 5.00,
    payout_threshold DECIMAL(10,2) DEFAULT 50.00,
    approved_at TIMESTAMP
);
 
-- Admin subclass (overlapping)
CREATE TABLE platform_admin (
    user_id INT PRIMARY KEY REFERENCES platform_user(user_id) ON DELETE CASCADE,
    admin_level INT NOT NULL CHECK (admin_level BETWEEN 1 AND 5),
    permissions JSONB DEFAULT '{}',
    assigned_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
 
-- Optional: Business rule constraint (Admins cannot be Sellers)
CREATE OR REPLACE FUNCTION check_admin_seller_conflict()
RETURNS TRIGGER AS $$
BEGIN
    IF TG_TABLE_NAME = 'seller' THEN
        IF EXISTS (SELECT 1 FROM platform_admin WHERE user_id = NEW.user_id) THEN
            RAISE EXCEPTION 'Business rule violation: Admins cannot be Sellers';
        END IF;
    ELSIF TG_TABLE_NAME = 'platform_admin' THEN
        IF EXISTS (SELECT 1 FROM seller WHERE user_id = NEW.user_id) THEN
            RAISE EXCEPTION 'Business rule violation: Sellers cannot become Admins';
        END IF;
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;
 
CREATE TRIGGER enforce_admin_seller_conflict_on_seller
    BEFORE INSERT OR UPDATE ON seller FOR EACH ROW
    EXECUTE FUNCTION check_admin_seller_conflict();
    
CREATE TRIGGER enforce_admin_seller_conflict_on_admin
    BEFORE INSERT OR UPDATE ON platform_admin FOR EACH ROW
    EXECUTE FUNCTION check_admin_seller_conflict();

Case Study Outcome

The analysis clearly indicates an overlapping specialization. Users can hold multiple roles simultaneously, roles are acquired over time, and no fundamental exclusivity exists. The implementation uses separate subclass tables with optional business rule constraints for specific pairs where policy demands restrictions.

Summary: Disjoint vs Overlapping Mastery

We have explored the fundamental distinction between disjoint and overlapping constraints in EER modeling—a distinction that shapes database schemas, application logic, and system behavior. Let's consolidate the essential knowledge:

Core Concepts Mastered

•Disjoint Constraint (d): Subclasses are mutually exclusive. An entity belongs to at most one subclass. Formal: ∀i,j: Sᵢ ∩ Sⱼ = ∅.
•Overlapping Constraint (o): Subclasses are not mutually exclusive. An entity may belong to multiple subclasses simultaneously.
•Notation: 'd' or 'o' in Chen's circle; {disjoint} or {overlapping} in UML; varies across notations.
•Decision Framework: Analyze classification basis, apply 'Can It Be Both?' test, consider temporal dynamics, examine business rules.
•Disjoint Implementation: Single table with discriminator, or class table inheritance with triggers enforcing exclusivity.
•Overlapping Implementation: Flag columns, separate subclass tables allowing multiple memberships, or role junction tables.

Quick Reference: Disjoint vs Overlapping
Aspect	Disjoint (d)	Overlapping (o)
Meaning	Mutually exclusive subclasses	Non-exclusive subclasses
Entity Membership	At most one subclass	Zero to all subclasses
Real-World Analog	Type, state, category	Role, feature, tag
Discriminator	Single value determines subclass	Multiple independent flags
Constraint Enforcement	CHECK, triggers, single insert	No exclusivity needed
Default When Unsure	No—requires explicit analysis	Yes—more flexible choice

Page Complete

You now possess a deep understanding of disjoint vs overlapping constraints in EER specialization. You can identify which constraint applies to real-world scenarios, understand notation, and design appropriate implementations. Next, we explore the orthogonal dimension: Total vs Partial participation constraints.

Database Management SystemsEnhanced ER (EER)

Constraints on Specialization

LevelIntermediate

Duration75 mins

TopicEnhanced ER (EER)

1 / 5

Disjoint vs Overlapping Constraints

The Fundamental Question of Subclass Membership

The distinction between these two constraint types is not merely academic—it fundamentally affects:

How we structure tables in the physical database
What integrity constraints we enforce
How insert, update, and delete operations behave
What queries are valid and efficient
How application code interacts with the database

What You Will Master

Disjoint Constraint: Exclusive Subclass Membership

Formal Definition:

Given a superclass C with a specialization defining subclasses S₁, S₂, ..., Sₙ, a disjoint constraint specifies:

∀i, j where i ≠ j: Sᵢ ∩ Sⱼ = ∅

In plain language: The intersection of any two distinct subclasses is always the empty set. No entity can exist in more than one subclass.

Intuitive Understanding:

The 'd' Notation

Canonical Examples of Disjoint Specialization:

Payment Types: A Payment entity can be specialized into CashPayment, CreditCardPayment, DebitCardPayment, CryptocurrencyPayment. Each payment is exactly one type—you cannot pay with both cash and credit card in a single payment entity.
Vehicle Classification: A Vehicle can be specialized into Motorcycle, Car, Truck, Bus. A vehicle is manufactured as exactly one of these types (ignoring unusual hybrid vehicles).
Employee Categories: In some organizations, an Employee is classified as either FullTime or PartTime. These categories are mutually exclusive based on employment contract terms.
Account Types: A BankAccount might be specialized into CheckingAccount, SavingsAccount, MoneyMarketAccount—each account is opened as exactly one type.
Transaction Types: A Transaction is either a Deposit, Withdrawal, Transfer, or Fee. Each transaction record represents exactly one operation type.

Disjoint Constraint: Key Properties and Implications
Property	Description	Implementation Impact
Mutual Exclusivity	Entity can belong to at most one subclass	Discriminator column with CHECK constraint
Classification Determinism	Entity's subclass membership is unambiguous	Single-table inheritance or class table inheritance
Query Simplicity	Subclass membership checks are straightforward	Simple WHERE clauses, no multi-table joins for type
Insert Validation	Insert into one subclass automatically excludes others	Trigger or application logic enforces exclusivity
Update Semantics	Changing subclass requires leaving old, entering new	Atomic update of discriminator; cascade to subclass tables

Overlapping Constraint: Inclusive Subclass Membership

Formal Definition:

Given a superclass C with a specialization defining subclasses S₁, S₂, ..., Sₙ, an overlapping constraint permits:

∃i, j where i ≠ j: Sᵢ ∩ Sⱼ ≠ ∅ is allowed

In plain language: The intersection of two or more subclasses may be non-empty. An entity can exist in multiple subclasses at the same time.

Intuitive Understanding:

Overlapping constraints model real-world situations where entities naturally fit into multiple categories based on different orthogonal characteristics.

The 'o' Notation

Canonical Examples of Overlapping Specialization:

University Roles: A Person in a university can be specialized into Student, Faculty, Staff, Alumnus. A graduate student who teaches could simultaneously be a Student and Faculty (as a teaching assistant). A professor who takes a continuing education course might be both Faculty and Student.
Product Categories: A Product might be specialized into Electronic, Portable, Rechargeable, WaterResistant. A smartphone belongs to all four categories simultaneously.
Project Roles: A TeamMember might be specialized into Developer, Tester, Designer, Analyst. In agile teams, individuals often hold multiple roles—a developer might also be a tester.
Insurance Policies: A Customer might have specializations LifeInsured, HealthInsured, PropertyInsured, VehicleInsured. Many customers hold multiple types of insurance simultaneously.
Media Classifications: A MediaItem might be specialized into Educational, Entertainment, Documentary, Fiction. A historical drama might be both Educational and Entertainment.

Overlapping Constraint: Key Properties and Implications
Property	Description	Implementation Impact
Non-Exclusivity	Entity can belong to multiple subclasses	Multiple flags/junction tables needed
Classification Combination	Entity may have any combination of subclass memberships	2^n possible combinations for n subclasses
Query Complexity	Membership checks may require multiple conditions	OR conditions, multiple joins, or bitmap columns
Insert Flexibility	Insert can specify membership in multiple subclasses	Multiple subclass table inserts or flag updates
Update Semantics	Add/remove subclass membership independently	Independent operations on each subclass table

Deep Comparative Analysis: Disjoint vs Overlapping

Understanding the differences between disjoint and overlapping constraints is crucial for correct data modeling. Let's examine these differences across multiple dimensions:

1. Semantic Dimension: What Does the Constraint Mean?

Disjoint: Categories are mutually exclusive. Membership in one category automatically precludes membership in others. The categories partition the superclass (if total) or partition a subset of the superclass (if partial).
Overlapping: Categories are independent characteristics. Membership in one category has no bearing on membership in others. Each category can be evaluated independently.

2. Mathematical Dimension: Set-Theoretic Properties

Disjoint: For all pairs of subclasses, Sᵢ ∩ Sⱼ = ∅. The subclasses form a partition (if total) or a partial partition (if partial) of the superclass.
Overlapping: Sᵢ ∩ Sⱼ ≠ ∅ is permitted for any pair. The subclasses may have arbitrary overlaps, including complete containment of one within another (though this is usually a modeling error).

3. Cardinality Dimension: How Many Subclasses Can an Entity Belong To?

Disjoint: An entity belongs to zero or one subclass (partial participation) or exactly one subclass (total participation).
Overlapping: An entity belongs to zero to n subclasses (partial participation) or one to n subclasses (total participation), where n is the number of subclasses.

Disjoint: When to Use

•Mutually Exclusive Types: The entity's 'type' is a fundamental, singular characteristic
•Discriminator-Based: A single attribute determines the subclass
•State Machines: Entity moves between states but occupies only one at a time
•Physical Reality: Object's physical nature prevents multiple classifications
•Business Rules: Policy dictates exclusive categorization

Overlapping: When to Use

•Role-Based: Entity can hold multiple roles simultaneously
•Multi-Dimensional: Multiple orthogonal classification axes
•Tagging Systems: Entity has multiple applicable tags
•Feature Sets: Entity possesses combination of features
•Temporal Evolution: Classifications that can be acquired over time

Common Modeling Mistake

Notation Systems and Standards

1. Chen Notation (Extended)

In Chen's original EER notation (and its many extensions):

A circle or semicircle connects the superclass to its subclasses
The letter 'd' inside the circle indicates disjoint
The letter 'o' inside the circle indicates overlapping
Some variants use a filled circle for disjoint and an empty circle for overlapping

2. (min, max) Notation

Some notations use minimum and maximum cardinalities:

(0, 1) on the superclass-to-subclass relationship implies disjoint (at most one subclass)
(0, n) on the superclass-to-subclass relationship implies overlapping (any number)

3. UML Class Diagram Notation

In UML, which incorporates EER concepts:

{disjoint} constraint text annotation near the generalization arrows
{overlapping} constraint text annotation (or {incomplete, overlapping} for partial overlapping)
{complete, disjoint} indicates total participation with disjoint subclasses

4. Barker Notation (Oracle)

In Barker notation (used in Oracle Designer tools):

Exclusive arcs with different symbols
Exclusive subtypes shown with special arc symbols
Non-exclusive subtypes shown without exclusivity markers

Notation Comparison

DISJOINT SPECIALIZATION (Chen Notation):
 
           ┌─────────┐
           │ Vehicle │
           └────┬────┘
                │
               (d)      ← 'd' indicates DISJOINT
           ┌────┴────┐
      ┌────┴────┐ ┌──┴──────┐
      │   Car   │ │  Truck  │
      └─────────┘ └─────────┘
 
OVERLAPPING SPECIALIZATION (Chen Notation):
 
         ┌─────────┐
         │  Person │
         └────┬────┘
              │
             (o)      ← 'o' indicates OVERLAPPING
         ┌────┴────┐
    ┌────┴────┐ ┌──┴──────┐
    │ Student │ │ Faculty │
    └─────────┘ └─────────┘

Notation Comparison Reference
Notation System	Disjoint Symbol	Overlapping Symbol	Context
Chen Extended	'd' in circle	'o' in circle	Academic, textbooks
Elmasri & Navathe	'd' in circle or 'd' notation	'o' in circle	Database textbooks
UML	{disjoint} annotation	{overlapping} annotation	Software engineering, OOP
Barker (Oracle)	Exclusive arc	No arc marker	Oracle Designer tools
IE (Crow's Foot)	Exclusion arc	No exclusion arc	Industry tools (ERwin, etc.)

Implementation Strategies in Relational Databases

Implementation Strategies for Disjoint Specialization:

Strategy 1: Single Table with Discriminator Column

All subclasses are merged into a single table. A discriminator column indicates which subclass each row belongs to. Columns specific to one subclass contain NULL for rows of other subclasses.

CREATE TABLE Vehicle (
    vehicle_id INT PRIMARY KEY,
    vehicle_type VARCHAR(20) NOT NULL CHECK (vehicle_type IN ('Car', 'Truck', 'Bus')),
    make VARCHAR(50),
    model VARCHAR(50),
    -- Car-specific columns
    num_passengers INT,
    -- Truck-specific columns
    cargo_capacity DECIMAL,
    -- Bus-specific columns
    route_number VARCHAR(10)
);

Advantages: Simple queries, no joins for polymorphic access Disadvantages: NULL pollution, wasted space, complex constraints

Strategy 2: Class Table Inheritance (Separate Tables)

One table for the superclass, separate tables for each subclass. Subclass tables have foreign keys to the superclass.

CREATE TABLE Vehicle (
    vehicle_id INT PRIMARY KEY,
    make VARCHAR(50),
    model VARCHAR(50)
);

CREATE TABLE Car (
    vehicle_id INT PRIMARY KEY REFERENCES Vehicle(vehicle_id),
    num_passengers INT
);

CREATE TABLE Truck (
    vehicle_id INT PRIMARY KEY REFERENCES Vehicle(vehicle_id),
    cargo_capacity DECIMAL
);

Enforcing Disjointness: Requires triggers or application logic to prevent a vehicle_id from appearing in multiple subclass tables.

Disjoint Enforcement
SQL (Trigger)
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
-- Trigger to enforce disjoint constraint in class table inheritance
-- This trigger prevents an entity from being in multiple subclass tables
 
CREATE OR REPLACE FUNCTION enforce_vehicle_disjoint()
RETURNS TRIGGER AS $$
BEGIN
    -- Check if this vehicle_id already exists in another subclass table
    IF TG_TABLE_NAME = 'car' THEN
        IF EXISTS (SELECT 1 FROM truck WHERE vehicle_id = NEW.vehicle_id) OR
           EXISTS (SELECT 1 FROM bus WHERE vehicle_id = NEW.vehicle_id) THEN
            RAISE EXCEPTION 'Disjoint constraint violated: Vehicle % already belongs to another subclass', NEW.vehicle_id;
        END IF;
    ELSIF TG_TABLE_NAME = 'truck' THEN
        IF EXISTS (SELECT 1 FROM car WHERE vehicle_id = NEW.vehicle_id) OR
           EXISTS (SELECT 1 FROM bus WHERE vehicle_id = NEW.vehicle_id) THEN
            RAISE EXCEPTION 'Disjoint constraint violated: Vehicle % already belongs to another subclass', NEW.vehicle_id;
        END IF;
    ELSIF TG_TABLE_NAME = 'bus' THEN
        IF EXISTS (SELECT 1 FROM car WHERE vehicle_id = NEW.vehicle_id) OR
           EXISTS (SELECT 1 FROM truck WHERE vehicle_id = NEW.vehicle_id) THEN
            RAISE EXCEPTION 'Disjoint constraint violated: Vehicle % already belongs to another subclass', NEW.vehicle_id;
        END IF;
    END IF;
    
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;
 
-- Apply trigger to all subclass tables
CREATE TRIGGER check_car_disjoint BEFORE INSERT OR UPDATE ON car
    FOR EACH ROW EXECUTE FUNCTION enforce_vehicle_disjoint();
    
CREATE TRIGGER check_truck_disjoint BEFORE INSERT OR UPDATE ON truck
    FOR EACH ROW EXECUTE FUNCTION enforce_vehicle_disjoint();
    
CREATE TRIGGER check_bus_disjoint BEFORE INSERT OR UPDATE ON bus
    FOR EACH ROW EXECUTE FUNCTION enforce_vehicle_disjoint();

Implementation Strategies for Overlapping Specialization:

Strategy 1: Multiple Flag Columns

Add boolean flag columns for each subclass membership in the superclass table:

CREATE TABLE Person (
    person_id INT PRIMARY KEY,
    name VARCHAR(100),
    is_student BOOLEAN DEFAULT FALSE,
    is_faculty BOOLEAN DEFAULT FALSE,
    is_staff BOOLEAN DEFAULT FALSE
);

Advantages: Simple, compact, fast membership checks Disadvantages: Limited subclass-specific columns, CHECK constraints for dependencies

Strategy 2: Separate Subclass Tables (Junction Style)

Separate tables for each subclass, allowing multiple rows per entity:

CREATE TABLE Person (
    person_id INT PRIMARY KEY,
    name VARCHAR(100)
);

CREATE TABLE Student (
    person_id INT PRIMARY KEY REFERENCES Person(person_id),
    student_id VARCHAR(20),
    enrollment_date DATE
);

CREATE TABLE Faculty (
    person_id INT PRIMARY KEY REFERENCES Person(person_id),
    department VARCHAR(50),
    hire_date DATE
);

A person can appear in any combination of subclass tables.

Strategy 3: Role Table with Many-to-Many

For highly dynamic overlapping scenarios:

CREATE TABLE PersonRole (
    person_id INT REFERENCES Person(person_id),
    role_type VARCHAR(20),
    PRIMARY KEY (person_id, role_type)
);

This fully normalizes role memberships but loses subclass-specific attributes.

Choosing an Implementation

Decision Framework: Diagnosing Real-World Scenarios

When analyzing a real-world domain to determine whether to model specialization as disjoint or overlapping, apply this systematic decision framework:

Step 1: Identify the Classification Basis

Ask: What distinguishes one subclass from another?

If the distinction is a single discriminating attribute with mutually exclusive values (e.g., payment_type = 'cash' | 'credit' | 'debit'), lean toward disjoint.
If entities are classified along multiple independent dimensions (e.g., roles, features, capabilities), lean toward overlapping.

Step 2: Apply the 'Can It Be Both?' Test

For each pair of subclasses, ask: Can a single real-world entity meaningfully be both simultaneously?

If NEVER (physically impossible or logically contradictory): Disjoint
If POSSIBLE (even if rare in practice): Consider Overlapping
If COMMON (entities frequently belong to multiple): Definitely Overlapping

Step 3: Consider Temporal Dynamics

Ask: Do entities transition between subclasses over time, or accumulate memberships?

Transition (entity moves from one subclass to another): Often Disjoint (state machine semantics)
Accumulation (entity gains additional classifications): Often Overlapping (role acquisition)

Step 4: Examine Business Rules

Ask: Are there explicit policies that mandate exclusivity?

If policy enforces exclusivity (e.g., regulatory requirement, legal distinction): Disjoint
If exclusivity is just current practice (could change): Consider future flexibility

Step 5: Evaluate Implementation Complexity

Consider:

How many subclasses are there?
How many subclass-specific attributes exist?
What are the dominant query patterns?

Sometimes overlapping is conceptually correct but practically complex; design decisions may involve tradeoffs.

Decision Framework: Diagnostic Questions
Question	Disjoint Indicator	Overlapping Indicator
Single discriminating value?	Yes, one value determines subclass	No, multiple criteria apply
Can entity be in 2+ subclasses?	Never, physically/logically impossible	Yes, common or occasional
Transition or accumulation?	Entity moves between states	Entity gains additional roles
Policy-mandated exclusivity?	Yes, regulatory or legal	No, or only current practice
Simple single-axis classification?	Yes, one dimension	No, multi-dimensional

When In Doubt

Case Study: E-Commerce User Classification

Let's apply our decision framework to a realistic e-commerce scenario, walking through the analysis step by step.

Scenario: An e-commerce platform needs to model users. Stakeholders have identified the following user categories:

Buyer: Users who purchase products
Seller: Users who list and sell products (marketplace model)
Affiliate: Users who earn commissions by referring buyers
Admin: Platform administrators with system access

Step 1: Classification Basis Analysis

Are these categories determined by a single discriminating attribute?

Step 2: 'Can It Be Both?' Test

Can a user be both Buyer AND Seller? Yes (common in marketplaces like Etsy, eBay)
Can a user be both Buyer AND Affiliate? Yes (buy products AND earn referral commissions)
Can a user be both Seller AND Admin? Yes (platform employee who also runs a shop)
Can a user be all four? Possible (though rare)

Verdict from this test: Overlapping

Step 3: Temporal Dynamics

Do users transition or accumulate?

A new user starts as Buyer (makes first purchase)
Later applies to become Seller (opens shop)—adds role, doesn't replace
Joins affiliate program—adds another role
Gets promoted to Admin—adds another role

This is accumulation, not transition. Confirms: Overlapping

Step 4: Business Rules

Are there any policies mandating exclusivity?

Legal: In some jurisdictions, admins might be prohibited from being sellers (conflict of interest). This could be a constraint but not a fundamental exclusivity—it's a business rule on top of an overlapping model.
General: No inherent exclusivity requirements.

No inherent disjointness. Overlapping, with possible subset constraints.

E-Commerce User Model
SQL Schema
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
-- Overlapping Specialization Implementation for E-Commerce Users
 
-- Superclass table
CREATE TABLE platform_user (
    user_id SERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    display_name VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    last_login_at TIMESTAMP
);
 
-- Buyer subclass (overlapping)
CREATE TABLE buyer (
    user_id INT PRIMARY KEY REFERENCES platform_user(user_id) ON DELETE CASCADE,
    shipping_address TEXT,
    preferred_payment_method VARCHAR(50),
    loyalty_points INT DEFAULT 0
);
 
-- Seller subclass (overlapping)
CREATE TABLE seller (
    user_id INT PRIMARY KEY REFERENCES platform_user(user_id) ON DELETE CASCADE,
    shop_name VARCHAR(100) NOT NULL,
    shop_description TEXT,
    commission_rate DECIMAL(5,2) DEFAULT 10.00,
    verified_at TIMESTAMP,
    payout_account VARCHAR(255)
);
 
-- Affiliate subclass (overlapping)
CREATE TABLE affiliate (
    user_id INT PRIMARY KEY REFERENCES platform_user(user_id) ON DELETE CASCADE,
    affiliate_code VARCHAR(20) UNIQUE NOT NULL,
    commission_percent DECIMAL(5,2) DEFAULT 5.00,
    payout_threshold DECIMAL(10,2) DEFAULT 50.00,
    approved_at TIMESTAMP
);
 
-- Admin subclass (overlapping)
CREATE TABLE platform_admin (
    user_id INT PRIMARY KEY REFERENCES platform_user(user_id) ON DELETE CASCADE,
    admin_level INT NOT NULL CHECK (admin_level BETWEEN 1 AND 5),
    permissions JSONB DEFAULT '{}',
    assigned_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
 
-- Optional: Business rule constraint (Admins cannot be Sellers)
CREATE OR REPLACE FUNCTION check_admin_seller_conflict()
RETURNS TRIGGER AS $$
BEGIN
    IF TG_TABLE_NAME = 'seller' THEN
        IF EXISTS (SELECT 1 FROM platform_admin WHERE user_id = NEW.user_id) THEN
            RAISE EXCEPTION 'Business rule violation: Admins cannot be Sellers';
        END IF;
    ELSIF TG_TABLE_NAME = 'platform_admin' THEN
        IF EXISTS (SELECT 1 FROM seller WHERE user_id = NEW.user_id) THEN
            RAISE EXCEPTION 'Business rule violation: Sellers cannot become Admins';
        END IF;
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;
 
CREATE TRIGGER enforce_admin_seller_conflict_on_seller
    BEFORE INSERT OR UPDATE ON seller FOR EACH ROW
    EXECUTE FUNCTION check_admin_seller_conflict();
    
CREATE TRIGGER enforce_admin_seller_conflict_on_admin
    BEFORE INSERT OR UPDATE ON platform_admin FOR EACH ROW
    EXECUTE FUNCTION check_admin_seller_conflict();

Case Study Outcome

Summary: Disjoint vs Overlapping Mastery

Core Concepts Mastered

•Disjoint Constraint (d): Subclasses are mutually exclusive. An entity belongs to at most one subclass. Formal: ∀i,j: Sᵢ ∩ Sⱼ = ∅.
•Overlapping Constraint (o): Subclasses are not mutually exclusive. An entity may belong to multiple subclasses simultaneously.
•Notation: 'd' or 'o' in Chen's circle; {disjoint} or {overlapping} in UML; varies across notations.
•Decision Framework: Analyze classification basis, apply 'Can It Be Both?' test, consider temporal dynamics, examine business rules.
•Disjoint Implementation: Single table with discriminator, or class table inheritance with triggers enforcing exclusivity.
•Overlapping Implementation: Flag columns, separate subclass tables allowing multiple memberships, or role junction tables.

Quick Reference: Disjoint vs Overlapping
Aspect	Disjoint (d)	Overlapping (o)
Meaning	Mutually exclusive subclasses	Non-exclusive subclasses
Entity Membership	At most one subclass	Zero to all subclasses
Real-World Analog	Type, state, category	Role, feature, tag
Discriminator	Single value determines subclass	Multiple independent flags
Constraint Enforcement	CHECK, triggers, single insert	No exclusivity needed
Default When Unsure	No—requires explicit analysis	Yes—more flexible choice

Page Complete