数据库设计(3)

概念结构设计所得的E-R模型是对用户需求的一种抽象的表达形式，它独立于任何一种具体的数据模型，因而也不能为任何一个具体的DBMS所支持。为了能够建立起最终的物理系统，还需要将概念结构进一步转化为某一DBMS所支持的数据模型，然后根据逻辑设计的准则、数据的语义约束、规范化理论等对数据模型进行适当的调整和优化，形成合理的全局逻辑结构，并设计出用户子模式。这就是数据库逻辑设计所要完成的任务。

数据库逻辑结构的设计分为两个步骤：首先将概念设计所得的E-R图转换为关系模型；然后对关系模型进行优化，如图1.14所示。

图1.14  逻辑结构设计的过程

关系模型是由一组关系(二维表)的结合，而E-R模型则是由实体、实体的属性、实体间的关系三个要素组成。所以要将E-R模型转换为关系模型，就是将实体、属性和联系都要转换为相应的关系模型。下面具体介绍转换的规则。

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

将每种实体类型转换为一个关系，实体的属性就是关系的属性，实体的关键字就是关系的关键字。例如，可将“学生”实体转换为一个关系模型，如图1.15所示。其中，带下划线的属性为主属性，该主属性为关系模型外键。

图1.15  一个实体类型转换为一个关系模型

2. 一对一关系(1:1)的转换

一对一关系有以下两种转换方式：

l          转换为一个独立的关系模型。联系名为关系模型名，与该联系相连的两个实体的关键字及联系本身的属性为关系模型的属性，其中每个实体的关键字均是该关系模型的候选键。

l          与任意一端的关系模型合并。可将相关的两个实体分别转换为两个关系，并在任意一个关系的属性中加入另一个关系的主关键字。

例如，若某工厂的每个仓库只配备了一名管理员，那么仓库实体与管理员实体间便为1:1关系。根据以上介绍的原则，可以进行如图1.16所示的变换。

图1.16  1:1关系的转换

在实际设计中究竟采用哪种方案可视具体的应用而定。如果经常要在查询仓库关系的同时查询此仓库管理员的信息，就可选用前一种关系模型，以减少查询时的连接操作。反之，如果在查询管理员时要频繁查询仓库信息，则选用后一种关系模型。总之，在模型转换出现较多方案时，效率是重要的取舍因素。

3. 一对多关系(1:n)的转换

一对多关系也有两种转换方式：

l          将1:n关系转换为一个独立的关系模型。联系名为关系模型名，与该联系相连的各实体的关键字及联系本身的属性为关系模型的属性，关系模型的关键字为n端实体的关键字。

l          将1:n联系与n端关系合并。1端的关键字及联系的属性并入n端的关系模型    即可。

在图1.17中，实体“专业”和“学生”之间的联系为1:n，则两者可使用以上的原则进行关系模型的转换。

图1.17  1:n 联系的转换

4. 多对多关系(m:n)的转换

关系模型名为关系名，与该关系相连的各实体的关键字及关系本身的属性为关系模型的属性，关系模型的关键字为关系中各实体关键字的并集。

例如，在学校中，一名学生可以选修多门课程，一门课程也可为多名学生选修，则实体“学生”与“课程”之间满足多对多的关系，其转换方法如图1.18所示。

图1.18  m:n关系的转换

数据库物理设计阶段的任务是根据具体计算机系统(DBMS和硬件等)的特点，为给定的数据库模型确定合理的存储结构和存取方法。所谓的“合理”主要有两个含义：一个是要使设计出的物理数据库占用较少的存储空间，另一个对数据库的操作具有尽可能高的速度。

为了设计数据库的物理结构，设计人员必须充分了解所用DBMS的内部特征；充分了解数据系统的实际应用环境，特别是数据应用处理的频率和响应时间的要求；充分了解外存储设备的特性。数据库的物理结构设计大致包括：确定数据的存取方法、确定数据的存储结构。

物理结构设计阶段实现的是数据库系统的内模式，它的质量直接决定了整个系统的性能。因此在确定数据库的存储结构和存取方法之前，对数据库系统所支持的事务要进行仔细分析，获得优化数据库物理设计的参数。

对于数据库查询事务，需要得到如下信息：

l          要查询的关系。

l          查询条件(即选择条件)所涉及的属性。

l          连接条件所涉及的属性。

