数据库设计

基本任务

根据用户的信息需求、处理需求和数据库的支持环境(包括硬件、操作系统和DBMS)，设计出数据库模式(包括外模式、逻辑模式和内模式)及其典型的应用程序

软件项目开发周期中数据库设计

1. 需求分析阶段：分析客户的业务和数据处理需求；
2. 概要设计阶段：设计数据库的E-R模型图，确认需求信息的正确和完整；
3. 详细设计阶段：应用三大范式审核数据库结构，将E-R图转换为数据库模型图；
4. 代码编写阶段：物理实现数据库，编码实现应用；
5. 软件测试阶段：编写测试文档，进行软件测试工作；
6. 软件维护阶段：安装部署，维护升级等工作；

数据库设计的基本步骤

1. 需求分析：通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求。
2. 概念结构设计：通过对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型。
3. 逻辑结构设计：将概念结构转换为某个数据库管理系统所支持的数据模型，并对其进行优化。
4. 物理结构设计：为逻辑数据结构选取一个最适合应用环境的物理结构,包括存储结构和存取方法。
5. 数据库实施：根据逻辑设计和物理设计的结果构建数据库,编写与调试应用程序,组织数据入库并进行试运行。
6. 数据库运行和维护：经过试运行后即可投入正式运行,在运行过程中必须不断对其进行评估、调整与修改。

需求分析和概念设计独立于任何数据库管理系统
逻辑设计和物理设计与选用的数据库管理系统密切相关

解释

设计阶段	数据	处理
需求分析	数据字典、数据项、数据流、数据存储的描述	数据流图和判定树、数据字典中处理过程的描述
概念结构设计	概念模型(E-R图)、数据字典	系统说明书(系统要求、方案、概图、数据流图)
逻辑结构设计	某种数据模型(比如关系)	系统结构图(模块结构)
物理设计	存储安排、方法选择、存取路径建立	模块设计
实施阶段	编写模式、装入数据、数据库试运行	程序编码、编译连接、测试
运行维护	性能监测、转储/恢复、数据库重组和重构	新旧系统转换、运行、维护

需求分析

需求分析的三个步骤：

1.需求调查:

收集需求信息, 调查清楚用户的实际要求, 与用户达成共识，与该系统有关人员进行交流、座谈，充分了解用户需求，理解数据库需要完成的任务。

• 需求调查的内容
  • 组织机构的情况: 组成, 职责, 作用, 现状, 问题，哪些业务适合计算机管理, 哪些不适合。
  • 各个部门的业务活动现状(调查的重点): 输入和使用的数据, 加工处理方法, 数据的流程, 输出的数据及格式, 注意收集原始数据资料, 如台帐、单据、发票、收据、统计报表、文档、档案等。
  • 外部要求：调查数据处理的响应时间、频度和如何发生的规则，以及经济效益的要求，安全性和完整性的要求。
  • 协助用户明确对新系统的各种要求(调查的又一个重点): 信息要求, 处理要求, 安全性要求, 完整性要求, 未来规划中对数据的应用需求等。
  • 确定新系统的边界: 哪些由计算机完成, 哪些由人工完成
• 步骤
  • 调查组织机构情况。
  • 调查各部门的业务活动情况。
  • 协助用户明确对新系统的各种要求，包括信息要求、处理要求、完全性与完整性要求。
  • 确定新系统的边界
• 方式
  • 跟班作业：通过亲身参加业务工作了解业务活动的情况。
  • 开调查会：通过与用户座谈来了解业务活动情况及用户需求。
  • 请专人介绍。
  • 询问：对某些调查中的问题，可以找专人询问。
  • 设计调查表请用户填写：调查表设计合理，则很有效。
  • 查阅记录：查阅与原系统有关的数据记录。
• 策略
  • 对高层负责人的调查: 一般采用个别交谈方式, 先给一份详细的调查提纲, 以便有所准备。
  • 对中层管理人员的调查: 可采用开座谈会, 个别交谈, 发调查表, 查阅记录的调查方式。
  • 对基层业务人员的调查: 主要采用发调查表, 个别交谈或跟班作业的调查方式。

2.分析

分析、整理和表达这些需求信息，形成需求说明书（例如，包括DFD和DD等）。

• 业务流程分析和表示
  • 目的是获得业务流程及业务与数据联系的形式描述。
  • 采用数据流层次结构分析法(SA法)。
  • 分析结果以数据流图(DFD图)表示, 再辅以数据字典(DD)作补充描述。
