CM20145CM20145Further DB Design –Further DB Design –NormalizationNormalization

Dr Alwyn BarryDr Joanna Bryson

Last TimeLast Time

Database design is an ongoing, iterative process. Requirements come from data, user

demands, design issues. Change occurs:

Corporations & technologies grow. Programmers & users learn.

Views / security. Lossless-join decomposition

Now: Science for improving design.

Design Process & NormalizationDesign Process & Normalization

We assume a 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 be the result of any ad hoc design of relations, which we then test & convert to normal form.

OverviewOverview

First Normal Form. Functional Dependencies. Second Normal Form. Third Normal Form. Boyce-Codd Normal Form. Fourth Normal Form. Fifth Normal Form. Domain Key / Normal Form. Design Process & Problems.

First Normal Form – 1NFFirst Normal Form – 1NF

You aren’t supposed to have more than one value per attribute of a tuple.

All tuples have the same number of attributes.

Necessary for a relational database.

Name Office Office Hours

Barry 2.23 1pm, 4pm

Bryson L2.27 11am, 5pmBAD

Getting Caught Out With 1NFGetting Caught Out With 1NF A domain is atomic if its elements are

considered to be indivisible units. Examples of non-atomic domains:

Set-valued attributes, composite attributes. Identifiers 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, encourage redundancy, Depend on interpretation built into

application programs.

Are You Atomic?Are You Atomic? Atomicity is not an intrinsic property of the

elements of the domain. Atomicity is a property of how the elements

of the domain are used. E.g. strings containing a possible delimiter (here:

a space) cities = “Melbourne Sydney” (non-

atomic: space separated list) surname = “Fortescue Smythe” (atomic:

compound surname) E.g. strings encoding two separate fields

bucs_login = cssjjb If the first two characters are extracted to find the

department, the domain bucs_login is not atomic. Leads to encoding of information in application program

rather than in the database.

Second Normal Form (2NF)Second Normal Form (2NF)

Violated when a nonkey column is a fact about part of the primary key.

A column is not fully functionally dependent on the full primary key. CUSTOMER-CREDIT in this case:

ORDER

ITEMID CUSTOMERID

QUANTITY

CUSTOMER-CREDIT

Desk JJB 25 OK

Chair AMB 3 POOR

ITEM

*itemid…

ORDER

quantity…

CUSTOMER

*customeridcustomer-credit

…

From Watson

BAD

FIX

Def: Def: Functional DependencyFunctional Dependency Let R be a relation schema

R and R The functional dependency (FD) holds on R (“ is

FD on ”) iff for any legal relations r(R): whenever any two tuples t1 and t2 of r agree on the

attributes they also agree on the attributes . i.e. (t1) = (t2) (t1) = (t2)

Example: Consider r(A,B) with the following instance of r:

A B does NOT hold, but B A does hold

A: Initials B: Chore

JJB Grading

AMB Setting Tutorials

JJB Writing Unit Reviews

Functional Dependencies: UsesFunctional Dependencies: Uses

Way to encode “business rules”. Specify constraints on the set of

legal relations. We say that F holds on R if all legal

relations on R satisfy the set of FDs F.

Test relations to see if they are legal under a given set of FDs. If a relation r is legal under a set F

of FDs, we say that r satisfies F.

Functional Dependencies Functional Dependencies

An FD is an assertion about a schema, not an instance.

If we only consider an instance or a few instances, we can’t tell if an FD holds. Inspecting only a few bird species (e.g.

crows, cardinals and canaries) we might conclude colour species.

However, this would be a bad FD as we would find out if we found some ravens.

Thus, identifying FDs is part of the data modelling process.

Trivial Functional DependenciesTrivial Functional Dependencies

An FD is trivial if it is satisfied by all instances of a relation E.g.

customer-name, loan-number customer-name

customer-name customer-name

In general, is trivial if

Permitting such FDs makes certain definitions and algorithms easier to state.

