Three paradigms of generalization and example _

This article explains the three paradigms in the eyes of Java programmers, with examples, and what problems this design will cause. To more generally describe the 3 big paradigm. Finally attach a little understanding of BC paradigm.

First paradigm, each column can not be divided.

Corresponding to our design is that no duplicate columns can appear. This is the basis of the relational database no one will make this mistake (the database is not allowed).

Here's an example of a mistake we might make.

Student table, (Name, class, age, sex, home address, class name, class title, selected course, course credits).

Here if the Bureau of Education to see all the tables, may appear, statistics of Beijing Tongzhou District number of students, statistics of Beijing Haidian District, the number of students. There's no way to count it. So in this context, we design should be. Student table (Name, class, age, Sex, home city, family area, class name, class title, selected course, course credits).

Understanding: When designing a database, it is best to divide things into suitable particles according to the business. We also have a 2 situation, is not enough fields, and can not arbitrarily add database fields, I put an alternate field, the middle with, "," as a separator, put a lot of things, and finally to classify statistics, on 2.

The second paradigm, based on the first paradigm, is dependent on the primary attribute.

or the example above.

The main attribute, the candidate code, is the only meaning (that is, the primary key in the database). If the student's name is unique, the student's name is the code, then there is the main attribute. If each student chooses only one course. Then the course is also the only one that relies on names. But in real life, students are easy to duplicate the name, students have to choose a number of courses. So the above violates the second paradigm. Change to, student form (school number, name, class, age, Sex, home city, family area, class name, class title, selected course number), curriculum (course number, course name, course credits).

Understanding: The program must set the primary key, a one-to-many relationship must be separated, much is the same as many. Sometimes the name and the primary key are placed in another table in order to make it easy to even watch. This eliminates the table, but there is a situation

The name of the teacher has changed, but the name of the teacher on your student table has not changed.

The third paradigm eliminates the dependency of non-primary attribute delivery.

Student form (school number, name, class, age, Sex, home city, family area, class name, class teacher title, selected course number)

At this time, the class teacher relies on the school number, the class name depends on the teacher, indirectly depends on the school number, which is the transfer of dependence should be changed.

Student form (school number, name, class, age, Sex, home city, family area, class number, selected course number)

Teacher's Table (teacher number, name, title)

Understanding: Other information in the program other than the primary key cannot appear in other tables. (that is, any two tables, duplicate non-primary key fields cannot appear)

BC Paradigm, eliminating main attribute transfer dependencies

Let's say that the school brain pumping, so that fingerprint easy to clock. Student form (school number, name, class, age, Sex, home city, family area, fingerprint)

The fingerprint is unique here, the fingerprint depends on the number, then there is the main attribute dependency.

If the students drop out and the fingerprint information disappears, the system does not meet the requirements if it wants to build a fingerprint library.

This is the waiting list, the student form (school number, name, class, age, Sex, home city, family area, fingerprint ID). Fingerprint list (fingerprint ID, fingerprint)

Understanding: 1 to 1 relations, preferably also differential.

The above is a personal understanding, if there is a mistake, hope the reader pointed out, thank you.