Tutorial 4

Entity-Relationship (ER) Modeling

1. What role does the ER diagram play in the design process?

A completed ER diagram is the actual blueprint of the database. Its composition must reflect an
organization's operations accurately if the database is to meet that organization's data requirements. It
forms the basis for a final check on whether the included entities are appropriate and sufficient, on the
attributes found within those entities, and on the relationships between those entities. It is also used as a
final crosscheck against the proposed data dictionary entries. The completed ER diagram also lets the
designer communicate more precisely with those who commissioned the database design. Finally, the
completed ER diagram serves as the implementation guide to those who create the actual database. In
short, the ER diagram is as important to the database designer as a blueprint is to the architect and
builder.

2. What two conditions must be met before an entity can be classified as a weak entity? Give an
example of a weak entity.

To be classified as a weak entity, two conditions must be met:

1. The entity must be existence-dependent on its parent entity.
2. The entity must inherit at least part of its primary key from its parent entity.

For example, the (strong) relationship depicted in the text’s Figure 4.9 shows a weak CLASS entity:
1. CLASS is clearly existence-dependent on COURSE. (You can’t have a database class unless a
database course exists.)
2. The CLASS entity’s PK is defined through the combination of CLASS_SECTION and
CRS_CODE. The CRS_CODE attribute is also the PK of COURSE.

The conditions that define a weak entity are the same as those for a strong relationship between an
entity and its parent. In short, the existence of a weak entity produces a strong relationship. And if
the entity is strong, its relationship to the other entity is weak. (Note the solid relationship line in the
text’s Figure 4.9.)

3. What is a strong (or identifying) relationship, and how is it depicted in a Crow’s Foot ERD?

A strong relationship exists when en entity is existence-dependent on another entity and inherits at
least part of its primary key from that entity. The Visio Professional software shows the strong
relationship as a solid line. In other words, a strong relationship exists when a weak entity is related
to its parent entity.
4. Given the business rule “an employee may have many degrees,” discuss its effect on
attributes, entities, and relationships. (Hint: Remember what a multivalued attribute is and
how it might be implemented.)

Suppose that an employee has the following degrees: BA, BS, and MBA. These degrees could be
stored in a single string as a multivalued attribute named EMP_DEGREE in an EMPLOYEE table
such as the one shown next:

EMP_NUM EMP_LNAME EMP_DEGREE

123 Carter AA, BBA
124 O’Shanski BBA, MBA, Ph.D.
125 Jones AS
126 Ortez BS, MS

Although the preceding solution has no obvious design flaws, it is likely to yield reporting
problems. For example, suppose you want to get a count for all employees who have BBA degrees.
You could, of course, do an “in-string” search to find all of the BBA values within the
EMP_DEGREE strings. But such a solution is cumbersome from a reporting point of view. Query
simplicity is a valuable thing to application developers – and to end users who like maximum query
execution speeds. Database designers ought to pay some attention to the competing database
interests that exist in the data environment.

One – very poor – solution is to create a field for each expected value. This “solution is shown next:

EMP_NUM EMP_LNAME EMP_DEGREE1 EMP_DEGREE EMP_DEGREE3

2
123 Carter AA BBA
124 O’Shanski BBA MBA Ph.D.
125 Jones AS
126 Ortez BS MS

This “solution yields nulls for all employees who have fewer than three degrees. And if even one
employee earns a fourth degree, the table structure must be altered to accommodate the new data
value. (One piece of evidence of poor design is the need to alter table structures in response to the
need to add data of an existing type.) In addition, the query simplicity is not enhanced by the fact
that any degree can be listed in any column. For example, a BA degree might be listed in the second
column, after an “associate of arts (AA) degree has been entered in EMP_DEGREE1. One might
simplify the query environment by creating a set of attributes that define the data entry, thus
producing the following results:

EMP_NUM EMP_LNAME EMP_AA EMP_AS EMP_BA EMP_BS EMP_BBA EMP_MS EMP_MBA EMP_PhD
123 Carter X X
124 O’Shanski X X X
125 Jones X
126 Ortez X X

