【转载】关系型数据库设计范式

为了建立冗余较小、结构合理的关系数据库,设计关系数据库时必须遵循一定的规则, 即关系数据库的设计范式。

第一范式(First Normal Form, 1NF)

关系型数据库的第一范式要求:

  • 所有字段都是不可分割的

举例来说,客户数据表中包含客户名和地址,地址由城市和街道组成。应用经常需要分别访问城市或街道字段。

数据表customers(name,city, street)是符合第一范式的,而数据表customers(name,address)则不满足第一范式的要求。

定义一个满足第一范式的数据表:

courses(student_id, course_id, school_name, president, credit)
primary key(student_id, course_id)

上表仍然存在四个问题:

  • 数据冗余: school_name, president属性重复出现

  • 插入异常: 若一个新建school没有开始招生则不能加入数据表中

  • 删除异常: 若一学院所有学生均毕业,则该学院信息消失

  • 修改异常: 若一学院院长更换,则需修改该学院所有学生的数据;

若一学生转院则需修改其所选所有课程的数据。

第二范式(Second Normal Form, 2NF)

第二范式是在第一范式的基础上定义的,它要求:

  • 表的设计满足第一范式

  • 除主键外所有属性完全函数依赖于主键

候选码是函数决定所有非主属性的最小集合,但不排除候选码的真子集决定某些而非全部非主属性的情况.

而2NF禁止候选码的真子集函数决定任何非主属性.

如上文数据表:

courses(student_id, course_id, school_name, president, credit)
primary key(student_id, course_id)

school_name和president属性依赖于student_id属性,不依赖于course_id属性。

也就是说school,president属性部分函数依赖于主键,不满足第二范式的要求。

若将上表拆分为两个数据表:

courses(student_id, course_id, credit)
primary key(student_id, course_id)

students(student_id, school_name, president)
primary key(student_id)

拆分后的数据表满足了第二范式的要求。

现在分析一下,第一范式没有解决的四个问题:

  • 数据冗余: 减少了school_name和president重复出现的次数

  • 插入异常: 未解决

  • 删除异常: 未解决

  • 修改异常: 解决了学生转院的问题,未解决院长更换的问题

第三范式(Third Normal Form, 3NF)

第三范式定义在第二范式的基础上:

  • 表的设计满足第二范式的要求

  • 除非主属性直接依赖于主键

看上文数据表的定义

students(student_id, school_name, president)
primary key(student_id)

存在传递函数依赖student_id->school_name->president,不满足第三范式。

进行进一步拆分:

courses(student_id, course_id, credit)
primary key(student_id, course_id)

students(student_id, school_name)
primary key(student_id)

schools(school_name, president) primary key

拆分后消除了传递函数依赖。

分析第三范式对上述四个问题处理。

  • 数据冗余: 除了主键外所有属性只出现一次

  • 删除异常: 允许删除所有学生而保留学院信息

  • 插入异常: 允许建立没有学生的学院

  • 更新异常: 更换院长,学生转院均只需修改一条记录

第三范式基本上可以解决上述问题。

BCNF

BC(Boyce-Codd)范式在3NF的基础上进一步消除了传递依赖.

BCNF要求:

  • 关系模式符合3NF

  • 函数依赖集F中所有函数依赖X->F, 左部X必须包含R的所有候选码.

即所有候选码都直接决定所有非主属性.

BCNF分解算法

给定关系模式R和其上的函数依赖集F, 将R进行满足BCNF的无损连接分解:

  1. 置初值p = {R}

  2. 检查p中的关系模式若均满足BCNF则停止分解, 否则重复执行3.

  3. 在p中选出不满足BCNF的关系模式S, 其中必有非平凡依赖B->C, 且B不是S的候选码.将S分解为S1= {B,C}和S2 = R - {C}, 用S1,S2代替p中S的位置.

示例:

R = {A, B, C} F = {A->B, B->C}

候选码A, 函数依赖B->C, 因为B不是Candidate Key所以要进行分解:

{B, C} {A, B}

第四范式(Forth Normal Form, 4NF)

4NF要求:

  • 必须满足BCNF

  • 非主属性不能存在多值

示例:

phone(user_id,  phone, cell)

若某用户有多个phone同时又有多个cell时此表设计显然不合理.

可以采用如下的拆分方案:

phone(user_id, phone, type)

拆分后的数据表满足了4NF.

