数据库设计 — 范式

一、数据规范化

  1、范式

    好的数据库设计对数据的存储性能和后期的程序开发,都产生重要的影响。

    建立规范的数据库就需要满足一些规则来优化数据的设计和存储,这些规则就称为范式

    设置关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。

  2、三大范式

    目前关系数据库有六种范式:第一范式(1NF)、第二范式(1NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。

    满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式依次类推。一般来说,数据库值需要第三范式(3NF)就行了。

二、第一范式(1NF)

  1、概念

    数据库表的每一列都是不可分割的原子数据项,不能是集合、数组等非原子数据项。

    即表中的某个列有多个值时,必须拆分为不同的列。

    IN A WORD:第一范式每一列不可再拆分,称为原子性。

  2、案例

学号 姓名 班级
1 张三 一年三班
2 李四 一年二级
3 王五 二年三班

 

三、第二范式(2NF)

  1、概念

    在满足第一范式的前提下,表中的每一个字段都完全依赖于主键。(非码属性必须完全依赖于码,即消除非主属性对主码的部分函数依赖)

    所谓完全依赖是指不能存在仅依赖主键一部分的列。简而言之,第二范式就是在第一范式的基础上所有列完全依赖于主键列。

    当存在一个复合主键包含多个主键列的时候,才会发生不符合第二范式的情况。

    例如:有一个表中的主键有两个列,不能存在这样的数学,它只依赖于其中一个列,这时就不符合第二范式。

  2、常用概念

    ① 函数依赖:A-->B,如果通过A属性(属性组)的值,可以确定唯一B属性的值。则称B依赖于A。例如:学号-->姓名

    ② 完全函数依赖:A-->B,如果A是一个属性组,则B属性值的确定需要依赖于A属性组中所有的属性值。例如:(学号,课程名称)-->分数

    ③ 部分函数依赖:A-->B,如果A是一个属性组,则B属性值的确定只需要依赖于A属性组中某一些值即可。例如:(学号,课程名称) -- > 姓名

    ④ 传递函数依赖:A-->B,B-->C.如果通过A属性(属性组)的值,可以确定唯一B属性的值,在通过B属性(属性组)的值可以确定唯一C属性的值,则称 C 传递函数依赖于A。例如:学号-->系名,系名-->系主任。

    ⑤ :如果在一张表中,一个属性或属性组,被其他所有属性所完全依赖,则称这个属性(属性组)为该表的码。

      •  主属性:码属性组中的所有属性
      •    非住属性:除过码属性组的属性

  3、特点

    ① 一张表只描述一件事情

    ② 表中的每一列都完全依赖于主键

  4、案例

    ① 借书证表

学生证号 学生证名称 学生证办理时间 借书证号 借书证名称 借书证办理时间

    ② 分成两张表

学生证号 学生证名称 学生证办理时间
借书证号 借书证名称 借书证办理时间

四、第三范式(3NF)

  1、概念

     在满足第二范式的前提下,表中的每一列都直接依赖于主键,而不是通过其它的列来间接依赖于主键(在2NF基础上消除传递依赖)。

     简而言之,第三范式就是所有列不依赖于其它非主键列,就是在满足第二范式的基础上,任何非主列不得传递依赖于主键。

     所谓传递依赖,指的是如果存在“A—>B—>C”的决定关系,则 C 传递依赖于 A。因为,满足第三范式的数据库表不应该存在依赖关系。

  2、案例

    学生信息表

学号 姓名 年龄 所在学院 学院地点

     存在传递的决定关系:

      学号 —> 所在学院 —> 学院地点

    拆分为两张表

学号 姓名 年龄 所在学院的编号(外键)
学院编号 所在学院 学院地点

 

五、三大范式小结

范式 特点
1NF 原子性:表中每列不可再拆分。
2NF 不产生局部依赖,一张表只描述一件事情
3NF 不产生传递依赖,表中每一列都直接依赖于主键。而不是通过其它列间接依赖于主键。

猜你喜欢

转载自www.cnblogs.com/niujifei/p/11586650.html