database management systems edition 9 chapter 3

7/27/2019 Database management Systems edition 9 Chapter 3

1/45

Database management Systems edition 9

Chapter 3

Answers to Review Questions

1. Define each of the following terms:

a. Entity type A collection of entities that share common properties orcharacteristics.

b. Entity-relationship model A logical representation of the data for an organization

or for a business area.c. Entity instance A single occurrence of an entity type.

d. Attribute A property or characteristic of an entity type that is of interest to the

organization.

e. Relationship type A meaningful association between (or among) entity types.f. Identifier An attribute (or combination of attributes) that uniquely identifies

individual instances of an entity type.

g. Multivalued attribute An attribute that may tae on more than one value for a

given entity instance.h. Associative entity An entity type that associates the instances of one or more

entity types and contains attributes that are peculiar to the relationship betweenthose entity instances.

i. Cardinality constraint !pecifies the number of instances of one entity that can

(or must) be associated with each instance of another entity.". Weak entity An entity type whose e#istence depends on some other entity type.

. Identifying relationship $he relationship between a wea entity type and its

owner.

l. Derived attribute An attribute whose values can be calculated from relatedattribute values.

m. Multivalued attribute !ee letter g.n. usiness rule A statement that defines or constrains some aspect of the business.

%. &atch the following terms and definitions:

i composite attributed associative entity

b unary relationship

" wea entity

h attributem entity

e relationship type

c cardinality constraintg degree

a identifier

f entity type ternary

l bill'of'materials


2/45

. ontrast the following terms:

a. !tored attribute" derived attribute A stored attribute is one whose values are

stored in the database* while a derived attribute is one whose values can becalculated or derived from related stored attributes.

b. !imple attribute" composite attribute A simple attribute is one that cannot be

broen down into smaller components* while a composite attribute can be broendown into component parts.

c. Entity type" relationship type An entity type is a collection of entities that share

common properties or characteristics* while a relationship type is a meaningfulassociation between (or among) entity types.

d. !trong entity type" #eak entity type A strong entity type is an entity that e#ists

independently of other entity types* while a wea entity type depends on some

other entity type.e. Degree" cardinality $he degree (of a relationship) is the number of entity types

that participate in that relationship* while cardinality is a constraint on the number

of instances of one entity that can (or must) be associated with each instance of

another entity.f. Re$uired attribute" optional attribute A required attribute must have a value for

each entity instance* whereas an optional attribute may not have a value for everyentity instance.

g. Composite attribute" multivalued attribute A composite attribute has component

parts that give meaning* whereas a multivalued attribute may tae on or morevalues for an entity instance.

+. $hree reasons why data modeling is the most important part of the system development

process:a. $he characteristics of data captured during data modeling are crucial in the design

of databases* programs* and other system components. ,acts and rules that are

captured during this process are essential in assuring data integrity in aninformation system.

b. Data* rather than processes* are the most important aspects of many modern

information systems and hence* require a central role in structuring systemrequirements.

c. Data tend to be more stable than the business processes that use the data. $hus*

an information system that is based on a data orientation should have a longer

useful life than one based on a process orientation.

-. ,our reasons why a business rules approach is advocated as a new paradigm for

specifying information systems requirements:a. usiness rules are a core concept in an enterprise since they are an e#pression of

business policy* and they guide individual and aggregate behavior. /ell'

structured business rules can be stated in a natural language for end users and in adata model for system developers.

b. usiness rules can be e#pressed in terms that are familiar to end users. $hus*

users can define and then maintain their own rules.

c. usiness rules are highly maintainable: they are stored in a central repository and


3/45

each rule is e#pressed only once* then shared throughout the organization.

d. 0nforcement of business rules can be automated through the use of software that

can interpret the rules and enforce them using the integrity mechanisms of thedatabase management system.

. usiness rules appear in descriptions of business functions* events* policies* units*staeholders* and other ob"ects. $hese descriptions can be found in interview notes from

