Basics of the Relational Model How to convert E-R model to Relational Model Functional Dependencies Multivalued Dependencies Normal Forms

跳转到第一页

Basics of Relational Model

Table = relation Column headers = attributes Row = tuple Relational schema = name(relation+attributes)+other structure info., e.g., keys and other constraints. Relation instance is current set of rows for a relation schema. Database schema = collection of relation schemas. 跳转到第一页

Relational Model (cont.) A1 A2 A3 …. An

attributes

a1 a2 a3 b1 b2 b3

tuple

n: Number of attributes

an bn

component

Set of attributes names: schema REL(A1,A2,…An) 跳转到第一页

Relational Model (cont.) Domains:corresponding with attributes. N A T N1 A1 T1 N2 A2 T2 N3 A3 A4 Domain A5 Cardinality of domain N:3 A:5 T:2 跳转到第一页

Why relations? Very simple model. Often a good match for the way we think about our data. Abstract model that underlies SQL, the most important language in DBMS’s today Name Manf. Winterblue Peters Budlit A.B.

Relation instance

跳转到第一页

About Relational Model

Order of tuples not important, order of attributes not important (in theory) Collection of relation schemas: relational database schema (intension) Corresponding relation instances: Relational database (extension) Intension vs. extension (内含与外延) Schema vs. data Metadata: includes schema 跳转到第一页

Relational Design Simplest approach (not always best): convert each E.S. to a relation and each relationship to a relation. Entity Set Æ Relation E.S.attributes Ærelational attributes name

Manf. Beers

Becomes: Beers (name, manf.)

跳转到第一页

E/R Relationships Æ Relations Relation has attribute for key attributes of each E.S. that participates in the relationship. Add any attributes that belong to the relationship itself. Renaming attributes OK, essential if multiple roles for an E.S. For example, Sells (bar_name, Beer_name, price) price Bar name

sells

Beer name 跳转到第一页

Keys in Relations An attribute or set of attributes K is a key for a relation R if we expect that in no instance of R will two different tuples agree on all the attributes of K Indicate a key by underlining the key attributes. Example: if name is key for Beers Beers( name, manf.) 跳转到第一页

addr

name

name Drinkers

Likes

1 2 Buddies husband

Beers

Favorite wife

married

Manf.

Likes(drinker, beer) Favorite(drinker, beer) Buddies(name1, name2) Married(Husband, wife) 跳转到第一页

Combining Relations Sometimes it makes sense to combine relations. Common case: Relation for an E.S. E plus the relation for some manyone relationship from E to another E.S. Example:combine Drinker(name,addr) with Favorite(drinker, beer) to get Drinker1(name, addr, favBeer). 跳转到第一页

Continue.

Danger in pushing this idea too far: redundancy. E.g.combining Drinker with Likes causes the drinker’s address to be repeated. Notice the difference: Favorite is many-one, Likes is many-many.

跳转到第一页

Weak Entity Sets, relationships Æ relations

Relation for a weak E.S. must include its full key(i.e., attributes of related entity sets) as well as its own attributes. A supporting relationship(doublediamond) yields a relation that is actually redundant and should be deleted from the database schema.

跳转到第一页

Example name

Logins

name @

Host

Hosts(hostName) Logins(LoginName, hostName) At(LoginName, hostName,hostName2) In At, hostName and hostName2 must be the same host,so delete one of them. Then, Logins and At become the same relation; delete one of them. 跳转到第一页

Subclasses Æ Relations Three approaches: 1. Object-oriented:each entity is in one class. Create a relation for each class, with all the attributes for that class, do not forget inherited attributes. 2. E/R style: an entity is in a network of classes related by isa. Create one relation for each E.S. An entity is represented in the relation for each subclass to which it belongs. Relation has only the attributes attached to that E.S. + key at the root

跳转到第一页

Subclasses Æ Relations(cont.) 3. Use nulls. Create one relation for the root class or root E.S., with all attributes found anywhere in its network of subclasses. Put NULL in attributes not relevant to a given entity.

跳转到第一页

Example:

OO-Style

name

Name

manf.

Bud

A.B.

Ales Manf.

SummerBlue Peter’s

Manf.

isa

Beers

Name

beers

color

color dark

Ales

跳转到第一页

E/R Style: Name

manf.

Bud

A.B.

Name

color

SummerBlue dark

