ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 重提范式 -- 挑战设计

重提范式 -- 挑战设计

原创 Linux操作系统 作者:iSQlServer 时间:2009-10-22 06:50:02 0 删除 编辑

关系数据库的设计构筑在实体和关系的概念之上。一个实体一般依赖于一个“父”表。通常,对于正在描述的实体的每个实例,表中有且仅有一个行与之对应。然而一个实体或许需要多个其他表来提供额外的描述信息。关系是对两个实体相互之间如何逻辑相关的一种表达。

  从实践的观点看,有三种规范形式:

  1、第一范式(1NF)全部是为了消除重复的数据组以及保证原子性的。在较高水平上,第一范式是通过下面的步骤来实现的:创建主键,然后把所有重复的数据组移动到新的表中,并在新的表中创建新的键,依此类推。另外,为每一条数据准备好了所有的列,列中的数据组合形成单独的行。简而言之,第一范式就是无重复的列。

  2、第二范式(2NF)进一步减小重复数据的发生率(不必是组),要求数据库表中的每个实例或行必须可以被惟一地区分。这个惟一属性列被称为主关键字或主键、主码。第二范式有两条准则:

    a.表必须满足第一范式。(规范化是一种类似搭积木的过程----如果没有前两块,则无法叠放第三块。)

    b.每一列必须依赖于整个主键。

  第二范式要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是非主属性非部分依赖于主关键字。

  3、第三范式(2NF)涉及的问题是:使表中所有的列不仅依赖于某个事物,而且要依赖于正确的事物,就是要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。简言之,即属性不依赖于其它非主属性。第三范式有三条准则:

    a.表必须是满足第二范式的(前面说过这是一个类似搭积木的过程)。

    b.列不能与任何非主键列有依赖关系。

    c.不能有派生的数据。

  另外,至少在学术上,还有一些其他的形式是规范化模型的一部分。包括:

  1、Boyce-Codd(实际上被认为只是第三范式的变体)----该规范形式试图处理多个候选键有交叠的情况。这种情况只可能出现在:

    a.所有这些候选键都是组合键。(即,由一个以上的列组成的键)

    b.有不止一个候选键。

    c.每一个候选键至少有一列于另一个候选键一样。

  通常,这是一种有许多种可行的解决方案的情形,并且在学术之外基本不予考虑。

  2、第四范式(4NF)这种规范形式试图处理与多值依赖有关的问题。在这种情形中,对于每个单独的行,没有任何列依赖于主键之外的列;并且也没有任何列依赖于整个主键(满足第三范式)。然而这里可能出现相当古怪的情形,主键中的一个列能够单独依赖于主键中的其他列。

  3、第五范式(5NF)处理无损分解和有损分解的问题。本质上,必然存在这样的情形,在这里可以对关系进行分解,这样的分解不能够再重新组合回到其原先的形式。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/16436858/viewspace-617137/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-10-17

  • 博文量
    1319
  • 访问量
    2077797