設計關係數據庫時，遵從不同的規範要求，設計出合理的關係型數據庫，這些不同的規範要求被稱爲不同的範式，各種範式呈遞次規範，越高的範式數據庫冗餘越小。
固然範式可以避免數據冗餘，減少數據庫的空間，減輕維護數據完整性的麻煩，但是操作困難，因爲需要聯繫多個表才能得到所需要數據，而且範式越高性能就會越差。要權衡是否使用更高範式是比較麻煩的，一般在項目中，用得最多的也就是第三範式，性能好而且方便管理數據。
First normal form
First normal form (1NF) means that a table has no multivalued attributes or composite attributes. (A composite attribute contains other attributes and can therefore be divided
into smaller parts.) All relational tables are by definition in 1NF, because the value of any column in a row must beatomic—that is, single valued.
Second Normal Form
A table is in second normal form (2NF) if it is in 1NF and there is no nonkey column dependent on a partial primary key of that table. This means if (A,B) is a combination of two table columns building the key of the new table, then there is no column of the table depending either on only A or only B.
Say you have a table containing courses that are taken in a certain semester, and you have the following data:
|-----Primary Key----| uh oh |
V
CourseID| Semester | #Places | Course Name |
-------------------------------------------------|
IT101 | 2009-1 | 100 | Programming |
IT101 | 2009-2 | 100 | Programming |
IT102 | 2009-1 | 200 | Databases |
IT102 | 2010-1 | 150 | Databases |
IT103 | 2009-2 | 120 | Web Design |
This is not in 2NF, because the fourth column does not rely upon theentire key - but only a part of it. The course name is dependent on the Course's ID, but has nothing to do with which semester it's taken in. Thus, as you can see, we have duplicate information - several rows telling us that IT101 is programming, and IT102 is Databases. So we fix that by putting the course name into another table, where CourseID is the ENTIRE key.
Primary Key |
CourseID | Course Name |
---------------------------|
IT101 | Programming |
IT102 | Databases |
IT103 | Web Design |
No redundancy!
Third Normal Form
A table is in third normal form (3NF) if it is in 2NF and there are no functional dependencies between nonkey columns.
第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個關係中不包含已在其它關係已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性，也就是在滿足2NF的基礎上，任何非主屬性不得傳遞依賴於主屬性。
Okay, so let's say we also add the name of the teacher of the course, and some details about them, into the RDBMS:
|-----Primary Key----| uh oh |
V
Course | Semester | #Places | TeacherID | TeacherName |
---------------------------------------------------------------|
IT101 | 2009-1 | 100 | 332 | Mr Jones |
IT101 | 2009-2 | 100 | 332 | Mr Jones |
IT102 | 2009-1 | 200 | 495 | Mr Bentley |
IT102 | 2010-1 | 150 | 332 | Mr Jones |
IT103 | 2009-2 | 120 | 242 | Mrs Smith |
Now it should be obvious that TeacherName is dependent on TeacherID - so this isnot in 3NF. To fix this, we do much the same as we did in 2NF - take TeacherName out of this table, and put it in its own, which has TeacherID as the key.
Primary Key |
TeacherID | TeacherName |
---------------------------|
332 | Mr Jones |
495 | Mr Bentley |
242 | Mrs Smith |
No redundancy!!
One important thing to remember is that if something is not in 1NF, it is not in 2NF or 3NF either.
簡單的說，
第一範式就是原子性，字段不可再分割也即表內每個記錄中每個列的值只有有唯一值；
第二範式就是完全依賴，沒有部分依賴也即非主屬性只允許完全依賴於主屬性；
第三範式就是沒有傳遞依賴，也即除了要滿足第二範式外，非主屬性間不允許存在依賴關係。
