Mapping an ERD to a Relational Database To map an ERD to a relational database, five rules are...
-
date post
19-Dec-2015 -
Category
Documents
-
view
237 -
download
0
Transcript of Mapping an ERD to a Relational Database To map an ERD to a relational database, five rules are...
Mapping an ERD to a Relational Database
To map an ERD to a relational database, five rules are defined to govern how tables are constructed.
1) Rule for entity types
2) Rule for relationships
3) Rule for attributes
4) Rule for generalization/specialization hierarchies
(will not be discussed in this course)
5) Rule for participation constraint
1. Entities
Each entity set is implemented with a separate relation.
a. Strong Entities
Strong, or regular, entities are mapped to their own relation.
The PK (Primary Key) is chosen from the set of keys available.
A
Example: Strong Entities
A
cd
e c d e
1. Entities
Each entity set is implemented with a separate relation.
b. Weak Entities
Weak entities are mapped to their own relation
The PK of the weak entity is the combination of the PKs of entities related through identifying relationships and the discriminator (partial key) of the weak entity.
B
Example: Weak Entities
A
cd
e
c x yB
xy
2. Relationships
We’ll consider binary relationships only
All relationships involve the use of foreign keys: the PKattribute of one entity set is added as an attribute to therelation representing the other entity set
a. Binary One-To-One
In general, with a one-to-one relationship, you have achoice regarding where to implement the relationship.You may choose to place a foreign key in one of the tworelations, or in both.
B
1
1
Example: 1-1
A
cd
e
x y cB
xy
c is a FK in B
A
1
1
Example: 1-1
A
cd
e
c … XB
xy
X is a FK in A
A1
1
If the participation constraint on an entity set is mandatory, we must choose the table for that entity set.
A
cd
e
c … XB
xy
X is a FK in B
2. Relationships
b. Binary One-To-Many
With a one-to-many relationship you must place a foreign key in the relation corresponding to the many side of the relationship.
Example: 1-n
A
cd
e
x y c
B
B
xy
1
n
c is a FK placed on the “many” side of the relationship
Example: 1-n
A
cd
e
x y
B
cB
xy
1
n
s is also involved in the table
s
s
2. Relationships
c. Binary Many-To-Many
A many-to-many relationship must be implemented with a separate relation for the relationship. This new relation will have a composite primary key comprising the primary keys of the participating entity sets plus any discriminator attribute.
Example: m-n
A
cd
e
x c s
AB
B
xy
m
n
x and c are FKs, and together they form the PK of AB
s
3. Attributes
All attributes, with the exception of derived and composite attributes, must appear in relations.
a. Simple, atomic
These are included in the relation created for the pertinent entity set, many-to-many relationship, or n-ary relationship.
A
Example: Atomic Attributes
A
cd
e c d e
3. Attributes
b. Multi-valued
Each multi-valued attribute is implemented using a new relation. This relation will include the primary key of the original entity set. The primary key of the new relation will be the primary key of the original entity set and the multi-valued attribute. Note that in this new relation, the attribute is no longer multi-valued.
Example: Multi-valued Attributes
A
cd
e c d
A
c e
AE
e is a multi-valued attribute.
3. Attributes
c. Composite
Composite attributes are not included. However the atomic attributes comprising the composite attribute must appear in the pertinent relation.
Example: Composite Attributes
cd e
c d e
A
A
n
4. Generalization/Specialization Hierarchies
91.2914 can ignore this section
5. Participation constraints
If a relationship is mandatory for an entity set, then
if the entity set is on the “many” side of the relationship, then a specification is required to ensure a foreign key has a value, and that it cannot be null
•setting the ‘required’ property for the FK in MS Access (91.2914 should know how to do this), or
•NOT NULL constraint in the DDL.
N
A
c d
B
x y
1
c d
A
x y c
B
The “required” property for attribute cis set “yes”.
Setting the required property to Yes
5. Participation constraints
Otherwise, if the entity set is on the “one” side of a relationship, then a check constraint or database trigger can be specified to ensure compliance.
N
A
c d
B
x y
1
c d
A
x y c
B
A program should be produced to check that any valueappearing in c-column in table A must appear at leastonce in c-column in table B.
Example
The company database keeps track of a company’s employees, departments, and projects:
Requirements:
concerning the department:1. company is organized into departments2. a department has a unique name, a unique number, and a specific
employee is its’ manager3. we track the start date for the manager function4. a department may be in several locations5. a department controls a number of projects
concerning the project:6. a project has a unique name, a unique number, and is in a single
location
example continued
concerning the employee:7. each employee has a name, social insurance number,
address, salary, sex, and birth date8. an employee is assigned to one department but may work on several
projects which are not necessarily controlled by the same department9. we track the number of hours per week that an employee works on
each project10. we keep track of the direct supervisor of each employee11. we track the dependents of each employee (for insurance purposes)
concerning the dependent:12. we record each dependent’s first name, sex, birth date,
and relationship to the employee
The entities:
employee
department
project
dependent
The entities:
bdate
ssn
name
lnameminitfname
sex address salary
birthdatename sex relationship
name number location
name number location
employee
department
project
dependent
With relationships:
employee
department
project
dependent
works for
manages
works on
dependents of
controls
supervision 1
N
N
1N M
1
N
1
1
N
1
supervisorsupervisee
partial constrainttotal constraint
employee
department
project
dependent
works for
manages
works on
dependents of
controls
supervision
bdate
ssn
name
lnameminitfname
sex address salary
birthdatename sex relationship
name number location
name number
number ofemployeesstartdate
hours
1
1
1
N
supervisorsupervisee
M
N
11
NNdegree
location
Summary
1.Entities
a. Each entity set is implemented with a separate relation.
b.Weak Entities
Weak entities are mapped to their own relation
The PK of the weak entity is the combination of the PKs of entities related through identifying relationships and the discriminator (partial key) of the weak entity;
2. All relationships involve foreign keys. If the relationshipis identifying then the primary key of the strong entitymust be propagated to the relation representing the weakentity.a. Binary One-To-One
In general, with a one-to-one relationship, you havea choice regarding where to implement therelationship. You may choose to place a foreign keyin one of the two relations, or in both.
b. Binary One-To-Many With a one-to-many relationship you must place theforeign key in the relation corresponding to the manyside of the relationship.
c. Binary Many-To-Many A many-to-many relationship must be implemented witha separate relation for the relationship. This new relationwill have a composite primary key comprising theprimary keys of the participating entity sets plus anydiscriminator attribute.
d. n-ary, n>2 new relation is generated for the n-ary relationship.This new relation will have a composite primary keycomprising the primary keys of the participating entitysets plus any discriminator attribute. If the cardinalityrelated for any entity set is 1, then the primary key ofthat entity set is only included as a foreign key and notas part of the primary key of the new relation.
3. Attributesa. Simple, atomicThese are included in the relation created for thepertinent entity set, many-to-many relationship, or n-aryrelationship.b. Multi-Valued A multi-valued attribute is implemented using a newrelation. This relation will include the primary key of theentity set. The primary key of the new relation will bethe primary key of the entity set and the multi-valuedattribute. Note that in this relation, the attribute is nolonger multi-valued.c. CompositeComposite attributes must be replaced by their equivalentatomic attributes in the pertinent relation.
4. Generalization/Specialization HierarchiesThere are several options available for this case …(ignore for 91.2914)
5. Participation constraints.
If a relationship is mandatory for an entity set, then if the entity set is on the “many” side of the relationship,a specification is required (a NOT NULL constraint)to ensure a foreign key has a value, and that it cannot benull.
If the entity set is on the “one” side of a relationship, thenthat “one” side will be chosen as the primary table andthe other is chosen as the referenced table. A NOT NULLconstraint for the foreign key should be specified.