• 需求信息的补充描述
  • 数据字典: 主要用于概念结构设计。
  • 业务活动清单: 列出每一部门中最基本的工作任务。
  • 其他需求清单: 如完整性、安全性、一致性要求。
• 撰写需求分析说明书
  

数据字典

数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。任何字典最主要的用途是供人查阅对不了解的条目的解释，数据字典的作用也正是在软件分析和设计的过程中给人提供数据的描述信息。数据流图和数据字典共同构成系统的逻辑模型

内容

定义数据的方法

案例

• 数据项：数据的最小单位。其具体内容包括：数据项名、含义说明、别名、类型、长度、取值范围、与其他数据项的关系。

  数据项名	选课单号
  说明	表示每张选课单
  类型	CHAR(8)
  长度	8
  别名	选课号
  取值范围	000000001-99999999

• 数据结构：数据项有意义的集合。内容包括：数据结构名、含义说明，这些内容组成数据项名。

  数据结构名	考试课程
  说明	作为考场安排的组成部分，说明某门课程哪位老师代，以及所选学生人数。
  组成	课程号、教师号、选课人数

• 数据流：可以是数据项，也可以是数据结构，它表示某一处理过程中数据在系统内传输的路径。内容包括：数据流名、说明、流出过程、流入过程，这些内容组成数据项或数据结构。

  数据流名	考场安排
  说明	由各课程所选学生数，选定教师、时间、安排考场
  来源	考场
  去向	教师
  数据结构	考场安排（考试课程、考试时间、教学楼、教师编号）

• 数据存储：处理过程中数据的存放场所，也是数据流的来源和去向之一。可以是手工凭证，手工文档或计算机文件。

  数据存储名	课程表
  说明	对每门课程的名称、学分、先行课程号和摘要描述。
  输出数据流	课程介绍
  数据描述	课程号、课程名、学分数、先行课程号、摘要
  数目	每年500种
  存取方式	随机存取

• 处理过程：处理过程的处理逻辑通常用判定表或判定树来描述，数据字典只用来描述处理过程的说明性信息。

  处理过程	选课
  说明	对要选某门课程的每一个学生，根据已选修课程 确定其是否可选该课程。再根据学生选课的人数选择适当的教室，制定选课单。
  输入	学生选课、可选课程、已选课程
  输出	选课单
  程序提要	a. 对所选课程在选课表中查找其是否已选此课程 b. 若未选过此课程，则在选课表中查找是否已选此课程的先行课程 c. 若a、b都满足，则在选课表中增加一条选课记录 d. 处理完全部学生的选课处理后，形成选课单

3. 评审

由主管部门和专家评价、审批。

概念结构设计

将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程。

概念模型

目前应用最普遍的是实体关系（E-R）模型，它将现实世界的信息结构统一用属性、实体以及它们之间的联系来描述。

概念结构设计

实体与属性的划分：为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。
两条准则：

• 作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。
• 属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。

E-R图概念模型

组成元素：

元素	描述	表示
实体	数客观存在并可以相互区别的事物	用矩形框，矩形框内写明实体名
属性	数据	用椭圆表示，椭圆内写明属性名，用无向边将其与相应的实体连接起来
关系	数据	用菱形表示，菱形框内写明联系名称，用无向边将其与相应的实体连接起来，同时在无向边旁边标记联系的类型

关系解释

• 一对一：【例：学生与学号】一对一关系是指对于实体集A与实体集B，A中的每一个实体至多与B中一个实体有关系；反之，在实体集B中的每个实体至多与实体集A中一个实体有关系。
• 一对多：【例：班级与学生】一对多关系是指实体集A与实体集B中至少有N(N>0)个实体有关系；并且实体集B中每一个实体至多与实体集A中一个实体有关系。
• 多对多：【例：学生与课程】多对多关系是指实体集A中的每一个实体与实体集B中至少有M(M>0)个实体有关系，并且实体集B中的每一个实体与实体集A中的至少N（N>0）个实体有关系。

案例分析

一个学生可选修多门课，一门课有若干学生选修；
一个教师可讲授多门课，一门课只有一个教师讲授；
一个学生选修一门课，仅有一个成绩。
学生的属性有学号、学生姓名；教师的属性有教师编号，教师姓名；课程的属性有课程号、课程名。

逻辑结构设计

将概念结构转换成特定DBMS所支持的数据模型的过程。关系数据库逻辑设计的结果是一组关系模式的定义

逻辑结构设计步骤

1. 将概念结构转换为一般的关系、网状、层次模型；
2. 将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换；
3. 对数据模型进行优化。

