Chapter 6

Data Modelling Advanced Concepts

Selected Answers to Review Questions
1. What is an entity supertype, and why is it used?

An entity supertype is a generic entity type that is related to one or more entity subtypes, where the
entity supertype contains the common characteristics and the entity subtypes contain the unique
characteristics of each entity subtype. The reason for using supertypes is to minimize the number of
nulls and to minimize the likelihood of redundant relationships.

3. What is a specialization hierarchy?

A specialization hierarchy depicts the arrangement of higher-level entity supertypes (parent

entities) and lower-level entity subtypes (child entities). To answer the question precisely, we have
used the text’s Figure 6.2. (We have reproduced the figure on the next page for your convenience.)
Figure 6.2 shows the specialization hierarchy formed by an EMPLOYEE supertype and three entity
subtypes—PILOT, MECHANIC, and ACCOUNTANT.

For use with Database Principles, Second Edition, Cengage Learning EMEA
FIGURE 6.2 A Specialization Hierarchy – from the text book

The specialization hierarchy shown in Figure 6.2 reflects the 1:1 relationship between EMPLOYEE
and its subtypes. For example, a PILOT subtype occurrence is related to one instance of the
EMPLOYEE supertype and a MECHANIC subtype occurrence is related to one instance of the
EMPLOYEE supertype.

5. What is an overlapping subtype? Give an example.

Overlapping subtypes are subtypes that contain non-unique subsets of the supertype entity set; that
is, each entity instance of the supertype may appear in more than one subtype. For example, in a
university environment, a person may be an employee or a student or both. In turn, an employee may
be a professor as well as an administrator. Because an employee also may be a student, STUDENT
and EMPLOYEE are overlapping subtypes of the supertype PERSON, just as LECTURER and
ADMINISTRATOR are overlapping subtypes of the supertype EMPLOYEE. The text’s Figure 6.4
(reproduced next for your convenience) illustrates overlapping subtypes.

For use with Database Principles, Second Edition, Cengage Learning EMEA
 FIGURE 6.4 Specialization Hierarchy with Overlapping Subtypes

7. What is an entity cluster, and what advantages are derived from its use?

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

9. Under what circumstances would composite primary keys be appropriate?

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 *:* relationship.
• As identifiers of weak entities, where the weak entity has a strong identifying relationship with
the parent entity.

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 a *:* relationship via an ENROLL entity set in
which each student/class combination may appear only once in the composite entity. The text’s
Figure 6.7 (reproduced here for your convenience) shows the ERD to represent such a relationship.

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

STU_NUM STU_LNAME STU_FNAME STU_INIT

321452 Bowser William C
324257 Smithson Anne K
324258 Brewer Juliette
324269 Oblonski Walter H
324273 Smith John D
324274 Katinga Raphael P
324291 Robertson Gerald T
324299 Smith John B

Table name: ENROLL

CLASS_CODE STU_NUM ENROLL_GRADE

10014 321452 C
10014 324257 B
10018 321452 A
10018 324257 B
10021 321452 C
10021 324257 C

Table name: CLASS

CLASS_CODE CRS_CODE CLASS_SECTION

10012 ACCT-211 1
10013 ACCT-211 2
10014 ACCT-211 3
10015 ACCT-212 1
10016 ACCT-212 2
10017 CIS-220 1
10018 CIS-220 2
10019 CIS-220 3
10020 CIS-420 1
10021 QM-261 1
10022 QM-261 2
10023 QM-362 1
10024 QM-362 2
10025 MATH-243 1

FIGURE 6.7 *:* Relationship Between Student and Class

As shown in the text’s Figure 6.7, 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 cases:
1. A real-world object that is existent 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 independent of each other. However, such objects can exist in the model only

For use with Database Principles, Second Edition, Cengage Learning EMEA
 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 cases, 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.

11. 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?

Section 6.4.1 provides a detailed discussion. The text’s Table 6.6, reproduced here for your
convenience, shows the rationale for selecting the foreign key in a 1:1 relationship based on the
relationship properties in the ERD.

