RELATIONAL DATABASE DESIGN Good Database Design Principles

1. no redundancy a field is stored in only one table, unless it happens to be a foreign key replication of foreign keys is permissible, because they allow two tables to be joined together 2. no bad dependencies in the dependency diagram of any relation in the database, the determinant should be the whole primary key, or a candidate key. Violations of this rule include: partial dependencies transitive dependencies normalization is the process of eliminating bad dependencies by splitting up tables and linking them with foreign keys normal forms are categories that classify how completely a table has been normalized there are six recognized normal forms (NF):
First Normal Form (1NF) Second Normal Form (2NF) Third Normal Form (3NF) Boyce-Codd Normal Form (BCNF) Fourth Normal Form (4NF) Fifth Normal Form (5NF)

Relational Database Design

13

RELATIONAL DATABASE DESIGN First Normal Form

a table is said to be in the first normal form (1NF) if all its attributes are atomic. Attributes that are not atomic go by the names Nested relations, nested tables, or sub-tables Repeating groups or repeating sections List-valued attributes example of a table that is not in first normal form:

Client ID 2173

Client Name
Barbara Hennessey

VetID 27

VetName PetVet

PetID 1 2 3 2 1 2 3

PetName PetType Sam Hoober Tom Charlie Beefer Kirby Kirby Bird Dog Hamster Cat Dog Cat Dog

4519 8005 8112

Vernon Noordsy Sandra Amidon Helen Wandzell

31 27 24

PetCare PetVet PetsRUs

CLIENT(ClientD, ClientName, VetID, VetName, PET(PetID, PetName, PetType) ) This kind of nested or hierarchical form is a very natural way for people to think about or view data. However, the relational database philosophy claims that it may not be a very good way for computers to store some kinds of data. Over the years, a lot of information systems have stored data in this kind of format but they were not relational databases

Relational Database Design

14

RELATIONAL DATABASE DESIGN

In order to eliminate the nested relation, pull out the nested relation and form a new table Be sure to include the old key in the new table so that you can connect the tables back together.
Client Name Vet Name

ClientID

VetID

CLIENT

ClientID

Pet Name PET

PetID

Pet Type

CLIENT(ClientD, ClientName, VetID, VetName) PET(ClientID, PetID, PetName, PetType) ClientID foreign key to CLIENT In this particular example, note that PetID is only unique within sets of pets with the same owner.
Relational Database Design 15

RELATIONAL DATABASE DESIGN Second Normal Form

Recall: a partial dependency occurs when You have a composite primary key A non-key attribute depends on part of the primary key, but not all of it A table in 1NF is said to be in the second normal form (2NF) if it does not contain any partial dependencies. Example of a partial dependency: ACTIVITY(StudentID, Activity, Fee) on pages 6, 7, and 9
StudentID Fee Activity

Our new CLIENT-PET database does not have any partial dependencies So, it already in second normal form But it still has a transitive dependency :
Client Name Vet Name

ClientID

VetID

Relational Database Design

16

RELATIONAL DATABASE DESIGN Third Normal Form

Recall: a transitive dependency happens when a non-key attribute depends on another non-key attribute, and that attribute could not have been used as an alternative primary key (or the same thing for a composition of several attributes). A table of 2NF is said to be in the third normal form (3NF) if it does not contain any transitive dependencies, In order to eliminate transitive dependency, we split the CLIENTS table again: CLIENTS(ClientID, ClientName, VetID) VetID foreign key to VET PETS(ClientID, PetID, PetName, PetType) ClientID foreign key to CLIENT VETS(VetID, VetName)
CLIENT Client Name

ClientID VET VetID VetID Vet Name

PET ClientID Pet Name

PetID

Pet Type

Relational Database Design

17

RELATIONAL DATABASE DESIGN Third Normal Form (Cont.)

CLIENTS-PETS-VETS database in third normal form:
Client ID 2173 4519 8005 8112 Client Name
Barbara Hennessey Vernon Noordsy Sandra Amidon Helen Wandzell
Client ID 2173 2173 2173 4519 8005 8005 8112 PetID 1 2 3 2 1 2 3 PetName Sam Hoober Tom Charlie Beefer Kirby Kirby PetType Bird Dog Hamster Cat Dog Cat Dog

VetID 27 31 27 24

VetID 27 31 24

VetName PetVet PetCare PetsRUs

with MS Access table relationships

the database consists of three types of entities, stored as distinct relations in separate tables: clients (CLIENTS) pets ( PETS) vets (VETS) there is no redundancy (only foreign keys are replicated) there are no partial and transitive dependencies
Relational Database Design 18

RELATIONAL DATABASE DESIGN Normal Forms and Normalization

The distinctions between third normal form (3NF), BoyceCodd normal form (BCNF), fourth normal form (4NF), and fifth normal form (5NF) are subtle. They have to do with overlapping sets of attributes that could be used as primary keys (composite candidate keys). For our purposes, its enough to know about 3NF. You need to be able to put a database in 3NF. That is more important than recognizing 1NF and 2NF Key factors to recognize 3NF: All attributes atomic gives you 1NF. Every determinant in every relationship is the whole primary key (or could have been chosen as an alternative primary key) guarantees no partial or transitive dependencies.

Redesigning a database so its in 3NF is called normalization.

Relational Database Design

19

RELATIONAL DATABASE DESIGN Example With Multiple Candidate Keys

