ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

hapter 4

Specific Learning Outcomes

The students must have the ability to:

1. Create extended entity relationship (EER) model

2. Recognize when to use supertype/subtype relationships in data
modeling
3. Use both specialization and generalization as techniques for defining
supertype and subtype relationships.
4. Explain how entity clusters are used to represent multiple entities
and relationships
5. Know the characteristics of good primary keys and how to select them
6. Know how to use flexible solutions for special data-modeling
cases

Learning Content

1. The extended entity relationship (EER) model

2. Supertype and subtype relationships
3. Constraints in the supertype/subtype relationships
4. The characteristics of good primary keys and how to
select them
5. Flexible solutions for special data-modeling cases

INSTRUCTOR’S GUIDE 1
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

4.1 THE EXTENDED ENTITY RELATIONSHIP MODEL

Basic concepts of ER modeling are not sufficient to represent the requirement of

newer, more complex operation. To overcome the issue of ER modeling there is response
in development of additional ‘semantic’ modeling concept Semantic concept which is
integrated into original ER Model is known as Extended Entity Relation Relationship Model
(EER). As you might expect, a diagram using this model is called an EER diagram (EERD).
In the following sections, you will learn about the main EER model constructs—entity
supertypes, entity subtypes, and entity clustering—and see how they are represented in
ERDs.

4.1.1 Entity Supertypes and Subtypes

In some case, entity type has numerous sub-grouping of its entities because that
are meaningful way for representation and need to be explicitly defined because of their
importance. A subtype is a subgrouping of the entities in an entity type that is meaningful
to the organization. For example, STUDENT is an entity type in a university. Two subtypes
of STUDENT are GRADUATE STUDENT and UNDERGRADUATE STUDENT. In this example, we
refer to STUDENT as the supertype. A supertype is a generic entity type that has a
relationship with one or more subtypes. Entity supertype contains the common
characteristics, and the entity subtypes contain the unique characteristics of each entity
subtype.

There are two criteria that 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 have one or more attributes that
are unique to that kind or type of instance.

The notation that is used for supertype/subtype relationships in this text is shown in
Figure 4.1. The supertype is connected with a line to a circle, which in turn is connected
with a line to each subtype that has been defined. The U-shaped symbol on each line
connecting a subtype to the circle emphasizes that the subtype is a subset of the
supertype. It also indicates the direction of the subtype/supertype relationship. (This U is
optional because the meaning and direction of the supertype/subtype relationship is
usually obvious).

Figure 4.1. Basic notation of supertype/subtype relationships

INSTRUCTOR’S GUIDE 2
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Figure 4.2 shows the type of EER notation used by Microsoft Visio. Attributes that
are shared by all entities (including the identifier) are associated with the supertype.
Attributes that are unique to a particular subtype are associated with that subtype. The
same is true for relationships.

Figure 4.2. Microsoft Visio notation of a supertype and subtype entities

4.1.1.1 Example of a supertype/subtype relationship

Let us illustrate supertype/ subtype relationships with a simple yet common example.
Suppose that an organization has three basic types of employees: hourly employees,
salaried employees, and contract consultants. The following are some of the important
attributes for each of these types of employees:

 Hourly employees Employee Number, Employee Name, Address, Date Hired,

Hourly Rate
 Salaried employees Employee Number, Employee Name, Address, Date Hired,
Annual Salary, Stock Option
 Contract consultants Employee Number, Employee Name, Address, Date Hired,
Contract Number, Billing Rate

Notice that all of the employee types have several attributes in common: Employee
Number, Employee Name, Address, and Date Hired. In addition, each type has one or
more attributes distinct from the attributes of other types (e.g., Hourly Rate is unique to
hourly employees). If you were developing a conceptual data model in this situation, you
might consider three choices:

1. Define a single entity type called EMPLOYEE. Although conceptually simple, this
approach has the disadvantage that EMPLOYEE would have to contain all of the
attributes for the three types of employees. For an instance of an hourly employee (for
example), attributes such as Annual Salary and Contract Number would not apply
(optional attributes) and would be null or not used. When taken to a development
environment, programs that use this entity type would necessarily need to be quite
complex to deal with the many variations.

INSTRUCTOR’S GUIDE 3
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

2. Define a separate entity type for each of the three entities. This approach would fail to
exploit the common properties of employees, and users would have to be careful to
select the correct entity type when using the system.

3. Define a supertype called EMPLOYEE with subtypes HOURLY EMPLOYEE, SALARIED

