简明现代魔法 -> 数据库技术 -> 数据库范式理解

数据库范式理解

2010-04-03

当前我们使用的主流数据库是关系型数据库,所以我是记录在关系型数据库中对范式的一些理解和看法。数据库库范式分为六种(其实还有有一个BCNF),分别为从第一范式到第六范式。高级一层是建立在所有低层的基础上的,如第2范式是建立在第一范式的基础上的,依次类推。下面分别举例讲解各种范式:

  1. 第一范式(1NF)
  2. 第一范式的核心描述为:数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值。该范式讲的是列的原子性。有两层意思:一层是说每一列只能存一个属性值(如果把2个属性值存在1列中)。第二层说的是在一张表中属性值不能重复。在现代关系行数据库中,都是默认满足第一范式的,所以你想要写出不满足第一范式的结构来还是不可能的事情,所以第一范式就不再多说。如果想深入,可以研究下其他非关系型的数据库的情况。

  3. 第二范式(2NF)
  4. 第二范式的核心描述为:行有唯一的主键,非主键仅对主键依赖。有2层意思,第一层,每一行都要有主键(单独信息或组合信息),这个容易理解。第二层意思是非主键对主键依赖,如果是复合主键的情况,非主键属性不能依赖于部分主键属性。如 【产品,仓库号,数量,仓库地址,仓库管理员】,这里(产品+仓库号)为复合主键,而仓库地址和仓库管理员依赖于仓库号,这就是上面描述的“主键属性不能依赖于部分主键属性”,因此这是违背第二范式的,符合范式的设计应该为:【产品,仓库号,数量】,【仓库号,仓库地址,仓库管理员】。

  5. 第三范式(3NF)
  6. 第三范式的核心描述为:非主键属性互不依赖。这个很容易理解,直接上例子:【学生编号,姓名,系编号,系办公地点,系办公电话】,这里学生编号是主键。然后这里的非主键属性系编号->系办公室+系办公电话,这里应该把该表拆成2个表,然后外键相连。符合范式的设计应该为:【学生编号,姓名,系编号】和【系编号,系办公地点,系办公电话】。

    BC范式(BCNF), 是两个叫 Raymond F. Boyce 和 Edgar F. Codd 的总结出来的,取他们的姓拼成范式名。BC 范式是第三范式的加强版。

  7. 第四范式(4NF)
  8. 第四范式的核心描述为:不允许冗余的多对多关系。这个范式的核心思想也是节省数据库空间。举例来说,【员工,技能,语言】,一个员工能拥有多项技能和多种语言能力,而同一技能或语言可以有多个员工掌握。在这种情况下,依据第四范式,我们应该把表单设计成【员工,技能】+【员工,语言】。在存储时,我们能节省一些空间,但是在操作时,join 往往带来更多的系统开支。

  9. 第五范式(5NF)
  10. 第五范式指在可能的前提下继续打碎数据表。这个范式和第四范式的思想是相同的,希望消除冗余,在可能的情况下,继续打碎信息。例如上面的例子,一个三列的表,如果表的各列是两两之间多对多的关系,则按照第五范式的思想,应该建立三张表,每张表有之前表的两列信息。

  11. 第六范式(6NF)
  12. 第六范式已经挺极端了,按文献的说法,只有数据量大到数据仓储级别,才有使用的必要。貌似是仔细设计表单的依赖关系和 join 关系的,就不仔细研究下去了。

在做数据库设计的时候,满足范式要求的数据库设计是结构清晰的,同时可避免数据冗余和操作异常。一般情况下满足第二和第三范式就OK(第一范式是默认满足的),这并意味着不符合范式要求的设计一定是错误的,这种较特殊的情况下,不符合范式要求反而是合理的。

随机文章推荐
网站分类


注:如需转载本文,请注明出处(原文链接),谢谢。更多精彩内容,请进入简明现代魔法首页。

进入新博客
喜欢本文,就分享它吧
给我留言
您的名字:
您的邮件:
您的网站:


 

copyright © 2009 简明现代魔法    学习、分享、进步

power by Gonn 感谢所有关心和支持本站的朋友们