Chapter 8: Relational Database Design

Database System Concepts, 6th Ed.

Silberschatz, Korth and Sudarshan See www.db-book.com for conditions on re-use

Goals of Normalization

Let R be a relation scheme with a set F of functional dependencies. Decide whether a relation scheme R is in good form. In the case that a relation scheme R is not in good form, decompose it into a set of relation scheme {R1, R2, ..., Rn} such that Each relation scheme is in good form There is no loss of information Eliminate Redundancies Caused By: Fields Repeated Within A File Fields Not Directly Describing The Key Entity Fields Derived From Other Fields Avoid Anomalies In Updating (Adding, Editing, Deleting) Represent Accurately The Items Being Modeled Simplify Maintenance And Retrieval Of Info Preferably, the decomposition should be dependency preserving.

Database System Concepts - 6th Edition

8.2

Silberschatz, Korth and Sudarshan

Functional-Dependency Theory
A Functional Dependency is a relationship between or among

attributes such that the values of one attribute depend on or are determined by the values of the other attribute(s).
Partial Dependency is a relationship between attributes such that the

values of one attribute is dependent on, or determined by, the values of another attribute which is part of the composite key.
Partial dependencies are not good due to duplication of data and

update anomalies

Database System Concepts - 6th Edition

8.3

Silberschatz, Korth and Sudarshan

Example
If we know an ISBN, then we know the Book Title and the author(s)

ISBN Book Title ISBN Author(s) VIN Auto_Owner SID S_Name

If we know the VIN, then we know who is the Auto owner

If we know Student-ID (SID), then we can uniquely determine his/her Name

Database System Concepts - 6th Edition

8.4

Silberschatz, Korth and Sudarshan

Transitive Dependency
Is a relationship between attributes such that the values of one

attribute is dependent on, or determined by, the values of another attribute which is not a part of the key.
Exist when a nonkey attribute value is functionally dependent upon

another nonkey value in the record. For example:

EMPLOYEE_ID --> JOB_CATEGORY JOB_CATEGORY --> HOURLY_RATE

An employee data table that includes the hourly pay rate would

require searching every employee record to properly update an hourly rate for a particular job category.

Database System Concepts - 6th Edition

8.5

Silberschatz, Korth and Sudarshan

First Normal Form

Domain is atomic if its elements are considered to be indivisible units

Examples of non-atomic domains:

Set of names, composite attributes Identification numbers like CS101 that can be broken up into parts

A relational schema R is in first normal form if the domains of all

attributes of R are atomic

Non-atomic values complicate storage and encourage redundant

(repeated) storage of data

Example: Set of accounts stored with each customer, and set of owners stored with each account

Database System Concepts - 6th Edition

8.6

Silberschatz, Korth and Sudarshan

First Normal Form (Contd)

There are no duplicated rows in the table Each attribute is single-valued (i.e., there are no repeating groups or

arrays)
Entries in a column (attribute, field) are of the same kind Goal is the elimination of repeated groups of data by creating separate

tables of related data

Database System Concepts - 6th Edition

8.7

Silberschatz, Korth and Sudarshan

Instructor Table
ID 10101 12121 LastName Sutton Banks FirstName Ronald Myles DeptName Computer Science Finance Building Johnson Hall Lewis Building Salary 65000 90000

15151 22222
32343 45565 58554

Hill Young
Jones Allen Miller

Christopher Aaron
Jonathan Andrew Ayanna

Physics Music
Health Computer Science Music

Johnson Hall Performing Arts Center

Taylor Hall Johnson Hall Performing Arts Center

75000 95000
85000 72000 80000

Database System Concepts - 6th Edition

8.8

Silberschatz, Korth and Sudarshan

Second Normal Form

Must be in First Normal Form Elimination of redundant data It includes no partial dependencies; that is, no attribute is dependent

on only a portion of the primary key.

Database System Concepts - 6th Edition

8.9

Silberschatz, Korth and Sudarshan

Third Normal Form

Must be in Second Normal Form Eliminate all attributes from a table that are not directly dependent

upon the key

Must have a Primary key This is sufficient for most database applications

Database System Concepts - 6th Edition

8.10

Silberschatz, Korth and Sudarshan

Boyce-Codd Normal Form

Boyce Codd Normal Form (BCNF) is considered a special condition of

third Normal form.

A table is in BCNF if every determinant is a candidate key. A table can be in 3NF but not in BCNF. This occurs when a non key

attribute is a determinant of a key attribute.

Database System Concepts - 6th Edition

8.11

Silberschatz, Korth and Sudarshan

Fourth Normal Form

