数据库实用教程ppt课件

7.5 逻辑(结构)设计 概念设计的结果是得到一个与DBMS无关的概念模式。而逻辑设计的目的是把概念设 计阶段设计好的全局ER模式转换成与选用的具体机器上的DBMS所支援的数据模型相符合的的逻辑结构（包括数据库模式和外模式）。这些模式在功能上、完整性和一致性约束及数据库的可扩充性等方面均应满足用户的各种要求。对于逻辑设计而言，应首先选择DBMS，但往往数据库设计人员没有挑选的余地，都是在指定的DBMS上进行逻辑结构的设计。,1,7.5.1 逻辑设计环境 逻辑设计的输入输出环境如图7.22所示,2,在逻辑设计阶段主要输入下列信息： （1）独立于DBMS的概念模式。这是概念设计阶段产生的所有局部和全局概念模式。 （2）处理需求。需求分析阶段产生的业务活动分析结果。这里包括数据的规模和应用频率，用户或用户集团的需求。 （3）约束条件。即完整性、一致性、安全性要求及响应时间要求等等。 （4）DBMS特性。即特定的DBMS所支持的模式、子模式和程序语法的形式规则。,3,在逻辑设计阶段主要输出如下的信息： （1）DBMS可处理的模式。一个能用特定 DBMS实现的数据库结构的说明，但是不包括记录的聚合、块的大小等物理参数的说明，但要对某些访问路径参数（如顺序、指针检索的类型）加以说明。 （2）子模式。与单个用户观点和完整性约束一致的DBMS所支持的数据结构。 （3）应用程序设计指南。根据设计的数据库结构为应用程序员提供访问路径选择。 （4）物理设计指南。完全文档化的模式和子模式应包括容量、使用频率、软硬件等信息。这些信息将要在物理设计阶段使用,4,7.5.2 逻辑设计的步骤 逻辑设计主要是把概念模式转换成DBMS能处理的模式。转换过程中要对模式进行评 价和性能测试，以便获得较好的模式设计。逻辑设计的主要步骤如图7.23所示。 1初始模式的形成； 这一步是形成初始的 DBMS模式。 根据概念模式以及DBMS的记录类型特点，将ER模式的实体类型或联系类型转换成记录类型，在比较复杂的情况下，实体可能分裂或合并成新的记录类型。,5,6,2子模式设计 子模式是模式的逻辑子集。子模式是应用程序和数据库系统的接口，它能允许应用程序有效地访问数据库中的数据，而不破坏数据库的安全性。 3应用程序设计梗概 在设计完整的应用程序之前，先设计出应用程序的草图，对每个应用程序应设计出数据存取功能的梗概，提供程序上的逻辑接口。,7,4模式评价 这一步的工作就是对数据库模式进行评价。评价数据库结构的方法通常有定量分析和性能测量等方法。 定量分析有两个参数：处理频率和数据容量。处理频率是在数据库运行期间应用程序的使用次数；数据容量是数据库中记录的个数。数据库增长过程的具体表现就是这两个参 数值的增加。 性能测量是指逻辑记录的访问数目、一个应用程序传输的总字节数。数据库的总字节 数，这些参数应该尽可能预先知道，它能预测物理数据库的性能。,8,5修正模式 修正模式的目的是为了使模式适应信息的不同表示。此时，可利用DBMS的性能，如索引或散列功能，但数据库的信息内容不能修改。如果信息内容不修改，模式就不能进一步求精，那么就要停止模式设计，返回到概念设计或需求分析阶段，重新设计。,9,7.5.3 ER模型向关系模型的转换 1. ER模型转换为关系模型的一般规则 ER模型中的主要成分是实体类型和联系类型，转换规则就是如何把实体类型、联系类型转换成关系模式。 （1）实体类型的转换：将每个实体类型转换成一个关系模式，实体的属性即为关系模式的属性，实体标识符即为关系模式的键。,10,（2）联系类型的转换，根据不同的情况做不同的处理： 若实体间的联系是1：1的，可以在两个实体类型转换成的两个关系模式中的任意一个关系模式的属性中加人另一个关系模式的键和联系类型的属性。,11,例79 某大学管理中的实体“院长”与“学院之间存在着1:1的联系，其ER图如724所示。在将其转化为关系模型时，“院长与“学院”各为一个模式。如果用户经常要在查询学院信息时查询其院长信息，那么可在学院模式中加人院长名和任职年月，其关系模式设计如下（加下划线者为主键，加波浪线者为外键）： 学院关系模式（学院编号，学院名，地址，电话，院长名，任职年月） 院长关系模式（院长名，年龄，性别，职称),12,13,若实体间的联系是1:N的，则在N端实体类型转换成的关系模式中加入1端实体类 型转换成的关系模式的键和联系类型的属性。 例710某大学管理中的实体“系”与“教师”之间存在着1：N的联系，其ER图如725所示。转换成的关系模式如下： 系关系模式（系编号，系名，电话，系主任） 教师关系模式（教师编号，姓名，年龄，性别，职称，系编号，聘用年月）,14,弱实体：若实体间的联系是1：N的，而且在N端实体类型为弱实体，转换成的关系模式中将1端实体类型（父表）的键作为外键放在N端的弱实体（子表）中。弱实体的主键由父表的主键与弱实体本身的候选键组成。也可以为弱实体建立新的独立的标识符 ID。 例711某大学管理中的实体“学生”与弱实体“社会关系”之间存在着1：N的联系，其ER图如726所示。转换成的关系模式如下： 学生关系模式（学生编号，姓名，年龄，性别，家庭地址，所在系，班号） 社会关系模式（学生编号，称呼，姓名，年龄，政治面貌，工作单位）,15,16,若实体间的联系是M：N的，则将联系类型也转换成关系模式，其属性为两端实体类型的键加上联系类型的属性，而键为两端实体键的组合。 例712某大学管理中的实体“学生”与“课程”之间存在着M：N的联系，其ER图如727所示。转换成的关系模式如下： 学生关系模式（学生编号，姓名，年龄，性别，家庭地址，所在系，班号） 课程关系模式（课程编号，课程名，课程性质，学分数，先行课，开课学期，开课系编号） 选修关系模式（学生编号，课程编号，成绩）,17,18,2超类和子类的转换规则 将超类和子类各转换成一个关系模式，在子类转换成的关系模式（子表）中加入超类转换成关系模式（父表）的键，从而实现父表与子表的联系。由于父表与子表的主键相同，所子表的主键也是外键。 例 7.13某大学数据库中的实体“教师”（超类）的成员实体也可以分为教授、副教授，讲师和助教四个子实体集合（子类）如图728所示。,19,转换成的关系模式如下： 教师关系模式（教师编号，姓名，年龄，性别） 教授关系模式（教师编号，是否博导） 副教授关系模式（教师编号，是否硕导） 讲师关系模式（教师编号，学历，是否班导师） 助教关系模式（教师编号，导师姓名）,20,7.5.4 关系数据库的逻辑设计 由于关系模型的固有优点，逻辑设计可以运用关系数据库模式设计理论使设计过程形式化地进行，并且结果可以验证。关系数据库的逻辑设计的过程如图 729所示。,21,从图729可以看出，概念设计的结果直接影响到逻辑设计过程的复杂性和效率。在概念设计阶段已经把关系规范化的某些思想用作构造实体类型和联系类型的标准，在逻辑设计阶段，仍然要使用关系规范化理论来设计模式和评价模式。关系数据库的逻辑设计的结果是一组关系模式的定义。 1导出初始关系模式 逻辑设计的第一步是把概念设计的结果（即全局ER模式）转换成初始关系模式。,22,2规范化处理 规范化的目的是减少乃至消除关系模式中存在的各种异常，改善完整性、一致性和存储效率。规范化过程分为两个步骤： (1) 确定规范级别 规范级别取决于两个因素，一是归结出来的数据依赖的种类，二是实际应用的需要。在这里，我们主要从数据依赖的种类出发，来讨论规范级别问题。 首先考察数据依赖集合。在仅有函数依赖时，3NF或BCNF是适宜的标准,23,如还包括多值依赖时，应达到4NF。由于多值依赖语义的复杂性、非直观性，一般使用得并不多。 在现实环境中，大量作用的还是函数依赖。 （2）实施规范化处理 确定规范级别之后，利用第5章的算法，逐一考察关系模式，判断它们是否满足规范要求。若不符合上下步所确定的规范级别，则利用相应的规范算法将关系模式规范化。 在规范化综合或分解过程中，要特别注意保持依赖和无损联接要求。,24,综合以上数据库的设计过程，规范化理论在数据库设计中有如下几方面的应用： (1) 在需求分析阶段，用数据依赖概念分析和表示各个数据项之间的联系。 (2) 在概念结构设计阶段，以规范化理论为指导，确定关系键，消除初步E-R图中冗余的联系。 (3) 在逻辑结构设计阶段，从E-R图向数据模型转换过程中，用模式合并与分解方法达到规范化级别。,25,(3) 模式评价 关系模式的规范化不是目的而是手段，数据库设计的目的是最终满足应用需求。因此，为了进一步提高数据库应用系统的性能，还应该对规范化后产生的关系模式进行评价、改进，经过反复多次的尝试和比较，最后得到优化的关系模式。 模式评价的目的是检查所设计的数据库模式是否满足用户的功能要求、效率，确定加以改进的部分。模式评价包括功能评价和性能评价。,26,(A) 功能评价 功能评价指对照需求分析的结果，检查规范化后的关系模式集合是否支持用户所有的应用要求。关系模式必须包括用户可能访问的所有属性。在涉及多个关系模式的应用中，应确保联接后不丢失信息。如果发现有的应用不被支持，或不完全被支持，则应该改进关系模式。发生这种问题的原因可能是在逻辑设计阶段，也可能是在需求分析或概念设计阶段。是哪个阶段的问题就返回到哪个阶段去，因此有可能对前两个阶段再进行评审，解决存在的问题。,27,在功能评价的过程中，可能会发现冗余的关系模式或属性，这时应对它们加以区分，搞清楚它们是为未来发展预留的，还是某种错误造成的，比如名字混淆。如果属于错误处置，进行改正即可，而如果这种冗余来源于前两个设计阶段，则也要返回重新进行评审。 (B) 性能评价 对于目前得到的数据库模式，由于缺乏物理设计所提供的数量测量标准和相应的评价手段，所以性能评价是比较困难的，只能对实际性能进行估计，包括逻辑记录的存取数、传送量以及物理设计算法的模型等。,28,美国密执安大学的T.Teorey和J.Fry于1980年提出的逻辑记录访问（Logical Record Access，LRA）方法是一种常用的模式性能评价方法。LRA方法对网状模型和层次模型较为实用，对于关系模型的查询也能起一定的估算作用。 有关LRA方法本书不详细介绍，读 者可以参考有关书籍。,29,(4) 模式改进 根据模式评价的结果，对已生成的模式进行改进。 如果因为需求分析、概念设计的疏漏导致某些应用不能得到支持，则应该增加新的关系模式或属性。 如果因为性能考虑而要求改进，则可采用合并或分解的方法。 (A) 合并 如果有若干个关系模式具有相同的主键，并且对这些关系模式的处理主要是查询操作，而且经常是多关系的查询，那么可对这些关系模式按照组合使用频率进行合并。 这样便可以减少联接操作而提高查询效率。,30,(B) 分解 为了提高数据操作的效率和存储空间的利用率，最常用和最重要的模式优化方法就是分解，根据应用的不同要求，可以对关系模式进行垂直分解和水平分解。 水平分解是把关系的元组分为若干子集合，定义每个子集合为一个子关系。 对于经常进行大量数据的分类条件查询的关系，可进行水平分解，这样可以减少应用系统每次查询需要访问的记录数，从而提高了查询性能。,31,例如，有学生关系（学号，姓名，类别），其中类别包括大专生、本科生和研究生。如果多数查询一次只涉及其中的一类学生，就应该把整个学生关系水平分割为大专生、本科生和研究生三个关系。 垂直分解是把关系模式的属性分解为若干子集合，形成若干子关系模式。垂直分解的原则是把经常一起使用的属性分解出来，形成一个子关系模式。 例如，有教师关系（教师号，姓名，性别，年龄，职称，工资，岗位津贴，住址，电话），如果经常查询的仅是前六项，而后三项很少使用，则可以将教师关系进行垂直分割，得到两个教师关系：,32,教师关系1（教师号，姓名，性别，年龄，职称，工资） 教师关系2（教师号，岗位津贴，住址，电话） 这样，便减少了查询的数据传递量，提高了查询速度。 垂直分解可以提高某些事务的效率，但也有可能使另一些事务不得不执行连接操作，从而降低了效率。因此是否要进行垂直分解要看分解后的所有事务的总效率是否得到了提高。垂直分解要保证分解后的关系具有无损连接性和函数依赖保持性。相关的分解算法已经在第4章进行了详细介绍。,33,经过多次的模式评价和模式改进之后，最终的数据库模式得以确定。逻辑设计阶段的结果是全局逻辑数据库结构。对于关系数据库系统来说，就是一组符合一定规范的关系模式组成的关系数据库模型。 数据库系统的数据物理独立性特点消除了由于物理存储改变而引起的对应程序的修改。标准的DBMS例行程序应适用于所有的访问，查询和更新事务的优化应当在系统软件一级上实现。这样，逻辑数据库确定之后，就可以开始进行应用程序设计了。,34,例715 学员王洪林为浙江省黄骅纸制品公司设计的“库存销售信息管技系统”对仓库、车间、产品、客户、销售部的信息进行了有效的管理，其ER图如图730所示。,35,这个ER图有5个实体类型，其属性如下： 车间：车间号，车间名，主任名。 产品：产品号，产品名，单价。 仓位：仓位号，地址，主任名。 客户：客户号，客户名，联系人，电话，地址，税号，账号。 销售员：销售员号，姓名，性别，学历，业绩。,36,这个ER图有4个联系类型，其中3个是M：N：P， 1个是M：N，属性如下： 入库：入库单号，入库量，入库日期，经手人。 存储：核对日期，核对员，存储量。 出库：出库单号，出库量，出库日期，经手人。 定单：定单号，数量，折扣，总价，定单日期。 试把这个ER图转换成关系模型，并指出每个表的主键和外键。,37,解根据ER模型转换成关系模型的规则，可把上述ER图转换成9个关系模式，具体如下： 车间（车间号，车间名，主任名） 产品（产品号，产品名，单价） 仓位（仓位号，地址，主任名） 客户（客户号，客户名，联系人，电话，地址，税号，账号）,38,销售员（销售员号，姓名，性别，学历，业绩） 入库（入库单号，入库量，入库日期，经手人，车间号，仓位号，产品号） 存储（仓位号，产品号，核对日期，核对员，存储量） 出库（出库单号，出库量，出库日期，经手人，客户号，产品号，仓位号） 定单（定单号，数量，折扣，总价，定单日期，产品号，客户号，销售员号）,39,7.6 数据库物理设计 数据库最终要存储在物理设备上。对于给定的逻辑数据模型，选取一个最适合应用环境的物理结构的过程，称为数据库物理设计。数据库的物理结构主要指数据库的存储记录格式、存储记录安排和存取方法。显然，数据库的物理设计是完全依赖于给定的硬件环境和数据库产品的。 在关系模型系统中，物理设计比较简单一些，因为文件形式是单记录类型文件，仅包含索引机制、空间大小、块的大小等内容。,40,数据库的物理设计可分为两步： (1) 确定物理结构，在关系数据库中主要指存取方法和存储结构； (2)评价物理结构，评价的重点是时间和空间效率。 7.6.1 确定物理结构 设计人员必须深入了解给定的DBMS的功能，DBMS提供的环境和工具、硬件环境,特别是存储设备的特征。另一方面也要了解应用环境的具体要求，如各种应用的数据量、处理频率和响应时间等。只有“知己知彼”才能设计出较好的物理结构。,41,1存储记录结构的设计 在物理结构中，数据的基本存取单位是存储记录。有了逻辑记录结构以后，就可以设计存储记录结构，一个存储记录可以和一个或多个逻辑记录相对应。存储记录结构包括记录的组成、数据项的类型和长度，以及逻辑记录到存储记录的映射。某一类型的所有存储记录的集合称为“文件”，文件的存储记录可以是定长的，也可以是变长的。 文件组织或文件结构是组成文件的存储记录的表示法。文件结构应该表示文件格式、逻辑次序、物理次序、访问路径、物理设备的分配。物理数据库就是指数据库中实际存储记录的格式、逻辑次序和物理次序、访问路径、物理设备的分配。 决定存储结构的主要因素包括存取时间、存储空间和维护代价三个方面。设计时应当根据实际情况对这三个方面进行综合权衡。一般DBMS也提供一定的灵活性可供选择，包括聚簇和索引。,42,(1) 聚簇（Cluster） 聚簇就是为了提高查询速度，把在一个（或一组）属性上具有相同值的元组集中地存放在一个物理块中。如果存放不下，可以存放在相邻的物理块中。其中，这个（或这组）属性称为聚簇码。 为什么要使用聚簇呢？聚簇有两个作用： 使用聚簇以后，聚簇码相同的元组集中在一起了，因而聚簇值不必在每个元组中重复存储，只要在一组中存储一次即可，因此可以节省存储空间。,43,聚簇功能可以大大提高按聚簇码进行查询的效率。例如，假设要查询学生关系中计算机系的学生名单，设计算机系有300名学生。在极端情况下，这些学生的记录会分布在300个不同的物理块中，这时如果要查询计算机系的学生，就需要做300次的I/O操作，这将影响系统查询的性能。如果按照系别建立聚簇，使同一个系的学生记录集中存放，则每做一次I/O操作，就可以获得多个满足查询条件和记录，从而显著地减少了访问磁盘的次数。,44,(2) 索引 存储记录是属性值的集合，主关系键可以惟一确定一个记录，而其他属性的一个具体值不能惟一确定是哪个记录。在主关系键上应该建立惟一索引，这样不但可以提高查询速度，还能避免关系键重复值的录入，确保了数据的完整性。 在数据库中，用户访问的最小单位是属性。如果对某些非主属性的检索很频繁，可以考虑建立这些属性的索引文件。索引文件对存储记录重新进行内部链接，从逻辑上改变了记录的存储位置，从而改变了访问数据的入口点。关系中数据越多索引的优越性也就越明显。,45,建立多个索引文件可以缩短存取时间，但是增加了索引文件所占用的存储空间以及维护的开销。因此，应该根据实际需要综合考虑。 2访问方法的设计 访问方法是为存储在物理设备（通常指辅存）上的数据提供存储和检索能力的方法。一个访问方法包括存储结构和检索机构两个部分。存储结构限定了可能访问的路径和存储记录；检索机构定义了每个应用的访问路径，但不涉及存储结构的设计和设备分配。,46,存储记录是属性的集合，属性是数据项类型，可用作主键或辅助键。主键惟一地确定了一个记录。辅助键是用作记录索引的属性，可能并不惟一确定某一个记录。 访问路径的设计分成主访问路径与辅访问路径的设计。主访问路径与初始记录的装入有关，通常是用主键来检索的。首先利用这种方法设计各个文件，使其能最有效地处理主要的应用。一个物理数据库很可能有几套主访问路径。辅访问路径是通过辅助键的索引对存储记录重新进行内部链接，从而改变访问数据的入口点。用辅助索引可以缩短访问时间，但增加了辅存空间和索引维护的开销。设计者应根据具体情况作出权衡。,47,3.数据存放位置的设计 为了提高系统性能，应该根据应用情况将数据的易变部分、稳定部分、经常存取部分和存取频率较低部分分开存放。 例如，目前许多计算机都有多个磁盘，因此可以将表和索引分别存放在不同的磁盘上，在查询时，由于两个磁盘驱动器并行工作，可以提高物理读写的速度。 在多用户环境下，可能将日志文件和数据库对象（表、索引等）放在不同的磁盘上，以加快存取速度。另外，数据库的数据备份、日志文件备份等，只在数据库发生故障进行恢复时才使用，而且数据量很大，可以存放在磁带上，以改进整个系统的性能。,48,4.系统配置的设计 DBMS产品一般都提供了一些系统配置变量、存储分配参数，供设计人员和DBA对数据库进行物理优化。系统为这些变量设定了初始值，但是这些值不一定适合每一种应用环境，在物理设计阶段，要根据实际情况重新对这些变量赋值，以满足新的要求。 系统配置变量和参数很多，例如，同时使用数据库的用户数、同时打开的数据库对象数、内存分配参数、缓冲区分配参数（使用的缓冲区长度、个数）、存储分配参数、数据库的大小、时间片的大小、锁的数目等，这些参数值影响存取时间和存储空间的分配，在物理设计时要根据应用环境确定这些参数值，以使系统的性能达到最优。,49,7.6.2 评价物理结构 和前面几个设计阶段一样，在确定了数据库的物理结构之后，要进行评价，重点是时间和空间的效率。 如果评价结果满足设计要求，则可进行数据库实施。 实际上，往往需要经过反复测试才能优化物理设计。,50,7.7 数据库实施 数据库实施是指根据逻辑设计和物理设计的结果，在计算机上建立起实际的数据库结构、装入数据、进行测试和试运行的过程。 数据库实施主要包括以下工作： 建立实际数据库结构； 装入数据； 应用程序编码与调试； 数据库试运行； 整理文档。,51,7.7.1 建立实际数据库结构 DBMS提供的数据定义语言（DDL）可以定义数据库结构。可使用第3章所讲的SQL定义语句中的CREATE TABLE语句定义所需的基本表，使用CREATE VIEW语句定义视图。 7.7.2 装入数据 装入数据又称为数据库加载（Loading），是数据库实施阶段的主要工作。在数据库结构建立好之后，就可以向数据库中加载数据了。,52,由于数据库的数据量一般都很大，它们分散于一个企业（或组织）中各个部门的数据文件、报表或多种形式的单据中，它们存在着大量的重复，并且其格式和结构一般都不符合数据库的要求，必须把这些数据收集起来加以整理，去掉冗余并转换成数据库所规定的格式，这样处理之后才能装入数据库。因此，需要耗费大量的人力、物力，是一种非常单调乏味而又意义重大的工作。,53,由于应用环境和数据来源的差异，所以不可能存在普遍通用的转换规则，现有的DBMS并不提供通用的数据转换软件来完成这一工作。 对于一般的小型系统，装入数据量较少，可以采用人工方法来完成。 首先将需要装入的数据从各个部门的数据文件中筛选出来，转换成符合数据库要求的数据格式， 然后输入到计算机中， 最后进行数据校验，检查输入的数据是否有误。,54,但是，人工方法不仅效率低，而且容易产生差错。对于数据量较大的系统，应该由计算机来完成这一工作。通常是设计一个数据输入子系统，其主要功能是从大量的原始数据文件中筛选、分类、综合和转换数据库所需的数据，把它们加工成数据库所要求的结构形式，最后装入数据库中，同时还要采用多种检验技术检查输入数据的正确性。 为了保证装入数据库中数据的正确无误，必须高度重视数据的校验工作。在输入子系统的设计中应该考虑多种数据检验技术，在数据转换过程中应使用不同的方法进行多次检验，确认正确后方可入库。,55,如果在数据库设计时，原来的数据库系统仍在使用，则数据的转换工作是将原来老系统中的数据转换成新系统中的数据结构。同时还要转换原来的应用程序，使之能在新系统下有效地运行。 数据的转换、分类和综合常常需要多次才能完成，因而输入子系统的设计和实施是很复杂的，需要编写许多应用程序，由于这一工作需要耗费较多的时间，为了保证数据能够及时入库，应该在数据库物理设计的同时编制数据输入子系统，而不能等物理设计完成后才开始。,56,7.7.3 应用程序编码与调试 数据库应用程序的设计属于一般的程序设计范畴，但数据库应用程序有自己的一些特点。例如，大量使用屏幕显示控制语句、形式多样的输出报表、重视数据的有效性和完整性检查、有灵活的交互功能。 为了加快应用系统的开发速度，一般选择第四代语言开发环境，利用自动生成技术和软件复用技术，在程序设计编写中往往采用工具（CASE）软件来帮助编写程序和文档，如目前普遍使用的PowerBuilder、Delphi以及由北京航空航天大学研制的863/CMIS支持的数据库开发工具OpenTools等。,57,数据库结构建立好之后，就可以开始编制与调试数据库的应用程序，这时由于数据入库尚未完成，调试程序时可以先使用模拟数据。 7.7.4 数据库试运行 应用程序编写完成，并有了一小部分数据装入后，应该按照系统支持的各种应用分别试验应用程序在数据库上的操作情况，这就是数据库的试运行阶段，或者称为联合调试阶段。在这一阶段要完成两方面的工作。,58,(1) 功能测试。实际运行应用程序，测试它们能否完成各种预定的功能。 (2) 性能测试。测量系统的性能指标，分析系统是否符合设计目标。 系统的试运行对于系统设计的性能检验和评价是很重要的，因为有些参数的最佳值只有在试运行后才能找到。如果测试的结果不符合设计目标，则应返回到设计阶段，重新修改设计和编写程序，有时甚至需要返回到逻辑设计阶段，调整逻辑结构。,59,重新设计物理结构甚至逻辑结构，会导致数据重新入库。由于数据装入的工作量很大，所以可分期分批的组织数据装入，先输入小批量数据做调试用，待试运行基本合格后，再大批量输入数据，逐步增加数据量，逐步完成运行评价。 数据库的实施和调试不是几天就能完成的，需要有一定的时间。在此期间由于系统还不稳定，随时可能发生硬件或软件故障，加之数据库刚刚建立，操作人员对系统还不熟悉，对其规律,60,缺乏了解，容易发生操作错误，这些故障和错误很可能破坏数据库中的数据，这种破坏很可能在数据库中引起连锁反应，破坏整个数据库。 因此必须做好数据库的转储和恢复工作，要求设计人员熟悉DBMS的转储和恢复功能，并根据调试方式和特点首先加以实施，尽量减少对数据库的破坏，并简化故障恢复。,61,7.7.5 整理文档 在程序的编码调试和试运行中，应该将发现的问题和解决方法记录下来，将它们整理存档作为资料，供以后正式运行和改进时参考。 全部的调试工作完成之后，应该编写应用系统的技术说明书和使用说明书，在正式运行时随系统一起交给用户。 完整的文件资料是应用系统的重要组成部分，但这一点常被忽视。必须强调这一工作的重要性，引起用户与设计人员的充分注意。,62,7.8 数据库运行和维护 数据库试运行结果符合设计目标后，数据库就投入正式运行，进入运行和维护阶段。数据库系统投入正式运行，标志着数据库应用开发工作的基本结束，但并不意味着设计过程己经结束。 由于应用环境不断发生变化，用户的需求和处理方法不断发展，数据库在运行过程中的存储结构也会不断变化，从而必须修改和扩充相应的应用程序。,63,数据库运行和维护阶段的主要任务包括以下三项内容： (1) 维护数据库的安全性与完整性； (2) 监测并改善数据库性能； (3) 重新组织和构造数据库。 7.8.1 维护数据库的安全性与完整性 按照设计阶段提供的安全规范和故障恢复规范，DBA要经常检查系统的安全是否受到侵犯，根据用户的实际需要授予用户不同的操作权限。,64,数据库在运行过程中，由于应用环境发生变化，对安全性的要求可能发生变化，DBA要根据实际情况及时调整相应的授权和密码，以保证数据库的安全性。 同样数据库的完整性约束条件也可能会随应用环境的改变而改变，这时DBA也要对其进行调整，以满足用户的要求。 另外，为了确保系统在发生故障时，能够及时地进行恢复，DBA要针对不同的应用要求定制不同的转储计划，定期对数据库和日志文件进行备份，以使数据库在发生故障后恢复到某种一致性状态，保证数据库的完整性。,65,7.8.2 监测并改善数据库性能 目前许多DBMS产品都提供了监测系统性能参数的工具，DBA可以利用系统提供的这些工具，经常对数据库的存储空间状况及响应时间进行分析评价； 结合用户的反应情况确定改进措施；及时改正运行中发现的错误； 按用户的要求对数据库的现有功能进行适当的扩充。 但要注意在增加新功能时应保证原有功能和性能不受损害。,66,7.8.3 重新组织和构造数据库 数据库建立后，除了数据本身是动态变化以外，随着应用环境的变化，数据库本身也必须变化以适应应用要求。 数据库运行一段时间后，由于记录的不断增加、删除和修改，会改变数据库的物理存储结构，使数据库的物理特性受到破坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。因此，需要对数据库进行重新组织，即重新安排数据的存储位置，回收垃圾，减少指针链，改进数据库的响应时间和空间利用率，提高系统性能。这与操作系统对“磁盘碎片”的处理的概念相类似。,67,数据库的重组只是使数据库的物理存储结构发生变化，而数据库的逻辑结构不变，所以根据数据库的三级模式，可以知道数据库重组对系统功能没有影响，只是为了提高系统的性能。 数据库应用环境的变化可能导致数据库的逻辑结构发生变化，比如要增加新的实体，增加某些实体的属性，这样实体之间的联系发生了变化，这样使原有的数据库设计不能满足新的要求，必须对原来的数据库重新构造，适当调整数据库的模式和内模式，比如要增加新的数据项，增加或删除索引，修改完整性约束条件等。,68,DBMS一般都提供了重新组织和构造数据库的应用程序，以帮助DBA完成数据库的重组和重构工作。 只要数据库系统在运行，就需要不断地进行修改、调整和维护。一旦应用变化太大，数据库重新组织也无济于事，这就表明数据库应用系统的生命周期结束，应该建立新系统，重新设计数据库。从头开始数据库设计工作，标志着一个新的数据库应用系统生命周期的开始。,69,小 结 本章主要讨论数据库设计的方法和步骤，列举了许多实例，详细介绍了数据库设计中规划、需求分析、概念设计、逻辑设计、物理设计及运行与维护各阶段的目标、方法和应注意的事项。其中重点是概念结构的设计和逻辑结构的设计，这也是数据库设计过程中最重要的两个环节。 学习这一章，要努力掌握书中讨论的基本方法，还要能在实际工作中运用这些思想，设计出符合应用需求的数据库应用系统。,70,