l          查询的投影属性。

对于数据更新事务，需要得到如下信息：

l          要更新的关系。

l          每个关系上的更新操作的类型。

l          删除和修改操作所涉及的属性。

l          修改操作要更改的属性值。

上述这些信息是确定关系存取方法的依据。除此之外，还需要知道每个事务在各关系上运行的频率，某些事务可能具有严格的性能要求。例如，某个事务必须在20秒内结束。这种时间约束对于存取方法的选择有重大的影响。需要了解每个事务的时间约束。

值得注意的是，在进行数据库物理结构设计时，通常并不知道所有的事务，上述信息可能不完全。所以，以后可能需要修改根据上述信息设计的物理结构，以适应新事务的要求。

1. 确定关系模型的存取方法

确定数据库的存取方法，就是确定建立哪些存储路径以实现快速存取数据库中的数据。现行的DBMS一般都提供了多种存取方法，如索引法、HASH法等。其中，最常用的是索引法。

数据库的索引类似书的目录。在书中，目录允许用户不必浏览全书就能迅速地找到所需要的位置。在数据库中，索引也允许应用程序迅速找到表中的数据，而不必扫描整个数据库。在书中，目录就是内容和相应页号的清单。在数据库中，索引就是表中数据和相应存储位置的列表。使用索引可以大大减少数据的查询时间。

但需要注意的是索引虽然能加速查询的速度，但是为数据库中的每张表都设置大量的索引并不是一个明智的做法。这是因为增加索引也有其不利的一面：首先，每个索引都将占用一定的存储空间，如果建立聚簇索引(会改变数据物理存储位置的一种索引)，占用需要的空间就会更大；其次，当对表中的数据进行增加、删除和修改的时候，索引也要动态地维护，这样就降低了数据的更新速度。

在创建索引的时候，一般遵循以下的一些经验性原则：

l          在经常需要搜索的列上建立索引。

l          在主关键字上建立索引。

l          在经常用于连接的列上建立索引，即在外键上建立索引。

l          在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的。

l          在经常需要排序的列上建立索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询的时间。

l          在经常成为查询条件的列上建立索引。也就是说，在经常使用在WHERE子句中的列上面建立索引。

同样，对于某些列不应该创建索引。这时候应该考虑下面的指导原则：

l          对于那些在查询中很少使用和参考的列不应该创建索引。因为既然这些列很少使用到，有索引并不能提高查询的速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。

l          对于那些只有很少值的列不应该建立索引。例如，人事表中的“性别”列，取值范围只有两项：“男”或“女”。若在其上建立索引，则平均起来，每个属性值对应一半的元组，用索引检索，并不能明显加快检索的速度。

l          属性值分布严重不均的属性。例如学生的年龄往往集中在几个属性值上，若在年龄属性上建立索引，则在检索某个年龄的学生时，会涉及相当多的学生。

l          过长的属性，例如超过30个字节。因为在过长的属性上建立索引，索引所占的存储空间较大，而索引的级数也随之增加，有诸多不利之处。如果实在需要在其上建立索引，必须采取索引属性压缩的措施。

l          经常更新的属性或表。因为在更新时有关的索引需要做相应的修改。

最后举个简单的例子，说明究竟哪些情况下需要建立索引以提高效率。假设，某个大学需要建立一个学生成绩的数据库系统，整个系统包括三个数据表：课程信息表、学生信息表和学生成绩表。数据库的结构如下：

l          学生信息表(学号、姓名、出生日期、性别、系名、班号)

l          课程信息表(课程号、课程名、教师、学分)

l          学生成绩表(学号、课程号、成绩)

整个系统需要统计学生的平均分、某课程的平均分等，所以学生信息表中的属性“学号”，课程信息表中的属性“课程号”，学生成绩表中的属性“学号”、“课程号”将经常出现在查询条件中，可以考虑在上面建立索引以提高效率。

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

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

确定数据存放位置是按照数据应用的不同将数据库的数据划分为若干类，并确定各类数据的大小和存放位置。数据的分类可依据数据的稳定性、存取响应速度、存取频度、数据共享程度、数据保密程度、数据生命周期的长短、数据使用的频度等因素加以区别。

确定数据存放的位置主要是从提高系统性能的角度考虑。由于不同的系统和不同应用环境有不同的应用需求，所以在此只列出一些启发性的规则。