关系数据库逻辑设计的步骤

1. 将概念模型(例如基本E-R图)转换为关系模式的集合 — 得到关系数据库模式；
2. 运用关系数据理论对关系数据库模式进行规范化处理；
3. 对关系数据库模式进行评价；
4. 对关系数据库模式进行修正；
5. 设计关系子模式 — 视图。

ER图向关系模型的转换

一个实体转换为一个关系模式

关系的属性=实体型的属性；关系的码=实体型的码；关系模式的码(用下横线标出) = 实体型的码；

转换为：学生(学号，姓名，系别)

每个联系类型转换为独立的关系模式

关系模式的属性 = 与该联系相连的各实体型的码+该联系自身的属性；关系模式的码(用下划线标出) = 各实体型的码；

• 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并
  • 转换为一个独立的关系模式，原则：关系模式的属性 = 与该联系相连的各实体型的码 + 该联系自身的属性；关系模式的码(用下划线标出) = 各实体型的码；
  • 与某一端实体对应的关系模式合并，原则：合并后关系的属性=加入对应关系的码和联系本身的属性；合并后关系的码不变；
    
• 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
  • 转换为一个独立的关系模式，原则：关系模式的属性 = 与该联系相连的各实体型的码 + 该联系自身的属性；关系模式的码(用下划线标出) = n端实体的码；
  • 与某一端实体对应的关系模式合并，原则：合并后关系的属性=在n端关系中加入1端关系的码和联系本身的属性；合并后关系的码不变；
    
• 一个m:n联系必须转换为一个独立的关系模式
  • 转换为一个独立的关系模式，原则：关系模式的属性 = 与该联系相连的各实体型的码 + 该联系自身的属性；关系模式的码(用下划线标出) =各实体码的组合
    - 三个或三个以上实体间的一个多元联系转换为一个关系模式，原则：关系模式的属性 = 与该联系相连的各实体型的码 + 该联系自身的属性；关系模式的码(用下划线标出) =各实体码的组合
• 具有相同码的关系模式可合并。目的：减少系统中的关系个数
  • 将其中一个关系模式的全部属性加入到另一个关系模式中
  • 然后去掉其中的同义属性（可能同名也可能不同名）
  • 适当调整属性的次序

关系图

把每一个实体装换为一个关系：

首先分析各实体的属性，从中确定其主键，然后分别用关系模式表示。

实体：学生	对应的关系：学生（学号，姓名，性别，年龄）
实体：课程	对应的关系：课程（课程号，课程名）
实体：教师	对应的关系：教师（教师号，姓名，性别，职称）
实体：系		对应的关系：系（系名，电话）

把每一个联系装换为关系模式

将4个联系转换为关系模式，其中2个多对多类型的联系转换为独立关系模式，2个一对多的联系也转换为独立的关系模式。

联系：属于	对应的关系：属于（教师号，系名）
联系：讲授	对应的关系：讲授（教师号，课程号）
联系：选修	对应的关系：选修（学号，课程号，成绩）
联系：拥有	对应的关系：拥有（学号，系名）

画出关系图

物理结构设计

数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。
为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。

步骤

• 确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构;
• 对物理结构进行评价，评价的重点是时间和空间效率；若评价结果满足原设计要求，则可进入到物理实施阶段。否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。

准备

• 要充分了解应用环境，详细分析要运行的事务。以获得选择物理数据库设计所需要的参数。分析数据库查询事务需要的信息、数据更新事务需要的信息、每个事务在各关系上运行的频率和性能要求等。
• 要充分了解所用的 DBMS的内部特征, 特别是系统提供的存取方法和存储结构。

内容

• 为关系模式选择存取方法，即要确定选择哪些存取方法，建立哪些存取路径。
• 设计关系(表)、聚簇、索引、日志、备份等数据的物理存储结构。

关系模式存取方法选择

数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求

• B+树索引
• Hash索引
• 聚簇索引

确定数据库的存储结构

• 确定数据库物理结构主要指确定数据的存放位置和存储结构，包括：确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等
• 影响数据存放位置和存储结构的因素：硬件环境和应用需求；要综合考虑存取时间、存储空间利用率和维护代价（这三个方面常常是相互矛盾的。比如：消除一切冗余数据虽能够节约存储空间和减少维护代价，但往往会导致检索代价的增加。必须进行权衡，选择一个折中方案。）

确定数据的存放位置

根据应用情况将易变部分与稳定部分分开存放，经常存取部分与存取频率较低部分分开存放。

