1.数据库设计概述

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

信息管理要求：在数据库中应该存储和管理哪些数据对象 。

数据操作要求：对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作。

数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境 。

高效率的运行环境：

数据库数据的存取效率高。

数据库存储空间的利用率高 。

数据库系统运行管理的效率高。

1.数据库设计的特点

1. 数据库建设的基本规律： 三分技术，七分管理，十二分基础数据

管理 ：数据库建设项目管理 ，企业（即应用部门）的业务管理。

基础数据 ：数据的收集、整理、组织和不断更新。

数据库设计的基本步骤：

2.数据库设计过程中的各级模式

数据库设计不同阶段形成的数据库各级模式

2.需求分析

需求分析就是分析用户的要求： 是设计数据库的起点 。结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用

1.业务流分析

1、组织结构调查

2.业务流程调查

例：

3.数据流图

在需求分析阶段，数据流(也称信息流)是系统分析的基础。所谓数据流，形象地说就是系统中“流动的数据结构”。数据流图(DFD，Data Flow Diagram)是描述软件系统中数据处理过程的一种有力的图形工具。数据流图从数据传递和加工的角度出发，刻画数据流从输入到输出的移动和变换过程。由于它能够清晰地反映系统必须完成的逻辑功能，所以它已经成为需求分析阶段最常用的工具。

1．数据流图的用途      

画数据流图的基本目的是利用它作为交流信息的工具。数据流图的另一个主要用途是作为分析和设计的工具。

2．数据流图的组成符号  

1）基本符号

2）附加符号

数据流的画法：

数据流，即数据在系统内传播的路径，数据流使用带箭头的线条表示，指明了数据的流向，并在线条上标注数据流的名称

除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名

数据流通常由一个成分固定的数据结构组成，如订票单由旅客姓名、年龄、单位、身份证号、日期、目的地等数据项组成

在绘图时，需要注意数据流的两端必须至少有一端是处理过程

数据流必须起始或终止于处理过程：

外部项的画法：

数据源点（或终点），即数据的源头或要送达的终点，代表系统之外的实体，可以是人、物或其他软件系统，统称为外部实体。一般只出现在数据流图的顶层图中

外部实体常用矩形框表示，在框内写上相应的名称，如果一个外部项在同一张图上出现多次，则可在其右下画上小斜线，表示重复的项。如果重复的外部实体有多个，通常给相同的外部实体画上数目相同的小斜线以示区别

3.概念结构设计

1.概念模型

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

概念模型的特点：

（1）能真实、充分地反映现实世界，是现实世界的一个真实模型。

（2）易于理解，从而可以用它和不熟悉计算机的用户交换意见。

（3）易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。

（4）易于向关系、网状、层次等各种数据模型转换

描述概念模型的工具： E-R模型

2.E-R模型

1. 实体之间的联系

（1）两个实体型之间的联系：

①一对一联系（1∶1）：如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1∶1。 例如，学校里一个班级只有一个正班长，而一个班长只在一个班中任职，则班级与班长之间具有一对一联系。

②一对多联系（1∶n）：如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1∶n。

③多对多联系（m∶n）：如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m≥0）与之联系，则称实体集A与实体集B具有多对多联系，记为m∶n。

（2）两个以上的实体型之间的联系

一般地，两个以上的实体型之间也存在着一对一、一对多、多对多联系。

对于课程、教师与参考书3个实体型，如果一门课程可以有若干个教师讲授，使用若干本参考书，而每一个教师只讲授一门课程，每一本参考书只供一门课程使用，则课程与教师、参考书之间的联系是一对多的。

（3）单个实体型内的联系

同一个实体集内的各实体之间也可以存在一对一、一对多、多对多的联系。

例如，职工实体型内部具有领导与被领导的联系，即某一职工（干部）“领导”若干名职工，而一个职工仅被另外一个职工直接领导，因此这是一对多的联系。

联系的度：参与联系的实体型的数目

2个实体型之间的联系度为2，也称为二元联系；

3个实体型之间的联系度为3，称为三元联系；

N个实体型之间的联系度为N，也称为N元联系。

2. E-R图

E-R图提供了表示实体型、属性和联系的方法：

实体型：用矩形表示，矩形框内写明实体名。

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

例如，学生实体具有学号、姓名、性别、出生年份、系、入学时间等属性，用E-R图表示

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

例：某个工厂物资管理的概念模型。物资管理涉及的实体有： 仓库：属性有仓库号、面积、电话号码 零件：属性有零件号、名称、规格、单价、描述 供应商：属性有供应商号、姓名、地址、电话号码、账号 项目：属性有项目号、预算、开工日期 职工：属性有职工号、姓名、年龄、职称

