Scribd
Upload
9 views

Database Lecture25

Uploaded by

shahidullah.se1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
9 views

Database Lecture25

Uploaded by

shahidullah.se1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 14

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

You might also like