关系数据库设计, since 2022-01-02

(2021.01.02 Sun)

概念

• 函数依赖(functional dependency, FD): 如果关系R的两个元组(即两行数据)在属性A₁, A₂, ..., A_n上一致，即它们对应于这些属性的分量值都相等，那么它们必定在其他属性B₁, B₂, ..., B_m上也一致。该函数的依赖形式记为，并称为“A₁, A₂, ..., A_n函数决定B₁, B₂, ..., B_m”。通常，FD的右边可能是单属性。一个函数依赖等价于一组FD:
  
  
  
  

• 键key: 如果下列条件满足，就认为一个或多个属性集是关系R的键。

1. 这些属性函数决定关系的所有其他属性。或，关系R不可能存在两个不同的元组，他们具有相同的值。
2. 在的真子集中，没有一个能函数决定R的所有其他属性。或，键必须是最小的(minimal)。
   当键只包括一个单独的属性A时，称A(而不是{A})是键。

• 超键superkey: 一个包含键的属性集叫做超键(superkey)，它是键的超集的简写。因此每个键都是超键。然而某些超键不是(最小化的)键。每个超键都满足键的第一个条件，即它函数决定了关系中所有其他属性。但超键不需要满足第二个条件，即最小化。
  超键有时被称为键。而对最小化的键，也就是这里的键，有时被称为候选键candidate key。

• 异常(anomaly): 当试图在一个关系中包含过多信息时，产生的问题(如冗余)称为异常anomaly。异常的基本类型有

1. 冗余(redundancy)。信息没有必要的在多个元组中重复。
2. 异常更新(update anomaly)。可能修改了某个元组的信息，但是没有改变其他元组中的相同信息。
3. 删除异常(delete anomaly)。如果一个值变成空集，就可能带来丢失信息的副作用。

函数依赖的规则

假设已经知道关系满足一些FD集合。通常从这些已知FD中还能推导出这个关系上必定存在的其他FD。发现其他FD的能力，对于讨论怎样设计一个好的关系模式很有必要。

如果关系R中的属性Y是FD属性X的，则满足以下两个条件

1. 属性Y函数依赖于属性X
2. 属性Y不函数依赖于属性X的任一个真子集X'。

如果属性Y值函数依赖于属性X的某一个真子集X'，则称属性Y局部依赖于属性X。

如果关系中的主键是单属性的，则非键属性对主键肯定都是完全函数依赖的。当关系中的主键是复合属性时，则非键属性对主键的函数依赖就有完全与部分两种可能。

在关系R中，若，()，，，则称Z传递依赖于X。

关系数据库的设计流程

(2022.01.03 Mon)

数据库设计一般步骤.jpg

• 系统分析：按照提出的设计任务收集相关的数据和确定数据处理的流程，并分析各业务的输入数据、输出数据、各类数据的使用频度及各部门之间交换数据的数量和处理功能与要求。最后应整理出“需求说明书”，作为以后各阶段工作的基础。
  *概念设计：根据需求说明书，进一步细致了解各业务处理过程中数据的名称、类型、长度、数量、取值范围，使用一种能为大多数人理解的形式描述所需数据库的逻辑结构，并与任何计算机硬件、软件无关，即所谓概念结构说明。比较常用的是实体-关系图描述(E-R图)。
• 逻辑设计：目标是产生一个具体的DBMS可以处理的模式。这个模式能够满足全部用户的要求。前述E-R图可以转换成任何类型的数据库模式。当吧E-R图转换成关系模式(data schema?)时，要把其中所有实体型转换成关系模式，并把所有联系带上相连实体型的主关键字后也转换成关系模式。同时，可应用关系的规范化理论，选择性能好的关系模式。
  这一阶段还要同时对应用程序进行逻辑设计，即对每个处理程序给出数据存储的方法及程序结构及各模式间的接口。
