Web-DSS-Chapter-03
Web-DSS-Chapter-03
Web-DSS-Chapter-03
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
56 CHAPTER 3 ■ Entity-Relationship Modeling<br />
result, researchers in the ’80s enhanced the original E-R model to form the enhanced entityrelationship<br />
(EE-R) model.<br />
In the remaining sections of this chapter, we will discuss the EE-R model by detailing superclass<br />
and subclass entities, the processes of specialization and generalization, and various<br />
constraints on these processes.<br />
3.15 Superclass, Subclass, and Relationships<br />
Recall that we have defined an entity type as a collection of entities that share the same attributes.<br />
In this section, we will introduce two special types of entities: superclass and subclass. We will<br />
also discuss the notations that allow us to include these special entities in a regular E-R diagram<br />
to create an enhanced entity-relationship (EE-R) diagram. We will also study superclass and<br />
subclass relationships as well as the process of attribute inheritance associated with superclass<br />
and subclass entity types.<br />
3.15.1 Superclass and Subclass<br />
All the instances of an entity type share the same set of attributes, but each single attribute may not<br />
be a required attribute of for each instance. For example, consider the PERSON entity type. The<br />
entity PERSON includes all personnel in a university. Specifically, it includes students, staff, and<br />
faculty members. The attributes of this entity, SSN, Address, Email, Salary, Class, GPA, and Office<br />
Phone are depicted in Figure 3.21. Although all these attributes are common to the PERSON entity,<br />
attributes such as Class and GPA are not required for faculty instances of PERSON. At the<br />
same time, the attribute Salary is required for staff and faculty but may not be relevant for students.<br />
This distinction is important when we have a large number of instances for an entity type. In<br />
such a scenario, one or more attributes for each instance won’t have any valid value. In our example,<br />
each faculty instance will have no valid value for GPA and Class, and many student instances<br />
won’t have value for Salary, Rank, and Designation. As we will see in <strong>Chapter</strong> 4, having many redundant<br />
fields results in a data redundancy problem and degrades the database performance.<br />
BirthDate<br />
SSN<br />
Email<br />
Office Phone<br />
Address<br />
Name<br />
GPA<br />
Rank<br />
Class<br />
Salary<br />
Designation<br />
PERSON<br />
Figure 3.21 The E-R diagram for entity type PERSON.