chapter 6: questions and answers - umuc's official web page is at

CHAPTER 6: QUESTIONS AND ANSWERS 1. What does it mean to say that constructing an ERD is an iterative process? Ans: In constructing an ERD, you construct a preliminary data model and then refine it many times. 2. Why decompose a compound attribute into smaller attributes? Ans: Because a compound attribute contains multiple items of data, decomposing a compound attribute can facilitate a search of the embedded data. 3. When is it appropriate to transform an attribute into an entity type? Ans: When the database should contain more than just the identifier of an entity. 4. Why transform an entity type into two entity types and a relationship? Ans: To record a finer level of detail about an entity. 5. Why transform a weak entity to a strong entity? Ans: This transformation can be useful to make it easier to reference an entity type after conversion to a table design. After conversion, a reference to a weak entity will involve a combined foreign key with more than one column. This transformation is most useful for associa tive entity types especially associative entity types representing M-way relationships. 6. Why transform an entity type into a generalization hierarchy? Ans: If there are attributes and relationships that do not apply to all entities and there is an accepted classification of entities, transformation to a generalization hierarchy may be useful. 7. Why add history to an attribute or relationship? Ans: Historical details may be necessary for legal requirements as well as strategic reporting requirements. 8. What data model changes are involved in transforming an attribute to an entity type? Ans: This transformation involves the addition of an entity type and a 1-M relationship. 9. What data model changes are involved in splitting a compound attribute? Ans: This transformation involves replacing an attribute with a collection of attributes. 10. What data model changes are involved in expanding an entity type? Ans: This transformation involves adding an entity type and 1-M relationship. The new entity type may be weak or strong depending on the database requirements. 11. What data model changes are involved in transforming a weak entity to a strong

entity?

Ans: This transformation involves changing a weak entity into a strong entity and changing the associated identifying relationships into non identifying relationships. It may be necessary to add a new primary key attribute to the new strong entity. 12. What data model changes are involved in adding history to an attribute or a

relationship? Ans: When applied to an attribute, the transformation involves adding a new entity type and a relationship. The new entity type should contain a change date attribute. When applied to a relationship, the transformation involves changing the cardinality of the relationship from 1-M to M-N. The M-N relationship should contain a change date attribute. When applied to a M-N relationship, this transformation involves converting the M-N relationship into an associative entity type along with the addition of a change date attribute that becomes part of the primary key of the associative entity type. 13. What data model changes are involved in adding a generalization hierarchy? Ans: This transformation involves the addition of a supertype and a generalization relationship along with redistributing attributes and relationships to the subtypes of the generalization hierarchy. 14. What should you document about an ERD? Ans: You should include justification for design decisions involving multiple feasible choices and explanations of subtle design choices. You should also provide a description for each attribute especially where an attribute’s name does not indicate its purpose. As an ERD is developed, you should document incompleteness and inconsistency in the database requirements. 15. What should you omit in ERD documentation? Ans: You should not use documentation just to repeat the details contained in the ERD. 16. Why are design errors more difficult to detect and resolve than diagram errors? Ans: Design errors are more difficult to detect and resolve because they involve the meaning of the items on a diagram, not just a diagram’s appearance. 17. What is a misplaced relationship and how is it resolved? Ans: A misplaced relationship involves connection of the wrong entity types on an ERD. You can use entity type clusters to avoid misplaced relationships. 18. What is an incorrect cardinality and how is it resolved? Ans: An incorrect cardinality typically involves a M-N relationship recorded as a 1-M relationship. To avoid an incorrect cardinality, you should not make inferences beyond the requirements. 19. What is a missing relationship and how is it resolved? Ans: A missing relationship involves entity types that should be connected directly to support the requirements. To avoid a missing relationship, you should examine implications of the requirements.

20. What is overuse of a generalization hierarchy and how is it resolved? Ans: Generalization hierarchies are specialized modeling tools that should be used sparingly. You should not use a generalization hierarchy just because an entity can exist in multiple states. You should use a generalization hierarchy when an accepted classification exists and subtypes have specialized attributes and relationships. 21. What is a relationship cycle? Ans: A relationship cycle involves a collection of relationships arranged in a loop starting and ending with the same entity type. 22. What is a redundant relationship and how is it resolved? Ans: A redundant relationship can be derived from other relationships. You should examine relationship cycles to see if a relationship can be derived from other relationships. 23. How is an M-N relationship converted to the Relational Model? Ans: Each M-N relationship becomes a separate table. The primary key of the table is a combined key consisting of the primary keys of the entity types participating in the M-N relationship. 24. How is a 1-M relationship converted to the Relational Model? Ans: Each 1-M relationship becomes a foreign key in the table corresponding to the child entity type. If the minimum cardinality is one, the foreign key cannot accept null values. 25. What is the difference between the 1-M relationship rule and the optional 1-M

relationship rule? Ans: Using the 1-M relationship rule results in null values when converting optional 1-M relationships. For the optional 1-M relationship rule, each 1-M relationship with a minimum cardinality of 0 and maximum cardinality of 1 becomes a new table. The primary key of the new table is the primary key of the entity type on the many side of the relationship. The primary key of the other entity type becomes a foreign key in the new table. However, usage of the optional 1-M relationship results in more tables. 26. How is a weak entity type converted to the Relational Model? Ans: Each identifying relationship adds a column to a primary key. The primary key of the table corresponding to the weak entity type consists of (i) the underlined local key (if any) in the weak entity type and (ii) the primary key(s) of the entity type(s) connected by the identifying relationship(s). 27. How is a generalization hierarchy converted to the Relational Model? Ans: Each entity type of a generalization hierarchy becomes a table. The columns of a table are the attributes of the corresponding entity type plus the primary key of the parent entity type. For each table representing a subtype, define a foreign key constraint that references the table corresponding to the parent entity type.

28. How is a 1-1 relationship converted to the Relational Model? Ans: A 1-1 relationship is converted into two foreign keys. If the relationship is optional with respect to one of the entity types, the corresponding foreign key may be dropped to eliminate null values. 29. List some symbol differences in ERD notation that you may experience in your

