1. Mapping an ERD to a Relational Database
Entities
Each entity set is implemented with a separate relation.
Strong Entities
Strong, or regular, entities are mapped to their own relation.
The PK is chosen from the set of keys available.

2. Example: Strong Entitiesc d e

3. Rules for Mapping ERD onto Relational Schema
Entities
a. Each entity set is implemented with a separate relation.
Weak Entities
Weak entities are mapped to their own relation
If there are any identifying relationships, then the PK of the weak entity is the combination of the PKs of entities related through identifying relationships and the discriminator of the weak entity;
otherwise the PK of the relation is the PK of the weak entity.

4. Example: Weak Entitiesc d e x y B

5. Relationships
We’ll consider binary relationships only
All relationships involve the use of foreign keys: the PK attribute of one entity set is added as an attribute to the relation representing the other entity set
a.   Binary One-To-One
In general, with a one-to-one relationship, you have a choice regarding where to implement the relationship. You may choose to place a foreign key in one of the two relations, or in both.

6. Example: 1-1 A c d e x y B 1
c is a FK in B

7. Relationships
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.

8. Example: 1-n A c d e x y B 1 n
c is a FK placed on the “many” side of the relationship

9. Relationships
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.

10. Example: m-n A c d e x s AB B y
x and c are FKs, and together they form the PK of AB

11. Attributes
All attributes, with the exception of derived and composite attributes, must appear in relations.
Simple, atomic
These are included in the relation created for the pertinent entity set, many-to-many relationship, or n-ary relationship.

12. Example: Atomic Attributesd e

13. Attributes
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.

14. Example: Multi-valued AttributesAE c e c d c e A

15. Attributes
Composite
Composite attributes are not included. However the atomic attributes comprising the composite attribute must appear in the pertinent relation.

16. Example: Composite Attributesd e A n

17. Generalization/Specialization Hierarchies
can ignore this section

18. 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
NOT NULL constraint in the DDL, or
setting the ‘required’ property for the FK in MS Access ( should know how to do this).
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. ( can ignore this)

19. Setting the required
property to Yes

20. department employee N project dependent works for controls manages
name
number
location 1
fname
lname
works for
minit N
department
salary
address
name
sex 1
number of
employees
startdate 1
ssn
manages
controls
employee 1
bdate N
supervisor
hours N
degree
supervisee M
supervision 1
works on
project
dependents of
name
number
location N
dependent
relationship
name
sex
birthdate

21. Summary
Entities
a. Each entity set is implemented with a separate relation.
Weak Entities
Weak entities are mapped to their own relation
If there are any identifying relationships, then the PK of the weak entity is the combination of the PKs of entities related through identifying relationships and the discriminator of the weak entity;
otherwise the PK of the relation is the PK of the weak entity.

22. 2. All relationships involve foreign keys. If the relationship
is identifying then the primary key of the strong entity
must be propagated to the relation representing the weak
entity.
Binary One-To-One
In general, with a one-to-one relationship, you have
a choice regarding where to implement the
relationship. You may choose to place a foreign key
in one of the two relations, or in both.
b. Binary One-To-Many
With a one-to-many relationship you must place the
foreign key in the relation corresponding to the many
side of the relationship.

23. 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.
d. n-ary, n>2
new relation is generated for the n-ary relationship.
This new relation will have a composite primary key
comprising the primary keys of the participating entity
sets plus any discriminator attribute. If the cardinality
related for any entity set is 1, then the primary key of
that entity set is only included as a foreign key and not
as part of the primary key of the new relation.

24. 3. Attributes
Simple, atomic
These are included in the relation created for the
pertinent entity set, many-to-many relationship, or n-ary
relationship.
b. Multi-Valued
A multi-valued attribute is implemented using a new
relation. This relation will include the primary key of the
entity set. The primary key of the new relation will be
the primary key of the entity set and the multi-valued
attribute. Note that in this relation, the attribute is no
longer multi-valued.
c. Composite
Composite attributes must be replaced by their equivalent
atomic attributes in the pertinent relation.

25. 4. Generalization/Specialization Hierarchies
There are several options available for this case …
(ignore for )
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 (a NOT NULL constraint)
to ensure a foreign key has a value, and that it cannot be
null.
If the entity set is on the “one” side of a relationship, then
a check constraint or database trigger could be specified
to ensure compliance. (Ignore for )

26. DeptNumConsider the ERD:
Example 1:
DeptNumConsider the ERD:
DeptNum n 1
Employee
works in
Department
EmpNum
DeptName
EmpFname
EmpLname

27. Each entity is strong and all attributes are simple and atomic,
so by 1a) and 3a) we have an Employee and a Department
relation. Because of the 1-to-many relationship we must have
a foreign key on the many side of the works in relationship.
So, the Employee relation has a foreign key DeptNum. Our
relations are:
EmpNum
EmpFname
EmpLname
DeptNum
DeptNum
DeptName
The FK DeptNum needs a constraint to ensure it is never
Null.

28. Consider the star schema
Example 2:
Consider the star schema
Ssk
Store
StLocn 1
Dsk
Quarter n
Year
Product 1 n
Fact 1
Date n
Month
price
qty
Psk
Day
Week
ProdTitle

29. This diagram has three identifying 1-to-many relationships.
By applying the considerations in 1a), 1b), 2b), and 3a) above,
we have four relations: three for the dimension entity sets and
one for the fact entity set. The fact relation will have three
foreign keys referencing the dimension relations. The primary
key of the fact relation comprises three foreign keys.
Our relations are:
Store
Product
Ssk
StLocn
Psk
ProdTitle
Date
Dsk
Day
Week
Month
Quarter
Year
Fact
Ssk
Psk
Price
Qty

30. Reconsider the example above but replace the fact entity set
with a 3-ary (ternary) relationship:
Ssk
Store
StLocn
Dsk
Quarter n n
Year
Product
Fact
Date n
Month
price
qty
Psk
Day
Week
ProdTitle
Now, by applying 1a), 2d), and 3a), we end up with the
same physical database as Example 2.