individual and group information systems requirements collection sessions*

organizational documents* and other sources. 2ules are identified by asing questionsabout the who* what* when* where* why* and how of the organization.

3. !i# general guidelines for naming data ob"ects in a data model:

a. Data names should relate to business* not technical characteristics.b. Data names should be meaningful* almost to the point of being self'documenting.

c. Data names should be unique from the name used for every other distinct data

ob"ect.

d. Data names should be readable* so the name is structured as the concept wouldmost naturally be said.

e. Data names should be composed of words taen from an approved list.f. Data names should be repeatable* meaning that different people or the same

person at different times should develop e#actly or almost the same name.

4. ,our criteria for selecting identifiers for entities:

a. hoose an identifier that will not change its value over the life of each instance of

the entity type.

b. hoose an identifier such that for each instance of the entity the attribute isguaranteed to have valid values and not be null (or unnown).

c. Avoid the use of so'called intelligent identifiers (or eys)* whose structure

indicates classifications* locations* and so on.d. onsider substituting single'attribute surrogate identifiers for large composite

identifiers.

5. $hree conditions that suggest the designer should model a relationship as an associative

entity type are:

a. All of the relationships for the participating entity types are 6many7 relationships.

b. $he resulting associative entity type has independent meaning to end users* and itpreferably can be identified with a single'attribute identifier.

c. $he associative entity has one or more attributes in addition to the identifier.


4/45

,our types of cardinality constraints are:

a. 8ptional one:

b. &andatory one:

c. 8ptional many:

d. &andatory many:

11. 98;0 A


5/45

1%. $he degree of a relationship is the number of entity types that participate in the

relationship.

1) >nary (one entity type):

%) inary (two entity types):

) $ernary (three entity types):


6/45

1. Attribute e#amples:

a. Derived ? distance (rate # time)b. &ultivalued ? spoen language

c. omposite ? flight @D (flight number date)

1+. 0#amples of relationships:

a. $ernary

b. >nary


7/45

1-.

1./hen the attribute is the identifier or some other characteristic of an entity type in the

data model* and multiple entity instances need to share these same attributes.

13. A relationship name should always be a verb phrase and should state the action taen*

as opposed to the result of the action taen.

>se descriptive* powerful verb phrases as opposed to vague names.

14. $he relationship definition should also e#plain the following:

any optional participation

the reason for any e#plicit ma#imum cardinality

any mutually e#clusive relationships

any restrictions on participation in the relationship

the e#tent of history that is ept in the relationship

whether an entity instance involved in a relationship instance can transfer

participation to another relationship instance

15. 9resently* the cardinality is one'to'many. 8ne possible scenario is an employee who is

supervised by more than one manager. $his would mae the cardinality many'to'many.

Another possibility is that the employee is supervised by one manager* and the manageronly supervises one employee. $his would result in a one'to'one cardinality. @f we tae

timeBhistory into consideration* the idea of someone being managed currently versus

never being managed could affect the cardinality. As we can see here* you cannot always

tell what the business rule is by looing at the 02D. $hese possible scenarios will need

to be discussed with the end user to determine the 6correct7 modeling representation forthe business rules at this organization.

%C. An entity type can be thought of as a template* defining all of the characteristics of an

entity instance. ,or e#ample* 6student7 would be an entity type* whereasyouare an

instance of 6student.7


8/45

Answers to Problems and Exerises

1. 0ach answer refers to ,igure '%% found in the chapter te#t.

a) /here is a unary relationship* what does it mean* and for what reasons might the

cardinalities on it be different in other organizations

A unary relationship is shown with the 0&9


9/45

$he DoesFusinessF@n associative entity associates a single instance of a

!A!$8&02 for the overriding &:&

DoesFusinessF@n relationship between !A!$8&02. 0achDoesFusinessF@n instance must be related to e#actly one !A!$8&02 because the business rules of 9G, indicate that sales territories have been