为了建立冗余较小、结构合理的关系数据库,设计关系数据库时必须遵循一定的规则, 即关系数据库的设计范式。

第一范式(First Normal Form, 1NF)

关系型数据库的第一范式要求:

  • 所有字段都是不可分割的

举例来说,客户数据表中包含客户名和地址,地址由城市和街道组成。应用经常需要分别访问城市或街道字段。

数据表customers(name,city, street)是符合第一范式的,而数据表customers(name,address)则不满足第一范式的要求。

定义一个满足第一范式的数据表:

courses(student_id, course_id, school_name, president, credit)
primary key(student_id, course_id)

上表仍然存在四个问题:

  • 数据冗余: school_name, president属性重复出现

  • 插入异常: 若一个新建school没有开始招生则不能加入数据表中

  • 删除异常: 若一学院所有学生均毕业,则该学院信息消失

  • 修改异常: 若一学院院长更换,则需修改该学院所有学生的数据;

若一学生转院则需修改其所选所有课程的数据。

第二范式(Second Normal Form, 2NF)

第二范式是在第一范式的基础上定义的,它要求:

  • 表的设计满足第一范式

  • 除主键外所有属性完全函数依赖于主键

候选码是函数决定所有非主属性的最小集合,但不排除候选码的真子集决定某些而非全部非主属性的情况.

而2NF禁止候选码的真子集函数决定任何非主属性.

如上文数据表:

courses(student_id, course_id, school_name, president, credit)
primary key(student_id, course_id)

school_name和president属性依赖于student_id属性,不依赖于course_id属性。

也就是说school,president属性部分函数依赖于主键,不满足第二范式的要求。

若将上表拆分为两个数据表:

courses(student_id, course_id, credit)
primary key(student_id, course_id)

students(student_id, school_name, president)
primary key(student_id)

拆分后的数据表满足了第二范式的要求。

现在分析一下,第一范式没有解决的四个问题:

  • 数据冗余: 减少了school_name和president重复出现的次数

  • 插入异常: 未解决

  • 删除异常: 未解决

  • 修改异常: 解决了学生转院的问题,未解决院长更换的问题

第三范式(Third Normal Form, 3NF)

第三范式定义在第二范式的基础上:

  • 表的设计满足第二范式的要求

  • 除非主属性直接依赖于主键

看上文数据表的定义

students(student_id, school_name, president)
primary key(student_id)

存在传递函数依赖student_id->school_name->president,不满足第三范式。

进行进一步拆分:

courses(student_id, course_id, credit)
primary key(student_id, course_id)

students(student_id, school_name)
primary key(student_id)

schools(school_name, president) primary key

拆分后消除了传递函数依赖。

分析第三范式对上述四个问题处理。

  • 数据冗余: 除了主键外所有属性只出现一次

  • 删除异常: 允许删除所有学生而保留学院信息

  • 插入异常: 允许建立没有学生的学院

  • 更新异常: 更换院长,学生转院均只需修改一条记录

第三范式基本上可以解决上述问题。

BCNF

BC(Boyce-Codd)范式在3NF的基础上进一步消除了传递依赖.

BCNF要求:

  • 关系模式符合3NF

  • 函数依赖集F中所有函数依赖X->F, 左部X必须包含R的所有候选码.

即所有候选码都直接决定所有非主属性.

BCNF分解算法

给定关系模式R和其上的函数依赖集F, 将R进行满足BCNF的无损连接分解:

  1. 置初值p = {R}

  2. 检查p中的关系模式若均满足BCNF则停止分解, 否则重复执行3.

  3. 在p中选出不满足BCNF的关系模式S, 其中必有非平凡依赖B->C, 且B不是S的候选码.将S分解为S1= {B,C}和S2 = R - {C}, 用S1,S2代替p中S的位置.

示例:

R = {A, B, C} F = {A->B, B->C}

候选码A, 函数依赖B->C, 因为B不是Candidate Key所以要进行分解:

{B, C} {A, B}

第四范式(Forth Normal Form, 4NF)

4NF要求:

  • 必须满足BCNF

  • 非主属性不能存在多值

示例:

phone(user_id,  phone, cell)

若某用户有多个phone同时又有多个cell时此表设计显然不合理.

可以采用如下的拆分方案:

phone(user_id, phone, type)

拆分后的数据表满足了4NF.

猜你喜欢

转载自www.cnblogs.com/ralap7/p/9029359.html