zoukankan      html  css  js  c++  java
  • 数据库范式

         在一张表上,只应用一条规则也是很困难的,所有范式规则的原则就是后一级规则必须符合前一级规则。换句话说,如果一个设计符合第二范式,就必然符合第一范式。

         第一范式--1NF

         范式的第一条规则规定

    • 表是二维的,包含行和列,每一行必须有相同的列数;
    • 表中的每个列都包含一个特性,列中的所有特性都必须有相同的类型;
    • 每一行必须可以唯一标识。

    要将平面数据转化到第一范式,需要利用数据库设计器创建另外一个表。重复的列要被删除,相关的数据要放在第二个表中,使每一行都是唯一的。这条规则,用于减少横向轴(列)上的冗余。

        第二范式--2NF

        这条规则规定,非键字段,不可依赖于主键的一部分,依赖于键值的字段要放到另一个表中。例如,如果一个表的主键,由两个列组成,行中的其他列都必须依赖这两个列,而不能只依赖其中一列。

       为了符合第二范式,必须先满足第一范式,然后找出与表主键有部分依赖关系的属性,放在另一个表中。

       在避免使用多列主键,或者删除部分依赖的列后,就达到了第二范式。然后就进入第三范式。

        第三范式--3NF

        第一条规则规定,行必须有键值,以便于区分。3NF在1NF的基础上进一步规定,任何行的唯一性都必须完全依赖于主键。第三范式是要减少纵轴(行)上的重复。

       Boyce-Codd范式,第4范式与第5范式

       Boyce和Codd构建了他们的标准--Boyce-Codd范式(BCNF)。这个范式是定义在前面讨论的理想情况上的。在符合后面的范式之前,必须先满足第一范式与第二范式,实际上,就是因为从第一范式到第二范式再到第三范式的改进过程中,催生了对BCNF的需要。通过对属性的函数依赖的分解,就在一些实体间,产生了多对多关系。有时这会不精确地留下这样一个状态:在所参与的实体中,有一个或多个实体有重复的候选键。

        非键属性所依赖的属性就是候选键。BCNF解决候选键内的依赖问题。第四范式和第五范式的冗长而复杂的数学理论一个简单版本就是:第四范式和第五范式用来解决多对多关系。

  • 相关阅读:
    前端工具Rythem介绍
    Redis持久化————AOF与RDB模式
    Hessian——轻量级远程调用方案
    JavaScript中的类数组对象
    在SpringMVC中获取request对象
    linux下,远程连接mysql
    nohup后台运行jar与关闭
    Vi常用命令
    spring mvc 重定向问题
    eclipse修改jdk后版本冲突问题
  • 原文地址:https://www.cnblogs.com/caofangsheng/p/5275896.html
Copyright © 2011-2022 走看看