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

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

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)

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.

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

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.

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

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)

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)

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)

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)

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)

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)

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)

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

Problem 1.14b The Initial Library Relational Schema

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!

Problem 1.14d The Corrected Library Relational Schema

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)

Initial (logical) design Expanded and implementable design Problem 1.18 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)

Figure P1-19 The PumpCo Relational Schema

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)

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

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

The End