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
7/27/2019 Database management Systems edition 9 Chapter 3
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
7/27/2019 Database management Systems edition 9 Chapter 3
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.
7/27/2019 Database management Systems edition 9 Chapter 3
4/45
,our types of cardinality constraints are:
a. 8ptional one:
b. &andatory one:
c. 8ptional many:
d. &andatory many:
11. 98;0 A
7/27/2019 Database management Systems edition 9 Chapter 3
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):
7/27/2019 Database management Systems edition 9 Chapter 3
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/27/2019 Database management Systems edition 9 Chapter 3
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
7/27/2019 Database management Systems edition 9 Chapter 3
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
7/27/2019 Database management Systems edition 9 Chapter 3
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
7/27/2019 Database management Systems edition 9 Chapter 3
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.
!
7/27/2019 Database management Systems edition 9 Chapter 3
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.
7/27/2019 Database management Systems edition 9 Chapter 3
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;.
7/27/2019 Database management Systems edition 9 Chapter 3
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:
7/27/2019 Database management Systems edition 9 Chapter 3
14/45
(-f continued) !ituation 1 ' Adding ourlyF2ate attribute: this could be added to the 8;!>
7/27/2019 Database management Systems edition 9 Chapter 3
15/45
-g.
7/27/2019 Database management Systems edition 9 Chapter 3
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.
7/27/2019 Database management Systems edition 9 Chapter 3
17/45
-i.
7/27/2019 Database management Systems edition 9 Chapter 3
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.
7/27/2019 Database management Systems edition 9 Chapter 3
19/45
4.
7/27/2019 Database management Systems edition 9 Chapter 3
20/45
4.
5. ;ote: attributes are omitted to save space in the @nstructorHs &anual.
a.
b.
c.
7/27/2019 Database management Systems edition 9 Chapter 3
21/45
d.
7/27/2019 Database management Systems edition 9 Chapter 3
22/45
e.
f.
7/27/2019 Database management Systems edition 9 Chapter 3
23/45
1C.
7/27/2019 Database management Systems edition 9 Chapter 3
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.
7/27/2019 Database management Systems edition 9 Chapter 3
25/45
11.
7/27/2019 Database management Systems edition 9 Chapter 3
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.
7/27/2019 Database management Systems edition 9 Chapter 3
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.
7/27/2019 Database management Systems edition 9 Chapter 3
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.
7/27/2019 Database management Systems edition 9 Chapter 3
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).
7/27/2019 Database management Systems edition 9 Chapter 3
30/45
Alternative Two: 15a
,ERC:A#%
,erhant/&D
,erhant/#ame
,erhant/Addr
4Street5 City5 State5 1ip6
,erhant/Phone
RECE&P%
Reeipt/#o
Date
%ime
%ransation/%ype
CC/Charge/Amount
CC/Aount/#o
Card/%ype
Auth/Code
@ssues
Problem + Exerise ()a
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.
7/27/2019 Database management Systems edition 9 Chapter 3
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
4Street5 City5 State5 1ip6
Phone
ApprovalDate
8wns
Problem + Exerise ()b
,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 ;>
7/27/2019 Database management Systems edition 9 Chapter 3
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.
7/27/2019 Database management Systems edition 9 Chapter 3
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
Problem + Exerise ()a
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.
-)
7/27/2019 Database management Systems edition 9 Chapter 3
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
4Street5 City5 State5 1ip6
Phone
ApprovalDate
8wns
Problem + Exerise ()b
,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 ;>
7/27/2019 Database management Systems edition 9 Chapter 3
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.
7/27/2019 Database management Systems edition 9 Chapter 3
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*
7/27/2019 Database management Systems edition 9 Chapter 3
37/45
13.
14. .@. $opi !chool of usiness 02D
7/27/2019 Database management Systems edition 9 Chapter 3
38/45
15. 9G, 02D
7/27/2019 Database management Systems edition 9 Chapter 3
39/45
%C. 0merging 0lectric 02D
%1. !$>D0;$ and ADG@!82s 02D
7/27/2019 Database management Systems edition 9 Chapter 3
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
7/27/2019 Database management Systems edition 9 Chapter 3
41/45
%.
7/27/2019 Database management Systems edition 9 Chapter 3
42/45
%-.
7/27/2019 Database management Systems edition 9 Chapter 3
43/45
%. a. $he address attributes of employee* customer* and vendor do not currently contain the street* city*or state.
7/27/2019 Database management Systems edition 9 Chapter 3
44/45
%b. $here could be more than 1 product finish for a product* which could affect the price.
7/27/2019 Database management Systems edition 9 Chapter 3
45/45
%c. Ees* this would be possible. ,or e#ample* a customer could have more than 1
address.
%3.
Top Related