Case ER Relationship Constraints Action

I One side is mandatory and the Place the PK of the entity on the mandatory side in
other side is optional. the entity on the optional side as a FK and make the
FK mandatory.
II Both sides are optional. Select the FK that causes the fewest number of nulls
or place the FK in the entity in which the
(relationship) role is played.
III 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
entity.

TABLE 6.6 Selection of Foreign Key in a 1:1 Relationship

13. What is the most common design trap, and how does it occur?

A design trap occurs when a relationship is improperly or incompletely identified and therefore, it is
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:* relationships to other
entities, thus producing an association among the other entities that is not expressed in the model.

For use with Database Principles, Second Edition, Cengage Learning EMEA
15. Using the design checklist shown in this chapter, what characteristics should entities have?

The points stressed in database design are discussed in detail in Section 6.5, “Data Modeling
Checklist.” Database design is based on data modeling principles. Therefore, note that we have not
made a distinction between data modeling requirements and design requirements.

Entity requirements:
• All entities should represent a single subject.
• All entities should be in 3NF or higher.
• The granularity of the entity instance is clearly defined.
• The PK is clearly defined and supports the selected data granularity.

For use with Database Principles, Second Edition, Cengage Learning EMEA
Selected Problem Solutions
1. AVANTIVE Corporation is a company specializing in the commercialization of automotive
parts. AVANTIVE has two types of customers: retail and wholesale. All customers have a
customer ID, a name, an address, a phone number, a default shipping address, a date of last
purchase, and a date of last payment. Retail customers have the credit card type, credit card
number, expiration date, and e-mail address. Wholesale customers have a contact name,
contact phone number, contact e-mail address, purchase order number and date, discount
percentage, billing address, tax status (if exempt), and tax identification number. A retail
customer cannot be a wholesale customer and vice versa. Given that information, create the
ERD containing all primary keys, foreign keys, and main attributes.

The solution is shown in Figure P6.1 Avantive Corporation:

FIGURE P6.1 Avantive Corporation

For use with Database Principles, Second Edition, Cengage Learning EMEA
3. AVANTIVE Corporation operates under the following business rules:
• AVANTIVE keeps a list of cars models with information about the manufacturer, model,
and year. AVANTIVE keeps several parts in stock. A part will have a part ID, description,
unit price, and quantity on hand. A part can be used for many car models, and a car model
has many parts.
• A retail customer normally pays by credit card and is charged the list price for each
purchased item. A wholesale customer normally pays via purchase order with terms of net
30 days and is charged a discounted price for each item purchased. (The discount varies
from customer to customer.)
• A customer (retail or wholesale) can place many orders. Each order will have an order
number; a date; a shipping address; a billing address; and a list of part codes, quantities,
unit prices, and extended line totals. Each order also has a sales representative ID (an
employee) to identify the person who made the sale, an order subtotal, an order tax total, a
shipping cost, a shipping date, an order total cost, an order total paid, and an order status
(open, closed, or cancel).

Given that information, create the complete ERD containing all primary keys, foreign keys,
and main attributes.

The solution is shown in Figure P6.3 Avantive Corporation Full

For use with Database Principles, Second Edition, Cengage Learning EMEA
FIGURE P6.3 Avantive Corporation
Full

For use with Database Principles, Second Edition, Cengage Learning EMEA
For use with Database Principles, Second Edition, Cengage Learning EMEA
5. Tiny University wants to keep track of the history of all administrative appointments (date of
appointment and date of termination). (Hint: Time variant data are at work.) The Tiny
University chancellor may want to know how many deans worked in the School of Business
between January 1, 1960 and January 1, 2006 or who the dean of the School of Education was
in 1990. Given that information, create the complete ERD containing all primary keys, foreign
keys, and main attributes.

The solution is shown in Figure P6.5 Tiny University History

FIGURE P6.5 Tiny University History