EMPLOYEE, and CONSULTANT. This approach exploits the common properties of all
employees, yet it recognizes the distinct properties of each type. Figure 4.3 shows a
representation of the EMPLOYEE supertype with its three subtypes, using enhanced E-R
notation. Attributes shared by all employees are associated with the EMPLOYEE entity
type. Attributes that are peculiar to each subtype are included with that subtype only.

Figure 4.3. Employee supertype with three subtypes

4.1.1.2. Attribute Inheritance

A subtype is an entity type in its own right. An entity instance of a subtype

represents the same entity instance of the supertype. For example, if “Therese Jones” is
an occurrence of the CONSULTANT subtype, then this same person is necessarily an
occurrence of the EMPLOYEE supertype. As a consequence, an entity in a subtype must
possess not only values for its own attributes, but also values for its attributes as a member
of the supertype, including the identifier. Attribute inheritance is the property by which
subtype entities inherit values of all attributes and instance of all relationships of the
supertype.

This important property makes it unnecessary to include supertype attributes or

relationships redundantly with the subtypes (remember, when it comes to data modeling,
redundancy = bad, simplicity = good). For example, Employee Name is an attribute of
EMPLOYEE (Figure 4.3) but not of the subtypes of EMPLOYEE. Thus, the fact that the
employee’s name is “Therese Jones” is inherited from the EMPLOYEE supertype. However,
the Billing Rate for this same employee is an attribute of the subtype CONSULTANT. We
have established that a member of a subtype must be a member of the supertype. Is the
converse also true—that is, is a member of the supertype also a member of one (or more)
of the subtypes? This may or may not be true, depending on the business situation. (Sure,
“it depends” is the classic academic answer, but it’s true in this case.)

INSTRUCTOR’S GUIDE 4
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

4.1.1.3. When to Use Supertype/Subtype Relationships?

You should consider using subtypes when either (or both) of the following conditions are
present:
1. There are attributes that apply to some (but not all) instances of an entity type. For
example, see the EMPLOYEE entity type in Figure 4.3.
2. The instances of a subtype participate in a relationship unique to that subtype.

Figure 4.4 is an example of the use of subtype relationships that illustrates both of
these situations. The hospital entity type PATIENT has two subtypes: OUTPATIENT and
RESIDENT PATIENT. (The identifier is Patient ID.) All patients have an Admit Date attribute,
as well as a Patient Name. Also, every patient is cared for by a RESPONSIBLE PHYSICIAN
who develops a treatment plan for the patient.

Each subtype has an attribute that is unique to that subtype. Outpatients have
Checkback Date, whereas resident patients have Date Discharged. Also, resident
patients have a unique relationship that assigns each patient to a bed. (Notice that this
is a mandatory relationship; it would be optional if it were attached to PATIENT.) Each
bed may or may not be assigned to a patient. Earlier we discussed the property of
attribute inheritance. Thus, each outpatient and each resident patient inherits the
attributes of the parent supertype PATIENT: Patient ID, Patient Name, and Admit Date.
Figure 3-3 also illustrates the principle of relationship inheritance. OUTPATIENT and
RESIDENT PATIENT are also instances of PATIENT; therefore, each Is Cared For by a
RESPONSIBLE PHYSICIAN.

Figure 4.4. Supertype and subtype relationships in a hospital

4.1.2 Specialization and Generalization

You can use various approaches to develop entity supertypes and subtypes. For
example, you can first identify a regular entity, and then identify all entity subtypes based
on their distinguishing characteristics. You can also start by identifying multiple entity
types and then later extract the common characteristics of those entities to create a
higher-level supertype entity.

INSTRUCTOR’S GUIDE 5
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

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
unique characteristics and relationships of the subtypes. In the patient example, you used
specialization to identify multiple entity subtypes from the original PATIENT supertype.

An example of specialization is shown in Figure 4.5 and 4.6. Figure 4.5 shows an
entity type named PART, together with several of its attributes. The identifier is Part No,
and other attributes are Description, Unit Price, Location, Qty On Hand, Routing Number,
and Supplier. (The last attribute is multivalued and composite because there may be
more than one supplier with an associated unit price for a part.)
In discussions with users, we discover that there are two possible sources for parts:
Some are manufactured internally, whereas others are purchased from outside suppliers.
Further, we discover that some parts are obtained from both sources. In this case, the
choice depends on factors such as manufacturing capacity, unit price of the parts, and
so on.

