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 c d e cde

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 c d e cxy B x y

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

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

A 1 1 Example: 1-1 A c d e c…X B x y X is a FK in A

A 1 1 If the participation constraint on an entity set is mandatory, we must choose the table for that entity set. A c d e c…X B x y 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 c d e xyc B B x y 1 n c is a FK placed on the “many” side of the relationship

Example: 1-n A c d e xy B c B x y 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 c d e xcs AB B x y 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 c d e cde

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 c d e cd A ce 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 c d e cde A A n

4.Generalization/Specialization Hierarchies 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 ( should know how to do this), or NOT NULL constraint in the DDL. N A c d B x y 1

cd A xyc B The “required” property for attribute c is 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

cd A xyc B A program should be produced to check that any value appearing in c-column in table A must appear at least once 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 departments 2.a department has a unique name, a unique number, and a specific employee is its’ manager 3.we track the start date for the manager function 4.a department may be in several locations 5.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 date 8.an employee is assigned to one department but may work on several projects which are not necessarily controlled by the same department 9.we track the number of hours per week that an employee works on each project 10.we keep track of the direct supervisor of each employee 11.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 lname minit fname sex address salary birthdatenamesex relationship name numberlocation name numberlocation employee department project dependent

With relationships: employee department project dependent works for manages works on dependents of controls supervision 1 N N 1 NM 1 N 1 1 N 1 supervisor supervisee partial constraint total constraint

employee department project dependent works for manages works on dependents of controls supervision bdate ssn name lname minit fname sex address salary birthdatenamesex relationship name numberlocation name number number of employees startdate hours N supervisor supervisee M N 1 1 N N degree 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 relationship is identifying then the primary key of the strong entity must be propagated to the relation representing the weak entity. 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. 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.

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.

3.Attributes a. 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.

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, 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 that “one” side will be chosen as the primary table and the other is chosen as the referenced table. A NOT NULL constraint for the foreign key should be specified.