l          在大型系统中，数据库的数据备份、日志文件备份等数据只在故障恢复时才使用，而且数据量很大，可以考虑放在磁带上。

l          对于拥有多个磁盘驱动器或磁盘阵列的系统，可以考虑将表和索引分别存放在不同的磁盘上，在查询时，由于两个磁盘驱动器分别工作，因而可以保证物理读写速度比较快。

l          将比较大的表分别存放在不同的磁盘上，可以加快存取的速度，特别是在多用户的环境下。

l          将日志文件和数据库对象(表、索引等)分别放在不同的磁盘可以改进系统的性能。

由于各个系统所能提供的对数据进行物理安排的手段、方法差异很大，因此设计人员应该在仔细了解给定的DBMS在这方面提供了什么方法、系统的实际应用环境的基础上进行物理安排。

3. 确定系统存储参数的配置

现行的许多DBMS都设置了一些系统的配置变量，供设计人员和DBA(数据库管理员)进行物理的优化。在初始情况下，系统都为这些变量赋予了合理的初值。但是这些值只是从产品本身特性出发，不一定能适应每一种应用环境，在进行物理结构设计时，可以重新对这些变量赋值以改善系统的性能。以Microsoft公司的SQL Server 2000为例，它为用户提供的配置变量包括：同时使用数据库的用户数、同时打开的数据库对象数，使用的缓冲区长度、个数，数据库的大小，索引文件的大小，锁的数目等。

应该指出，在物理结构设计对系统配置变量的调整只是初步的，在系统运行时还需要根据系统实际的运行情况做进一步的调整，以获得最佳的系统性能。

在进行概念结构设计和物理结构设计之后，设计者对目标系统的结构、功能已经分析得较为清楚了，但这还只是停留在文档阶段。数据系统设计的根本目的，是为用户提供一个能够实际运行的系统，并保证该系统的稳定和高效。要做到这点，还有两项工作，就是数据库的实施、运行和维护。

1. 数据库的实施

数据库的实施主要是根据逻辑结构设计和物理结构设计的结果，在计算机系统上建立实际的数据库结构、导入数据并进行程序的调试。它相当于软件工程中的代码编写和程序调试的阶段。

用具体的DBMS提供的数据定义语言(DDL)，把数据库的逻辑结构设计和物理结构设计的结果转化为程序语句，然后经DBMS编译处理和运行后，实际的数据库便建立起来了。目前的很多DBMS系统除了提供传统的命令行方式外，还提供了数据库结构的图形化定义方式，极大地提高了工作的效率。

具体地说，建立数据库结构应包括以下几个方面：

l          数据库模式与子模式，以及数据库空间的描述。

l          数据完整性的描述。

l          数据安全性描述。

l          数据库物理存储参数的描述。

此时的数据库系统就如同刚竣工的大楼，内部空空如也。要真正发挥它的作用，还有必须装入各种实际的数据。

2. 数据库的试运行

当有部分数据装入数据库以后，就可以进入数据库的试运行阶段，数据库的试运行也称为联合调试。数据库的试运行对于系统设计的性能检测和评价是十分重要的，因为某些DBMS参数的最佳值只有在试运行中才能确定。

由于在数据库设计阶段，设计者对数据库的评价多是在简化了的环境条件下进行的，因此设计结果未必是最佳的。在试运行阶段，除了对应用程序做进一步的测试之外，重点执行对数据库的各种操作，实际测量系统的各种性能，检测是否达到设计要求。如果在数据库试运行时，所产生的实际结果不理想，则应回过头来修改物理结构，甚至修改逻辑结构。

3. 数据库的运行和维护

数据库系统投入正式运行，意味着数据库的设计与开发阶段的基本结束，运行与维护阶段的开始。数据库的运行和维护是个长期的工作，是数据库设计工作的延续和提高。

在数据库运行阶段，完成对数据库的日常维护，工作人员需要掌握DBMS的存储、控制和数据恢复等基本操作，而且要经常性地涉及物理数据库、甚至逻辑数据库的再设计，因此数据库的维护工作仍然需要具有丰富经验的专业技术人员(主要是数据库管理员)来完成。

数据库的运行和维护阶段的主要工作有：

l          对数据库性能的监测、分析和改善。

l          数据库的转储和恢复。

l          维持数据库的安全性和完整性。

l          数据库的重组和重构。