established for its customers. @n particular* the rules are: a !A&E!'(ERRI()R* hasone-to-many C+!()MERs" and a C+!()MER may do business in ,M!A&E!'(ERRI()RIE!. /hen converting this &:& relationship on the 02D* the

cardinalities near the originating entities will always be mandatory 1* indicating the

e#actly one relationship with each entityHs instances and the associative entityHs instance.

f) @n what way might 9ine Galley change the way it does business that would cause the!upplies associative entity to be eliminated and the relationships around it change

According to current business practice at 9G,* each 2A/F&A$02@A< is provided by

1 or more G0;D82s and a G0;D82 supplies C* 1* or many 2A/F&A$02@AnitF9rice attribute could become part of the

2A/F&A$02@A< entity instance= the !upplies associative entity would no longer need

to be on the 02D.

%. Analysis of ,igure '%%:

%.1. 0ntities 928D>$* 928D>$F!$8&02* 82D02= relationship !ubmits%.. 0ntities 82D02* 928D>$= associative entity 8rderF!$8&02* !A


10/45

+.

+a) $he 02D for ity does not (nor does any 02D) tell us why the cardinality is 1:&.

$he more restrictive cardinality for ity could be due to a business rule that they wantto maintain only current volunteers but it could also be due to only tracing the agency

for which the volunteer wors the most hours of assistance. &ore detailed discussions

would need to be held with the end users to properly document this business rule= notesshould be added to the diagram to depict the appropriate business rule.

+b) $he 02D for ity A shows that a volunteer may assist one* none* or several agencies.

+c) $he native notation used in 02Ds does not show whether membership in a relationship

can change (i.e.* whether a volunteer can change agencies or whether an agency can

change its volunteers). !ome D&!s can be told whether membership can change ornot* and special notation or te#tual notes can be added to an 02D to state such business

rules. $he minimum cardinality ne#t to Agency does address whether a Golunteer must

always be associated with an Agency to e#ist in the database* but none of the

cardinalities control whether linages between specific agencies and volunteers canchange. &ore detailed discussions would need to be held with the end users to properly

document this business rule= notes should be added to the diagram to depict theappropriate business rule.

ity A ity anJt $ell

a. /hich city maintains data about only those volunteers who

currently assist agencies

!

b. @n which city would it be possible for a volunteer to assist more

than one agency

!

c. @n which city would it be possible for a volunteer to change

which agency or agencies she assists.

!


11/45

-.

-a.

Ees* the attribute names do generally follow the guidelines for naming attributes.

-b.

Assignment: All three entities participate in the Assigned relationship that is modeled as anassociative entity Assignment* since the AssignFDate for each hemistHs assignment to a

particular pro"ect and equipment item must be traced. owever* 0K>@9&0;$ and 928L0$

do not need to participate in any assignments. All entities can have multiple assignments.


12/45

-c.

;ote: !0$@8; is modeled as a wea entity. @t could have been modeled as a multivaluedattribute= however* using a wea entity is better* since !0$@8; may have a relationship with

another entity. A multivalued attribute could not be used to show this relationship.

-d.