Functional Dependency Functional Dependency vsvs Key Key

FDs can express the same constraints we could express using keys:

Superkeys: K is a superkey for relation schema R if

and only if K R

Candidate keys: K is a candidate key for R if and only if

K R, and there is no K’ K such that K’ R

Of course, which candidate key becomes the primary key is arbitrary.

FDs FDs <><> Keys Keys

FDs can represent more information than keys can on their own.

Consider the following Loan-info-schema:Loan-info-schema = (customer-name, loan-number,

branch-name, amount).

We expect these FDs to hold:loan-number amountloan-number branch-name

We could try to express this by making loan-number the key, however the following FD does not hold:

loan-number customer-name Incidentally, this isn’t a very good table!

(¬2NF)

FD ClosureFD Closure Given a set F of FDs, other FDs are logically implied.

E.g. If A B and B C, we can infer that A C The set of all FDs implied by F is the closure of F, written F+ . Find F+ by applying Armstrong’s Axioms:

if , then (reflexivity) if , then (augmentation) if , and , then (transitivity)

Additional rules (derivable from Armstrong’s Axioms): If and holds, then holds (union) If holds, then holds and holds (decomposition) If holds and holds, then holds (pseudotransitivity)

Bad Decomposition ExampleBad Decomposition Example(From Last Time)(From Last Time)

A Non Lossless-Join Decomposition R = (A, B) R1 = (A), R2 = (B)

A B

121

A

B

12

rA(r)

B(r)

A (r) ⋈ B (r)

A B

1212

Thus, r is different to A (r) ⋈ B (r)

So A,B is not a lossless-join decomposition of R.

FDs & Lossless DecompositionFDs & Lossless Decomposition

All attributes of an original schema (R) must appear in the decomposition (R1, R2):

R = R1 R2

Lossless-join decomposition.For all possible relations r on schema R

r = R1 (r) ⋈ R2 (r) A decomposition of R into R1 and R2 is

lossless-join if and only if at least one of the following dependencies is in F+: R1 R2 R1

R1 R2 R2

Second Normal Form (2NF)Second Normal Form (2NF)

Violated when a nonkey column is a fact about part of the primary key.

A column is not fully functionally dependent on the full primary key. CUSTOMER-CREDIT in this case:

ORDER

ITEMID CUSTOMERID

QUANTITY

CUSTOMER-CREDIT

Desk JJB 25 OK

Chair AMB 3 POOR

ITEM

*itemid…

ORDER

quantity…

CUSTOMER

*customeridcustomer-credit

…

From Watson

BAD

FIX

Third Normal Form (3NF)Third Normal Form (3NF)

Violated when a nonkey column is a fact about another nonkey column.

A column is not fully functionally dependent on the primary key.

R is 3NF iff R is 2NF and has no transitive dependencies. EXCHANGE RATE violates this.

STOCK

*stock codefirm namestock price

stock quantitystock dividend

stock PE

NATION

*nation codenation name

exchange rate

STOCK

STOCK CODE

NATION EXCHANGE RATE

GOOG USA 0.67

NOK FIN 0.46BAD

FIX

Boyce-Codd (BCNF)Boyce-Codd (BCNF) Arises when a table:

has multiple candidate keys, the candidate keys are composite, the candidate keys overlap.

R is BCNF iff every determinant is a cand. key. E.g. Assume one consultant per problem per client, and

one problem per consultant. If client-problem is the primary key, how do you add a new

consultant? Like 3NF but now worry about all fields.

ADVISOR

CLIENT PROBLEM CONSULTANT

Alpha Marketing Gomez

Alpha Production

Raginiski

CLIENT

*clientno…

CLIENT-PROBLEM

*cltprobdate…

PROBLEM

*problemcode…

CONSULTANT

*consultid…

BAD

FIX

Design Goals & their discontentsDesign Goals & their discontents

