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

VEHICLE 1 references EMPLOYEE DRIVER M LICENSE 1 TYPE 1 (0,N) SCHOOL M (1,1) houses (0,N) ENDORSEMENT M (1,1) DEPENDENT is a 1 (0,N) M (1,1) DRIV_LICENSE 1 (0,N) (1,1) M (1,N) M (1,1) 1(0,N) BASE M locates (0,1) (1,1) 1 (0,N) M DRIV_ENDORSE (1,1) M has M (0,N)1 (1,1) Note that this ERD allows the TruckCo management to track from which school the license or the endorsement was earned, on what date each license and endorsement was earned, and so on. This ERD assumes that a driver can have more than one license and more than one endorsement. A driver must have at least one license, but may or may not have one or more endorsements.

AIRCRAFT 1 references CERTIFICATION 1 MODEL (0,N) M (1,1) (0,N) RENTAL 1 (1,1) M M 1 CUSTOMER 1 (0,N) QUALIFICATION (1,1) M (0,N) 1 M(1,1) Problem: This design does not include the ability to track payments on account, not does it enable Flyhigh’s management to track payment types -- cash, check, credit card, and payments on account. This design, while correct, is incomplete. (The design requires a TRANSACTION entity.)

AIRCRAFT 1 references CERTIFICATION 1 MODEL (0,N) M (1,1) (0,N) RENTAL 1 (1,1) M M 1 CUSTOMER 1 (0,N) QUALIFICATION (1,1) M (0,N) 1 M(1,1) 1(0,N)1 (1,1) makes M M(0,1) (1,N) Note: The TRANSACTION entity is used to track all payments, including any payments on account. To simplify the queries that will be used to report the current customer account balances, a derived attribute, perhaps named CUST_BALANCE, may be included in the CUSTOMER entity. The TRANSACTION entity would include such attributes as the date, the type (debit or credit), the amount, the customer reference, and the rental reference. The design is easily expanded to keep track of all balances for individual rental charges to help determine when “late” interest is appropriate. TRANSACTION Note: A customer may make multiple payments to pay off a charged rental activity. Therefore, a rent number may be referenced more than once in the TRANSACTION entity. However, each of the TRANSACTION entries references only one CUSTOMER and one RENTAL record.

Some sample TRANSACTION records are shown in Table 3.3. If you want to keep track of all balances by the rental number, add a column named TRANS_BALANCE. For example, customer number 123 charged a $ rental to his or her account on 18-May-2002 and paid $ on that rental on 20-May-2002, thus leaving a balance for that particular rental transaction of $ Such a “running balance” is desirable, but it takes some work to design the application to perform this task. Table 3.3 Sample TRANSACTION Records TRANS_NUMTRANS_DATETRANS_TYPECUST_NUMRENT_NUMTRANS_AMT May-2002Charge $ May-2002Payment $ May-2002Payment $ May-2002Charge $ May-2002Payment $ May-2002Payment $ May-2002Payment $ May-2002Charge $ May-2002Payment $200.00

Note: When the rental time has been calculated, that time must be used to update the appropriate fields in the AIRCRAFT and CUSTOMER tables. To make sure that the update is made only once, the RENTAL table contains a field, named RENT_UPDATED, that will be used to control the update process. Here is an example of an attribute (field) that is used to enable an application process, rather than to describe the entity. The RENT_CHG_HOUR is copied from the MODEL entity to ensure that the rental transactions are historically accurate. (Rental charges per hour can change over time!)

EMPLOYEE DRIVER LICENSE 11 SCHOOL M (1,1) (1,N) M (1,1) is a 1 M (1,1) QUALIFICATION (0,N) (1,1) (1,N) (1,1) 1 (0,1) 1 (1,N) 1 (0,1) (1,1) becomes a MECHANIC 1 All drivers and mechanics licenses and endorsements are stored in the LICENSE table. The QUALIFICATION table is used to store licenses and endorsements for all mechanics and drivers, as well as the date on which each qualification was earned and the school (number) from which the qualification was earned. SCHOOL_LICENSE 1 (1,1)(0,N) Each mechanic and driver must have at least one license. Therefore, QUALIFICATION is mandatory to both DRIVER and MECHANIC. Not all approved schools are necessarily represented. For example, there may be 15 approved schools, but TruckCo’s drivers and mechanics have graduated from only a few of these schools. Therefore, the entity named SCHOOL_LICENSE is optional to SCHOOL. 1 M M 1

