Chapter 3 The Relational Database Model
Chapter 3
The Relational Database Model
Discussion Focus
Why is most of this book based on the relational database model? The answer to that question is, quite
simply, that the relational database model has a very successful track record and it is the dominant
database model in the market.
But why has the relational database model (RDM) been so successful? The Object Oriented database
model (OODM) seemed to be poised to dislodge the RDM in the face of increasingly complex data that
included video and audio … yet the OODM fell short in the database arena. However, the OODM’s
basic concepts have become the basis of a wide variety of database systems analysis and design
procedures. In addition, the basic OO approach has been adopted by many application generators and
other development tools.
The OODM’s inability to replace the RDM is due to several factors. First, the large installed base of
RDM-based databases is difficult to overcome. Change is often difficult and expensive, so the prime
requisite for change is an overwhelming advantage of the change agent. The OODM advantages were
simply not accepted as overwhelming and were, therefore, not accepted as cost-effective. Second,
compared to the RDM, the OODM’s design, implementation, and management learning curves are much
steeper than the RDM’s. Third, the RDM preempted the OODM in some important respects by adopting
many of the OODM’s best features, thus becoming the extended relational data model (ERDM).
Because the ERDM retains the basic modeling simplicity of the RDM while being able to handle the
complex data environment that was supposed to be the OODM’s forte, you can have the proverbial cake
and eat it, too.
The OODM-ERDM battle for dominance in the database marketplace seems remarkably similar to the
one waged by the hierarchical and network models against the relational model almost three decades
ago. The OODM and ERDM are similar in the sense that each attempts to address the demand for more
semantic information to be incorporated into the model. However, the OODM and the ERDM differ
substantially both in underlying philosophy and in the nature of the problem to be addressed. Although
the ERDM includes a strong semantic component, it is primarily based on the relational data model’s
concepts. In contrast, the OODM is wholly based on the OO and semantic data model concepts. The
ERDM is primarily geared to business applications, while the OODM tends to focus on very specialized
engineering and scientific applications. In the database arena, the most likely scenario appears to be an
ever-increasing merging of OO and relational data model concepts and procedures.
Although the ERDM label has frequently been used in the database literature to describe the -- quite
successful -- relational data model’s response to the OODM challenge, C. J. Date objects to the ERDM
label for the following reasons (set forth in “Back to the Relational Future”
www.dbpd.com/vault/9808date.html):
 The useful contribution of the object model is its ability to let users define their own -- and often very
complex -- data types. However, mathematical structures known as “domains” in the relational model
49
Chapter 3 The Relational Database Model

