Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Introduction
Normalisation is a theory for designing relational schema that make sense and work well. Well-normalised tables avoid redundancy and thereby reduce inconsistencies. Redundancy is unnecessary duplication. In well-normalised DBs semantic dependencies are maintained by primary key uniqueness.
Goals of Normalisation
Eliminate certain kinds of redundancy avoid certain update anomalies good reresentation of real world simplify enforcement of DB integrity
Update anomalies
Undesirable side-effects that occur when performaing insertion, modification or deletion operations on badly designed relational DBs.
SSN 987 654 333 321 678 467 Name J Smith M Burke A Dolan K Doyle O ONeill R McKay Dept 1 2 1 1 3 2 DeptMgr Dept Name 321 467 ... 321 321 678 467
Sample anomalies
Modification when the manager of a dept changes we have to change many values. If we are not careful the DB will contain inconsistencies. There is no easy way to get the DB to ensure that a department has only one manager and only one name.
Anomalies continued
Deletion if O ONeill leaves we delete his tuple and lose
the fact that there is a department 3 the name of dept 3 who is the manager of dept. 3
Insertion
how would we create a new department before any employees are assigned to it ?
Better design
Separate entities are represented in separate tables.
SSN 987 654 333 321 678 467 Name J Smith M Burke A Dolan K Doyle O ONeill R McKay Dept 1 2 1 1 3 2 Dept 1 2 3 DeptMgr Dept Name 321 467 ... 678
Note that mapping from an ER model following the steps given will give a well-normalised DB.
Determinants
A is a determinant of B if each value of A has precisely one (possibly null) associated value of B. Said another way A is a determinant of B if and only if whenever two tuples agree on their A value they agree on their B value.
A B
Determinants
Note that determinancy depends on semantics of data
cannot be decided from individual table occurences.
Alternative terminology
if A (functionally) determines B then B is (functionally) dependent on A
Example determinants
SSN determines employee name SSN determines employee department Dept. No. determines Dept. Name Dept. Name determines Dept. No.
assuming Dept. names are also unique
Determinancy Diagram
Name SSN Department Dept. Name
Dept. Mgr
In general key attributes of an entity determine all the single-valued attributes of the entity.
Composite Determinants
(SSN, Project#) together determine the hours that the employee works on the project. Suppose packsize of a part depends on the supplier.
Name SSN hours Project# PName
S# packsize
P#
PName
Superfluous Attrbiutes
Superfluous attributes
If SSN determines name, so does (SSN, Dept) and (SSN, Dept, salary), etc. Always remove superfluous attributes from determinants.
Transitive Dependencies
SSN actually determines DeptMgr but only because
DeptNo SSN
Dept. Mgr
Candidate keys
candidate key = any attribute or set of attributes which will be unique for a table (set of attributes).
As well as the primary key there may be other candidate keys. E.g. DNUMBER and DNAME are both candidate keys for the Department table.
(SSN, Project#) is a (composite) candidate key for a table containing these five attributes.
teacher
E F
Dept. Mgr
BCNF rule
In well-normalised relations (Boyce-Codd normal form) every determinant is a candidate key.
SSN Name DeptNo The employee/dept table decomposed to BCNF. Note that both DeptNo and DeptName are candidate keys of the second table. DeptNo Dept. Name
Dept. Mgr
Transformation to BCNF
Create new tables such that each non-key determinant is a candidate key in a new table. The new table contains the attributes which are directly determined by the new candidate key.
V V X W A B C Z A V W Y
V
W Z
X
Y A B C BCNF tables : (V, X) (A, B, C) (V, W, Z, A) (V, W, Y)
2NF - every non-key attribute is fully dependent on the primary key G H J 3NF - eliminate functional is in 2NF dependencies between non-key Table but not 3NF attributes
all dependencies can then be enforced by uniqueness of keys.
A teacher teaches only one subject. For a given subject a given student has only one teacher. teacher student teacher
Fully-normalised
BCNF relations are well-normalised Fully-normalised relations are those with no multi-valued dependencies (4NF) and no join dependencies (5NF).