First, the concept of
creating a database of the process, must follow certain guidelines, which are called paradigm, a total of six from the first to the sixth paradigm.
Second, the background of
varying degrees of standardization of the database (on a blog have written), and there will be so many paradigms. Database database design paradigm is essential knowledge, no understanding of the paradigm, you can not design a high efficiency, elegant database, or even design a database error mistake.
Third, the goal of
general database design simply follow the first paradigm, the second paradigm, the third paradigm, and it is sufficient to meet these specifications database is simple and clear structure, at the same time, does not occur insert (insert), delete (delete ) and update (update) operation exception.
The correct data structure, not only contribute to the appropriate database access operation can greatly simplify other content (queries, forms, reports, code, etc.) application, in accordance with the table "database normalization" design, the aim is to reduce data redundancy in the database, in order to increase the consistency of data.
Fourth, the concept of
a candidate key: uniquely identifies the attribute or group table. And any of its subsets can no longer identified, the property is said group (super symbol) candidate code.
For example: In the student entity, "student number" is uniquely distinguish student entity, while if "name", "class" attribute combination sufficient to distinguish student entity, {student number} and {name, class} are It is (super symbol) candidate code.
2, the so-called dependency, is the functional dependency is mapped. Can be one to one, one to many may be many to many.
Five, six major paradigm
The first paradigm (1NF): property is not split or duplicate column without
a property is not allowed to build the column into a plurality of attributes. In fact, in the current DBMS it is not possible to split the property, because they are not allowed to do so.
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. Paradigm model requires a first attribute value can no longer be split into smaller portions, i.e., the property item is not composed of a combination of attributes or a set of attributes.
In short, the first paradigm is no duplicate column. For example, a table "employee No." "Name," "Phone Number" consisting of (a person may have an office phone and a mobile phone), then it can be normalized to 1NF phone number into "work phone" and "mobile phone" two properties, namely workers (employees number, name, office phone, mobile phone).
The second paradigm (2NF) :( is to have a unique key, and the non-primary key attribute candidate is totally dependent.) (May be a candidate key, may be two, if a relational table, there is generally a candidate key two primary attributes, the non-primary key attributes of the candidate dependence on the two main properties, depends on whether it is totally dependent. redundant data portion can cause dependence.)
the second paradigm (2NF) in the first paradigm ( established 1NF) on the basis that the 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.
Fully functional dependency
to talk about what is part of the functional dependency.
Function dependent part, another attribute is determined a plurality of attributes, but in fact, the plurality of attributes is redundant. For example, (student number, class) -> name, in fact, only need to be able to decide the name of student number, and therefore the class is redundant and should be removed.
If the relational model is the first paradigm R, and R each non-primary key attribute is fully dependent on the function of a candidate of R, R is called the second mode paradigm (if A is a candidate key attribute of the relational schema R , then a is the main attribute of R, otherwise known as non-a is the main attribute of R).
So the goal is to eliminate redundant second paradigm property function dependencies that exist on the left.
For example, enrollment in relational tables (student number, course number, grades, credits), the keyword for the combination of keywords (student number, course number), but because of non-primary attributes credit depends only on the course number, keyword (Student ID , course number) is only partially dependent, rather than rely solely on, so in this way can lead to data redundancy and update anomalies and other issues, the solution is divided into two relational schema: student Form (student number, course number, score ) and curriculum (course number, credit), a new relationship, connection on demand by foreign keys course number to contact the student table.
3. A third paradigm (3NF): transmission-dependent elimination of
third normal form must meet a second database paradigm.
That is, the database is only dependent on the non-primary attributes candidate key, is associated with other non-primary property does not exist.
For example, the relationship between the books, the library. Comprising a number of books, publishers, page number and other information, including library Library numbers stored Books (foreign key). Wherein the library table should not be any specific information stored in the book (e.g., publisher ..), but only to obtain information corresponding to the primary key books Book Number. (This example illustrates not only partly dependent, dependent on nothing to do with the transfer, the water is really ah)
Student Form (student number, name, course number, results) as an example, where the student's name without the same name, so the table has two candidate code (student number, course number) and (name, program number), it is the presence of functional dependency: school -> name (student number, course number) -> results, the only non-primary property of the code results partially dependent absent, there was no transfer dependency, the attributes belonging to the third paradigm.
Briefly, a third paradigm (3NF) requires a database table does not contain non-primary property information has already contained 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.
To summarize: two tables associated with a table can have only one dependent on the other table.
General system design needs to meet the third paradigm. Briefly third paradigm two associated table, a table can have a candidate key in another table, you can not have a common non-primary property.
That is, two association table, a Table A Table B another non-primary property C, Table A candidate key has a key candidate and b, b also table B, is transmitted at this time dependencies: AB, Bc. In this case does not meet the third paradigm.
4.BC Paradigm (BCNF) :( candidate key when there are multiple attributes, a plurality of main properties directly transferred to eliminate dependencies)
(1) All non-primary attributes of each code is completely dependent function;
(2) for each of all the main properties that do not contain a code, the function is completely dependent;
(3) does not have any function depends entirely on the properties of any combination of a non-code.
R belongs 3NF, not necessarily belong BCNF, if R belongs BCNF, must belong 3NF.
···
is respect to the candidate code includes a plurality of attributes, which does not rely on another key field.
Suppose warehouse management relations table (warehouse number, storage items number, administrator number, quantity), meet an administrator working in a warehouse only; a warehouse can store a variety of items, there is the following relationship:
(Warehouse number, storage items number) -> (administrator number, quantity)
(No. administrators, storage items number) -> (warehouse number, quantity)
Therefore, (warehouse number, storage items number) and (administrator number, item number stored) are warehouse management relations table of candidate code, the only non-key fields of the table for the number, which is in line with the third paradigm. However, because of the following decisions relationship:
(Warehouse No.) -> (administrator No.)
(No. administrator) -> (warehouse number)
???
that there is a key field decide the case of key fields, so it does not in line with BCNF. The warehouse management relations table into two tables warehouse management relations table (warehouse number, the administrator number) and a warehouse tables (warehouse number, storage items number, quantity), so that the database table is consistent with BCNF and eliminate the abnormal deleted , insertion anomaly and update anomalies.
The fourth normal form (4NF) :( a primary key table corresponds to only a multi-value)
for each of X-> Y, X can find a candidate code (an attribute value group if the relationship can be uniquely expressed a tuple, but not its subset, this property is said group of candidate codes).
Let R be a relational model, D is multi-value dependent on the set R. If the D value is dependent on the presence of all the multi X-> when Y, X must be a super-R bond, then R is said fourth normal mode.
For example, staff table (employee number, the name of the child workers, workers elective courses), in the table, the same workers may have more workers child's name, the same, the same workers may also have multiple workers elective courses, namely here there is multi-valued fact, does not meet the fourth normal form. If you want to meet the fourth normal form, just on the table is divided into two tables you want to make them only the fact that more than one value, such as a staff table (employee number, employee child's name), employees Table II (staff numbers, staff elective courses) two tables is only one multi-valued fact, it is consistent with the fourth paradigm.
6 Summary:
first normal, second paradigm for this table. The third paradigm, BC paradigm and fourth paradigm involving multiple tables.
1, a first relatively simple paradigm, property is not split. A phone number field can be divided into two landline number and mobile phone number fields.
2, a second paradigm is easy to understand, the non-primary key attributes of the candidate totally dependent, partially dependent not exist. Only one primary candidate key attributes it must conform to a second paradigm.
When the main candidate keys comprising a plurality of attributes, the situation does not meet the second paradigm may occur, is the dependence on non-primary property multiple attribute candidate key function section. When non-primary key attributes of the plurality of candidate attribute entirely dependent function, consistent with the second paradigm.
3, a third paradigm removing redundant, non-primary property can only be one table, there should not be more than one table, meaningless to remove data redundancy.
4, BC paradigm is a keyword that determine a keyword should not exist. I.e. the relationship table, a table has a plurality of candidate key attributes constituting the composite master should not have properties directly depend on each other. Job number and ID number are interdependent.
5, a fourth paradigm, the candidate key exists only for no more than one multi-valued attributes. He asked to delete many relationship in the same table.
Reference: https://blog.csdn.net/yahohi/article/details/7529710
https://blog.csdn.net/hyqsong/article/details/52245195
https://blog.csdn.net/dove_knowledge/article/ details / 71434960