career. Ans: Students' responses may vary. The Chen notation uses a diamond to represent the relationship, while the Crow’s foot notation has the name on the line. For minimum and maximum cardinality, the Chen notation presents 0, 1, and N in parentheses. Some notations reverse the position of the cardinalities. Some notations display names for both directions of a relationship. Other symbol variations are visual representations for certain kinds of entity types. In some notations, weak entities and M-N relationships have special representations. Weak entities are sometimes enclosed in double rectangles. Identifying relationships are sometimes enclosed in double diamonds. M-N relationships with attributes are sometimes shown as a rectangle with a diamond inside denoting the dual qua lities (both relationship and entity type). 30. List some diagram rule differences in ERD notation that you may experience in your

career. Ans: Students' responses may vary. Some notations do not support M-way relationships, M-N relationships, relationships with attributes, and self- referencing (unary) relationships. Some notations support relationships to be connected to other relationships and attributes to have more than one value (multi-valued attributes). 31. What is the Unified Modeling Language (UML)? Ans: The Unified Modeling Language is the standard notation for object-oriented modeling. The UML contains class diagrams, interface diagrams, and interaction diagrams to support object-oriented modeling. The class diagram notation provides an alternative to the ERD notations presented in this chapter. 32. What are the modeling elements in a UML class diagram? Ans: Class diagrams can contain classes (collections of objects), associations (binary relationships) among classes, and object features (attributes and operations). In addition, class diagrams can include generalization hierarchies and composition relationships. 33. What are the criteria for choosing a primary key? Ans: Ideally, primary keys should be stable and single purpose. Stable means that a primary key should never change after it has been assigned to an entity. Single purpose means that a primary key attribute should have no purpose other than entity identification. 34. What should you do if a proposed primary key does not meet the criteria? Ans: If the proposed primary key does not meet either criterion, you probably should reject it as a primary key. If the proposed primary key only meets one criterion, you

should explore other attributes for the primary key. Sometimes, industry or organizational practices may dictate the choice of a primary key even if the choice is not ideal.

II. PROBLEM SOLUTIONS The problems are divided between data modeling problems and conversion problems. Additional conversion problems are found in Chapter 7, where conversion is followed by normalization. Besides the problems presented here, the case study in Chapter 13 provides practice on a larger problem. Data Modeling Problems 1. Define an ERD for the following narrative. The database should track homes and

owners. A home has a unique home identifier, a street address, a city, a state, a zip, a number of bedrooms, a number of bathrooms, and square feet. A home is either owner occupied or rented. An owner has a social security number, a name, an optional spouse name, a profession, and an optional spouse profession. An owner can possess one or more homes. Each home has only one owner.

Ans:

homeidstreetcitystatezipnobedrmsnobathssqftownoccupied

home

ssnownnamespousenameprofessionspouseprofess

owner

owns

2. Refine the ERD from problem 1 by adding an agent entity type. Agents represent owners in the sale of a home. An agent can list many homes but only one agent can list a home. An agent has a unique agent identifier, a name, an office identifier, and a phone number. When an owner agrees to list a home with an agent, a commission (percentage of the sales price) and a selling price are determined.

Ans:

homeidstreetcitystatezipnobedrmsnobathssqftownoccupiedcommissionsalesprice

home


owner

owns

agentidagentnameofficeidphone

agent

lists

3. In the ERD from problem 2, transform the attribute, office identifier, into an entity type. Data about an office include the phone number, the manager name, and the address.

Ans:


home


owner

owns

agentidagentnamephone

agent

lists

officeidaddressmgrnamephone

office

worksat

4. In the ERD from problem 3, add a buyer entity type. A buyer entity type has a social security number, a name, a phone, preferences for the number of bedrooms and bathrooms, and a price range. An agent can work with many buyers, but a buyer works with only one agent.

Ans:


home


owner

owns


agent

lists


office

worksat

ssnbuyernameaddressbdrmsbthrmsminpricemaxprice

buyer

workswith

5. Refine the ERD from problem 4 with a generalization hierarchy to depict similarities between buyers and owners.

Ans:


home

ssnspousenameprofessionspouseprofess

owner

owns


agent

lists


office

worksat

ssnaddressminpricebdrmsbthrmsmaxprice

buyer

workswith

ssnnamephone

person

D,C

6. Revise the ERD from problem 5 by adding an offer entity type. A buyer makes an offer on a home for a specified sales price. The offer starts on the submission date and time and expires on the specified date and time. A unique offer number identifies an offer. A buyer may submit multiple offers for the same home.

Ans:


home

ssnspousenameprofessionspouseprofess

owner

owns


agent

lists


office

worksat

ssnaddressminpricebdrmsbthrmsmaxprice

buyer

workswith

ssnnamephone

person

D,C

OfferNoexpdatepricecounterofferSubmitDate

offer

madefor

makes

7. Construct an ERD to represent accounts in a database for personal financial software. The software supports checking accounts, credit cards, and two kinds of investments (mutual funds and stocks). No other kinds of accounts are supported and every account must fall into one of these account types. For each kind of account, the software provides a separate data entry screen. The following list describes the fields on the data entry screens for each kind of account. § For all accounts, the software requires the unique account identifier, the account

name, date established, and the balance. § For checking accounts, the software supports attributes for the bank name, the

bank the address, the checking account number, and the routing number. § For credit cards, the software supports attributes for the credit card number, the

expiration date, and the credit card limit. § For stocks, the software supports attributes for the stock symbol, the stock type

(common or preferred), the last dividend amount, the last dividend date, the exchange, the last closing price, and the number of shares (a whole number).

§ For mutual funds, the software supports attributes for the mutual fund symbol, the share balance (a real number), the fund type (stock, bond, or mixed), the last closing price, the region (domestic, international, or global), and the tax exempt status (yes or no).