For use with Database Principles, Second Edition, Cengage Learning EMEA
7.
The FlyRight Aircraft Maintenance (FRAM) division of the FlyRight Company (FRC) performs
all maintenance for FRC’s aircraft. Produce a data model segment that reflects the following
business rules:
• All mechanics are FRC employees. Not all employees are mechanics.
• Some mechanics are specialized in engine (EN) maintenance. Some mechanics are
specialized in airframe (AF) maintenance. Some mechanics are specialized in avionics (AV)
maintenance. (Avionics are the electronic components of an aircraft that are used in
communication and navigation.) All mechanics take periodic refresher courses to stay
current in their areas of expertise. FRC tracks all course taken by each mechanic—date,
course type, certification (Y/N), and performance.
• FRC keeps a history of the employment of all mechanics. The history includes the date
hired, date promoted, date terminated, and so on. (Note: The “and so on” component is, of
course, not a real-world requirement. Instead, it has been used here to limit the number of
attributes you will show in your design.)

Given those requirements, create the ERD segment using UML notation.

The solution is shown in Figure P6.7 FlyRight.

For use with Database Principles, Second Edition, Cengage Learning EMEA
 FIGURE P6.7 FlyRight

TABLE P6-9 ERD Documentation

Table Unique, Not Null Index
Name Primary key (on candidate key) Explanation
Customer cus_id (surrogate) unique(cus_name) The unique index on cus_name is
used to ensure no duplicate customers
exist.
Region region_id (surrogate) unique(region_name) The unique index on region_name is
used to ensure that no duplicate
regions are entered.
Employee emp_id (surrogate) unique(emp_lname, The unique index on emp_lname,
emp_fname, emp_mi) emp_fname and emp_mi is used to
ensure that no duplicate employees
are entered.
Skill skill_id (surrogate) unique(skill_description) The unique index on skill_description
is used to ensure that no duplicate
skills are entered.

For use with Database Principles, Second Edition, Cengage Learning EMEA
 EmpSkill emp_id, skill_id The composite primary key ensures
(composite) that no duplicate skills are entered for
each employee.
Project prj_id (surrogate) unique(cus_id, The unique index on cus_id and
prj_description) prj_description is used to ensure that
no duplicate project entries exist for a
given customer.
PS ps_id (surrogate) unique( prj_id, ps_task, The unique index on prj_id, ps_task
(project skill_id) and skill_id is used to ensure that no
schedule) duplicate skills within a given task
for the same project exist.
Assign asn_id (surrogate) unique (ps_id, emp_id) The unique index on ps_id and
emp_id is used to ensure that an
employee cannot be assigned twice to
the same project’s scheduled task.
Worklog wl_id (surrogate) unique(asn_id, wl_date) The unique indexes on asn_id and
wl_date are used to ensure that no
duplicate work log entries exist (for
an employee) on a given date.
Bill bill_id (surrogate)

It is important to point out to your students that the surrogate primary keys are usually not shown in the
graphical user interfaces that are available to the end users. The only function of the surrogate primary
key is to provide a single-attribute identifier for each row in the table.

The completed ERD for the GCS database is shown in Figure P6-9C.

For use with Database Principles, Second Edition, Cengage Learning EMEA
Figure P6-9C – ERD for the GCS Database

For use with Database Principles, Second Edition, Cengage Learning EMEA
Case Study Solutions

1. Wharfe Dale Bike Rentals

Wharfe Dale Bike Rentals is a small family owned business located in a small village in Cumbria,
United Kingdom. Tourists regularly visit the area to admire the countryside and cycle around the areas
many lakes. The main business of Wharfe Dale Bike Rentals is in acquiring bikes to hire to tourists,
maintaining those bikes to ensure a good working order, and to sell on bikes that are no longer suitable
for hiring.

Create a complete ERD to support the business needs described below:

• Every bike has a bike record and is identified by a unique number. For each bike the model,
manufacturer, and type (e.g. mountain or road) is recorded along with the size (e.g. infant, child,
teenager, adult etc.). After a bike has reached the end of its lifespan (typically 3 years but dependent on
usage) it is sold on to a dealer. The price it is sold for and the date are also recorded in the bike record.

