1. Chapter 1 Problem Solutions
Peter Rob and Elie Semaan Databases: Design, Development, and Deployment Using Microsoft Access
Second Edition

2. Problem 1.4 ERD 1 EMPLOYEE (0,N) writes 1 M (1,1) M CUSTOMER initiates
CONTRACT
(0,N)
(1,1)

3. Problem 1.5b (JewelCo ERD)
CUSTOMER
generates
INVOICE
(0,N)
(1,1) 1
(1,N)
includes M
(1,1) M 1
LINE
references
JEWELER
(1,1)
(0,N) M
(1,1) 1
(0,N)
contains 1
(0,N) M
JEWELRY
creates
(1,1)

4. Problem 1.7a The Revised EMPLOYEE Table Contents
This is a poor solution:
Proliferation of nulls. If an employee does not have any of the three skills shown in this EMPLOYEE table, that employee's record will contain three nulls. If an employee has only one of the skills shown in this EMPLOYEE table, that employee's record will contain two nulls. And so on. The proliferation of nulls is undesirable.
Frequent structural modifications. If an employee earns more than three skills, the table structure must be modified to accommodate the additional data. Structural modifications should be rare and they should not have to be made to simply accommodate multivalued attributes.

5. Problem 1.8 ERD 1 M M 1 EMPLOYEE CUSTOMER SKILL JOB (0,N) (1,1) (1,1)

6. Problem 1.8a-c The Implementation of the Revised Design
The Revised EMPLOYEE Table (EMPLOYEE_P1_8a)
The SKILL Table (SKILL_P1_8c)
The JOB Table (JOB_P1_8b)
This is a good solution:
Elimination of nulls. If an employee does not have any tracked skills, that employee simply does not show up in the composite SKILL table.
No structural modifications needed to accommodate additional skills. If an employee earns additional skills, all that’s needed is an additional record in the composite SKILL table.

7. Problem 1.9 ERD 1 M A x B 1 M M 1 C D

8. Problem 1.11a ConsultCo ERD
is rep to
EMPLOYEE
QUALIFICATION
(0,N)
(0,N)
(1,1)
(0,N)
(0,N)
(1,1) M 1 1
(0,N) 1
coordinates
leads
JOB_CLASS
(0,N) 1 M
(1,1) M
(1,1)
(1,1) M 1 M
CUSTOMER
contracts
PROJECT
(0,N)
(1,1)
(1,1) 1
(1,N) M
(1,1) M
CHARGE
(1,1) M
(1,1)

9. Problem 1.11b ConsultCo ERD
is rep to
EMPLOYEE
QUALIFICATION
(0,N)
(0,N)
(1,1) 1
(0,N)
(1,1) M M
(1,1)
(0,N) 1
MANAGEMENT
JOB_CLASS M
(1,1)
(0,N) 1 M
(1,1) 1
(0,N) 1 M
CUSTOMER
contracts
PROJECT
(0,N)
(1,1) 1
(1,N) M
(1,1) M
CHARGE
(1,1) M
(1,1)

10. Problem 1.12a LuxMobile ERD
(Version 1)
PART 1
(0,N) 1 M
is found in
CUSTOMER
CUSTOMER
makes
PAYMENT
(0,N)
(1,1) 1
(0,N) 1
(0,N) M
(0,1) M
references
EMPLOYEE
LINE
owns M
(1,1)
(1,1) M
(1,1) M
(1,1) 1 M 1
CAR
enters
CUSTOMER
LOG
contains
(1,N)
(0,N)
(1,1)
(1,1) M M
(1,1)
opens
closes 1 1
(0,N)
(0,N) 1 1 1
EMPLOYEE
EMPLOYEE
is a
MECHANIC
EMPLOYEE
signs
(0,1)
(1,1)
(0,N)

11. Problem 1.12b LuxMobile ERD
(Version 1)
PART 1
(0,N) 1 M
is found in
CUSTOMER
CUSTOMER
makes
PAYMENT
(0,N)
(1,1) 1
(0,N) 1
(0,N) M
(0,1) M
EMPLOYEE
LINE
references
owns M
(1,1)
(1,1) M
(1,1) M
(1,1) 1 M 1
CAR
enters
CUSTOMER
LOG
contains
(1,N)
(0,N)
(1,1) 1
(0,N) M
(1,1)
ACTION M
(1,1) 1
(0,N) 1 1 1
EMPLOYEE
EMPLOYEE
is a
MECHANIC
EMPLOYEE
signs
(0,1)
(1,1)
(0,N)

