Database
Ch8.relational design
8.1 features of good design
8.1.1 larger alternatives
why design is good ?
Otherwise ,a larger alternative(schema) may cause:
1)redundancy
2)update may cause inconsistency
3)update may bring nulls
8.1.2 smaller alternatives
So,how do we make a smaller alternative(schema)?
It is impossible to divide a larger schema into a smaller one by means of finding repetition caused by join(why impossible? large amount of data and unknown of relations int the real world).
What matters is the the functional dependency(the rules in the real world).
On the other hand,a smaller alternative(schema) may cause:
1) lossy decomposition.which means when you decompose relation X,getting Y&Z.You will find Y join Z !=X.
8.2 atomic domains &1st normal form
atomic if elements of the domain are considered to be indivisible units.
a relation schema R is in first normal form (1NF) if the domains of all attributes of R are atomic.
Discuss in whether cs0114 is an atomic domain.
8.3 Decomposition Using Functional Dependencies
Recall notation
1)Roman letter stands for a relation set while Greek letter for other attribute set(always one attribute).
2)K is a super-key of r (R).(candidate key is a minimal super-key )
3)we use single lowercase letter in our definitions and algorithms,not for eg. Instructor.
4)instance of r means a particular value at some given time.
8.3.1 Keys and Functional Dependencies
Define :relations have feature of functions .
we say that the instance satisfies the functional Dependency
We say that the functional dependency alpha→beta holds on schema r (R)
a functional dependency of the form alpha→beta is trivial if beta ⊆alpha .
Some times alpha!->beta but alpha,gamma->beta.
notation F+ to denote the closure of the set F,
8.3.2 Boyce–Codd Normal Form
Boyce–Codd normal form (BCNF) eliminates all redundancy that can be discovered based on functional dependencies.
Formal definition
for all functional dependencies in F+ of the form alpha → beta, where alpha⊆ R and beta ⊆ R, at least one of the following holds:
• alpha→ beta is a trivial functional dependency (that is, beta ⊆alpha ).
• alpha is a super-key for schema R.
In other words,BCNF requires that all nontrivial dependencies be of the form α→β , where α is a superkey.
Decomposition rules: divide R into:
• (α ∪ β)
• (R − (β−α ))
8.3.3 BCNF and Dependency Preservation
About testing constrains.
in some cases, decomposition into BCNF can prevent efficient testing of certain functional dependencies.
When a dependency whose attributes do not all appear in any one schema we call it is not dependency preserving.
BCNF is not dependency preserving but 3rdNF is.
second normal form is of historical significance only and is not used in practice.
8.3.4 Third Normal Form
BCNF requires that all nontrivial dependencies be of the form α→β , where α is a superkey.
Third normal form (3NF) relaxes this constraint slightly by allowing certain nontrivial functional dependencies whose left side is not a superkey.