Informal design guidelines for relation schemas

GUIDELINE 1: Design a relation schema so that it is easy to explain its meaning. Do not combine attributes from multiple entity types and relationship types into a single relation. Intuitively, if a relation schema corresponds to one entity type or one relationship type, the meaning tends to be clear. Otherwise, the relation corresponds to a mixture of multiple entities and relationships and hence becomes semantically unclear.

note them clearly and make sure that the programs that update the database will operate correctly. If any anomalies are present. deletion.Informal design guidelines for relation schemas GUIDELINE 2: Design the base relation schemas so that no insertion. or modification anomalies are present in the relations. .

Informal design guidelines for relation schemas GUIDELINE 3: As far as possible. . make sure that they apply in exceptional cases only and do not apply to a majority of tuples in the relation. If nulls are unavoidable. avoid placing attributes in a base relation whose values may frequently be null.

because the join may produce spurious tuples. If such relations are unavoidable.Informal design guidelines for relation schemas GUIDELINE 4: Design relation schemas so that they can be JOINed with equality conditions on attributes that are either primary keys or foreign keys in a way that guarantees that no spurious tuples are generated do not have relations that contain matching attributes other than foreign key-primary key combinations. . do not join them on such attributes.

or projective rule) : { X→YZ } ╞ X→Y • IR5 (union. X→Z } ╞ X→YZ • IR6 (pseudo transitive rule) : { X→Y.Inference rules for FDs IR1 (reflexive rule) : if X  Y. or additive rule) : { X→Y. WY→Z } ╞ WX→Z • • • • . then X→Y IR2 (augmentation rule) : { X→Y } ╞ XZ → YZ IR3 (transitive rule) : { X→Y. Y→Z } ╞ X→Z IR4 (decomposition.

. For each fd Y  Z in F do If X+  Y then X+ := X+ U Z. Repeat oldX+ := X+. Until (X+ = oldX+).Determining X+. the closure of X under F X+ := X.

and still have a set of dependencies that is equivalent to F. 3. . 2. We cannot remove any dependency from F and still have a set of dependencies that is equivalent to F. where Y is a proper subset of X. Every dependency in F has a single attribute for its RHS. We cannot replace any dependency XA in F with a dependency YA.Minimal sets of Functional Dependencies A set FDs F is minimal if it satisfies the following conditions: 1.

…. Set G:= F 2. For each FD XA in G For each attribute B that is an element of X if ((G .{XA}) U {(X – {B})  A}) is equivalent to G.Finding a minimal cover G for F 1. Replace each FD X  {A1.XAn 3. XA2.{XA}) is equivalent to G.…. then replace XA with (X – {B})  A in G 4.A2. then remove XA from G . For each remaining FD XA in G If (G .An} in G by the n FDs XA1.

General Definition Of Second Normal Form A relation schema R is in second normal form if every nonprime attribute A in R is not partially dependent on any key of R .

Normalization to Second Normal Form LOTS PROPERTY_ID COUNTY_NAME LOT# AREA PRICE TAX_RATE FD1 FD2 FD3 LOTS1 PROPERTY_ID COUNTY_NAME FD4 LOT# AREA PRICE FD1 FD2 LOTS2 COUNTY_NAME TAX_RATE FD4 FD3 .

whenever a nontrivial FD X  A holds in R. or (b) A is a prime attribute of R.General Definition Of Third Normal Form A relation schema R is in third normal form if. . either (a) X is a super key of R.

Normalization to Third Normal Form LOTS1 PROPERTY_ID COUNTY_NAME LOT# AREA PRICE FD1 FD2 LOTS1A PROPERTY_ID COUNTY_NAME FD4 LOT# AREA FD1 FD2 LOTS1B AREA PRICE FD4 .

Boyce-Codd Normal Form A relation schema R is in BCNF if. . then X is a super key of R. whenever a nontrivial FD X  A holds in R.

Normalization to BCNF LOTS1A PROPERTY_ID COUNTY_NAME LOT# AREA FD1 FD2 FD5 LOTS1AX PROPERTY_ID AREA LOT# FD1 LOTS1AY AREA COUNTY_NAME FD5 .

Relational Database Design Algorithms & Further Dependencies .

}. Create an initial matrix S with 1 row I for each relation Ri in D. For each row i representing relation schema Ri {for each column j representing attribute Aj {if (relation Ri includes attribute Aj) then set S(i. .Testing For Lossless Join Property 1. 3. Set S(i. and 1 column j for each attribute Aj in R 2.}.j) := aj.j) := bij for all matrix entries.

}. it does not . 5. If no “a” symbol exists for the attribute in any of the rows. If a row is made up entirely of “a” symbols. then the decomposition has the lossless join property . choose one of the “b” symbols that appear in one of the rows for the attribute and set the other rows to that same “b” symbol in the column . Repeat the following loop until a complete loop execution results in no changes to S {for each FD XY in F {for all rows in S which have the same symbols in the columns corresponding to attributes in X { make the symbols in each column that correspond to an attribute in Y be the same in all these rows as follows: if any of the rows has an “a” symbol for the column.otherwise.}. set the other rows to that same “a” symbol in the column.4.}.

PNAME. HOURS. PNUMBER. {SSN. PLOCATION} F={SSNENAME.PLOCATION}. PLOCATION} R2 = EMP_PROJ1={SSN. ENAME. PNUMBER. PNAME.An Example • • • • • R = {SSN. PNUMBER{PNAME. HOURS} R1 = EMP_LOCS={ENAME.PNUMBER}HOURS} SSN R1 R2 B1 a1 ENAME a2 b22 PNUMBER b13 a3 PNAME b14 a4 PLOCATION a5 a5 HOURS b16 a6 (no changes to matrix after applying functional dependencies) . PLOCATION.

{SSN. PLOCATION} R3 = WORKS_ON = {SSN.PNUMBER}HOURS } . HOURS} F= { SSNENAME. PNUMBER{PNAME. PNUMBER. HOURS} R1 = EMP={SSN. ENAME} R2 = PROJ={PNUMBER.Another Example R = {SSN. ENAME. PNAME. PNAME. PNUMBER. PLOCATION.PLOCATION}.