数据库三大范式另一角度的理解

1.第一范式

  在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 
      数据库表中的字段都是单一属性的,不可再分。

2.第二范式

  在第一范式的基础上。

  第二范式(2NF):数据库表不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有   关键字段都完全依赖于任意一组候选关键字。

    假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系: 
    (学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 

    这个数据库表不满足第二范式,因为存在如下决定关系: 
    (课程名称) → (学分) 
    (学号) → (姓名, 年龄) 
    即存在组合关键字中的字段决定非关键字的情况。 

  多对多的关系表内不要添加其中一张表的其他属性,如关联表user_org(uid,oid,uname,oname)内除了用户id,组织id外还添加了用户姓名,组织名称等属性。

3.第三范式

 在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。

假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话),关键字为单一关键字"学号",因为存在如下决定关系: 
    (学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话) 

    这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系: 
    (学号) → (所在学院) → (学院地点, 学院电话) 
    即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。

  一对多的数据库表设计时(一个组织有多人,一个人只属于一个组织)只保存组织的id,不保存组织的其他属性。如:user(id,name,age,oid),user内如果添加org_name,那么就不符合第三范式。

阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u014411966/article/details/52367303
上一篇linux常用命令
下一篇java环境配置
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