关系数据库的规范化理论和数据库设计

最新推荐文章于 2024-09-02 20:25:29 发布

ole1

最新推荐文章于 2024-09-02 20:25:29 发布

阅读量2.4k

点赞数 3

分类专栏：未完成数据库

本文链接：https://blog.csdn.net/u011810467/article/details/84191309

版权

未完成同时被 2 个专栏收录

5 篇文章 0 订阅

订阅专栏

数据库

4 篇文章 0 订阅

订阅专栏

PS：涉及到关系代数部分，需要查阅离散数学知识。

概念设计：数据模型的设计（生成ER图）

逻辑设计：模型校验，设计规范化（生成关系表/二维表）

什么是不好的关系模式

函数依赖

数据依赖：在计算机科学中，数据依赖是指一种状态，当程序结构导致数据引用之前处理过的数据时的状态。其中最重要的是函数依赖和多值依赖。

函数依赖

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

理解方式2：某个属性集决定另一个属性集时，称另一属性集依赖于该属性集。 函数依赖是由数学派生的术语，它表征一个属性或属性集合的值对另一个属性或属性集合的值的依赖性。

函数依赖定义：

设R(U)是一个属性集U上的关系模式，X和Y是U的子集。

若对于R(U)的任意两个可能的关系r1、r2，若r1[x]=r2[x],则r1[y]=r2[y]，或者若r1[y]不等于r2[y],则r1[x]不等于r2[x]，称X决定Y，或者Y依赖X。

必要时再查阅：

平凡函数依赖

当关系中属性集合Y是属性集合X的子集时(Y⊆X)，存在函数依赖X→Y，即一组属性函数决定它的所有子集，这种函数依赖称为平凡函数依赖。

非平凡函数依赖

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

完全函数依赖

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

例子：学生基本信息表R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在R关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；

部分函数依赖

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

举个例子：学生基本信息表R中（学号，身份证号，姓名）当然学号属性取值是唯一的，在R关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖于（学号，身份证号）；

传递函数依赖

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

例子：在关系R(学号 ,宿舍, 费用)中，(学号)->(宿舍),宿舍！=学号，(宿舍)->(费用),费用!=宿舍，所以符合传递函数的要求；

函数依赖的蕴含逻辑

设R<U,F>是属性集U上的一个关系模式，X和Y都是U中属性组，若在R<U,F>在任何一个满足F中函数依赖的关系r上，都有函数依赖X->Y成立，称F逻辑蕴含X->Y。

码

如果函数依赖X->U在关系模式R(U)上成立，并且不存在X的任意真子集X‘，使得X'->U成立，那么称X是模式R的一个候选码/候选键，当候选码多于一个时，选定其中一个作为主码/主键。

R的属性一般分为两类，一类是键的属性，称为主属性；另一类是不属于任何键的属性，称为非主属性。

函数依赖的公理系统

设有关系模式R(U)，F是R上成立的FD（函数依赖）集，W、X、Y、Z是属性集U的子集，则有如下推理规则：

自反律：若 $Y \subseteq X \subseteq U$ ,则 $X \rightarrow Y$ 在R上成立
增广律：若 $X \rightarrow Y$ ，则 $WX \rightarrow WY$ 在R上成立
传递律：若 $X \rightarrow Y , Y \rightarrow Z$ ，则 $X \rightarrow Z$ 在R上成立
合并规则：若 $X \rightarrow Y , Y \rightarrow Z$ ，则 $X \rightarrow YZ$ 在R上成立
分解规则：若 $X \rightarrow Y$ ，且 $Z \subseteq Y$ ，则 $X \rightarrow Z$ 在R上成立
伪传递规则：若 $X \rightarrow Y , Y \rightarrow Z$ ，则 $WX \rightarrow Z$ 在R上成立

1NF、2NF、3NF、BCNF

范式：数据库设计的模式规范。

各范式定义/要求：

第一范式（1NF）：各属性值不可分解，关系模式的基本要求
第二范式（2NF）：消除部分依赖，（必须有一个主键，没有包含在主键的属性不能只依赖与主键的一部分；通过拆表实现）
第三范式（3NF）：消除传递依赖，（拆表实现）
Boyce-Codd范式（BCNF）：进一步消除传递依赖（包括消除主属性的传递依赖）

$1NF \supseteq 2NF \supseteq 3NF \supseteq BCNF \supseteq 4NF \supseteq 5NF$

以下转载自：https://blog.csdn.net/u014458048/article/details/56678698?utm_source=copy

1NF 一言以蔽之：“第一范式的数据表必须是二维数据表”，第一范式是指数据库的每一列都是不可分割的基本数据项，强调列的原子性，试题中某一属性不能拥有几个值。比如数据库的电话号码属性里面不可以有固定电话和移动电话值，如下图：
违反第一范式的示例

说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

2NF 第二范式建立在第一范式的基础上，即满足第二范式一定满足第一范式，第二范式要求数据表每一个实例或者行必须被唯一标识。除满足第一范式外还有两个条件，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。

每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。

举例来说：当数据表中是联合主键，但是有的列只依赖联合主键中的一个或一部分属性组成的联合主键，此时需要拆表才能复合第二范式。

3NF 若某一范式是第二范式，且每一个非主属性都不传递依赖于该范式的候选键，则称为第三范式，即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

举例来说：Employee(emp_id,emp_name,emp_age,dept_id,dept_name,dept_info)，当员工表中emp_id能够唯一确定员工员工信息，但是dept_name可由dept_id唯一确定，此时，该表不符合第三范式，此时可以删除除了dept_id之外的其他部门信息，把所有部门信息单独建立一张部门表。

BCNF 在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

（1）所有非主属性对每一个码都是完全函数依赖；
（2）所有的主属性对于每一个不包含它的码，也是完全函数依赖；
（3）没有任何属性完全函数依赖于非码的任意一个组合。

R属于3NF，不一定属于BCNF，如果R属于BCNF，一定属于3NF。

假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：

(仓库ID, 存储物品ID) →(管理员ID, 数量)

(管理员ID, 存储物品ID) → (仓库ID, 数量)

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

(仓库ID) → (管理员ID)

(管理员ID) → (仓库ID)

即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。

多值依赖和4NF（*未掌握）

多值依赖：多值依赖属4nf的定义范围，比函数依赖要复杂得多。在关系模式中，函数依赖不能表示属性值之间的一对多联系，这些属性之间有些虽然没有直接关系，但存在间接的关系，把没有直接联系、但有间接的联系称为多值依赖的数据依赖。在函数依赖中，X与Y是否存在函数依赖关系，只需考察X,Y的两组属性，与别的属性无关。

第四范式（4NF）：属性之间不允许有非平凡且非函数依赖的多值依赖。