MAINT_LOG 1 closes 1 (0,N) M (1,1) (0,N) MECH_LOG (1,1) M MECHANIC 1 M (0,N) 1 MECHANIC MAINT_LOG opens 1 M(1,1) Option 1: Each maintenance log opening and closing generates a separate record in the MECH_LOG table. This table records the date, the identity of the mechanic, and the log action (open or close) for each MAINT_LOG record. Option 2: Each maintenance log opening generates a record in MAINT_LOG. The record contains a null closing date and a null for the mechanic who closes the log … until the log is closed. Requires using synonyms. (Note that Access generates a “shadow” virtual table to indicate the use of multiple relationships.)

VEHICLE 1 references M 1 1 (0,N) M (1,1) houses (0,N) M (1,1) DEPENDENT is a 1 (0,N) M (1,1) 1 (0,N) (1,1) M (1,N) M (1,1) 1(0,N) M locates (0,1) (1,1) 1 (0,N) (1,1) DRIV_ENDORSE (1,1) M has M (0,N)1 (1,1) becomes DRIV_LICENSE signs (1,1) MECH_ENDORSE (0,N)1 M 1M M1 SCHOOL_LICENSE 1 M (0,N)(1,1) (0,N) M MECH_LICENSE M 1 (1,N) (1,1) M1 (0,N) DRIVER_LOGDRIV_TEST MECH_LOG MAINT_LOG 1M (1,1) is used in MAINT_DETAIL PART generates (1,N) M1 (0,N)(1,1) M 1 (0,N) 1M 1 M (1,1) 1 M (0,N) M 1 1M(1,1) M 1 (0,N) 1 M(1,1) 1 1 (0,1) (1,1)(1,N) (1,1) (0,N) M 1 (1,1) (0,N) SCHOOL EMPLOYEEDRIVER TYPE ENDORSEMENT BASE MECHANIC TEST LICENSE enters

PAYMENT INVOICEINV_LINECUSTOMER generatescontains makes ASSEMBLY PRODUCT PROD_RETURN yields PROD_RET_LINE is found in requests requires VENDOR ORDERORD_LINE receives is included in shows in PART PART_RET_LINEPART_RETURN approves includes has 1M M M 1 1M (0,N)(1,1) (1,N)(1,1)1 M (0,N)(1,1) (1,N) 1 (0,N) (1,1) is seen in M 1(0,N) (1,1) M MM M MM M (0,N) (1,N) (1,1) (1,N)(1,1) (1,N)1 (0,N) (1,1) (0,N) (1,N)(1,1) MM11 1 M (0,N) (1,1)

ASSEMBLY PRODUCT PART (0,N) (1,N) (1,1) contains (0,N) 11 MM 1 M(1,1) The M:N recursive relationship “PART includes PART” is implemented through the composite entity ASSEMBLY. By implementing such a design, the end user can track what components are found in each multi-component part. The design can easily be modified to track serialized parts that are found in each product.

INVOICECUSTOMER ACCOUNT PROD_RETURN producesINV_LINE PRODUCT contains referencesPROD_SERIAL has consists of enters makes generates PROD_SERIAL_PART_SERIAL creates yields PROD_RET_LINE possessesis shown in Connector to part 2 1M (0,N)(1,1) 1 1 M 1 M (0,N) (1,1) (0,N) (1,1) 1 M (1,N) 1 M (0,N) (1,1) 1M (0,N)(1,1) M (1,N) (0,1) 1 1 M (1,N)(0,N) (1,1) 1 M M 1 (1,N) M(1,1) 1 (1,N) (1,1) 1 Note: The ACCOUNT entity represents all the transactions. Because the transactions include product returns, customer payments, and in- voicing, the invoice number can occur many times in the ACCOUNT entity.

PRODUCT PART is found in PROD_PART ASSEMBLY appears in ORD_LINE ORDER includes VENDOR PART_RET_LINE PART_RETURN receives ORD_LINE_PART_SERIAL comprises ships PART_RET_LINE_PART_SERIAL holds Connector to Part 1 is included in produces 1 M(1,1) (1,N) (0,N) M 1 (1,1) 1M 1 M 1M (0,N)(1,1) (0,N) (1,1) 1 M (0,N) (1,1) 1 M (1,N) (1,1) 1 M (0,N) M1 (1,1) M 1(0,N) 1(1,1) 1 (0,N) 1M (1,1) 1 M (1,N)

(1,1) DONOR DONATION CONTRIBUTION (0,N) (1,1) (0,N) donates makes REFERENCE MODEL ARTIFACTAIRCRAFT 1 M M M 1 M (0,N) (1,1) 1 (0,1) (1,1) M 1 (0,1)(1,1) 1 is an is a STORY yields describes M 1 1 (0,1)(0,N)

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