Ans: The following solution uses a two level generalization hierarchy. The investment entity type was added because mutual funds and stocks share two attributes. The share balance is not shared because the balance for stocks is a whole number (no partial shares) but a real number of mutual funds (fractional shares). The set constraints (disjoint and complete) are used because the financial software does not permit other kinds of accounts to be defined. These constraints may not hold in other financial software databases.

CheckingCheckAcctNo

BankNameRouteNo

CreditCardCardNoExpDate

Limit

D,C

StockShares

ExchangeLastDivAmtLastDivDate

MutualFundTaxExempt

RegionFundType

ShareBalance

D,C

InvestmentSymbol

LastClosePrice

AccountAcctID

AcctNameBalanceDateEst

8. Construct an ERD to represent categories in a database for personal financial software. A category has a unique category identifier, a name, a type (expense, asset, liability, or revenue), and a balance. Categories are organized hierarchically so that a category can have a parent category and one or more subcategories. For example, the category ‘household’ can have subcategories for ‘cleaning’ and ‘maintenance.’ A category can have any number of levels of subcategories. Make an instance diagram to depict the relationships among categories.

9. Design an ERD for a parts and relationships among parts. A part has a unique part

identifier, a name, and a color. A part can have multiple subparts and multiple parts that use it. The quantity of each subpart should be recorded. Make an instance diagram to depict relationships among parts.

Ans: 8 and 9 respectively.

CatIDCatNameBalanceCatType

Category

8) category hierarchy

decomposed

9) part hierarchy

partnopartdescpartcolor

part contains

Qty

C1

C2 C3

C4 C5

P1

P2

P3 P4

P5

8) decomposed instance diagram 9) contains instance diagram

10. Design an ERD to represent a credit card statement. The statement has two parts: a

heading containing the unique statement number, the account number of the credit card holder, and the statement date; and a detail section containing a list of zero or more transactions for which the balance is due. Each detail line contains a line number, a transaction date, a merchant name, and the amount of the transaction. The line number is unique within a statement.

Ans:

stmtnodateacctno

statementlinenotransdatemerchnameamt

stmtline

contains

11. Modify your ERD form problem 10. Everything is the same except that each detail line contains a unique transaction number in place of the line number. Transaction numbers are unique across statements.

Ans:

stmtnodateacctno

statementtransnotransdatemerchnameamt

stmtline

contains

12. Using the ERD in Figure 6.P1, transform the ProvNo attribute into an entity type

(Provider) and a 1-M relationship (Treats). A provider has a unique provider number, a first name, a last name, a phone, a specialty, a hospital name in which the provide practices, an email address, a certification, a pay grade, and a title. A provider is required for a visit. New providers do not have associated visits.

Patient

PatNoPatFirstNamePatLastNamePatCityPatStatePatZipPatHealthPlan

Visit

VisitNoVisitDateVisitPayMethodVisitChargeProvNo

Treats

Figure 6.P1: ERD for Problem 12

Ans:

Patient


Visit

VisitNoVisitDateVisitPayMethodVisitCharge

Attends

Provider

ProvNoProvFirstNameProvLastNameProvPhoneProvEMailProvSpecialtyProvHospitalProvCertificationProvPayGradeProvTitle

Treats

13. In the result of problem 12, expand the Visit entity type to record details about a visit. A visit detail includes a detail number, a detail charge, an optional provider number, an item number. The combination of the visit number and visit detail number is unique for a visit detail. An item includes a unique item number, an item description, an item price, and an item type. An item can be related to multiple visits. New items may not be related to any visit details. A provider can be related to multiple visit details. Some provides may not be associated to any visit details.

Ans:

Patient


Visit


Attends

Provider

ProvNoProvFirstNameProvLastNameProvPhoneProvSpecialtyProvEMailProvSpecialtyProvHospitalProvCertificationProvTitleProvPayGrade

Treats

Item

ItemNoItemDescItemTypeItemPrice

VisitDetail

VisitDetailNoDetailChargeContains

Provides

UsedIn

14. In the result of problem 13, add a generalization hierarchy to distinguish between

nurse and physician providers. A nurse has a pay grade and a title. A physician has a residence hospital, email address, and a certification. The other attributes of provider apply to both physicians and nurses. A visit involves a physician provider while a visit detail may involve a nurse provider.

Ans:

Patient


Visit


Attends

Physician

PhyEMailPhyHospitalPhyCertification

Treats

Nurse

NursePayGradeNurseTitle

Item


VisitDetail


Provides

UsedIn

Provider

ProvNoProvFirstNameProvLastNameProvPhoneProvSpecialty

D,C

15. In the result of problem 14, transform VisitDetail into a strong entity with VisitDetailNo as the primary key.

Ans:

Patient


Visit


Attends

Physician


Treats

Nurse


Item


VisitDetail


Provides

UsedIn

Provider


D,C

16. In the result of problem 15, add a history of item prices. Your solution should support the current price along with the two most recent prices. Include change dates for each item price.

Ans:

Patient


Visit


Attends

Physician


Treats

Nurse


Item

ItemNoItemDescItemTypeItemCurrPriceItemCurrPriceDateItemPrev1PriceItemPrev1PriceDateItemPrev2PriceItemPrev2PriceDate

VisitDetail


Provides

UsedIn

Provider


D,C

17. In the result of problem 15, add a history of item prices. Your solution should support an unlimited number of prices and change dates.

Ans:

Patient


Visit


Attends

Physician


Treats

Nurse


Item

ItemNoItemDescItemType

VisitDetail


Provides

UsedIn

Provider


D,C

ItemPriceHistory

ItemChangeDateItemPrice

PriceHist

18. Design an ERD with entity types for projects, specialties, and contractors. Add relationships and/or entity types as indicated in the following description. Each contractor has exactly one specialty, but many contractors can provide the same specialty. A contractor can provide the same specialty on multiple projects. A project can use many specialties, and a specialty can be used on many projects. Each combination of project and specialty should have at least two contractors.

Ans: project projectneeds

has

specialty

fulfills

contractor

providedby

supplies

2

