.1 first paradigm (1NF) without duplicate column
The so-called first paradigm (1NF) means for each column of a database table are indivisible basic data items, the same column can not have more than one value, i.e., an entity attribute values or not have a plurality of properties can not be duplicated . If duplicate attribute appears, it may be necessary to define a new entity, the new entity composed of repeating attribute to-many relationship between the new entity and the original entities. Each row in the first paradigm (1NF) table contains only one example of information. In short, the first paradigm is no duplicate column.
Description: In any relational database, first normal form (1NF) is the basic requirement of the relational schema, does not meet the first normal form (1NF) database is not a relational database.
1.2 The second paradigm (2NF) entirely dependent on the primary key attribute [Functions dependent relief portion]
Second Normal Form (2NF) is established on the basis of first normal form (1NF) on that second normal form (2NF) must be met first normal form (1NF). The second paradigm (2NF) requires each instance or a database table row must be uniquely distinguished. To achieve the distinction typically requires adding a column to the table, to uniquely identify each instance storage. Such as employee information table, adding the number of employees (the emp_id) column, because the employee number each employee is unique, each employee can be uniquely distinguished. This unique property is referred to as the primary key column or primary key, the master key.
The second paradigm (2NF) required attributes of the entity entirely dependent on the primary key. The so-called completely dependent on the presence of means can not rely solely on a part of the primary key attribute, if present, and this part of the primary key attribute should be separated to form a new entity, between the original and the new entity is an entity of many relationship. To achieve the distinction typically requires adding a column to the table, to uniquely identify each instance storage. In short, the second paradigm is entirely dependent on the primary key attribute.
1.3 The third paradigm (3NF) is not dependent on the other properties of the non-primary property [eliminate dependency passed]
Third normal form (3NF) must satisfy the second paradigm (2NF). Briefly, a third paradigm (3NF) requires a database table comprising a non-primary key information is not already included in other tables. For example, there is a department information table, where each department has a department number (dept_id), department name, department briefings and other information. Then the department number listed in the employee information table after the department can no longer name, department briefings and other information related to the department added staff information table. If the department information table does not exist, according to the third normal form (3NF) should build it, otherwise there will be a lot of data redundancy. Briefly, third paradigm is not dependent on other properties of non-primary property.
II, Analysis Model Application Examples
The following students at a school system as an example analysis shows that application of these paradigms. First, a first paradigm (1NF): database table fields are a single property, it can not be divided. This property consists of a single basic types, including integer, real number, character, logic type, date type. In any current relational database management system (DBMS), the fool can not make the database does not meet the first paradigm, because the DBMS does not allow you to a database table subdivided into two or more columns. So, you want to design a database does not meet the first paradigm in the existing DBMS is impossible.
First we determine what to include those designed. Student number, student's name, age, gender, curriculum, course credits, academic departments, academic performance, the department office address, office phone system and other information. For simplicity we consider only those temporary field information. We have the following aspects to the problem of information, said concern.
Those students have basic information
Students chose those classes, what results is
Each lesson is how much credit
Students belonging to that department, what the basic information system Yes.
2.1 The second paradigm (2NF) example analysis
First, we consider all this information into a table (student number, student's name, age, gender, curriculum, course credits, academic departments, academic performance, the department office address, office telephone system) has the following dependencies below.
(Student ID) → (name, age, gender, academic departments, the Department of office address, office telephone system)
(Course name) → (credits)
(Student number, course) → (academic achievement)
2.1.1 Analysis
Did not satisfy requirements of the second paradigm, the following problems occur
Data redundancy: n the same course by the student elective, "credits" on repeat n-1 times; m elective courses with a student's name and age on repeated m-1 times.
Update anomalies:
1) If a credit adjustment of a course, "credit" data in the table all the rows values will be updated, the same or a different course credits would happen.
2) Suppose you want to set up a new course, being no one elective. Thus, since no "study" keyword, course name and credit can not record into the database.
Delete anomaly: Suppose a group of students in elective courses have been completed, records of these electives should be removed from the database table. However, at the same time, course name and credit information has been deleted. Obviously, this can lead to insert exception.
2.1.2 Solution
Elective SelectCourse the table to the following three tables:
Student: Student (Student ID, name, age, gender, academic departments, the Department of office address, office telephone system);
Course: Course (course name, credits);
Elective Relations: SelectCourse (student number, course name, results).
2.2 The third paradigm (3NF) Analysis of Examples
Then look at the table above student Student (student number, name, age, gender, academic departments, the Department of office address, office telephone lines), keywords for a single keyword "Student Number", because of the following decisions relationship:
(Student ID) → (name, age, gender, academic departments, the Department of office address, office telephone system)
But there is also decided the following relationship
(Student ID) → (where the Academy) → (College Place, college phone)
That there is a non-key fields, "Institute of place", "School Phone" dependence on key field "study" of the transfer function.
It also there is data redundancy, update anomalies, insertion and deletion of abnormal abnormal. (Update data, delete abnormal here is not analysis, and can be analyzed with reference to 2.1.1)
According to the third paradigm of the relationship between the student table is divided into the following two tables to meet the third paradigm:
:( school student number, name, age, gender, academic departments);
Do not tie :( Department, the Department of office address, office phone system).
to sum up
The above is consistent with the database table I, II, III paradigm, eliminating data redundancy, update anomalies, insertion anomaly and deletion anomaly
First, the concept of functional dependency
functional dependency is defined mathematically, where each constrained to characterize the relationship between each attribute in yet interdependent relationship. Functional dependency exists in real life, for example, describe a relationship between the student and can have multiple attributes number, name, location-based, etc., as a student number corresponding to one and only one student, a student enrolled in a certain system , so when the value of the attribute "study" OK, "name" and "location-based" value will uniquely identified at this time, you can say "name" and "host-based" function depends on the "Student ID "or" study "function determines the" name "and" host system ", recorded as: school → name, student number Department → lies. The exact definition given below dependent function.
Definitions: Let U {A1, A2, ..., An} is a set of attributes, R (U) is a relation on U, x, y is a subset of U. If for any possible relationship in R (U), has a value of x corresponds to a unique value of y particular, said y x is functionally dependent on, referred to as x → y. Where x is called the determining factor. Further when there are x → y, x and y are called interdependent, denoted x ← → y. For example the relationship shown in Table 1.2, "System": If the value is unique name lines, i.e., each department name are not the same, then there is functional dependencies:
Department Code → department name, the code-based system → address codes based → based phone, the code-based system → Specialties.
→ Department Code Department name, department name → Department address, telephone system name → Department, the Department of professional settings → name.
Visible, department name and the code interdependent system, referred to as a department name ← →-based code.
Function dependencies can be subdivided into various functional dependency, were introduced as follows:
II, part functional dependency
provided R & lt (U) is related to the attribute set U, x, Y is a subset of U, x 'is a true child of x set, if x → y and x '→ y, y partially dependent called x, denoted by X → PY. Obviously, if and only if x is the composite attribute set, only partially functional dependency may occur.
For example, Table 1.6, it is clear there is course number → course name, course number → commencement Department code. From another perspective, as long as a certain number of courses, but courses were OK, Department of commencement will be uniquely determined, so the course number + course name → commencement Department code. But it is the previous course number → commencement Department of the code is different, because {course number, course name} there is a proper subset: "course number", course number → commencement Department code, we put the course on the 10th course name → commencement Department of Code says the "commencement Department Code" function depends on the course number + course name.
Third, fully functional dependency
provided R & lt (U) is related to the attribute set U, x, Y is a subset of U, x 'is a subset of x. If for any possible relation R (U), there are x → y but x '→ y, y called totally dependent on the function x, referred to as X → FY.
The so-called explanation is completely dependent on no excess property in dependency DECISION (ie dependencies items on the left), there is excess property is partially dependent.
E.g. relational schema provided R, R R = (number, name, class number, course number, grade), is easy to know:
"(school, class number, course number) → score" is a part of the R dependence. So there is a proper subset of (student number, course number) decision items, making "(student number, course number) → score" was established, and the "study → accomplishments" or "course number → results" established "(student number, course number) → score "R is a totally dependencies.
Fourth, the transfer function is dependent
provided R & lt (U) is related to the attribute set U, x, y, z is a subset of U, in R & lt (U), if x → y, but y → x, if y → z , then x → z, z transfer function dependent on said x, denoted by X → TZ.
For example, in a school, each course are taught a bit, but some teachers may teach a multi-course, there is shown the relationship between "teaching" as shown in Table 3.1.
From the above analysis is not difficult relationship, course name → staff number, employee number → name of course, but as a function of number of workers and other properties are the determining factor in that the number of workers → teacher name, employee number → title, in this case under the teacher name, title transfer function depends on the course name.
Table 3.1 Table Teaching
Course Name
No. of workers
teacher name
Sex
Date of Birth
titles in
English
T1
Zhang Ping
Male
55.6.3
professor of
mathematics
T2
Wang
female
62.10.5
associate professor of
C language
T3
Li Ying
female
62.10.5
Associate Professor
database
T2
Wang
female
62.10.5
Associate Professor
Closures concept
The following are write more scientific and standardized closure solving method, a subset of the set of attributes X and Y are both provided in the relationship between R, F is a function dependent on a set of R, B attribute set if any one of R, once the X → B, must B⊆Y, and R is any of a set of attributes Y1 satisfy the above conditions, there must Y⊆Y1, at this time, said set of attributes X and Y is in the closure under the functional dependencies F, denoted as X + .
The step of calculating the set of attributes closure relation R X is as follows:
Step: The final set will be the set of attributes closure is Y, the X-Y initialized;
Step Two: Check each of the F functional dependency A → B, if the attribute set A of all properties in Y, B and Y Some of the properties are not, then it is added to the Y;
The third step: The second step is repeated until there is no attribute may be added to the property set Y, so far. The resulting Y is the X- +
Example (1): has a relational schema R (U, F), where U = {A, B, C , D, E, I}, F = {A → D, AB → E, BI → E, CD → I, E → C}, is calculated (the AE) +
Solution: (1) Order X = {AE}, X (0) = AE
(2) Looking not been used on the left in F is a function dependent on a subset of the AE, the result is: A → D, E → C; therefore X (1) = X (0) DC = ACDE, apparently X (1 ) ≠ X (0).
(3) Find the left has not been used in function F is dependent subset ACDE, the result is: CD → I; therefore X (2) = X (1 ) I = ACDEI. Although X (2) ≠ X (1 ), but has not been used to find F function has no dependency on the left X (2) a subset of, the need to calculate it, i.e., (the AE) + = ACDEI.
He said vernacular that: the closure is a collection of property derived directly or indirectly all attributes.
For example: f = {a-> b, b-> c, a-> d, e-> f}; it can be obtained directly by the a and b d, indirectly, c, then a closure is {a, b, c, d}
Theory and algorithms for solving Candidate Keys
For a given relation R (A1, A2, ... An) and functional dependencies F, which property can be divided into four categories:
L Appearing in only the left portion of the function-dependent properties.
R Appearing in only the right portion of the function-dependent properties.
N class attributes were not there in the left and right sides of the functional dependencies.
LR attribute class dependent function both left and right sides appear.
Theorem: Let R For a given functional dependency and cluster F, if X (x∈R) L is a class attribute, then X must be members of any of the candidate code is R.
Corollary: For a given relational schema R and functional dependencies cluster F, if X (x∈R) L is a class attribute, and X + contains all attributes of R; then X must be a unique candidate code R.
Example (2): Relationship with mode R (A, B, C, D), which functional dependencies F = {D → B, B → D, AD → B, AC → D}, find all candidate code R .
Solution: investigation found F, A, C L is a class attribute two properties, it must be a candidate code AC member R, and because (AC) + = ABCD, the AC is the only candidate code of R.
Theorem: Let R For a given functional dependency and cluster F, if X (x∈R) R is a class attribute, then X is not any of the candidate codes.
Theorem: Let R For a given functional dependency and cluster F, if X (x∈R) is an N-type attribute, then X must be included in any candidate code R in.
Corollary: For a given relational schema R and functional dependencies cluster F, if X (x∈R) is a set of attributes and N classes Class L, and X + contains all attributes of R; only then X is R candidate code.