8/2/2019 307 Chapter 4

1/20

1. What role does the ER diagram play in the design process?

A completed ER diagram is the actual blueprint of the database. Its compositionmust reflect an organization's operations accurately if the database is to meet thatorganization's data requirements. It forms the basis for a final check on whether the

included entities are appropriate and sufficient, on the attributes found within thoseentities, and on the relationships between those entities. It is also used as a finalcrosscheck against the proposed data dictionary entries. The completed ER diagramalso lets the designer communicate more precisely with those who commissionedthe database design. Finally, the completed ER diagram serves as theimplementation guide to those who create the actual database. In short, the ERdiagram is as important to the database designer as a blueprint is to the architectand builder.

2. What two conditions must be met before an entity can be classified as aweak entity? Give an example of a weak entity.

To be classified as a weak entity, two conditions must be met:1. The entity must be existence-dependent on its parent entity.2. The entity must inherit at least part of its primary key from its parent entity.

For example, the (strong) relationship depicted in the texts Figure 4.10 shows aweak CLASS entity:1. CLASS is clearly existence-dependent on COURSE. (You cant have a

database class unless a database course exists.)2.The CLASS entitys PK is defined through the combination of

CLASS_SECTION and CRS_CODE. The CRS_CODE attribute is also thePK of COURSE.

The conditions that define a weak entity are the same as those for a strongrelationship between an entity and its parent. In short, the existence of a weakentity produces a strong relationship. And if the entity is strong, its relationship tothe other entity is weak. (Note the solid relationship line in the texts Figure4.10.)

Keep in mind that whether or not an entity is weak usually depends on thedatabase designers decisions. For instance, if the database designer haddecided to use a single-attribute as shown in the texts Figure 4.8, the CLASSentity would be strong. (The CLASS entitys PK is CLASS_CODE, which is notderived from the COURSE entity.) In this case, the relationship betweenCOURSE and CLASS is weak. (Note the dashed relationship line in the textsFigure 4.8.) However, regardless of how the designer classifies therelationship weak or strong CLASS is always existence-dependent onCOURSE.

3. What is a strong (or identifying) relationship, and how is it depicted in a

Crows Foot ERD?

8/2/2019 307 Chapter 4

2/20

A strong relationship exists when en entity is existence-dependent on anotherentity and inherits at least part of its primary key from that entity. The VisioProfessional software shows the strong relationship as a solid line. In otherwords, a strong relationship exists when a weak entity is related to its parententity. (Note the discussion in question 1.)

4. Given the business rule an employee may have many degrees, discussits effect on attributes, entities, and relationships. (Hint: Remember what amultivalued attribute is and how it might be implemented.)

Suppose that an employee has the following degrees: BA, BS, and MBA. Thesedegrees could be stored in a single string as a multivalued attribute namedEMP_DEGREE in an EMPLOYEE table such as the one shown next:

EMP_NUM EMP_LNAME EMP_DEGREE123 Carter AA, BBA

124 OShanski BBA, MBA, Ph.D.125 Jones AS126 Ortez BS, MS

Although the preceding solution has no obvious design flaws, it is likely to yieldreporting problems. For example, suppose you want to get a count for allemployees who have BBA degrees. You could, of course, do an in-stringsearch to find all of the BBA values within the EMP_DEGREE strings. But sucha solution is cumbersome from a reporting point of view. Query simplicity is avaluable thing to application developers and to end users who like maximum

query execution speeds. Database designers ought to pay some attention to thecompeting database interests that exist in the data environment.

One very poor solution is to create a field for each expected value. Thissolution is shown next:

EMP_NUM EMP_LNAME EMP_DEGREE1 EMP_DEGREE2 EMP_DEGREE3123 Carter AA BBA124 OShanski BBA MBA Ph.D.125 Jones AS126 Ortez BS MS

This solution yields nulls for all employees who have fewer than three degrees.And if even one employee earns a fourth degree, the table structure must bealtered to accommodate the new data value. (One piece of evidence of poordesign is the need to alter table structures in response to the need to add dataof an existing type.) In addition, the query simplicity is not enhanced by the factthat any degree can be listed in any column. For example, a BA degree might belisted in the second column, after an associate of arts (AA) degree has beenentered in EMP_DEGREE1. One might simplify the query environment bycreating a set of attributes that define the data entry, thus producing thefollowing results:

8/2/2019 307 Chapter 4

3/20

EMP_N

UM

EMP_LN

AME

EMP_

AA

EMP_

AS

EMP_

BA

EMP_

BS

EMP_

BBA

EMP_

MS

EMP_M

BA

EMP_

PhD123 Carter X X124 OShansk

iX X X

125 Jones X126 Ortez X X

This solution clearly proliferates the nulls at an ever-increasing pace.

The only reasonable solution is to create a new DEGREE entity that stores eachdegree in a separate record, this producing the following tables. (There is a 1:M

relationship between EMPLOYEE and DEGREE. Note that the EMP_NUM canoccur more than once in the DEGREE table. The DEGREE tables PK isEMP_NUM + DEGREE_CODE. This solution also makes it possible to recordthe date on which the degree was earned, the institution from which it wasearned, and so on.

Table name: EMPLOYEE

EMP_NUM EMP_LNAME123 Carter124 OShanski

125 Jones126 Ortez

Table name: DEGREE

EMP_NUM DEGREE_CODE DEGREE_DATE DEGREE_PLACE123 AA May-1999 Lake Sumter CC123 BBA Aug-2004 U. of Georgia124 BBA Dec-1990 U. of Toledo124 MBA May-2001 U. of Michigan124 Ph.D. Dec-2005 U. of Tennessee

125 AS Aug-2002 Valdosta State126 BS Dec-1989 U. of Missouri126 MS May-2002 U. of Florida

Note that this solution leaves no nulls, produces a simple query environment,and makes it unnecessary to alter the table structure when employees earnadditional degrees. (You can make the environment even more flexible bynaming the new entity QUALIFICATION, thus making it possible to storedegrees, certifications, and other useful data that define an employeesqualifications.)

5. What is a composite entity, and when is it used?

8/2/2019 307 Chapter 4

4/20

A composite entity is generally used to transform M:N relationships into 1:Mrelationships. (Review the discussion that accompanied Figures IM4.3 throughIM4.5.) A composite entity, also known as a bridge entity, is one that has aprimary key composed of multiple attributes. The PK attributes are inherited from

the entities that it relates to one another.

6. Suppose you are working within the framework of the conceptual model inFigure Q4.5.

Figure Q4.5 The Conceptual Model for Question 5

Given the conceptual model in Figure Q4.5:

a. Write the business rules that are reflected in it.

Even a simple ERD such as the one shown in Figure Q4.5 is based onmany business rules. Make sure that each business rule is written on aseparate line and that all of its details are spelled out. In this case, thebusiness rules are derived from the ERD in a reverse-engineeringprocedure designed to document the database design. In a real worlddatabase design situation, the ERD is generated on the basis of businessrules that are written before the first entity box is drawn. (Remember that thebusiness rules are derived from a carefully and precisely written description

of operations.)

Given the ERD shown in Figure Q4.5, you can identify the followingbusiness rules:

1. A customer can own many cars.2. Some customers do not own cars.3. A car is owned by one and only one customer.4. A car may generate one or more maintenance records.5. Each maintenance record is generated by one and only one car.6. Some cars have not (yet) generated a maintenance procedure.7. Each maintenance procedure can use many parts.

(Comment: A maintenance procedure may include multiplemaintenance actions, each one of which may or may not use

8/2/2019 307 Chapter 4

5/20

parts. For example, 10,000-mile check may include theinstallation of a new oil filter and a new air filter. But tightening analternator belt does not require a part.)

8. A part may be used in many maintenance records.(Comment: Each time an oil change is made, an oil filter is used.

Therefore, many oil filters may be used during some period oftime. Naturally, you are not using the sameoil filter each time but the part classified as oil filter shows up in manymaintenance records as time passes.)

Note that the apparent M:N relationship betweenMAINTENANCE and PART has been resolved through the useof the composite entity named MAINT_LINE. The MAINT_LINEentity ensures that the M:N relationship betweenMAINTENANCE and PART has been broken up to produce thetwo 1:M relationships shown in business rules 9 and 10.

9. Each maintenance procedure generates one or moremaintenance lines.10. Each part may appear in many maintenance lines. (Review thecomment in business rule 8.)

As you review the business rules 9 and 10, use the following two tables toshow some sample data entries. For example, take a look at the (simplified)contents of the following MAINTENANCE and LINE tables and note that theMAINT_NUM 10001 occurs three times in the LINE table:

Sample MAINTENANCE Table Data

MAINT_NUM MAINT_DATE10001 15-Mar-200610002 15-Mar-200610003 16-Mar-2006

Sample LINE Table Data

MAINT_NUM

LINE_NUM

LINE_DESCRIPTION

LINE_PART

LINE_UNITS

10001 1 Replace fuel filter FF-015 1

10001 2 Replace air filter AF-1187 110001 3 Tighten alternator

beltNA 0

10002 1 Replace taillightbulbs

BU-2145 2

10003 1 Replace oil filter OF-2113 110003 2 Replace air filter AF-1187 1

b. Identify all of the cardinalities.

The Visio-generated Crows Foot ERD, shown in Figure Q4.5, does not showcardinalities directly. Instead, the cardinalities are implied through the CrowsFoot symbols. You might write the cardinality (0,N) next to the MAINT_LINE

8/2/2019 307 Chapter 4

6/20

entity in its relationship with the PART entity to indicate that a part might occurN times in the maintenance line entity or that it might never show up in themaintenance line entity. The latter case would occur if a given part has neverbeen used in maintenance.

7. What is a recursive relationship? Given an example.

A recursive relationship exists when an entity is related to itself. For example, aCOURSE may be a prerequisite to a COURSE. (See Section 4.1.10, RecursiveRelationships, for additional examples.

8. How would you (graphically) identify each of the following ERMcomponents in a Crows Foot model?

The answers to questions (a) through (d) are illustrated with the help of FigureQ4.7.

FIGURE Q4.7 Crows Foot ERM Components

STUDENT

STU_NUM (PK)

STU_LNAMESTU_FNAME

STU_INITIALDEPT_CODE (FK)

Simplified Crows Foot entity box

(no attribute component.)STUDENT

Crows Foot entity box

(attribute component included.)

Crows Foot connectivity symbol,

implied (0,N) cardinality.

A weak relationship

A strong relationship

a. an entity

An entity is represented by a rectangle containing the entity name.(Remember that, in ER modeling, the word "entity" actually refers to theentity set.)

The Crows Foot ERD as represented in Visio Professional does notdistinguish among the various entity types such as weak entities andcomposite entities. Instead, the Crows Foot ERD uses relationshiptypesstrong or weak to indicate the nature of the relationships between entities.For example, a strong relationship indicates the existence of a weak entity.

8/2/2019 307 Chapter 4

7/20

A composite entity is defined by the fact that at least one of the PKattributes is also a foreign key. Therefore, the Visio Crows Foot ERDscomposite and weak entities are not differentiated whether or not an entityis weak or composite depends on the definition of the business rule(s) thatdescribe the relationships. In any case, two conditions must be met before

an entity can be classified as weak:1. The entity must be existence-dependent on its parent entity2. The entity must inherit at least part of its primary key from its parententity.

b. the cardinality (0,N)

Cardinalities are implied through the use of Crows Foot symbols. Forexample, note the implied (0,N) cardinality in Figure Q4.7.

c. a weak relationship

A weak relationship exists when the PK of the related entity does notcontain at least one of the PK attributes of the parent entity. For example, ifthe PK of a COURSE entity is CRS_CODE and the PK of the relatedCLASS entity is CLASS_CODE, the relationship between COURSE andCLASS is weak. (Note that the CLASS PK does not include the CRS_CODEattribute.) A weak relationship is indicated by a dashed line in the (Visio)ERD.

d. a strong relationship

A strong relationship exists when the PK of the related entity contains atleast one of the PK attributes of the parent entity. For example, if the PK ofa COURSE entity is CRS_CODE and the PK of the related CLASS entity isCRS_CODE + CLASS_SECTION, the relationship between COURSE andCLASS is strong. (Note that the CLASS PK includes the CRS_CODEattribute.) A strong relationship is indicated by a solid line in the (Visio) ERD.

9. Discuss the difference between a composite key and acomposite attribute. How would each be indicated in an ERD?

A composite key is one that consists of more than one attribute. If the ERdiagram contains the attribute names for each of its entities, a composite key isindicated in the ER diagram by the fact that more than one attribute name isunderlined to indicate its participation in the primary key.

A composite attribute is one that can be subdivided to yield meaningfulattributesfor each of its components. For example, the composite attribute CUS_NAMEcan be subdivided to yield the CUS_FNAME, CUS_INITIAL, and CUS_LNAMEattributes. There is no ER convention that enables us to indicate that an attributeis a composite attribute.

10. What two courses of action are available to a designer when he or sheencounters a multivalued attribute?

8/2/2019 307 Chapter 4

8/20

The discussion that accompanies the answer to question 3 is valid as an answerto this question.

11. What is a derived attribute? Give an example.

A derived attribute is an attribute whose value is calculated (derived) from otherattributes. The derived attribute need not be physically stored within thedatabase; instead, it can be derived by using an algorithm. For example, anemployees age, EMP_AGE, may be found by computing the integer value of t hedifference between the current date and the EMP_DOB. If you use MS Access,you would use INT((DATE() EMP_DOB)/365).Similarly, a sales clerk's total gross pay may be computed by adding a computedsales commission to base pay. For instance, if the sales clerk's commission is1%, the gross pay may be computed byEMP_GROSSPAY = INV_SALES*1.01 + EMP_BASEPAY

Or the invoice line item amount may be calculated byLINE_TOTAL = LINE_UNITS*PROD_PRICE

12. How is a relationship between entities indicated in an ERD?Give an example, using the Crows Foot notation.

Use Figure Q4.7 as the basis for your answer. Note the distinction between thedashed and solid relationship lines, then tie this distinction to the answers toquestion 7c and 7d.

13. Discuss two ways in which the 1:M relationship between COURSE andCLASS can be implemented. (Hint: Think about relationship strength.)

Note the discussion about weak and strong entities in questions 7c and 7d. Thenfollow up with this discussion:

The relationship is implemented as strongwhen the CLASS entitys PK containsthe COURSE entitys PK. For example,

COURSE(CRS_CODE, CRS_TITLE, CRS_DESCRIPTION, CRS_CREDITS)CLASS(CRS_CODE, CLASS_SECTION, CLASS_TIME, CLASS_PLACE)

Note that the CLASS entitys PK is CRS_CODE + CLASS_SECTION and thatthe CRS_CODE component of this PK has been borrowed from the COURSEentity. (Because CLASS is existence-dependent on COURSE and uses a PKcomponent from its parent (COURSE) entity, the CLASS entity is weak in thisstrong relationship between COURSE and CLASS. The Visio Crows Foot ERDshows a strong relationship as a solid line. (See Figure Q4.12a.) Visio refers to astrong relationship as an identifyingrelationship.

Figure Q4.12a Strong COURSE and CLASS Relationship

8/2/2019 307 Chapter 4

9/20

Sample data are shown next:

Table name: COURSE

CRS_CODE CRS_TITLE CRS-DESCRIPTION CRS_CREDITSACCT-211 Basic Accounting An introduction to accounting.

Required of all business majors.3

CIS-380 DatabaseTechniques I

Database design andimplementation issues. Uses CASE

tools to generate designs that arethen implemented in a majordatabase management system.

3

CIS-490 DatabaseTechniques II

The second half of CIS-380. BasicWeb database applicationdevelopment and managementissues.

4

Table name: CLASS

CRS_CO

DE

CLASS_SECTI

ON

CLASS_TIME CLASS_PLA

CEACCT-211 1 8:00 a.m. 9:30 a.m. T-Th. Business 325ACCT-211 2 8:00 a.m. 8:50 a.m. MWF Business 325ACCT-211 3 8:00 a.m. 8:50 a.m. MWF Business 402CIS-380 1 11:00 a.m. 11:50 a.m.

MWFBusiness 415

CIS-380 2 3:00 p.m. 3:50 a.m. MWF Business 398CIS-490 1 1:00 p.m. 3:00 p.m. MW Business 398CIS-490 2 6:00 p.m. 10:00 p.m. Th. Business 398

The relationship is implemented as weakwhen the CLASS entitys PK does not

contain the COURSE entitys PK. For example,

COURSE(CRS_CODE, CRS_TITLE, CRS_DESCRIPTION, CRS_CREDITS)CLASS(CLASS_CODE, CRS_CODE, CLASS_SECTION, CLASS_TIME,CLASS_PLACE)

(Note that CRS_CODE is no longer part of the CLASS PK, but that it continuesto serve as the FK to COURSE.)

The Visio Crows Foot ERD shows a weak relationship as a dashed line. (SeeFigure Q4.12b.) Visio refers to a weak relationship as a non-identifyingrelationship.

8/2/2019 307 Chapter 4

10/20

Figure Q4.12b Weak COURSE and CLASS Relationship

Given the weak relationship depicted in Figure Q4.13b, the CLASS tablecontents would look like this:

Table name: CLASS

CLASS_CO

DE

CRS_CO

DE

CLASS_SECTI

ON

CLASS_TIME CLASS_PLA

CE21151 ACCT-211 1 8:00 a.m. 9:30 a.m.T-Th.

Business 325

21152 ACCT-211 2 8:00 a.m. 8:50 a.m.MWF

Business 325

21153 ACCT-211 3 8:00 a.m. 8:50 a.m.MWF

Business 402

38041 CIS-380 1 11:00 a.m. 11:50a.m. MWF

Business 415

38042 CIS-380 2 3:00 p.m. 3:50 a.m.MWF

Business 398

49041 CIS-490 1 1:00 p.m. 3:00 p.m.MW

Business 398

49042 CIS-490 2 6:00 p.m. 10:00 p.m.Th.

Business 398

The advantage of the second CLASS entity version is that its PK can bereferenced easily as a FK in another related entity such as ENROLL. Using asingle-attribute PK makes implementation easier. This is especially true whenthe entity represents the 1 side in one or morerelationships. In general, it isadvisable to avoid composite PKs whenever it is practical to do so.

You can demonstrate how Microsoft Visio helps you to define the weakrelationship by clicking on the Miscellaneous option and then clicking on theNon-identifying relationship type. (See Figure Q4.12c. Appendix A provides atutorial on how to create Crows Foot ERDs with Microsoft Visio.) If youclick on the Identifying relationship type, Visio will automatically redefine theCLASS entitys PK and the relationship line depiction to match Figure Q4.12a.

Figure Q4.13c Visio Definition of a Weak COURSE and CLASS Relationship

8/2/2019 307 Chapter 4

11/20

14. How is a composite entity represented in an ERD, and what is its function?Illustrate the Crows Foot model.

The label "composite" is based on the fact that the composite entity contains atleast the primary key attributes of each of the entities that are connected by it.The composite entity is an important component of the ER model because

relational database models should not contain M:N relationships and thecomposite entity can be used to break up such relationships into 1:Mrelationships.

Remind students to heed the advice given in the answer to the previousquestion. That is, avoid composite PKs whenever it is practical to do so.Note that the CLASS entity structure shown in Figure Q4.12b is far better thanthat of the CLASS entity structure shown in Figure Q4.12a. Suppose, forexample, that you want to design a class enrollment entity to serve as thebridge between STUDENT and CLASS in the M:N relationship defined bythese two business rules:

A student can take many classes.

Each class can be taken by many students.

In this case, you could create a (composite) entity named ENROLL to linkCLASS and STUDENT, using these structures:

STUDENT(STU_NUM, STU_LNAME ..)ENROLL(STU_NUM, CLASS_NUM, ENROLL_GRADE )CLASS(CLASS_CODE, CRS_CODE, CLASS_SECTION, CLASS_TIME,CLASS_PLACE)

Your students might argue that a composite PK in ENROLL does no harm, since

8/2/2019 307 Chapter 4

12/20

it is not likely to be related to another entity in the typical academic databasesetting. Although that is a good observation, you would run into a problem in theevent that might trigger a required relationship between ENROLL and anotherentity. In any case, you may simplify the creation of future relationships if youcreate an artificial single-attribute PK such as ENROLL_NUM, while

maintaining the STU_NUM and CLASS_NUM as FK attributes. In other words:

ENROLL(ENROLL_NUM, STU_NUM, CLASS_NUM, ENROLL_GRADE )

The ENROLL_NUM attribute values can easily be generated through the properuse of SQL code or application software, thus eliminating the need for data entryby humans.

The use of composite vs. single-attribute PKs is worth discussing. CompositePKs are frequently encountered in composite entities and your students will seethat MS Visio will generate composite PKs automatically when you classify a

relationship as strong. Composite PKs are not wrong is any sense, butminimizing their use does make the implementation of multiple relationshipssimple Simple is generally a good thing!

NOTEBecause composite entities are frequently encountered in the real worldenvironment, we continue to use them in the text and in many of our exercisesand examples. However, the words of caution about their use should be repeatedfrom time to time and you might ask your students to convert such compositeentities.

Lets examine another example of the use of composite entities. Suppose that atrucking company keeps a log of its trucking operations to keep track of itsdriver/truck assignments. The company may assign any given truck to anygiven driver many times and, as time passes, each driver may be assigned todrive many of the company's trucks. Since this M:N relationship should not beimplemented, we create the composite entity named LOG whose attributes aredefined by the end-user information requirements. In this case, it may be usefulto include LOG_DATE, TRUCK_NUM, DRIVER_NUM, LOG_TIME_OUT, andLOG_TIME_IN.

Note that the LOG's TRUCK_NUM and DRIVER_NUMattributes are the driverLOG's foreign keys. The TRUCK_NUM and DRIVER_NUM attribute valuesprovide the bridge between the TRUCK and DRIVER, respectively. In otherwords, to form a proper bridge between TRUCK and DRIVER, the compositeLOG entity must contain at least the primary keys of the entities connected by it.

You might think that the combination of the composite entitys foreign keys maybe designated to be the composite entity's primary key. However, thiscombination will not produce unique values over time. For example, the samedriver may drive a given truck on different dates. Adding the date to the PK

attributes will solve that problem. But we still have a non-unique outcome whenthe same driver drives a given truck twice on the same date. Adding a time

8/2/2019 307 Chapter 4

13/20

attribute will finally create a unique set of PK attribute values but the PK is nowcomposed of four attributes: TRUCK_NUM, DRIVER_NUM, LOG_DATE, andLOG_TIME_OUT. (The combination of these attributes yields a unique outcome,because the same driver cannot check out two trucks at the same time on agiven date.)

Because multi-attribute PKs may be difficult to manage, it is oftenadvisable to create an artificial single-attribute PK, such as LOG_NUM,to uniquely identify each record in the LOG table. (Access users can definesuch an attribute to be an autonumber to ensure that the system will generateunique LOG_NUM values for each record.) Note that this solution produces aLOG table that contains two candidate keys: the designated primary key and thecombination of foreign keys that couldhave served as the primary key.

While the preceding solution simplifies the PK definition, it does not prevent thecreation of duplicate records that merely have a different LOG_NUM value.

Note, for example, the first two records in the following table:

LOG_NUM

LOG_DATE

TRUCK_NUM

DRIVER_NUM

LOG_TIME_OUT

LOG_TIME_IN

10015 12-Mar-2006

322453 1215 07:18 a.m. 04:23p.m.

10016 12-Mar-2006

322453 1215 07:18 a.m. 04:23p.m.

10017 12-Mar-2006

545567 1298 08:12 a.m. 09:15p.m.

To avoid such duplicate records, you can create a unique index onTRUCK_NUM + DRIVER_NUM + LOG_DATE + LOG_TIME_OUT.

Composite entities may be named to reflect their component entities. Forexample, an employee may have several insurance policies (life, dental,accident, health, etc.) and each insurance policy may be held by manyemployees. This M:N relationship is converted to a set of two 1:M relationships,by creating a composite entity named EMP_INS. The EMP_INS entity mustcontain at least the primary key components of each of the two entitiesconnected by it. How many additional attributes are kept in the composite entity

depends on the end-user information requirements.

15. What three (often conflicting) database requirements must be addressed indatabase design?

Database design must reconcile the following requirements:

Design elegance requires that the design must adhere to design rulesconcerning nulls, derived attributes, redundancies, relationship types, andso on.

Information requirements are dictated by the end users

Operational (transaction) speed requirements are also dictated by the end

users.

8/2/2019 307 Chapter 4

14/20

Clearly, an elegant database design that fails to address end user informationrequirements or one that forms the basis for an implementation whose useprogresses at a snail's pace has little practical use.

16. Briefly, but precisely, explain the difference between single-valued

attributes and simple attributes. Give an example of each.

A single -valued attribute is one that can have only one value. For example, aperson has only one first name and only one social security number.

A simple attribute is one that cannot be decomposed into its component pieces.For example, a person's sex is classified as either M or F and there is noreasonable way to decompose M or F. Similarly, a person's first name cannot bedecomposed into meaningful components. (In contrast, if a phone numberincludes the area code, it can be decomposed into the area code and the phonenumber. And a person's name may be decomposed into a first name, an initial,

and a last name.)

Single-valued attributes are not necessarily simple. For example, aninventory code HWPRIJ23145 may refer to a classification scheme in which HWindicates Hardware, PR indicates Printer, IJ indicates Inkjet, and 23145 indicatesan inventory control number. Therefore, HWPRIJ23145 may be decomposed intoits component parts... even though it is single-valued. To facilitate producttracking, manufacturing serial codes must be single-valued, but they may not besimple. For instance, the product serial number TNP5S2M231109154321 mightbe decomposed this way:

TN = state = TennesseeP5 = plant number 5S2 = shift 2M23 = machine 2311 = month, i.e., November09 = day

154321 = time on a 24-hour clock, i.e., 15:43:21, or 3:43 p.m. plus 21 seconds.

17. What are multivalued attributes, and how can they be handled within thedatabase design?

The answer to question 3 is just as valid as an answer to this question. You canaugment that discussion with the following discussion:

As the name implies, multi-valued attributes may have many values. Forexample, a person's education may include a high school diploma, a 2-yearcollege associate degree, a four-year college degree, a Master's degree, aDoctoral degree, and various professional certifications such as a CertifiedPublic Accounting certificate or a Certified Data Processing Certificate.

There are basically three ways to handle multi-valued attributes -- and two ofthose three ways are

bad:

8/2/2019 307 Chapter 4

15/20

1. Each of the possible outcomes is kept as a separate attribute within the table.This solution is undesirable for several reasons. First, the table wouldgenerate many nulls for those who had minimal educational attainments.Using the preceding example, a person with only a high school diplomawould generate nulls for the 2-year college associate degree, the four-year

college degree, the Master's degree, the Doctoral degree, and for each of theprofessional certifications. In addition, how many professional certificationattributes should be maintained? If you store two professional certificationattributes, you will generate a null for someone with only one professionalcertification and you'd generate two nulls for all persons without professionalcertifications. And suppose you have a person with five professionalcertifications? Would you create additional attributes, thus creating manymore nulls in the table, or would you simply ignore the additional professionalcertifications, thereby losing information?

2. The educational attainments may be kept as a single, variable-length string or

character field. This solution is undesirable because it becomes difficult toquery the table. For example, even a simple question such as "how manyemployees have four-year college degrees?" requires string partitioning thatis time-consuming at best. Of course, if there is no need to ever groupemployees by education, the variable-length string might be acceptable froma design point of view. However, as database designers we know that,sooner or later, information requirements are likely to grow, so the stringstorage is probably a bad idea from that perspective, too.

3. Finally, the most flexible way to deal with multi-valued attributes is to create acomposite entity that links employees to education. By using the compositeentity, there will never be a situation in which additional attributes must becreated within the EMPLOYEE table to accommodate people with multiplecertifications. In short, we eliminate the generation of nulls. In addition, wegain information flexibility because we can also store the details (dateearned, place earned, etc.) for each of the educational attainments. The(simplified) structures might look like those in Figure Q4.16 A and B.

The Ch04_Questions database is located on the Instructors CD.Please look in the \Ch04-ER-Modeling\Databases\Teacher\ folder. Your

students may use the databases available on the Student OnlineCompanion.

Figure Q4.16a The Ch04_Questions Database Tables

8/2/2019 307 Chapter 4

16/20

Figure Q4.16b The Ch04_Questions Relational Diagram

By looking at the structures shown in Figures Q4.16a and Q4.16b, we cantell that the employee named Romero earned a Bachelor's degree in 1989,a Certified Network Professional certification in 2002, and a Certified DataProcessing certification in 2004. If Randall were to earn a Master's degreeand a Certified Public Accountant certification later, we merely add anothertwo records in the EMP_EDUC table. If additional educational attainmentsbeyond those listed in the EDUCATION table are earned by any employee,all we need to do is add the appropriate record(s) to the EDUCATION table,then enter the employee's attainments in the EMP_EDUC table. There areno nulls, we have superb query capability, and we have flexibility. Not a badset of design goals!

The database design on which Figures Q4.16a and Q4.16b are based isshown in Figure Q4.16c.

Figure Q4.16c The Crows Foot ERD for the Ch04_Questions Database

8/2/2019 307 Chapter 4

17/20

NOTEDiscuss with the students that the design in Figure Q4.16c shows that anemployee must meet at least one educational requirement, becauseEMP_EDUC is not optional to EMPLOYEE. Thus each employee must appearat least once in the EMP_EDUC table. And, given this design, some of theeducational attainments may not yet been earned by employees, because thedesign shows EMP_EDUC to be optional to EDUCATION. In other words,some of the EDUCATION records are not necessarily referenced by anyemployee. (In the original M:N relationship between EMPLOYEE and

EDUCATION, EMPLOYEE must have been optional to EDUCATION.)

8/2/2019 307 Chapter 4

18/20

The final four questions are based on the ERD in Figure Q4.17.

FIGURE Q4.17 The ERD For Questions 1720

18. Write the ten cardinalities that are appropriate for this ERD.

The cardinalities are indicated in Figure Q4.17sol.

FIGURE Q4.17sol The Cardinalities

19. Write the business rules reflected in this ERD.

The following business rules are reflected in the ERD:

A store may place many orders. (Note the use of may which isreflected in the ORDER optionality.)

An order must be placed by a store. (Note that STORE is mandatory toORDER. In this ERD, the order environment apparently reflects awholesale environment.)

An order contains at least one order line. (Note that ORDER_LINE ismandatory to ORDER, and vice-versa.)

Each order line is contained in one and only one order. (Discussion:Although a given item such as a hammer may be found in many

orders, a specific hammer sold to a specific store is found in only oneorder.)

8/2/2019 307 Chapter 4

19/20

Each order line has a specific product written in it.

A product may be written in many orders. (Discussion: Many stores canorder one or more specific products, but a product that is not in demandmay never be sold to a store and will, therefore, not show up in any orderline -- note that ORDER_LINE is optional to PRODUCT. Also, note that

each order line may indicate more than one of a specific item. Forexample, the item may be hammer and the number sold may be 1 or 2,or 500. The ORDER_LINE entity would have at least the followingattributes: ORDER_NUM, ORDLINE_NUM, PROD_CODE,ORDLINE_PRICE, ORDLINE_QUANTITY. The ORDER_LINE compositePK would be ORDER_NUM + ORDLINE_NUM. You might add the derivedattribute ORDLINE_AMOUNT, which would be the result of multiplyingORDLINE_PRICE and ORDLINE_QUANTITY.)

A store may employ many employees. (Discussion: A new store may notyet have any employees, yet the database may already include the newstore information location, type, and so on. If you made the EMPLOYEEentity mandatory to STORE, you would have to create an employee forthat store before you had even hired one.)

Each employee is employed by one (and only one) store.

An employee may have one or more dependents. (Discussion: You cannotrequirean employee to have dependents, so DEPENDENT is optional toEMPLOYEE. Note the use of the word may in the relationship.)

A dependent must be related to an employee. (Discussion: It makes nosense to keep track of dependents of people who are not even employees.Therefore, EMPLOYEE is mandatory to DEPENDENT.)

20. What two attributes must be contained in the composite entity betweenSTORE and PRODUCT? Use proper terminology in your answer.

The composite entity must at least include the primary keys of the entities itreferences. The combination of these attributes may be designated to be thecomposite entity's (composite) primary key. Each of the (composite) primarykey's attributes is a foreign key that references the entities for which thecomposite entity serves as a bridge.

As you discuss the model in Figure Q4.17sol, note that an order is representedby two entities, ORDER and ORDER_LINE. Note also that the STOREs 1:M

relationship with ORDER and the ORDERs 1:M relationship with ORDER_LINEreflect the conceptual M:N relationship between STORE and PRODUCT. Theoriginal business rules probably read:

A store can order many products

A product can be ordered by many stores.

8/2/2019 307 Chapter 4

20/20

21. Describe precisely the composition of the DEPENDENT weak entitys primarykey. Use proper terminology in your answer.

The DEPENDENT entity will have a composite PK that includes the EMPLOYEEentitys PK and one of its attributes. For example, if the EMPLOYEE entitys PK is

EMP_NUM, the DEPENDENT entitys PK might be EMP_NUM + DEP_NUM.