Some of the attributes in Figure 4.5 apply to all parts, regardless of source.
However, others depend on the source. Thus, Routing Number applies only to
manufactured parts, whereas Supplier ID and Unit Price apply only to purchased parts.
These factors suggest that PART should be specialized by defining the subtypes
MANUFACTURED PART and PURCHASED PART (Figure 4.6).

Figure 4.5. Entity type PART

In Figure 4.6, Routing Number is associated with MANUFACTURED PART. The data
modeler initially planned to associate Supplier ID and Unit Price with PURCHASED PART.
However, in further discussions with users, the data modeler suggested instead that they
create a SUPPLIER entity type and an associative entity linking PURCHASED PART with
SUPPLIER. This associative entity (named SUPPLIES in Figure 4.6) allows users to more easily
associate purchased parts with their suppliers. Notice that the attribute Unit Price is now
associated with the associative entity so that the unit price for a part may vary from one
supplier to another. In this example, specialization has permitted a preferred
representation of the problem domain.

INSTRUCTOR’S GUIDE 6
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Figure 4.6. Specialization to MANUFACTURED PART

and PURCHASED PART

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
common characteristics and relationships of the subtypes.

An example of generalization is shown in Figure 4.7 and 4.8. In Figure 4.7, three
entity types have been defined: CAR, TRUCK, and MOTORCYCLE. At this stage, the data
modeler intends to represent these separately on an E-R diagram. However, on closer
examination, we see that the three entity types have a number of attributes in common:
Vehicle ID (identifier), Vehicle Name (with components Make and Model), Price,
and Engine Displacement. This fact (reinforced by the presence of a common identifier)
suggests that each of the three entity types is really a version of a more general entity
type.

This more general entity type (named VEHICLE) together with the resulting
supertype/subtype relationships is shown in Figure 4.8. The entity CAR has the specific
attribute No Of Passengers, whereas TRUCK has two specific attributes: Capacity and
Cab Type. Thus, generalization has allowed us to group entity types along with their
common attributes and at the same time preserve specific attributes that are peculiar to
each subtype.

Notice that the entity type MOTORCYCLE is not included in the relationship. It is
deliberately not included because it does not satisfy the conditions for a subtype
discussed earlier. Comparing Figure 4.7 and Figure 4.8, you will notice that the only
attributes of MOTORCYCLE are those that are common to all vehicles; there are no
attributes specific to motorcycles. Furthermore, MOTORCYCLE does not have a
relationship to another entity type. Thus, there is no need to create a MOTORCYCLE
subtype.

The fact that there is no MOTORCYCLE subtype suggests that it must be possible
to have an instance of VEHICLE that is not a member of any of its subtypes. We discuss
this type of constraint in the section on specifying constraints.

INSTRUCTOR’S GUIDE 7
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Figure 4.7. Three Entity Types – CAR, TRUCK and MOTORCYCLE

Figure 4.8. Generalization to VEHICLE supertype

4.2. CONSTRAINTS IN SUPERTYPE/SUBTYPE RELATIONSHIPS

This section introduces additional notation to represent constraints on

supertype/subtype relationships. These constraints allow us to capture some of the
important business rules that apply to these relationships. The two most important types
of constraints that are described in this section are completeness and disjointness
constraints (Elmasri and Navathe, 1994).

4.2.1. Total and Partial Completeness Constraints

The completeness constraint specifies whether each entity supertype occurrence

must also be a member of at least one subtype. The completeness constraint can be
partial or total. Partial completeness (symbolized by a single line) means that not every
supertype occurrence is a member of a subtype; that is, there may be some supertype
occurrences that are not members of any subtype.

Figure 4.9 as as an example, the business rule is: A patient must either be an
outpatient or a resident patient. In this example, every time a new instance of PATIENT is
inserted into the supertype, a corresponding instance is inserted into either OUTPATIENT
or RESIDENT PATIENT. If the instance is inserted into RESIDENT PATIENT, an instance of the
relationship Is Assigned is created to assign the patient to a hospital bed.

INSTRUCTOR’S GUIDE 8
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Total completeness (symbolized by a double line) means that every supertype

occurrence must be a member of at least one subtype. Figure 4.10 is an example

Figure 4.9. Partial Completeness Constraint

of Entity Type VEHICLE

employing the rules of total completeness. Recall the example in Figure 4.8, where
motorcycle is a type of vehicle, but it is not represented as a subtype in the data model.
Thus, if a vehicle is a car, it must appear as an instance of CAR, and if it is a truck, it must
appear as an instance of TRUCK. However, if the vehicle is a motorcycle, it cannot
appear as an instance of any subtype. This is an example of partial specialization, and it
is specified by the single line from the VEHICLE supertype to the circle.

