The Relational Data Model
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 跳转到第一页
