Chapter 3

Relational Model Characteristics

Answers to Review Questions
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.

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.

5. What is the domain of an attribute?

Each attribute is a named column within the relational table and draws it values from a domain. A
domain is a set of all the possible values for this attribute.

7. Create the basic ERD using UML notation for the database shown in Figure Q3.2.

The UML solution is shown in Figure Q3.7

For use with Database Principles, Second Edition, Cengage Learning EMEA
 Figure Q3.7 UML ERD Solution for Question 7

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.

11. Identify and describe the components of the table shown in Figure Q3.4, using correct
terminology. Use your knowledge of naming conventions to identify the table’s probable
foreign key(s).

For use with Database Principles, Second Edition, Cengage Learning EMEA
 FIGURE Q3.11The Ch03_NoComp Database EMPLOYEE Table

EMP_NUM EMP_LNAME EMP_INITIAL EMP_FNAME DEPT_CODE JOB_CODE

11234 Friedman K Robert MKTG 12
11238 Olanski D Delbert MKTG 12
11241 Fontein Juliette INFS 5
11242 Cruazona J Maria ENG 9
11245 Smithson B Bernard INFS 6
11248 Washington G Oleta ENGR 8
11256 McBride Randall ENGR 8
11257 Kachinn D Melanie MKTG 14
11258 Smith W William MKTG 14
11260 Ratula A Katrina INFS 5

The database table in Figure Q3.11 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.

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 *:* relationship has been broken down into two 1:* relationships for which the
BENEFIT table serves as the composite or bridge entity.

For use with Database Principles, Second Edition, Cengage Learning EMEA
FIGURE P3.1 The Ch03_BeneCo Database Tables

Database name: Ch03_BeneCo

Table name: EMPLOYEE

EMP_CODE EMP_LNAME JOB_CODE

14 Rudell 2
15 McDade 1
16 Ruellardo 1
17 Smith 3
20 Smith 2

Table name: BENEFIT

EMP_CODE PLAN_CODE
15 2
15 3
16 1
17 1
17 3
17 4
20 3

Table name: JOB

JOB_CODE JOB_DESCRIPTION
1 Clerical
2 Technical
3 Managerial

Table name: PLAN

PLAN_CODE PLAN_DESCRIPTION
1 Term life
2 Stock purchase
3 Long-term disability
4 Dental

For use with Database Principles, Second Edition, Cengage Learning EMEA
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 PRIMARY KEY FOREIGN KEY(S)

EMPLOYEE EMP_CODE JOB_CODE
BENEFIT EMP_CODE + PLAN_CODE EMP_CODE, PLAN_CODE
JOB JOB-CODE None
PLAN PLAN_CODE None

3.Do the tables exhibit entity integrity? Answer yes or no; then explain your answer.

TABLE ENTITY INTEGRITY EXPLANATION

EMPLOYEE Yes Each EMP_CODE value is unique and there are no
nulls.
BENEFIT Yes Each combination of EMP_CODE and
PLAN_CODE values is unique and there are no
nulls.
JOB Yes Each JOB_CODE value is unique and there are no
nulls.
PLAN Yes Each PLAN_CODE value is unique and there are no
nulls.

For use with Database Principles, Second Edition, Cengage Learning EMEA
5. Create the ERD using Crow’s Foot notation to show the relationships among EMPLOYEE,
BENEFIT, JOB, and PLAN.

The Crow’s Foot ERD is shown in Figure P3.5.

Figure P3.5 The Crow’s Foot ERD

For use with Database Principles, Second Edition, Cengage Learning EMEA
Use the database shown in Figure P3.7 to answer Problems 7-13.

FIGURE P3.7 The Ch03_StoreCo Database Tables

Database name: Ch03_StoreCo

Table name: EMPLOYEE

EMP_CODE EMP_TITLE EMP_LNAME EMP_FNAME EMP_INITIAL EMP_DOB STORE_CODE