This solution enforces the constraint that a contractor can have only 1 specialty (supplies relationship). In the providedby relationship, a contractor can be related to many combinations of project-specialty combinations. There is no constraint ensuring that the specialty is the same in all related project-specialty combinations. This solution also enforces the constraint that that a combination of project and specialty is related to a minimum of two contractors. The number 2 by the min cardinality means that a contractor must be related to at least two projectneeds entities. ERD tools (such as Visio Professional) may not support this cardinality specification.

project specialty

contractorsupplies

needs

uses

This solution enforces the constraint that a contractor can have only 1 specialty (supplies relationship). This solution does not enforce the constraint that that a combination of project and specialty is related to a minimum of 2 contractors. 19. For the following problem, define an ERD for the initial requirements and then

revise the ERD for the new requirements. Your solution should have an initial ERD, a revised ERD, and a list of design decisions for each ERD. In performing the problem, you may want to follow the approach presented in Section 6.1.

The database supports the placement office of a leading graduate school of business. The primary purpose of the database is to schedule interviews and facilitate searches by students and companies. Consider the following requirements in your initial ERD:

• Student data include a unique student identifier, a name, a phone number, an email address, a web address, a major, a minor, and a GPA.

• The placement office maintains a standard list of positions based on the Labor Department’s list of occupations. Position data include a unique position identifier and a position description.

• Company data include a unique company identifier, a company name, and a list of positions and interviewers. Each company must map its positions into the position list maintained by the placement office. For each available position, the company lists the cities in which positions are available.

• Interviewer data include a unique interviewer identifier, a name, a phone, an email address, and a web address. Each interviewer works for one company.

• An interview includes a unique interview identifier, a date, a time, a location (building and room), an interviewer, and a student.

After reviewing your initial design, the placement office decides to revise the requirements. Make a separate ERD to show your refinements. Refine your original ERD to support the following new requirements:

• Allow companies to use their own language to describe positions. The placement office will not maintain a list of standard positions.

• Allow companies to reserve blocks of interview time. The interview blocks will not specify times for individual interviews. Rather a company will request a block of X hours during a specified week. Companies reserve interview blocks before the placement office schedules individual interviews. Thus the placement office needs to store interviews as well as interview blocks.

• Allow students to submit bids for interview blocks. Students receive a set amount of bid dollars that they can allocate among bids. The bid mechanism is a pseudo market approach to allocating interviews, a scarce resource. A bid contains a unique bid identifier, a bid amount, and a company. A student can submit many bids and an interview block can receive many bids.

Ans:

stdidnamephoneemailwebmajorminorgpaadvisernoadvisername

student

interviewiddatetimebldgnameroomnoroomtype

interview

attends

intervieweridnamephoneemail

interviewer

compidcompname

company

posidname

position

citystate

comppos

conducts

worksfor

offers

available1

1. An interview may be initially setup without knowing the student or interviewer. Transformations: see ERD below • Remove the position entity type so that positions are not standardized across

companies. Add attributes to the comppos entity type for the position name and number of openings (optional attribute not explicitly derived from the problem statement). To reduce the number of attributes in the combined primary key of comppos, a unique identifier could be added. In this case, the compid, city, and state attributes would no longer be part of the primary key.

• Add an entity type (interviewblock) and relationships between interviewblock and interview and between interviewblock and company. The new entity type and relationships allow companies to schedule blocks of time. An interview block will contain a collection of interviews with the same company.

• Add an entity type for bids. The bid entity type should be connected to student and interviewblock.

stdidnamephoneemailwebmajorminorgpaadvisernoadvisername

student

interviewiddatetimebldgnameroomnoroomtype

interview

attends

intervieweridnamephoneemail

interviewer

compidcompname

company

intblocknoblockstarttimeblockendtimeduration

interviewblockcitystateposnameNumOpenings

comppos

conducts

worksfor

offers

bidnobidamtbidpriority

bid

submits

madefor

partof

requests

20. For the following problem, define an ERD for the initial requirements and then


Design a database for managing the task assignments on a work order. A work order records the set of tasks requested by a customer at a specified location.

• A customer has a unique customer identifier, a name, and a billing address (street, city, state, zip).

• A work order has a unique work order number, creation date, date required, a completion date, an optional supervising employee, a work address (street, city, state, zip), and a set of tasks.

• Each task has a unique task identifier, a task name, an hourly rate, and estimated hours. Tasks are standardized across work orders so that the same task may be performed on many work orders.

• Each task on a work order has a status (not started, in progress, or completed), actual hours, and a completion date. The completion date is not entered until the status changes to complete.

After reviewing your initial design, the company decides to revise the requirements. Make a separate ERD to show your refinements. Refine your original ERD to support the following new requirements:

• The company wants to maintain a list of materials. The data about materials include a unique material identifier, a name, and an estimated cost.

• Each work order also has a collection of material requirements. A material requirement includes a material, an estimated quantity of the material, and the actual quantity of the material used.

• The estimated number of hours for a task depends on the work order and task, not on the task alone. Each task of a work order includes an estimated number of hours.

Ans:

Customer NoCustomer NameAddressCityStateZipemailweb

customer

Work Order NoCreateDateReqDateAddress

workorderstatusacthrscompletedate

workdetail

tasknotasknameesthrsrate

task

requests

includes

requires

1

1. A workorder cannot be created unless at least 1 task is known.

Transformations: • Workdetail could be a M-N relationship. • Add an entity type for material. Connect material to work order in an associative

entity type or a M-N relationship. • Move esthrs from task to workdetail.

Customer NoCustomer NameAddressCityStateZipemailweb

customer

Work Order NoCreateDateReqDateAddress

workorder

tasknotasknamerate

task

requests

matnomatname

material

MatUsed

taskused

statusacthrsesthrs

compdate

estqty actqty

21. For the following problem, define an ERD for the initial requirements and then


Design a database to assist physical plant personnel in managing assignments of keys to employees. The primary purpose of the database is to ensure proper accounting for all keys.

• An employee has a unique employee number, a name, a position, and an optional office number.