• Wharfe Dale Bike Rentals have a number of dealers they sell to on a regular basis and maintain a
list which contains the dealers contact information. A dealer may or may not purchase a bike depending
on its condition. If the bike is in poor condition then it is not offered to a dealer and just scrapped.

• Each bike is associated with a class size code which is used to determine standard rates for the
period of hire (half day or full day). The class sizes of bike are {Infant, Child_young, Child_old,
Teenager, Standard_Adult and Large_Adult).For each class size a unique code is assigned along with
the half day and full day rates.

• After a bike has been returned, it is checked to ensure that it is still in good working order. It a
fault is noticed it is recorded in the Bikes Maintenance Log. A description of the fault, the date it was
noticed is recorded. When the bike has been repaired the action that was taken and the date are also
recorded. For example, a typical problem is that new tyres are required. Over its lifespan, a bike will
undergo maintenance on a regular basis however it is possible that a bike may never need maintenance.

• Customers make a request to hire bikes by either telephoning Wharfe Dale Bike Rentals or by
simply walking into the shop. If a customer agrees to hire a bike(s) then their name, address and contact
details are recorded. A customer can rent one or more bikes at a given time.

• For each bike that is rented, a rental record is created. This contains the rental date, the time the
bike was taken out, the time it was due back and the actual time it was returned. In addition the amount
of rent paid is recorded which is determined through the class size code. Each rental record is associated
with only one customer. A bike can be rented out any number of times or may never be rented.

• When a bike is being maintained, an employee of Wharfe Dale Bike Rentals will be responsible
for ordering additional bike parts that are required. Typically orders are placed on Fridays each week,
for delivery on Mondays. An employee may place any number of orders. An order consists of an order

For use with Database Principles, Second Edition, Cengage Learning EMEA
number, order date, a subtotal of the order, any associated delivery costs and a grand order total. Only
one employee can be associated in placing one order but over time employees can place many orders.

• A order can be made for many parts and parts can be ordered on multiple occasions. Each part
is identified by a unique number, a part description and part cost. An order must be for at least one part
but can often contain a request for several of the same parts e.g. 3 explorer mountain bike large saddles.

• A particular part can always be obtained from any number of manufacturers. If a part is not in
stock with one manufacturer, others can be checked to see if they have the part in stock. Wharfe Dale
Bike Rentals keep a list of Manufacturers they use on a regular basis. For each manufacture the
following information is recorded: the name, address, telephone number and email address.

• Each order is placed with one manufacturer and a manufacturer may supply parts via orders to
Wharfe Dale Bike Rentals on a regular basis.

A solution to this case study is shown in Figure C1.

For use with Database Principles, Second Edition, Cengage Learning EMEA
Figure C1 – ERD for Wharfe Dale Bike Rentals

3. Global Computer Solutions

Global Computer Solutions (GCS) is an information technology consulting company with many
offices located throughout the United States. The company’s success is based on its ability to
maximize its resources—that is, its ability to match highly skilled employees with projects according
to region. To better manage its projects, GCS has contacted you to design a database so that GCS
managers can keep track of their customers, employees, projects, project schedules, assignments,
and invoices.

For use with Database Principles, Second Edition, Cengage Learning EMEA
The GCS database must support all of GCS’s operations and information requirements. A basic
description of the main entities follows:

• The employees working for GCS have an employee ID, an employee last name, a middle initial,
a first name, a region, and a date of hire.
• Valid regions are as follows: Northwest (NW), Southwest (SW), Midwest North (MN), Midwest
South (MS), Northeast (NE), and Southeast (SE).
• Each employee has many skills, and many employees have the same skill.
• Each skill has a skill ID, description, and rate of pay. Valid skills are as follows: data entry I,
data entry II, systems analyst I, systems analyst II, database designer I, database designer II,
Cobol I, Cobol II, C++ I, C++ II, VB I, VB II, ColdFusion I, ColdFusion II, ASP I, ASP II,
Oracle DBA, MS SQL Server DBA, network engineer I, network engineer II, web administrator,
technical writer, and project manager. Table C3.A shows an example of the Skills Inventory.