othAdmitsand (reatsrelationships were created since the patient could be treated by different

9E!@@A;s than the admitting 9E!@@A;.


13/45

-e. "irst situation: credit chec can be used by more than 1 request.

>sing 1 entity type seems much simpler since the credit chec and rating only apply tothis credit request. owever* reditFhecFDate and reditF2ating will be blan (null)

until the credit chec is received.

-f. !tarting point diagram:


14/45

(-f continued) !ituation 1 ' Adding ourlyF2ate attribute: this could be added to the 8;!>


15/45

-g.


16/45

-h.NOTES TO INSTRUCTOR for P&E 5h: (his problem and e%ercise is a good lead-in for

Chapter / modeling notation for the E%tended Entity Relationship Diagram 0EERD1. (he 23E

offers several chances to provide better representation in the EERD 0#ith subtyping1 than theERD notation that is provided in Chapter 4. +sing EERD notation5 a single &E6A&'E7(I(*

can be sho#n as a supertype5 #ith subtypes of DE8E7DA7( and 2&AI7(I88. (he 9type:

0person or )rgani;ation1 characteristic of both DE8E7DA7( and 2&AI7(I88 may also beconsidered for further subtyping. (he solution presented here is a valid ans#er to the 23E5

given the limitations of basic ERD notation and #hat is currently kno#n about the situation.

(his 23E also provides the instructor #ith an opportunity to discuss ho# history might be

modeled if the business assumption regarding the tracking of 7et'Worth for both 2laintiff and

Defendant #as changed from only being concerned #ith 7et'Worth at the time of the CA!E5 to

#anting to track the 7et'Worth over time of each party to the CA!E. Refer to the chaptersection on ? for more information on ho# this

ERD could be revised.


17/45

-i.


18/45

. ;8$0: $he addition of !emester and Eear attributes on the 2egistersFfor relationship

allows this diagram (and resulting database) to reflect multiple semesters of data.

3. ;ote: Assume !tudentF;ame is unique and available to be used as the identifier.


19/45

4.


20/45

4.

5. ;ote: attributes are omitted to save space in the @nstructorHs &anual.

a.

b.

c.


21/45

d.


22/45

e.

f.


23/45

1C.


24/45

9roblem M 0#ercise 1Ce:

$he solution in 1Cd does not place any restrictions on the number of persons to whom any oneperson is simultaneously married* thus the 1Cd solution is sufficient in representing the lac of

legal restrictions regarding the number of marriage partners.


25/45

11.


26/45

1%. Are associative entities also wea entities /hy or why not @f yes* is there anything special

about their 6weaness7

A wea entity requires the presence of another entity type= the wea entity does not e#ist

independently from the other entity type and has no business meaning in the 02D withoutthe other entity type. A wea entity will not have its own identifier* but will have a partial

identifier attribute that will later be combined with the identifier of its strong entity owner tocreate a full identifier.

An associative entity is an entity type that associates the instances of one or more entity types

and contains attributes specific to the relationship between those entity instances. An

associative entity generally has independent business meaning to end users and can beidentified with a single'attribute identifier. @f an associative entity meets these conditions*

then it would not be considered a wea entity.

1. ,igure '%3 shows two diagrams (A and )* both of which are legitimate ways to representthat a stoc has a history of many prices. /hich of the two diagrams do you consider abetter way to model this situation and why

#$%E %$ S%R'C%$R: !tudent answers may vary. $he cru# of the answer relies upon

what is the purpose of the 02 diagram for the modeling situation and how end users in the

organization 6see7 the situation. @n particular* do people in the organization have a term forstocFprice and refer to it as its own concept @f so* solution may be the 6better7 way to

model this situation. @nstructors may also use solution to demonstrate an issue related to

view integration (topic in chapter -) where transitive dependencies emerge= solution maesthe model easy to e#pand so that stoc prices may have relationships that do not directly

involve the !$8I entity.

!olution A indicates that each !$8I has multiple prices and is well'suited to early

discussions with end users about the data needs of a system. !olution adds theprecision of multiple !$8IF92@0 entity instances occurring for each !$8I entity

instance. !olution indicates that !$8IF92@0 is a wea entity whose instances do

not e#ist independently in the database without a corresponding !$8I entity instance.

!olution presents more precise detail of the data relationships that will liely bedeveloped in the logical design of the database= this model may more closely resemble

the relational model implementation of this design. !olution also maes it easy to

e#pand the model so that stoc prices may have relationships with other entities that donot directly involve the !$8I entity.

$he cru# of the answer relies upon what is the purpose of the 02 diagram for themodeling situation and how end users in the organization 6see7 the situation.


27/45

1+.

1+.

()*

Alternative One: 15a

Problem + Exerise ()a

Amerian Express

,onthly Statement o- Aount ERD . initial dra-t

C'S%$,ER

Customer/&D

Customer/0ast

ustomerF&@

Customer/"irst

Customer/Street/Addr

Customer/City

Customer/State

Customer/1ip

Customer/Phone

Customer/Email

CARD/ACC$'#%

Aount/#o

Exp/Date

Card/%ype

AC%&2&%3

Ativity/&D

Ativity/Date

Ativity/Post/Date

Ativity/%ype

Ativity/Des4,erhant/#ame5

,erhant/State5

,erhant/Phone5

Charge/Des6

Ativity/Amount

olds

Nenerates

;otes:

1) ardF$ype refers to !tandard* Nold* 9latinum* orporate.%) ActivityF$ype refers to 9urchase or 9ayment.

) ActivityFDesc is modeled as a composite attribute so that we donJt forget to show the details of the &erchant contac t

information in an Activity instanc e in the database.


28/45

Alternative One: 15b

C'S%$,ER

Customer/&D

Customer/#ame

40ast5&@5 "irst6

Customer/Address

4Street5 City5 State5 1ip6

Customer/Phone

Customer/Email

ACC$'#%

Aount/#o

Exp/Date

Card/%ype

%RA#SAC%&$#

%xn/&D

%xn/Date

%xn/Post/Date

%xn/Des

Charge/Amount

8wns

@ncurs

#otes7

1) ardF$ype refers to !tandard* Nold* 9latinum* orporate.

%) !90;D@;NFA$0N82E provides ma"or grouping of A2DFA8>;$ transactions so

the >!$8&02 can now spending patterns by groups such as $2AG0$8* etc. 0ach !90;D@;NFA$0N82E includes at least one* and usually more than one* !>FA$0N82E.

!>FA$0N82@0! are unique to each !90;D@;NFA$0N82E.

() $#nDesc includes the +C character te#t description of each &erchantJs charge to the A2DFA8>;$.

Problem + Exerise ()b

Amerian Express

3ear.End Summary ERD . initial dra-t

SPE#D/S'9/CA%E8$R3

Sub/Category/&D

Sub/Category/#ame

SPE#D/CA%E8$R3

Spending/Category/&D

Spending/Category/#ame

@ncludes

Assigned

Alternative One: 15c

Do you find the same entities* attributes* and relationships in the two 02Ds you developed for

parts a and b /hat differences do you find in modeling the same data entities* attributes* and

relationships between the two 02Ds an you combine the two 02Ds into one 02D for which

the original two are subsets Do you encounter any issues in trying to combine the 02Ds!uggest some issues that might arise if two different data modelers had independently developed

the two data models.

Ees* the same entities of >!$8&02 and A8>;$ are in both sets of 02Ds= these

entities also appear to share the same attributes in each 02D. $he relationship between

>!$8&02 and A8>;$ in part a 02D is 8wns* while in part b 02D it is olds.$his would appear to be the same ind of relationship between entity instances in both

02Ds. Also* the $2A;!A$@8; entity in part b appears to be the same as A$@G@$E

in part a.


29/45

$here appear to be differences in the level of detail that is modeled in the A$@G@$E

entity with respect to the description of the activity charge when it is compared to the$2A;!A$@8; entityHs $#nDesc attribute. Additionally* the part b 02D shows

additional entities of !90;D@;NF!>FA$0N82E and !90;D@;NFA$0N82E

that are related to $2A;!A$@8;= these additional entities are not in evidence in thepart a 02D.

@t would appear that these two 02Ds can be combined into one 02D with minimalconfusion. owever* further clarification from the end user is necessary to determine the

meaning (semantics) of the ActivityF$ype attribute in part a 02D and the $#nFDesc

attribute in part b 02D. ,urther* some discussion is necessary to determine whether the

use of 6Activity7 or 6$ransaction7 terminology is preferred with the end users so properdecisions can be made about attribute naming conventions.

@f two data modelers had independently modeled these user views* it is possible that even

greater variance might be evidenced between the entity* attribute* and relationship names.@t is also possible that the data modeler woring on the &onthly !tatement user view

might not have been as specific in noting the composition of the ActivityFDesc attribute=thus* it would not be apparent that contact information related to the &erchant is part of

this data model.

Alternative One: 15d

ow might you use data naming and definition standards to overcome the issues you identified

in part c

;aming and definition standards could be used to develop common lasses Oe.g.*

@dentifier (@D)* ;umber (;o)* Date (Date)* Address (Addr)* $ransaction ($#n)*

Description (Desc)P and Kualifiers O9ost* $ransaction* ActivityP* as well as how attributenames will be noted (i.e.* AccountF;o vs. Account;o).


30/45

Alternative Two: 15a

,ERC:A#%

,erhant/&D

,erhant/#ame

,erhant/Addr


,erhant/Phone

RECE&P%

Reeipt/#o

Date

%ime

%ransation/%ype

CC/Charge/Amount

CC/Aount/#o

Card/%ype

Auth/Code

@ssues


Credit Card Reeipt ERD . -irst dra-t

#otes7

1) $ransactionF$ype refers to !ale or 2efund= a 200@9$ has only 1 $ransactionF$ype at a time.

%) $his 02D refers to a redit ard 2eceipt= revisions would be necessary to depict a cash transaction.

) ardF$ype refers to Gisa* &asterard* American 0#press* Discover* etc.


