第七章 数据库设计
7.1 数据库设计概述
数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。
信息管理要求：在数据库中应该存储和管理哪些数据对象 。
数据操作要求：对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作。
7.1.1 数据库设计的特点
7.1.2 数据库设计方法
7.1.3 数据库设计的基本步骤
数据库设计分6个阶段
需求分析
概念结构设计
逻辑结构设计
物理结构设计
数据库实施
运用DBMS提供的数据库语言（如SQL）及宿主语言，根据逻辑设计和物理设计的结果
建立数据库
编制与调试应用程序
组织数据入库
进行试运行
数据库运行和维护
需求分析和概念设计独立于任何数据库管理系统
逻辑设计和物理设计与选用的DBMS密切相关
7.1.4 数据库设计过程中的各级模式
数据库设计不同阶段形成的数据库各级模式
需求分析阶段： 综合各个用户的应用需求
概念设计阶段：形成独立于机器特点，独立于各个数据库管理系统产品的概念模式（E-R图）
逻辑设计阶段：
1. 首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，
形成数据库逻辑模式
2. 然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立
必要的视图（View），形成数据的外模式
物理设计阶段：
根据数据库管理系统特点和处理的需要，
进行物理存储安排，建立索引，形成数
据库内模式
7.2 需求分析
7.2.1 需求分析的任务
需求分析的任务
需求分析的重点 ：调查的重点是“数据”和“处理”，获得用户对数据库要求
信息要求
处理要求
安全性与完整性要求
需求分析的难点
7.2.2 需求分析的方法
调查需求
达成共识
分析表达需求
结构化分析方法（Structured Analysis，简称SA方法）
从最上层的系统组织机构入手
自顶向下、逐层分解分析系统
1.抽象
2．分解处理功能和数据
(1)分解处理功能Ø将处理功能的具体内容分解为若干子功能
(2)分解数据Ø处理功能逐步分解同时，逐级分解所用数据，形成若干层次的数据流图
(3)表达方法Ø 处理逻辑：用判定表或判定树来描述Ø 数据：用数据字典来描述
3．将分析结果再次提交给用户，征得用户的认可
7.2.3 数据字典
数据字典的用途 ：进行详细的数据收集和数据分析所获得的主要结果
数据字典的内容
数据项
数据结构
数据流
数据存储
处理过程
7.3 概念结构设计
7.3.1 概念结构
概念模型的工具：E-R图
7.3.2 概念结构设计的方法与步骤
设计概念结构的四类方法
自顶向下：首先定义全局概念结构的框架，然后逐步细化
自底向上 ：首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构
逐步扩张 ：首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其它概念结构，直至总体概念结构
混合策略 ：将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。
常用策略
自顶向下地进行需求分析
自底向上地设计概念结构
v自底向上设计概念结构的步骤
第1步：抽象数据并设计局部视图
第2步：集成局部视图，得到全局概念结构
7.3.3 数据抽象与局部视图设计
数据抽象
分类，聚集，概括。
局部视图设计
7.3.4 视图的集成
1.两类属性冲突
属性域冲突
属性值的类型
取值范围
取值集合不同
属性取值单位冲突
2.两类命名冲突
同名异义：不同意义的对象在不同的局部应用中具有相同的名字
异名同义（一义多名）：同一意义的对象在不同的局部应用中具有不同的名字
3.三类结构冲突
同一对象在不同应用中具有不同的抽象
同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同
实体之间的联系在不同局部视图中呈现不同的类型
基本任务 消除不必要的冗余，设计生成基本E-R图
7.4 逻辑结构设计
逻辑结构设计的任务
把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构
逻辑结构设计的步骤
将概念结构转化为一般的关系、网状、层次模型
将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换
对数据模型进行优化
7.4.1 E-R图向关系模型的转换
1)一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。§转换为一个独立的关系模式§ 与某一端实体对应的关系模式合并
(2)一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。§ 转换为一个独立的关系模式 与n端对应的关系模式合并
(3) 一个m:n联系转换为一个关系模式。
(4)三个或三个以上实体间的一个多元联系转换为一个关系模式。
(5)具有相同码的关系模式可合并
目的：减少系统中的关系个数
合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序
7.4.2 数据模型的优化
优化数据模型的方法
1.确定数据依赖
按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖
2.消除 冗余的联系
对于各个关系模式之间的数据依赖进行极小化处理，消除 冗余的联系。
3.确定所属范式
§按照数据依赖的理论对关系模式逐一进行分析
§考查是否存在部分函数依赖、传递函数依赖、多值依赖等
§确定各关系模式分别属于第几范式
4.按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。
注意：并不是规范化程度越高的关系就越优，一般说来，第三范式就足够了
5.按照需求分析阶段得到的各种应用对数据处理的要求，对关系模式进行必要的分解，以提高数据操作的效率和存储空间的利用率
常用分解方法 ：
水平分解 把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率
垂直分解 把关系模式R的属性分解为若干子集合，形成若干子关系模式
7.4.3 设计用户子模式
定义用户外模式时应该注重的问题
包括三个方面：
(1) 使用更符合用户习惯的别名
合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。
用视图机制可以在设计用户视图时可以重新定义某些属性名，使其与用户习惯一致，以方便使用。
(2) 针对不同级别的用户定义不同的View ，以满足系统对安全性的要求。
(3) 简化用户对系统的使用:如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图
7.5 数据库的物理设计
7.5.1 数据库物理设计的内容和方法
7.5.2 关系模式存取方法选择
7.5.3 确定数据库的存储结构
7.5.4 评价物理结构
7.6 数据库实施和维护
7.6.1 数据的载入和应用程序的调试
7.6.2 数据库的试运行
v在原有系统的数据有一小部分已输入数据库后，就可以开始对数据库系统进行联合调试，称为数据库的试运行v
数据库试运行主要工作包括：
1）功能测试
§实际运行数据库应用程序，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求
§如果不满足，对应用程序部分则要修改、调整，直到达到设计要求
2）性能测试
§测量系统的性能指标，分析是否达到设计目标
§如果测试的结果与设计目标不符，则要返回物理设计阶段，重新调整物理结构，修改系统参数，某些情况下甚至要返回逻辑设计阶段，修改逻辑结构
7.6.3 数据库的运行和维护
v在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成的，包括：
1. 数据库的转储和恢复
2.数据库的安全性、完整性控制
初始定义
数据库管理员根据用户的实际需要授予不同的操作权限
根据应用环境定义不同的完整性约束条件
修改定义
当应用环境发生变化，对安全性的要求也会发生变化，数据库管理员需要根据实际情况修改原有的安全性控制
由于应用环境发生变化，数据库的完整性约束条件也会变化，也需要数据库管理员不断修正，以满足用户要求
3.数据库性能的监督、分析和改进
在数据库运行过程中，数据库管理员必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。
利用监测工具获取系统运行过程中一系列性能参数的值
通过仔细分析这些数据，判断当前系统是否处于最佳运行状态
如果不是，则需要通过调整某些参数来进一步改进数据库性能
4.数据库的重组织与重构造
7.7 小结
数据库的设计过程
需求分析
概念结构设计
逻辑结构设计
物理设计
实施和维护
数据库各级模式的形成
数据库的各级模式是在设计过程中逐步形成的
需求分析阶段综合各个用户的应用需求（现实世界的需求）
概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模型），用E-R图来描述
在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式
在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式
Last updated