这些实体之间的联系如下：  （1） 一个仓库可以存放多种零件，一种零件可以存放在多个 仓库中，因此仓库和零件具有多对多的联系。用库存量来表示某种零件在某个仓库中的数量。 （2） 一个仓库有多个职工当仓库保管员，一个职工只能在一个仓库工作，因此仓库和职工之间是一对多的联系。（3） 职工之间具有领导与被领导关系。即仓库主任领导若干保管员，因此职工实体型中具有一对多的联系。 （4） 供应商、项目和零件三者之间具有多对多的联系。即一 个供应商可以供给若干项目多种零件，每个项目可以使用不同供应商供应的零件，每种零件可由不同供应商供 给。

1. 实体与属性的划分原则

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

（1）作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。  

（2）属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。

例：如果一种货物只存放在一个仓库，那么就可以把存放货物的仓库的仓库号作为描述货物存放地点的属性。如果一种货物可以存放在多个仓库中，或者仓库本身又用面积作为属性，或者仓库与职工发生管理上的联系，那么就应把仓库作为一个实体。

4.逻辑结构设计

逻辑结构设计的任务 把概念结构设计阶段设计好的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构

1.E-R图向关系模型的转换

转换内容：

E-R图由实体型、实体的属性和实体型之间的联系三个要素组成 。

关系模型的逻辑结构是一组关系模式的集合。

将E-R图转换为关系模型：将实体型、实体的属性和实体型之间的联系转化为关系模式。

转换原则  ：

1. 一个实体型转换为一个关系模式。

关系的属性：实体的属性

关系的码：实体的码

2. 实体型间的联系有以下不同情况

（1） 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。

① 转换为一个独立的关系模式

关系的属性：与该联系相连的各实体的码以及联系本身的属性

关系的候选码：每个实体的码均是该关系的候选码

②与某一端实体对应的关系模式合并

合并后关系的属性：加入对应关系的码和联系本身的属性

合并后关系的码：不变

（2）一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。

①转换为一个独立的关系模式

关系的属性：与该联系相连的各实体的码以及联系本身的属性

关系的码：n端实体的码

②与n端对应的关系模式合并

合并后关系的属性：在n端关系中加入1端关系的码和联系本身的属性

合并后关系的码：不变

可以减少系统中的关系个数，一般情况下更倾向于采用这种方法

（3）一个m:n联系转换为一个关系模式

关系的属性：与该联系相连的各实体的码以及联系本身的属性

关系的码：各实体码的组合

（4）三个或三个以上实体间的一个多元联系转换为一个关系模式。

关系的属性：与该多元联系相连的各实体的码以及联系本身的属性

关系的码：各实体码的组合

（5）具有相同码的关系模式可合并

目的：减少系统中的关系个数

合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中。  然后去掉其中的同义属性（可能同名也可能不同名）。  适当调整属性的次序。

2.数据模型的优化

（1）确定数据依赖 按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。

（2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。     

（3）按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。

（4）按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。

并不是规范化程度越高的关系就越优 ：

当查询经常涉及两个或多个关系模式的属性时，系统必须经常地进行连接运算 。连接运算的代价是相当高的 。因此在这种情况下，第二范式甚至第一范式也许是适合的。

对关系模式进行必要分解，提高数据操作效率和存储空间的利用率。

常用分解方法： 水平分解， 垂直分解。

水平分解：

把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。

对符合80/20的，把经常被使用的数据（约20%） 水平分解出来，形成一个子关系。 水平分解为若干子关系，使每个事务存取的数据对应一个子关系。

垂直分解 ：把关系模式R的属性分解为若干子集合，形成若干子关系模式。

垂直分解的原则 ：经常在一起使用的属性从R中分解出来形成一个子关系模式

垂直分解的优点： 可以提高某些事务的效率

垂直分解的缺点 ：可能使另一些事务不得不执行连接操作，降低了效率。

垂直分解的适用范围 ：取决于分解后R上的所有事务的总效率是否得到了提高

垂直分解必须不损失关系模式的语义（保持无损连接性和保持函数依赖）

3.设计用户子模式

定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。

定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：

（1）使用更符合用户习惯的别名

合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。 用视图机制可以在设计用户视图时可以重新定义某些属性名，使其与用户习惯一致，以方便使用。

（2）针对不同级别的用户定义不同的视图，以保证系统的安全性。

（3）简化用户对系统的使用

如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。

5.物理结构设计

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

1.数据库物理设计的内容和方法

为关系模式选择存取方法（建立存取路径）

设计关系、索引等数据库文件的物理存储结构

2.关系模式存取方法选择

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

物理结构设计的任务之一是根据关系数据库管理系统支持的存取方法确定选择哪些存取方法。

数据库管理系统常用存取方法

1. B+树索引存取方法

