Download Relational Database

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Chapter 5: Transforming EER
Diagrams into Relations
Mapping Regular Entities to Relations
1. Simple attributes: E-R attributes map directly
onto the relation
2. Composite attributes: Use only their simple,
component attributes
3. Multi-valued Attribute - Becomes a separate
relation with a foreign key taken from the
superior entity
Chapter 5
© Prentice Hall, 2002
1
Figure 5-8: Mapping a regular entity
(a) CUSTOMER
entity type with
simple
attributes
(b) CUSTOMER relation
Chapter 5
© Prentice Hall, 2002
2
Figure 5-9: Mapping a composite attribute
(a) CUSTOMER
entity type with
composite
attribute
(b) CUSTOMER relation with address detail
Chapter 5
© Prentice Hall, 2002
3
Figure 5-10: Mapping a multivalued attribute
(a)
Multivalued attribute becomes a separate relation with foreign key
(b)
1 – to – many relationship between original entity and new relation
Chapter 5
© Prentice Hall, 2002
4
Transforming EER Diagrams
into Relations
Mapping Weak Entities
– Becomes a separate relation with a
foreign key taken from the superior entity
– Primary key composed of:
Partial identifier of weak entity
 Primary key of identifying relation (strong
entity)

Chapter 5
© Prentice Hall, 2002
5
Figure 5-11: Example of mapping a weak entity
(a) Weak entity DEPENDENT
Chapter 5
© Prentice Hall, 2002
6
Figure 5-11(b) Relations resulting from weak entity
NOTE: the domain constraint
for the foreign key should
NOT allow null value if
DEPENDENT is a weak
entity
Foreign key
Composite primary key
Chapter 5
© Prentice Hall, 2002
7
Transforming EER Diagrams
into Relations
Mapping Binary Relationships
– One-to-Many - Primary key on the one side
becomes a foreign key on the many side
– One-to-One - Primary key on the mandatory
side becomes a foreign key on the optional side
– Many-to-Many - Create a new relation with the
primary keys of the two entities as its primary
key
Chapter 5
© Prentice Hall, 2002
8
NULL Values in Foreign Keys

Whether or not a Foreign Key can have
NULL values depends on the minimum
cardinality of the concerned relationship
 Minimum cardinality of 0 represented as
NULL allowed for foreign key columns
 Minimum cardinality of 1 represented as
NULL disallowed for foreign key columns
Chapter 5
© Prentice Hall, 2002
9
Figure 5-12: Example of mapping a 1:M relationship
(a) Relationship between customers and orders
Note the mandatory one
Chapter 5
© Prentice Hall, 2002
10
Figure 5-12(b) Mapping the relationship
Again, no null value in the
foreign key…this is because
of the mandatory minimum
cardinality
Foreign key
Chapter 5
© Prentice Hall, 2002
11
Figure 5-14: Mapping a binary 1:1 relationship
(a) Binary 1:1 relationship
Chapter 5
© Prentice Hall, 2002
12
Figure 5-14(b) Resulting relations
Chapter 5
© Prentice Hall, 2002
13
Figure 5-13: Example of mapping an M:N relationship
(a) ER diagram (M:N)
The Supplies relationship will need to become a separate relation
Chapter 5
© Prentice Hall, 2002
14
Figure 5-13(b) Three resulting relations
Composite primary key
Foreign key
Foreign key
Chapter 5
© Prentice Hall, 2002
New
intersection
relation
15
Transforming EER Diagrams
into Relations
Mapping Associative Entities
– Identifier Not Assigned
 Default primary key for the association
relation is composed of the primary keys of
the two entities (as in M:N relationship)
– Identifier Assigned
 It is natural and familiar to end-users
 Default identifier may not be unique