1 Mr. Williamson John W 21-May-64 3
2 Ms. Ratula Nancy 09-Feb-69 2
3 Ms. Greenboro Lottie R 02-Oct-61 4
4 Mrs. Rumpersfro Jennie S 01-Jun-71 5
5 Mr. Smith Robert L 23-Nov-59 3
6 Mr. Renselaer Cary A 25-Dec-65 1
7 Mr. Ogallo Roberto S 31-Jul-62 3
8 Ms. Johnsson Elizabeth I 10-Sep-68 1
9 Mr. Eindsmar Jack W 19-Apr-55 2
10 Mrs. Jones Rose R 06-Mar-66 4
11 Mr. Broderick Tom 21-Oct-72 3
12 Mr. Washington Alan Y 08-Sep-74 2
13 Mr. Smith Peter N 25-Aug-64 3
14 Ms. Smith Sherry H 25-May-66 4
15 Mr. Olenko Howard U 24-May-64 5
16 Mr. Archialo Barry V 03-Sep-60 5
17 Ms. Grimaldo Jeanine K 12-Nov-70 4
18 Mr. Rosenberg Andrew D 24-Jan-71 4
19 Mr. Rosten Peter F 03-Oct-68 4
20 Mr. Mckee Robert S 06-Mar-70 1
21 Ms. Baumann Jennifer A 11-Dec-74 3

Table name: STORE

STORE_CODE STORE_NAME STORE_YTD_SALES REGION_CODE EMP_CODE

1 Access Junction €792,730.05 2 8
2 Database Corner €1,123,370.04 2 12
3 Tuple Charge €779,558.74 1 7
4 Attribute Alley €746,209.16 2 3
5 Primary Key Point €2,314,777.78 1 15

Table name: REGION

REGION_CODE REGION_DESCRIPT
1 East
2 West

For use with Database Principles, Second Edition, Cengage Learning EMEA
7. 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 PRIMARY KEY FOREIGN KEY(S)

EMPLOYEE EMP_CODE STORE_CODE
STORE STORE_CODE REGION_CODE, EMP_CODE
REGION REGION_CODE NONE

9. Do the tables exhibit referential integrity? Answer yes or no; then explain your answer. Write
NA (Not Applicable) if the table does not have a foreign key.

TABLE REFERENTIAL INTEGRITY EXPLANATION

EMPLOYEE Yes Each STORE_CODE value in EMPLOYEE
points to an existing STORE_CODE value
in STORE.
STORE Yes 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.
REGION NA

11. Create the ERD using UML notation to show the relationship between STORE and
REGION.

The UML ERD is shown in Figure P3.11. 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.11 ERD for the STORE and REGION Relationship

13. Draw the ERD to show the relationships among EMPLOYEE, STORE, and REGION.

The UML ERD is shown in Figure P3.13. Remind students that you always read from the “1” side
to the “*” side in any 1:* 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.13’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

For use with Database Principles, Second Edition, Cengage Learning EMEA
 why there is an optional relationship represented by 0:1 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 5. If you use Microsoft Visio Professional, let your students use the
Visio tutorial in Appendix A, located in the book’s Student CD-ROM Companion.

Figure P3.13 The UML ERD

Use the database shown in Figure P3.14 to answer Problems 14-18.

FIGURE P3.14 The Ch03_CheapCo Database Tables

Database name: Ch03_CheapCo

Table name: PRODUCT Primary Key: PROD_CODE

Foreign Key: VEND_CODE

PROD_CODE PROD_DESCRIPTION PROD_STOCK_DATE PROD_ON_HAND PROD_PRICE VEND_CODE