Figure 4.10. Total Completeness Constraint of Entity Type PATIENT

INSTRUCTOR’S GUIDE 9
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

4.2.2. Disjoint and Overlapping Constraints

An entity supertype can have disjoint or overlapping entity subtypes. Disjoint

subtypes, also known as nonoverlapping subtypes, are subtypes that contain a unique
subset of the supertype entity set; in other words, each entity instance of the supertype
can appear in only one of the subtypes. For example, in Figure 4.11, at any given time, a
patient must be either an outpatient or a resident patient, but cannot be both. This is the
disjoint rule, as specified by the letter d in the circle joining the supertype and its subtypes.
Note in this figure, the subclass of a PATIENT may change over time, but at a given time,
a PATIENT is of only one type. (The Microsoft Visio notation does not have a way to
designate disjointness or overlap; however, you can place a d or an o inside the category
circle using the Text tool.)

Figure 4.11. Example of Disjoint Subtypes

Overlapping 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.

Look at Figure 4.12. In this example, an instance of PART is a particular part number
(i.e., a type of part), not an individual part (indicated by the identifier, which is Part No).
For example, consider part number 4000. At a given time, the quantity on hand for this
part might be 250, of which 100 are manufactured and the remaining 150 are purchased
parts. In this case, it is not important to keep track of individual parts. When tracking
individual parts is important, each part is assigned a serial number identifier, and the
quantity on hand is one or zero, depending on whether that individual part exists or not.

1
INSTRUCTOR’S GUIDE
0
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Figure 4.12. Example of Overlapping Subtypes

4.2.3. Subtype Discriminator

A subtype discriminator is the attribute in the supertype entity that determines to

which subtype the supertype occurrence is related.

An example of the use of a subtype discriminator is shown in Figure 4.13. Notice

that the following constraints have been added to this figure: total specialization and
disjoint subtypes. Thus, each employee must be either hourly, salaried, or a consultant. A
new attribute (Employee Type) has been added to the supertype EMPLOYEE to serve as
a subtype discriminator. When a new employee is added to the supertype, this attribute
is coded with one of three values, as follows: “H” (for Hourly), “S” (for Salaried), or “C” (for
Consultant). Depending on this code, the instance is then assigned to the appropriate
subtype. (An attribute of the supertype may be selected in the Microsoft Visio notation
as a discriminator, which is shown similarly next to the category symbol.)

The expression Employee Type= (which is the left side of a condition statement) is
placed next to the line leading from the supertype to the circle. The value of the attribute
that selects the appropriate subtype (in this example, either “H,” “S,” or “C”) is placed
adjacent to the line leading to that subtype. Thus, for example, the condition Employee
Type=“S” causes an entity instance to be inserted into the SALARIED EMPLOYEE subtype.

Figure 4.13. An Example using a Subtype Discriminator

1
INSTRUCTOR’S GUIDE
1
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

4.3. SPECIALIZATION HIERARCHY

Entity supertypes and subtypes are organized in a specialization hierarchy, which

depicts the arrangement of higher-level entity supertypes (parent entities) and lower-
level entity subtypes (child entities). Figure 4.14 shows a specialization hierarchy formed
by general entity type PERSON with attributes, SSN (identifier), Name, Address, Gender,
and Date Of Birth. Major subtypes of PERSON entity are: EMPLOYEE (persons who work
for the university), STUDENT(persons who attend classes), and ALUMNUS (persons who
have graduated).

Assuming that there are no other types of persons of interest to the university, the
total specialization(completeness) rule applies, as shown in the figure. A person might
belong to more than one subtype (e.g., ALUMNUS and EMPLOYEE), so the overlap rule is
used. Note that overlap allows for any overlap. (A PERSON may be simultaneously in any
pair or in all three subtypes.)

Attributes that apply specifically to each of these subtypes are shown in the figure.
Thus, each instance of EMPLOYEE has a value for Date Hired and Salary. Major Dept is an
attribute of STUDENT, and Degree (with components Year, Designation, and Date) is a
multivalued, composite attribute of ALUMNUS.

