数据库应用系统的设计.docx
《数据库应用系统的设计.docx》由会员分享，可在线阅读，更多相关《数据库应用系统的设计.docx（7页珍藏版）》请在冰豆网上搜索。
数据库应用系统的设计
数据库应用系统的设计
1.数据库应用系统的设计步骤
按规范设计的方法可将数据库设计分为以下六个阶段
（1）需求分析;
（2）概念结构设计;
（3）逻辑结构设计;
（4）数据库物理设计;
（5）数据库实施;
（6）数据库运行和维护。
2.需求分析
需求收集和分析是数据库应用系统设计的第一阶段。
明确地把它作为数据库应用系统设计的第一步是十分重要的。
这一阶段收集到的基础数据和一组数据流图（DataFlowDiagram———DFD）是下一步设计概念结构的基础。
概念结构是整个组中所有用户关心的信息结构，对整个数据库设计具有深刻影响。
而要设计好概念结构，就必须在需求分析阶段用系统的观点来考虑问题、收集和分析数据及其处理。
如何分析和表达用户需求呢?
在众多的分析方法中，结构化分析（StructuredAnalysis，简称SA方法）是一个简单实用的方法。
SA方法用自顶向下、逐层分解的方式分析系统。
用数据流图、数据字典描述系统。
然后把一个处理功能的具体内容分解为若干子功能，每个子功能继续分解，直到把系统的工作过程表达清楚为止。
在处理功能逐步分解的同时，它们所用的数据也逐级分解，形成若干层次的数据流图。
数据流图表达了数据和处理过程的关系。
处理过程的处理逻辑常常用判定表或判定树来描述。
数据字典（DataDictionary，简称DD）则是对系统中数据的详尽描述，是各类数据属性的清单。
对数据库应用系统设计来讲，数据字典是进行详细的数据收集和数据分析所获得的主要结果。
数据字典是各类数据描述的集合，它通常包括以下5个部分:
（1）数据项，是数据最小单位。
（2）数据结构，是若干数据项有意义的集合。
（3）数据流，可以是数据项，也可以是数据结构。
表示某一处理过程的输入输出。
（4）数据存储，处理过程中存取的数据。
常常是手工凭证、手工文档或计算机文件。
（5）处理过程。
3.概念结构设计
如同软件工程中重视需求分析与规范说明的思想一样，数据库设计中同样十分重视数据分析、抽象与概念结构的设计。
概念结构的设计，是整个数据库设计的关键之一。
概念结构独立于数据库逻辑结构，独立于支持数据库的DBMS，也独立于具体计算机软件和硬件系统。
归纳总结，其主要特点是:
（1）能充分地反映现实世界，包括实体和实体之间的联系，能满足用户对数据处理的要求，是现实世界的一个真实的模型，或接近真实的模型。
（2）易于理解，从而可以和不熟悉计算机的用户交换意见。
用户的积极参与是数据库应用系统设计成功与否的关键。
（3）易于更动。
当现实世界改变时容易修改和扩充，特别是软件、硬件环境变化时更应如此。
（4）易于向关系、网状或层次等各种数据模型转换。
概念结构是各种数据模型的共同基础，它比任意一种数据模型更独立于机器，更抽象，从而更加稳定。
描述概念结构的有力工具是E-R模型。
P.P.S.Chen把用E-R模型定义的概念结构称为组织模式。
设计概念结构的策略有3种:
（1）自顶向下首先定义全局概念结构的框架，然后逐步细化。
（2）自底向上首先定义各局部应用的概念结构，然后将它们集成，得到全局概念结构。
（3）混合策略自顶向下和自底向上相结合的方法。
用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。
现介绍自底向上设计概念结构的策略。
按照这种策略，概念结构的设计可按下面步骤进行。
（1）数据抽象与局部视图设计
E-R模型是对现实世界的一种抽象。
一般地讲，所谓抽象是对实际的人、物、事和概念的人为处理。
它抽取人们关心的共同特性，忽略非本质的细节，并把这些特性用各种抽象的概念精确地加以描述。
这些概念组成了现实世界的一种模型表示。
有3种抽象方法形成了抽象机制，来对数据进行组织:
①分类（Classification）定义某一概念作为现实世界中一组对象的类型。
这些对象具有某些共同的特性和行为。
它抽象了对象值和型之间的“isamemberof”的语义。
在E-R模型中，实体型就是这种抽象。
②聚集（Aggregation）定义某一类型的组成成分。
它抽象了对象内部属性类型和整体与部分之间“isapartof”的语义。
在E-R模型中若干属性的聚集组成了实体型，就是这种抽象。
③概括（Generalization）定义类型之间的一种子集联系。
它抽象了类型之间的“isasubsetof”的语义。
概括具有一个很重要的性质:
继承性。
子类继承超类上定义的所有抽象性质。
当然，子类可以增加自己的某些特殊属性。
概念结构设计的第一步就是利用上面介绍的抽象机制对需求分析阶段收集到的数据进行组织，形成实体、实体的属性，标识实体的码，确定实体之间的联系类型（1∶1、1∶n、n∶m），设计成部分E-R图。
（2）视图的集成
视图集成就是把上一步得到的各个部分E-R图综合成一个总体的E-R图。
视图集成可以有两种方式:
①多个部分E-R图一次集成。
②逐步集成。
用累加的方式一次集成两个部分E-R图。
无论哪种方式，每次集成可分两步走。
第一步是合并，解决各部分E-R图之间的冲突问题，生成初步E-R图。
第二步是修改和重构，消除不必要的冗余，生成基本E-R图。
4.逻辑结构设计
逻辑结构设计的任务就是把概念结构转换为选用的DBMS所支持的数据模型的过程。
设计逻辑结构按理应选择对某个概念结构最好的数据模型，然后对支持这种数据模型的各种DBMS进行比较，选出最合适的DBMS。
但实际情况常常是已给定了某台机器，设计人员没有选择DBMS的余地。
现行的DBMS一般只支持关系、网状或层次三种模型中的某一种，对某一种数据模型，各个机器系统又有许多不同的限制，提供不同的环境与工具。
因而我们把设计过程分三步进行。
首先把概念结构向一般的关系模型转换，然后向特定的DBMS支持下的数据模型转换，最后进行模型的优化。
（1）E-R图向关系数据模型的转换
下面给出把E-R图转换为关系模型的转换规则。
①一个实体转换为一个关系模式。
实体的属性就是关系的属性，实体的码就是关系的码。
②一个联系转换为一个关系模式，与该联系相连的各实体的码以及联系的属性转换为关系的属性。
该关系的码则有三种情况:
若联系为1∶1，则每个实体的码均是该关系的候选码。
若联系为1∶n，关系的码为n端实体的码。
若联系为n∶m，则关系的码为诸实体码的组合。
具有相同码的关系模式可合并。
形成了一般的数据模型后，下一步就向特定的DBMS规定的模型转换。
设计人员必须熟知所用DBMS的功能及限制。
这一步转换是依赖于机器的，不能给出一个普遍的规则。
转化后的模型必须进行优化。
对数据模型进行优化是指调整数据模型的结构，以提高数据库应用系统的性能。
性能有动态性能和静态性能两种。
静态性能分析容易实现。
根据应用要求，选出合适的模型是一项复杂的工作。
（2）规范化理论的应用
规范化理论是数据库逻辑设计的指南和工具，具体地讲可应用在下面几个具体的方面:
第一，在数据分析阶段用数据依赖的概念分析和表示各数据项之间的关系。
第二，在设计概念结构阶段，用规范化理论为工具消除初步E-R图中冗余的联系。
第三，由E-R图向数据模型转换过程中用模式分解的概念和算法指导设计。
现在，不管选用的DBMS是支持哪种数据模型的，均先把概念结构向关系模型转换。
然后，充分运用规范化理论的成果优化关系数据库模式的设计。
设计办法是:
①确定数据依赖把E-R图中每个实体内的各个属性按数据分析阶段所得到的语义写出其数据依赖。
实体之间的联系用实体主码之间的联系来表示。
②用关系来表示E-R图中的每一个实体每个实体对应一个关系模式Ri，其中Ui就是该实体所包含的诸属性，∑i就是∑在Ui上的投影。
③对于实体之间的那些数据依赖进行极小化处理设函数依赖集为F，求F和最小覆盖G的差集。
D=F-G
逐一考察D中的函数依赖，确定是否应该去掉，由于规范化理论受泛关系假设的限制，应注意下面两个问题:
冗余的联系一定在D中，而D中的联系不一定是冗余的。
当实体之间存在多种联系时应该利用子类的概念将实体之间的联系形式上单一化，然后才能进行极小化处理。
④用关系表示实体之间的联系每个联系对应一个关系模式RjUjo由相互联系的诸实体（二个或多个实体）的主码属性以及描述该联系的性质的属性组成。
∑j就是∑在Ui上的投影。
对于不同实体非主码属性之间的联系同样也要形成一个关系模式。
这样就得到了一组关系模式。
按照数据依赖的理论，逐一分析这组模式。
考查是否存在部分函数依赖、传递依赖、多值依赖等，确定它们分别属于第几范式。
然后按照数据分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这模式是否合适，确定是否要对它们进行合并或分解。
⑤关系模式的分解，对于需要进行分解的关系模式进行分解，对产生的各种模式进行评价，选出较合适的模式。
规范化理论给出了判断关系模式优劣的理论标准，帮助预测模式可能出现的问题，提供了自动产生各种模式的算法工具，因此是设计人员的有力工具，也使数据库应用系统设计工作有了严格的理论基础。
5.数据库的物理设计
物理设计的内容主要包括:
（1）确定数据的存储结构从DBMS所提供的存储结构中选取一种合适的加以实现。
确定存储结构的主要因素是存取时间、存储空间利用率和维护代价三个方面。
设计者常常要对这些因素进行权衡。
一般的DBMS也总是具有一定灵活性供你选择。
例如，若引入某些冗余数据，则可能减少物理I/O次数提高检索效率。
相反节约存储空间检索代价就会增加。
当然应该尽量寻找优化方法，使这三方面的性能都较好。
折衷有时是必须的。
（2）存取路径的选择和调整数据库必须支持多个用户的多种应用，因而必须提供对数据库的多个存取入口，也就是对同一数据存储要提供多条存取路径。
物理设计的任务应确定建立哪些存取路径。
设计者应该进行定量的分析，根据计算结果确定存取路径。
（3）确定数据存放位置首先按数据的应用情况划分为不同的组，然后确定存放位置。
一般的应把数据的易变部分和稳定部分分开，把经常存取和不常存取的数据分开。
经常存取或存取时间要求高的记录应存放在高速存储器上，如硬盘。
存取频率小或存取时间要求低的放在低速存储器上，如软盘、磁带。
对于同一数据文件也可根据情况进行水平划分或垂直划分。
（4）确定存储分配许多DBMS提供了存储分配的参数供设计者物理优化处理用。
例如溢出空间的大小和分布参数、块的长度、块因子的大小、装填因子、缓冲区的大小和个数等等，它们都要在物理设计中确定。
这些参数的大小影响存取时间和存储空间的分配。
物理设计过程需要对时间、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案。
在实施数据库前对这些方案进行方案进行细致的评价，以选择一个较优的方案是十分必要的。
6.数据库应用系统的实施和维护
对数据库的物理设计初步评价完成后就可建立数据库了。
数据库应用系统实施对应于软件工程的编码、调试阶段。
设计人员运用DBMS提供的数据定义语言将逻辑设计和物理设计的结果严格地描述出来，成为DBMS可接受的源代码，经过调试产生目标模式。
然后组织数据入库。
组织数据入库是数据库应用系统实施阶段最主要的工作。
（1）数据库数据的载入和应用程序的开发
由于数据库数据量一般都非常大，并且这些数据来源于一个组织的各个部门，分散在各种数据文件或原始凭证中。
这些数据的结构和格式一般也不符合数据库的要求，还要进行转换。
因此组织数据入库是一件耗费大量人力物力的工作。
数据的转换和组织对于小系统可以用人工方法完成。
但是，人工转换效率低、质量差。
一般来说，应设计一个数据输入子系统让计算机完成这个工作。
输入子系统的主要功能是:
原始数据的输入、抽取、校验、分类、转换和综合，最终把数据组织成符合数据库结构的形式。
然后把数据存入数据库中。
数据的转换、分类和综合常常要经过多次才能完成，因而输入子系统的设计和实施亦是比较复杂的，要编写许多应用程序。
输入子系统的设计不能等物理设计完成后才动手，应该和数据库设计工作并行开展。
为了保证数据库数据正确无误，必须高度重视数据的检验工作。
在输入子系统进行数据转换的过程中应该进行多次检验，每次检验的方法亦不要相同。
对于重要数据的校验更应该反复多次，确认正确后方可入库。
数据库应用系统中应用程序的设计应该和数据库模式设计并行。
数据库应用系统的实施阶段的另一项工作便这是这些应用程序的编码、调试工作。
有了装载实际数据的数据库和应用程序，就建立了数据库应用系统，可以试运行了。
（2）数据库应用系统的试运行
在完成上述工作之后，便可进入数据库的试运行阶段，或者称联合调试阶段。
这阶段的主要工作是:
①实际运行应用程序，执行对数据库的各种操作，测试应用程序的功能。
②测量系统的性能指标，分析是否符合设计目标。
虽然已在物理设计过程中进行了性能预测，但是仅仅估价了时间和空间指标，而且在性能估价的过程中作了许多简化和假设，忽略了许多次要因素，因而估价是粗糙的并可能失真。
必须在试运行阶段进行实际测量和评价。
有些参数的最佳值往往是经过运行调试后才找到的。
如果实际结果不符合设计目标，则需返回物理设计阶段，调整物理结构，修改参数。
有时，也许还需要返回逻辑设计阶段，调整逻辑结构。
最后还须指出两点。
第一，上面已看到组织数据入库是十分费事的，如果运行调试后又要修改数据库设计则又要重新组织数据入库。
因此应分批分期输入数据，逐步完成运行评价。
第二，数据库的实施和调试不是一朝一夕能完成的，在此期间软硬件的错误随时可能发生。
加上数据库刚刚建立，工作人员对系统还不熟悉，对其规律更缺乏深入了解，容易发生操作错误。
因此必须做好数据库的转储和恢复工作，这就要求设计人员了解DBMS的这个功能，并根据调试方式和特点首先实施，尽量减少对数据库的破坏并简化故障恢复。
（3）数据库应用系统的运行和维护
数据库应用系统投入运行标志着开发任务的基本完成和维护工作的开始，但并不意味着设计过程结束。
任何数据库应用系统只要它存在一天，它的设计就得不不断地进行评价、调整、修改，甚至完全改革。
因此数据库应用系统的维护不仅是维护其正常活动而且是设计工作的继续和提高。
维护阶段的主要工作是:
①数据库的安全性、完整性控制及系统的转储和恢复;②性能的监督、分析和改进;③数据库的重组织和重构造。
下面简单介绍数据库的重组织和重构造。
数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏。
例如，逻辑上属于同一记录型或同一关系的数据被分散到了不同的文件或文件的多个碎片上。
从而降低了数据库存储空间的利用率和数据的存取效率，数据库的性能下降。
这时，DBA就要进行数据库的重组织，DBMS一般都提供重组织用的实用程序。
在重组过程中，按原设计要求重新安排记录的存储位置，调整数据区和溢出区，回收“垃圾”，减少指针链等。
数据库的重组织不改变原设计的数据逻辑结构和物理结构。
而数据库的重构造则不同。
部分修改原数据库的模式或内模式称为数据库的重构造。
由于数据库应用环境的变化，数据库重构的程度是有限的。
只能作部分的修改和调整。
若应用变化太大，重构也无济于事了，则表明数据库应用系统生命周期的结束，应该重新设计数据库应用系统。
新的数据库应用系统新的生命周期开始了。
升级会员 