31/45

Alternative Two: 15b

ACC$'#%

Aount#oCredit0ine

CashAdv0imit

AtStatus

9illingCyleDays

9illingCyleDate

ExpDate

Current9alane

%RA#SAC%&$#

%xn&D

%xnDate

PostDate

%xn%ype

%xnAmount

%!#/CA%E8$R3

%xnCatCode

%xnCatDesription

C:8/%$/CA%E8$R3

Chg%oCatCode

Chg%oCatDesription

@ncurs

@sFAssigned

@sF9rovided

C'S%$,ER

Cust#o#ame 40ast5 &@5 "irst6

Address


Phone

ApprovalDate

8wns


,onthly Statement o- 2isa Credit Card Aount ERD . -irst dra-t

#otes7

1) $#n$ype refers to 9urchase* ash Advance* 9ayment* or Ad"ustment.

%) NF$8FA$0N82E refers to ,inance harge ategories (e.g.* !tandard9urchase or !tandardashAdv).

) $Q;FA$0N82E refers to !pending ategories (e.g.* &erchandise* !ervices* Auto 2ental* etc.).

+) Acct!tatus refers to Active* @nactive* losed* 8verdue.-) &erchant$#n$e#t refers to the te#t shown as part of the $#nDescription= if this value is ;>


32/45

