Introduction
A university database may contain Room 101 in several buildings. The room number alone cannot identify a particular room; the database also needs its building. The same database may record a person who is both a student and an employee, sharing personal details while having different role-specific information.
Weak entities represent objects whose identification depends on another entity. Enhanced entity relationship modeling, or EER modeling, extends the ER model to describe concepts such as subclasses, inheritance, and rules governing subclass membership.
Understanding Weak Entities
A weak entity type cannot uniquely identify its entities using its own attributes alone. It depends on an owner entity, also called an identifying entity.
Suppose room numbers are unique within each building but can repeat across buildings. ROOM is then modeled as a weak entity owned by BUILDING.
The following illustration shows why identifying a room requires both values.
Identifying a Weak Entity
The complete identifier is BuildingID + RoomNo. RoomNo is the partial key, or discriminator: it distinguishes rooms belonging to the same building. The identifying relationship connects each room to its owner, and ROOM must participate in that relationship.
In this example, (B1, 101) and (B2, 101) identify different rooms even though their room numbers match.
Identifying Relationships and ER Notation
An identifying relationship contributes the owner’s identity to the identification of a weak entity. In the diagram above, CONTAINS connects BUILDING and ROOM.
In Chen notation:
Double rectangle: Represents the weak entity type, ROOM.
Double diamond: Represents the identifying relationship, CONTAINS.
Dashed underline: Marks the partial key, RoomNo.
Double connecting line: Shows total participation of ROOM in its identifying relationship. Every room must have an owner building.
An owner may have several weak entities. Under the stated rules, each room belongs to exactly one building, but a building may exist before any rooms are recorded.
Weak Entities and Ordinary Foreign Keys
Having a foreign key does not automatically make an entity weak. Consider an instructor identified by a globally unique InstructorID who must belong to a department. Department membership is compulsory, but the department’s identifier is not needed to identify the instructor.
For ROOM, the building’s identity is part of the room’s identification. Identification dependence is the essential distinction.
Specialization Generalization and Inheritance
The EER model adds richer structures to basic ER modeling. A central addition is the superclass–subclass relationship.
A superclass represents a general entity type. A subclass represents a more specific group of its entities. Each subclass entity is also the same entity in its superclass.
The following hierarchy shows two ways of developing that design.
Specialization and Generalization
Specialization
Specialization proceeds from general to specific. Starting with PERSON, the designer identifies STUDENT and EMPLOYEE as subclasses.
PERSON contains shared information such as PersonID and Name. STUDENT adds Program, while EMPLOYEE adds Salary.
Generalization
Generalization proceeds from specific to general. Starting with STUDENT and EMPLOYEE, the designer recognizes their shared characteristics and introduces PERSON as a superclass.
Both processes can produce the same hierarchy. They differ in the direction of design.
Inheritance
A subclass inherits the attributes and relationship participation of its superclass. It may also introduce its own attributes and relationships.
For example, a student inherits the person’s identity and name while participating in a student-specific ENROLLS_IN relationship. An employee can participate in WORKS_FOR.
A shared subclass can inherit from multiple superclasses. For example, TEACHING_ASSISTANT may be a subclass of both STUDENT and EMPLOYEE, representing people who satisfy both roles.
Constraints on Specialization
A hierarchy needs rules governing which entities can belong to its subclasses. Two independent choices define these rules.
The following set illustrations distinguish membership restrictions from coverage requirements.
Specialization Constraints
Disjoint and Overlapping Subclasses
Disjoint subclasses allow an entity to belong to at most one subclass within a specialization. For example, a university may classify each student as either undergraduate or postgraduate under a rule that prevents simultaneous membership.
Overlapping subclasses allow multiple memberships. A person may be both a student and an employee.
Total and Partial Specialization
Total specialization requires every superclass entity to belong to at least one of the specified subclasses.
Partial specialization permits superclass entities outside all specified subclasses. A university might record visitors as people without classifying them as students or employees.
These choices combine independently:
Combination | Permitted membership |
|---|---|
Disjoint and total | Exactly one subclass |
Disjoint and partial | Zero or one subclass |
Overlapping and total | One or more subclasses |
Overlapping and partial | Zero, one, or multiple subclasses |
Disjointness limits simultaneous membership; completeness determines whether membership is required.
Mapping the Model to Relational Tables
The conceptual model guides table design, but its rules must also be implemented.
Mapping a Weak Entity
For the building example:
Table | Attributes | Primary key |
|---|---|---|
BUILDING | BuildingID, BuildingName | BuildingID |
ROOM | BuildingID, RoomNo, Capacity | BuildingID and RoomNo together |
BuildingID in ROOM also acts as a foreign key referencing BUILDING.
This design permits Room 101 in different buildings while preventing two ROOM rows with the same building and room number. The conceptual identifying relationship does not itself prescribe automatic deletion; deletion behavior must be chosen explicitly.
Mapping a Superclass and Its Subclasses
One approach creates a table for the superclass and a separate table for each subclass.
Table | Attributes | Key relationship |
|---|---|---|
PERSON | PersonID, Name | PersonID is the primary key |
STUDENT | PersonID, Program | PersonID is both primary key and foreign key to PERSON |
EMPLOYEE | PersonID, Salary | PersonID is both primary key and foreign key to PERSON |
A person who studies and works appears in both subclass tables using the same PersonID. Shared details remain in PERSON.
Other mapping approaches combine the hierarchy into one table or store inherited attributes in subclass tables. The appropriate choice depends on the specialization rules and application requirements.
Constraint enforcement: Foreign keys from subclass tables ensure that their members exist in PERSON. They do not, by themselves, enforce disjointness or require every person to appear in a subclass. Those rules need additional enforcement.
Summary
Weak entities depend on an owner’s identity and a partial key for identification. EER modeling represents superclass–subclass structures through specialization, generalization, and inheritance. Disjointness controls simultaneous subclass membership, while completeness determines whether membership is required. Accurate table mapping must preserve these meanings and enforce the associated rules.
Be the first to add a comment.