2-1-6

概 述
1.软件危机的起因
　　由于软件规模的扩大，复杂性成倍的增加，在60年代中后期导致了所谓的“软件危机”。
2.软件危机的表现
(1)开发过程往往无法控制，常常一再拖延。
(2)缺乏科学的指导原则和管理方法，软件产品质量低劣，达不到规定的要求。
(3)由于产品质量低劣，维护任务十分繁重。
(4)软件开发费用急剧上升，常常超出预算，使应用部门与开发部门无法负担。
3.解决软件危机的方法
(1)为了解决“软件危机”，在1968年首次提出“软件工程”的概念。
(2)人们认为，应该用科学知识、工程方面的纪律指导软件开发的过程，以提高软件质量和开发效率，降低开发成本。
4.软件生存期
(1)软件工程中把软件开发和运营的全过程称为“软件生存期”（life cycle）。
(2)软件生存期是软件工程的一个重要概念。
(3)软件生存期是指从软件的规划、研制、实现、投入运行后的维护，直到它被新的软件所取代而停止使用的整个期间。
5.数据库应用系统
(1)以数据库为基础的信息系统通常称为数据库应用系统。
(2)它一般具有信息的采集、组织、加工、抽取、综合和传播等功能。
(3)数据库应用系统的开发是一项软件工程，但又有自己特有的特点，所以特称为“数据库工程”。
6.数据库系统生存期
(1)仿照软件生存期，可以得到数据库系统生存期概念。
(2)我们把数据库应用系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个期间，称为数据库系统生存期。
(3)这个生存期一般可划分成下面七个阶段：规划、需求分析、概念设计、逻辑设计、物理设计、实现、运行维护。 2.1.1 规划阶段
1.重要性
(1)对于数据库系统，特别是大型数据库系统或大型信息系统中的数据库群，规划阶段是十分必要。
(2)规划的好坏将直接影响到整个系统的成功与否，对应用单位的信息化进程将产生深远的影响。
2.规划阶段的三个步骤
(1)系统调查。对应用单位作全面的调查。发现其存在的主要问题，并画出组织层次图，以了解企业的组织机构。
(2)可行性分析。从技术、经济、效益、法律等诸方面对建立数据库的可行性进行分析；然后写出可行性分析报告；组织专家进行讨论其可行性。
(3)确定数据库系统的总目标，并对应用单位的工作流程进行优化和制订项目开发计划。在得到决策部门批准后，就正式进入数据库系统的开发工作。