12. Problem 1.13a RentAll ERD, version 1
Note: If the unit cannot be repaired, it is scrapped and taken out of inventory. Therefore, it will be possible for REPAIR_LOG to contain a foreign key reference to a unit that no longer exists. For this reason, the REPAIR_LOG and UNIT records must be archived for the scrapped unit.
Problem 1.13a RentAll ERD, version 1
Note: From a pure design perspective, it would be appropriate to model the rental process through a composite entity.
In this ERD, the design reflects the end user
interface requirements. The price for this
decision is that the rental return date and the
employee who processes the return remain
null until the unit is returned. If it is not necessary to track which employee performed each rental transaction, the design can be simplified by eliminating the relation- ships between EMPLOYEE and RENTAL.
EMPLOYEE
CUSTOMER
REPAIR_LOG 1
(0,N)
(0,N) 1
(1,1) M
writes
requires
completes M
(1,1)
(1,1) M 1
(0,N) 1 1 M
CUSTOMER
CUSTOMER
makes
RENTAL
UNIT
(0,N)
(0,N)
(1,1) 1
(1,N)
(1,1) M
contains
references M
(1,1) M
(1,N) 1
LINE
lists
EQUIPMENT
(1,1)

13. Problem 1.13b RentAll ERD, version 2 1 M opens (0,N) (1,1) 1 M
EMPLOYEE
CUSTOMER
closes
REPAIR_LOG
(0,N)
(1,1) 1
(0,N)
(0,N) 1
(1,1) M
writes
requires
completes M
(1,1)
(1,1) M 1
(0,N) 1 1 M
CUSTOMER
CUSTOMER
makes
RENTAL
UNIT
(0,N)
(0,N)
(1,1) 1
(1,N)
(1,1) M
contains
references M
(1,1) M
(1,N) 1
LINE
lists
EQUIPMENT
(1,1)

14. Problem 1.13c RentAll ERD, version 3 1 M M 1 EMPLOYEE CUSTOMER
REP_ENTRY
REPAIR_LOG
(0,N) 1
(0,N)
(1,1)
(1,1)
(0,N)
(1,1) M
(1,1) M
RENT_ENTRY
requires
(1,1) M
(0,N) 1 1
(0,N) 1 1 M
CUSTOMER
CUSTOMER
makes
RENTAL
UNIT
(0,N)
(0,N)
(1,1) 1
(1,N)
(1,1) M
contains
references M
(1,1) M
(1,N) 1
LINE
lists
EQUIPMENT
(1,1)

15. Problem 1.14a The Initial Library ERD
EMPLOYEE
writes
(0,N) 1 M
(1,1) M M 1
CUSTOMER
makes
LOAN
lists
BOOK
(0,N)
(1,1)
(1,1)
(0,N)
(1,N) 1
Note: This design illustrates three major design flaws. First, each loan record records only a single book check-out. Therefore, if a customer wants to check out five books, five separate loans must be generated, one per book. Second, the book categories (fiction, computers, business, etc.) must be recorded in BOOK, thus producing the kind of redundancy that creates anomalies. Third, the relationship between LOAN and BOOK is not appropriate. (If a book has three copies in “inventory,” customers check out one of the book’s copies. The remaining two copies are still available.) It would be better to create a relationship between LOAN and COPY. To give you a chance to learn how to make corrections, this poor design is implemented in the LIBRARY database and its applications interface will need considerable rework. The applications interface is corrected in LIBRARY-2, and the design is corrected -- and implemented correctly -- in LIBRARY-3. (You will still have to modify the applications interface to match the corrected design!)
has
(1,1) M
COPY

16. Problem 1.14b The Initial Library Relational Schema

17. Problem 1.14c The Corrected Library ERD
EMPLOYEE
writes
(0,N) 1 M
(1,1) M M
CUSTOMER
makes
LOAN
fits
BOOK
(1,1)
(0,N)
(1,1) 1
(1,N)
(1,N) 1 1
(0,N)
contains
CATEGORY
references M
(1,1) M 1
(1,1) M
LOAN_LINE
lists
COPY
(1,1)
(0,N)
Note: This design still requires some tweaking. For example, it might be wise to include a transactions entity to track fines paid for over-due books.
And did you notice that the relationships between LOAN, LOAN_LINE, and COPY match those found in the INVOICE, INVOICE_LINE, and PRODUCT invoicing environment? The main difference is that the library’s “product” is expected to be returned!