In a table containing a list of three things - college courses, the lecturer in charge of each course and the recommended book for each course - these three elements (course, lecturer and book) are independent of one another. Changing the courses recommended book, for instance, has no effect on the course itself. Multi-valued dependency : An item depends on more than one value. In this example, the course depends on both lecturer and book. 4NF states that a table should not have more than one of these dependencies. 4NF is rarely used outside of academic circles. Under fourth normal form, a record type should not contain two or more independent multivalued facts about an entity. In addition, the record must satisfy third normal form. Consider employees, skills, and languages, where an employee may have several skills and several languages. We have here two many-to-many relationships, one between employees and skills, and one between employees and languages. Under fourth normal form, these two relationships should not be represented in a single record such as EMPLOYEE | SKILL | LANGUAGE Instead, they should be represented in the two records EMPLOYEE | SKILL & EMPLOYEE | LANGUAGE |

Database System Concepts - 6th Edition

8.12

Silberschatz, Korth and Sudarshan

Design Goals
Enter the minimum data necessary Avoiding duplicate entry of information Minimum risks to data integrity

Database System Concepts - 6th Edition

8.13

Silberschatz, Korth and Sudarshan

Further Normal Forms

Join dependencies generalize multivalued dependencies

lead to project-join normal form (PJNF) (also called fifth normal form)

A class of even more general constraints, leads to a normal form

called domain-key normal form.

Problem with these generalized constraints: are hard to reason with,

and no set of sound and complete set of inference rules exists.

Hence rarely used

Database System Concepts - 6th Edition

8.14

Silberschatz, Korth and Sudarshan

Overall Database Design Process

We have assumed schema R is given

R could have been generated when converting E-R diagram to a set of tables. R could have been a single relation containing all attributes that are of interest (called universal relation). Normalization breaks R into smaller relations. R could have been the result of some ad hoc design of relations, which we then test/convert to normal form.

Database System Concepts - 6th Edition

8.15

Silberschatz, Korth and Sudarshan

ER Model and Normalization

When an E-R diagram is carefully designed, identifying all entities

correctly, the tables generated from the E-R diagram should not need further normalization.
However, in a real (imperfect) design, there can be functional

dependencies from non-key attributes of an entity to other attributes of the entity

Example: an employee entity with attributes department_name and building, and a functional dependency department_name building Good design would have made department an entity

Functional dependencies from non-key attributes of a relationship set

possible, but rare --- most relationships are binary

Database System Concepts - 6th Edition

8.16

Silberschatz, Korth and Sudarshan

Denormalization for Performance

Normalization is often difficult to sustain in the modern database

environment. The conflict between design efficiency, information requirements, and processing speed are often resolved through compromises that include denormalization. May want to use non-normalized schema for performance For example, displaying prereqs along with course_id, and title requires join of course with prereq
Alternative 1: Use denormalized relation containing attributes of course

as well as prereq with all above attributes faster lookup extra space and extra execution time for updates extra coding work for programmer and possibility of error in extra code Alternative 2: use a materialized view defined as course prereq Benefits and drawbacks same as above, except no extra coding work for programmer and avoids possible errors

Database System Concepts - 6th Edition

8.17

Silberschatz, Korth and Sudarshan

Other Design Issues

Some aspects of database design are not caught by normalization Examples of bad database design, to be avoided:

Instead of earnings (company_id, year, amount ), use

earnings_2004, earnings_2005, earnings_2006, etc., all on the schema (company_id, earnings).

Above are in BCNF, but make querying across years difficult and needs new table each year

company_year (company_id, earnings_2004, earnings_2005, earnings_2006)

Also in BCNF, but also makes querying across years difficult and requires new attribute each year.
Is an example of a crosstab, where values for one attribute become column names Used in spreadsheets, and in data analysis tools

Database System Concepts - 6th Edition

8.18

Silberschatz, Korth and Sudarshan

End of Chapter

Database System Concepts, 6th Ed.

Silberschatz, Korth and Sudarshan See www.db-book.com for conditions on re-use

Figure 8.02

Database System Concepts - 6th Edition

8.20

Silberschatz, Korth and Sudarshan

Figure 8.03

Database System Concepts - 6th Edition

8.21

Silberschatz, Korth and Sudarshan

Figure 8.04

Database System Concepts - 6th Edition

8.22

Silberschatz, Korth and Sudarshan

Figure 8.05

Database System Concepts - 6th Edition

8.23

Silberschatz, Korth and Sudarshan

Figure 8.06

Database System Concepts - 6th Edition

8.24

Silberschatz, Korth and Sudarshan

Figure 8.14

Database System Concepts - 6th Edition

8.25

Silberschatz, Korth and Sudarshan

Figure 8.15

Database System Concepts - 6th Edition

8.26

Silberschatz, Korth and Sudarshan

Figure 8.17

Database System Concepts - 6th Edition

8.27

Silberschatz, Korth and Sudarshan