This “solution” clearly proliferates the nulls at an ever-increasing pace.

 The only reasonable solution is to create a new DEGREE entity that stores each degree in a separate
record, this producing the following tables. (There is a 1:M relationship between EMPLOYEE and
DEGREE. Note that the EMP_NUM can occur more than once in the DEGREE table. The
DEGREE table’s PK is EMP_NUM + DEGREE_CODE. This solution also makes it possible to
record the date on which the degree was earned, the institution from which it was earned, and so on.

Table name: EMPLOYEE

EMP_NUM EMP_LNAME
123 Carter
124 O’Shanski
125 Jones
126 Ortez

Table name: DEGREE

EMP_NUM DEGREE_CODE DEGREE_DATE DEGREE_PLACE
123 AA May-1999 Lake Sumter CC
123 BBA Aug-2004 U. of Georgia
124 BBA Dec-1990 U. of Toledo
124 MBA May-2001 U. of Michigan
124 Ph.D. Dec-2005 U. of Tennessee
125 AS Aug-2002 Valdosta State
126 BS Dec-1989 U. of Missouri
126 MS May-2002 U. of Florida

Note that this solution leaves no nulls, produces a simple query environment, and makes it
unnecessary to alter the table structure when employees earn additional degrees. (You can make the
environment even more flexible by naming the new entity QUALIFICATION, thus making it
possible to store degrees, certifications, and other useful data that define an employee’s
qualifications.)

5. What is a composite entity, and when is it used?

A composite entity is generally used to transform M:N relationships into 1:M relationships. A
composite entity, also known as a bridge entity, is one that has a primary key composed of multiple
attributes. The PK attributes are inherited from the entities that it relates to one another.
6. Suppose you are working within the framework of the conceptual model in Figure 1.

Figure 1 The Conceptual Model

a. Write the business rules that are reflected in it.

Even a simple ERD such as the one shown in Figure Q4.5 is based on many business rules.
Make sure that each business rule is written on a separate line and that all of its details are
spelled out.

Given the ERD shown in Figure Q4.5, you can identify the following business rules:
1. A customer can own many cars.
2. Some customers do not own cars.
3. A car is owned by one and only one customer.
4. A car may generate one or more maintenance records.
5. Each maintenance record is generated by one and only one car.
6. Some cars have not (yet) generated a maintenance procedure.
7. Each maintenance procedure can use many parts.
(Comment: A maintenance procedure may include multiple maintenance actions,
each one of which may or may not use parts. For example, 10,000-mile check
may include the installation of a new oil filter and a new air filter. But tightening
an alternator belt does not require a part.)
8. A part may be used in many maintenance records.
(Comment: Each time an oil change is made, an oil filter is used. Therefore, many
oil filters may be used during some period of time. Naturally, you are not using
the same oil filter each time – but the part classified as “oil filter” shows up in
many maintenance records as time passes.)

Note that the apparent M:N relationship between MAINTENANCE and PART
has been resolved through the use of the composite entity named MAINT_LINE.
The MAINT_LINE entity ensures that the M:N relationship between
MAINTENANCE and PART has been broken up to produce the two 1:M
relationships shown in business rules 9 and 10.
 9. Each maintenance procedure generates one or more maintenance lines.
10. Each part may appear in many maintenance lines. (Review the comment in
business rule 8.)

As you review the business rules 9 and 10, use the following two tables to show some sample
data entries. For example, take a look at the (simplified) contents of the following
MAINTENANCE and LINE tables and note that the MAINT_NUM 10001 occurs three times
in the LINE table:

Sample MAINTENANCE Table Data

MAINT_NUM MAINT_DATE
10001 15-Mar-2018
10002 15-Mar-2018
10003 16-Mar-2018

Sample LINE Table Data

MAINT_NUM LINE_NUM LINE_DESCRIPTIO LINE_PART LINE_UNITS
N
10001 1 Replace fuel filter FF-015 1
10001 2 Replace air filter AF-1187 1
10001 3 Tighten alternator belt NA 0
10002 1 Replace taillight bulbs BU-2145 2
10003 1 Replace oil filter OF-2113 1
10003 2 Replace air filter AF-1187 1

b. Identify all of the cardinalities.

The Crow’s Foot ERD, shown in Figure Q4.5, does not show cardinalities directly. Instead, the
cardinalities are implied through the Crow’s Foot symbols. You might write the cardinality
(0,N) next to the MAINT_LINE entity in its relationship with the PART entity to indicate that a
part might occur “N” times in the maintenance line entity or that it might never show up in the
maintenance line entity. The latter case would occur if a given part has never been used in
maintenance.

7. What is a recursive relationship? Given an example.

A recursive relationship exists when an entity is related to itself. For example, a COURSE may be a
prerequisite to a COURSE. (See Section 4.1j in the text for additional examples.)

8. Discuss the difference between a composite key and a composite attribute. How would each be
indicated in an ERD?

A composite key is one that consists of more than one attribute. If the ER diagram contains the
attribute names for each of its entities, a composite key is indicated in the ER diagram by the fact
that more than one attribute name is underlined to indicate its participation in the primary key.
 A composite attribute is one that can be subdivided to yield meaningful attributes for each of its
components. For example, the composite attribute CUS_NAME can be subdivided to yield the
CUS_FNAME, CUS_INITIAL, and CUS_LNAME attributes. There is no ER convention that
enables us to indicate that an attribute is a composite attribute.

9. What two courses of action are available to a designer when encountering a multivalued
attribute?

The discussion that accompanies the answer to question 4 is valid as an answer to this question. For
additional insight see discussion in section 4-1b, in particular Figures 4.3, 4.4, 4.5 and, Table 4.1.

10. What is a derived attribute? Give an example.

A derived attribute is an attribute whose value is calculated (derived) from other attributes. The
derived attribute need not be physically stored within the database; instead, it can be derived by
using an algorithm. For example, an employee’s age, EMP_AGE, may be found by computing the
integer value of the difference between the current date and the EMP_DOB.

11. What three (often conflicting) database requirements must be addressed in database design?

Database design must reconcile the following requirements:

a. Design elegance requires that the design must adhere to design rules concerning nulls, derived
attributes, redundancies, relationship types, and so on.
b. Information requirements are dictated by the end users
c. Operational (transaction) speed requirements are also dictated by the end users.

Clearly, an elegant database design that fails to address end user information requirements or one
that forms the basis for an implementation whose use progresses at a snail's pace has little practical
use.

12. Briefly, but precisely, explain the difference between single-valued attributes and simple
attributes. Give an example of each.

A single -valued attribute is one that can have only one value. For example, a person has only one
first name and only one social security number.

A simple attribute is one that cannot be decomposed into its component pieces. For example, a
person's sex is classified as either M or F and there is no reasonable way to decompose M or F.
Similarly, a person's first name cannot be decomposed into meaningful components. (In contrast, if
a phone number includes the area code, it can be decomposed into the area code and the phone
number. And a person's name may be decomposed into a first name, an initial, and a last name.)

Single-valued attributes are not necessarily simple. For example, an inventory code
HWPRIJ23145 may refer to a classification scheme in which HW indicates Hardware, PR indicates
Printer, IJ indicates Inkjet, and 23145 indicates an inventory control number. Therefore,
 HWPRIJ23145 may be decomposed into its component parts... even though it is single-valued. To
facilitate product tracking, manufacturing serial codes must be single-valued, but they may not be
simple. For instance, the product serial number TNP5S2M231109154321 might be decomposed
this way:
TN = state = Tennessee
P5 = plant number 5
S2 = shift 2
M23 = machine 23
11 = month, i.e., November
09 = day
154321 = time on a 24-hour clock, i.e., 15:43:21, or 3:43 p.m. plus 21 seconds.

13. Create a complete ERD in Crow’s Foot notation that can be implemented in the relational
model using the following description of operations. Hot Water (HW) is a small start-up
company that sells spas. HW does not carry any stock. A few spas are set up in a simple
warehouse so customers can see some of the models available, but any products sold must be
ordered at the time of the sale.
 HW can get spas from several different manufacturers.
 Each manufacturer produces one or more different brands of spas.
 Each and every brand is produced by only one manufacturer.
 Every brand has one or more models.
 Every model is produced as part of a brand. For example, Iguana Bay Spas is a
manufacturer that produces Big Blue Iguana spas, a premium-level brand, and Lazy
Lizard spas, an entry-level brand. The Big Blue Iguana brand offers several models,
including the BBI-6, an 81-jet spa with two 6-hp motors, and the BBI-10, a 102-jet spa
with three 6-hp motors.
 Every manufacturer is identified by a manufacturer code. The company name,
address, area code, phone number, and account number are kept in the system for
every manufacturer.
 For each brand, the brand name and brand level (premium, mid-level, or entry-level)
are kept in the system.
 For each model, the model number, number of jets, number of motors, number of
horsepower per motor, suggested retail price, HW retail price, dry weight, water
capacity, and seating capacity must be kept in the system.

ERD Solution
14. Automata Inc. produces specialty vehicles by contract. The company operates several
departments, each of which builds a particular vehicle, such as a limousine, a truck, a van, or
an RV.

Before a new vehicle is built, the department places an order with the purchasing department
to request specific components. Automata’s purchasing department is interested in creating a
database to keep track of orders and to accelerate the process of delivering materials.

The order received by the purchasing department may contain several different items. An
inventory is maintained so that the most frequently requested items are delivered almost
immediately. When an order comes in, it is checked to determine whether the requested item
is in inventory. If an item is not in inventory, it must be ordered from a supplier. Each item
may have several suppliers.

Given that functional description of the processes encountered at Automata’s purchasing

department, do the following:
a. Identify all of the main entities.
b. Identify all of the relations and connectivities among entities.
c. Identify the type of existence dependency in all the relationships.
d. Give at least two examples of the types of reports that can be obtained from the
database.

The initial Crow’s Foot ERD is shown in Figure P4.6init. The discussion preceding Figure P4.6rev
explains why the revision was made.
Figure P4.6init Initial Automata Crow’s Foot ERD

As you explain the development of the Crow’s Foot ERD shown in Figure P4.6init, several points
are worth stressing:
 The ORDER and ORD_LINE entities are perfect reflections of the INVOICE and
INV_LINE entities the students have encountered before. This kind of 1:M relationship is
quite common in a business environment and you will see it recur throughout the book and
in its many problems. Note that the ORD_LINE entity is weak, because it inherits part of its
PK from its ORDER “parent” entity. Therefore, the “contains” relationship between
ORDER and ORD_LINE is properly shown as an identifying (strong) relationship. (The
relationship line is solid, rather than dashed.) Finally, note that ORD_LINE is mandatory to
ORDER; it is not possible to have an ORDER that does not contain at least one order line.
And, of course, ORDER is mandatory to ORD_LINE, because an ORD_LINE occurrence
cannot exist without referencing an ORDER.
 The ORDER entity is shown as optional to DEPARTMENT, indicating that it is quite
possible that a department has not (yet) placed an order. Aside from the fact that such an
optionality makes common sense, it also makes operational sense from a database point of
view. For example, if the ORDER entity were mandatory to the DEPARTMENT entity, the
creation of a new department would require the creation of an order, so you might have to
create a “dummy” order when you create a new department. Also, keep in mind that an
 order cannot be written by a department that does not (yet) exist.
 Note also that the VENDOR may not (yet) have received and order, so ORDER is optional
to VENDOR. The VENDOR entity may contain vendors who are simply potential suppliers
if items and you may want to have such potential vendors available just in case your “usual”
vendor(s) run(s) out of items that you need.

The other optionalities should be discussed, too – using the same basic scenarios that were
described in bullets 2 and 3.

NOTE
In this presentation, the relationship between VENDOR and ITEM is shown as 1:M.
Therefore, each vendor can supply many items, but only one vendor can supply each item.
If it is possible for items to be supplied by more than one vendor, there is a M:N
relationship between VENDOR and ITEM and this relationship would have to be
implemented through a composite (bridge) entity. Actually, such an M:N relationship is
specified in the brief description of the Automata company’s data environment. Therefore,
the following Figure P4.6rev more accurately reflects the problem description.

Figure P4.6rev Revised Automata Crow’s Foot ERD