Skill Employee
Data Entry I Seaton Amy; Williams Josh; Underwood Trish
Data Entry II Williams Josh; Seaton Amy
Systems Analyst I Craig Brett; Sewell Beth; Robbins Erin; Bush Emily; Zebras Steve
Systems Analyst II Chandler Joseph; Burklow Shane; Robbins Erin
DB Designer I Yarbrough Peter; Smith Mary
DB Designer II Yarbrough Peter; Pascoe Jonathan
Cobol I Kattan Chris; Epahnor Victor; Summers Anna; Ellis Maria
Cobol II Kattan Chris; Epahnor Victor, Batts Melissa
C++ I Smith Jose; Rogers Adam; Cope Leslie
C++ II Rogers Adam; Bible Hanah
VB I Zebras Steve; Ellis Maria
VB II Zebras Steve; Newton Christopher
ColdFusion I Duarte Miriam; Bush Emily
ColdFusion II Bush Emily; Newton Christopher
ASP I Duarte Miriam; Bush Emily
ASP II Duarte Miriam; Newton Christopher
Oracle DBA Smith Jose; Pascoe Jonathan
SQL Server DBA Yarbrough Peter; Smith Jose
Network Engineer I Bush Emily; Smith Mary
Network Engineer II Bush Emily; Smith Mary
Web Administrator Bush Emily; Smith Mary; Newton Christopher
Technical Writer Kilby Surgena; Bender Larry
Project Manager Paine Brad; Mudd Roger; Kenyon Tiffany; Connor Sean

Table C3.A Skills Inventory

For use with Database Principles, Second Edition, Cengage Learning EMEA
• GCS has many customers. Each customer has a customer ID, customer name, phone number, and
region.
• GCS works by projects. A project is based on a contract between the customer and GCS to
design, develop, and implement a computerized solution. Each project has specific
characteristics such as the project ID, the customer to which the project belongs, a brief
description, a project date (that is, the date on which the project’s contract was signed), a project
start date (an estimate), a project end date (also an estimate), a project budget (total estimated
cost of project), an actual start date, an actual end date, an actual cost, and one employee
assigned as manager of the project.
• The actual cost of the project is updated each Friday by adding that week’s cost (computed by
multiplying the hours each employee worked by the rate of pay for that skill) to the actual cost.
• The employee who is the manager of the project must complete a project schedule, which is, in
effect, a design and development plan. In the project schedule (or plan), the manager must
determine the tasks that will be performed to take the project from beginning to end. Each task
has a task ID, a brief task description, the task’s starting and ending date, the type of skill
needed, and the number of employees (with the required skills) required to complete the task.
General tasks are initial interview, database and system design, implementation, coding, testing,
and final evaluation and sign-off. For example, GCS might have the project schedule shown in
Table C3.B

Project ID: 1 Description: Sales Management System

Company : See Rocks Contract Date: 2/12/2010 Region: NW
Start Date: 3/1/2010 End Date: 7/1/2010 Budget: $15,500
Start End Task Skill(s) Quantity
Date Date Description Required Required
1/03/13 6/3/13 Initial Interview Project Manager 1
Systems Analyst II 1
DB Designer I 1
11/03/13 15/03/13 Database Design DB Designer I 1
11/03//13 12/04/13 System Design Systems Analyst II 1
Systems Analyst I 2
18/03/13 22/03/13 Database Implementation Oracle DBA 1
25/03/13 20/03/13 System Coding & Testing Cobol I 2
Cobol II 1
Oracle DBA 1
25/03/13 07/06/13 System Documentation Technical Writer 1
10/06/13 14/06/13 Final Evaluation Project Manager 1
Systems Analyst II 1
DB Designer I 1
Cobol II 1
17/06/13 21/06/13 On-Site System Online and Project Manager 1
Data Loading Systems Analyst II 1
DB Designer I 1
Cobol II 1
01/07/13 01/07/13 Sign-Off Project Manager 1