12-WW/P2 7.25-cm. power saw blade 07-Apr-06 12 €0.94 123
1QQ23-55 2.5-cm. wood screw, 100 19-Mar-06 123 €3.55 123
231-78-W PVC pipe, 3.5-cm., 4m. 07-Dec-05 45 €7.01 121
33564/U Rat-tail file, 0.125-cm., fine 08-Mar-06 18 €0.94 123
AR/3/TYR Cordless drill, 0.25-cm. 29-Nov-05 8 €36.33 121
DT-34-WW Phillips screwdriver pack 20-Dec-05 11 €18.40 123
EE3-67/W Sledge hammer, 6kg. 25-Feb-06 9 €14.21 121
ER-56/DF Houselite chain saw, 16-cm. 28-Dec-05 7 €186.04 125
FRE-TRY9 Jigsaw, 12-cm blade 12-Aug-05 67 €1.15 125
SE-67-89 Jigsaw, 8-cm. blade 11-Oct-05 34 €1.07 125
ZW-QR/AV Hardware cloth, 0.25-cm 23-Apr-06 14 €10.26 123
ZX-WR/FR Claw hammer 01-Mar-06 15 €7.07 121

For use with Database Principles, Second Edition, Cengage Learning EMEA
Table name: VENDOR Primary Key: VEND_CODE

Foreign Key: none

VEND_CODE VEND_NAME VEND_CONTACT VEND_AREACODE VEND_PHONE

120 BargainSnapper, Inc. Melanie T. Travis 0181 899-1234
121 Cut'nGlow Co. Henry J. Olero 0181 342-9896
122 Rip & Rattle Supply Co. Anne R. Morrins 0113 225-1127
123 Tools 'R Us Juliette G. McHenry 0161 546-7894
124 Trowel & Dowel, Inc. George F. Frederick 0113 453-4567
125 Bow & Wow Tools Bill S. Sedwick 0113 324-9988

15. Do the tables exhibit entity integrity? Answer yes or no; then explain your answer.

TABLE ENTITY INTEGRITY EXPLANATION

PRODUCT Yes All the PROD_CODE values in PRODUCT are
unique and there are no nulls.
VENDOR Yes All the VEND_CODE values in VENDOR are
unique and there are no nulls.

17. Create the ERD using UML notation for this database.

The ERD is shown in Figure P3.17.

Figure P3.17 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 *:*
relationship between VENDOR and PRODUCT. This *:* relationship must then be
decomposed into two sets of 1:* relationships, thus requiring the creation of a third table
structure (a composite entity) to form the "bridge" between VENDOR and PRODUCT.
We will explore such relationships in greater detail in Chapter 5.

Use the database shown in Figure P3.19 to answer Problems 19-24

For use with Database Principles, Second Edition, Cengage Learning EMEA
FIGURE P3.19 The Ch03_TransCo Database Tables

Database name: Ch03_TransCo

Table name: TRUCK Primary Key: TRUCK_NUM

Foreign Key: BASE-CODE, TYPE_CODE

TRUCK_NUM BASE_CODE TYPE_CODE TRUCK_MILES TRUCK_BUY_DATE TRUCK_SERIAL_NUM

1001 501 1 32,123.50 23-Sep-03 AA-322-12212-W11
1002 502 1 76,984.30 05-Feb-02 AC-342-22134-Q23
1003 501 2 12,346.60 11-Nov-03 AC-445-78656-Z99
1004 1 2,894.30 06-Jan-04 WQ-112-23144-T34
1005 503 2 45,673.10 01-Mar-03 FR-998-32245-W12
1006 501 2 193,245.70 15-Jul-00 AD-456-00845-R45
1007 502 3 32,012.30 17-Oct-01 AA-341-96573-Z84
1008 502 3 44,213.60 07-Aug-02 DR-559-22189-D33
1009 503 2 10,932.90 12-Feb-04 DE-887-98456-E94

Table name: BASE Primary Key: BASE_CODE

Foreign Key: none

BASE_CODE BASE_CITY BASE_COUNTY BASE_AREA_CODE BASE_PHONE BASE_MANAGER

501 London Buckinghamshire 0181 123-4567 Andrea D. Gallager
502 Edingburgh Edingburgh City 0117 234-5678 George H. Delarosa
503 Best North Brabant 4567 345-6789 Maria J. Talindo
504 Blackrock Cork 3531 456-7890 Peter F. McAvee