The next step is to evaluate whether any of the subtypes already defined qualify
for further specialization. In this example, EMPLOYEE is partitioned into two subtypes:
FACULTY and STAFF. FACULTY has the specific attribute Rank, whereas STAFF has the
specific attribute Position. Notice that in this example the subtype EMPLOYEE becomes a
supertype to FACULTY and STAFF. Because there may be types of employees other than
faculty and staff (such as student assistants), the partial specialization rule is indicated.
However, an employee cannot be both faculty and staff at the same time. Therefore,
the disjoint rule is indicated in the circle.

Two subtypes are also defined for STUDENT: GRADUATE STUDENT and UNDERGRAD
STUDENT. UNDERGRAD STUDENT has the attribute Class Standing, whereas GRADUATE
STUDENT has the attribute Test Score. Notice that total specialization and the disjoint rule
are specified; you should be able to state the business rules for these constraints.

1
INSTRUCTOR’S GUIDE
2
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Figure 4.14. Example of a Specialization Hierarchy

Notes to remember in the specialization hierarchy:

1. Attributes are assigned at the highest logical level that is possible in the
hierarchy. For example, because SSN (i.e., Social Security Number) applies to all
persons, it is assigned to the root entity PERSON. In contrast, Date Hired applies only
to employees, so it is assigned to EMPLOYEE. This approach ensures that attributes
can be shared by as many subtypes as possible.

2. Subtypes that are lower in the hierarchy inherit attributes not only from their
immediate supertype, but from all supertypes higher in the hierarchy, up to the
root. Thus, for example, an instance of faculty has values for all of the following
attributes: SSN, Name, Address, Gender, and Date Of Birth (from PERSON); Date
Hired and Salary (from EMPLOYEE); and Rank (from FACULTY).
4.4 ENTITY INTEGRITY: SELECTING PRIMARY KEYS

Arguably, the most important characteristic of an entity is its primary key (a single
attribute or some combination of attributes), which uniquely identifies each entity
instance. The primary key’s function is to guarantee entity integrity. Furthermore, primary
keys and foreign keys work together to implement relationships in the relational model.
Therefore, the importance of properly selecting the primary key has a direct bearing on
the efficiency and effectiveness of database implementation.

4.4.1. Primary Key Guidelines

A primary key is the attribute or combination of attributes that uniquely identifies

entity instances in an entity set. This section examines the practices in selecting a good
primary key.

First, you should understand the function of a primary key. The primary key’s main
function is to uniquely identify an entity instance or row within a table. In particular, given

1
INSTRUCTOR’S GUIDE
3
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

a primary key value—that is, the determinant—the relational model can determine the
value of all dependent attributes that “describe” the entity.

Second, primary keys and foreign keys are used to implement relationships among
entities. However, the implementation of such relationships is done mostly behind the
scenes, hidden from end users. Table 5.3 provides the desirable primary key
characteristics.

Table 4.1. Desirable Primary Key Characteristics

PK Characteristic Rationale
Unique values The PK must uniquely identify each entity instance. A
primary key must be able to guarantee unique values. It
cannot contain nulls.
Non-intelligent The PK should not have embedded semantic meaning other
than to uniquely identify each entity instance. An attribute
with embedded semantic meaning is probably better used as
a descriptive characteristic of the entity than as an identifier.
For example, a student ID of 650973 would be preferred over
Smith, Martha L. as a primary key identifier.
No change over time If an attribute has semantic meaning, it might be subject to
updates. This is why names do not make good primary keys.
If you have Vickie Smith as the primary key, what happens if
she changes her name when she gets married? If a primary
key is subject to change, the foreign key values must be
updated, thus adding to the database work load.
Furthermore, changing a primary key value means that you
are basically changing the identity of an entity. In short, the
PK should be permanent and unchangeable.
Preferably single-attribute A primary key should have the minimum number of attributes
possible (irreducible). Single-attribute primary keys are
desirable but not required. Single attribute primary keys
simplify the implementation of foreign keys. Having multiple-
attribute primary keys can cause primary keys of related
entities to grow through the possible addition of many
attributes, thus adding to the database work load and making
(application) coding more cumbersome.
Preferably numeric Unique values can be better managed when they are
numeric, because the database can use internal routines to
implement a counter-style attribute that automatically
increments values with the addition of each new row. In fact,
most database systems include the ability to use special
constructs, such as Autonumber in Microsoft Access, to
support self-incrementing primary key attributes.
Security-compliant The selected primary key must not be composed of any
attribute(s) that might be considered a security risk or
violation. For example, using a Social Security number as a
PK in an EMPLOYEE table is not a good idea.

4.4.2 When to Use Composite Primary Keys

Composite primary keys are particularly useful in two cases:

 As identifiers of composite entities, where each primary key combination is