18. Problem 1.14d The Corrected Library Relational Schema

19. Problem 1.15 The L_League ERD
ORGANIZATION 1
(0,N) M
(1,1)
SPONSOR M
(1,1) 1
(1,N) M 1 1
COACH
is coached by
TEAM
uses
(0,1)
(1,N)
(10,N) M
(1,N) 1
(0,N)
(0,N) 1
(1,1) M
Note: Remember that the relationship is read from the 1 to the M side. For example, CITY owns TEAM. Also, optionalities are often used for operational reasons. For example, the COACH table may include people who are available, but who have not (yet) been assigned to coach a team.
owns
PLAYER 1
(1,1)
CITY M M
GAME
(1,1)
(1,1)

20. Initial (logical) design Expanded and implementable design
Problem The PumpCo ERD
Initial (logical) design 1 M M 1
CUSTOMER
PART
ORDER
VENDOR
(0,N)
(1,1)
(1,1)
(0,N)
Expanded and implementable design 1 M
VENDOR
receives
ORDER
(0,N)
(1,1) 1
(1,N)
contains M
(1,1) 1 M
PART
CUSTOMER
is found in
ORDER_LINE
(0,N)
(1,1)

21. Figure P1-19 The PumpCo Relational Schema

22. Problem 1.20 The Chen AC_Museum ERD
makes
CONTRIBUTION
(1,1) 1
(0,N)
DONOR 1 M 1
(0,N) 1 1
is a
STORY
REFERENCE
(0,1)
(1,1)
(0,N)
donates
(1,1)
(0,N) M
(1,1) M
(1,1) 1
(0,N) M 1 1 1
DONATION
is an
ARTIFACT
yields
AIRCRAFT
(0,1)
(1,1)
(0,1)
(0,N) M
(1,1) 1
MODEL
describes
(0,N)

23. Problem 1.21 The Enhanced Chen AC_Museum ERD
makes
CONTRIBUTION
(1,1)
CONTRIB_NUM (PK) M 1
(0,N)
DONOR_NUM (FK)
CONTRIB_DATE
CONTRIB_AMOUNT
includes
REFERENCE
DONOR
(1,1)
STORY_NUM (PK,FK)
AC_NUM (PK,FK)
DONOR_NUM (PK) 1
(0,N) 1
DONOR_LNAME
is a
STORY
PHOTO_PATH
(1,1) 1
(0,N) 1
STORY_NUM (PK) M
(1,1)
DONATE_NUM (FK)
STORY_TEXT
(0,1)
donates
is found in 1 M
is an
ARTIFACT M
(1,1)
(0,1) 1
(0,N)
(1,1) 1 1
ARTI_NUM (PK)
DONATION
yields
AIRCRAFT
DONATE_NUM (FK)
ARTI_DESCRIPT
AC_NUM (FK)
ARTI_LOCATION
PHOTO_PATH
(0,1)
(0,N)
DONATE_NUM (PK)
AC_NUM (PK)
DONOR_NUM (FK)
DONATE_DATE
DONATE_TYPE
MOD_CODE (FK)
AC_BLOCK
(1,1) 1 M
MODEL
describes
(0,N)
MOD_CODE (PK)
MOD_DESCRIPT
MOD_ENGINE

24. Problem 1.22 The Crow's Foot AC_Museum ERD
makes
CONTRIBUTION
CONTRIB_NUM (PK)
includes
DONOR_NUM (FK)
CONTRIB_DATE
CONTRIB_AMOUNT
REFERENCE
DONOR
STORY_NUM (PK,FK)
AC_NUM (PK,FK)
DONOR_NUM (PK)
DONOR_LNAME
STORY
PHOTO_PATH
STORY_NUM (PK)
is a
DONATE_NUM (FK)
STORY_TEXT
donates
is found in
ARTIFACT
is an
ARTI_NUM (PK)
yields
DONATION
AIRCRAFT
DONATE_NUM (FK)
ARTI_DESCRIPT
AC_NUM (FK)
ARTI_LOCATION
PHOTO_PATH
DONATE_NUM (PK)
AC_NUM (PK)
DONOR_NUM (FK)
DONATE_DATE
DONATE_TYPE
MOD_CODE (FK)
AC_BLOCK
describes
MODEL
MOD_CODE (PK)
MOD_DESCRIPT
MOD_ENGINE

25. The End