Alternative Two: 15c

Do you find the same entities* attributes* and relationships in the two 02Ds you developed for

parts a and b /hat differences do you find in modeling the same data entities* attributes* and

relationships between the two 02Ds an you combine the two 02Ds into one 02D for whichthe original two are subsets Do you encounter any issues in trying to combine the 02Ds

!uggest some issues that might arise if two different data modelers had independently developed

the two data models.

Ees* when comparing the 02Ds in part a and part b* &02A;$ appears to be the

same entity in both data models. Additionally* since it is nown that the physical 2eceipt

document that was used to generate the part a 02D is actually one of the transactions thatis shown on the Gisa &onthly !tatement* there are common attributes between 200@9$

(part a) and $2A;!A$@8; (part b)* although different names have been used in the

data models. Additionally* the FAccountF;o from 200@9$ (in part a) is equivalentto the Account;o from A8>;$ (in part b).

$he two 02Ds could be combined into one 02D* however* there would need to bedecisions made about how the data that crosses organizational boundaries are maintained

in different organizationHs databases. ,or instance* the 2eceiptF;o on the &erchantHs

receipts for purchases at the &erchant are relevant to the &erchantHs internal accounting

records and may not be of use to the redit ard ompanyHs reporting to its accountcardholders.


33/45

Alternative Two: 15d