SummerBlue Peter’s Beers

Ales

Using Nulls: Name

Manf.

Color

Bud

A.B.

Null

SummerBlue Peter’s

Beers

dark 跳转到第一页

Comparison of three ways

•

•

•

Speed, fewer relations, less space and avoid repeating information: Efficient for nulls approach: all attributes are in one relation Object-oriented offers the minimum possible space usage: one tuple per entity; the E/R method has several tuples for each entity, but only the key attributes are repeated.

跳转到第一页

Classroom Exercises 3.2.1, 3.3.1 Answer to 3.2.1: Customers(ssNo, name, address, phone) Flights(number, day, aircraft) Bookings(ssNo, number, day, row, seat) Answer to 3.3.1 a) Depts(name, chair) Courses(number, deptName, room) LabCourses(number, deptName, allocation) b) Depts(name, chair) Courses(number, deptName, room) LabCourses(number, deptName, room, allocation) c) Depts(name, chair) Courses(number, deptName, room, allocation) 跳转到第一页

Functional Dependency

Exist in a relational schema as a constraint. Agree for all instances of the schema (t and u are any two tuples) A’s

B’s

t u If t and Then they u agree must agree here here

We have functional dependency like this A1A2…ÆB1B2…

跳转到第一页

Convention: …, X, Y, Z represent sets of attributes; A, B, C,… represent single attributes. Convention: no set formers in sets of attributes, just ABC, rather than {A,B,C }.

Functional Dependencies XÆ A = assertion about a relation R that whenever two tuples agree on all the attributes of X, then they must also agree on attribute A. Example: Drinkers(name, addr, beersLiked, manf, favoriteBeer) Reasonable FD’s to assert: Name Æ addr beersLiked Æ manf Name Æ favoriteBeer 跳转到第一页

Example Data name Janeway Janeway Spock

addr Voyager Voyager Enterprise

Because name -> addr

beersLiked Bud WickedAle Bud

manf A.B. Pete’s A.B.

favBeer WickedAle WickedAle Bud

Because name -> favBeer

Because beersLiked -> manf

跳转到第一页

Functional Dependencies (cont.)

Shorthand: combine FD’s with common left side by concatenating their right sides. Name Æ addr, favoriteBeer Sometimes, several attributes jointly determine another attribute, although neither does by itself. Example: beer bar Æ price 跳转到第一页

Functional Dependencies (cont.) A1A2…An Æ B1B2….Bm Trivial if the B’s are a subset of the A’s Nontrivial if at least one of the B’s is not among the A’s Completely nontrivial if none of the B’s is also one of the A’s

跳转到第一页

Examples

Trivial FD

sno,sname → sname

Nontrivial FD

sno,sname → sname,sdept

Completely nontrivial FD

sno,cno → grade

跳转到第一页

Keys of Relations K is a key for relation R if: 1. K Æ all attributes of R (uniqueness) 2. For no proper subset of K is (1) true.(minimality) 3. If k at least satisfies (1), then K is a superkey. Conventions: Pick one key; underline key attributes in the relation schema.It is Primary key X,etc.,represent sets of attributes; A etc., represent single attributes. No set formers in FD’s, e.g., ABC instead of {A,B,C} 跳转到第一页

Example Drinkers (name, addr, beersLiked, manf, favoriteBeer) {name, beersLiked} FD’s all attributes, as seen. Name Æ beersLiked is false, beersLiked Æ name also false No other keys in this example. Important point: “key”in a relation refers to tuples, not the entities they represent. 跳转到第一页

Example Data name Janeway Janeway Spock

addr Voyager Voyager Enterprise

Keys in E/R concern entities. Keys in relations concern tuples. in poor relational designs, E/R keys and Relational keys are different.

beersLiked Bud WickedAle Bud

manf A.B. Pete’s A.B.

favBeer WickedAle WickedAle Bud

Relational key = {name beersLiked} But in E/R, name is a key for Drinkers, and beersLiked is a key for Beers. Note: 2 tuples for Janeway entity and 2 tuples for Bud entity.

跳转到第一页

Example Lastname Firstname StudentID major key(2 attributes)

key

superkey Note; there are alternate keys

跳转到第一页

Who determines the keys/FD’s ?

We could assert a key K, then the only FD’s asserted are that K Æ A for every attribute A. Or, we could assert some FD’s and deduce one or more keys by the formal definition. E/R diagram implies FD’s by key declarations and many-one relationship declarations.

