Database concepts 8th edition kroenke solutions manual

Database Concepts 8th Edition

David M. Kroenke • David J. Auer • Scott L. Vandenberg• Robert C. Yoder

Instructor’s Manual

Prepared by David J. Auer

Chapter 5

Database Design

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America.

 CHAPTER OBJECTIVES

• Learn how to transform E-R data models into relational designs

• Practice applying the normalization process

• Understand the need for denormalization

• Learn how to represent weak entities with the relational model

• Know how to represent 1:1, 1:N, and N:M binary relationships

• Know how to represent 1:1, 1:N, and N:M recursive relationships

• Learn SQL statements for creating joins over binary and recursive relationships

 CHAPTER ERRATA

There are no known errors at this time. Any errors that are discovered in the future will be reported and corrected in the online DBC e08 Errata document, which will be available at http://www.pearsonhighered.com/kroenke.

 THE ACCESS WORKBENCH

Solutions to the Access Workbench exercises may be found in Solutions to all Sections: The Access Workbench, which is a separate document within the Instructor’s Manual.

 NOTES ON MICROSOFT WINDOWS 10

This book uses the Microsoft Windows 10 operating system as the basis for screenshots and step-by-step instructions. However, with Windows 10, Microsoft has introduced a continuous update system that has already resulted in some fundamental differences in how different versions of Windows 10 look and operate.

For example, in the original version of Microsoft Windows 10, clicking the Windows Start button (or pressing the Windows key on the keyboard) displayed the menu shown in Figure 1. In this menu, we need to click the All apps button in order to see the All apps menu shown in Figure 2.

Figure 1 – Windows 10 Main Menu

The All apps button

The File Explorer button

The File Explorer icon

The All apps menu

The All apps menu

The File Explorer button

The File Explorer icon

