数据库关系规范化模式设计

Posted on

概念

关系模式的五元组表示： R(U, D, DOM, F)

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

关系模式的简化三元组表示： R（U, F）

不好的数据库模式设计可鞥会导致如下问题：

  1. 数据冗余：浪费存储空间，引起异常。
  2. 操作异常：更新，删除，插入异常。

通常用模式分解的办法消除冗余和异常现象。但是注意，范式可能不是数据库的最佳实践；

函数依赖与数据依赖

什么是数据依赖？

  • 是现实世界属性间相互联系的抽象
  • 是数据内在的性质
  • 是语义的体现

数据依赖的类型

  • 函数依赖（Functional Dependency，简记为FD）
  • 多值依赖（Multivalued Dependency，简记为MVD）

函数依赖：

  • 属性（列）之间的联系
  • 属性之间在语义上的关联特性
  • 两个属性或属性集之间的约束

数据库设计者根据对关系R中的属性的语义理解确定函数依赖，确定约束R的所有元组r的函数依赖集，并获知属性间的语义关联。

平凡函数依赖：如果Y⊆X,显然X→Y成立；

  • 例如：{Dname,Pname}→{Pname}
  • 不反映新的语义；

完全函数依赖：

  • X、Y是某关系不同属性集；
  • 不存在X’⊂X,使得 X’→Y成立；

部分函数依赖：

  • X、Y是某关系不同属性集；
  • 存在X’⊂X,使得 x’→Y成立；

传递函数依赖

  • X、Y、Z是某关系不同属性集
  • 如果X→Y， Y→Z， X→Z且不存在Y → X；
  • 条件Y → X说明，X和Y不是一一对应；

候选码与主码：设$K$为$R(U,F)$ 中的属性或属性组合，若$K \xrightarrow{f} U$,则$K$为$R$​的候选码(Candidate Key)。若候选码多于一个，则选定其中的一个为主码(Primary Key)。

在一个学生表（Student）中，可能有以下列：学号（StudentID）、身份证号（IDNumber）、电子邮件（Email）。每一个列都可以单独作为候选码，因为它们都能够唯一地标识一个学生记录。如果选择学号（StudentID）作为主码，那么学号列将被用作唯一标识每一行学生记录的主键。

包含在任何候选码中的属性称为主属性（Prime Attribute）。不包含在任何候选码中的属性称为非主属性（Non-Key Attribute）。
最简单的情况，单个属性是码。最极端的情况，整个属性组是码，称为全码（All-key）

关系模式$R_l$中属性或属性组合$X$并非 $R_l$的码,但$X$是另一个关系模式 $R_2$的码,则称$X$是$R_l$的外码(Foreign Key)。

模式分解和规范化

函数依赖可能引起的更新异常问题
解决方法：“一事一地” ，对关系模式进行分解，使之表达的语义概念单纯化。
关系模式R的分解就是用两个或两个以上关系来替换R，分解后的关系模式的属性集都是R中属性的子集，其并集与R的属性集相同。
模式分解帮助消除不良设计中的一些问题，如冗余、不一致或异常。
模式分解的定义

设有关系模式 $R(U)$,属性集为$U$,若用一关系模式的集合${R_1(U_1),R_2(U_2),\cdots,R_k(U_k)}$来取代,其中$U=\bigcup_{i=1}^{k}U_{i}$则称此关系模式的集合为$R$的一个分解,以$\rho={R_{1},\cdots,R_{k}}$表示。

无损连接分解：通过连接被分解后的小表可以获得原始表的内容

范式（Normal Forma，NF）是一种关系的状态，是衡量关系模式的标准。
范式的种类（ 1NF，2NF，3NF，BCNF ）与数据依赖有着直接的联系
数据冗余浪费存储空间，导致数据库难以保持一致性。
范式确保数据库模式的一致性。
为确定特定关系是否符合范式，需要检查关系中属性间的函数依赖，而不是检查关系中的当前实例。
规范化主要作为验证和改进逻辑数据库设计的工具，使得逻辑设计能够：
满足特定约束
避免不必要的数据重复。
例如：就诊关系模式R（Dname，Dlevel，Dsal，Pname，Fsum）存在冗余信息（重复存储的职称和工资），不是一个好的设计

1NF

在关系模式R的每个关系r中，如果每个属性值都是不可再分的原子值，那么称R是第一范式（1NF）的模式。
满足1NF的关系称为规范化的关系；否则称为非规范化的关系。
关系数据库研究的关系都是规范化的关系。
1NF中不允许出现“表中有表”的现象。

image-20240618050126646

2NF

如果关系模式R∈1NF，且每个非主属性（不是组成候选码的属性）完全函数依赖于候选码，那么称R属于2NF的模式。
只有在主键是复合属性下才可能不符合2NF
2NF举例

  • 设有关系模式R（Dname，Pname，Dlevel，Dsal，Fsum)的属性分别表示医生编号、患者编号、医生职称级别、医生工资和诊疗费用。（Dname，Pname）是R的候选码。
  • 如果R上有两个FD：（ Dname ， Pname ）→（Dlevel，Dsal）和Dname →（Dlevel，Dsal），因此前面一个FD是局部依赖，所以R不是2NF。此时R会出现冗余和异常。例如，某个医生为N个病人看病，则在关系中会出现N个元组，而医生的职称级别和工资就会重复N次。
  • 如果将R分解为R1（ Dname ，Dlevel，Dsal）和R2（ Dname ， Pname ，Fsum）后，局部依赖（ Dname ， Pname ）→（Dlevel，Dsal）就消失了，R1和R2都是2NF了。

