Chapter 5:

Logical Database Design

and the Relational Model
Modern Database
Management
8th Edition
Jeffrey A. Hoffer, Mary B. Prescott,
Fred R. McFadden
Transforming EER Diagrams
into Relations (cont.)
Mapping Ternary (and n-ary)
Relationships
 One relation for each entity
and one for the associative
entity
 Associative entity has foreign

keys to each entity in the

relationship
 Figure 5-19 Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship with

associative entity
 Figure 5-19 Mapping a ternary relationship (cont.)

b) Mapping the ternary relationship PATIENT TREATMENT

Remember This is why But this makes a It would be

that the treatment date very better to create a
primary key and time are cumbersome surrogate key
MUST be included in the key… like Treatment#
unique composite
primary key
 Transforming EER
Diagrams into Relations
(cont.)
Mapping Supertype/Subtype Relationships
 One relation for supertype and for each

subtype
 Supertype attributes (including identifier

and subtype discriminator) go into

supertype relation
 Subtype attributes go into each subtype;

primary key of supertype relation also

becomes primary key of subtype relation
 1:1 relationship established between

supertype and each subtype, with

supertype as primary table
Figure 5-20 Supertype/subtype relationships
Figure 5-21
Mapping Supertype/subtype relationships to relations

These are implemented as one-to-one

relationships
 Normalization
 Normalization is a formal process for deciding which attributes should be
grouped together in a relation so that all anomalies are removed.
 Normalization is the process of successively reducing relations with
anomalies to produce smaller, well-structured relations. Following are
some of the main goals of normalization:

 1. Minimize data redundancy, thereby avoiding anomalies and conserving

storage space
 2. Simplify the enforcement of referential integrity constraints
 3. Make it easier to maintain data (insert, update, and delete)
 4. Provide a better design that is an improved representation of the real
world and a stronger basis for future growth
 Normalization
 Normalization places no constraints on
 How data should be displayed in queries.
 how data can or should be physically stored or, therefore, on processing
performance.
 Normalization is a logical data modeling technique used to ensure that
data are well structured from an organization-wide view.
 Steps in Normalization
 Normalization can be accomplished and understood in stages, each of
which corresponds to a normal form.
 A normal form is a state of a relation that requires that certain rules
regarding relationships between attributes (or functional dependencies)
are satisfied. We describe these rules briefly in this section.
 1. First normal form: Any multivalued attributes (also called repeating
groups) have been removed, so there is a single value (possibly null) at the
intersection of each row and column of the table.
 2. Second normal form: Any partial functional dependencies have been
removed (i.e., nonkey attributes are identified by the whole primary key).
 3.Third normal form: Any transitive dependencies have been removed
(i.e., nonkey attributes are identified by only the primary key).
 Data Normalization
 Primarily a tool to validate and
improve a logical design so that it
satisfies certain constraints that
avoid unnecessary
duplication of data
 The process of decomposing
relations with anomalies to
produce smaller, well-
structured relations
 Well-Structured Relations
 A relation that contains minimal data
redundancy and allows users to insert, delete,
and update rows without causing data
inconsistencies
 Goal is to avoid anomalies
 Insertion Anomaly–adding new rows forces user to
create duplicate data
 Deletion Anomaly–deleting rows may cause a loss
of data that would be needed for other future rows
 Modification Anomaly–changing data in a row
forces changes to other rows because of duplication
General rule of thumb: A table should not pertain to
more than one entity type
 Example–Figure 5-2b

Question–Is this a relation? Answer–Yes: Unique rows and no

multivalued attributes

Question–What’s the primary key? Answer–Composite: Emp_ID, Course_Title

 Anomalies in this Table
 Insertion–can’t enter a new employee
without having the employee take a class
 Deletion–if we remove employee 140, we
lose information about the existence of a Tax
Acc class
 Modification–giving a salary increase to
employee 100 forces us to update multiple
records
Why do these anomalies exist?
Because there are two themes (entity types) in this
one relation. This results in data duplication and an
unnecessary dependency between the entities