• A building has a unique building number, a name, and a location within the campus.

• A room has a room number, a size (physical dimensions), a capacity, a number of entrances, and a description of equipment in the room. Because each room is located in exactly one building, the identification of a room depends on the identification of a building.

• Key types (also known as master keys) are designed to open one or more rooms. A room may have one or more key types that open it. A key type has a unique key type number, a date designed, and the employee authorizing the key type. A key type must be authorized before it is created.

• A copy of a key type is known as a key. Keys are assigned to employees. Each key is assigned to exactly one employee, but an employee can hold multiple keys. The key type number plus a copy number uniquely identify a key. The date the copy was made should be recorded in the database.

After reviewing your initial design, the physical plant supervisor decides to revise the requirements. Make a separate ERD to show your refinements. Refine your original ERD to support the following new requirements:

• The physical plant needs to know not only the current holder of a key but the past holders of a key. For past key holders, the date range that a key was held should be recorded.

• The physical plant needs to know the current status of each key: in use by an employee, in storage, or reported lost. If lost, the date reported lost should be stored.

Ans:

bldgnobldgnamelocation

building

copynodatemade

key

roomnosizenumdoorsequipment

room

contains

keytypenodateassignedpurpose

keytype

opens

empnoempnamepositionOfficeNo

employee

copyof

authorizes

issuedto1

2

1. The minimum cardinality of 0 is necessary because there may be times when a key is not assigned to

an employee, for example, between the time that one employee leaves an office and a new employee is assigned.

2. The OfficeNo attribute could be replaced by a 1-M relationship to the room entity type. The problem specification does not indicate whether office number should be connected to the room entity type.

Transformations: • The issuedto relationship should be changed into an entity type and two 1-M

relationships. The new entity type is identification dependent on key and employee. The dates assigned (beginning and ending) should be recorded in the new entity type.

• Add additional attributes to either the key entity type or the new entity type. If the attributes are added to the key entity type, only the current status can be recorded. If added to the new entity type, past status can be recorded. The most suitable solution is probably adding the attributes to the key entity type. Past status data is partially available through the new entity type.

bldgnobldgnamelocation

buildingcopynodatemadestatusdatelost

key

roomnosizenumdoorsequipment

room

contains

keytypenodateassignedpurpose

keytype

opensempnoempnamepositionOfficeNo

employee

copyof

authorizes

begdateenddate

keyhistory

useskey

usedby

22. Define an ERD that supports the generation of product explosion diagrams, assembly

instructions, and part lists. These documents are typically included in hardware products sold to the public. Your ERD should represent the final products as well as the parts comprising final products. The following points provide more details about the documents. • Your ERD should support the generation of product explosion diagrams as shown

in Figure 6.P2 for a wheelbarrow with a hardwood handle. Your ERD should store the containment relationships along with the quantities required for each subpart. For line drawings and geometric position specifications, you can assume that image and position data types are available to store attribute values.

Figure 6.P2: Product Explosion Diagram

• Your ERD should support the generation of assembly instructions. Each product can have a set of ordered steps for instruction. Table 6-P1 shows some of the assembly instructions for a wheelbarrow. The numbers in the instructions refer to the parts diagram.

Table 6-P1: Sample Assembly Instructions for the Wheelbarrow

Step Instructions

1 Assembly requires a few hand tools, screw driver, box, or open wrench to fit the nuts.

2 Do NOT wrench tighten nuts until entire wheelbarrow has been assembled.

3 Set the handles (1) on two boxes or two saw horses (one at either end).

4 Place a wedge (2) on top of each handle and align the bolt holes

in the wedge with corresponding bolt holes in the handle.

• Your ERD should support the generation of a parts list for each product. Table 6-P2 shows the parts list for the wheelbarrow.

Table 6-P2: Partial Parts List for the Wheelbarrow

Quantity Part Description

1 Tray

2 Hardwood handle

2 Hardwood wedge

2 Leg

Ans:

In the first solution, the Part entity type contains all parts and products. The PartImage attribute contains a line drawing of the part. The PartDiagram contains a line drawing showing the parts explosion diagram. The Product? attribute is true if the part is a final product. If there are other differences between parts and products, a generalization hierarchy could be used in place of the Product? attribute. The self-referencing contains relationship represents the assembly details. The parts list is derived from the contains relationship. The InstructionStep entity is a weak entity dependent on part through the identifying assembles relationship. The references relationship shows the parts referenced in an instruction step.

PartNoPartDescPartImagePartDiagramProduct?

Partcontains

StepNoDescription

InstructionStep

Qty

assembles

references

In the second solution, the contains relationship is replaced with an entity type (Component) and two 1-M relationships. The Component entity type is not identification dependent on the Part entity type because a given part can occur many times as a component. Each occurrence of Component contains the geometry of the component within the part. In the first solution, the geometry of each component was not represented. The parts list is derived from the Contains and UsedIn relationships.

PartNoPartDescPartImagePartDiagramProduct?

Part

StepNoDescription

InstructionStep

assembles

references

ComponentNoComGeometry

Component

Contains UsedIn

23. For the Expense Report ERD shown in Figure 6.P3, identify and resolve errors and

note incompleteness in the specifications. Note that the ERD may have both diagram and design errors. If you are using the ER Assistant, you can use the Check Diagram feature after checking the diagram rules yourself. Specifications for the ERD appear below: • The Expense Reporting database tracks users and expense reports and expense

report items along with users, expense categories, status codes, and limits on expense category spending.

• For each user, the database records the unique user number, the first name, the last name, the phone number, the email address, the spending limit, the organizational relationships among users, and the expense categories (at least one) available to the user. A user can manage other users but have at most one manager. For each expense category available to a user, there is a limit amount.

• For each expense category, the database records the unique category number, the category description, the spending limit, and the users permitted to use the expense category. When an expense category is initially created, there may not be related users.

• For each status code, the database records the unique status number, the status description, and the expense reports using the status code.

