数据库管理系统——数据库设计

摘要：本博客讲解了数据库管理系统中的数据库设计相关内容，包括概念结构设计：E-R模型，逻辑结构设计：E-R模型到关系设计等内容。

目录

一、数据库设计和数据模型

1.1.数据库设计概述

1. 2.数据库结构概述

1.3.数据库的设计过程

二、概念结构设计：E-R模型

2.1.E-R模型概述

2.2.E-R模型的基本元素

2.3.E-R图

2.4.E-R联系类型

三、逻辑结构设计：从E-R图到关系设计

四、规范化设计理论

4.1函数依赖理论

4.2规范化设计和范式

4.3数据依赖的公理系统

在前面几小结中，我们学习和数据库相关的概念，以及数据库的结构化查询语言，下面我们将学习数据库的数据库设计，学习怎样设计好一个数据库。

一、数据库设计和数据模型

1.1.数据库设计概述

• 数据库是组织、存储和管理数据的集合
• 数据库设计会直接影响数据库自身和上层应用的性能，一个好的数据库设计可以提高存储空间的利用率和数据存取的效率，可以更好地支持基于数据库的应用系统
• 在数据库领域，数据模型被广泛用于表示这些数据库设计的“描述”，更好的刻画数据。

1. 2.数据库结构概述

数据库结构的基础是数据模型，它是描述数据(数据结构)、数据之间的联系，数据语义即数据操作，以及一致性(完整性)约束的概念和工具的集合。

1.3.数据库的设计过程

 数据库的设计的三个设计阶段：概念设计阶段、逻辑设计阶段和物理设计阶段。

• 概念数据模型：

        将现实世界的客观事物及其关系抽象为“实体”和“关系”等形式，用于描述业务领域的数据对象及其关系。概念数据模型主要是依据用户对现实业务的理解来对数据对象进行建模，主要用于数据库的概念设计。

• 逻辑数据模型：

        在概念数据模型的基础上，需要进一步考虑这些数据对象在计算机系统中的逻辑表示，主要用于数据库管理系统的逻辑设计。常见的逻辑数据模型有关系模型、层次模型和网状模型等。

• 物理数据模型：

        把逻辑模型转化为物理实现。该模型已经将数据抽象为“表格”、“列”、“键”等形式，该数据模型需要具体考虑数据对象如何在数据库管理系统中物理实现。数据表、索引的设计。

---

三种数据模型的转换关系如下表：（展示了数据对象从抽象到实现的映射）

概念数据模型	逻辑数据模型	物理数据模型
实体（entity）	实体（entity）	表（table）
---	属性（attribute）	列（column）
---	标识符(primary/foreign identifier)	键（primary/foreign key）
关系（relation）	关系（relation）	参照完整性约束(reference)

概念数据模型：实体、关系（抽象描述，无技术细节）。

逻辑数据模型：增加了属性和标识符（如主键/外键）。

物理数据模型：最终转换为表、列、键和引用完整性。

---

概念模型的设计：

由于E-R模型可以进行概念设计和逻辑设计阶段的数据模型表示，

        无论采用何种设计路线，最终的目标都是将E-R模型转化为物理数据模型。

在关系数据库的设计中，物理数据模型即是关系模型。

•         因此，关系数据库设计的一个核心步骤就是将E-R模型转化为关系模型。

二、概念结构设计：E-R模型

2.1.E-R模型概述

E-R模型是实体-联系模型（entity-relationship model）的简称

是用于描述现实世界的概念数据模型

2.2.E-R模型的基本元素

• 实体和实体集

        实体是对现实世界中事物数据概念的某种抽象。

                例如，一个人是实体，一个公司也是实体。

        多个具有相同性质的同类实体构成的集合，称为实体集。

                例如，一所大学的所有学生是一个实体集，特定的实体称为实体实例