跳转到第一页

Who determines the keys/FD’s ? (cont.) Rule of thumb: FD’s either come from Keyness, many-1 relationship, or from physics. Example: “no two courses can meet in the same room at the same time”yields room time Æ course

More FD’s From “Physics”

跳转到第一页

Functional Dependencies and many-one relationships Consider R(A1,…An) and X is a key then XÆY for any attributes Y in A1..An . Suppose R is used to represent a manyÆone relationship E1 entity set (x) Æ E2 entity set(y) Then, XÆY holds, and Y Æ X doesn’t hold unless the relationship is one-to-one What about many-to-many relationship ?

跳转到第一页

Inferring FD’s Given FD’s X1 Æ A1, X2 Æ A2… Xn Æ An, does FD YÆ B necessarily hold in the same relation ? When we talk about improving relational designs, we often need to ask “does this FD hold in this relation ?” Start by assuming two tuples agree in Y. Use given FD’s to infer other attributes on which they must agree. If B is among them, then yes, else no. Y 0000000. . . 0 Three ways: 00000?? . . . ? •A simple test for it • use FD to deduce •Calculate Closure of y

跳转到第一页

Armstrong’s axioms Reflexivity: If {B1B2…Bm} ⊆ {A1,A2,…An} then A1,A2,…An Æ B1B2…Bm called trivial FD’s Augmentation: If A1,A2,…An Æ B1B2…Bm then, A1,A2,…An C1,C2..Ck Æ B1B2…Bm C1,C2..Ck Transitivity: If A1,A2,…An Æ B1B2…Bm,and B1B2…Bm Æ C1,C2..Ck then, A1,A2,…An Æ C1,C2..Ck

跳转到第一页

The Closure of attributes Define Y+=closure of Y = set of attributes functionally determined by Y. Y+={A,B,C,Y} that means, there exists FDs like: YÆA, YÆB, YÆC, YÆY (obvious) Generally,{A1A2…AN}+ is the closure of attribute set {A1A2…AN}

跳转到第一页

Algorithm: how to compute the closure

New Y+

A

Y+ X

Basis: Y+:=Y Induction: If X ⊆Y+, and X Æ A is a given FD, then add A to Y+. End when Y+ can not be changed.

跳转到第一页

Example The process to compute AC+:

Given FD: A Æ B, BC Æ D + A = AB + Because AÆB, add B to AC + = C C Because BCÆD, add D to AC+ + (AC) = ABCD AC+=AC

No more attributes

A C

B D 跳转到第一页

Given Versus Implied FD’s Typically, we state a few FD’s that are known to hold for a relation R Other FD’s may follow logically from the given FD’s; these are implied FD’s. We are free to choose any basis for the FD’s of R, a set of FD’s that imply all the FD’s that hold for R.

跳转到第一页

Finding all Implied FD’s Motivation: Suppose we have a relation ABCD with some FD’s F. If we decide to decompose ABCD into ABC and AD, what are the FD’s for ABC,AD? F=ABÆC, CÆD,DÆA. It looks like just ABÆC holds in ABC, but in fact C Æ A follows from F and applies to relation ABC. Problem is exponential in worst case.

跳转到第一页

Why? ABCD

a1b1cd1

a2b2cd2

comes from ABC

a1b1c

a2b2c

d1=d2 because C -> D a1=a2 because D -> A

Thus, tuples in the projection with equal C’s have equal A’s; C -> A. 跳转到第一页

Basic Idea for finding all FD’s after decomposition 1.

Start with given FD’s and find all nontrivial FD’s that follow from the given FD’s.

2.

Nontrivial = left and right sides disjoint.

Restrict to those FD’s that involve only attributes of the projected schema.

跳转到第一页

Algorithm

For each set of attributes X compute X+，but skip X=0,X=all attributes. Add XÆA for each A in x+ - X Drop XY ÆA if X ÆA holds Finally, project the FD’s by selecting only those FD’s that involve only the attributes of the projection.Notice that after we project the discovered FD’s onto some relation, the eliminated FD’s can be inferred in the projected relation. 跳转到第一页

