本节要点：
- 数据库设计概述
- 需求分析
- 概念结构设计
- 逻辑结构设计
- 数据库的物理设计
- 数据库实施与维护
1 数据库设计概述
什么是数据库设计？
- 指对于一个给定的应用环境，构造最优的数据库模式，建立数据库，使之能够存储数据，满足各种用户的应用需求。（数据库本身的设计）
- 参与人员是数据库系统分析员，DBA，(用户)
- 采用数据库设计方法
什么是数据库应用系统设计？
- 在数据库基础上的应用程序系统的设计。
- 参与人员是应用系统分析员和程序员，(用户)
- 采用软件工程方法
数据库设计有哪些基本步骤？
1、 需求分析
了解用户的需求，包括数据与处理。(数据流图，数据字典)
2、 概念结构设计
设计独立于DBMS的概念模型（ER图）
3、 逻辑结构设计
设计DBMS逻辑模型，并优化
4、 物理结构设计
选取合适的存储结构与方法
5、 数据库实施
建立数据库，编制与调试应用程序，组织数据入库
6、 数据库运行与维护
正式运行，并对数据库评价调整与修改
2 需求分析
需求分析简单地说就是分析用户的要求。通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求。
调查的重点是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的信息要求、处理要求、安全性与完整性要求。
确定用户的最终需求是一件很困难的事，这是因为用户缺少计算机知识，而设计人员缺少用户的专业知识，所以需要不断的沟通。
需求分析的过程：
需求分析不仅是对用户需求进行分析表达，还需要提交给用户，征得用户的认可。那么需求分析很重要的部分就是分析和表达用户的需求。系统的分析和表达有很多种方法，一般使用数据流图和数据字典。数据流图表达了数据和处理过程的关系，数据字典则是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果。
2.1 数据流图
示例：销售管理子系统数据流图
2.2 数据字典
数据字典是各类数据描述的集合。
数据字典的内容:
1) 数据项
是不可再分的数据单位，对数据项的描述通常包括以下内容：
数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}
示例：“学号”
数据项： 学号
含义说明：唯一标识每个学生
别名： 学生编号
类型： 字符型
长度： 8
取值范围：00000000至99999999
取值含义：前两位标别该学生所在年级，后六位按顺序编号
2) 数据结构
数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。对数据结构的描述通常包括以下内容：
数据结构描述={数据结构名，含义说明，组成：{数据项或数据结构}}
示例：学生
数据结构名：学生
含义说明：是学籍管理子系统的主体数据结构，定义了一个学生的有关信息
组成：学号，姓名，性别，年龄，所在系，年级
3) 数据流
数据流是数据结构在系统内传输的路径。对数据流的描述通常包括以下内容：
数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}
示例：体检结果
数据流： 体检结果
说明： 学生参加体格检查的最终结果
数据流来源：体检
数据流去向：批准
组成： 学生，体检项目,体检结果
平均流量： ……
高峰期流量：……
4) 数据存储
数据存储是数据结构停留或保存的地方。也是数据流的来源和去向之一。对数据流的描述通常包括以下内容：
数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}
示例：学生登记表
数据存储： 学生登记表
说明： 记录学生的基本情况
流入数据流：……
流出数据流：……
组成： ……
数据量： 每年3000张
存取方式： 随机存取
3 概念结构设计
将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。它是整个数据库设计的关键。
3.1 概念结构设计概述
在需求分析阶段所得到的应用需求应该首先抽象为信息世界的结构，才能更好地、更准确地用某一DBMS实现这些需求。
描述概念模型的有力工具是E-R模型。
3.2 概念结构设计的方法与步骤
设计概念结构常用的方法：
自顶向下。即首先定义全局概念结构的框架，然后逐步细化。
自底向上。即首先定义各局部应用的概念结构，然后将他们集成起来，得到全局概念结构。（较常采用）
3.3 数据抽象与局部视图设计
概念结构是对现实世界的一种抽象。所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特征，忽略非本质的细节，并把这些特性用各种概念精确地加以描述，这些概念组成了某种模型。
一般有三种抽象：
1) 分类
定义某一类概念作为现实世界中一组对象的类型。这些对象具有某些共同的特征和行为。它抽象了对象值和型之间的“is member of”的语义.
在E-R模型中，实体型就是这种抽象：
2) 聚集
定义某一类型的组成成分。它抽象了对象值和型之间的“is part of”的语义。在E-R中若干属性的聚集组成了实体型，就是这种抽象：
3) 概括
类型之间的一种子集联系。它抽象了对象值和型之间的“is subset of”的语义：
概念结构设计的第一步就是利用上面介绍的抽象机制对需求分析阶段收集到的数据进行分类、组织（聚集），形成实体、实体的属性，标识实体的码，明确实体之间的联系类型（1:1,1：n，m:n），设计分E-R图。具体做法是：
1) 选择局部应用
根据某个系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，作为设计分E-R图的出发点。让这组图中每一部分对应一个局部应用。
由于高层的数据流图只能反映系统的概貌，而中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此人们往往以中层数据流图作为设计分E-R图的依据：
2) 逐一设计分E-R图
选择好局部应用后，就要对每个局部应用逐一设计分E-R图。
设计分E-R图的步骤：
（1）以数据字典为出发点定义E-R图。
数据字典中的“数据结构”、“数据流”和“数据存储”等已是若干属性的有意义的聚合
（2）按属性的定义准则进行必要的调整。
定义属性的两条准则：
准则1：属性不能再有属性
准则2：属性不可与实体有联系。
3.4 视图的集成
各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图。
集成局部E-R图的步骤：
- 合并。解决各部分E-R图之间的冲突，将各分E-R图合并起来生成初步E-R图
- 修改与重构。消除不必要的冗余，生成基本E-R图
1) 合并分E-R图，生成初步E-R图
各个局部应用所面向的问题不同，由不同的设计人员进行设计，各个分E-R图之间必定会存在许多不一致的地方，所以，需要合理消除各分E-R图的冲突。
各分E-R图之间的冲突主要有三类：属性冲突、命名冲突、结构冲突：
- 属性冲突：同一属性的属性值的类型、取值范围或取值集合不同
- 命名冲突：分同名异议和异名同义
同名异议，即不同意义的对象在不同的局部应用中具有相同的名字
异名同义，即同一意义的对象在不同的局部应用中具有不同的名字
- 结构冲突：
同一对象在不同应用中具有不同的抽象
同一实体在不同的分E-R图中包含的属性个数和属性排列次序不完全相同
实体间的联系在不同的分E-R图中为不同的类型
2) 消除不必要的冗余，设计生成基本E-R图
消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。如下图中，Q3=sum(Q1*Q2) Q4=sum(Q5)，所以Q3和Q4是冗余数据，可以消去。并且由于Q3消去，产品与材料间m:n的冗余联系也应消去。
但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。
例如，若物种部门经理经常要查询各种材料的库存量，如果每次都要查询每个仓库中此种材料的库存，再对它们求和，查询效率就太低了。所以应保留Q4，同时把Q4=sum(Q5)定义为Q4的完整性约束条件。每当Q5修改后，就触发该完整性检查例程，对Q4作相应的修改。
4 逻辑结构设计
概念结构是独立于任何一种数据模型的信息结构。逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。
4.1 E-R图向关系模型的转换
转换原则
⒈ 一个实体型转换为一个关系模式。
关系的属性：实体型的属性
关系的码：实体型的码
⒉ 一个m:n联系转换为一个关系模式。
关系的属性：与该联系相连的各实体的码以及联系本身的属性
关系的码：各实体码的组合 （或码的一部分）
⒊ 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
转换为一个独立的关系模式：
关系的属性：与该联系相连的各实体的码以及联系本身的属性
关系的码：n端实体的码
例，《班级》与《学生》的“组成”联系为1:n联系。
将其转换为关系模式：组成（学号，班号）
⒋ 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
例，《班主任》与《班级》的“管理”联系为1:1联系，可以有三种转换方法：
（1）转换为一个独立的关系模式：
管理（职工号，班级号）
或 管理（职工号，班级号）
（2）“管理”联系与班级关系模式合并，则只需在班级关系中加入教师关系的码，即职工号：
班级：（班级号，学生人数，教师号）
（3）“管理”联系与教师关系模式合并，则只需在教师关系中加入班级关系的码，即班级号：
教师：（教师号，姓名，性别，职称，班级号）
⒌ 三个或三个以上实体间的一个多元联系转换为一个关系模式。
关系的属性：与该多元联系相连的各实体的码以及联系本身的属性
关系的码：各实体码的组合 （或码的一部分）
⒍ 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。
例，如果教师实体集内部存在领导与被领导的1:n自联系：
教师：｛职工号，姓名，性别，职称，系主任｝
⒎ 具有相同码的关系模式可合并。
目的：减少系统中的关系个数。
例如:
拥有（学号，性别）
学生（学号，姓名，出生日期，所在系，年级，
班级号，平均成绩）
都以学号为码，可以将它们合并：
学生（学号，姓名，性别，出生日期，所在系，
年级，班级号，平均成绩）
总结：
⒈ 一个实体型转换为一个关系模式。
⒉ 一个m:n联系转换为一个关系模式。
⒊ 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
⒋ 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
⒌ 三个或三个以上实体间的一个多元联系转换为一个关系模式。
⒍ 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。
⒎ 具有相同码的关系模式可合并。
示例：ER转关系模式
部门（部门号，部门名，经理职工号，…）
职工（职工号,……）
产品（…..）
供应商(…….)
零件(……..)
职工工作(………)
供应（产品号，供应商号，零件号，供应量）
……
4.2 数据模型的优化
数据库逻辑设计的结果不是唯一的。得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库的性能，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导。
4.3 设计用户子模式
将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体DBMS的特点，设计用户的外模式。
定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。
定义用户外模式时可以注重考虑用户的习惯与方便。包括三个方面：
(1)使用更符合用户习惯的别名
(2)针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。
(3)简化用户对系统的使用
5 数据库的物理设计
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。
数据库的物理设计通常分为两步：
1) 确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构；
2) 对物理结构进行评价，评价的重点是时间和空间效率。
如果评价结果满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。
如图：
1) 为关系模式选择存取方法(建立存取路径)
物理设计的第一个任务就是要确定选择哪些存取方法，即建立哪些存取路径。设计关系、索引等数据库文件的物理存储结构。
DBMS常用存取方法：
- 索引方法
- 聚簇（Cluster）方法
- HASH方法
2) 确定数据库的存储结构
确定数据的存放位置和存储结构：
根据应用情况将易变部分与稳定部分、存取频率较高部分与存取频率较低部分，分开存放，以提高系统性能。
确定系统配置（DBMS产品一般都提供了一些存储分配参数）：
- ü 同时使用数据库的用户数
- ü 同时打开的数据库对象数
- ü 使用的缓冲区长度、个数
- ü 时间片大小
- ü 数据库的大小
- ü 装填因子
- ü 锁的数目等等
3) 评价物理结构
对数据库物理设计过程中产生的多种方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
6 数据库实施和维护
数据库实施的工作内容：
- 用DDL定义数据库结构
- 组织数据入库
- 编制与调试应用程序
- 数据库试运行
在数据库运行阶段，对数据库经常性的维护工作主要是由DBA完成的，包括：
- 数据库的转储和恢复
- 数据库的安全性、完整性控制
- 数据库性能的监督、分析和改进
- 数据库的重组织和重构造