allowed only once in the M:N relationship.
 As identifiers of weak entities, where the weak entity has a strong identifying
relationship with the parent entity.

1
INSTRUCTOR’S GUIDE
4
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

To illustrate the first case, assume that you have a STUDENT entity set and a CLASS
entity set. In addition, assume that those two sets are related in an M:N relationship via
an ENROLL entity set in which each student/class combination may appear only once in
the composite entity. Figure 4.15 shows the ERD to represent such a relationship.

As shown in Figure 4.15, the composite primary key automatically provides the
benefit of ensuring that there cannot be duplicate values—that is, it ensures that the
same student cannot enroll more than once in the same class.

In the second case, a weak entity in a strong identifying relationship with a parent
entity is normally used to represent one of two situations:

1. A real-world object that is existence-dependent on another real-world object.

Those types of objects are distinguishable in the real world. A dependent and an
employee are two separate people who exist independently of each other.
However, such objects can exist in the model only when they relate to each other
in a strong identifying relationship. For example, the relationship between
EMPLOYEE and DEPENDENT is one of existence dependency in which the primary
key of the dependent entity is a composite key that contains the key of the parent
entity.
2. A real-world object that is represented in the data model as two separate entities
in a strong identifying relationship. For example, the real-world invoice object is
represented by two entities in a data model: INVOICE and LINE. Clearly, the LINE
entity does not exist in the real world as an independent object, but rather as part
of an INVOICE.

In both situations, having a strong identifying relationship ensures that the

dependent entity can exist only when it is related to the parent entity. In summary, the
selection of a composite primary key for composite and weak entity types provides
benefits that enhance the integrity and consistency of the model.

Figure 4.15. The M:N relationship between STUDENT and CLASS

4.5 DESIGN CASES: LEARNING FLEXIBLE DATABASE DESIGN

1
INSTRUCTOR’S GUIDE
5
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Data modeling and database design require skills that are acquired through
experience. In turn, experience is acquired through practice—regular and frequent
repetition, applying the concepts learned to specific and different design problems. This
section presents four special design cases that highlight the importance of flexible
designs, proper identification of primary keys, and placement of foreign keys.

4.5.1 Design Case #1: Implementing 1:1 Relationships

Foreign keys work with primary keys to properly implement relationships in the
relational model. 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. However, 1:1
relationship is a different case. For example, a 1:1 relationship between EMPLOYEE and
DEPARTMENT based on the business rule “one EMPLOYEE is the manager of one
DEPARTMENT, and one DEPARTMENT is managed by one EMPLOYEE.” In that case, there
are two options for selecting and placing the foreign key:

1. Place a foreign key in both entities. 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, as it would create duplicated work, and it could
conflict with other existing relationships. (Remember that DEPARTMENT and
EMPLOYEE also participate in a 1:M relationship—one department employs many
employees.)

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 and the guide which primary key should be used as a foreign key is found
in Table 4.2. Table 5.5 shows the rationale for selecting the foreign key in a 1:1
relationship based on the relationship properties in the ERD.

Table 4.2 – Selection of Foreign Key in a 1:1 Relationship

CASE RELATIONSHIP ACTION

CONSTRAINT
One side is mandatory and the Place the PK of the entity on the mandatory side in the
other entity on the optional side as a FK, and make the FK
I side is optional. mandatory.
Both sides are optional. Select the FK that causes the fewest nulls, or place the
FK in the entity in which the (relationship) role is played.
II
Both sides are mandatory. See Case II, or consider revising your model to ensure
that the two entities do not belong together in a single
III entity.

Figure 4.16 illustrates the “EMPLOYEE manages DEPARTMENT” relationship. Note

that in this case, EMPLOYEE is mandatory to DEPARTMENT. Therefore, EMP_NUM is placed
as the foreign key in DEPARTMENT. Alternatively, you might also argue that the
“manager” role is played by the EMPLOYEE in the DEPARTMENT.

1
INSTRUCTOR’S GUIDE
6
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Figure 4.16. The 1:1 relationship between

DEPARTMENT and EMPLOYEE

As a designer, you must recognize that 1:1 relationships exist in the real world, and
therefore, they should be supported in the data model. In fact, a 1:1 relationship is used
to ensure that two entity sets are not placed in the same table. In other words, EMPLOYEE
and DEPARTMENT are clearly separate and unique entity types that do not belong
together in a single entity. If you grouped them together in one entity, what would be
the name of that entity?