Example:in ABC with FD’s A->B, B->C, project onto AC A+ = ABC; yields AÆB, AÆC 2. B+ = BC; yields BÆC 3. AB+ = ABC; yields ABÆC; drop in favor of AÆC 4. AC+ =ABC yields AC ÆB; drop in favor of AÆB 5. C+ =C and BC++ =BC; adds nothing. Resulting FD’s: AÆB, AÆC,BÆC Projection onto AC: AÆC. 1.

跳转到第一页

Classroom Exercise 3.5.1 Consider a relation with schema R(A,B,C,D) and FD’s ABÆC, CÆD and DÆA a) What are all the nontrieval FD’s that follow from the given FD’s? b) What are all the keys of R? c) What are all the superkeys for R that are not keys? 跳转到第一页

Solution a) Nontrivial FD’s (Implied FD’s) Given FD’s: ABÆC, CÆD, DÆA A+=A, B+=B,C+={C,D,A},D+={D,A} AB+={A,B,C,D},AC+={A,C,,D},AD+={A,D}, BC+={B,C,D,A},BD+={B,D,A,C},CD+={C,D,A} ABC+= ABD+=BCD+={B,C,D,A} ACD+={ACD} Answer is: C->A, AB->D, AC->D, BC->A, BC->D, BD->A, BD->C, CD->A, ABC->D, ABD->C, and BCD->A. b) AB, BC, and BD are keys c) ABC, ABD, BCD, and ABCD

跳转到第一页

Introduction to Normalization

Functional Dependencies cause some anomalies in a relational model. Solve the problem is to decompose relations. The process of decomposing is called Normalization. There are different conditions for Normalization: 1NF, 2NF,3NF and BCNF. 跳转到第一页

FD’s: NameÆaddr NameÆfavoriteBeer

Anomalies

beersLikedÆ.manf

Drinkers(name,addr,beersLiked,manf,favoriteBeer)

Name

Redundant Update anomalies Deletion anomalies addr

beersLiked

manf.

favoriteBeer

Janeway Voyager Bud

A.B.

Janeway Voyager WickedAle

Peter’s WickedAle

Spock

A.B.

Enterprise

Bud

WickedAle

Bud 跳转到第一页

Solution: Normalization

Solve the problem is to decompose relations. Guarantees no redundancy due to FD’s. Guarantees no update anomalies = one occurrence of a fact is updated, not all. Guarantees no deletion anomalies = valid fact is lost when tuple is deleted.

跳转到第一页

Normalization

A 1 4

B 2 2

Different conditions produce different Normal Forms BCNF(Boyce-Codd ),3NF,2NF,1NF Problems for decomposition C 3 5

A

B

B C

1

2

2

3

4

2

2

5

A

B

C

1

2

3

1

2

5

4

2

3

4

2跳转到第一页 5

Normalization: Boyce-Codd Normal Form Goal: BCNF(Boyce-Codd Normal Form ) = all FD’s follow from the fact “key Æ everything” Formally, R is in BCNF if every nontrivial FD for R, say XÆ A, has X a superkey. (Nontrivial means right-side attribute not in left side.)

跳转到第一页

Reason of problems Drinkers(name,addr,beersLiked,manf,favoriteBeer) FD’s: Each of the given FD’s is a BCNF violation: NameÆfavoriteBeer Key = { name, beersLiked } Each of the given FD’s has a left side a beersLikedÆ.manf proper subset of the key. NameÆaddr

Name

addr

beersLiked

manf.

favoriteBeer

Janeway Voyager Bud

A.B.

WickedAle

Janeway Voyager WickedAle

Peter’s WickedAle

Spock Enterprise Bud

A.B.

Bud 跳转到第一页

Another example: Beers(name,manf,manfAddr) FD’s= nameÆmanf, manfÆmanfAddr Key=name, so manfÆmanfAddr violates BCNF with left side unrelated to any key.

跳转到第一页

Decomposition to Reach BCNF Setting: relation R,given FD’s F. Suppose relation R has BCNF violation XÆB 1. Compute X+ Can not be all attributes Æ why? 2 Decompose R into X+ and (R-X+) ∪ X 3. Find the FD’s for the decomposed relations Project the FD’s from F = calculate all consequents of F that involve only attributes from X+ or only from (R – X+) ∪ X 跳转到第一页

Example R = Drinkers(name, addr, beersLiked, manf, favoriteBeer) F = 1. name → addr 2. name → favoriteBeer 3 . beersLiked → manf

