数据库系统设计

最新推荐文章于 2024-09-09 00:00:00 发布

黎先生你好

最新推荐文章于 2024-09-09 00:00:00 发布

阅读量3.9k

点赞数

分类专栏： Database

本文链接：https://blog.csdn.net/DlMmU/article/details/104603912

版权

Database 专栏收录该内容

15 篇文章 1 订阅

订阅专栏

1. 数据库理论

1.1 基础概念

数据依赖

函数依赖
多值依赖
连接依赖

关系模式

关系模式的形式化定义：R(U, D, DOM, F)

参数	描述
R	关系名
U	该关系的属性集合
D	属性组U中属性所来自的域
DOM	属性向域的映象集合
F	属性间数据的依赖关系集合

关系模式的简化表示：R<U, F>
将关系模式简化为一个三元组，影响数据库模式设计的主要是U和F。当且仅当U上的一个关系r满足F时，r称为关系模式R<U, F>的一个关系。

U = {Sno, Sdept, Mname, Cno, Grade} # 学生No，系名称，系主任，课程No，学生成绩
F = {Sno -> Sdept, Sdept -> Mname, (Sno, Cno) -> Grade)}
关系模式STUDENT<U, F>

1.2 规范化

1.2.1 函数依赖

设X,Y是关系R的两个属性集合，当任何时刻R中的任意两个元组中的X属性值相同时，则它们的Y属性值也相同，则称X函数决定Y，或Y函数依赖于X。记作 X -> Y。

上面一段话是某些教材上的话，比较不好理解。比如在设计学生表时，一个学生的学号能决定学生的姓名，也可称姓名属性依赖于学号，对于现实来说，就是如果知道一个学生的学号，就一定能知道学生的姓名，这种情况就是姓名依赖于学号，这就是函数依赖（Sno -> Sname）。函数依赖又分为非平凡依赖，平凡依赖；从性质上还可以分为完全函数依赖、部分函数依赖和传递函数依赖。

平凡函数依赖

定义：当关系中属性集合Y是属性集合X的子集时(Y⊆X)，存在函数依赖X→Y，即一组属性函数决定它的所有子集，这种函数依赖称为平凡函数依赖。对于任意关系模式，平凡函数依赖总是成立的。

例：
(Sno, Cno) -> Sno
(Sno, Cno) -> Cno

非平凡函数依赖

定义：当关系中属性集合Y不是属性集合X的子集时，存在函数依赖X→Y，则称这种函数依赖为非平凡函数依赖。

例：(Sno, Cno) -> Grade

完全函数依赖

设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。

例：(Sno, Cno) -F-> Grade

部分函数依赖

设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

例：(Sno, Cno) -P-> Sdept, 因为Sno --> Sdept

传递函数依赖

设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
Sno --> Sdept --> Mname, 所以Sno -传递-> Mname.

1.2.2 码

码是数据系统中的基本概念。所谓码就是能唯一标识实体的属性，他是整个实体集的性质，而不是单个实体的性质。它包括超码，候选码，主码。

超码

超码是一个或多个属性的集合，这些属性可以让我们在一个实体集中唯一地标识一个实体。如果K是一个超码，那么K的任意超集也是超码，也就是说如果K是超码，那么所有包含K的集合也是超码。

候选码

候选码是从超码中选出的，自然地候选码也是一个或多个属性的集合。因为超码的范围太广，很多是我们并不感兴趣即无用处的。所以候选码是最小超码，它们的任意真子集都不能成为超码。

例如，如果K是超码，那么所有包含K的集合都不能是候选码；如果K，J都不是超码，那么K和J组成的集合（K，J）有可能是候选码。如果候选码只有一个，那么候选码就是主码。虽然说主码的选择是比较随意的，但在实际开发中还是要靠一定的经验，不然开发出来的系统会出现很多问题。一般来说主码都应该选择那此从不或者极少变化的的属性。

例如：学生是一个实体，则学生的集合是一个实体集，而超码是用来在学生的集合中区分不同的学生。假设学生（实体）具有多个属性：学号，身份证号，姓名，性别。因为通过学号可以找到唯一一个学生，所以{学号}是一个超码，同理{学号,身份证号}、{学号,身份证号,姓名}、{学号,身份证号,姓名，性别}、{身份证号}、{身份证号，姓名}、{身份证号，姓名、性别}也是超码.在这里，因为不同的学生可能拥有相同的姓名，所以姓名不可以区别一个学生，既{姓名}不是一个超码，{性别}、{姓名、性别}也不是。

虽然超码可以唯一标识一个实体，但是可能大多数超码中含有多余的属性。所以我们需要候选码。

候选码：如果任意超码的真子集不能包括超码，则称其为候选码；超码包括候选码；

在上例中，只有{学号}、{身份证号}都是候选码；另外，如果性别和姓名可以唯一标识一个学生，则{姓名，性别}也为超码。

外码

如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码，也称为外键。外码的值要嘛为空，要嘛要为其对应的主码中的一个值

属性

简单来说，主属性是候选码属性的并集

非主属性

不包含在候选码中的属性称为非主属性。非主属性是相对于主属性来定义的。

总结：

