Relational Database Design II

transcript

Database Principles

Database Principles

Design Objective:

• Turn bad tables into good.– Create a set of tables; all about one thing

• Do so without loss of information– The new set of tables are related in such a way that

joining new tables recreates exactly the information found in the original tables

Database Principles

It is all about Information:

• How is information captured within a table?

• In the above table, a table about Suppliers, the “information” is that:– every supplier has a unique ID– every supplier has a unique name– every supplier has a unique location

Sno Sname Location

s1 Acme NYs2 Ajax Boss3 Apex Chis4 Ace LAs5 A-1 Phil

Supplier

Database Principles

Table Information and Enterprise Rules:

• The rules:– every supplier has a unique ID– every supplier has a unique name– every supplier has a unique location

are called Enterprise Rules (ER).• Enterprise Rules are rules that come from

– domain knowledge, – how the business or organization is run,– what the “experts” know about the business

Database Principles

Example:

• Instead of “every supplier has a unique location”:

• Suppose we are told that a supplier can have several locations:

Sno Sname Location

Supplier

pk = {Sno}

Sno Sname Location

s1 Acme NY,LAs2 Ajax Boss3 Apex Chi,Phil,SFs4 Ace LAs5 A-1 Phil

Supplier

This is not permitted:each row-column intersection should contain a single value

pk = {Sno}

Database Principles

Example (cont):

• Suppose we are told that a supplier can have several locations – a better solution:

• Point to be Made: Different Enterprise Rules result in different table configurations.

Sno Sname

s1 Acmes2 Ajaxs3 Apexs4 Aces5 A-1

Supplier Sno Location

s1 NYs1 LAs2 Boss3 Chis3 Phils3 SFs4 LAs5 Phil

SupplierLocation

pk = {Sno} pk = {Sno,Location}

Database Principles

How to Capture Enterprise Rules:

• A functional dependency (FD) is a functional relationship among attributes of a table, whose definition may vary over time.

• The difference between a mathematical function and a functional dependency is that the latter may have its definition change over time.

Function Definition: For every a Є A there is a uniqueb Є B such that f(a) = b.

a b = f(a)

Database Principles

Example of Functional Dependencies:

• Consider the following:

• Both name_of and location_of are functional dependencies but may not both be functions.

SNOs SNAMEsname_of

SNOs LOCATIONs

location_of

Enterprise Rules:

Every Supplier has a unique nameChange over Time: Not likely

Every Supplier has a unique LocationChange over Time: Possibly.

Database Principles

Functional Dependencies for Capturing Enterprise Rules

• Write down all the functional dependencies in the following table:

• If you capture the table information in FDs you have also captured the Enterprise Rules of the business.

borrowerid b_name b_addr b_status loan_limit

Cardholder

borrowerid b_nameborrowerid b_addrborrowerid b_statusborrowerid loan_limitb_status loan_limit

Database Principles

Many Enterprise Rules of a business are captured bythe Functional Dependencies found among the columns

of the tables that hold the data of the business.

As a database designer, if you capture the FDs of thevarious tables of the database you also

understand the rules by which the organization goes about its business.

Database Principles

Why we need FDs?

• Because we must never lose any information turning bad tables into good, we must know before we start what information we have.

• Relational Database Design starts with listing all FDs of all existing tables.

Database Principles

FD Notation:

• Suppose R = {A, B, C, D, E, F} is a table schema.

• Further suppose X ⊆ R and that there is a functional dependency from X to D. We write this:

A B C D E FR

Database Principles

Different Ways of Describing FDs:

• If R is a table and A, B ε R then the following are equivalent:

– A B

– B depends on A

– A determines B

– B is determined by A

– if your know (the value of) A then you know (the value of) B

Database Principles

Example:

• Consider the table:

• Claim:

• Alternatively:

• Justification:

StudentID SSN Fname Lname DOB Address

Student

StudentID DOB

if you know the value of the StudentID then you can determine exactly the DOB.

there is an Enterprise Rule that says “everyone has a unique DOB”

Database Principles

Example:

• What other FDs exist in this table:

StudentID SSN Fname Lname DOB Address