• 属性

        实体集都可以被一组特征来描述，这些用来描述实体集的数据特征被称为实体集的属性

                例如，在Student实体集有Sno、Sname、Sgender、Sage和Sdept属性

• 联系

        主要指代实体与实体之间的联系

                例如，学生实体与课程实体之间的一种联系是“选课”

2.3.E-R图

E-R图是用来描述实体集、属性和联系的图形化表示。

        实体集：用矩形表示，矩形框内标注实体集名。

        属性：用椭圆形表示，并用无向边将其与相应的实体集连接起来。

        实体集的标识符用下划线标识出来。

                例如，Student实体集具有学号（Sno）、姓名（Sname）、性别（Sgender）、年龄（Sage）、系（Sdept）等属性，Sno是Student的标识符。

---

        联系：用菱形表示，菱形框内标注联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1∶1，1∶n 或 m∶n）。

        联系可具有属性。如果实体之间的联系也具有属性，则用无向边连接属性和菱形。

                例如，联系SC有成绩Grade的属性，使用无向边将二者连接：

2.4.E-R联系类型

一元联系：实体集内部实体之间的联系，即实体自己与自己之间的联系称为一元联系。

二元联系：两个实体集之间的联系称为二元联系。

三元联系：三个实体集之间的联系称为三元联系。

三元联系分解为二元联系

针对三元联系，可以将其分解为二元联系：

三、逻辑结构设计：从E-R图到关系设计

E-R图转化为关系的步骤：实体集的转换、联系的转换和规范化设计

• E-R实体集的转换

        关系表的表名是实体集的名称

        关系表的属性是实体集的属性

        关系表的主键是实体集的标识符

• 联系的转换

        一元联系：转换规则与二元联系类似

        二元联系：是E-R关系中最常见的关系类型，做重点介绍

        三元联系：可以将其先分解成二元联系，再用二元联系的规则进行转换

---

E-R联系中二元联系的转换

一对一（1:1）联系的转换示例：

        在上述两个实体集对应的关系模式中任选一个添加另一个关系模式的主键即可

即转化后的关系模式可为：

Student(Sno, Sname, Sgender, Sage, Sdept, StuCardID)，

StuCard(StuCardID, Cardbalance, CardExp)或Student(Sno, Sname, Sgender, Sage, Sdept), StuCard(StuCardID, Cardbalance, CardExp, Sno )

        在两个实体集转换成的两个关系模式的基础上，添加一个新关系模式

可添加一个独立的关系模式，即Hold(Sno, StuCardID)

一对多（1:n）联系的两种转换方式：

Student关系模式为Student(Sno, Sname, Sgender, Sage, Sdept, SchoolID)

School关系为School(SchoolID, SchoolName, SchoolLocation)

添加一个独立的关系模式，即 Admission(Sno, SchoolID)。

多对多（m:n）联系：对该联系添加一个新的关系模式，这个新的关系模式的属性是两端实体类型的标识符以及该联系自有的属性，其键为两端实体集的标识符的组合。

即SC联系转换的关系为：SC(Sno, Cno, Grade)：

Sno （学号）	Cno （课程号）	Grade （成绩）
2021310721	5	98
2021310722	1	87
2021310723	1	92
2021310723	5	76
2021310724	7	84
2021310725	4	95

四、规范化设计理论

4.1函数依赖理论

为了解决关系模式设计的规范化问题，需要引入一个重要概念： 函数依赖 （ functional dependency ） 函数依赖 反映了一个关系中属性或者属性组之间相互依存、相互制约的关系，即两个列或者列组之间的约束。基于函数依赖理论，可以将一个关系分解为几个更小的关系，使之满足规范化程度更高的关系表。 函数依赖 是关系中属性之间在语义上的关联特性。例如，假设一个关系表的 A 列是国家， B 列是首都，那么如果两条记录的 A 列值是一样的，那么必然它们 B 列的值也是一样的，即国家决定了首都。