名称	描述
码	数据表的一列、一个属性或者属性组；
超码	可以用来在实体集中标识唯一实体的集合。超码包括候选码；
主码	主键；被数据库设计者选中的，用来在同一实体集中区分不同实体的候选码。应该选择哪些从不或极少变化的属性；
外码	外键
候选码	数据表中能够标识出并唯一确定一行数据一个属性或者属性组；

1.2.3 范式

参考 https://blog.csdn.net/Dove_Knowledge/article/details/71434960

在设计与操作维护数据库时，最关键的问题就是要确保数据能够正确地分布到数据库的表中。使用正确的数据结构，不仅有助于对数据库进行相应的存取操作，还可以极大地简化应用程序中的其他内容(查询、窗体、报表、代码等)，按照“数据库规范化”对表进行设计，其目的就是减少数据库中的数据冗余，以增加数据的一致性。

泛化时在识别数据库中的一个数据元素、关系以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。常见的范式有1NF、2NF、3NF、BCNF以及4NF。下面对这几种常见的范式进行简要分析。

1NF(第一范式)

第一范式是指数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。第一范式的模式要求属性值不可再分裂成更小部分，即属性项不能是属性组合或是由一组属性构成。

简而言之，第一范式就是无重复的列。例如，由“职工号”“姓名”“电话号码”组成的表(一个人可能有一部办公电话和一部移动电话)，这时将其规范化为1NF可以将电话号码分为“办公电话”和“移动电话”两个属性，即职工(职工号，姓名，办公电话，移动电话)。不满足第一范式的数据库不是关系型数据库

2NF(第二范式)

第二范式(2NF)是在第一范式(1NF)的基础上建立起来的，即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。

如果关系模型R为第一范式，并且R中的每一个非主属性完全函数依赖于R的某个候选键，则称R为第二范式模式(如果A是关系模式R的候选键的一个属性，则称A是R的主属性，否则称A是R的非主属性)。

例如，在选课关系表(学号，课程号，成绩，学分)，关键字为组合关键字(学号，课程号)，但由于非主属性学分仅依赖于课程号，对关键字(学号，课程号)只是部分依赖，而不是完全依赖，因此此种方式会导致数据冗余以及更新异常等问题，解决办法是将其分为两个关系模式：学生表(学号，课程号，分数)和课程表(课程号，学分)，新关系通过学生表中的外码课程号联系，在需要时进行连接。

3NF(第三范式)

如果关系模型R是第二范式，且每个非主属性都不传递依赖于R的候选键，则称R是第三范式的模式。

以学生表(学号，姓名，课程号，成绩)为例，其中学生姓名无重名，所以该表有两个候选码(学号，课程号)和(姓名，课程号)，故存在函数依赖：学号——>姓名，(学号，课程号)——>成绩，唯一的非主属性成绩对码不存在部分依赖，也不存在传递依赖，所以属性属于第三范式。

BCNF(BC范式)

它构建在第三范式的基础上，如果关系模型R是第三范式，且每个属性都不传递依赖于R的候选键，那么称R为BCNF的模式。

假设仓库管理关系表(仓库号，存储物品号，管理员号，数量)，满足一个管理员只在一个仓库工作；一个仓库可以存储多种物品，则存在如下关系：

(仓库号，存储物品号)——>(管理员号，数量)

(管理员号，存储物品号)——>(仓库号，数量)

所以，(仓库号，存储物品号)和(管理员号，存储物品号)都是仓库管理关系表的候选码，表中唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库号)——>(管理员号)

(管理员号)——>(仓库号)

即存在关键字段决定关键字段的情况，因此其不符合BCNF。把仓库管理关系表分解为两个关系表仓库管理表(仓库号，管理员号)和仓库表(仓库号，存储物品号，数量)，这样这个数据库表是符合BCNF的，并消除了删除异常、插入异常和更新异常。

4NF(第四范式)

设R是一个关系模型，D是R上的多值依赖集合。如果D中存在凡多值依赖X->Y时，X必是R的超键，那么称R是第四范式的模式。

例如，职工表(职工编号，职工孩子姓名，职工选修课程)，在这个表中，同一个职工可能会有多个职工孩子姓名，同样，同一个职工也可能会有多个职工选修课程，即这里存在着多值事实，不符合第四范式。

如果要符合第四范式，只需要将上表分为两个表，使它们只有一个多值事实 。例如职工表一(职工编号，职工孩子姓名)，职工表二(职工编号，职工选修课程)，两个表都只有一个多值事实，所以符合第四范式。

拓展：各范式的关系图如下所示：
在这里插入图片描述

总结

范式	描述
1NF	数据库表中的每一列都是不可分割的基本数据项。
\|	消除非主属性对码的部分函数依赖
2NF	如果关系模型R是1NF, R中的每一个非主属性完全函数依赖于R的某个候选码
\|	消除非主属性对码的传递函数依赖
3NF	如果关系模型R是2NF，且每个非主属性都不传递依赖于R的候选键。即不存在非主属性函数依赖码。
\|	消除主属性对码的部分和传递函数依赖
BCNF	没有任何属性对码的部分函数依赖和传递函数依赖。不能存在关键字段决定关键字段的情况。每一个决定因素都包含码
\|	消除非平凡且非函数依赖的多值依赖
4NF	每个属性都不传递依赖于R的候选键