Student

StudentID DOB

StudentID SSNStudentID FNameStudentID LNameStudentID Address

SSN StudentIDSSN FNameSSN LNameSSN AddressSSN DOB

What about: StudentID, Address DOB

Where do all these FDs come from?

Answer: Enterprise Rules

Database Principles

How Does Knowing the FDs tell Us If A Table Is Good?

• Remember, a table is “good” if it is about one thing.

• A table is always “about” whatever its key identifies.

• Therefore, a table is good if it only includes info about its key.

• An FD with a table key on the left-hand-side, tells us info about the key and consequently keeps the table “good”.

• Other FDs are consequently “bad”.

Database Principles

Good FDs and Good Tables:

• Def’n: A functional dependency is good in a table if it is of the form

table key some attribute

Sno Sname Location

Supplier

Sno SnameSno Location

Hence the only FDs are “good”and consequently the table is also “good”.

pk = {Sno}

NOTE: The fact that in the current version of the table there are notwo suppliers with the same name does not mean that the world ofbusiness has an Enterprise Rule that says it must always be so. So we can’t say Sname Location

Database Principles

Something To Remember:

• The previous example points out an important fact.

We can’t be looking at current rows in the table, which reflect today’s reality, to decide what FDs exist or don’t exist. FDs reflect Enterprise Rules and FDs come from knowing about the business over the long term, not just what happens to hold true today.

Database Principles

Why is this a good thing?

• Because looking for FDs is a design-phase activity. We don’t need to have the tables already built.

• This means that we don’t need to build the tables only to find out later they are bad; we can avoid bad tables from the get-go.

Database Principles

What is Our Basic Job:

• To find out if a table is “good” we must first find all FDs in a table and decide which ones are “good” and which ones are not.

• In order to know which FDs are “good” we need to know all the keys of a table.

• Keys to a table are either super keys and have more columns than they need or as small as they can be, in which case are candidate keys.

• Super keys always contain a candidate key

• Basic Job: Find all candidate keys.

Database Principles

Reasoning Rule #1:

• Composition/Decomposition:

• The argument:– X A, B means X determines both A and B. This is

true either as a pair or individually so we can conclude

– if X A and X B then knowing X means you know both A and B; either individually or as a pair. Hence

X A, B is equivalent to X A and X B

X A, B implies X A and X B

X A and X B implies X A, B

Database Principles

Reasoning Rule #2:

• Identity:

• The argument:– If you know X then you know X.

Database Principles

Reasoning Rule #3:

• Transitivity:

• The argument:– If you know X then you know Y. – But if you know Y you know Z.– Hence if you know X you know Z.

• Note: This is nothing more than function composition applied to FDs.

If X Y and Y Z then X Z

if f : A B and g : B C then g f : A C

Database Principles

Reasoning Rule #4:

• Trivial:

• The argument:– This says that X determines the empty set. – In other words, if you know X there is nothing else you

need or want to know.

If X Ǿ

Database Principles

Reasoning Rule #5:

• Augmentation:

• The argument:– This says that if X determines Y then including extra

columns in X does not alter this.

If X Y then X, A Y

Database Principles

Reasoning Rule #6:

• Augmentation+:

• The argument:– This says that if X determines Y and A determines B,

then X together with A determine Y together with B.

If X Y and A B then X, A Y,B

Database Principles

The 6 Reasoning Rules for FDs:

• Composition/Decomposition:

• Identity:

• Transitivity:

• Trivial:

• Augmentation:

• Augmentation+:

If X Ǿ

If X Y then X, A Y

If X Y and A B then X, A Y,B

Database Principles

Be Careful:

• Notice, for example, that you can’t reason Augmentation backwards. You can’t say:

• A simple counter-example:

but neither

are true.

If X, A Y then X Y

CourseNumber, SectionNumber ProfessorName

SectionNumber ProfessorName

CourseNumber ProfessorName

Database Principles

Exercise:

• Consider the table:

• The following sentences describe the data in the table:

StudID CrsID SecID Semester StudName CrsDesc Grade Bldg RoomNum RoomCap TTSlot

