How to verify the good relations?
Minimizing redundancy, so that it appears only once in each attribute (column), unless these attributes as all or part of the role of foreign keys.
Why is this not a good design?
redundancy!
Redundancy cause an exception:
1. Insert the exception: In the absence of some attribute information, and the property can not null, the cause can not be inserted.
For example, he hired a new lecturer, the department has not generated lecID lecturer, you can not insert information leading to the lecturer to the form
2. Delete anomaly: just want to delete a message but delete the associated additional information.
If the Department of the only two retired lecturer, the lecturer of the information is deleted from the database two years, the dept of relevant information is also missing
3. Update anomalies: update a record, but the associated need to update other multiple records.
If the phone system update, deptPhone replaced, all table must be associated with the update deptPhone
Dependent function (functional dependency)
Similar to the function X = Y 2 when x = 2, may be determined y = 4; but when the 4 y equal, x = 2 can not be determined (may equals -2)
That is, if there x-> y relation R in (functional dependencies, x is determined Y), there is t1 [x] = t2 [x] (both as a) may be determined t1 [y] = t2 [y] (both b)
Fully functional dependency X, Y is a table of property or property group, if X → Y, and the X is any a proper subset (if the property group X contains more than one property, then), X → Y holds, then we say Y fully function It depends on X.
For example: lectID -> deptCode
lectID can determine deptCode
Part functional dependency X, Y is a table attribute or set of attributes, if the X → Y, and X is present in a subset (if the attribute group X contains more than one attribute, then), X → Y holds, then we call Y moieties functions depend in X.
For example: lectID, name -> deptCode
It can be seen (lectID, name) of the key combination can be determined deptCode, but a part of lectID key combination can be determined DEPTCODE
The first paradigm (1NF, First Normal Form): Column away with
Summary
1. If a table is unique in each row and column does not contain any row of a plurality of values, it satisfies 1NF. But for the table, the real standardization process starting from the second paradigm, because the relationship between the 1NF table itself has been met.
2. To ensure that the data must satisfy 1NF In actual use, no columns (column) secondary split (Atomicity)
3. 1NF main line processing large particles (Row)
4. there are still four questions: Insert abnormal, abnormal delete, update anomalies, data redundancy
The second paradigm (2NF, Second Normal Form): elimination of non-primary property of the code portion functions dependent
to sum up
1. Solution column (column) in part dependent upon the primary key (composite primary key) in question
2. In practice, almost no composite primary key, it is possible to perfectly avoid violation of the second paradigm
3. Insert anomalies and data redundancy issues have improved, but still, there are still delete abnormal and update anomalies.
The third paradigm (3NF, Third Normal Form): elimination of non-primary property of the code transfer function dependent
Boyce-Codd 范式（BCNF，Boyce-Codd normal form）