4.5.2 Design Case #2: Maintaining History of Time-Variant Data

Normally, data changes are managed by replacing the existing attribute value
with the new value, without regard to the previous value. However, there are situations
in which the history of values for a given attribute must be preserved. From a data-
modeling point of view, time-variant data refer to data whose values change over time
and for which you must keep a history of the data changes.

Keeping the history of time-variant data is equivalent to having a multivalued

attribute in your entity. To model time-variant data, you must create a new entity in a 1:M
relationship with the original entity. This new entity will contain the new value, the date of
the change, and whatever other attribute is pertinent to the event being modeled. For
example, if you want to keep track of the current manager as well as the history of all
department managers, you can create the model shown in Figure 4.17.

Figure 4.17. Maintaining Manager History

1
INSTRUCTOR’S GUIDE
7
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Note that in Figure 4.17, the MGR_HIST entity has a 1:M relationship with EMPLOYEE
and a 1:M relationship with DEPARTMENT to reflect the fact that, over time, an employee
could be the manager of many different departments, and a department could have
many different employee managers. Because you are recording time-variant data, you
must store the DATE_ASSIGN attribute in the MGR_HIST entity to provide the date on which
the employee (EMP_NUM) became the manager of the department. The primary key of
MGR_HIST permits the same employee to be the manager of the same department, but
on different dates. If that scenario is not the case in your environment—if, for example,
an employee is the manager of a department only once—you could make DATE_ASSIGN
a nonprime attribute in the MGR_HIST entity.

4.5.3 Design Case #3: Fan Traps

Creating a data model requires proper identification of the data relationships

among entities. However, due to miscommunication or incomplete understanding of the
business rules or processes, it is not uncommon to misidentify relationships among entities.
Under those circumstances, the ERD may contain a design trap.
A 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. The most
common design trap is known as a fan trap.

A 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. For example, assume the JCB basketball league has many divisions. Each
division has many players, and each division has many teams. Given those “incomplete”
business rules, you might create an ERD that looks like the one in Figure 4.18.

As you can see in Figure 4.18, DIVISION is in a 1:M relationship with TEAM and in a
1:M relationship with PLAYER. Although that representation is semantically correct, the
relationships are not properly identified. For example, there is no way to identify which
players belong to which team. Figure 4.18 also shows a sample instance relationship
representation for the ERD. Note that the relationship lines for the DIVISION instances fan
out to the TEAM and PLAYER entity instances—thus the “fan trap” label.

Figure 4.19 shows the correct ERD after the fan trap has been eliminated. Note
that, in this case, DIVISION is in a 1:M relationship with TEAM. In turn, TEAM is in a 1:M
relationship with PLAYER. Figure 4.19 also shows the instance relationship representation
after eliminating the fan trap.

1
INSTRUCTOR’S GUIDE
8
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Figure 4.18 – Incorrect ERD with a fan trap problem

Given the design in Figure 4.19, note how easy it is to see which players play for
which team. However, to find out which players play in which division, you first need to
see what teams belong to each division; then you need to find out which players play
on each team. In other words, there is a transitive relationship between DIVISION and
PLAYER via the TEAM entity.

Figure 4.19 – Corrected ERD after removal of the fan trap

4.5.4 Design Case #4: Redundant Relationships

Redundant relationships occur when there are multiple relationship paths

between related entities. The main concern with redundant relationships is that they
remain consistent across the model. However, it’s important to note that some designs
use redundant relationships as a way to simplify the design.
An example of a redundant relationship is represented in Figure 4.20.

1
INSTRUCTOR’S GUIDE
9
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Figure 4.20. A redundant relationship

In Figure 4.20, note the transitive 1:M relationship between DIVISION and PLAYER
through the TEAM entity set. Therefore, the relationship that connects DIVISION and
PLAYER is, for all practical purposes, redundant. In that case, the relationship could be
safely deleted without losing any information-generation capabilities in the model.

2
INSTRUCTOR’S GUIDE
0
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Coronel, C. , Morris, S. and Rob, P. (2017) Database Systems: Design, Implementation

and Management 12th Edition

Hoffer, A. ,Ramesh V. and Topi, H. (2016) Modern Database Management 12th Edition:
Design, Implementation and Management

Ross, R. G. 1997. The Business Rule Book. Version 4. Boston: Business Rule Solutions,
Inc.

University of MichiganL Scott Moore’s “Advanced Topics in ER Modelling”.

https://learn.saylor.org/mod/page/view.php?id=21071