ow might you use data naming and definition standards to overcome the issues you identified

in part c

;aming and definition standards could be used to develop common lasses Oe.g.*

;umber (;o)* redit ard ()* Date (Date)* Address (Addr)* $ransaction ($#n)*Description (Desc)P and Kualifiers O9ost* $ransaction* Activity* illingycleP* as well as

how attribute names will be noted (i.e.* AccountF;o vs. Account;o).

Alternative Three: 15a

S%$RE

Store/#o

Store/#ame

Store/Addr 4Street5 City5 State5 1ip6

Store/Phone

RECE&P%

Reeipt/#o

Date

%ime

Register/#o

%ransation/%ype

Cashier

0ine/&tems/Subtotal

%otal/%ax

Purhase/%otal

CC/Charge/Amount

CC/Aount/#o

Card/%ype

Auth/Code

@ssues


Cash Register Credit Card Reeipt ERD . -irst dra-t

#otes7

1) $ransactionF$ype refers to !ale or 2efund= a 200@9$ has only 1 $ransactionF$ype at a time.%) $his 02D refers to a redit ard 2eceipt= revisions would be necessary to depict a cash transaction.

) ashier refers to the first name of the ashier and is assumed to be unique. An alternative design would be to use a ashierF;umber and provide a relationship to a A!@02 entity.+) ardF$ype refers to Gisa or &asterard.

-)


34/45

Alternative Three: 15b

ACC$'#%Aount#o

Credit0ine

CashAdv0imit

AtStatus

9illingCyleDays

9illingCyleDate

ExpDate

Current9alane

%RA#SAC%&$#

%xn&D

%xnDate

PostDate

%xn%ype

%xnAmount

%!#/CA%E8$R3

%xnCatCode

%xnCatDesription

C:8/%$/CA%E8$R3

Chg%oCatCode

Chg%oCatDesription

@ncurs

@sFAssigned

@sF9rovided

C'S%$,ERCust#o

#ame 40ast5 &@5 "irst6

Address


Phone

ApprovalDate

8wns


,onthly Statement o- 2isa Credit Card Aount ERD . -irst dra-t

#otes7

1) $#n$ype refers to 9urchase* ash Advance* 9ayment* or Ad"ustment.

%) NF$8FA$0N82E refers to ,inance harge ategories (e.g.* !tandard9urchase or !tandardashAdv).) $Q;FA$0N82E refers to !pending ategories (e.g.* &erchandise* !ervices* Auto 2ental* etc.).

+) Acct!tatus refers to Active* @nactive* losed* 8verdue.

-) &erchant$#n$e#t refers to the te#t shown as part of the $#nDescription= if this value is ;>


35/45

quantity of the item purchased* the price for each item purchased* as well as ta# and the

total charge to the credit card account. ,rom the !toreHs perspective* this data model

provides tracing of the ashier and 2egister related to the overall sales transaction* aswell as credit card processing information (e.g.* type of card* charge amount* card

account number* and authorization code)* and information related to management of the

!toreHs inventory (e.g.* item information and quantities).

$he &onthly !tatement of a Gisa redit ard Account 02D was developed from a user

view sent to the Account 8wner of the Gisa redit ard and reflects the entities andattributes present in the data on the sample document. $his data model serves both the

Account 8wner by providing details of all transactions posted against the redit ard

Account* and also the Gisa redit ard ompany by providing transaction charges for

both customers and merchants served.

/hen these two 02Ds are reviewed* it does not appear that any entities* attributes* or

relationships are named the same which seems to indicate that none of these are the same