• 物理设计：主要确定数据库的存储记录格式、索引组成、空间大小估算等。同步开发应用程序。
• 数据库的实现和维护：在具体的硬软件平台上建立数据库的结构，装入数据；完成应用程序并上机调试运行；在运行过程中评价库结构的合理性、存储效率、处理效率和应用程序的功能等；根据需要调整、修改和维护数据库。

关系数据库设计的基本步骤

1. 研究初始的模式设计存在的问题
2. 引入“分解”思想，把一个初始关系模式(若干属性的集合)分解为两个(或多个)较小的模式
3. 引入“Boyce-Codd范式”(Boyce-Codd Normalisation Format, BCNF)，消除上述问题
4. 当解释怎样通过分解关系模式来确保BCNF条件时，把上面的几点结合起来。

分解关系(decompose)

一般用分解关系的方法来消除异常。关系R的分解设计分离R的属性，以构造两个新的关系模式。

给定一个关系，把它分解为和，并且满足：

这里的是投影(projection)。投影操作用来从关系R生成一个新关系，这个关系只包含原来关系R中的不分裂，而只包含关系R属性所代表的的列。

关系数据库的规范化处理

在关系数据库的设计过程中，初始的关系模式通常需要改进，尤其在消除冗余方面。一般来说，冗余等问题是由于模式试图将过多的内容合并到一个关系中而造成的。我们使用异常(anomaly)来指代这些问题。

使用函数依赖(functional dependency)这一概念来定义关系模式的规范形式，称为规范化(normalisation)。规范化的影响在于可以将关系分解(decompose)为两个或多个关系以消除异常。多值依赖(multivalued dependency)，直观的表示了一个条件：关系的一个或多个属性独立于其他若干个属性。这些依赖也可以导致关系的规范构造和分解，以消除冗余。

关系的第一、二、三范式

• 第一范式(1NF)：所有符合关系定义的关系都称为规范关系，即第一范式，记为1NF。表中的每一列都是不可拆分的最小单元，保证每个属性的原子性。
  为了与规范关系相区别，有时也把某些属性有重复组或空白值的二维表称为非规范关系。非规范关系可转变为规范关系。比如把空白值用特殊符号标记，也可以在值空白时将表拆开。
  一个1NF关系可能是个结构不太好的关系，可能存在如下问题：
  • 数据冗余大，记录重复
  • 修改异常，由于数据冗余大，难免疏漏
  • 插入一场，
  • 删除异常
• 第二范式2NF：若关系，且每个非主属性均完全函数依赖于主键，则称关系R是第二范式的，即。也就是表中所有列必须依赖于主键，不能有任何一列与主键没有关系。2NF存在的问题和1NF相似。
• 第三范式3NF：若有关系，且关系中的每个非主属性均不传递依赖于主键，则称关系R是第三范式的，即。也就是属性于主键直接相关而非间接相关，或表中每一列只依赖于主键。要求一个表中不包含已包含在其他表中的非主键属性。
  3NF由于消除可能存在的部分函数依赖和传递函数依赖，因而具有较好的性能。但是，3NF中没有限制某些主属性对主键之间的函数依赖，故又提出了BCNF范式，作为对3NF的修正。

BCNF范式

定义：当且仅当关系R中每个决定因素都是候选键时，则称关系R是Boyce-Codd范式，即。
所谓决定因素，是关系模式中的一个属性或属性集，其他某些属性或属性集完全函数依赖于它。
一个BCNF关系必定是3NF的，但是一个3NF的关系未必是BCNF的。

重复选择使用适当的分解，可以把任何一个关系模式分解为带有下列重要性质的具有多个属性的子集：

1. 以这些子集为模式的关系都属于BCNF
2. 原始关系中的数据都被正确的反映在分解后的关系上，或，原始关系应该能从分解后的几个关系实例中重构。

Reference

1 匙彦斌等主编，计算机软件技术基础教程，天津大学出版社
2 Jeffery U.等著，岳丽华等译，数据库系统基础教程，机械工业出版社