Table name: TYPE Primary Key: TYPE_CODE

Foreign Key: none

TYPE_CODE TYPE_DESCRIPTION
1 Single box, double-axle
2 Single box, single-axle
3 Tandem trailer, single-axle

For use with Database Principles, Second Edition, Cengage Learning EMEA
19. 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 PRIMARY KEY FOREIGN KEY(S)

TRUCK TRUCK_NUM BASE_CODE, TYPE_CODE
BASE BASE_CODE None
TYPE TYPE_CODE 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.

21. Do the tables exhibit referential integrity? Answer yes or no; then explain your answer. Write
NA (Not Applicable) if the table does not have a foreign key.

TABLE REFERENTIAL INTEGRITY EXPLANATION

TRUCK Yes 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.
BASE NA
TYPE NA

NOTE
Some of the answers to the following problem 23 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.

For use with Database Principles, Second Edition, Cengage Learning EMEA
 23. 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 + (This secondary key is likely to produce multiple

TRUCK_BUY_DATE matches, but it is not likely that end-users will know
attribute values such as TRUCK_MILES or
TRUCK_NUM + TRUCK_MILES + TRUCK_BUY_DATE. Therefore, the selected
TRUCK_BUY_DATE + TYPE_CODE attributes create a reasonable secondary key.)

BASE 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 TYPE_CODE + TYPE_DESCRIPTION TYPE_DESCRIPTION

Use the database shown in Figure P3.25 to answer Problems 25-29.

FIGURE P3.25 The Ch03_AviaCo Database Tables

Database name: Ch03_AviaCo

Table name: CHARTER

CHAR_ CHAR_D CHAR_ CHAR AC_NUM CHAR_DES CHAR_DI CHAR_ CHAR_ CHAR_FUEL CHAR CUS_
TRIP ATE PILOT _COPI BER TINATION STANCE HOURS HOUR _GALLONS _OIL_ CODE
LOT _FLOW S_WAI QTS
N T
10001 05-Feb-08 104 2289L CDG 936.00 5.1 2.2 354.1 1 10011
10002 05-Feb-08 101 2778V BNA 320.00 1.6 0 72.6 0 10016
10003 05-Feb-08 105 109 4278Y LHR 1,574.00 7.8 0 339.8 2 10014
10004 06-Feb-08 106 1484P CPT 472.00 2.9 4.9 97.2 1 10019
10005 06-Feb-08 101 2289L CDG 1,023.00 5.7 3.5 397.7 2 10011
10006 06-Feb-08 109 4278Y CPT 472.00 2.6 5.2 117.1 0 10017
10007 06-Feb-08 104 105 2778V LHR 1,574.00 7.9 0 348.4 2 10012
10008 07-Feb-08 106 1484P TYS 644.00 4.1 0 140.6 1 10014
10009 07-Feb-08 105 2289L LHR 1,574.00 6.6 23.4 459.9 0 10017
10010 07-Feb-08 109 4278Y CDG 998.00 6.2 3.2 279.7 0 10016
10011 07-Feb-08 101 104 1484P BNA 352.00 1.9 5.3 66.4 1 10012
10012 08-Feb-08 101 2778V MOB 884.00 4.8 4.2 215.1 0 10010
10013 08-Feb-08 105 4278Y TYS 644.00 3.9 4.5 174.3 1 10011
10014 09-Feb-08 106 4278Y CDG 936.00 6.1 2.1 302.6 0 10017
10015 09-Feb-08 104 101 2289L LHR 1,645.00 6.7 0 459.5 2 10016
10016 09-Feb-08 109 105 2778V MQY 312.00 1.5 0 67.2 0 10011
10017 10-Feb-08 101 1484P CPT 508.00 3.1 0 105.5 0 10014
10018 10-Feb-08 105 104 4278Y TYS 644.00 3.8 4.5 167.4 0 10017