• For each expense report, the database records the unique expense report number, the description, the submitted date, the status date, the status code (required), the user number (required), and the related expense items.

• For each expense item, the database records the unique item number, the description, the expense date, the amount, the expense category (required), and the expense report number (required).

ExpenseCategory

CatNoCatDescCatLimitAmount

ExpenseReport

ERNoERDescERSubmitDateERStatusDate

StatusOf

User

UserNoUserFirstNameUserLastNameUserPhoneUserEMailUserLimit

Manages

ExpenseItem

ExpItemNoExpItemDescExpItemDateExpItemAmount

Contains

StatusType

StatusNoStatusDesc

Categorizes

Limits

Expenses

Figure 6.P3: ERD for the Expense Reporting Database

24. For the Intercollegiate Athletic ERD shown in Figure 6.P4, identify and resolve

errors and note incompleteness in the specifications. Note that the ERD may have both diagram and design errors. If you are using the ER Assistant, you can use the Check Diagram feature after checking the diagram rules yourself. Specifications for the ERD appear below: • The Intercollegiate Athletic database supports the scheduling and the operation of

events along with tracking customers, facilities, locations within facilities, employees, and resources to support events. To schedule an event, a customer initiates an event request with the Intercollegiate Athletic Department. If an event request is approved, one or more event plans are made. Typically, event plans are made for the setup, the operation, and the cleanup of an event. An event plan consists of one or more event plan lines.

• For each event request, the database records the unique event number, the date held, the date requested, the date authorized, the status, an estimated cost, the estimated audience, the facility number (required), and the customer number (required).

• For each event plan, the database records the unique plan number, notes about the plan, the work date, the activity (setup, operation, or cleanup), the employee number (optional), and the event number (required).

• For each event plan line, the database records the line number (unique within a plan number), the plan number (required), the starting time, the ending time, the

resource number (required), the location number (required), and the quantity of resources required.

• For each customer, the database records the unique customer number, the name, the address, the contact name, the phone, the email address, and the list of events requested by the customer. A customer is not stored in the database until submitting an event request.

• For each facility, the database records the unique facility number, the facility name, and the list of events in which the facility is requested.

• For each employee, the database records the unique employee number, the name, the department name, the email address, the phone number, and the list of event plans supervised by the employee.

• For each location, the database records the related facility number, the location number (unique within a facility), the name, and the list of event plan lines in which the location is used.

• For each resource, the database records the unique resource number, the name, the rental rate, and the list of event plan lines in which the resource is needed.

EventPlanLine

LineNoEPLTimeStartEPLTimeEndEPLQty

EventRequest

ERNoERDateHeldERRequestDateERAuthDateERStatusEREstCostEREstAudience

Customer

CustNoCustNameCustContactNameCustPhoneCustEMailCustAddr

Submits

EventPlan

EPNoEPDateEPNotesEPActivity

Requires

Resource

ResNoResNameResRate

PartOf

Facility

FacNoFacName

Location

LocNoLocName

Employee

EmpNoEmpNameEmpPhoneEmpEMailEmpDept

Supervises

Requires

Contains

Supports

Figure 6.P4: ERD for the Intercollegiate Athletic Database

Ans:

The ERD below fixes the errors in the original ERD. The following list describes the problem resolutions. § The Contains relationship should be identifying. § The EventPlanLine table should be weak.

§ The HeldAt relationship was added from Facility to EventRequest. Without this relationship, the facility for an event request cannot be determined until an event plan line uses the facility.

§ The Requires relationship should be from Resource to EventPlanLine, not Resource to EventPlan. Each line in an event plan can involve a different resource.

§ The Supports relationship should be 1-M, not M-N. § The minimum cardinality in the Submits relationship should be 1 not 0

(customer must be related to at least one event request). § The specification is incomplete in the minimum number of event plan lines

related to a resource and a location and in the minimum number of event plans supervised by an employee.

§ The specification is also incomplete about attribute constraints such as null value allowed and data types.

EventPlanLine

LineNoEPLTimeStartEPLTimeEndEPLQty

EventRequest

ERNoERDateHeldERRequestDateERAuthDateERStatusEREstCostEREstAudience

Customer

CustNoCustNameCustContactNameCustPhoneCustEMailCustAddr

Submits

EventPlan

EPNoEPDateEPNotesEPActivity

Requires

Resource

ResNoResNameResRate

PartOf

Facility

FacNoFacName

Location

LocNoLocName

Employee

EmpNoEmpNameEmpPhoneEmpEMailEmpDept

Supervises

Requires

Contains

Supports

HeldAt

25. Define an ERD that supports the generation of television viewing guides, movie

listings, sports listings, public access listings, and cable conversion charts. These documents are typically included in television magazines bundled with Sunday newspapers. In addition, these documents are available online. The following points provide more details about the documents. • A television viewing guide lists the programs available during each time slot of a

day as depicted in Figure 6.P5. For each program in a channel/time slot, a viewing guide may include some or all of these attributes: a program title, a television content rating, a description, a rerun status (yes or no), a duration, a closed

caption status (yes or no), and a starting time if a program does not begin on a half hour increment. For each movie, a guide also may include some or all of these attributes: an evaluative rating (number of stars from 1 to 4 with half star increments), a list of major actors, an optional brief description, a motion picture content rating, and a release year. Public access programs are shown in a public access guide, not in a television viewing guide.

• A movie listing contains all movies shown in a television guide as depicted in Figure 6.P6. For each movie, a listing may include some or all of these attributes: a title, a release year, an evaluative rating, a content rating, a channel abbreviation, a list of days of the week/time combinations, a list of major actors, and a brief description. A movie listing is organized in ascending order by movie titles.

• A sports listing contains all sports programming in a television guide as depicted in Figure 6.P7. A sports listing is organized by sport and day within a sport. Each item in a sports listing may include some or all of these attributes: an event title, a time, a duration, a channel, an indicator for closed-captioning, an indicator if live, and an indicator if a rerun.