2NF分解算法：将关系模式R分解成2NF模式子集
设有关系模式R(U)，主键是W，R上还存在函数依赖X→Z，其中Z是非主属性和X ⊂ W，则W→Z就是一个局部依赖。此时应该把R分解成两个模式：
① R1（XZ），主键是X；
② R2（U-Z），主键仍为W，外键是X（参考R1）。
利用外键和主键的连接可以从R1和R2重新得到R。
如果R1和R2还不是2NF，则重复上述过程，一直到数据库模式中每一个关系模式都是2NF为止。

3NF

如果关系模式R∈1NF，且每个非主属性都不传递依赖于R的候选码，那么称R属于3NF的模式。
两个条件:
（1）R中的非主属性相互独立；
（2）R中的非主属性函数依赖于主键。
举例：

  • R2（ Dname ，Pname，Fsum）是2NF模式，而且也是3NF模式。
  • 但是R1（ Dname ，Dlevel，Dsal）是2NF模式，但不一定是3NF。因为如果R1中存在函数依赖Dname →Dlevel和Dlevel→Dsal，那么Dname→Dsal就是一个传递依赖，即R1不是3NF模式。
  • 此时R1的关系也会出现冗余和异常。例如，R2中存在M个职称同为主任级别的医生，则R1中需要重复存储M个相同的工资数目。
  • 如果将R1分解为R11（ Dname ，Dlevel）和R12（Dlevel，Dsal）后，Dname→Dsal就不会出现在R11和R12中，因此R11和R12都是3NF的模式。

BCNF

定义：如果关系模式R∈1NF，且每个属性都不传递依赖于R的候选码，那么称R是BCNF的模式。
原因： 3NF模式中，并未排除主属性对候选键的传递依赖
满足BCNF的关系模式有：

  • 所有非主属性对每一个码都是完全函数依赖。
  • 所有的主属性对每一个不包含它的码，也是完全函数依赖。
  • 没有任何属性完全函数依赖于非码的任何一组属性。

以下是一个例子：

关系模式R（Bno，Bname，Author）的属性分别表示书号、书名和作者名。假如每个书号只有一个书名，但不同的书号可以有相同的书名；每本书可以有多个作者合写，但每个作者参与编著的书名应该互不相同。

  • R上的FD如下：Bno→Bname和（Bname，Author）→Bno
  • 因此R的关键码是（Bno，Author）或（Bname，Author），因而模式R的属性都是主属性，R是3NF模式。
  • 但根据两个FD可知，属性Bname传递依赖于关键码（Bname，Author），因此R不是BCNF。
  • 例如，一本书由多个作者编写时，其书名与书号之间的联系在关系中将多次出现，会导致数据冗余和操作异常。
  • 如果将R分解为R1（Bno，Bname）和R2（Bno，Author），则能够解决上述问题，且R1和R2都是BCNF。
  • 但这样分解可能会导致新的问题，例如，这个分解把（Bname，Author）→Bno丢失了，数据语义将会引起新的矛盾。

BCNF分解算法：将R无损分解且保持依赖地分解成3NF模式集。
① 对于关系模式R和R上成立的FD集F，先求出F的最小依赖集，然后再把最小依赖集中那些左部相同的FD用合并性合并起来。
② 对最小依赖集中每个FD X→Y去构成一个模式(XY)。
③ 在构成的模式集中，如果每个模式都不包含R的候选码，那么把候选码作为一个模式放入模式集中。
举例：

  • 设关系模式R（ABCDE），R的最小依赖集为{A→B，C→D}。从依赖集可知R的候选码为ACE。
  • 先根据最小依赖集，可知ρ={AB,CD}。然后再加入由候选码组成的模式ACE。因此最后结果ρ={AB,CD,ACE}是一个3NF模式集，R相对于该依赖集是无损分解且保持函数依赖。

模式设计原则

满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的。
关系模式分解一般应具有3个特性：

  • 达到BCNF，或3NF；
  • 无损分解；
  • 保持函数依赖。

一个好的模式设计方法应符合3条原则：表达性、分离性和最小冗余性。

  • 表达性：数据等价和语义等价；即无损分解和保持依赖集
  • 分离性：关系中只存储有直接联系的属性值；清除冗余和异常现象
  • 最小冗余性：模式个数和模式中属性总数应最少；

image-20240618051626993

数据库有如下的设计方法：

  • 直观设计方法（手工试凑法）

    依赖于设计者的经验和技巧，设计质量难以保证。

  • 新奥尔良（New Orleans）设计方法

    运行软件工程的思想和方法，提出了数据库设计的规范 .新奥尔良法将数据库设计分成：需求分析、概念设计、逻辑设计和物理设计。

  • 基于实体-关系（E-R）模型的数据库设计方法

    在需求分析的基础上，用E-R图构造一个反映现实世界实体之间联系的企业模式转换成基于某一特定的DBMS的概念模式；

  • 3NF设计方法
    在需求分析的基础上，确定数据库模式中的全部属性和属性间的依赖关系，将它们组织在一个单一的关系模式中，然后再分析模式中不符合3NF的约束条件，将其进行投影分解，规范成若干个3NF关系模式的集合。
  • 面向对象的数据库设计方法 （ODL）
    使用面向对象的概念和术语来描述和完成数据库的结构设计，并可方便地转换为面向对象的数据库。
  • 用于数据库设计的计算机辅助软件工具(CASE)
    SYSBASE公司的PowerDesigner、Oracle公司的Design er2000、CA公司的ERWin、Rational公司的Rational Rose、Microsoft公司的Visio。