For use with Database Principles, Second Edition, Cengage Learning EMEA
The destinations are indicated by standard three-letter airport codes. For example,

CDG = PARIS CHARLES DE GAULLE, FRANCE, LHR = LONDON HEATHROW, UNITED

KINGDOM AND CPT = CAPE TOWN D. F. MALAN, SOUTH AFRICA

Table name: AIRCRAFT

AC_NUMBER MOD_CODE AC_TTAF AC_TTEL AC_TTER

1484P PA23-250 1,833.10 1,833.10 101.80
2289L C-90A 4,243.80 768.90 1,123.40
2778V PA31-350 7,992.90 1,513.10 789.50
4278Y PA31-350 2,147.30 622.10 243.20

AC_TTAF = Aircraft total time, airframe (hours)

AC_TTEL = Total time, left engine (hours)

AC_TTER = Total time, right engine (hours)

In a fully developed system, such attribute values would be updated by application software when

the CHARTER table entries are posted.

Table name: MODEL

MOD_CODE MOD_MANUFACTURER MOD_NAME MOD_SEATS MOD_CHG_MILE

C-90A Beechcraft KingAir 8 €1.67
PA23-250 Piper Aztec 6 €1.20
PA31-350 Piper Navajo Chieftain 10 €1.47

Customers are charged per round-trip mile, using the MOD_CHG_MILE rate. The MOD_SEAT

gives the total number of seats in the airplane, including the pilot and copilot seats. Therefore a

PA31-350 trip that is flown by a pilot and copilot has six passenger seats available.

For use with Database Principles, Second Edition, Cengage Learning EMEA
Table name: PILOT

EMP_NUM PIL_LICENSE PIL_RATINGS PIL_MED_TYPE PIL_MED_DATE PIL_PT135_DATE

101 ATP ATP/SEL/MEL/Instr/CFII 1 20-Jan-07 11-Jan-07
104 ATP ATP/SEL/MEL/Instr 1 18-Dec-06 17-Jan-07
105 COM COMM/SEL/MEL/Instr/CFI 2 05-Jan-07 02-Jan-07
106 COM COMM/SEL/MEL/Instr 2 10-Dec-06 02-Feb-07
109 COM ATP/SEL/MEL/SES/Instr/CFII 1 22-Jan-07 15-Jan-07

The pilot licenses shown in the PILOT table include the ATP = Airline Transport Pilot and COM =

Commercial Pilot. Businesses that operate on demand air services are governed by Part 135 of the

Federal Air Regulations (FARs) that are enforced by the Federal Aviation Administration (FAA).

Such businesses are known as “Part 135 operators.” Part 125 operations require that pilots

successfully complete flight proficiency checks every six months. The “Part 135” flight proficiency

check data is recorded in PIL_PT135_DATE. To fly commercially, pilots must have at least a

commercial license and a second-class medical certificate (PIL_MED_TYPE = 2).

The PIL_RATINGs include

SEL = Single Engine, land MEL – Multengine, Land

SES = Single Engine, Sea Instr. = Instrument

CFI = Certified Flight Instructor CFII = Certified Flight Instructor, Instrument

Table name: EMPLOYEE

EMP_NUM EMP_TITLE EMP_LNAME EMP_FNAME EMP_INITIAL EMP_DOB EMP_HIRE_DATE

100 Mr. Kolmycz George D 15-Jun-42 15-Mar-88
101 Ms. Lewis Rhonda G 19-Mar-65 25-Apr-86
102 Mr. Vandam Rhett 14-Nov-58 18-May-93
103 Ms. Jones Anne M 11-May-74 26-Jul-99
104 Mr. Lange John P 12-Jul-71 20-Aug-90
105 Mr. Williams Robert D 14-Mar-75 19-Jun-03
106 Mrs. Duzak Jeanine K 12-Feb-68 13-Mar-89
107 Mr. Diante Jorge D 01-May-75 02-Jul-97
108 Mr. Wiesenbach Paul R 14-Feb-66 03-Jun-93
109 Ms. Travis Elizabeth K 18-Jun-61 14-Feb-06
110 Mrs. Genkazi Leighla W 19-May-70 29-Jun-90