选择索引存取方法的一般规则：

如果一个（或一组）属性经常在查询条件中出现， 则考虑在这个（或这组）属性上建立索引（或组合 索引）

如果一个属性经常作为最大值和最小值等聚集函数 的参数，则考虑在这个属性上建立索引

如果一个（或一组）属性经常在连接操作的连接条 件中 出现，则考虑在这个（或这组）属性上建立索引

关系上定义的索引数过多会带来较多的额外开销 ： 维护索引的开销  ，查找索引的开销。

2. Hash索引存取方法

如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一

该关系的大小可预知，而且不变； 该关系的大小动态改变，但所选用的数据库管理系统提供了动态Hash存取方法。

3. 聚簇存取方法

为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块中称为聚簇。 该属性（或属性组）称为聚簇码（cluster key） 。许多关系型数据库管理系统都提供了聚簇功能。

聚簇索引 ：

建立聚簇索引后，基表中数据也需要按指定的聚簇属性值的升序或降序存放。也即聚簇索引的索引项顺序与表中元组的物理顺序一致。 在一个基本表上最多只能建立一个聚簇索引

聚簇索引的适用条件  ：很少对基表进行增删操作  ，很少对其中的变长列进行修改操作。

聚簇的用途：

对于某些类型的查询，可以提高查询效率

1. 大大提高按聚簇属性进行查询的效率

2. 节省存储空间

聚簇以后，聚簇码相同的元组集中在一起了，因而聚簇码值不必在每个元组中重复存储，只要在一组中存一次就行了。

例：假设学生关系按所在系建有索引，现在要查询信息系的所有学生名单。

计算机系的500名学生分布在500个不同的物理块上时，至少要执行500次I/O操作。

如果将同一系的学生元组集中存放，则每读一个物理块可得到多个满足查询条件的元组，从而显著地减少了访问磁盘的次数。

聚簇的局限性  ：

聚簇只能提高某些特定应用的性能  。

建立与维护聚簇的开销相当大： 对已有关系建立聚簇，将导致关系中元组的物理存储位置移动，并使此关系上原有的索引无效，必须重建。 当一个元组的聚簇码改变时，该元组的存储位置也要做相应改变。

聚簇的适用范围 ：

既适用于单个关系独立聚簇，也适用于多个关系组合聚簇  

当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的时，可以使用聚簇

尤其当SQL语句中包含有与聚簇码有关的ORDER BY, GROUP BY, UNION, DISTINCT等子句或短语时，使用聚簇特别有利，可以省去或减化对结果集的排序操作

3.确定数据库的存储结构

确定数据库物理结构主要指确定数据的存放位置和存储结构，包括：确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。

确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价3个方面的因素。

影响数据存放位置和存储结构的因素 ：硬件环境 、应用需求 ：存取时间， 存储空间利用率， 维护代价。

1. 确定数据的存放位置

基本原则： 易变部分与稳定部分分开存放 ，经常存取部分与存取频率较低部分分开存放。

2. 确定系统配置

系统都为这些变量赋予了合理的缺省值。在进行物理设计时需要根据应用环境确定这些参数值，以使系统性能最优。

在物理设计时对系统配置变量的调整只是初步的，要根据系统实际运行情况做进一步的调整，以切实改进系统性能。

6.数据库的实施和维护

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

1. 数据库的转储和恢复    

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

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

初始定义 ：数据库管理员根据用户的实际需要授予不同的操作权限。 根据应用环境定义不同的完整性约束条件 。

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

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

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

利用监测工具获取系统运行过程中一系列性能参数的值

通过仔细分析这些数据，判断当前系统是否处于最佳运行状态

如果不是，则需要通过调整某些参数来进一步改进数据库性能

4. 数据库的重组织与重构造

（1）数据库的重组织

数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。

重组织的形式： 全部重组织， 部分重组织 （只对频繁增、删的表进行重组织 ）

重组织的目标 ：提高系统性能

重组织的工作：

按原设计要求 ：重新安排存储位置， 回收垃圾， 减少指针链。

数据库的重组织不会改变原设计的数据逻辑结构和物理结构

数据库管理系统一般都提供了供重组织数据库使用的实用程序，帮助数据库管理员重新组织数据库。

（2）数据库的重构造

数据库应用环境发生变化，会导致实体及实体间的联系也发生相应的变化，使原有的数据库设计不能很好地满足新的需求：

增加新的应用或新的实体， 取消某些已有应用 ，改变某些已有应用。

数据库重构造的主要工作 ：根据新环境调整数据库的模式和内模式 。增加或删除某些数据项 。改变数据项的类型 。增加或删除某个表。 改变数据库的容量 。增加或删除某些索引。

重构造数据库的程度是有限的， 若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大，则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库应用系统了。