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.

Example: Strong Entities c d e

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.

Example: Weak Entities c d e x y B

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.

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

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.

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

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.

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

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.

Example: Atomic Attributes d e

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.

Example: Multi-valued Attributes AE c e c d c e A

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

Example: Composite Attributes d e A n

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

Setting the required property to Yes

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

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.

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.

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 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 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, 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 91.2914)

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

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.

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

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  

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.