For use with Database Principles, Second Edition, Cengage Learning EMEA
Table name: CUSTOMER

CUS_CODE CUS_LNAME CUS_FNAME CUS_INITIAL CUS_AREACODE CUS_PHONE CUS_BALANCE

10010 Ramas Alfred A 0181 844-2573 €0.00
10011 Dunne Leona K 0161 894-1238 €0.00
10012 Smith Kathy W 0181 894-2285 €559.73
10013 Olowski Paul F 0181 894-2180 €802.09
10014 Orlando Myron 0181 222-1672 €420.15
10015 O'Brian Amy B 0161 442-3381 €633.19
10016 Brown James G 0181 297-1228 €0.00
10017 Williams George 0181 290-2556 €0.00
10018 Farriss Anne G 0161 382-7185 €0.00
10019 Smith Olette K 0178 297-3809 €283.33

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

For use with Database Principles, Second Edition, Cengage Learning EMEA
25. For each table, where possible, identify:

a. The primary key

TABLE PRIMARY KEY
CHARTER CHAR_TRIP
AIRCRAFT AC_NUMBER
MODEL MOD_CODE
PILOT EMP_NUM
EMPLOYEE EMP_NUM
CUSTOMER CUS_CODE

b. A superkey
TABLE SUPER KEY
CHARTER CHAR_TRIP + CHAR_DATE
AIRCRAFT AC_NUM + MOD-CODE
MODEL MOD_CODE + MOD_NAME
PILOT EMP_NUM + PIL_LICENSE
EMPLOYEE EMP_NUM + EMP_DOB
CUSTOMER CUS_CODE + CUS_LNAME

For use with Database Principles, Second Edition, Cengage Learning EMEA
c. A candidate key
TABLE CANDIDATE KEY
CHARTER No practical candidate key is available. For example,

CHAR_DATE + CHAR_DESTINATION + AC_NUMBER +

CHAR_PILOT + CHAR_COPILOT

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.
AIRCRAFT See the previous discussion.
MODEL See the previous discussion.
PILOT See the previous discussion.
EMPLOYEE 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 FOREIGN KEY
CHARTER CHAR_PILOT (references PILOT)
CHAR_COPILOT (references PILOT)
AC_NUMBER (references AIRCRAFT)
CUS_CODE (references CUSTOMER)
AIRCRAFT MOD_CODE
MODEL None
PILOT EMP_NUM (references EMPLOYEE)
EMPLOYEE None
CUSTOMER None

e. A secondary key
TABLE SECONDARY KEY
CHARTER CHAR_DATE + AC_NUMBER + CHAR_DESTINATION
AIRCRAFT MOD_CODE
MODEL MOD_MANUFACTURER + MOD_NAME
PILOT PIL_LICENSE + PIL_MED_DATE
EMPLOYEE EMP_LNAME + EMP_FNAME + EMP_DOB
CUSTOMER CUS_LNAME + CUS_FNAME + CUS_PHONE

For use with Database Principles, Second Edition, Cengage Learning EMEA
26. Create the ERD using UML notation. (Hint: Look at the table contents. You will discover that
an AIRCRAFT can fly many CHARTER trips, but each CHARTER trip is flown by one
AIRCRAFT. Similarly, you will discover that a MODEL references many AIRCRAFT, but
each AIRCRAFT references a single MODEL, etc.)

The UML ERD is shown in Figure P3.26. The optional (default) 1:1 relationship crops up in this
ERD and 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 5 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.26 The Ch03_AviaCo Database ERD

For use with Database Principles, Second Edition, Cengage Learning EMEA
27. Modify the ERD you created in Problem 26 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 ERD is shown in Figures P3.27b.

Figure P3.27b The Ch03_AviaCo_2 Database ERD

For use with Database Principles, Second Edition, Cengage Learning EMEA