• A public access listing shows public access programming that does not appear elsewhere in a television guide as depicted in Figure 6.P8. A public access listing contains a list of community organizations (title, area, street address, city, state, zip code, and phone number). After the listing of community organizations, a public access listing contains programming for each day/time slot. Because public access shows do not occupy all time slots and are available on one channel only, there is a list of time slots for each day, not a grid as for a complete television guide. Each public access program has a title and an optional sponsoring community organization.

• A cable/conversion chart shows the mapping of channels across cable systems as depicted in Figure 6.P9. For each channel, a conversion chart shows a number on

each cable system in the local geographic area.

Figure 6.P5: Sample Television Viewing Guide

Figure 6.P6: Sample Movie

Listing

Figure 6.P7: Sample Sports

Listing

Figure 6.P9: Sample Conversion Chart

Ans:

This ERD supports the documents shown in the problem description. Design notes follow the ERD.

Actor

ActorNoActName

Movie

MVStarRatingMVContentRatingMVYear

PerformsIn

SportEvent

SportTypeLive

Program

ProgNoProgTitleProgDescProgContentRatingClosedCaptionedDuration

D

Channel

ChannelIdChnAbbrChnTitle

TimeSlot

TSNoTSDateTSTime

ScheduledItem

StartTimeRerun

ChannelOf

ProgramOf

TimeOf

PublicAccess

PANoPATitle

Duration

ScheduledPA

TimeOf

PAOf

CommOrg

OrgNoOrgAreaOrgStreetOrgCityOrgStateOrgZipOrgPhone

Sponsors

CableSystem

CSIdCSName

CSChannel

Number

ChannelOf

CSOf

Design notes § The generalization hierarchy is not complete because regular programs are neither

movies nor sporting events. Regular programs can be added as another subtype if there are attributes unique to regular programs.

§ A generalization hierarchy is not essential in the ERD although it is a good idea. Sporting events and movies are significant subsets of programming. Sporting events and movies have some unique attributes so a generalization hierarchy avoids null values for a significant subset of programming.

§ It is assumed that there is a function to compute the day of the week given a date.

§ The starting time for a scheduled item is null except when the item does not start on a half hour interval.

§ The design assumes that public access programming begins on half hour intervals. § The use of optional relationships in the cardinalities near the weak entities allows

flexibility when adding entities to the database. § The narrative is not clear about the placement of the attributes Rerun, Live, and

ClosedCaption. In the solution ERD, the Rerun attribute is placed in the ScheduledItem entity type because it is assumed that the same program can be shown for the first time or as a rerun. The Live and ClosedCaption attributes are placed respectively in the SportEvent and Program entity types because these attributes are assumed to be associated with all viewings. These assumptions should be verified with the user for clarification.

§ Primary keys for most entity types were not specified in the problem. The primary keys added meet the stable and single-purpose criteria. The choice of primary keys should be evaluated with knowledgeable users especially to see if there are any standard accepted primary keys. The industry may use bar codes to identify programs.

Conversion Problems 1. Convert the ERD shown in Figure 6.CP1 into tables. List the conversion rules used

and the resulting changes to the tables.

HomeIDStreetCityStateZipNoBedrmsNoBathsSqFtOwnOccupiedCommissionSalesPrice

Home

AgentIDNamePhone

Agent

Lists

OfficeIDMgrNamePhoneAddress

Office

SSNNameSpouseNameProfessionSpouseProfession

Owner

Owns

WorksAt

Figure 6.CP1: ERD for Conversion Problem 1

Ans: • Entity Type Rule: generate home, owner, agent, and office tables • 1-M Relationship Rule: foreign keys in home (agentid and ssn) and agent

(officeid)

Result after conversion home(homeid, agentid, ssn, street, city, state, zip, nobedrms, nobath, sqft, price,

…) FOREIGN KEY(agentid) REFERENCES agent FOREIGN KEY(ssn) REFERENCES owner agent(agentid, officeid, name, phone) FOREIGN KEY(officeid) REFERENCES office owner(ssn, name, spousename, profess, spouseprofess) office(officeid, mgrname, phone, address) 2. Convert the ERD shown in Figure 6.CP2 into tables. List the conversion rules used


StmtNoDateAcctNo

StatementLineNoMerNameAmtTransDate

StmtLine

Contains


Ans: • Entity Type Rule: generate statement and stmtline tables • 1-M Relationship Rule: foreign key in stmtline • Id Dependency Rule: make the combination of stmtno and lineno the primary

key

Result after conversion statement(stmtno, date, acctno)

stmtline(stmtno, lineno, mername, transdate) FOREIGN KEY(stmtno) REFERENCES statement 3. Convert the ERD shown in Figure 6.CP3 into tables. List the conversion rules used


PartNoPartName

PartSuppNoSuppName

Supplier

ProjNoProjName

Project

UsesPart-Uses

Supp-Uses

Proj-Uses


Ans: • Entity Type Rule: generate part, supplier, and project tables • M-N Relationship Rule: generate uses table

Result after conversion part(partno, …)

supplier(suppno, …)

project(projno, …)

uses(partno, suppno, projno)

FOREIGN KEY(partno) REFERENCES part FOREIGN KEY(suppno) REFERENCES supplier FOREIGN KEY(projno) REFERENCES project 4. Convert the ERD shown in Figure 6.CP4 into tables. List the conversion rules used


EmpNoEmpName

EmployeeSkilNnoSkillName

Skill

ProjNoProjName

Project

Hrs

ProvidesEmp-Uses

Skill-Uses

Proj-Uses


Ans: • Entity Type Rule: generate part, supplier, project, and usage tables • 1-M Relationship Rule: generate foreign keys in usage table • Id Dependency Rule: 3 applications make the primary key in usage

Result after conversion part(partno, …)

supplier(suppno, …)

project(projno, …)

usage(partno, suppno, projno)

FOREIGN KEY(partno) REFERENCES part FOREIGN KEY(suppno) REFERENCES supplier FOREIGN KEY(projno) REFERENCES project 5. Convert the ERD shown in Figure 6.CP5 into tables. List the conversion rules used