DRIVER(License#, SocialSecurity#, Gender, BirthDate)
Gender Social Security# BirthDate

License#

The dependencies SocialSecurity# Gender and SocialSecurity# BirthDate are not considered transitive because we could have chosen SocialSecurity# as the primary key for the table. This kind of design will not give rise to anomalies.

Relational Database Design

20

RELATIONAL DATABASE DESIGN Normalization Example: Hardware Store Database

the ORDERS table :
Order Numb 10001 10001 10002 10002 10002 10002 10003 10004 10004 10005 Cust Code
5217 5217 5021 5021 5021 5021 4118 6002 6002 5021

Order Date 11/22/94 11/22/94 11/22/94 11/22/94 11/22/94 11/22/94 11/22/94 11/22/94 11/22/94 11/23/94

Cust Name Williams Williams Johnson Johnson Johnson Johnson Lorenzo Kopiusko Kopiusko Johnson

Prod Price Hammer $8.99 Screwdriver $4.45 Clipper $18.22 Screwdriver $4.45 Crowbar $11.07 Saw $14.99 Hammer $8.99 Saw $14.99 Screwdriver $4.45 Cordlessdrill $34.95

ProdDescr

Quantity 2 1 1 3 1 1 1 1 2 1

Note: in practice, we would also want to have product codes as well as descriptions, and use the product codes as keys to identify products. Here, well identify products by their ProdDescr to keep the number of fields down.

Relational Database Design

21

RELATIONAL DATABASE DESIGN Example: Hardware Store Database (Cont.)

ORDERS(OrderNum, ProdDescr, CustCode, OrderDate, CustName, ProdPrice, Quantity)

Conversion of the hardware store database to 2NF QUANTITY(OrderNum, ProdDescr, Quantity) OrderNum foreign key to ORDERS ProdDescr foreign key to PRODUCTS PRODUCTS(ProdDescr, ProdPrice) ORDERS(OrderNum, CustCode, OrderDate, CustName)
OrderNum Quantity ProdDescr ProdDescr ProdPrice

OrderNum

CustCode

Order Date

Cust Name

Transitive
Relational Database Design 22

RELATIONAL DATABASE DESIGN Example: Hardware Store Database (Cont.)

conversion of the ORDERS relation to 3NF QUANTITY(OrderNum, ProdDescr, Quantity) OrderNum foreign key to ORDERS ProdDescr foreign key to PRODUCTS PRODUCTS(ProdDescr, ProdPrice) ORDERS(OrderNum, CustCode, OrderDate) CustCode foreign key to CUSTOMERS CUSTOMERS(CustCode, CustName)
OrderNum Quantity ProdDescr ProdDescr ProdPrice

CustCode Cust Name

OrderNum Order Date

CustCode

Relational Database Design

23

RELATIONAL DATABASE DESIGN Example: Video Store Database

the CUSTOMER relation:
Customer Phone ID 1 502-666-7777 2 502-888-6464 3 4 5 .. 502-777-7575 502-333-9494 502-474-4746 . Last Name Johnson Smith Washington Adams Steinmetz First Name Martha Jack Elroy Samuel Susan Address 125 Main St. 873 Elm St. 95 Easy St. 746 Brown Dr. 15 Speedway Dr. City Alvaton Bowling Green Smiths Grove Alvation Portland .. State KY KY KY KY TN .. Zip Code 42122 42101 42171 42122 37148 ..

the RENTALFORM relation:

Trans ID 1 1 2 2 2 3 .. Rent Date 4/18/95 4/18/95 4/18/95 4/18/95 4/18/95 4/18/95 . Customer ID 3 3 7 7 7 8 Video ID 1 6 8 2 6 9 Copy# 2 3 1 1 1 1 Title 2001:SpaceOdyssey Clockwork Orange Hopscotch Apocalypse Now Clockwork Orange Luggage of the Gods .. Rent $1.50 $1.50 $1.50 $2.00 $1.50 $2.50 ..

a customer can rent multiple videos as part of the same transaction multiple copies of the same video exist the copy# field stores the number of the copy unique only with copies of that same video one customer cannot rent two copies of the same video at the same time although it has two tables, the database still contains some anomalies
Relational Database Design 24

RELATIONAL DATABASE DESIGN Example: Video Store Database (Cont.)

relations for the video store database CUSTOMER(CustomerID, Phone, Name, Address, City, State, ZipCode) RENTALFORM(TransID, RentDate, CustomerID, VideoID, Copy#, Title, Rent) dependency diagram for the video store database
Phone Name Address

Customer ID City State Zip

TransID

RentDate

Customer ID

Copy#

VideoID

Title

Rent

Relational Database Design

25

RELATIONAL DATABASE DESIGN Example: Video Store Database (Cont.)

video store database after eliminating partial and transitive dependencies CUSTOMER(CustomerID, Phone, Name, Address, City, State, ZipCode) RENTAL(TransID, RentDate, CustomerID) CustomerID foreign key to CUSTOMER VIDEO(VideoID, Title, Rent) VIDEOSRENTED(TransID, VideoID, Copy#) TransID foreign key to RENTAL VideoID foreign key to VIDEO
Phone Name Address

Customer ID City State Zip

TransID Copy# VideoID TransID

RentDate

Customer ID

VideoID

Title

Rent

Relational Database Design

26

RELATIONAL DATABASE DESIGN Example: Video Store Database (Cont.)

table relationships for the video store database

Relational Database Design

27

RELATIONAL DATABASE DESIGN Summary of Guidelines for Database Design

identify the entities involved in the database identify the fields relevant for each entity and define the corresponding relations determine the primary key of each relation avoid data redundancy, but have some common fields so that tables can be joined together ensure that all the required database processing can be done using the defined relations normalize the relations by splitting them into smaller ones

Relational Database Design

28