extended entity relationship model (EERM)

- A.k.a enhanced entity relationship model

- the result of adding more semantic constructs such as entity supertypes, entity subtypes, and
entity clustering, to the original entity relationship (ER) model

entity supertype

- In a generalization or specialization hierarchy, a generic entity type that contains the common
characteristics of entity subtypes

entity subtype

- In a generalization or specialization hierarchy, a subset of an entity supertype.

- The entity supertype contains the common characteristics and the subtypes contain the unique
characteristics of each entity
- Example
o . For instance, a retail company could group employees as salaried and hourly, while a
university could group employees as faculty, staff, and administrators.

The grouping of employees into various types provides two important benefits:
• It avoids unnecessary nulls in attributes when some employees have characteristics
that are not shared by other employees.
• It enables a particular employee type to participate in relationships that are unique to
that employee type.
Two criteria help the designer determine when to use subtypes and supertypes:

• There must be different, identifiable kinds or types of the entity in the user’s environment.

• The different kinds or types of instances should each have one or more attributes that are unique to
that kind or type of instance.

specialization hierarchy

- Were Entity supertypes and subtypes are organized

- which depicts the arrangement of higher-level entity supertypes (parent entities) and lower-
level entity subtypes (child entities)
Note:

1. the specialization hierarchy formed by an EMPLOYEE super type and three entity subtypes—
PILOT, MECHANIC, and ACCOUNTANT

2. The specialization hierarchy reflects the 1:1 relationship between EMPLOYEE and its subtypes
- a PILOT subtype occurrence is related to one instance of the EMPLOYEE supertype, and a
MECHANIC subtype occurrence is related to one instance of the EMPLOYEE supertype.

3. The relationships depicted within the specialization hierarchy are sometimes described in terms
of “is-a” relationships.
- a pilot is an employee
- a mechanic is an employee
- an accountant is an employee

4. every subtype can have only one supertype to which it is directly related. However, a
specialization hierarchy can have many levels of supertype or subtype relationship
 5. Specialization hierarchies enable the data model to capture additional semantic content
(meaning) into the ERD. A specialization hierarchy provides the means to:
• Support attribute inheritance.
• Define a special supertype attribute known as the subtype discriminator.
• Define disjoint or overlapping constraints and complete or partial constraints.

Inheritance

- enables an entity subtype to inherit the attributes and relationships of the supertype.
- a supertype contains attributes that are common to all of its subtypes
- subtypes contain only the attributes that are unique to the subtype.

Note: (Figure 5.2)

1. illustrates that pilots, mechanics, and accountants all inherit the employee number, last name,
first name, middle initial, and hire date from the EMPLOYEE entity
2. illustrates that pilots have unique attributes; the same is true for mechanics and accountants
3. One important inheritance characteristic is that all entity sub types inherit their primary key
attribute from their supertype which is that the EMP_NUM attribute is the primary key for each
of the subtypes.

Note:

1. At the implementation level, the supertype and its subtype(s) depicted in the specialization
hierarchy maintain a 1:1 relationship.
- For example, the specialization hierarchy lets you replace the undesirable EMPLOYEE table
structure in Figure 5.1 with two tables—one representing the supertype EMPLOYEE and the
other representing the subtype PILOT. (5.2)
 2. Entity subtypes inherit all relationships in which the supertype entity participates.
- For example, Figure 5.2 shows the EMPLOYEE entity supertype participating in a 1:M
relationship with a DEPENDENT entity.
- Through inheritance, all subtypes also participate in that relationship.
- In specialization hierarchies with multiple levels of supertype and subtypes, a lower-level
subtype inherits all of the attributes and relationships from all of its upper-level supertypes.

subtype discriminator

- is the attribute in the supertype entity that determines to which subtype the supertype
occurrence is related.

Note:

1. It is common practice to show the subtype discriminator and its value for each subtype in the
ERD
2. the subtype discriminator is the employee type (EMP_TYPE).
3. a text tool was used to manually add the discriminator value above the entity subtype, close to
the connector line
 4. , note that the supertype is related to a PILOT subtype if the EMP_TYPE has a value of “P.” If the
EMP_TYPE value is “M,” the supertype is related to a MECHANIC subtype. If the EMP_TYPE value
is “A,” the supertype is related to the ACCOUNTANT subtype.

Disjoint subtypes

- also known as nonoverlapping subtypes

- are subtypes that contain a unique subset of the supertype entity set
- each entity instance of the supertype can appear in only one of the subtypes.
- , such disjoint subtypes are indicated by the letter d inside the category symbol.
- Example:
o , an employee (supertype) who is a pilot (subtype) can appear only in the PILOT subtype,
not in any of the other subtypes.

Overlapping subtypes

- if the business rule specifies that employees can have multiple classifications, the EMPLOYEE
supertype may contain overlapping job classification subtypes
- are subtypes that contain nonunique subsets of the supertype entity set; that is, each entity
instance of the supertype may appear in more than one subtype
- Example:
o , a person may be an employee, a student, or both. In turn, an employee may be a
professor as well as an administrator. Because an employee may also be a student,
STUDENT and EMPLOYEE are overlapping subtypes of the supertype PERSON, just as
PROFESSOR and ADMINISTRATOR are overlapping subtypes of the supertype EMPLOYEE
Note:

1. overlapping subtypes with the letter o inside the category symbol

Note:

1. There are attributes that apply to volunteers that do not apply to paid staff, so VOLUNTEER is a
valid subtype
2. There are attributes that apply to paid staff that do not apply to volunteers, so STAFF is also a
valid subtype
3. . A single member of the organization cannot be both a volunteer and paid staff, so those
subtypes are disjoint.