Pick BCNF violation name → addr. + = name addr favoriteBeer. Close the left side: name Decomposed relations: Drinkers1(name, addr, favoriteBeer) Drinkers2(name, beersLiked, manf) Projected FD’s For Drinkers1: name → addr and name → favoriteBeer. For Drinkers2: beersLiked → manf. 跳转到第一页

(Repeating) •Decomposed relations: Drinkers1(name, addr, favoriteBeer) Drinkers2(name, beersLiked, manf) •Projected FD’s: For Drinkers1: name → addr and name → favoriteBeer. For Drinkers2: beersLiked → manf. •BCNF violations? For Drinkers1, name is key and all left sides of FD’s are superkeys. For Drinkers2, {name, beersLiked} is the key, and beersLiked → manf violates BCNF. 跳转到第一页

Decompose Drinkers2

First set of decomposed relations: Drinkers1(name, addr,favoriteBeer) Drinkers2(name, beersLiked,manf) Close beersLiked+ = beersLiked, m anf. Decompose Drinkers2 into: Drinkers3(beersLiked,manf) Drinkers4(name, beersLiked) Resulting relations are all in BCNF: Drinkers1(name, addr,favoriteBeer) Drinkers3(beersLiked, manf) Drinkers4(name, beersLiked)

跳转到第一页

Properties of Decomposition into BCNF

Relations in BCNF has no anomalies. Be able to reconstruct the original relation from decomposed relations, not more, not less.

跳转到第一页

Keys:{A,B} and {A,C} but CÆB has left side not a superkey •Suggests decomposition into BC and AC, but you can’t check the FD’:ABÆC in the relation

Problem caused by BCNF One FD structure causes problems: If you decompose, you cannot check the FD’s in the decomposed relations If you do not decompose, you violate BCNF Abstractly: ABÆC and CÆB Title city Æ theatre, theatre Æ City Street city Æzip, zip Æcity 跳转到第一页

Example: decomposition into BC and AC, but you can’t keep the FD’: ABÆC in the relation A = street, B = city, C = zip.

Join:

street

zip

545 Tech Sq. 545 Tech Sq.

02138 02139

city

zip

Cambridge Cambridge

02138 02139

zip → city street city → zip

city

street

zip

Cambridge Cambridge

545 Tech Sq. 545 Tech Sq.

02138 02139

跳转到第一页

3 NF Define the problem away A relation R is in 3NF iff for every nontrivial FD XÆ A, either: 1. X is a superkey or 2. A is prime = member of at least one key. Thus, the canonical problem goes away: you don’t have to decompose because all attributes are prime. 跳转到第一页

What 3NF gives you There are two important properties of a decomposition: 1. We should be able to recover from the decomposed relations the data of the original. Recovery involves projection and join, which we shall defer until we have discussed relational algebra

跳转到第一页

What 3NF gives you (cont.) 2. We should be able to check that the FD’s for the original relation are satisfied by checking the projections of those FD’s in the decomposed relations It is always possible to decompose into BCNF and satisfy (1) We can decompose into 3NF and satisfy both (1) and (2) It is not possible to decompose into BCNF and get both (1) and (2) 跳转到第一页

Example: Abstractly: AB → C and C → B. •Example 1: title city → theatre and theatre → city. •Example 2: street city → zip, zip → city. Keys: {A, B} and {A, C}, A,B,C are all prime. C → B. R(title, city, theatre) or R(street, city, zip) conform to 3NF. 跳转到第一页

Classroom Exercises: Exercise 3.6.1 a) R(A,B,C,D) with FD’s ABÆC, CÆD, DÆA a) Indicate all the BCNF violations. b) Decompose the relations, as necessary into collections of relations that are in BCNF c) Indicate all the 3NF violations d) Decompose the relations into 3NF. 跳转到第一页

Solution 1) C->A, C->D, D->A, AC->D, CD->A 2) Key are AB, BC, and BD BCNF: R1(AC), R2(BC), R3(CD) Or R1(CD),R2(BC),R3(AD) or… 3) No 3NF violations and why? 4) R(A,B,C,D) is already in 3NF

跳转到第一页

Multivalued Dependencies

The multivalued dependency X ->> Y holds in a relation R if whenever we have two tuples of R that agree in all the attributes of X, then we can swap their Y components and get two new tuples that are also in R

