bar*_*oon 269 database database-design database-normalization
在关系数据库设计中,存在数据库规范化或简单规范化的概念,其是组织列(属性)和表(关系)以减少数据冗余和改善数据完整性的过程.(如维基百科上所写).
由于大多数文章都是技术性的,因此难以理解,我要求有人根据1NF,2NF,3NF甚至3.5NF(Boyce-Codd)的含义的例子写出一个更容易理解的解释.
Sma*_*ery 426
1NF是最基本的普通形式 - 表中的每个单元格必须只包含一条信息,并且不能有重复的行.
2NF和3NF都是关于依赖主键的.回想一下,主键可以由多列组成.克里斯在回答中说:
数据取决于密钥[1NF],整个密钥[2NF],只有密钥[3NF](所以帮助我Codd).
假设您有一个包含某个学期课程的表格,并且您拥有以下数据:
|-----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是ENTIRE键.
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.因此,每个额外的范式要求一切,下部正常形态了,再加上一些额外的条件,必须全部满足.
Chr*_*fer 116
我从来没有对确切的措辞有好记,但在我的数据库课中,我认为教授总是这样说:
数据取决于密钥[1NF],整个密钥[2NF],只有密钥[3NF].
Dav*_*kle 44
这是一个快速的,公认的被宰杀的回应,但在一句话中:
1NF:你的表被组织成一个无序集的数据,并且没有重复列.
2NF:由于另一列,您不会在表的一列中重复数据.
3NF:表中的每一列只与表的键相关 - 表中没有列描述表中不是键的另一列.
有关更多详细信息,请参阅维基百科...