For use with Database Principles, Second Edition, Cengage Learning EMEA
 Table C3.B Project Schedule Form

• Assignments: GCS pools all of its employees by region, and from this pool, employees are
assigned to a specific task scheduled by the project manager. For example, for the first project’s
schedule, you know that for the period 1/03/13 to 06/03/13, a Systems Analyst II, a Database
Designer I, and a Project Manager are needed. (The project manager is assigned when the project
is created and remains for the duration of the project). Using that information, GCS searches the
employees who are located in the same region as the customer, matching the skills required and
assigning them to the project task.
• Each project schedule task can have many employees assigned to it, and a given employee can
work on multiple project tasks. However, an employee can work on only one project task at a
time. For example, if an employee is already assigned to work on a project task from 20/02/13 to
03/03/13, (s)he cannot work on another task until the current assignment is closed (ends). The
date on which an assignment is closed does not necessarily match the ending date of the project
schedule task, because a task can be completed ahead of or behind schedule. The date on which
an assignment is closed does not necessarily match the ending date of the project schedule task
because a task can be completed ahead of (or behind) schedule.
• Given all of the preceding information, you can see that the assignment associates an employee
with a project task, using the project schedule. Therefore, to keep track of the assignment, you
require at least the following information: assignment ID, employee, project schedule task, date
assignment starts, and date assignment ends (which could be any dates as some projects run
ahead of or behind schedule). Table C3.C shows a sample assignment form.

For use with Database Principles, Second Edition, Cengage Learning EMEA
Project ID: 1 Description: Sales Management System
Company: See Rocks Contract Date: 2/12/2010 As of: 03/29/10
SCHEDULED ACTUAL ASSIGNMENTS
Project Start End Date Start End
Task Date Skill Employee Date Date
Initial 01/03/13 06/03/13 Project Mgr. 101—Connor 3/1/10 3/6/10
Interview Sys. Analyst II S. 3/1/10 3/6/10
DB Designer I 102—Burklow 3/1/10 3/6/10
S.
103—Smith M.
Database 11/03/13 15/03/13 DB Designer I 104—Smith M. 3/11/10 3/14/10
Design
System Design 11/03/13 12/04/13 Sys. Analyst II 105—Burklow 3/11/10
10 Sys. Analyst I S. 3/11/10
Sys. Analyst I 106—Bush E. 3/11/10
107—Zebras S.
Database 18/03/13 22/03/13 Oracle DBA 108—Smith J. 3/15/10 3/19/10
Implementation
System Coding 25/03/13 20/05/13 Cobol I 109—Summers 3/21/10
& Testing Cobol I A. 3/21/10
Cobol II 110—Ellis M. 3/21/10
Oracle DBA 111—Ephanor 3/21/10
V.
112—Smith J.
System 25/03/13 07/06/13 Tech. Writer 113—Kilby S. 3/25/10
Documentation
Final 10/06/13 14/06/13 Project Mgr.
Evaluation Sys. Analyst II
DB Designer I
Cobol II
On-Site System 17/06/13 21/06/13 Project Mgr.
Online and Sys. Analyst II
Data Loading DB Designer I
Cobol II
Sign-Off 1/07/13 1/07/13 Project Mgr.

Table C3.C Project Assignment Form

(Note: The assignment number is shown as a prefix of the employee name; for example, 101,
102.) Assume that the assignments shown previously are the only ones existing as of the date of
this design. The assignment number can be whatever number matches your database design.