Another Note:

1. a website that provides data about popular children’s stories and tracks stories that appear in
movies and books.
2. Stories in movies have attributes that stories in books do not have, such as a rating and sound
type.
 3. Stories in books have attributes that do not apply to movies, such as the number of chapters and
pages.
4. MOVIE and BOOK are valid subtypes because each is an identifiable kind of story, and each has
attributes that do not apply to the other kind of story
5. these subtypes are overlapping because it is possible for a story to appear as both a book and a
movie.
6. In this case, notice the use of two subtype discriminator attributes (Story_Is_Movie and
Story_Is_Book) to indicate if the supertype instance has a matching entity subtype.

completeness constraint

- specifies whether each entity supertype occurrence must also be a member of at least one
subtype
- Kinds:
o Partial completeness
 s that not every supertype occurrence is a member of a subtype; some
supertype occurrences may not be members of any subtype
o Total completeness
 means that every supertype occurrence must be a member of at least one
subtype.

Specialization

- is the top-down process of identifying lower-level, more specific entity subtypes from a higher-
level entity supertype.
- Specialization is based on grouping the unique characteristics and relationships of the subtypes.
In the aviation
- Example
o you used specializa tion to identify multiple entity subtypes from the original employee
supertype
Generalization

- is the bottom-up process of identifying a higher-level, more generic entity supertype from
lower-level entity subtypes.
- Generalization is based on grouping the common characteristics and relationships of the
subtypes.
- For example
o you might identify multiple types of musical instruments: piano, violin, and guitar.
o Using the generalization approach, you could identify a “string instrument” entity
supertype to hold the common characteristics of the multiple subtypes

entity cluster

- a “virtual” entity type used to represent multiple entities and relation ships in the ERD.
- formed by combining multiple interrelated entities into a single, abstract entity object.
- An entity cluster is considered “virtual” or “abstract” in the sense that it is not actually an entity
in the final ERD. Instead, it is a “conceptual” entity used to represent multiple entities and
relationships, with the purpose of simplifying the ERD and thus enhancing its readability.
-

- Note
1. OFFERING, which groups the SEMESTER, COURSE, and CLASS entities and relationships
2. OFFERING, which groups the SEMESTER, COURSE, and CLASS entities and relationships
3. Figure 5.6 does not show attributes for the entities.
4. , the key attributes of the combined entities are no longer available. Without the key
attributes, primary key inheritance rules change
surrogate key

- a primary key created by the database designer to simplify the identification of entity instances
- has no meaning in the user’s environment—it exists only to distinguish one entity instance from
another
- One practical advantage of a surrogate key is that because it has no intrinsic meaning, values for
it can be generated by the DBMS to ensure that unique values are always provided.
 -

Note:

1. case of a park recreation facility that rents rooms for small parties
2. The manager of the facility keeps track of all events, using a folder with the format
3. Assume you select the composite primary key (DATE, TIME_START, ROOM) for the EVENT entity
4. the same RESOURCE may be used for many EVENTs. The RESOURCE entity would be represented
by the following attributes: RESOURCE (RSC_ID, RSC_DESCRIPTION, RSC_TYPE, RSC_QTY,
RSC_PRICE)
5. the M:N relationship between RESOURCE and EVENT would be represented via the EVNTRSC
composite entity with a composite primary key as follows: EVNTRSC (DATE, TIME_START,
ROOM, RSC_ID, QTY_USED)
6. At this point, you can see that the composite primary key could make the database
implementation and program coding unnecessarily complex.
7. if you use a surrogate key, you must ensure that the candidate key of the entity in question
performs properly through the use of “unique index” and “not null” constraints. In the above
example, you would create a unique index on (DATE, TIME_START, ROOM, RSC_ID).
Design Case

1. Design Case 1: Implementing 1:1 Relationships

Note:
a. The basic rule is very simple: put the primary key of the “one” side (the parent entity) on the
“many” side (the dependent entity) as a foreign key

In that case, there are two options for selecting and placing the foreign key:

1. Place a foreign key in both entities.

- This option is derived from the basic rule you learned in Chapter 4. Place EMP_NUM as a
foreign key in DEPARTMENT, and place DEPT_ID as a foreign key in EMPLOYEE. However, this
solution is not recommended because it duplicates work, and it could conflict with other existing
relationships.

2. Place a foreign key in one of the entities.

- In that case, the primary key of one of the two entities appears as a foreign key in the other
entity. That is the preferred solution, but a question remains: which primary key should be used
as a foreign key? The answer is found in Table 5.5, which shows the rationale for selecting the
foreign key in a 1:1 relationship based on the relationship properties in the ERD.
Note:

1. a 1:1 relationship is used to ensure that two entity sets are not placed in the same table.
2. Design Case 2: Maintaining History of Time-Variant Data

time-variant data

- refers to data whose values change over time and for which you must keep a history of the data
changes.

Note:

1. EMP_SALARY attribute becomes multivalued, as shown in Figure 5.9. In this case, for each
employee, there will be one or more records in the SALARY_HIST entity, which stores the salary
amount and the date when the new salary goes into effect.
Design Case 3: Fan Traps

design trap

- occurs when a relationship is improperly or incompletely identified and is, therefore,

represented in a way that is not consistent with the real world.
- e most common design trap is known as a fan trap

fan trap

- occurs when you have one entity in two 1:M relationships to other entities, thus producing an
association among the other entities that is not expressed in the model

Note:

1.