Goals for a relational database design: eliminate redundancies by decomposing

relations, must be able to recover original data using

lossless joins, prefer not to loose dependencies.

BCNF: no redundancies, no guarantee of dependency preservation.

3NF: dependency preservation, but possible redundancies.

Fourth normal form (4NF)Fourth normal form (4NF)

A row should not contain two or more independent multivalued facts.

4NF iff BCNF & no non-trivial multi-valued dependencies.

Multivalued dependency means the value of one attributed determines a set of values for another.

STUDENT

STUDENTID

SPORT SUBJECT

…

50 Football

English …

50 Football

Music …

50 Tennis Botany …

50 Karate Botany …

BAD

FIX

Fifth normal form (5NF)Fifth normal form (5NF)

5NF iff a relation has no join dependency.

The schemas R1, R2,.., Rn have a join dependency over R if they define a lossless-join decomposition over R.

This is way too complicated, don’t worry about it.

Domain Key Normal FormDomain Key Normal Form

Every constraint on the relation must be a logical consequence of the domain constraints and the key constraints that apply to the relation. Key: unique identifier. Constraint: rule governing attribute

values. Domain: set of values of the same

data type. No known algorithm gives DK/NF.

E-R Model and NormalizationE-R Model and Normalization When an E-R diagram is carefully

designed, identifying all entities correctly, the tables generated should not need further normalization.

However, in a real (imperfect) design there can be FDs from non-key attributes of an entity to other attributes of the entity.

The keys identified in E-R diagrams might not be minimal - FDs can help us to identify minimal keys.

FDs from non-key attributes of a relationship set are possible, but rare.

Denormalization & PerformanceDenormalization & Performance May want to use non-normalized schema

for performance. E.g. displaying customer-name along with

account-number and balance requires join of account with depositor.

Alternative 1: Use denormalized relation containing attributes of account as well as depositor. 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

account ⋈ depositor as above, except less extra coding, errors.

Limits of NormalizationLimits of Normalization

Examples of bad database design, not caught by normalization.

Good: earnings(company-id, year, amount)

Bad: earnings-2000, earnings-2001, earnings-

2002, etc., on (company-id, earnings) all are BCNF, but querying across years difficult needs a new table each year

company-year(company-id, earnings-2000,earnings-2001, earnings-2002) in BCNF, but querying across years difficult requires new attribute each year

Summary 1 – Rules to WatchSummary 1 – Rules to Watch 1NF: attributes not atomic. 2NF: non-key attribute FD on part of

key. 3NF: one non-key attribute FD on

another. Boyce-Codd NF: overlapping but

otherwise independent candidate keys. 4NF: multiple, independent multi-valued

attributes. 5NF: join dependency. Domain Key / NF: all constraints either

domain or key

Summary 2 – ConceptsSummary 2 – Concepts

Functional Dependencies: Axioms & Closure.

Lossless-join decomposition. Design Process. Normalization Problems.

Next: Interfaces and Architectures

Reading & ExercisesReading & Exercises

Reading Connolly & Begg Chapter (13, 14) Silberschatz Chapters 7. Any other book, the

design/normalization chapter. Exercises:

Silberschatz7.1, 7.2, 7.16, 7.23, 7.24, 7.27-29

Next WeekNext Week

• Architectures and Implementations

• Integrity and Security

Slides after and including Slides after and including this one you are not this one you are not responsible for, but I am responsible for, but I am saving in case I decide to saving in case I decide to use them in the future.use them in the future.

Goal: Formalize “Good Design”Goal: Formalize “Good Design” Process:

Decide whether a particular relation R is in “good” form.

In the case that a relation R is not in “good” form, decompose it into a set of relations {R1, R2, ..., Rn} such that: each relation is in good form, the decomposition is a lossless-join

decomposition.

Theory: Constraints on the set of legal relations. Require that the value for a certain set of

attributes determines uniquely the value for another set of attributes – functional dependencies.