数据库-基础设计规范及过程

本文整理自《数据库系统概论》第六、七章。

知识准备

关系模型

一个关系模型应当是一个五元组R(U,D,DOM,F)

这里：

• 关系名R是符号化的元组语义。
• U为一组属性。
• D为属性组U中的属性所来自的域。
• DOM为属性到域的映射。
• F为属性组U上的一组数据依赖。

由于D、DOM与模式设计关系不大，因此在本章中把关系模式看作一个三元组：R<U,F>

//当且仅当U上的一个关系r满足F时，r称为关系模式R<U,F>的一个关系。

数据依赖

数据依赖是一个关系内部属性与属性之间的一种约束关系。这种约束关系是通过属性间值的相等与否体现出来的数据间相关联系。它是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现。

人们已经提出了许多种类型的数据依赖，其中最重要的是函数依赖（FD）和多值依赖（MVD）。

函数依赖

属性间的函数依赖类似于数学中的函数y=f(x)，自变量x确定之后，相应的函数值y也就唯一确定了。比如，描述一个学生，其学号是唯一的，那么当学生的学号确定后，其姓名等也有了确定的对应值。

即，X决定Y，但是X不包含Y。

若X决定Y，且X包含Y，那么就是平凡的函数依赖。

若X决定Y，且X的任一真子集X'不能决定Y，那么就是完全函数依赖，否则就是部分函数依赖。

多值依赖

 

多值依赖具有以下性质：

对称性：

以上图的Teaching(C,T,B)为例，课程（C）可以唯一决定一组教师（T），也能唯一决定一组参考书（B）。即C->->T，C->->B，T多值依赖于C，B也多值依赖于C。

传递性：

以上图的Teaching(C,T,B)为例，课程（C）可以唯一决定一组教师（T），这组教师（T）能唯一决定一组参考书（B），课程（C）也能唯一决定这组参考书（B）。即C->->T，T->->B，则C->->B，T多值依赖与C，B多值依赖于T，则B多值依赖于C。

函数依赖可以看作是一种特殊的多值依赖。

码

若候选码多于一个，则选定其中的一个为主码（primary key），没错，就是我们熟悉的主键。一般从多个候选码中选出主键，是人为经验选择。

包含在任何一个候选码中的属性称为主属性；不包含在任何候选码中的属性称为非主属性或非码属性。最简单的情况，单个属性是码；最极端的情况，整个属性组是码，称为全码。

就是我们熟悉的外键。

规范化

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

通常按属性间依赖的情况来区分关系规范化程度为第一范式、第二范式、第三范式和第四范式等。

可以看出，各级范式之间是层层包含关系。

1NF

作为一个二维表，关系要符合一个最基本的条件：每一个分量必须是不可分的数据项。满足了这个条件的关系模式就属于第一范式（1NF）。1NF是数据库规范化最基本的条件，即各个属性基于现实场景得到了比较合理的抽象。很少有数据库设计会不满足1NF，基本没有。

2NF

3NF

BCNF

4NF

4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。

规范化小结

规范化可以有效减少数据冗余、更新异常、插入异常、删除异常等问题，但是规范化有没有缺点呢？一般，我们会使用分表的手段来落实规范化，势必会造成数据操作的效率降低，因此，在商用系统中，很少能严格遵循规范化，往往只能达到2NF。

设计过程

基本概念

数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。

数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效的运行环境。高效的运行环境指数据库数据的存储效率、数据库存储空间的利用率、数据库系统运行管理的效率等都是高的。

基本步骤

数据库设计有6大基本步骤：

1. 需求分析
2. 概念结构设计
3. 逻辑结构设计
4. 物理结构设计
5. 数据库实施
6. 数据库运行和维护

需求分析

调查、收集与分析用户的各种需求，重点把握“数据”和“处理”，获得用户对数据库的如下要求：

1. 信息要求。指用户需要从数据库中获得信息的内容与实质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。
2. 处理要求。指用户要完成的数据处理功能，对处理性能的要求。
3. 安全性与完整性要求。

概念结构设计

概念结构设计即是把在需求阶段所得到的应用需求抽象为信息世界的结构，重点把握E-R图。

逻辑结构设计

逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用数据库管理系统产品所支持的诗句模型相符合的逻辑结构。可以简单理解为，E-R图向关系模型的转换。

一个实体型转换为一个关系模式，关系的属性就是实体的属性，关系的码就是实体的码。

对于实体型的联系有以下不同的情况：

1. 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
2. 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
3. 一个m:n联系转换为一个关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
4. 三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
5. 具有相同码的关系模式可合并。

物理结构设计

为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。

数据库的物理设计通常分为两步：

1. 确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构。
2. 对物理结构进行评价，评价的重点是时间和空间效率。

数据库实施

数据库实施阶段包括两项重要的工作，一项是数据的载入，另一项是应用程序的编码和调试。

数据库运行和维护

在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成的。数据库的维护工作主要包括以下几个方面。

1. 数据库的转储和恢复。
2. 数据库的安全性、完整性控制。
3. 数据库性能的监督、分析和改造。
4. 数据库的重组织与重构造。

实例

系统背景

游戏上传、下载网站

需求分析

该系统主要面向四类用户：游客、会员、游戏开发者和管理员。系统UML用例图如下图所示，游客可以查看游戏，还可以查看排行榜，根据游戏名称搜索游戏，下载游戏，不具备数据库交互功能。游客注册成功后则成为会员，会员可以评论游戏、参与游戏讨论、查看个人信息等。游客注册申请为游戏开发者后，可以发布游戏，查看发布历史等。管理员登录后台管理系统后，则可以管理游戏信息，管理用户，管理站内发言。

概念结构设计

E-R图

部分实体属性图（篇幅有限，不详细展开）

逻辑结构设计

注释：在各实体属性中，下划线的字段表示主键；倾斜的字段表示外键。

物理结构设计

部分数据表如下：

普通用户表（ada_user）

游戏开发者表（ada_developer）

游戏表（ada_game）

例子就举到这了~数据库实施、数据库运行和维护涉及到编码，而且概念不是很抽象，相信大家能够理解。一般数据库设计进行到物理结构设计，就可以对系统整体有种了然于胸之感，接下来就是把设计转为具体实施。

个人总结

《数据库系统概论》是一本很好的书，其中的理论知识对现实的业务数据库设计有很好的指导意义，然而数据库的学习之路远不止于此，即便没有要成为DBA，具备扎实的数据库知识于开发也是如虎添翼。

参考资料

《数据库系统概论》