AcctidAcctNameBalance

Account DecomposedPartNoPartDescColor

Part Contains


Ans: • Entity Type Rule: generate part and account tables • Optional 1-M Relationship Rule: generate the decomposed table • M-N Relationship Rule: generate the contains table

Result after conversion part(partno, partdesc, color)

account(acctid, acctname, balance)

decomposed(acctid, parent_acctid)

FOREIGN KEY(acctid) REFERENCES account FOREIGN KEY(parent_acctid) REFERENCES account

contains(super_partno, sub_partno) FOREIGN KEY(super_partno) REFERENCES part FOREIGN KEY(sub_partno) REFERENCES part

6. Convert the ERD shown in Figure 6.CP6 into tables. List the conversion rules used


StudentStdIDName

GenderDOB

AdmitDate

UndStudentMajorMinorClass

GradStudentAdvisor

ThesisTitleAsstStatus

D,C


Ans: • Entity Type Rule: generate student table • Generalization Rule: generate the undstudent and gradstudent tables

Result after conversion student(stdid, name, gender, dob, admitdate)

undstudent(stdid, major, minor, class)

CONSTRAINT FKUndStudent FOREIGN KEY(stdid) REFERENCES student

gradstudent(stdid, advisor, thesistitle, asststatus) CONSTRAINT FKGradStudent FOREIGN KEY(stdid) REFERENCES student 7. Convert the ERD shown in Figure 6.CP7 into tables. List the conversion rules used


HomeNoAddress

HomeAgentIDName

Agent

Commission

Lists


Ans:

• Entity Type Rule: generate home and agent tables • Optional 1-M Relationship Rule: generate the lists table

Result after conversion home(homeno, address, …)

agent(agentid, name, …)

lists(homeno, agentid)

FOREIGN KEY(homeno) REFERENCES home FOREIGN KEY(agentid) REFERENCES agent 8. Convert the ERD shown in Figure 6.CP8 into tables. List the conversion rules used


ContrNoContrName

Contractor

SpecNoSpecName

SpecialtyProjNoProjName

Project ProjectNeedsFulFillsHas

ProvidedBy

Supplies


Ans: Result after conversion proiect(projno, …)

specialty(specno, …)

contractor(contrno, specno, …)

FOREIGN KEY(specno) REFERENCES specialty projectneeds(projno, specno) FOREIGN KEY(projno) REFERENCES project FOREIGN KEY(specno) REFERENCES specialty providedby(contrno, projno, specno) FOREIGN KEY(projno, specno) REFERENCES projectneeds FOREIGN KEY(contrno) REFERENCES contractor

Conversion rules § Use the entity type rule to convert each entity type § Use the M-N rule to convert the providedby relationship § Use the 1-M relationship rule to convert the has, fulfills, and supplies

relationships. § Use the identification dependency rule to determine the primary key of the

projectneeds relationship. 9. Convert the ERD shown in Figure 6.CP9 into tables. List the conversion rules used


Customer

CustNoCustFirstNameCustLastNameCustCityCustStateCustZipCustBal

Order

OrdNoOrdDateOrdNameOrdCityOrdStateOrdZip

Places

Employee

EmpNoEmpFirstNameEmpLastNameEmpPhoneEmpEMailEmpDeptNameEmpCommRate

Takes

Manages

Product

ProdNoProdNameProdQOHProdPriceProdNextShipDate

Contains

Qty


Ans:

Result after conversion customer(custno, …)

employee(empno, supempno, …)

FOREIGN KEY(supempno) REFERENCES employee

product(prodno, …)

order(ordno, custno, empno, …) FOREIGN KEY(custno) REFERENCES customer

FOREIGN KEY(empno) REFERENCES employee contains(ordno, prodno, qty) FOREIGN KEY(ordno) REFERENCES order FOREIGN KEY(prodno) REFERENCES product

Conversion rules § Use the entity type rule to convert each entity type § Use the M-N rule to convert the contains relationship § Use the 1-M relationship rule for all relationships except the contains

relationship § Can use the optional 1-M relationship rule instead of the 1-M relationship

rule to convert the takes and manages relationships. Using the optional 1-M relationship rule, order.empno should be replaced by the takes table and employee.supempno should be replaced by the manages table.

takes(ordno, empno)

FOREIGN KEY(ordno) REFERENCES order FOREIGN KEY(empno) REFERENCES employee

manages(empno, supempno) FOREIGN KEY(empno) REFERENCES employee FOREIGN KEY(supempno) REFERENCES employee 10. Convert the ERD shown in Figure 6.CP10 into tables. List the conversion rules used


Patient


Visit


Attends

Physician


Treats

Nurse


Item


VisitDetail


Provides

UsedIn

Provider


D,C


Ans: Result after conversion patient(patno, …)

provider(provno, …)

physician(provno, …)

FOREIGN KEY(provno) REFERENCES provider ON DELETE CASCADE

nurse(provno, …) FOREIGN KEY(provno) REFERENCES provider ON DELETE CASCADE

item(itemno, …)

visit(visitno, patno, provno, …) FOREIGN KEY(patno) REFERENCES patient FOREIGN KEY(provno) REFERENCES physician visitdetail(visitno, visitdetailno, provno, itemno) FOREIGN KEY(visitno) REFERENCES visit FOREIGN KEY(provno) REFERENCES nurse FOREIGN KEY(itemno) REFERENCES item

Conversion rules § Use the entity type rule to convert each entity type § Use the 1-M relationship rule for all relationships § Use the identification dependency rule to determine the primary key of

visitdetail. § Can use the optional 1-M relationship rule instead of the 1-M relationship

rule to convert the provides relationship. Using the optional 1-M relationship rule, visitdetail.provno should be replaced by the provides table.

provides(visitno, visitdetailno, provno)

FOREIGN KEY(visitno, visitdetailno) REFERENCES visitdetail FOREIGN KEY(provno) REFERENCES nurse

chapter 6: questions and answers - umuc's official web page is at

Documents