sid cid sec sem sn desc gd bg rn cap tt

A student, sid, whose name is sn enrolls in section sec of course cid in semester sem. The course description is desc. The student gets a grade of gr. The course was held in room rn of the building bg. The capacity of the room is cap. The time table slot for the course was tt.

Database Principles

Exercise:

• To find FDs we need to focus on Enterprise Rules

StudID CrsID SecID Semester StudName CrsDesc Grade Bldg RoomNum RoomCap TTSlot

sid cid sec sem sn desc gd bg rn cap tt

StudID StudName

CrsID CrsDesc

Bldg, RoomNum RoomCap

CrsID, SecID, Semester TTSlot

CrsID, SecID, Semester Bldg

CrsID, SecID, Semester RoomNum

StudID, CrsID, SecID, Semester Grade

Bldg, RoomNum, TTSlot, Semester CrsID,SecID

CrsID, SecID, Semester RoomCap, TTSlot, Bldg

Reason: Composition + Transitivity

Database Principles

Exercise:

• Find the FDs in this table:

borrowerid b_name b_addr b_status loan_limit

Cardholder

borrowerid b_name, b_addr, b_status, loan_limit

b_status loan_limit

b_name, b_addr borrowerid (?)

NOTE: The last FD, if it is an FD, shows us an important fact; namely if X determines a key then X too is a key. Reason: If X is a key then X R. If Y X then by transitivity Y R and so is a key too.

Database Principles

Finding Candidate keys:

• In order to know if an FD is good or bad, and so know if it belongs in the table or not, we need to know if a given set of columns (the columns in the left hand side of the FD) is a key (contains a candidate key).

• To find all keys we must first find all candidate keys.• Every key contains a candidate key.

Database Principles

Relationship Between FDs and Keys

• Can we recognize a set of columns as being a key by looking at a FD?

• Recall that a key is a set of columns whose values uniquely determine the remaining values in a row.

• Another way of putting this is:

• X R characterizes a key.

if X is a key to R and r1 and r2 are rows of Rthen: r1[X] = r2[X] implies r1 = r2

if you know X you know everything (R)

Database Principles

Exercise:

• X is a key to R if and only if X (R \ X)

R = X (R \ X)If X is a key to R we know X Rby definition, soX X, (R \ X)From the Decomposition Rule we can say X X and X (R \ X)In other words,X (R \ X)

Now supposeX (R \ X)We already knowX Xby the Identity Rule.By the Composition Rule we can combine thelast two FDs.X X, (R \ X) = RSo X is a key.

X R \ X

Database Principles

Find Candidate Keys:

• Consider:

• Let’s assume that the FDs we know about are:– A, B C -- FD 1– D, E B -- FD 2– F D -- FD 3– B, E F -- FD 4– D A -- FD 5

A B C D E F

Database Principles

Find Candidate Keys (2):

A B C D E F

A, B C -- FD 1D, E B -- FD 2F D -- FD 3B, E F -- FD 4D A -- FD 5

We know we are looking for something like X R \ Xwhere we can’t make X any smaller. This meansan FD with all six columns, either on the left or the right hand side.

(i) D A -- FD5 (ii) D, B A, B -- (i), Identity(B), Aug+ (iii) D, B C -- (ii), FD1, Tran

(v) D, E B, D -- FD2, Identity(D), Aug+ (vi) D, E C -- (v), (iii),Tran

(viii) D, E B, E -- FD2, Iden(E), Aug+ (ix) D, E F -- (viii), FD4, Tran

(x) D, E A -- FD5, Aug (xi) D, E A, B, C, F -- (x), FD2, (vi), (ix), Comp

So {D, E} is a key since it determines all other columns. It is a candidate key if we can’t removeeither D or E. If we could then it should bepossible to prove either D Eor E Dusing only the original 5 FDs.

Clearly D E is impossible since nothing determines E (E is missing from all right-hand sides)

E D is also impossible. The best we can do is B, E F D

Database Principles

Finding Candidate Keys (3)

• Conclusion:

• Are there any other candidate keys? You must always ask and try to answer this question.

So can we solve the following query?

