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.
Informal design guidelines for relation schemas
GUIDELINE 2: Design the base relation schemas so that no insertion, deletion, or modification anomalies are present in the relations. If any anomalies are present, note them clearly and make sure that the programs that update the database will operate correctly.
Informal design guidelines for relation schemas
GUIDELINE 3: As far as possible, avoid placing attributes in a base relation whose values may frequently be null. If nulls are unavoidable, make sure that they apply in exceptional cases only and do not apply to a majority of tuples in the relation.
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. If such relations are unavoidable, do not join them on such attributes, because the join may produce spurious tuples.
Inference rules for FDs
IR1 (reflexive rule) : if X Y, then XY IR2 (augmentation rule) : { XY } XZ YZ IR3 (transitive rule) : { XY, YZ } XZ IR4 (decomposition, or projective rule) : { XYZ } XY IR5 (union, or additive rule) : { XY, XZ } XYZ IR6 (pseudo transitive rule) : { XY, WYZ } WXZ
Determining X+, the closure of X under F
X+ := X; Repeat oldX+ := X+; For each fd Y Z in F do If X+ Y then X+ := X+ U Z; Until (X+ = oldX+);
Minimal sets of Functional Dependencies
A set FDs F is minimal if it satisfies the following conditions:
1. Every dependency in F has a single attribute for its RHS. 2. We cannot replace any dependency XA in F with a dependency YA, where Y is a proper subset of X, and still have a set of dependencies that is equivalent to F. 3. We cannot remove any dependency from F and still have a set of dependencies that is equivalent to F.
Finding a minimal cover G for F
1. Set G:= F 2. Replace each FD X {A1,A2,,An} in G by the n FDs XA1, XA2,,XAn 3. For each FD XA in G
For each attribute B that is an element of X if ((G - {XA}) U {(X {B}) A}) is equivalent to G, then replace XA with (X {B}) A in G
4. For each remaining FD XA in G
If (G - {XA}) is equivalent to G, then remove XA from G
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
General Definition Of Third Normal Form
A relation schema R is in third normal form if, whenever a nontrivial FD X A holds in R, either (a) X is a super key of R, or (b) A is a prime attribute 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, whenever a nontrivial FD X A holds in R, then X is a super key of 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
Testing For Lossless Join Property
1. Create an initial matrix S with 1 row I for each relation Ri in D, and 1 column j for each attribute Aj in R 2. Set S(i,j) := bij for all matrix entries. 3. 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,j) := aj;};};
4.
5.
Repeat the following loop until a complete loop execution results in no changes to S {for each FD XY 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, set the other rows to that same a symbol in the column. If no a symbol exists for the attribute in any of the rows, 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 ;};};}; If a row is made up entirely of a symbols, then the decomposition has the lossless join property ;otherwise, it does not
An Example
R = {SSN, ENAME, PNUMBER, PNAME, PLOCATION, HOURS} R1 = EMP_LOCS={ENAME, PLOCATION} R2 = EMP_PROJ1={SSN, PNUMBER, HOURS, PNAME, PLOCATION} F={SSNENAME; PNUMBER{PNAME,PLOCATION}; {SSN,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)
Another Example
R = {SSN, ENAME, PNUMBER, PNAME, PLOCATION, HOURS} R1 = EMP={SSN, ENAME} R2 = PROJ={PNUMBER, PNAME, PLOCATION} R3 = WORKS_ON = {SSN, PNUMBER, HOURS} F= { SSNENAME; PNUMBER{PNAME,PLOCATION}; {SSN,PNUMBER}HOURS }
