Scribd
Upload
5K views

Informal Design Guidelines For Relation Schemas

The document provides informal guidelines for designing relation schemas in a database. Guideline 1 recommends designing relations so each corresponds to a single entity or relationship type for clarity. Guideline 2 recommends avoiding anomalies like insertion, deletion, and modification anomalies. Guideline 3 recommends avoiding frequent null attribute values. Guideline 4 recommends designing relations to join on primary and foreign keys to avoid spurious tuples.

Uploaded by

adddata
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
5K views

Informal Design Guidelines For Relation Schemas

The document provides informal guidelines for designing relation schemas in a database. Guideline 1 recommends designing relations so each corresponds to a single entity or relationship type for clarity. Guideline 2 recommends avoiding anomalies like insertion, deletion, and modification anomalies. Guideline 3 recommends avoiding frequent null attribute values. Guideline 4 recommends designing relations to join on primary and foreign keys to avoid spurious tuples.

Uploaded by

adddata
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 19

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 }

You might also like