DONOR DONATION CONTRIBUTION donates makes REFERENCE MODEL ARTIFACT AIRCRAFT is an is a STORY yields describes includes DONOR_NUM (PK) DONOR_LNAME CONTRIB_NUM (PK) DONATE_NUM (PK) DONOR_NUM (FK) CONTRIB_DATE CONTRIB_AMOUNT DONOR_NUM (FK) DONATE_DATE DONATE_TYPE STORY_NUM (PK) ARTI_NUM (PK) DONATE_NUM (FK) STORY_TEXT DONATE_NUM (FK) ARTI_DESCRIPT AC_NUM (FK) ARTI_LOCATION PHOTO_PATH MOD_CODE (PK) MOD_DESCRIPT MOD_ENGINE AC_NUM (PK) MOD_CODE (FK) AC_BLOCK STORY_NUM (PK,FK) AC_NUM (PK,FK) is found in PHOTO_PATH

WING SQUADRON ASSIGNMENT OTHER PERSONNEL AIRCRAFT M WING_COMM SQUA_COMM Note: The OTHER entity would be used to record assignment to an Air Force storage facility, a museum, a disposal unit (to scrap the aircraft), a flight research facility, or an Air Force / Air Guard facility in which the aircraft would be displayed as a so-called gate guard. 1 M 1 M M 1 M1 1 1 M M 1 (1,1) (0,N) (1,1) (0,N) (1,1) (0,N) (1,1) (0,N) (1,1)(0,N) (1,1)(0,N) (1,1) (0,N) (1,1) (0,N) 1 M Note: Optionalities are often used to make initial data entry easier. For example, an aircraft must be assigned to a wing and a squadron. However, making ASSIGNMENT optional to AIRCRAFT will make it much easier for the end user to enter an aircraft record if that aircraft’s assignment is not yet known. The same argument may be made for several of the other optionalities shown here. Note: The ASSIGNMENT entity would include foreign keys to four other entities. (AIRCRAFT, SQUADRON, WING, and OTHER.) The reference to the OTHER entity is N/A (not applicable) in most of the assignments. Therefore, to avoid the use of nulls in the ASSIGNMENT entity, the OTHER entity will include a dummy record in which the PK value is N/A.

WING SQUADRON ASSIGNMENT OTHER PERSONNEL AIRCRAFT M WING_COMMAND SQUA_LEAD 1 M 1 M M 1 M M M 1 (1,1) (0,N) (1,1) (0,N) (1,1) (0,N) (1,1) (0,N) (1,1) (0,N) (1,1) (0,N) (1,1) (0,N) (1,1) (0,N) 1 M AC_NUM (PK) SQUA_NUM (PK) ASSIGN_NUM (PK) WING_NUM (PK) PERS_NUM (PK) MOD_CODE (FK) SQLEAD_NUM (PK) WINGCOM_NUM (PK) OTHER_NUM (PK) OTHER_TYPE OTHER_DESCRIPT WING_NAME SQUA_NAME SQUA_NUM (FK) PERS_NUM(FK) SQLEAD_DATE SQLEAD_RANK WING_NUM (FK) PERS_NUM(FK) WINGCOM_DATE WINGCOM_RANK PERS_LNAME has leads commands uses ASSIGN_DATE AC_NUM (FK) WING_NUM (FK) SQUA_NUM (FK) OTHER_NUM (FK) shows in requires gets is given Note: The entities that had composite primary keys now have simple PKs to ensure that they will be referenced more easily. Entry of unique records will be ensured (at the application level) through their composite indexes. You will learn about CI in Chapter 4.

WING SQUADRON ASSIGNMENT OTHER PERSONNEL AIRCRAFT WING_COMMAND SQUA_LEAD AC_NUM (PK) SQUA_NUM (PK) ASSIGN_NUM (PK) WING_NUM (PK) PERS_NUM (PK) MOD_CODE (FK) SQLEAD_NUM (PK) WINGCOM_NUM (PK) OTHER_NUM (PK) OTHER_TYPE OTHER_DESCRIPT WING_NAME SQUA_NAME SQUA_NUM (FK) PERS_NUM(FK) SQLEAD_DATE SQLEAD_RANK WING_NUM (FK) PERS_NUM(FK) WINGCOM_DATE WINGCOM_RANK PERS_LNAME has leads commands usesASSIGN_DATE AC_NUM (FK) WING_NUM (FK) SQUA_NUM (FK) OTHER_NUM (FK) requires gets is given Note: The entities that had composite primary keys now have simple PKs to ensure that they will be referenced more easily. Entry of unique records will be ensured (at the application level) through their composite indexes. You will learn about the composite indexes in Chapter 4. shows in

The End