For use with Database Principles, Second Edition, Cengage Learning EMEA
• The hours an employee works are kept in a work log containing a record of the actual hours
worked by an employee on a given assignment. The work log is a weekly form that the employee
fills out at the end of each week (Friday) or at the end of each month. The form contains the date
(of each Friday of the month or the last work day of the month if it doesn’t falls on a Friday), the
assignment ID, the total hours worked that week (or up to the end of the month), and the number
of the bill to which the work log entry is charged. Obviously, each work log entry can be related
to only one bill. A sample list of the current work log entries for the first sample project is shown
in Table C3.D
Employee Week Assignment Hours Bill
Name Ending Number Worked Number
Burklow S. 01/03/13 1-102 4 xxx
Connor S. 01/03/13 1-101 4 xxx
Smith M. 01/03/13 1-103 4 xxx
Burklow S. 08/03/13 1-102 24 xxx
Connor S. 08/03/13 1-101 24 xxx
Smith M. 08/03/13 1-103 24 xxx
Burklow S. 15/03/13 1-105 40 xxx
Bush E. 15/03/13 1-106 40 xxx
Smith J. 15/03/13 1-108 6 xxx
Smith M. 15/03/13 1-104 32 xxx
Zebras S. 15/03/13 1-107 35 xxx
Burklow S. 22/03/13 1-105 40
Bush E. 22/03/13 1-106 40
Ellis M. 22/03/13 1-110 12
Ephanor V. 22/03/13 1-111 12
Smith J. 22/03/13 1-108 12
Smith J. 22/03/13 1-112 12
Summers A. 22/03/13 1-109 12
Zebras S. 22/03/13 1-107 35
Burklow S. 29/03/13 1-105 40
Bush E. 29/03/13 1-106 40
Ellis M. 29/03/13 1-110 35
Ephanor V. 29/03/13 1-111 35
Kilby S. 29/03/13 1-113 40
Smith J. 29/03/13 1-112 35
Summers A. 29/03/13 1-109 35
Zebras S. 29/03/13 1-107 35
Note: xxx represents the bill ID. Use the one that matches the bill
number in your database.

Table C3.D Project Work-Log Form as of 29/03/13

(Note: xxx represents the bill ID. Use the one that matches the bill number in your database.)

For use with Database Principles, Second Edition, Cengage Learning EMEA
• Finally, every 15 days, a bill is written and sent to the customer, totaling the hours worked on the
project that period. When GCS generates a bill, it uses the bill number to update the work-log
entries that are part of that bill. In summary, a bill can refer to many work log entries, and each
work log entry can be related to only one bill. GCS sent one bill on 15/03/13 for the first project
(See Rocks), totaling the hours worked between 03/01/13 and 15/03/13. Therefore, you can
safely assume that there is only one bill in this table and that that bill covers the work-log entries
shown in the above form.

Your assignment is to create a database that will fulfill the operations described in this problem. The
minimum required entities are employee, skill, customer, region, project, project schedule,
assignment, work log, and bill. (There are additional required entities that are not listed.)
• Create all of the required tables and all of the required relationships.
• Create the required indexes to maintain entity integrity when using surrogate primary keys.
• Populate the tables as needed (as indicated in the sample data and forms).

This is a complex database design case that requires the identification of many business rules, the
organization of those business rules, and the development of a complete database model. Note that
this database design case has three primary objectives:
• Evaluation of primary keys and surrogate keys. (When should each one be used?)
• Evaluation of the use of indexes on candidate keys to avoid duplicate entries when using
surrogate keys.
• Evaluation of the use of redundant relationships. In some cases, it is better to have the foreign
key attribute added to an entity, instead of using multiple join operations.

We recommend that you use this problem as the basis for a two part case project. One way to work
with this database case is to form small groups of two or three students and then let each group work
the problem independently. The following bullet list provides a sample scenario:
• Divide the class in groups of three students per group.
• Distribute the GCS database case to all students.
• Assign a deadline for the groups to submit an initial design ERD with written explanations of
the ERD components and features. This deadline should be two weeks from the assignment
date. (While the groups are working on the design phase, students will be learning to use
SQL to generate information.)
• The initial ERD must include:
 All the main entities with all primary/foreign keys clearly labeled.
 The identification of all relevant dependent attributes.
 For each table, the identification of all possible required indexes.