• 可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。
• 可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。
• 数据库数据备份、日志文件备份等由于只在故障恢复时才使用，而且数据量很大，可以考虑存放在磁带上。

确定系统配置

• 系统都为这些变量（同时使用数据库的用户数、同时打开的数据库对象数、内存分配参数、缓冲区分配参数（使用的缓冲区长度、个数）、存储分配参数 、物理块的大小、物理块装填因子、时间片大小、数据库的大小、锁的数目等）赋予了合理的缺省值。在进行物理设计时需要根据应用环境确定这些参数值，以使系统性能最优。
• 在物理设计时对系统配置变量的调整只是初步的，要根据系统实际运行情况做进一步的调整，以切实改进系统性能。

数据库的实施和维护

实施阶段：

1. 建立实际的数据库结构。用DDL定义数据库：定义基本表、索引、约束、视图等；

2. 装入数据，组织数据入库(又称数据库加载)，组织数据入库是数据库实施阶段最主要的工作。

   数据装载方法：人工方法；计算机辅助方法
   数据筛选、输入、转换(工具)、校验，确保正确

3. 编制和调试数据库应用程序。数据库应用程序的设计应该与数据库设计并行进行。数据库结构建立好后，就可以开始编制与调试数据库的应用程序。

数据库的试运行

应用程序调试完成，并且已有一小部分数据入库后，就可以开始对数据库系统进行联合调试，也称数据库的试运行。

• 功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
• 性能测试：测量系统的性能指标，分析是否符合设计目标。

数据库性能指标的测量

• 数据库物理设计阶段在评价数据库结构估算时间、空间指标时，作了许多简化和假设，忽略了许多次要因素，因此结果必然很粗糙。
• 数据库试运行则是要实际测量系统的各种性能指标（不仅是时间、空间指标），如果结果不符合设计目标，则需要返回物理设计阶段，调整物理结构，修改参数；有时甚至需要返回逻辑设计阶段，调整逻辑结构。

数据的分期入库

• 重新设计物理结构甚至逻辑结构，会导致数据重新入库

• 由于数据入库工作量实在太大，所以可以采用分期输入数据的方法

  先输入小批量数据供先期联合调试使用
  待试运行基本合格后再输入大批量数据
  逐步增加数据量，逐步完成运行评价

数据库的转储和恢复

• 在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生
• 系统的操作人员对新系统还不熟悉，误操作也不可避免
• 因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏

运行和维护

在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成的，包括：

数据库的转储和恢复

• 数据库管理员要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份。
• 一旦发生介质故障，即利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态

数据库的安全性、完整性控制

• 初始定义
  • 数据库管理员根据用户的实际需要授予不同的操作权限
  • 根据应用环境定义不同的完整性约束条件
• 修改定义
  • 当应用环境发生变化，对安全性的要求也会发生变化，数据库管理员需要根据实际情况修改原有的安全性控制
  • 由于应用环境发生变化，数据库的完整性约束条件也会变化，也需要数据库管理员不断修正，以满足用户要求

数据库性能的监督、分析和改进

在数据库运行过程中，数据库管理员必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。

• 利用监测工具获取系统运行过程中一系列性能参数的值
• 通过仔细分析这些数据，判断当前系统是否处于最佳运行状态
• 如果不是，则需要通过调整某些参数来进一步改进数据库性能

数据库的重组织与重构造

• 重组织
  • 为什么要重组织数据库 数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。
  • 重组织的形式：全部重组织和部分重组织，只对频繁增、删的表进行重组织
  • 重组织的目标：提高系统性能
• 重构造
  • 为什么要重构造数据库 数据库应用环境发生变化，会导致实体及实体间的联系也发生相应的变化，使原有的数据库设计不能很好地满足新的需求。
  • 重构造的主要工作 根据新环境调整数据库的模式和内模式增加或删除某些数据项、改变数据项的类型、增加或删除某个表、改变数据库的容量、增加或删除某些索引。
  • 重构造数据库的程度是有限的 若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大， 则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库应用系统了。

数据库三大范式

第一范式

第一范式的目标是确保每列的原子性，如果每列都是不可再分的最小数据单元（也称为最小的原子单元），则满足第一范式（1NF）

第二范式

如果一个关系满足第一范式，并且每列必须和主键相关，则满足第二范式 。第二范式要求每个表只描述一件事情。

第三范式

如果一个关系满足第二范式，并且表中各列必须和主键直接相关，不能间接相关，则满足第三范式

案例：规范化的酒店管理系统E-R图