between the two 02Ds. owever* since both the receipt and the monthly statement arefor my own purchases with a credit card* it is nown that some of the data underlying

both of these data models is the same* although different names have been used. ,orinstance* the monthly statement shows a listing of individual credit card receipts.

Although in this case* the individual receipt shows more detail that is shown on the

monthly statement* it can be seen that the underlying data is the same. $he !$820 entityin part a is actually equivalent to the &02A;$ entity in part b. $he

FhargeFAmount* Date (from 200@9$) in part a is the same as the $#nAmount*

$#nDate (from $2A;!A$@8;) in part b. ,inally* the FAccountF;o (from

200@9$) in part a is equivalent to the Account;o (from A8>;$) in part b.

Although it is technically feasible to combine these two 02Ds into one 02D* it would not

be advisable due to the difference in the level of detail captured (e.g.* !tore @nventory&anagement data in part a) in the two models and due to the different purposes (and

ultimate end users) of the data. ;aming standards would also have to be developed to

accomplish the merging of the data models. @f two data modelers had developed these02Ds* it is unliely that the common underlying data would have been identified.

Alternative Three: 15d

ow might you use data naming and definition standards to overcome the issues you identifiedin part c

;aming and definition standards could be used to develop common lasses Oe.g.*;umber (;o)* redit ard ()* Date (Date)* Address (Addr)* $ransaction ($#n)*

Description (Desc)P and Kualifiers O9ost* $ransaction* Activity* illingycleP* as well as

how attribute names will be noted (i.e.* AccountF;o vs. Account;o). owever* thesestandards would not address the level of detail and purpose issues identified earlier as

issues in merging the 02Ds.


36/45

1-.

1. 9ro"ects* @nc. 02D

;otes:

/e assume that a Gendor will be traced in our database even if they have not

participated in a uysF,rom relationship with a department* hence* the C:& cardinality

ne#t to Department in the diagram. $his permits the tracing of a Gendor in our database

prior to the first transaction with us. /e assume that we may set up a department in our company that may not yet have

employees assigned to it= thus* the C:& cardinality ne#t to 0mployee on the elongsF$o

relationship between 0mployee and Department.

lasses: ;umber (;o)* @dentifier (@D)* Date

Kualifiers: &arried* 8fFirth*


37/45

13.

14. .@. $opi !chool of usiness 02D


38/45

15. 9G, 02D


39/45

%C. 0merging 0lectric 02D

%1. !$>D0;$ and ADG@!82s 02D


40/45

%%. @n ,igure '%%* we have the following associative entities:

DoesFbusinessFin: between !A!$8&02Although this entity has no attributes and no independent meaning* it is the only way that

Gisio can represent the &:; relationship between !A!$8&02.

8rderF$ and 82D02

$his relationship has an attribute: 8rderedFKuantity that reflects the amount of product on

each line of the order by the customer. @t has independent meaning on the ustomerHs 8rder.

>ses: between 928D>$ and 2A/ &A$02@A

$his relationship has one attribute* NoesFintoFquantity. @t also may have independent

meaning* although there is no obvious independent identifier.

!upplies: between 2A/ &A$02@A

!ince there is an attribute on this entity and it can have independent meaning* it might be a

good candidate to convert to an associative entity.

9roducedFin: between /82I 0;$02 and 928D>$:Although this entity has no attributes and no independent meaning* it is the only way that

Gisio can represent the &:; relationship between /82IF0;$02 and 928D>$.

/orsFin: between /82I 0;$02 and 0&9


41/45

%.


42/45

%-.


43/45

%. a. $he address attributes of employee* customer* and vendor do not currently contain the street* city*or state.


44/45

%b. $here could be more than 1 product finish for a product* which could affect the price.


45/45

%c. Ees* this would be possible. ,or e#ample* a customer could have more than 1

address.

%3.

database management systems edition 9 chapter 3

Documents