Microsoft then released the Windows 10 Anniversary Update (Feature update to Windows 10, version 1607) (see the blog discussion at https://blogs.windows.com/windowsexperience/2016/08/02/how-to-get-the-windows-10anniversary-update/#K1CZuiw4auiuE9A5.97 ). One of the changes introduced in the Anniversary Update was a major change to the menu system. Now, as shown in Figure 3, the All apps menu is immediately available when the Start button is used (or when the keyboard Windows key is pressed).

Therefore, note that the step by step instructions in this book may need to be altered for your use depending upon which version of Microsoft Windows 10 you or your students are using!

We recommend that you update Windows 10 to the Windows 10 Anniversary Update (Feature update to Windows 10, version 1607), and make sure it is patched with all updates to that version (at a minimum patched to Windows 10 Version 1607 update for August 23, 2016 (KB3176936), and the Windows 10 Version 1607 cumulative update for September 29, 2016 (KB3194496). We also recommend using the 32-bit version of Microsoft Office. This insures that all the examples discussed in this book will function properly.

Figure 2 – Windows 10 All Apps Menu

Figure 3 – Windows 10 Anniversary Update Main Menu with All Apps Menu Included

Chapter Five – Database Design

 TEACHING SUGGESTIONS

• The best way to learn database design is to do it. Students should answer all of the Review questions and do at least one of the Garden Glory, James River Jewelry, or the Queen Anne Curiosity Shop projects.

• You may want to assign your own version of the data model for Garden Glory, James River Jewelry, or the Queen Anne Curiosity Shop. That way, students who did poorly on the data modeling exercise will have the same starting point as students who did well (It will also make your grading task easier!) Or, more like the real world, ask students to fix any problems found on their model before doing the database design.

• This is the chapter that many students have been waiting for. It gets into how tables look based upon the data design created in Chapter 4. Start by reviewing the elements of data model transformation in Figure 5-1 (see below). Remind students that designs must be implemented and the implementation must follow the design.

• Very important in this chapter is the understanding of primary and surrogate keys. A relatively easy way to introduce surrogate keys is to remind students that most keys we conceptually understand today were at one time surrogate keys. For example, social security numbers were surrogate keys when they were originally created. We need a way to identify each person in the country. Other examples of surrogate keys that we accept as keys now are credit card numbers, telephone numbers, invoice numbers, etc.

• Referential integrity is a term that students will hear virtually every day they work in the database field. It determines whether certain things can be done and the order in which things must be done. Virtually any change to a database will be impacted by a referential integrity constraint. Spend plenty of time discussing this. Remind students that when they begin creating databases (and especially populating databases) referential integrity appears to be a headache.

• The companion to referential integrity constraints is referential integrity actions. Discuss cascading updates, cascading deletes, and “no action” (the DBMS default when a cascading action is not specified).

• Work especially hard to get students to understand many-to-many relationships and the referential integrity actions. This will help them understand the true purpose of the intersection table. If they understand the requirement that no part of a primary key can be null, they will understand why the cascading behavior for intersection tables need to be set as it is.

• Make sure you cover what happens when you use a delete cascade integrity action with a database structure that has several levels. You can have the cascade action at level one, but the cascade may violate a referential integrity constraint at the next level. This makes the first level fail. Also, if you use enough delete cascade actions, you could think you are deleting a single row and potentially delete the entire database.

• Representation of recursive relationships is difficult for students to comprehend. The 1:1 and N:M are not bad, but understanding how the foreign key works for a 1:N is. Spend some time explaining this.

• It is important to spend time covering the minimum cardinalities O-O, M-O, O-M and M-M and their implications. This text, however, does not cover the application logic that is used to implement these cardinalities. For that, see David M. Kroenke and David J. Auer, Database Processing: Fundamentals, Design, and Implementation, 14th Edition (Upper Saddle River: Pearson/Prentice-Hall, 2016).

• We use and recommend MySQL Workbench for database design work. It is easy to download and install see Appendix C, “Getting Started with MySQL 5.7 Community Server.” If you are using a DBMS other than MySQL in your class, you can still have your students install and use just MySQL Workbench.

• One design area where MySQL Workbench does not have the proper tools is supertype/subtype constructions. Our work around to this is to use a dummy table in place of the supertype to subtype connector symbol, and make the needed connections to this table. To illustrate this, here is the solution to Review Question 5.28 (b) shown as drawn in erwin Data Modeler (see: http://erwin.com/products/erwin-data-modeler-standard-edition/ - note that the Erwin Data Modeler Community Edition is no longer available as of January 23rd, 2017) and then as drawn in MySQL Workbench. Study the MySQL Workbench diagram to see how the dummy table is used and connected.

CLIENT

ClientID

LastName

FirstName

Phone

Email

HOME_BUYER

ClientID (FK)

DesiredNumberOfBedrooms

_OtherAttributes_

RENTER

ClientID (FK)

DesiredNumberOfParkingSpaces

_OtherAttributes_

COMMERCIAL_BUYER

ClientID (FK)

DesiredTotalFloorSpace

_OtherAttributes_

One workaround in MySQL Workbench is to use a dummy table to replace the subtype connector in the diagrams above. Here is a version of the second diagram as drawn in MySQL Workbench. See MySQL Workbench file DBC-e08-RQ-5-28-B.mwb.

Chapter Five – Database Design

 ANSWERS TO REVIEW QUESTIONS

5.1 Explain how entities are transformed into tables.

See Figure 5-1: The Steps for Transforming a Data Model into a Database Design.

5.2 Explain how attributes are transformed into columns. What column properties do you take into account when making the transformations?

Each attribute in an entity becomes a column in the corresponding table. The column properties are the same as those in the discussion of attributes at the end of Chapter 4. These include data type, null status, default values, and any constraints on the values.

5.3 Why is it necessary to apply the normalization process to the tables created according to your answer to question 5.1?

An entity, and therefore a relation created from it, may contain more than one topic or theme. Normalize the relations to eliminate insertion, modification, and deletion anomalies. However, don’t normalize if usability or performance considerations indicate otherwise. (This is “denormalization” at work.)

5.4 What is denormalization?

Denormalization is not normalizing a database to a fully normalized status. One or more tables may be left in a state that we know is not fully normalized.

5.5 When is denormalization justified?

Denormalization is justified when usability or performance considerations indicate that a fully normalized set of tables is not optimum.

5.6 Explain the problems that unnormalized tables have for insert, update, and delete actions.

Unnormalized relations can technically be susceptible to insert, update, and delete anomalies. The question for the database designer is how much of a problem the possible anomalies really pose to the company. In the chapter example for instance, the functional dependency ZIP → (City, State) that was left in the CUSTOMER table had little potential to cause serious problems. The potential for problems will need to be assessed when unnormalized tables are suggested.

5.7 Explain how the representation of weak entities differs from the representation of strong entities.

A referential integrity constraint will be generated and a cascading deletions rule set up so that when the parent is deleted all dependent weak entities are also deleted. If the weak entity is IDdependent, then the key of the relation upon which it depends will need to be added to the relation.

5.8 Explain how supertype and subtype entities are transformed into tables. Supertype and subtype entities are basically transformed into tables the same as any other entity. The only special feature is that the primary key of the supertype becomes the primary key and the foreign key on each subtype.

5.9 List the three types of binary relationships and give an example of each. Do not use the examples given in this text.

For this example, we will consider boats in a marina:

5.10 Define the term foreign key and give an example.

A foreign key is an attribute in one relation that is a primary key of a different relation.

Example: Given the tables:

SALESPERSON (SalespersonNumber, {OtherColumns})

SALES_ORDER (OrderNumber, OrderDate, SalespersonNumber, {OtherColumns})

In the SALESPERSON table, SalespersonNumber is the primary key, whereas in the table

SALES ORDER SalespersonNumber is a foreign key referencing Salesperson Number in SALESPERSON.

5.11 Show two different ways to represent the 1:1 relationship in your answer to question 5.9. Use IE Crow’s Foot E-R diagrams.

See MySQL Workbench files DBC-e08-RQ-5-11-A and DBC-e08-RQ-5-11-B.

Assume relations:

BOAT (LicenseNumber, Type, Length)

SLIP (SlipNumber, Location, Charge)

Either (a) place LicenseNumber in SLIP or (b) place SlipNumber in BOAT as a foreign key.

(a)

BOAT (LicenseNumber, Type, Length)

SLIP (SlipNumber, Location, Charge, LicenseNumber) Where LicenseNumber in SLIP must exist in LicenseNumber in BOAT

(b)

BOAT (LicenseNumber, Type, Length, SlipNumber)

SLIP (SlipNumber, Location, Charge)

Where

SlipNumber in BOAT must exist in SlipNumber in SLIP

5.12 For your answers to question 5.11, describe a method for obtaining data about one of the entities, given the key of the other. Describe a method for obtaining data about the second entity, given the key of the first. Describe methods for both of your alternatives in question 5.11.

To go from BOAT (using LicenseNumber) to SLIP:

• For (a): Look up LicenseNumber in SLIP.

• For (b): Use LicenseNumber to get the row of BOAT, then obtain SlipNumber from BOAT, and look up the row in SLIP using the SlipNumber obtained.

To go from SLIP (using SlipNumber) to BOAT:

• For (a): Use SlipNumber to get the row of SLIP, then obtain LicenseNumber from SLIP, and look up the row in BOAT using the LicenseNumber obtained.

• For (b): Look up SlipNumber in BOAT.

5.13 Code SQL statements to create a join that has all data about both tables from your work for question 5.11.

The SQL statement will depend on which table has the foreign key:

SELECT *

FROM BOAT, SLIP

WHERE BOAT.LicenseNumber = SLIP.LicenseNumber;

©

Chapter Five – Database Design

Or SELECT *

FROM BOAT, SLIP

WHERE BOAT.SlipNumber = SLIP.SlipNumber;

5.14 Define the terms parent and child as they apply to tables in a database design and give an example of each.

A parent is a row on the one side of a 1:N relationship, while a child is a row on the many side of a 1:N relationship. For example, if DEPARTMENT and EMPLOYEE have a 1:N relationship, a row of DEPARTMENT is a parent and the rows of EMPLOYEE that pertain to that department are the children.

5.15 Show how to represent the 1:N relationship in your answer to question 5.9. Use an IE Crow’s Foot E-R diagram.

See MySQL Workbench file DBC-e08-RQ-5-15.mwb.

BOAT to RENTAL_FEE is 1:N.

Assume relations:

BOAT (LicenseNumber, Type, Length)

RENTAL_FEE (ChargeNumber, ChargeDate, ChargeAmount).

Place LicenseNumber in RENTAL-CHARGE as a foreign key.

BOAT (LicenseNumber, Type, Length)

RENTAL_FEE (ChargeNumber, ChargeDate, ChargeAmount, LicenseNumber)

©

5.16 For your answer to question 5.15, describe a method for obtaining data for all the children, given the key of the parent. Describe a method for obtaining data for the parent, given a key of the child.

Given a value of LicenseNumber in BOAT [Parent], look up all rows in RENTAL_FEE [Child] having that value for LicenseNumber.

Given a ChargeNumber, look up the row in RENTAL_FEE [Child] having that number, and then use that value to look up BOAT [Parent] data to obtain the value of the LicenseNumber for the parent.

5.17 For your answer to question 5.15, code a SQL statement that creates a table that has all data from both tables.

SELECT * FROM BOAT, RENTAL_FEE

WHERE BOAT.LicenseNumber = RENTAL_FEE.LicenseNumber;

5.18 For a 1:N relationship, explain why you must place the key of the parent table in the child table, rather than place the key of the child table in the parent table.

There is literally not enough room in the parent, since we can only have one value per cell in the relational model.

5.19 Give examples of binary 1:N relationships, other than those in this text, for (a) an optional-to-optional relationship, (b) an optional-to-mandatory relationship, (c) a mandatory-to-optional relationship, and (d) a mandatory-to-mandatory relationship. Illustrate your answer by using IE Crow’s Foot E-R diagrams.

A. An optional-to-optional (O–O) relationship: BOAT to SAIL

See MySQL Workbench file DBC-e08-RQ-5-19-A.mwb.

• One sailboat may have many sails, while a powerboat will have none.

• A sail may exist in SAIL without being assigned to a sailboat in BOAT.