2.1.2 需求分析阶段
1.概述
　　这一阶段是计算机人员（系统分析员）和用户双方共同收集数据库所需要的信息内容和用户对处理的需求。并以需求说明书的形式确定下来，作为以后系统开发的指南和系统验证的依据。
2.需求分析的四项主要工作
(1)分析用户活动，产生业务流程图
　　 ①了解用户的业务活动和职能，搞清其处理流程（即业务流程）。
　　 ②如果一个处理比较复杂，就要把处理分解成若干个子处理，使每个处理功能明确、界面清楚。
　　 ③分析之后画出用户的业务流程图。
(2)确定系统范围，产生系统关联图
　　 ①这一步是确定系统的边界。
　　 ②在和用户经过充分讨论的基础上，确定计算机所能进行的数据处理的范围，确定哪些工作由人工完成，哪些工作由计算机系统完成，即确定人机界面。
(3)分析用户活动涉及的数据，产生数据流图
　　 ①深入分析用户的业务处理，以数据流图形式表示出数据的流向和对数据所进行的加工。
　　 ②数据流图（Data Flow Diagram,简记为DFD）是从“数据”和“对数据的加工”两方面表达数据处理系统工作过程的一种图形表示法，具有直观、易于被用户和软件人员双方都能理解的一种表达系统功能的描述方式。
(4)分析系统数据，产生数据字典
　　 ①数据字典是对数据描述的集中管理，它的功能是存储和检索各种数据描述（称为元数据metadata）。对数据库设计来说，数据字典是进行详细的数据收集和数据分析所获得的主要成果。
　　 ②数据字典中通常包括数据项、数据结构、数据流、数据存储和处理过程5个部分。 2.1.3 概念设计阶段
1.概念设计的目标
概念设计的目标 功能名称 说明 概念设计 是产生反映用户单位信息需求的数据库概念结构，即概念模型。 概念模型 是独立于计算机硬件结构，独立于支持数据库的DBMS。
2.概念设计的重要性
(1)早期无概念设计阶段
　　 ①在早期的数据库设计中，概念设计并不是一个独立的设计阶段。
　　 ②当时的设计方式是在需求分析之后，直接把用户信息需求得到的数据存储格式转换成DBMS能处理的逻辑模型。
　　 ③这样，注意力往往被牵扯到更多的细节限制方面，而不能集中在最重要的信息组织结构和处理模型上。
　　 ④因此在设计依赖于具体DBMS的逻辑模型后，当外界环境发生变化时，设计结果就难以适应这个变化。
(2)增加概念设计阶段
　　 ①为了改善这种状况，在需求分析和逻辑设计之间增加了概念设计阶段。
　　 ②此时，设计人员仅从用户角度看待数据及处理需求和约束，尔后产生一个反映用户观点的概念模型（也称为“组织模型”）。
　　 ③将概念设计从设计过程中独立开来，可以使数据库设计各阶段的任务相对单一化，得以有效控制设计的复杂程度，便于组织管理。
　　 ④概念模型能充分反映现实世界中实体间的联系，又是各种基本数据模型的共同基础，同时也容易向现在普遍使用的关系模型转换。
3.概念设计的三个主要步骤
(1)进行数据抽象，设计局部概念模型
　　 ①局部用户的信息需求是构造全局概念模型的基础。因此，需要先从个别用户的需求出发，为每个用户或每个对数据的观点与使用方式相似的用户建立一个相应的局部概念结构。
　　 ②在建立局部概念结构时，要对需求分析的结果进行细化、补充和修改，如有的数据项要分为若干子项，有的数据的定义要重新核实等。
　　 ③设计概念结构时，常用的数据抽象方法是“聚集”和“概括”。
　　 a.聚集是将若干对象和它们之间的联系组合成一个新的对象。
　　 b.概括是将一组具有某些共同特性的对象抽象成更高一层意义上的对象。
(2)将局部概念模型综合成全局概念模型
　　 ①综合各局部概念结构就可得到反映所有用户需求的全局概念结构。
　　 ②在综合过程中，主要处理各局部模式对各种对象定义的不一致问题，包括同名异义、异名同义和同一事物在不同模式中被抽象为不同类型的对象（例如，有的作为实体，有的又作为属性）等问题。
　　 ③把各个局部结构合并，还会产生冗余问题，或导致对信息需求的再调整与分析，以确定确切的含义。
(3)评审
　　 ①消除了所有冲突后，就可把全局结构提交评审。
　　 ②评审分为用户评审与DBA及应用开发人员评审两部分。
　　 ③用户评审的重点放在确认全局概念模型是否准确完整地反映了用户的信息需求和现实世界事物的属性间的固有联系。
　　 ④DBA和应用开发人员评审则侧重于确认全局结构是否完整，各种成分划分是否合理，是否存在不一致性，以及各种文档是否齐全等。
　　 ⑤文档应包括局部概念结构描述、全局概念结构描述、修改后的数据清单和业务活动清单等。
4.概念设计中最著名的方法
(1)就是实体联系方法（ER方法）。
(2)建立ER模型，用ER图表示概念结构，得到数据库的概念模型。 2.1.4 逻辑设计阶段
1.逻辑设计的目的
(1)概念设计的结果是得到一个与DBMS无关的概念模式。
(2)而逻辑设计的目的是把概念设计阶段设计好的全局ER模型转换成与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构（包括数据库逻辑模型和外模型）。
(3)这些模型在功能上、完整性和一致性约束及数据库的可扩充性等方面均应满足用户的各种要求。
(4)对于逻辑设计而言，应首先选择DBMS，但往往数据库设计人员没有挑选的余地，都是在指定的DBMS上进行逻辑结构的设计。
(5)逻辑设计主要是把概念模型转换成DBMS能处理的逻辑模型。转换过程中要对模型进行评价和性能测试，以便获得较好的模式设计。
2.逻辑设计的五个主要步骤
(1)把概念模型转换成逻辑模型
　　 ①如果概念模型采用ER模型，逻辑模型采用关系模型，那么这一步就是把ER模型转换成关系模型，也就是把ER模型中的的实体类型和联系类型转换成关系模式。
　　 ②这个转换是有规则可循的，可以用计算机辅助软件工程（CASE）工具来实现。
(2)设计外模型
　　 ①外模型是逻辑模型的逻辑子集。
　　 ②外模型是应用程序和数据库系统的接口，它能允许应用程序有效地访问数据库中的数据，而不破坏数据库的安全性。
(3)设计应用程序与数据库的接口
　　 ○在设计完整的应用程序之前，对应用程序应设计出数据存取功能的梗概，提供应用程序与数据库之间通信的逻辑接口。
(4)评价模型
　　 ①这一步的工作就是对逻辑模型进行评价。评价数据库结构的方法通常有定量分析和性能测量等方法。
　　 ②定量分析有两个参数：处理频率和数据容量。处理频率是在数据库运行期间应用程序的使用次数。数据容量是数据库中记录的个数。数据库增长过程的具体表现就是这两个参数值的增加。
　　 ③性能测量是指逻辑记录的访问数目、一个应用程序传输的总字节数、数据库的总字节数，这些参数应该尽可能预先知道，它能预测物理数据库的性能。
(5)修正模型
　　 ①修正模型的目的是为了使模型适应信息的不同表示。
　　 ②此时，可利用DBMS的性能，如索引或散列功能，但数据库的信息内容不能修改。
　　 ③如果信息内容不修改，模式就不能进一步求精，那么就要停止模型设计，返回到概念设计或需求分析阶段，重新设计。 2.1.5 物理设计阶段
1.概述
(1)对于给定的基本数据模型选取一个最适合应用环境的物理结构的过程，称为物理设计。
(2)数据库的物理结构主要指数据库的存储记录格式、存储记录安排和存取方法。显然，数据库的物理设计是完全依赖于给定的硬件环境和数据库产品的。
(3)在关系模型系统中，物理设计比较简单一些，因为文件形式是单记录类型文件，仅包含索引机制、空间大小、块的大小等内容。
2.物理设计的五个步骤：前三步涉及到物理结构设计，后两步涉及到约束和具体的程序设计
(1)存储记录结构设计：包括记录的组成、数据项的类型、长度，以及逻辑记录到存储记录的映射。
(2)确定数据存放位置：可以把经常同时被访问的数据组合在一起，“记录聚簇（cluster）”技术能满足这个要求。
(3)存取方法的设计：存取路径分为主存取路径与辅存取路径，前者用于主键检索，后者用于辅助键检索。
(4)完整性和安全性考虑：设计者应在完整性、安全性、有效性和效率方面进行分析，作出权衡。
(5)程序设计：在逻辑数据库结构确定后，应用程序设计就应当随之开始。 2.1.6 数据库的实现
1.定义数据库结构
确定了数据库的逻辑结构与物理结构后，就可以用所选用的DBMS提供的数据定义语言（DDL）来严格描述数据库结构。
2.数据装载
(1)数据库结构建立好后，就可以向数据库中装载数据了。组织数据入库是数据库实现阶段最主要的工作。
(2)对于数据量不是很大的小型系统，可以用人工方法完成数据的入库。
(3)对于大中型系统，由于数据量极大，用人工方式组织数据入库将会耗费大量人力物力，而且很难保证数据的正确性，因此应该设计一个数据输入子系统，由计算机辅助数据的入库工作。
3.编制与调试应用程序
(1)数据库应用程序的设计应该与数据设计并行进行。
(2)在数据库实现阶段，当数据库结构建立好后，就可以开始编制与调试数据库的应用程序，也就是说，编制与调试应用程序是与组织数据入库同步进行的。
(3)调试应用程序时由于数据入库尚未完成，可先使用模拟数据。
4.数据库试运行
(1)应用程序调试完成，并且已有一小部分数据入库后，就可以开始数据库的试运行。数据库试运行也称为联合调试。
(2)如果结果不符合设计目标，则需要返回物理设计阶段，调整物理结构，修改参数；有时甚至需要返回逻辑设计阶段，调整逻辑结构。 2.1.7 数据库的运行与维护
1.概述
(1)在数据库试运行结果符合设计目标后，数据库就可以真正投入运行了。
(2)数据库投入运行标志开发任务的基本完成和维护工作的开始，并不意味着设计过程终结。
(3)由于应用环境在不断变化，数据库运行过程中物理存储也会不断变化。
(4)所以对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。
2.数据库运行与维护的工作内容
(1)数据库的转储和恢复
　　 ①数据库的转储和恢复是系统正式运行后最重要的维护工作之一。
　　 ②DBA要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份，以保证一旦发生故障，能利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态，并尽可能减少对数据库的破坏。
(2)数据库安全性、完整性控制
　　 ①DBA必须对数据库安全性和完整性控制负起责任。根据用户的实际需要授予不同的操作权限。
　　 ②此外，在数据库运行过程中，应用环境的变化，对安全性的要求也会发生变化，比如有的数据原来是机密，现在是可以公开查询了，而新加入的数据又可能是机密了。而系统中用户的密级也会改变。这些都需要DBA根据实际情况修改原有的安全性控制。
　　 ③同样，由于应用环境的变化，数据库的完整性约束条件也会变化，所以也需要DBA不断修正，以满足用户需要。
(3)数据库性能的监督、分析和改进
　　 ①在数据库运行过程中，监督系统运行，对监测数据进行分析，找出改进系统性能的方法是DBA的又一重要任务。
　　 ②目前许多DBMS产品都提供了监测系统性能参数的工具，DBA可以利用这些工具方便地得到系统运行过程中一系列性能参数的值。
　　 ③DBA应该仔细分析这些数据，判断当前系统是否处于最佳运行状态，如果不是，则需要通过调整某些参数来进一步改进数据库性能。
(4)数据库的重组织
　　 ①数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。这时DBA就要对数据库进行重组织，或部分重组织（只对频繁增、删的表进行重组织）。
　　 ②数据库的重组织不会改变原计划的数据逻辑结构和物理结构，只是按原计划要求重新安排存储位置、回收垃圾、减少指针链、提高系统性能。
　　 ③DBMS一般都提供了供重组织数据库使用的实用程序，帮助DBA重新组织数据库。
(5)数据库的重构造
　　 ①当数据库应用环境发生变化时，例如，增加新的应用或新的实体，取消某些已有应用，改变某些已有应用，这些都会导致实体及实体间的联系也发生相应的变化，使原有的数据库设计不能很好地满足新的需求，从而不得不适当调整数据库的模式和内模式。这就是数据库的重构造。DBMS都提供了修改数据库结构的功能。
　　 ②重构造数据库的程度是有限的。若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大，则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库系统，开始新数据库应用系统的生命周期了。