Chapter 4

Logical Database Design and the Relational Model

TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Transforming (or mapping) EER diagrams into relations is a relatively straightforward
process with a well-defined set of rules. In fact, many CASE tools can automatically
perform many of the conversion steps. However, it is important that you understand the
steps in this process for four reasons:
• 1. CASE tools often cannot model more complex data relationships such as ternary
relationships and supertype/subtype relationships. In these situations, you may have to
perform the steps manually.
• 2. There are sometimes legitimate alternatives for which you will need to choose a
particular solution.
• 3. You must be prepared to perform a quality check on the results obtained with a CASE
tool.
• 4. Understanding the transformation process helps you understand why conceptual
data modeling is different from logical data modeling.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• 1. Regular entities are entities that have an independent existence
and generally represent real-world objects, such as persons and
products. Regular entity types are represented by rectangles with a
single line.
• 2. Weak entities are entities that cannot exist except with an
identifying relationship with an owner (regular) entity type. Weak
entities are identified by a rectangle with a double line.
• 3. Associative entities (also called gerunds) are formed from many-
to-many relationships between other entity types. Associative entities
are represented by a rectangle with rounded corners.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
• Each regular entity type in an E-R diagram is transformed into a
relation. The name given to the relation is generally the same as the
entity type.
• Each simple attribute of the entity type becomes an attribute of the
relation. The identifier of the entity type becomes the primary key of
the corresponding relation.
• Figure 4-8a shows a representation of the CUSTOMER entity type for
Pine Valley Furniture Company. The corresponding CUSTOMER
relation is shown in graphical form in Figure 4-8b.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
COMPOSITE ATTRIBUTES
• When a regular entity type has a composite attribute, only the simple
components of the composite attribute are included in the new
relation as its attributes.
• Figure 4-9 shows a variant of the example in Figure 4-8, where
Customer Address is represented as a composite attribute with
components Street, City, and State (see Figure 4-9a). This entity is
mapped to the CUSTOMER relation, which contains the simple
address attributes, as shown in Figure 4-9b.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
COMPOSITE ATTRIBUTES
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
MULTIVALUED ATTRIBUTES
• When the regular entity type contains a multivalued attribute, two new relations (rather than
one) are created. The first relation contains all of the attributes of the entity type except the
multivalued attribute.
• The second relation contains two attributes that form the primary key of the second relation.
The first of these attributes is the primary key from the first relation, which becomes a foreign
key in the second relation. The second is the multivalued attribute. The name of the second
relation should capture the meaning of the multivalued attribute.
• An example of this procedure is shown in Figure 4-10. This is the EMPLOYEE entity type for Pine
Valley Furniture Company. As shown in Figure 4-10a, EMPLOYEE has Skill as a multivalued
attribute. Figure 4-10b shows the two relations that are created. The first (called EMPLOYEE)
has the primary key EmployeeID. The second relation (called EMPLOYEE SKILL) has the two
attributes, EmployeeID and Skill, which form the primary key.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
MULTIVALUED ATTRIBUTES
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 2: Map Weak Entities
• Recall that a weak entity type does not have an independent existence but
exists only through an identifying relationship with another entity type called
the owner.
• A weak entity type does not have a complete identifier but must have an
attribute called partial identifier that permits distinguishing the various
occurrences of the weak entity for each owner entity instance.
• For each weak entity type, create a new relation and include all of the simple
attributes (or simple components of composite attributes) as attributes of this
relation. Then include the primary key of the identifyin grelation as a foreign
key attribute in this new relation.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 2: Map Weak Entities
• An example of this process is shown in Figure 4-11. Figure 4-11a shows the
weak entity type DEPENDENT and its identifying entity type EMPLOYEE, linked
by the identifying relationship Claims.
• Figure 4-11b shows the two relations that result from mapping this E-R
segment.
• An alternative approach is often used to simplify the primary key of the
DEPENDENT relation: Create a new attribute (called DependentID), which will
be used as a surrogate primary key in Figure 4-11b.
SURROGATE PRIMARY KEY
• A serial number or other system assigned primary key for a relation.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 2: Map Weak Entities
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 3: Map Binary relationships
• Map Binary One-to-Many Relationships
• For each binary 1:M relationship, first create a relation for each of the
two entity types participating in the relationship, using the procedure
described in Step 1.
• Next, include the primary key attribute (or attributes) of the entity on
the one-side of the relationship as a foreign key in the relation that is
on the many-side of the relationship.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 3: Map Binary relationships
• MAP BINARY ONE-TO-MANY RELATIONSHIPS
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 3: Map Binary relationships
• MAP BINARY MANY-TO-MANY RELATIONSHIPS
• Suppose that there is a binary many-to-many (M:N) relationship between two
entity types, A and B. For such a relationship, create a new relation, C.
• Include as foreign key attributes in C the primary key for each of the two
participating entity types. These attributes together become the primary key
of C. Any non key attributes that are associated with the M:N relationship are
included with the relation C.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 3: Map Binary relationships
• MAP BINARY MANY-TO-MANY RELATIONSHIPS