{D, E} is a candidate key to the table R.

Lemma: If X is a key to R and Y --> X then Y is a key to R

Proof: Y --> X and X --> R so Y --> R. Hence Y is a key to R.

? --> D, E

Database Principles

• Solve:

• So {F, E} is a key to R. It is a CK if it can't be made any smaller. Making it “smaller” means that:

• F --> E is impossible since once again, E does not appear on the right-hand-side of any original FD.

• B, E --> F is the best we can do.• {F, E} is another CK.

? --> D, E

F --> D -- FD 3

(xii) F,E --> D, E -- FD 3, Ident(E), Aug+

either F --> E or E --> F

Database Principles

• Solve:

• So {B, E} is a key to R. It is a CK if it can't be made any smaller. Making it “smaller” means that:

• B --> E is impossible since once again, E does not appear on the right-hand-side of any original FD.

• D, E --> B is the best we can do.• {B, E} is another CK.

? --> F, E

B,E --> F -- FD 4

(xii) B,E --> F, E -- FD 4, Aug

either B --> E or E --> B

Database Principles

Observations:

• The candidate keys are {B, E}, {D, E} and {F, E}.

• If an attribute (E in the last example) does not appear on the right-hand-side of any basic FD then it belongs to every candidate key.

Database Principles

Find Candidate Keys Exercise:

• Consider:

• Let’s assume that the FDs we know about are:– D C, A -- FD 1– B F -- FD 2– F C, E -- FD 3– B D -- FD 4

A B C D E F

Database Principles

Answer

• OBS: B belongs to every CK.

• The above shows {B} is a key. Since it is a singleton, it is a candidate key.

• Since every candidate key must contain {B} but can't actually be any larger than {B}, any other candidate key is also {B}.

• {B} is the only candidate key.

D C, A -- FD 1

B F -- FD 2

F C, E -- FD 3

B D -- FD 4 B --> F -- FD2 B --> D -- FD4(i) B --> C, A -- FD4, FD1, transitivity(ii) F --> E -- FD3, decomposition(iii) B --> E -- FD2, (iii), transitivity B --> A, C, D, E, F -- (i), FD4, (iii), FD2, composition

Database Principles

Find Candidate Keys Exercise:

• Consider:

• Let’s assume that the FDs we know about are:– B, E C -- FD 1– A, F B -- FD 2– C A, D -- FD 3– B E -- FD 4

A B C D E F

Database Principles

Answer

OBS: F belongs to every CK.

• The above shows {B,F} is a key. F can not be removed (it belongs to all CKs).

• In order to move B to the RHS we must leave A and F. But A is already moved so we need to leave C. But C is already moved so we must leave B.

• Hence in order to move B we must leave it where it is.• Hence {B,F} is a candidate key.

B, E C -- FD 1

A, F B -- FD 2

C A, D -- FD 3

B E -- FD 4

(i) B --> B, E -- FD4, ident(B), aug+(ii) B --> C -- (i), FD1, trans(iii) B --> A, D -- (ii), FD3, transitivity(iv) B --> A,C,D,E -- (i)-(iii), composition(v) B,F --> A,C,D,E -- (iv), aug

Database Principles

Answer (Additional Candidate Keys)

• {B,F} is a candidate key. • F belongs to every CK.

• Hence {A,F} is a key. It is a CK because– F can't be removed (see above)– A can't be removed since {F} is not a key

• {C, F} is a third CK.

B, E C -- FD 1

A, F B -- FD 2

C A, D -- FD 3

B E -- FD 4? --> B, F

(vi) A, F --> B -- FD2(vii) A, F --> B, F -- (vi), indent(F), aug+

C, F --> A, F -- FD3, decomp, indent(F), aug+

Database Principles

Finding Candidate keys:

• Observation: There is a candidate key excluding any attribute that appears on the right-hand-side of an FD.

Suppose X A and A is not in X then X, R \ {X,A} A by Augmentation Since all attributes of R appear in the above FD, the left hand side is a key andso by definition contains a candidate key.Since A does not appear on the left hand side

the CK does not contain A.

Relational Database Design II

Documents