also provide this ability. Therefore, a relational DBMS that properly supports such domains greatly
diminishes the reason for using the object model. Given proper support for domains, relational data
models are quite capable of handling the complex data encountered in time series, engineering design,
office automation, financial modeling, and so on. Because the relational model can support complex
data types, the notion of an “extended relational data model” or ERDM is “extremely inappropriate
and inaccurate” and “it should be firmly resisted.” (The capability that is supposedly being extended is
already there!)
Even the label object/relational data model (O/RDM) is not quite accurate, because the relational
data model’s domain is not an object model structure. However, there are already quite a few
O/R products -- also known as universal database servers -- on the market. Therefore, Date
concedes that we are probably stuck with the O/R label. In fact, Date believes that “an O/R
system is in everyone’s future.” More precisely, Date argues that a true O/R system would be
“nothing more nor less than a true relational system -- which is to say, a system that supports the
relational model, with all that such support entails.”
C. J. Date concludes his discussion by observing that “We need do nothing to the relational model to
achieve object functionality. (Nothing, that is, except implement it, something that doesn’t yet seem to
have been tried in the commercial world.)”
Because C. J. Date is generally considered to be one of the world’s leading database thinkers and
innovators, his observations cannot be easily dismissed. In any case, regardless of the label that is used
to tag the relational data model’s growing capabilities, it seems clear that the relational data model is
likely to maintain its database market dominance for some time. We believe, therefore, that our
continued emphasis on the relational data model is appropriate.
50
Chapter 3 The Relational Database Model
Answers to Review Questions
ONLINE CONTENT
Answers to selected Review Questions and Problems for this chapter are contained in the
Student Online Companion for this book. The Student Online Companion also includes SQL
script files (Oracle and SQLServer) for all of the data sets used throughout the book.
1. What is the difference between a database and a table?
A table, a logical structure that represents an entity set, is only one of the components of a database.
The database is a structure that houses one or more tables and metadata. The metadata are data about
data. Metadata include the data (attribute) characteristics and the relationships between the entity
sets.
2. What does it mean to say that a database displays both entity integrity and referential
integrity?
Entity integrity describes a condition in which all tuples within a table are uniquely identified by
their primary key. The unique value requirement prohibits a null primary key value, because nulls
are not unique.
Referential integrity describes a condition in which a foreign key value has a match in the
corresponding table or in which the foreign key value is null. The null foreign key “value” makes it
possible not to have a corresponding value, but the matching requirement on values that are not null
makes it impossible to have an invalid value.
3. Why are entity integrity and referential integrity important in a database?
Entity integrity and referential integrity are important because they are the basis for expressing and
implementing relationships in the entity relationship model. Entity integrity ensures that each row is
uniquely identified by the primary key. Therefore, entity integrity means that a proper search for an
existing tuple (row) will always be successful. (And the failure to find a match on a row search will
always mean that the row for which the search is conducted does not exist in that table.) Referential
integrity means that, if the foreign key contains a value, that value refers to an existing valid tuple
(row) in another relation. Therefore, referential integrity ensures that it will be impossible to assign a
non-existing foreign key value to a table.
51
Chapter 3 The Relational Database Model
4. A database user manual notes that, “The file contains two hundred records, each record
containing nine fields.” Use appropriate relational database terminology to “translate” that
statement.
Using the proper relational terminology, the statement may be translated to "the table -- or entity set
-- contains two hundred rows -- or, if you like, two hundred tuples, or entities. Each of these rows
contains nine attributes."
5. Use the small database shown in Figure Q3.5 to illustrate the difference between a natural join,
an equijoin, and an outer join.
FIGURE Q3.5 The Ch03_CollegeQue Database Tables
52
Chapter 3 The Relational Database Model
ONLINE CONTENT
All of the databases used in the questions and problems are found on the Student
Companion Web site for this book. The database names used in the folder match the
database names used in the figures. For example, the source of the tables shown in Figure
Q3.5 is the Ch03_CollegeQue database. The Student Online Companion also includes SQL
script files (Oracle and SQLServer) for all of the data sets used throughout the book.
The natural JOIN process begins with the PRODUCT of the two tables:
STU_CODE
100278
128569
512272
531235
531268
553427
100278
128569
512272
531235
531268
553427
100278
128569
512272
531235
531268
553427
100278
128569
512272
531235
531268
553427
PROF_CODE
2
4
2
1
2
4
2
1
2
4
2
1
2
4
2
1
PROF_CODE
1
1
1
1
1
1
2
2
2
2
2
2
3
3
3
3
3
3
4
4
4
4
4
4
DEPT_CODE
2
2
2
2
2
2
6
6
6
6
6
6
6
6
6
6
6
6
4
4
4
4
4
4
Next, a SELECT is performed on the PRODUCT generated in the first step to yield only the rows
for which the PROF_CODE values in the STUDENT table are matched in the PROF table. Because
only the STUDENT table’s PROF_CODE values 1, 2, and 4 yield matches in the PROFESSOR
table, the SELECT yields the following output:
53
Chapter 3 The Relational Database Model
STU_CODE
128569
512272
531235
553427
PROF_CODE
2
4
2
1
PROF_CODE
2
4
2
1
DEPT_CODE
6
4
6
2
Finally, a PROJECT is performed to produce the natural JOIN output by listing only a single copy of
each attribute. The order in which the query output rows are shown is not relevant. If the output is to
be listed by having the STU_CODE values in ascending order, this result can be generated through
an “order by” specification in the query – remind the students that they can learn how that is done in
Chapter 6, “An Introduction to Structured Query Language (SQL)”.
STU_CODE
128569
512272
531235
553427
PROF_CODE
2
4
2
1
DEPT_CODE
6
4
6
2
The equiJOIN's results depend on the specified condition. For instance, if the equiJOIN specifies
that ALL STUDENTS FOR WHOM THE ADVISOR CODE IS 2 are to be listed, the output will be
STU_CODE
128569
531235
PROF_CODE
2
2
DEPT_CODE
6
6
In the outerJOIN, the unmatched pairs would be retained and the values that do not have a match in
the other table would be left null. Therefore, the will yield these results:
STU_CODE
100278
128569
512272
531235
531268
553427
PROF_CODE
DEPT_CODE
2
4
2
6
4
6
1
3
2
6
54
Chapter 3 The Relational Database Model
Microsoft Access uses two outer join options to make it easy to find unmatched pairs. For example,
its outer join selections, generated from its QBE (Query By Example) query generator, are
particularly effective. Note, for example, the selected left outer join option in Figure Q3.5A and
look at its output in Figure Q3.5b to see that professor 3 does not have any student advisees.
Figure Q3.5A The Left Outer Join QBE Properties Selection
If you select the option 2 in Figure Q3.5A’s QBE option screen, you’d get the output shown in the
left panel in Figure Q3.5B. Note that you can now easily detect that professor number 3 does not
have any student advisees assigned to him or her. If you select the option 3 in Figure Q3.5A’s QBE
option screen, you’d get the output shown in the right panel in Figure Q3.5B. The latter output
makes it easy to detect that students 100278 and 531268 do not yet have an advisor assigned to
them.
55
Chapter 3 The Relational Database Model
Figure Q3.5b The Left and Right Outer Join Outputs
6. Create the basic ERD for the database shown in Figure Q3.5.
Both the Chen and Crow’s Foot solutions are shown in Figure Q3.6. (We have used the PowerPoint
template to produce the first of the two Crow’s Foot ERDs and Visio Professional to produce the
second of the two Crow’s Foot ERDs.
Figure Q3.6 The Chen and Crow’s Foot ERD Solutions for Question 6
Chen ERD (generated with PowerPoint)
1
PROFESSOR
M
advises
STUDENT
Crow’s Foot ERD (generated with PowerPoint)
PROFESSOR
advises
STUDENT
Chen ERD (generated with Visio Professional)
56
Chapter 3 The Relational Database Model
NOTE
From this point forward, we will show the ERDs in Visio Professional format unless the
problem specifies a different format. Please refer your students to the Visio Professional tutorial
in Appendix A, “Designing Databases with Visio Professional: A Tutorial.” This appendix is
located on the student online companion website.
7. Create the relational diagram for the database shown in Figure Q3.5.
The relational diagram, generated in the Microsoft Access Ch03_CollegeQue database, is shown in
Figure Q.3.7.
Figure Q3.7 The Relational Diagram
8. Suppose that you have the ERM shown in Figure Q3.8.
FIGURE Q3.8 The Crow’s Foot ERD for Question 8
How would you convert this model into an ERM that displays only 1:M relationships? (Make
sure that you draw the revised ERM.)
The Crow’s Foot solution is shown in Figure Q3.8A. Note that the original M:N relationship has
been decomposed into two 1:M relationships based on these business rules:
 A driver may receive many (driving) assignments.
 Each (driving) assignment is made for a single driver.
 A truck may be driven in many (driving) assignments.
 Each (driving) assignment is made for a single truck.
Note that a driver can drive only one truck at a time, but during some period of time, a driver may be
assigned to drive many trucks. The same argument holds true for trucks – a truck can only be driven
during one trip (assignment) at a time, but during some period of time, a truck may be assigned to be
57
Chapter 3 The Relational Database Model
driven in many trips. Also, remind students that they will be introduced to optional (and additional)
relationships as they study Chapter 4, “Entity Relationship Modeling.” Finally, remind your students
that you always read the relationship from the “1” side to the “M” side. Therefore, you read
“DRIVER receives ASSIGNMENT and “TRUCK is driven in ASSIGNMENT.”
Figure Q3.8A The Crow’s Foot ERM Solution for Question 8
9. What are homonyms and synonyms, and why should they be avoided in database design?
Homonyms appear when more than one attribute has the same name. Synonyms exist when the same
attribute has more than one name. Avoid both to avoid inconsistencies. For example, suppose we
check the database for a specific attribute such as NAME. If NAME refers to customer names as
well as to sales rep names, a clear case of a homonym, we have created an ambiguity, because it is
no longer clear which entity the NAME belongs to.
Synonyms make it difficult to keep track of foreign keys if they are named differently from the
primary keys they point to. Using REP_NUM as the foreign key in the CUSTOMER table to
reference the primary key REP_NUM in the SALESREP table is much clearer than naming the
CUSTOMER table's foreign key SLSREP. The proliferation of different attribute names to describe
the same attributes will also make the data dictionary more cumbersome to use.
Some data RDBMSes let the data dictionary check for homonyms and synonyms to alert the user to
their existence, thus making their use less likely. For example, if a CUSTOMER table contains the
(foreign) key REP_NUM, the entry of the attribute REP_NUM in the SALESREP table will either
cause it to inherit all the characteristics of the original REP_NUM, or it will reject the use of this
attribute name when different characteristics are declared by the user.
10. How would you implement a l:M relationship in a database composed of two tables? Give an
example.
Let’s suppose that an auto repair business wants to track its operations by customer. At the most
basic level, it’s reasonable to assume that any database design you produce will include at least a car
entity and a customer entity. Further suppose that it is reasonable to assume that:
 A car is owned just by one customer.
 A customer can own more than one car.
The CAR and CUSTOMER entities and their relationships are represented by the Crow’s Foot ERD
shown in Figure Q3.10. (Discussion: Explain to your students that the ERDs are very basic at this
point. Your students will learn how to incorporate much more detail into their ERDs in Chapter 4.
58
Chapter 3 The Relational Database Model
For example, no thought has –yet – been given to optional relationships or to the strength of those
relationships. At this stage of learning the business of database design, simple is good! To borrow an
old Chinese proverb, a journey of a thousand miles begins with a single step.)
Figure Q3.10A The CUSTOMER owns CAR ERM
An example of this implemented relationship is shown in Figure Q3.10B. Note that the "many" side
of the relation (the CAR entity) contains the foreign key, which is the CUSTOMER entity's primary
key.
Figure Q3.10B The CUSTOMER and CAR Tables
The relational diagram for this implementation is shown in Figure Q3.10C.
Figure Q3.10C The Relational Diagram
(The tables shown in Figure Q3.10B and the relational diagram shown in Figure Q3.10C are found
in the Ch03_Questions database that is located on the CD.)
59
Chapter 3 The Relational Database Model
11. Identify and describe the components of the table shown in Figure Q3.11, using correct
terminology. Use your knowledge of naming conventions to identify the table’s probable
foreign key(s).
FIGURE Q3.11 The Ch03_NoComp Database EMPLOYEE Table
Figure Q3.11's database table contains:
 One entity set: EMPLOYEE.
 Five attributes: EMP_NUM, EMP_LNAME, EMP_INIT, EMP_FNAME, DEPT_CODE
and JOB_CODE.
 Ten entities: the ten workers shown in rows 1-10.
 One primary key: the attribute EMP_NUM because it identifies each row uniquely.
 Two foreign keys: the attribute DEPT_CODE, which probably references a department to
which the employee is assigned and the attribute JOB_CODE which probably references
another table in which you would find the description of the job and perhaps additional
information pertaining to the job.
60
Chapter 3 The Relational Database Model
Use the database composed of the two tables shown in Figure Q3.12 to answer Questions 1217.
FIGURE Q3.12 The Ch03_Theater Database Tables
12. Identify the primary keys.
DIR_NUM is the DIRECTOR table's primary key.
PLAY_CODE is the PLAY table's primary key.
13. Identify the foreign keys.
The foreign key is DIR_NUM, located in the PLAY table. Note that the foreign key is located on
the "many" side of the relationship between director and play. (Each director can direct many plays
... but each play is directed by only one director.)
14. Create the ERM.
The entity relationship model is shown in Figure Q3.12C.
Figure Q3.12C The Theater Database ERD
61
Chapter 3 The Relational Database Model
15. Create the relational diagram to show the relationship between DIRECTOR and PLAY.
The relational diagram, shown in Figure 3.12D, was generated with the help of Microsoft Access.
(Check the Ch03_Theater database.)
Figure Q3.12D The Relational Diagram
16. Suppose you wanted quick lookup capability to get a listing of all plays directed by a given
director. Which table would be the basis for the INDEX table, and what would be the index
key?
The PLAY table would be the basis for the appropriate index table. The index key would be the
attribute DIR_NUM.
17. What would be the conceptual view of the INDEX table that is described in question 16?
Depict the contents of the conceptual INDEX table.
The conceptual index table is shown in Table Q3.12f.
Figure Q3.12F The Conceptual Index Table
Index Key
100
101
102
Pointers to the PLAY table
4
2, 5, 7
1, 3, 6
62
Chapter 3 The Relational Database Model
Problem Solutions
Use the database shown in Figure P3.1 to work Problems 1−7. Note that the database is composed
of four tables that reflect these relationships:
 An EMPLOYEE has only one JOB_CODE, but a JOB_CODE can be held by many
EMPLOYEEs.
 An EMPLOYEE can participate in many PLANs, and any PLAN can be assigned to many
EMPLOYEEs.
Note also that the M:N relationship has been broken down into two 1:M relationships for which
the BENEFIT table serves as the composite or bridge entity.
FIGURE P3.1 The Ch03_BeneCo Database Tables
1. For each table in the database, identify the primary key and the foreign key(s). If a table does
not have a foreign key, write None in the assigned space provided.
TABLE
EMPLOYEE
BENEFIT
JOB
PLAN
PRIMARY KEY
EMP_CODE
EMP_CODE + PLAN_CODE
JOB-CODE
PLAN_CODE
63
FOREIGN KEY(S)
JOB_CODE
EMP_CODE, PLAN_CODE
None
None
Chapter 3 The Relational Database Model
2. Create the ERD to show the relationship between EMPLOYEE and JOB.
The ERD is shown in Figure P3.2. Note that the JOB_CODE = 1 occurs twice in the EMPLOYEE
table, as does the JOB_CODE = 2, thus providing evidence that a JOB can be assigned to many
EMPLOYEEs. But each EMPLOYEE has only one JOB_CODE, so there exists a 1:M relationship
between JOB and EMPLOYEE.
Figure P3.2 The ERD for the EMPLOYEE-JOB Relationship
3. Create the relational diagram to show the relationship between EMPLOYEE and JOB.
The relational schema is shown in Figure P3.3.
Figure P3.3 The Relational Diagram
4. Do the tables exhibit entity integrity? Answer yes or no and then explain your answer.
TABLE
EMPLOYEE
ENTITY INTEGRITY
Yes
BENEFIT
Yes
JOB
Yes
PLAN
Yes
EXPLANATION
Each EMP_CODE value is unique and there are no
nulls.
Each
combination
of
EMP_CODE
and
PLAN_CODE values is unique and there are no
nulls.
Each JOB_CODE value is unique and there are no
nulls.
Each PLAN_CODE value is unique and there are no
nulls.
64
Chapter 3 The Relational Database Model
5. Do the tables exhibit referential integrity? Answer yes or no and then explain your answer.
Write NA (Not Applicable) if the table does not have a foreign key.
TABLE
EMPLOYEE
REFERENTIAL INTEGRITY
Yes
BENEFIT
Yes
JOB
PLAN
NA
NA
EXPLANATION
Each JOB_CODE value in EMPLOYEE
points to an existing JOB_CODE value in
JOB.
Each EMP_CODE value in BENEFIT
points to an existing EMP_CODE value in
EMPLOYEE and each PLAN_CODE value
in BENEFIT points to an existing
PLAN_CODE value in PLAN.
6. Create the ERD to show the relationships among EMPLOYEE, BENEFIT, JOB, and PLAN.
The Crow’s Foot ERD is shown in Figure P3.6.
Figure P3.6 The Crow’s Foot ERD
65
Chapter 3 The Relational Database Model
7. Create the relational diagram to show the relationships among EMPLOYEE, BENEFIT, JOB,
and PLAN.
The relational diagram is shown in Figure P3.7. Note that the location of the entities is immaterial –
the relationships move with the entities.
Figure P3.7 The Relational Diagram
66
Chapter 3 The Relational Database Model
Use the database shown in Figure P3.8 to answer Problems 8-16.
FIGURE P3.8 The Ch03_StoreCo Database Tables
8. For each table, identify the primary key and the foreign key(s). If a table does not have a
foreign key, write None in the space provided.
TABLE
EMPLOYEE
STORE
REGION
PRIMARY KEY
EMP_CODE
STORE_CODE
REGION_CODE
FOREIGN KEY(S)
STORE_CODE
REGION_CODE, EMP_CODE
NONE
67
Chapter 3 The Relational Database Model
9. Do the tables exhibit entity integrity? Answer yes or no and then explain your answer.
TABLE
EMPLOYEE
ENTITY INTEGRITY
Yes
STORE
Yes
REGION
Yes
EXPLANATION
Each EMP_CODE value is unique and there are no
nulls.
Each STORE_CODE value is unique and there are
no nulls.
Each REGION_CODE value is unique and there
are no nulls.
10. Do the tables exhibit referential integrity? Answer yes or no and then explain your answer.
Write NA (Not Applicable) if the table does not have a foreign key.
TABLE
EMPLOYEE
REFERENTIAL INTEGRITY
Yes
STORE
Yes
REGION
NA
EXPLANATION
Each STORE_CODE value in EMPLOYEE
points to an existing STORE_CODE value
in STORE.
Each REGION_CODE value in STORE
points to an existing REGION_CODE value
in REGION and each EMP_CODE value in
STORE points to an existing EMP_CODE
value in EMPLOYEE.
11. Describe the type(s) of relationship(s) between STORE and REGION.
Because REGION_CODE values occur more than once in STORE, we may conclude that each
REGION can contain many stores. But since each STORE is located in only one REGION, the
relationship between STORE and REGION is M:1. (It is, of course, equally true that the relationship
between REGION and STORE is 1:M.)
68
Chapter 3 The Relational Database Model
12. Create the ERD to show the relationship between STORE and REGION.
The Crow’s Foot ERD is shown in Figure P3.12. Note that each store is located in a single region,
but that each region can have many stores located in it. (It’s always a good time to focus a discussion
on the role of business rules in the creation of a database design.)
Figure P3.12 ERD for the STORE and REGION Relationship
13. Create the relational diagram to show the relationship between STORE and REGION.
The relational diagram is shown in Figure P3.13. Note (again) that the location of the entities is
immaterial … the relationships are carried along with the entity. Therefore, it does not matter
whether you locate the REGION on the left side or on the right side of the display. But you always
read from the “1” side to the “M” side, regardless of the entity location.
Figure P3.13 The Relational Diagram for the STORE and REGION Relationship
69
Chapter 3 The Relational Database Model
14. Describe the type(s) of relationship(s) between EMPLOYEE and STORE. (Hint: Each store
employs many employees, one of whom manages the store.)
There are TWO relationships between STORE and REGION. The first relationship, expressed by
STORE employs EMPLOYEE, is a 1:M relationship, because one store can employ many employees
and each employee is employed by one store. The second relationship, expressed by EMPLOYEE
manages STORE, is a 1:1 relationship, because each store is managed by one employee and an
employee manages only one store.
NOTE
It is useful to introduce several ways in which the manages relationship may be
implemented. For example, rather than creating the manages relationship between
EMPLOYEE and STORE, it is possible to simply list the manager's name as an attribute in
the STORE table. This approach creates a redundancy which may not do much damage if
the information requirements are limited. However, if it is necessary to keep track of each
manager's sales and personnel management performance by store, the manages relationship
we have shown here will do a much better job in terms of information generation. Also, you
may want to introduce the notion of an optional relationship. After all, not all employees
participate in the manages relationship. We will cover optional relationships in detail in
Chapter 4, “Entity relationship (ER) Modeling.”
15. Draw the ERD to show the relationships among EMPLOYEE, STORE, and REGION.
The Crow’s Foot ERD is shown in Figure P3.15. Remind students that you always read from the “1”
side to the “M” side in any 1:M relationship, i.e., a STORE employs many EMPLOYEEs and a
REGION contains many STORES. In a 1:1 relationship, you always read from the “parent” entity to
the related entity. In this case, only one EMPLOYEE manages each STORE … and each STORE is
managed by only one EMPLOYEE.
We have shown Figure P3.15’s Visio Professional-generated ERD to include the properties of the
manages relationship. Note that there is no mandatory 1:1 relationship available at this point. That’s
why there is an optional relationship – the O symbol – next to the STORE entity to indicate that an
employee is not necessarily a manager. Let your students know that such optional relationships will
be explored in detail in Chapter 4. (Explain that you can create mandatory 1:1 relationships when
you add attributes to the entity boxes and specify a mandatory data entry for those attributes that are
involved in the 1:1 relationship.) If you use Microsoft Visio Professional, let your students use the
Visio tutorial in Appendix A, located in the book’s Student Online Companion.
70
Chapter 3 The Relational Database Model
Figure P3.15 The Crow’s Foot ERD
71
Chapter 3 The Relational Database Model
16. Create the relational diagram to show the relationships among EMPLOYEE, STORE, and
REGION.
The relational diagram is shown in Figure P3.16.
Figure P3.16 The Relational Diagram
NOTE
The relational diagram in Figure P3.16 was generated in Microsoft Access. If a relationship
already exists between two entities, Access generates a virtual table (in this case,
EMPLOYEE_1) to generate the additional relationship. The virtual table cannot be queried; its
only function is to store the manages relationship between EMPLOYEE and STORE. Just how
multiple relationships are stored and managed is a function of the software you use.
72
Chapter 3 The Relational Database Model
Use the database shown in Figure P3.17 to answer Problems 17-22.
FIGURE P3.17 The Ch03_CheapCo Database Tables
17. For each table, identify the primary key and the foreign key(s). If a table does not have a
foreign key, write None in the space provided.
TABLE
PRODUCT
VENDOR
PRIMARY KEY
PROD_CODE
VEND_CODE
FOREIGN KEY(S)
VEND_CODE
None
18. Do the tables exhibit entity integrity? Answer yes or no and then explain your answer.
TABLE
PRODUCT
VENDOR
ENTITY INTEGRITY
Yes
EXPLANATION
All the PROD_CODE values in PRODUCT
are unique and there are no nulls.
All the VEND_CODE values in VENDOR
are unique and there are no nulls.
Yes
73
Chapter 3 The Relational Database Model
19. Do the tables exhibit referential integrity? Answer yes or no and then explain your answer.
Write NA (Not Applicable) if the table does not have a foreign key.
TABLE
PRODUCT
REFERENTIAL INTEGRITY
Yes
VENDOR
NA
EXPLANATION
All the VEND_CODE values in the
PRODUCT table point to existing
VEND_CODE values in VENDOR table.
20. Create the ERD for this database.
The Crow’s Foot ERD is shown in Figure P3.20.
Figure P3.20 The Ch03_CheapCo Database ERD
NOTE
In this case, we assume that each product is supplied by a single vendor. It is, of course,
possible for a situation to exist in which a vendor can supply many products and each
product can be supplied by many vendors. In this latter scenario, there exists a M:N
relationship between VENDOR and PRODUCT. This M:N relationship must then be
decomposed into two sets of 1:M relationships, thus requiring the creation of a third table
structure (a composite entity) to form the "bridge" between VENDOR and PRODUCT.
We examined such composite entities in Chapter 3's Figure 3.27 in which the ENROLL
table served as the bridge between STUDENT and CLASS. We will explore such
relationships in greater detail in Chapter 4.
74
Chapter 3 The Relational Database Model
21. Create the relational diagram for this database.
The relational diagram is shown in Figure P3.21.
Figure P3.21 The Ch03_CheapCo Database Relational Diagram
22. Create the data dictionary for this database.
Use the attributes shown in Figure P3.17 and write the data dictionary using the format shown in
Table P3.22. To avoid referential integrity error messages at the implementation stage, make sure
that the foreign keys have the same attribute characteristics as the primary keys they point to.
Table P3.22 The Data Dictionary
Table
Name
PRODUCT
VENDOR
Attribute
Name
Contents
Type
Length
Format
Range
Req’d
Key
PK
PROD_CODE
Product code
VCHAR
10
X(10)
Y
PROD_DESCRIPTION
Product
description
VCHAR
35
X(35)
Y
PROD_STOCK_DATE
Stock date
DATE
8
mm/dd/yyyy
PROD_ONHAND
Units
available
SMALLINT
4
9999
0-9999
Y
P_PRICE
Product
price
DECIMAL
7
9999.99
0-9999.99
Y
VEND_CODE
Vendor code
INTEGER
5
99999
1-99999
Y
FK
VEND_CODE
Vendor code
INTEGER
5
99999
1-99999
Y
PK
VEND_NAME
Vendor
name
VCHAR
35
X(35)
Y
VEND_CONTACT
Contact
person
VCHAR
15
X(15)
Y
VEND_AREACODE
Area code
FCHAR
3
X(3)
Y
VEND_PHONE
Phone
FCHAR
8
X(8)
Y
75
Referenced
Table
Y
VENDOR
Chapter 3 The Relational Database Model
Use the database shown in Figure P3.23 to answer Problems 23-29.
FIGURE P3.23 The Ch03_TransCo Database Tables
23. For each table, identify the primary key and the foreign key(s). If a table does not have a
foreign key, write None in the space provided.
TABLE
TRUCK
BASE
TYPE
PRIMARY KEY
TRUCK_NUM
BASE_CODE
TYPE_CODE
FOREIGN KEY(S)
BASE_CODE, TYPE_CODE
None
None
NOTE
Note: The TRUCK_SERIAL_NUM could also be designated as the primary key. Because the
TRUCK_NUM was designated to be the primary key, TRUCK_SERIAL_NUM is an
example of a candidate key.
76
Chapter 3 The Relational Database Model
24. Do the tables exhibit entity integrity? Answer yes or no and then explain your answer.
TABLE
TRUCK
ENTITY INTEGRITY
Yes
BASE
Yes
TYPE
Yes
EXPLANATION
The TRUCK_NUM values in the TRUCK table are
all unique and there are no nulls.
The BASE_CODE values in the BASE table are all
unique and there are no nulls.
The TYPE_CODE values in the TYPE table are all
unique and there are no nulls.
25. Do the tables exhibit referential integrity? Answer yes or no and then explain your answer.
Write NA (Not Applicable) if the table does not have a foreign key.
TABLE
TRUCK
BASE
TYPE
REFERENTIAL INTEGRITY
Yes
EXPLANATION
The BASE_CODE values in the TRUCK
table reference existing BASE_CODE
values in the BASE table or they are null.
(The TRUCK table's BASE_CODE is null
for TRUCK_NUM = 1004.) Also, the
TYPE_CODE values in the TRUCK table
reference existing TYPE_CODE values in
the TYPE table.
NA
NA
26. Identify the TRUCK table’s candidate key(s).
A candidate key is any key that could have been used as a primary key, but that was, for some
reason, not chosen to be the primary key. For example, the TRUCK_SERIAL_NUM could have
been selected as the PK, but the TRUCK_NUM was actually designated to be the PK. Therefore, the
TRUCK_SERIAL_NUM is a candidate key. Also, any combination of attributes that would uniquely
identify any truck would be a candidate key. For example, the combination of BASE_CODE,
TYPE_CODE, TRUCK_MILES, and TRUCK_BUY_DATE is not likely to be duplicated and this
combination would, therefore, be a candidate key. However, while the latter combination might
constitute a candidate key, such a combination would not be practical. (An extreme – and
impractical -- example of a candidate key would be the combination of all of a table’s attributes.)
77
Chapter 3 The Relational Database Model
NOTE
Some of the answers to the following problem 27 define only a few of the available correct
choices. For example, a superkey is, in effect, a candidate key containing redundant
attributes. Therefore, any primary key plus any other attribute(s) is a superkey.
Because a secondary key does not necessarily yield unique outcomes, the number of
attributes that constitute a secondary key is somewhat arbitrary. The adequacy of a
secondary key depends on the extent of the end-user's willingness to accept multiple
matches.
27. For each table, identify a superkey and a secondary key.
TABLE
SUPERKEY
SECONDARY KEY
TRUCK
TRUCK_NUM + TRUCK_MILES
BASE_CODE + TYPE_CODE
TRUCK_NUM + TRUCK_MILES +
TRUCK_BUY_DATE
TRUCK_NUM + TRUCK_MILES +
TRUCK_BUY_DATE + TYPE_CODE
(This secondary key is likely to produce multiple
matches, but it is not likely that end-users will know
attribute values such as TRUCK_MILES or
TRUCK_BUY_DATE. Therefore, the selected
attributes create a reasonable secondary key.)
BASE_CODE + BASE_CITY
BASE_CITY + BASE_STATE
BASE_CODE + BASE_CITY + BASE_CITY
(This a very effective secondary key, since it is not
likely that a state contains two cities with the same
name.)
TYPE_CODE + TYPE_DESCRIPTION
TYPE_DESCRIPTION
BASE
TYPE
78
Chapter 3 The Relational Database Model
28. Create the ERD for this database.
The Crow’s Foot ERD is shown in Figures P3.28.
Figure P3.28 The Ch03_TransCo ERD
29. Create the relational diagram for this database.
The relational diagram is shown in Figure P3.29.
Figure P3.29 The Ch03_TransCo Relational Diagram
79
Chapter 3 The Relational Database Model
Use the database shown in Figure P3.30 to answer Problems 30−34. ROBCOR is an aircraft
charter company that supplies on-demand charter flight services using a fleet of four aircraft.
Aircrafts are identified by a unique registration number. Therefore, the aircraft registration
number is an appropriate primary key for the AIRCRAFT table.
FIGURE P3.30 The Ch03_AviaCo Database Tables (Part 1)
The nulls in the CHARTER table’s CHAR_COPILOT column indicate that a copilot is not
required for some charter trips or for some aircraft. Federal Aviation Administration (FAA) rules
require a copilot on jet aircraft and on aircraft having a gross take-off weight over 12,500 pounds.
None of the aircraft in the AIRCRAFT table are governed by this requirement; however, some
customers may require the presence of a copilot for insurance reasons. All charter trips are
recorded in the CHARTER table.
80
Chapter 3 The Relational Database Model
FIGURE P3.30 The Ch03_AviaCo Database Tables (Part 2)
81
Chapter 3 The Relational Database Model
NOTE
Earlier in the chapter, it was stated that it is best to avoid homonyms and synonyms. In this
problem, both the pilot and the copilot are pilots in the PILOT table, but EMP_NUM cannot be
used for both in the CHARTER table. Therefore, the synonyms CHAR_PILOT and
CHAR_COPILOT were used in the CHARTER table.
Although the solution works in this case, it is very restrictive and it generates nulls when a
copilot is not required. Worse, such nulls proliferate as crew requirements change. For example,
if the AviaCo charter company grows and starts using larger aircraft, crew requirements may
increase to include flight engineers and load masters. The CHARTER table would then have to
be modified to include the additional crew assignments; such attributes as
CHAR_FLT_ENGINEER and CHAR_LOADMASTER would have to be added to the
CHARTER table. Given this change, each time a smaller aircraft flew a charter trip without the
number of crew members required in larger aircraft, the missing crew members would yield
additional nulls in the CHARTER table.
You will have a chance to correct those design shortcomings in Problem 33. The problem
illustrates two important points:
1. Don’t use synonyms. If your design requires the use of synonyms, revise the design!
2. To the greatest possible extent, design the database to accommodate growth without
requiring structural changes in the database tables. Plan ahead and try to anticipate the
effects of change on the database.
82
Chapter 3 The Relational Database Model
ROBCOR is an aircraft charter company that supplies on-demand charter flight services, using a
fleet of four aircraft. Aircraft are identified by a (unique) registration number. Therefore, the
aircraft registration number is an appropriate primary key for the AIRCRAFT table.
The nulls in the CHARTER table’s CHAR_COPILOT column indicate that a copilot is not
necessarily required for some charter trips or for some aircraft. Federal Aviation Administration
(FAA) rules require a copilot on jet aircraft and on aircraft having a gross take-off weight over
12,500 pounds. None of the aircraft in the AIRCRAFT table is governed by this requirement;
however, some customers may require the presence of a copilot for insurance reasons. All charter
trips are recorded in the CHARTER table.
NOTE
Earlier in the chapter it was stated that it is best to avoid homonyms and synonyms. In this
problem, both the pilot and the copilot are pilots in the PILOT table, but EMP_NUM cannot be
used for both in the CHARTER table. Therefore, the synonyms CHAR_PILOT and
CHAR_COPILOT were used in the CHARTER table.
Although the “solution” works in this case, it is very restrictive and it generates nulls when a
copilot is not required. Worse, such nulls proliferate as crew requirements change. For
example, if the AviaCo charter company grows and starts using larger aircraft, crew
requirements may increase to include flight engineers and load masters. The CHARTER table
would then have to be modified to include the additional crew assignments; such attributes as
CHAR_FLT_ENGINEER and CHAR_LOADMASTER would have to be added to the
CHARTER table. Given this change, each time a smaller aircraft flew a charter trip without
the number of crew members required in larger aircraft, the “missing” crew members would
yield additional nulls in the CHARTER table.
You will have a chance to correct those design shortcomings in Problem 33. The problem
illustrates two important points:
1. Don’t use synonyms. If your design requires the use of synonyms, revise the design!
2. To the greatest possible extent, design the database to accommodate growth without
requiring structural changes in the database tables. Plan ahead—and try to anticipate
the effects of change on the database.
83
Chapter 3 The Relational Database Model
30. For each table, where possible, identify:
a. The primary key
TABLE
CHARTER
AIRCRAFT
MODEL
PILOT
EMPLOYEE
CUSTOMER
PRIMARY KEY
CHAR_TRIP
AC_NUMBER
MOD_CODE
EMP_NUM
EMP_NUM
CUS_CODE
b. A superkey
TABLE
CHARTER
AIRCRAFT
MODEL
PILOT
EMPLOYEE
CUSTOMER
SUPER KEY
CHAR_TRIP + CHAR_DATE
AC_NUM + MOD-CODE
MOD_CODE + MOD_NAME
EMP_NUM + PIL_LICENSE
EMP_NUM + EMP_DOB
CUS_CODE + CUS_LNAME
NOTE
The super key and secondary key compositions were described in the note that
accompanied Problem 27. The same arguments may be pursued with reference to parts
b, c and e of this problem.
84
Chapter 3 The Relational Database Model
c. A candidate key
TABLE
CHARTER
CANDIDATE KEY
No practical candidate key is available. For example,
CHAR_DATE + CHAR_DESTINATION + AC_NUMBER +
CHAR_PILOT + CHAR_COPILOT
AIRCRAFT
MODEL
PILOT
EMPLOYEE
will still not necessarily yield unique matches, because it is possible to fly
an aircraft to the same destination twice on one date with the same pilot and
copilot. You could, of course, present the argument that the combination of
all the attributes would yield a unique outcome.
See the previous discussion.
See the previous discussion.
See the previous discussion.
See the previous discussion. But Perhaps the combination of
EMP_LNAME + EMP_FNAME + EMP_INITIAL + EMP_DOB
will yield an acceptable candidate key.
CUSTOMER
See the previous discussion
d. The foreign key(s)
TABLE
CHARTER
AIRCRAFT
MODEL
PILOT
EMPLOYEE
CUSTOMER
FOREIGN KEY
CHAR_PILOT (references PILOT)
CHAR_COPILOT (references PILOT)
AC_NUMBER (references AIRCRAFT)
CUS_CODE (references CUSTOMER)
MOD_CODE
None
EMP_NUM (references EMPLOYEE)
None
None
e. A secondary key
TABLE
CHARTER
AIRCRAFT
MODEL
PILOT
EMPLOYEE
CUSTOMER
SECONDARY KEY
CHAR_DATE + AC_NUMBER + CHAR_DESTINATION
MOD_CODE
MOD_MANUFACTURER + MOD_NAME
PIL_LICENSE + PIL_MED_DATE
EMP_LNAME + EMP_FNAME + EMP_DOB
CUS_LNAME + CUS_FNAME + CUS_PHONE
85
Chapter 3 The Relational Database Model
31. Create the ERD. (Hint: Look at the table contents. You will discover that an AIRCRAFT can
fly many CHARTER trips but that each CHARTER trip is flown by one AIRCRAFT.
Similarly, you will discover that a MODEL references many AIRCRAFT but that each
AIRCRAFT references a single MODEL, etc.)
The Crow’s Foot ERD is shown in Figure P3.31. The optional (default) 1:1 relationship crops up in
this ERD, just as it did in the Problem 15 solution. Use the same discussion that accompanied
Problem 15. Also, note that EMPLOYEE is the “parent” of PILOT.
Note that all pilots are employees, but not all employees are pilots – some are mechanics,
accountants, and so on. (This discussion previews some of the Chapter 4 coverage … coming
attractions, so to speak.) The relationship between PILOT and EMPLOYEE is read from the
“parent” entity to the related entity. In this case, the relationship is read as “an EMPLOYEE is a
PILOT.”
Figure P3.31 The Ch03_AviaCo Database ERD
86
Chapter 3 The Relational Database Model
32. Create the relational diagram.
The relational diagram is shown in Figure P3.32.
Figure P3.32 The Ch03_AviaCo Database Relational Diagram
87
Chapter 3 The Relational Database Model
33. Modify the ERD you created in Problem 31 to eliminate the problems created by the use of
synonyms. (Hint: Modify the CHARTER table structure by eliminating the CHAR_PILOT
and CHAR_COPILOT attributes; then create a composite table named CREW to link the
CHARTER and EMPLOYEE tables. Some crewmembers, such as flight attendants, may not
be pilots. That’s why the EMPLOYEE table enters into this relationship.)
The Crow’s Foot ERD is shown in Figures P3.33.
Figure P3.33b The Ch03_AviaCo_2 Database ERD
88
Chapter 3 The Relational Database Model
34. Draw the relational diagram for the design you revised in problem 33. (After you have had a
chance to revise the design, your instructor will show you the results of the design change,
using a copy of the revised database named Ch03_AviaCo_2).
The relational diagram for the Ch03_AviaCo_2 database is shown in Figure P3.34. Note that there
are a few additional entities that you will encounter again in Chapter 4. (You can safely ignore the
extra entities, RATING and EARNEDRATING at this point … but you can let the students “read”
the relationship between these two entities.
Note that you can easily derive the M:N relationship between PILOT and RATING. (A PILOT can
earn many RATINGs. A RATING can be earned by many PILOTs.) Even though your students may
not know what a rating is, they can still draw up conclusions about its relationship to other entities
by looking at relational diagrams and ERDs. And that’s one of the many strengths of design tools.
Also, you can let your students break the M:N relationship down into two 1:M relationships – note
that this is done through the EARNEDRATING entity. The issues encountered in the design and
implementation of the Ch3_AviaCo_2 database will be revisited many times in the book.
Figure P3.34 The Ch03_AviaCo_2-Relational Diagram
89