在关系模式设计上最重要的约束是函数依赖，它反映了一个关系表中 列或者列组之间相互依存、相互制约 的关系，即两个列或者列组之间的约束。

【例6.1】描述一个学生Student关系，可以有学号、姓名、系名等属性。一个学号只对应一个学生，一个学生只在一个系中学习，“学号”值确定后，学生的姓名及所在系的值就被唯一确定。

有如下依赖关系， Sname =f( Sno ) ， Sdept =f( Sno ) 即 Sno 函数决定 Sname Sno 函数决定 Sdept 记作 Sno → Sname ， Sno → Sdept

函数依赖定义 l 对一关系R(U) ， X 和 Y 是其列集合 U 的子集， t 和 l 分别是 R 中的任意两个元组。 l 如果t[X]=l[X] ，则t[Y]=l[Y]， 那么称 Y 函数依赖于 X ，或者 X 函数决定 Y ， 记为 X → Y 。 l 如果 Y 不依赖于 X ，则记为X↛Y 。如果X→Y 且Y→X ，则 X 与 Y 一一对应，记 为X⟷Y 。 一个函数依赖要成立，不但要求关系 R 中当前的值都能满足函数依赖条件，而且还要求关系中的 任一可能取值都满足函数依赖的条件 。此外，函数依赖还具有数据语义特征，即函数依赖在某种程度上也是现实世界的反映。

 

4.2规范化设计和范式

规范化设计：在关系模式中存在函数依赖时就有可能存在数据冗余，进而可能导致数据操作异常。因此，关系表的规范化设计就是要尽可能地减少关系表中列或者列组之间的依赖关系，进而得到简洁独立的关系表。

范式 【 定义 1】 关系表的规范程度状态为 范式 （ normal form, NF ） 【定义 2 】 范式是符合某一种级别的关系模式的集合                 范式可以用于确保数据库模式中没有各种类型的异常和不一致，不同的规范化范式要求可以设计出冗余程度不同的数据库。

一个低一级范式的关系模式，通过 模式分解 可以转换为若干个高一级范式的关系模式的集合，这种过程就叫 规范化 ( normalization ) 。

---

第一范式 （ 1NF ）是指关系 R 的每一属性都是不可再分的基本数据项，同一属性中不能有多个值，即关系表中的某个属性不能有多个值或者不能有重复的属性。 在关系数据库中，满足最低要求的范式是第一范式 ，不满足第一范式的不是关系数据库。如果出现重复的属性，则根据第一范式，需要将该属性进行细分。 第二范式 （ 2NF ） 是指关系 R 首先要满足第一范式，并且每一个 非主属性都完全函数依赖于任何一个候选 键 。

【例】考虑下图的学生-选课-住址关系SLC，其复合主键是{Sno, Cno}，Sloc为学生的宿舍楼号，并且每个系的学生住在同一个地方。SLC关系存在如下函数依赖：

学生宿舍地址Sloc和系别Sdept只依赖于复合键中Sno，存在部分函数依赖。

【例-续】由此，我们将关系模式SLC分解成两个满足2NF的关系模式，以消除上述的异常。

第三范式（3NF）是指在关系R 满足第一范式，并且不存在非主属性对候选键的传递函数依赖

【例】考虑下图所示的SL关系表，该关系满足第二范式，但存在如下函数依赖：

【例-续】将关系模式SL分解成两个关系SL和DL以消除传递函数依赖，使之满足第三范式。

4.3数据依赖的公理系统

Armstrong 公理系统 l 用于推导关系数据库中的函数依赖和其他数据依赖 l 提供了一种形式化的方法来理解和处理数据依赖关系，从而提高数据库的可靠性、一致性和性能。 l 一套推理规则，是模式分解算法的理论基础 l 可以用于求给定关系模式的键 l 从一组函数依赖求得蕴涵的函数依赖 闭包及其计算 函数依赖集的等价和最小函数依赖集