--- i.e. for each value of X, the values of Y are independent of the values of R-X-Y. X Y other

跳转到第一页

example Drinkers(name,addr,phones,beersLiked) with MVD name >>phones. If Drinkers has the two tuples: Name addr phones beersLiked Sue a p1 b1 Sue a p2 b2 It must also have the same tuples with phones components swapped: Name addr phones beersLiked Sue a p2 b1 Sue a p1 b2 Note: we must check this condition for all pairs of tuples that agree on name, not just one pair. 跳转到第一页

MVD Rules 1. Every FD is an MVD Because if X-> Y, then swapping Y’s between tuples that agree on X doesn’t create new tuples. Example, in Drinkers:name->>addr. 2. Complementation: if X->>Y, then x->>z, where Z is all attributes not in X or Y Example:since name->>phones holds in Drinkers, so does name>>addr beersLiked. 跳转到第一页

Splitting does not hold Sometimes you need to have several attributes on the right of an MVD. E.g: Drinkers (name, areacode,phones,beersLiked, beersmanf.) Name areaCode phones BeersLiked beerManf Sue 650 555-1111 Bud A.B. Sue 650 555-1111 WickedAle Peter’s Sue 415 555-9999 Bud A.B. Sue 415 555-9999 WickedAle Peter’s Name ->>areaCode phones holds but neither name ->> areaCode nor name ->>phones do 跳转到第一页

4NF Eliminate redundancy due to multiplicative effect of MVD’s Roughly: treat MVD’s as FD’s for decomposition, but not for finding keys. Formally: R is in Fourth Normal Form if whenever MVD X->>Y is nontrivial (Y is not a subset of X, and X ∪ Y is not all attributes) then X is a superkey.(key still depends on FDs only. ) 跳转到第一页

4NF (cont.) Remember, XÆ Y implies X->>Y, so 4NF is more stringent than BCNF Decompose R, using 4NF violation X->>Y, into XY and X ∪ (R-Y)

X

Y

R 跳转到第一页

example Drinkers(name,addr,phones, beersLiked) FD: name Æ addr Nontrivial MVD’s: name ->>phones and name ->>beersLiked. Only key:{name, phones,beersLiked} All three dependencies above violate 4NF Decompose using name -> addr: 1. Drinkers1(name, addr) 2.

In 4NF; only dependency is name -> addr.

Drinkers2(name, phones, beersLiked)

Not in 4NF. MVD’s name ->-> phones and name ->-> beersLiked apply. No FD’s, so all three attributes form the key. 跳转到第一页

Example (cont.)

Either MVD name ->-> phones or name ->-> beersLiked tells us to decompose to: Drinkers3(name, phones) Drinkers4(name, beersLiked) Successive decomposition yields 4NF relations D1(name, addr) D3(name, phones) D4(name, beersLiked) 跳转到第一页

Exercise 3.7.3 a) R(A,B,C,D) with MVD’s AÆÆB, AÆÆC a) Find all the 4NF violations b) Decompose the relations into a collection of relation schemas in 4NF.

1) Find the keys of the relation based on FD’s 2) Key is ABCD 3) Derive all MVD’s based on the 2 rules 4) Find all 4 NF violations based on the definition 5) R1(AB) R2(ACD)ÆR1(AB) R21(AC)R22(AD) 跳转到第一页

Relationships Among Normal Forms Property

3NF

BCNF

Most

Yes

4NF

Eliminates Redundancy due to FDs

Yes

Eliminates redundancy Due to MVDs

Preserves FDs Preserves MVD Equal to original relation

No No Yes maybe maybe maybe Yes Yes

Yes maybe maybe Yes

跳转到第一页

Other Normal Forms

First Normal form is simply the condition that every component of every tuple is an atomic value. Second normal form is less restrictive than 3NF. It permits transitive FD’s in a relation but forbids a nontrivial FD with a left side that is a proper subset of a key.

跳转到第一页

Homework

Exercise 3.5.2 i) (about FD’s) Exercise 3.6.1 c) (BCNF & 3NF) Exercise 3.7.3 c) (4NF)

跳转到第一页

Summary

Relational model, how to transfer E/R diagram into relational model Relation Schemas & Database Schemas and instances Functional Dependencies & the BCNF, the 3NF Multivalued Dependencies & 4NF Relationship between 3NF,4NF and BCNF 跳转到第一页