8. MAPPING AN ERD TO A RELATIONAL DATABASE
All attributes, with the exception of derived and composite attributes, must appear in relations. In the following we consider attributes according to whether they are simple, atomic, multi-valued, derived, or composite.
- Simple, atomic
- These are included in the relation created for the pertinent entity type, many-to- many relationship, or n-ary relationship.
- Each multi-valued attribute is implemented using a new relation. This relation will include the primary key of the entity type. The primary key of the new relation will be the primary key of the entity type plus the multi-valued attribute. Note that in this new relation, the attribute is no longer multi-valued.
- Derived attributes are not included. However, a database designer could choose to include derived attributes if their presence would improve performance.
- Composite attributes: only attributes at the lowest levels of a composite hierarchy will appear in relations, according to whether they are simple/atomic, derived, or multivalued. Attributes above the lowest levels are not included in a relation.
The above constitutes the standard rules for mapping an ERD to relations. A designer may make other choices, but one expects there would be good reasons for doing so.