• Meet with each group and evaluate each design, paying close attention to:
 The propagation of primary/foreign keys and how surrogate keys would be useful to
simplify the design.
 The use of indexes to minimize the occurrence of duplicate entries.
 By this time, students should be familiar with SQL. Ask questions about how a query
would be written to generate information. You can use the sample queries provided in
the GCSdata-sol.mdb teacher solution file. This database is located on your
Instructor’s CD.)

For use with Database Principles, Second Edition, Cengage Learning EMEA
 Please note that there are two database files available:

• The GCSdata.mdb database is located in the Student subfolder on the Instructor’s CD. This
MS Access database contains the sample CUSTOMER, EMPLOYEE, REGION, and SKILL
tables. You can either distribute this file to your students by copying it to a common drive in
your lab or you can ask your students to download this file from the Course Technology
website for this book.
• The GCSdata-sol.mdb database is located in the Teacher subfolder on the Instructor’s CD.
This MS Access database contains the complete set of populated tables. In addition, the
solution database contains some sample queries. You can use the sample queries as the basis
for second part of this case, which may be used to complement the SQL coverage in chapters
7 and 8.

Figure C3-1 shows the sample tables in the GCSdata.mdb student database.

For use with Database Principles, Second Edition, Cengage Learning EMEA
Figure C3-1 GCS Student Sample Database Tables

The GCSdata-sol.mdb file contains the solution for this design case. Figure C3-2 shows the relational
diagram for the solution.

For use with Database Principles, Second Edition, Cengage Learning EMEA
Figure C3-2 – Relational Diagram for the GCS Database

To help your students understand the ERD, use Table C3-E to describe the main tables and the main
indexes that are appropriate for this design implementation.

For use with Database Principles, Second Edition, Cengage Learning EMEA
TABLE C3-E ERD Documentation
Table Unique, Not Null Index
Name Primary key (on candidate key) Explanation
Customer cus_id (surrogate) unique(cus_name) The unique index on cus_name is
used to ensure no duplicate customers
exist.
Region region_id (surrogate) unique(region_name) The unique index on region_name is
used to ensure that no duplicate
regions are entered.
Employee emp_id (surrogate) unique(emp_lname, The unique index on emp_lname,
emp_fname, emp_mi) emp_fname and emp_mi is used to
ensure that no duplicate employees
are entered.
Skill skill_id (surrogate) unique(skill_description) The unique index on skill_description
is used to ensure that no duplicate
skills are entered.
EmpSkill emp_id, skill_id The composite primary key ensures
(composite) that no duplicate skills are entered for
each employee.
Project prj_id (surrogate) unique(cus_id, The unique index on cus_id and
prj_description) prj_description is used to ensure that
no duplicate project entries exist for a
given customer.
Task task_id (surrogate) unique(prj_id, The unique index on prj_id and
(project task_descript) task_descript is used to ensure that no
schedule) duplicate task is given for the same
project.
TS ts_id(surrogate) unique(task_id, skill_id) The unique index on task_id and
(task skill_id is to prevent duplicate listings
schedule) for a single skill within a single task
for a single project.
Assign asn_id (surrogate) unique (ps_id, emp_id, The unique index on ps_id, emp_id,
ts_id) and ts_id is used to ensure that an
employee cannot be assigned twice to
perform the same skill on the same
task for a given project.
Worklog wl_id (surrogate) unique(asn_id, wl_date) The unique indexes on asn_id and
wl_date are used to ensure that no
duplicate work log entries exist (for
an employee) on a given date.
Bill bill_id (surrogate)

For use with Database Principles, Second Edition, Cengage Learning EMEA
It is important to point out to your students that the surrogate primary keys are usually not shown in the
graphical user interfaces that are available to the end users. The only function of the surrogate primary
key is to provide a single-attribute identifier for each row in the table.
The completed ERD for the GCS database is shown in Figure C3-3

Figure C3-3 – ERD for the GCS Database

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