在关系数据库设计中,有一个数据库归一化或简单归一化的概念,这是一个组织列(属性)和表(关系)以减少数据冗余和提高数据完整性的过程。(写在维基百科上)。
由于大多数文章都是技术性的,因此很难理解,我要求有人根据1NF, 2NF, 3NF,甚至3.5NF (Boyce-Codd)的意思写一个更容易理解的解释。
我从来没有一个很好的记忆准确的措辞,但在我的数据库课上,我想教授总是这样说:
数据依赖于密钥[1NF],整个密钥[2NF]和密钥[3NF]。
这里是一个快速的,无可否认的屠宰回应,但在一句话中:
1NF:你的表被组织为无序的集数据,并且没有重复的列。
2NF:你不会因为另一列而重复表中某一列的数据。
3NF:你的表中的每一列都只与你的表的键相关——你不会让一个表中的列描述你的表中的另一个不是键的列。
要了解更多细节,请参阅维基百科。
1NF是最基本的标准表单——表中的每个单元格必须只包含一条信息,并且不能有重复的行。
2NF和3NF都依赖于主键。回想一下,一个主键可以由多个列组成。正如克里斯在他的回答中所说:
数据依赖于键[1NF],整个键[2NF]和除键[3NF]以外的任何东西(所以帮助我科德)。
假设您有一个表,其中包含某个学期的课程,并且您有以下数据:
|-----Primary Key----| uh oh | V CourseID | SemesterID | #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 |
这是非2NF,因为第四列不依赖于整个键——而只是它的一部分。课程名称依赖于课程的ID,但与所选学期无关。因此,如您所见,我们有重复的信息——几行告诉我们IT101正在编程,而IT102是数据库。因此,我们通过将课程名称移动到另一个表中来解决这个问题,其中CourseID是whole键。
Primary Key | CourseID | Course Name | ---------------------------| IT101 | Programming | IT102 | Databases | IT103 | Web Design |
没有冗余!
好的,假设我们还添加了课程老师的名字,以及他们的一些细节,到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 |
现在应该很明显了,TeacherName依赖于TeacherID——所以这是不在3NF中。为了解决这个问题,我们做了与在2NF中所做的大致相同的事情——从这个表中取出TeacherName字段,并将其放在自己的表中,其中以TeacherID为键。
Primary Key | TeacherID | TeacherName | ---------------------------| 332 | Mr Jones | 495 | Mr Bentley | 242 | Mrs Smith |
要记住的一件重要的事情是,如果某样东西不在1NF中,那么它也不在2NF或3NF中。因此,每一个额外的标准形式都需要较低标准形式所具有的一切,加上一些额外的条件,这些条件必须所有被满足。
1NF:每列只有一个值
2NF:表中的所有非主键列都应该依赖于整个主键。
3NF:表中的所有非主键列都应该直接依赖于整个主键。
我已经写了一篇关于在这里的更详细的文章