Chapter 5
© Prentice Hall, 2002
16
Figure 5-15: Mapping an associative entity
(a) Associative entity
Chapter 5
© Prentice Hall, 2002
17
Figure 5-15(b) Three resulting relations
Chapter 5
© Prentice Hall, 2002
18
Transforming EER Diagrams
into Relations
Mapping Unary Relationships
– One-to-Many - Recursive foreign key in the
same relation
– Many-to-Many - Two relations:
 One for the entity type
 One for an associative relation in which the
primary key has two attributes, both taken
from the primary key of the entity
Chapter 5
© Prentice Hall, 2002
19
Figure 5-17: Mapping a unary 1:N relationship
(a) EMPLOYEE entity with
Manages relationship
(b) EMPLOYEE
relation with
recursive foreign
key
Chapter 5
© Prentice Hall, 2002
20
Figure 5-18: Mapping a unary M:N relationship
(a) Bill-of-materials
relationships (M:N)
(b) ITEM and
COMPONENT
relations
Chapter 5
© Prentice Hall, 2002
21
Transforming EER Diagrams
into Relations
Mapping Ternary (and n-ary)
Relationships
– One relation for each entity and one
for the associative entity
– Associative entity has foreign keys
to each entity in the relationship
Chapter 5
© Prentice Hall, 2002
22
Figure 5-19: Mapping a ternary relationship
(a) Ternary relationship with associative entity
Chapter 5
© Prentice Hall, 2002
23
Figure 5-19(b) Mapping the ternary relationship
Remember that the
primary key MUST be
unique
Chapter 5
© Prentice Hall, 2002
24
Transforming EER Diagrams
into Relations
Mapping Supertype/Subtype Relationships
– One relation for supertype and for each subtype
– Supertype attributes (including identifier and
subtype discriminator) go into supertype relation
– Subtype attributes go into each subtype; primary
key of supertype relation also becomes primary
key of subtype relation
– 1:1 relationship established between supertype
and each subtype, with supertype as primary
table
Chapter 5
© Prentice Hall, 2002
25
Figure 5-20: Supertype/subtype relationships
Chapter 5
© Prentice Hall, 2002
26
Figure 5-21:
Mapping Supertype/subtype relationships to relations
Chapter 5
© Prentice Hall, 2002
27
In-Class Exercise: Transform the
following ERD to a relational structure
FNAME
LNAME
SALARY
SSN
JOBCODE
EMP#
EMPLOYEE
MARRIED-TO
DIRECT
DIVISION
WORK-IN
BELONG-TO
DIVNAME
BLDG
MANAGE
DEPARTMENT
DIVNAME
DEPTNAME
DEPT#
Chapter 5
© Prentice Hall, 2002
28
Example Tables
EMPLOYEE
EMP#
SOCSEC
FNAME
LNAME
SEX
SPOUSE SALARY
JOBCODE
DIVNAME
DEPT#
E1
123-45-6789
JACK
SPRATT
M
E2
12,500
CLERK
FINANCE
D3
E2
987-65-4321
JANE
SPRATT
F
E1
55,000
SALES
MARKETING
D1
E3
NULL
DICK
BUTKUS
M
NULL
44,000
SALES
MARKETING
D2
E4
458-22-1513
SAM
SPADE
M
E5
12,800
NULL
LEGAL
D2
E5
321-47-1698
LAUREN
BACALL
F
E4
19,500
PROG
MARKETING
D1
DEPARTMENT
DIVNAME
DEPT#
DEPTNAME
MANAGER
FINANCE
D3
COMPTROLLER
E1
MARKETING
D1
NORTHEAST SALES
E3
MARKETING
D2
SOUTHWEST SALES
E9
RESEARCH
D3
PRODUCT TEST
NULL
LEGAL
D2
INVESTIGATION
E11
DIVISION
Chapter 5
DIVNAME
DIRECTOR
BUILDING
FINANCE
E8
102
MARKETING
E13
1000
RESEARCH
E9
87
LEGAL
E4
495
© Prentice Hall, 2002
29
Related documents