Moriarty, T. “Using Scenarios in Information Modeling: Bringing Business Rules to Life.”

Database Programming & Design 6, 8 (August): 65–67.

Courtney, J. and Paradise, D. (2010).Database Management Systems for Management

A Silberschatz, H Korth, S Sudarshan, “Database System and Concepts”, fifth Edition

McGraw-Hill ,

A Silberschatz, H Korth, S Sudarshan, “Database System and Concepts”, fifth Edition

McGraw-Hill ,

Elmasri, R. and Navathe, S.(2003) Fundamentals of Database Systems 4th Edition

Application Development Trends 4,3 (March): 36–54. GUIDE. 1997 (October). “GUIDE
Business Rules Project.” Final Report, revision 1.2.

Hay, D. C. 1996. Data Model Patterns: Conventions of Thought. New York: Dorset House
Publishing. Hoberman, S. 2006. “Industry Logical Data Models.” Teradata Magazine. Available
at www.teradata.com.

Scott Moore, “How to Design, Think about and Use Databases - Advanced Topics in ER
Modeling”. http://db4u.wikidot.com/eradvanced

Alternative Notations in Other Modeling Languages. Gerard Nico's "Data Modeling:

Entity-Relationship (E-R)" https://gerardnico.com/data/modeling/entity_relationship

2
INSTRUCTOR’S GUIDE
1
 ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

https://drive.google.com/file/d/1GbN7wHfvyZW070ttaKzndpJ2FMIEQoMM/view?usp=sharing

https://drive.google.com/file/d/1GbN7wHfvyZW070ttaKzndpJ2FMIEQoMM/view?usp=sharing
Lakshmi S' "The Enhanced Entity-Relationship Model". https://youtu.be/Y4w-
jcmBZKk

2
INSTRUCTOR’S GUIDE
2
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

Answer the following review questions.

1. Under what circumstances are composite primary keys appropriate?

2. When implementing a 1:1 relationship, where should you place the foreign key if
one side is mandatory and one side is optional? Should the foreign key be
mandatory or optional?

3. Construct an E-R diagram for a car insurance company whose customers own one
or more cars each. Each car has associated with it zero to any number of
recorded accidents. Each insurance policy covers one or more cars, and has one
or more premium payments associated with it. Each payment is for a particular
period of time, and has an associated due date, and the date when the payment
was received.

4. Referring to the product data model in Figure E3.1, answer the following:

a. Is it required that every entity instance in the PRODUCT table be associated

with an entity instance in the CD table? Why, or why not?
a. Is it possible for a book to appear in the BOOK table without appearing in the
PRODUCT table? Why, or why not?

Figure E3.1 – Product Data Model

5. Consider a database used to record the marks that students get in different
exams of different course offerings (sections).

a. Construct an E-R diagram that models exams as entities, and uses a ternary
relationship, for the database.

b. Construct an alternative E-R diagram that uses only a binary relationship

between student and section. Make sure that only one relationship exists

2
INSTRUCTOR’S GUIDE
3
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

between a particular student and section pair, yet you can represent the
marks that a student gets in different exams.

6. Given the following business scenario, create a Crow’s Foot ERD using a
specialization hierarchy if appropriate.

Tiny Hospital keeps information on patients and hospital rooms. The system assigns
each patient a patient ID number. In addition, the patient’s name and date of
birth are recorded. Some patients are resident patients who spend at least one
night in the hospital, and others are outpatients who are treated and released.
Resident patients are assigned to a room. Each room is identified by a room
number. The system also stores the room type (private or semiprivate) and room
fee. Over time, each room will have many patients. Each resident patient will stay
in only one room. Every room must have had a patient, and every resident patient
must have a room.

2
INSTRUCTOR’S GUIDE
4
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

2
INSTRUCTOR’S GUIDE
5
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

2
INSTRUCTOR’S GUIDE
6
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

2
INSTRUCTOR’S GUIDE
7
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________

2
INSTRUCTOR’S GUIDE
8
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

_______________________________________
_______________________________________

_______________________________________

_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________

2
INSTRUCTOR’S GUIDE
9
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________

_______________________________________

_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________

3
INSTRUCTOR’S GUIDE
0
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________

_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________

3
INSTRUCTOR’S GUIDE
1
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________

_______________________________________

_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________

3
INSTRUCTOR’S GUIDE
2
ADVANCED DATA MODELING INFORMATION MANAGEMENT 1

_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________
_______________________________________

3
INSTRUCTOR’S GUIDE
3