The three major SQL paradigms have been like this.

1NF) (A primary key is required and the column cannot be split) Any field in the database table is single attribute and cannot be divided.   Create table aa (id int, NameAge varchar (100 )) Insert aa values (1, ''infinite-female '') Not reaching the first paradigm Create table aa (id int, name varcahr (10), age char (2 )) Insert aa values (1, ''infinite '', ''female '') Reach the first paradigm   2NF) Non-Keyword fields in database tables do not have part of function dependencies on any candidate keyword segments. (When a table is a composite primary key, non-primary key fields do not depend on some primary keys (that is, they must depend on all primary key fields ))   Create table sci ( Sno int (32), cno int (32), grade int (32), credit int (32 ), Primary key sno, cno ) Course (cno) 1---1 credit (credit) Student (sno) n --- n course (cno) Student + course ---> score (grade) Sci Sno cno grade credit 1 1 60 80 2 1 90 80 3 1 70 80 .... .... .... In this way, credits are stored repeatedly and data redundancy occurs. If you want a course credit, you need to repeat a large number of operations. If you want to add a new course, because sno and cno are used as the primary keys, you must select this course when you join the new course. If a student finishes a course, other course information of the student is also deleted. In short This design is not very good. The non-Keyword attribute credit only depends on the cno function, that is, the credit part depends on the combined keyword (sno, cno) instead of the full dependency. Solution It is divided into two relational modes: sc1 (sno, cno, grade), c2 (cno, credit ). The new relationship includes two relational modes, which are connected by the external keyword cno in sc1. When necessary, they are naturally connected, restoring the original relationship.   3NF) All non-primary attributes in the relational mode R (U, F) do not have any dependency on any candidate keywords.   Example ---- S1 (SNO, SNAME, DNO, DNAME, LOCATION) Student ID name, Department name, Department address The SNO keyword determines the attributes. Because it is a single keyword, there is no part of the dependency problem, it must be 2NF. However, there must be a lot of redundancy in this relationship. The attributes DNO, DNAME, and LOCATION of the student will be stored, inserted, deleted, and modified repeatedly. Cause: A dependency is transmitted in the link. That is, SNO 1-> 1 DNO. However, DNO 1-> n SNO does not exist, while DNO-> LOCATION exists. Therefore, the key Liao SNO decides on the LOCATION function by passing the dependency SNO-> LOCATION. That is to say, SNO does not directly determine the non-primary attribute LOCATION. Solution: the transfer dependency cannot be left in each link mode. Solution: There are two relationships: S (SNO, SNAME, DNO), D (DNO, DNAME, LOCATION) Note: The outer keyword DNO cannot be found in link S. Otherwise, the two links are lost.   Bois-code Paradigm (BCNF) Based on 3NF, any field in the database table does not have a function dependency on any candidate keyword segment.   The Warehouse Management relation table is StorehouseManage (warehouse ID, storage item ID, administrator ID, quantity), and the Administrator 1--1 warehouse; the Warehouse 1 --- n items. This database table has the following decision relationships: (Repository ID, storage item ID) → (administrator ID, quantity) (Administrator ID, storage item ID) → (warehouse ID, quantity) Therefore, both (repository ID, storage item ID) and (administrator ID, storage item ID) are candidate Keywords of StorehouseManage, and the unique non-Keyword segments in the table are quantity, it conforms to the third paradigm. However, the following decision relationships exist: (Repository ID) → (administrator ID) (Administrator ID) → (repository ID) That is, the keyword segment determines the keyword segment, so it does not conform to the BCNF paradigm. Solution: Break down the warehouse management relationship table into two Relational Tables: Warehouse Management: StorehouseManage (warehouse ID, administrator ID) Repository: Storehouse (warehouse ID, storage item ID, quantity)