数据库系统与应用——第五章(续)

5.3数据库设计过程
5.3.1数据库设计概述
　1 数据库设计方法
　　随着信息技术的发展和应用环境多样性，数据库设计已经成为建立数据库及其应用系统的重要组成部分。具体的说，数据库设计是要在一个给定的应用环境中，通过合理的逻辑设计和有效的物理设计，构造较优的数据库模式，建立数据库及其应用系统，能够有效的存储和管理数据，满足用户的各种信息需求。因此，数据库设计是数据库在应用领域的主要研究课题。
　　大型数据库设计是涉及多学科的综合性技术，也是一项庞大的软件开发工程。因此，要求从事数据库设计的人员具备多方面的专业技术和知识。除了具备计算机科学的基础知识之外，还必须具备软件工程的原理和方法；掌握程序设计的技巧和方法；具备数据库的基本知识和数据库设计技术；同时还必须具备应用领域的专业知识，才能设计出符合具体应用领域要求的数据库应用系统。
　　然而，数据库应用于多种学科领域，这就要求数据库设计人员必须与应用领域的专业技术人员紧密配合，共同完成数据库应用系统的工程。因此，在数据库设计开始之前，首先必须选定参加设计的人员，包括系统分析人员、数据库设计人员和程序员、用户和数据库管理员。系统分析和数据库设计人员是数据库设计的核心人员，他们将自始至终参与数据库设计，他们的水平决定了数据库系统的质量。用户和数据库管理员在数据库设计中也是举足轻重的，他们主要参加需求分析和数据库的运行维护，他们的积极参与不但能加速数据库设计，而且也是决定数据库设计的质量的重要因素。程序员则在系统实施阶段参与进来，分别负责编制程序和准备软硬件环境。
　　在过去相当长的一段时期内，数据库设计主要采用手工试凑法。使用这种方法与设计人员的经验和水平有直接关系，它使数据库设计成为一种艺术而不是工程技术，缺乏科学理论和工程方法的支持，工程的质量难以保证，常常是数据库运行一段时间后又不同程度地发现各种问题，增加了系统维护的代价。长时间以来，人们努力探索，提出了各种数据库设计方法，这些方法运用软件工程的思想和方法，提出了各种设计准则和规程，都属于规范设计方法。
　　规范设计法中比较著名的有新奥尔良（New Orleans）方法。他将数据库设计分为四个阶段：需求分析（分析用户要求）、概念设计（信息分析和定义）、逻辑设计（设计实现）和物理设计（物理数据库设计）。其后，S.B.Yao等又将数据库设计分为五个步骤。又有。I.R.Palmer等主张把数据库设计当成一步接一步的过程，并采用一些辅助手段实现每一过程。基于E-R模型的数据库设计方法，基于3NF（第三范式）的设计方法，基于抽象语法规范的设计方法等，是在数据库设计的不同阶段上支持实现的具体技术和方法。
　　规范设计法从本质上看仍然是手工设计方法，其基本思想是过程迭代和逐步求精。
　　多年以来，数据库工作者和数据库厂商一直在研究和开发数据库设计工具。经过十多年的努力，数据库设计工具已经实用化和产品化，并同时进行数据库设计和应用程序设计。人们开始选择不同的快速应用程序开发(RAD)工具，例如，Microsoft Visual Studio、Borland 的Delphi和Builder C++ 、Sybase的PowerBuilder、Oracle公司的Design2000等。这些RAD工具允许开发者迅速设计、开发、调试和配置各种各样的数据库应用程序，并且能在性能、可扩展性和可维护性这些不断增长的需求上有所收获。作为RAD工具之所以强大的一个原因是它对应用程序开发工程生命周期中的每个阶段都提供支持。这些工具软件可以自动的或辅助设计人员完成数据库设计过程中的很多任务。人们已经越来越认识到自动数据库设计工具的重要性。特别是大型数据库的设计需要自动设计工具的支持。
　　目前许多计算机辅助软件工程（Computer Aided Software Engineering,简称CASE）工具已经把数据库设计作为软件工程设计的一部分。如ROSE，UML(Unified Modeling language)等。
　2 软件和数据库应用系统的生命周期 　
　　早期的数据库设计，注重数据库结构特性的设计，忽略了对行为的设计。就是说，比较重视研究在给定的环境下，采用是什么原则、方法来建造数据库的结构，而忽略了应用环境要求对数据库做什么处理，没有研究如何实现用户的功能要求。近十多年以来，许多专家、学者将结构特性和行为特性相结合进行数据库设计方面，进行了许多探讨和实践。
　　数据库应用软件和其他软件一样，也有它的诞生和消亡。数据库应用软件作为软件，在其生命周期可以看作有三个大的时期：软件定义时期，软件开发时期和软件运行维护时期。如图5-5所示。
　按照规范化设计方法，从数据库应用系统设计和开发的全过程来考虑，将数据库及其应用软件系统的生命周期的三个时期又可以细分为七个阶段：规划、需求分析；概念结构设计；逻辑结构设计；物理结构设计；实施及运行维护。如图5-6所示。
　3. 七个阶段的主要工作
　(1) 应用规划
　　规划阶段进行系统的必要性和可行性分析，确定数据库系统在整个企业管理系统中的地位。
　· 规划阶段必须要完成的任务包括：确定系统的范围；确定开发工作所需的资源(人员、硬件和软件)；估算软件开发的成本；确定项目进度。
　· 规划阶段产生的结果是可行性分析报告及数据库规划纲要，内容包括信息范围、信息来源、人力资源、设备资源、软硬件环境、开发成本估算、进度计划、现行系统向新系统过渡计划等。
　(2) 需求分析
　　这一阶段是计算机人员 (系统分析员) 和用户共同收集数据库所需要的信息内容和用户对处理的要求，加以规格化和分析，以书面形式确定下来，作为以后验证系统的依据。在分析用户要求时，要确保用户目标的一致性。-需求分析阶段的输入和输出如图5-7所示：
　　信息需求:指目标系统涉及的所有实体、属性、以及实体间的联系等，包括信息的内容和性质，以及由信息需求导出的数据需求。
　　处理需求:指为得到需要的信息而对数据进行加工处理的要求，包括处理描述，发生的频度、响应时间以及安全保密要求等。进行数据库设计首先必须准确了解与分析用户需求（包括数据与处理）。需求分析是整个设计过程的基础，是最困难、最耗费时间的一步。作为地基的需求分析是否做的充分于准确，决定了在其上构建数据库大厦的速度与质量。需求分析做得不好，甚至会导致整个数据库设计返工重做。
　(3)概念设计
　　把用户的信息要求统一到一个整体逻辑结构中，此结构能表达用户的要求，且独立于任何DBMS软件和硬件。概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。

　(4)逻辑设计
　　逻辑结构设计分为两部分，即数据库结构设计和应用程序的设计。从逻辑设计导出的数据库结构是DBMS能接受的数据库定义，这种结构有时也称为逻辑数据库结构。
　　逻辑结构设计是将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化。

　(5) 物理设计
　　物理设计也分为两部分：物理数据库结构的选择和逻辑设计中程序模块说明的精确化。这一阶段的工作成果是一个完整的能实现的数据库结构。数据库物理设计是为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。

　(6)．实现
　　根据物理设计的结果产生一个具体的数据库和它的应用程序，并把原始数据装入数据库。实现阶段主要有三项工作：

　　(1) 建立实际数据库结构；
　　(2) 装入试验数据对应用程序进行调试；
　　(3) 装入实据数据。
　　在数据库实施阶段，设计人员运用DBMS提供的数据语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。

　(7)．运行维护
　　数据库系统的正式运行，标志着数据库设计与应用开发工作的结束和维护阶段的开始。运行和维护阶段的主要任务有四项：
　　(1) 维护数据库的安全性与完整性；
　　(2) 监测并改善数据库运行性能；
　　(3) 根据用户要求对数据库现有功能进行扩充；
　　(4) 及时改正运行中发现的系统错误。
　　维护分为改正性维护，适应性维护，完善性维护和预防性维护。
　　数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。
　　需要指出的是，这个设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来，将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计。事实上，如果不了解应用环境对数据的处理要求，或没有考虑如何去实现这些处理　　要求，是不可能设计一个良好的数据库结构的。

　4.数据库应用系统开发中存在的问题
　· 用户需求调查不完善；
　· 粗糙的数据建模；
　· 不一致的数据结构；
　· 伸缩性能差；
　· 界面不友好；
　· 容错性不高；
　· 维护困难等；
　· 其它...
　5. 数据库设计的基本过程
　　本节重点是讲述数据库的设计过程。根据上述的设计过程，数据库设计的不同阶段形成数据库的各级不同模式。需求分析阶段，综合各个用户的应用需求；在概念设计阶段形成独立于具体机器，独立于各个DBMS产品的概念模式，就是E-R模型图；在逻辑设计阶段将E-R模型图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图（View），形成数据库的外模式；在物理设计阶段，根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。如图5-8：     
  　(1) 数据库设计的输入和输出
　　从用户需求出发,研制一个数据库结构的过程称为数据库设计。图5-9给出数据库设计过程的输入和输出。
　　一般信息需求包括数据库系统的目的说明、数据元素的定义、以及企业中数据元素的使用描述。这些要求并不限于某个特殊的用户，便于数据库结构的设计能适应应用要求的变化。
处理要求由三部分组成：每个应用要求的数据项、数据量(数据项值的数量)和处理频率。其中的每一部分对数据库的的设计都是很重要的。
　　DBMS的说明书、操作系统和硬件配置说明都对数据库设计有影响。例如，DBMS的性能约束通常看作是数据库设计需求的一部分。典型的性能约束如查询的响应时间、系统的恢复能力、对安全性和完整性的要求等都是数据库设计要考虑的因素。
　　数据库设计的结果体现在输出文件中，包括数据库的结构设计，应用程序的用户使用说明。这些结果文件是用户和设计人员进行系统验证的依据。
    (2) 数据库设计的基本过程

[ 本帖最后由 cayean 于 2007-1-29 12:59 编辑 ]

　　需求分析就是确定所要开发的应用系统的目标，收集和分析用户对数据库的要求，了解用户需要什么样的数据库，做什么样的数据库。对用户需求分析的描述是数据库概念设计的基础。
　　需求分析主要是考虑"做什么"的问题，而不是考虑"怎么做"的问题。
　　需求分析的结果是产生用户和设计者都能接受需求说明书。需求分析简单地说就是分析用户的要求。需求分析是设计数据库的起点，需求分析的结果是否准确的反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。
　 　1. 需求分析的主要工作
　(1)问题识别 (problem recognition)
　(2)评价和综合 (evaluation and synthesis)
　(3)建模 (modeling)
　(4)规格说明 (specification)
　(5)评审 (review)
　　需求分析的任务是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。
　　调查的重点是"数据"和"处理"，通过调查、分析，获得用户对数据库的如下要求：
　（1） 信息要求。指用户需要从数据库中获得信息的内容与性质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。
　（2） 处理要求。指用户要完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理。
　（3） 安全性与完整性要求。
　　确定用户的最终需求是一件很困难的事，这是因为一方面用户缺少计算机知识，开始时无法确定计算机究竟能为自己做什么，不能做什么，因此往往不能准确的表达自己的需求，所提出的需求往往不断的变化。另一方面，设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求。因此设计人员必须不断深入的与用户交流，才能逐步确定用户的实际需求。

　2. 软件需求规格说明
　　进行需求分析首先是调查清楚用户的实际要求，与用户达成共识，然后分析与表达这些需求。对用户需求进行分析与表达后，必须提交给用户，征得用户的认可。
　　软件需求规格说明是在对用户需求分析的基础上，把用户的需求规范化、形式化而写成的。目的是为软件开发提出总体要求，作为用户和开发人员之间相互了解和共同开发的基础。根据我国国家标准GB856D-88的规定，软件需求规格说明的内容如下：
　　1. 引言
　　　1.1 编写说明
　　　1.2 背景
　　　1.3 定义
　　　1.4 参考资料
　　2. 任务概述
　　　2.1 目标
　　　2.2 用户的特点
　　　2.3 假定与约束
　　3. 需求规定
　　　3.1 对功能的规定
　　　3.2 对性能的规定
　　　　3.2.1 精度
　　　　3.2.2 时间特性要求
　　　　3.2.3 灵活性
　　　3.3 输入输出要求
　　　3.4 数据管理能力要求
　　　3.5 故障处理要求
　　　3.6 其它专门要求
　　4. 运行环境规定
　　　4.1 设备
　　　4.2 支持软件
　　　4.3 接口
　　　4.4 控制

　3 软件需求分析方法和工具　
　　调查了解了用户的需求以后，还需要进一步分析和表达用户的需求。在众多的分析方法中结构化分析方法（Structured Analysis,简称SA方法）是一种简单实用的方法。SA方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。SA方法把任何一个系统都抽象为图5-11的形式。
　　在需求分析阶段，通常用系统逻辑模型描述系统必须具备的功能。系统逻辑模型常用的工具主要是：
　(1) 数据流图
　(2) 数据字典
　　图5-11给出的只是最高层次抽象的系统概貌，要反映更详细的内容，可将处理功能分解为若干子功能，每个子功能还可以继续分解，直到把系统工作过程表示清楚为止。在处理功能逐步分解的同时，他们所用的数据也逐级分解，形成若干层次的数据流图。
　　数据流图表达了数据和处理过程的关系。在SA方法中，处理过程的处理逻辑常常借助判定表或判定树来描述。系统中的数据则借助数据字典（Data Dictionary,简称DD）来描述。
  　4 数据流图　
　　有两种形式的数据流模型。首先是上下文图。它确定一个全局的系统边界。上下文图中所标识的外部实体表示数据流的源端或目的端。因此，外部实体就是候选对象。上下文图中的数据流代表了该系统的输入和输出。因此任何一种对象集合都必须阐明这些上下文图中的数据流是如何被接收、处理及生成的。
　　第二种为分层的数据流图集合。表示系统的功能分解为一些基本单元，最后对应于对象的处理方法或服务。
　　了解了用户的应用要求，可以使用信息流程图分析应用系统中的信息流。例如，学生选课系统简单的上下文信息流图如图5-12。

　　　　数据流图(Data Flow Diagram, 简记为DFD)是从"数据"和"对数据的加工"两方面表达数据处理系统工作过程的一种图形表示法, 具有直观、易于被用户和软件人员双方理解的特点。
分层的数据流图采用自顶向下的逐步细化的结构化方法表示。
　　DFD有四种基本成分：数据流用箭头表示；加工或处理(process)用圆圈表示；文件或数据库用双线段表示；数据流的源点或终点用方框表示。
　　下面是一个简单的DFD图示例，如图5-12。
　　分层的数据流图是由顶级的数据流图开始，可作为由顶向下逐步细化时描述对象的工具。顶层(0层)DFD的每一个加工都可以进一步细化为第1层、第2层...的DFD，直到最底层的每一个加工已表示一个最基本的处理动作为止。
　　对一个加工进行细化分解，一次可分解成两个或三个加工，可能需要的层次过多；分解得过多又难于让人理解。根据心理学的研究成果，人们能有效地同时处理问题的个数不超过7个。因此，一个加工每次分解细化出的子加工个数一般不要超过7个。
　　在DFD中并没有表示数据处理的过程逻辑(procedural logic)，如是否要循环处理或根据不同的条件进行处理等。
图5-13给出分层数据流图示例，顶层的处理过程分为第一层的两个处理过程P1和P2，第一层的两个处理过程P1和P2又可以划分产生第二层的四个处理功能，分别为P1.1，P1.2，P2.1和P2.2。还可以逐层细分，直至最基本的处理过程。
　 　 　
　 　5. 数据字典　
　　因为DFD只表示出系统由哪几部分组成和各部分之间的关系，并没有说明各个成分(数据流，加工等)的含义。因此，仅有DFD还不足以描述用户的需求，必须通过数据字典详细描述各类数据实体对象。
　　数据字典(Data Dictionary, 简记为DD)是各类数据描述的集合。
　　
　　数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分。其中数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构，数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。
　(1)． 数据项
　　数据项是不可再分的数据单位。对数据项的描述通常包括以下内容：
　　数据项描述={数据项名，数据项含义说明，别米，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}
　　其中"取值范围"、"与其他数据项的逻辑关系"（例如该数据项等于另几个数据项的和，该数据项值等于另一数据项的值等）定义了数据的完整性约束条件，是设计数据检验功能的依据。
　　可以用关系规范化理论为指导，用数据依赖的概念分析和表示数据项之间的联系。即按实际语义，写出每个数据项之间的数据依赖，他们是数据库逻辑设计阶段数据模型优化的依据。
　(2)． 数据结构
　　数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。对数据结构的描述通常包括以下内容：
　　数据结构描述={数据结构名，含义说明，组成：{数据项或数据结构}}
　(3)． 数据流
　　数据流是数据结构在系统内传输的路径。对数据流的描述通常包括以下内容：
　　数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}
　　其中"数据流来?quot;是说明该数据流来自哪个过程。"数据流取向"是说明该数据流将到那个过程去。"平均流量"是指在单位时间（每天、每周、每月等）里的传输次数。"高峰期流量"则是指在高峰时期的数据流量。
　(4)． 数据存储
　　数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。它可以是手工文档或手工凭单，也可以是计算机文档。对数据存储的描述通常包括以下内容：
　　数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}
　　其中"存取频度"值每小时或每天或每周存取几次、每次存取多少数据等信息?quot;存取方式"包括是批处理还是联机处理；是检索还是更新；是顺序检索还是随机检索等。另外，"输入的数据流"要指出其来源，"输出的数据流"要指出其去向。
　(5)． 处理过程
　　处理过程的具体处理逻辑一般用判定表或判定书来描述。数据字典中只需要描述处理过程的说明性信息，通常包括以下内容：
　　处理过程描述={处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}
　　其中"简要说明"中主要说明该处理过程的功能及处理要求。功能是指该处理过程用来做什么（而不是怎么做），处理要求包括处理频度要求，如单位时间里处理多少事务、多少数据量、响应时间要求等。这些处理要求是后面物理设计的输入及性能评价的标准。
　　可见，数据字典是关于数据库中数据的描述，即元数据，而不是数据本身。
　　数据字典是在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善的。
　　明确地把需求收集和分析作为数据库设计的第一阶段是十分重要的。这一阶段收集到的基础数据（用数据字典来表达）和一组数据流程图（Data Flow Diagram,简称DFD）是下一步进行概念设计的基础。
　　要强调两点：
　（1） 需求分析阶段的一个重要而困难的任务是收集将来应用所涉及的数据，设计人员应充分考虑到可能的扩充和改变，是设计易于更改，系统易于扩充，这是第一点。
　（2） 必须强调用户的参与，这是数据库应用系统设计的特点。数据库应用系统和广泛的用户有密切的联系，许多人要使用数据库。数据库的设计和建立又可能对更多人的工作环境产生重要影响。因此用户的参与是数据库设计不可分割的一部分。在数据分析阶段，任何调查研究没有用户的积极参加是寸步难行的。设计人员应该和用户取得共同的语言，帮助不熟悉计算机的用户建立数据库环境下的共同概念，并对设计工作的最后结果承担共同的责任。 　　　

　 　6． 数据流和数据字典描述示例　
　　了解了用户的应用要求，可以使用信息流程图分析应用系统中的信息流。下面的例子是实现一个计算机综合教务管理系统，完成班级信息管理，学生信息管理，课程信息管理和学生选课管理等功能。
　　本系统的用户分为超级用户和普通用户两类，超级用户负责系统维护，包括对班级信息，学生个人信息，课程信息的录入，修改，查询，删除等。普通用户即选课学生则只具有为自己选课的权限。下面给出部分数据流图和数据字典作为示例。
　　(1) 学生选课系统简单的上下文信息流图如图5-15。
　　(2) 学生选课第一层次数据流图
　　下面是学生选课申请的数据流图，作为第一层数据流图,如图5-16。
　　(3) 数据字典中数据项和数据流的描述

　　数据项名：学生编号
　　说明： 标识每个学生身份
　　类型： CHAR
　　长度： 8
　　别名： 学号
　　取值范围：970000－979999
　　数据流名：选课申请
　　说明：由学生个人信息，欲选课程信息组成选课申请
　　来自过程：无
　　流至过程：身份验证
　　数据结构：学生个人信息
　　欲选课的课程信息 数据结构：学生个人信息
　　说明： 说明了学生的个人情况。
　　组成： 帐号
　　密码
　　数据存储：上课时间信息
　　说明： 说明了每门课的上课时间，一门课可以有多个上课时间，同一时间可以有多门课程在上课。
　　输出数据流：课程上课时间
　　数据描述：课程编号
　　上课时间
　　数量：每学期200－300个
　　存取方式：随机存取
　　处理过程：身份验证
　　说明： 对学生输入的帐号，密码进行验证，确定正确，得到相应的学生编号。
　　输入：学生帐号；
　　密码；
　　选课的课程编号。
　　输出：学生编号；
　　选课的课程编号
　　程序提要说明：
　　o 对输入的学生个人信息，检查学号和密码是否正确？
　　o 对身份正确的学生检查要选修的课程是否允许？
　　o 检查是否正确返回信息。

[ 本帖最后由 cayean 于 2007-1-29 13:16 编辑 ]

　　概念模型是数据库系统的核心和基础。由于各个机器上实现的DBMS软件都是基于某种数据模型的，但是在具体机器上实现的模型都有许多严格的限制。而现实应用环境是复杂多变的，如果把实现世界中的事物直接转换为机器中的对象，就非常不方便。因此，人们研究把现实世界中的事物抽象为不依赖与具体机器的信息结构，又接近人们的思维，并具有丰富语义的概念模型，然后再把概念模型转换为具体的机器上DBMS支持的数据模型。概念模型的描述工具通常是使用E-R模型图。该模型不依赖于具体的硬件环境和DBMS。
　　概念结构是对现实世界的一种抽象。所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确的加以描述，这些概念组成了某种模型。通过概念设计得到的概念模型是从现实世界的角度对所要解决的问题的描述，不依赖于具体的硬件环境和DBMS。
　　在需求分析和逻辑设计之间增加概念设计阶段，可以使设计人员仅从用户的角度看待数据及处理要求和约束。
　1 对数据库概念模型的要求
　　表达概念设计的结果称为概念模型，对概念模型有以下要求：
　(1) 有丰富的语义表达能力，能表达用户的各种需求。
　(2) 易于交流和理解，从而可以用它和不熟悉计算机的用户交换意见。
　(3) 要易于更改。当应用环境和应用要求改变时，概念模型要能很容易的修改和扩充以反映这种变化。
　(4) 易于向各种数据模型转换。
　　按照上述要求，传统的数据模型（网状、层次和关系模型）都不适合作概念模型。在数据库的概念设计中，通常采用E-R数据模型来表示数据库的概念结构。 E-R数据模型将现实世界的信息结构统一用属性、实体以及它们之间的联系来描述。注释：
　　通过概念设计得到的概念模型是从现实世界的角度对所要解决的问题的描述，不依赖于具体的硬件环境和DBMS。把用户的信息要求统一到一个整体概念结构中，此结构能表达用户的要求，且独立于任何DBMS软件和硬件。
　　在需求分析和逻辑设计之间增加概念设计阶段，可以使设计人员仅从用户的角度看待数据及处理要求和约束。

　2 数据库概念模型的设计方法
　　概念设计阶段，一般使用语义数据模型描述概念模型。通常是使用E-R模型图作为概念设计的描述工具进行设计。用E-R模型图进行概念设计可以采用如下两种方法：
　(1)集中式模式设计法(centralized schema design approach)：
　　首先设计一个全局概念数据模型，再根据全局数据模式为各个用户组或应用定义外模式。
　(2)视图集成法(view integration approach)：
　　以个部分的需求说明为基础,分别设计各自的局部模式，这些局部模式相当于各部分的视图，然后再以这些视图为基础，集成为一个全部模式。
　　视图是按照某个用户组、应用或部门的需求说明，用E-R数据模型设计的局部模式。
　　现在的关系数据库设计通常采用视图集成法。
　 3 采用E-R方法的概念模型设计步骤　
　　概念结构设计的第一步就是对需求分析阶段收集到的数据进行分类、组织（聚集），形成实体、实体的属性，标识实体的码，确定实体之间的联系类型（1：1，1：N，M：N），设计分E-R图。
　　采用E-R方法进行概念设计，可分为三步进行：
　(1) 局部E-R模式设计；
　(2) 全局E-R模式设计；
　(3) 全局E-R模式的优化和评审。 　(1) 局部E-R模式设计；
　　局部E-R模式设计的过程如图5-17所示。
　　设计分E-R模式的具体做法是：
　· 先选择某个局部应用，根据某个系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，作为设计分析E-R图的出发点。
　　由于高层的数据流图只能反映系统的概貌，而中层的数据流图能较好的反映系统中各局部应用的子系统组成，因此人们往往以中层数据流图作为设计分E-R图的依据。
　· 逐一设计分E-R图
　　选择好局部应用之后，就要对每个局部应用逐一设计分E-R图，亦称局部E-R图。
　　在前面选好的某一层次的数据流图中，每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型。
　　事实上，在现实世界中具体的应用环境常常对实体和属性已经作了大体的自然的划分。在数据字典中，"数据结构"、"数据流"和"数据存储"都是若干属性有意义的聚合，就体现了这种划分。可以先从这些内容出发定义E-R图，然后再进行必要的调整。在调整中遵循的一条原则是：
　　为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。
　　注释：实体与属性之间并没有形式上可以截然划分的界限，但可以给出两条准则：
　（1）作为"属性"，不能再具有需要描述的性质。"属性"必须是不可分的数据项，不能包含其他属性。
　（2）"属性"不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。 　(2) 全局E-R模式设计
　　各子系统的分E-R图设计好以后，下一步就是要将所有的分E-R图综合成一个系统的总E-R图。全局E-R模式的集成过程如图5-18所示。
　(3) 全局E-R模式的优化和评审：进行相关实体类型的合并，以减少实体类型的个数；消除实体中的冗余属性；消除冗余的联系类型。
4 视图设计示例

　例1：教务处关于学生的局部视图如图5-20。
   例2：研究生院关于学生的局部视图.如图5-21。 　 　 　
　 　5 视图集成
　　各子系统的分E-R图设计好以后，下一步就是要将所有的分E-R图综合成一个系统的总E-R图。一般说，视图集成可以有两种方式：
　● 多个分E-R图一次集成。
　● 逐步集成，用累加的方式一次集成两个分E-R图。
　　无论采用哪种方式，每次集成局部E-R图都需要分两步骤：
　（1） 视图合并
　　视图合并要解决各分E-R图之间的冲突，将各分E-R图合并起来生成初步E-R图。
　　消除各分E-R图的冲突是合并分E-R图的主要工作与关键所在。各分E-R图之间的冲突主要有三类：命名冲突、属性冲突、结构冲突。
　· 命名冲突
　　(a)同名异义冲突。例如："学生"和"课程"这两个实体名在图5-20和图5-21中的含义是不同的，即它们的描述属性各不相同，分别表示不同的实体类型。
　　(b)异名同义冲突。例如：图5-20中的"何时入学"和图5-21中的"入学时间"是异名同义，它们都表示学生的入学时间，用了不同的属性名。
　· 属性冲突
　　(a)属性域冲突。例：学号在一个视图中可能当作字符串，在另一个视图中可能当作整数。
　　(b)属性取值单位冲突。
　· 结构冲突
　　（a）同一对象在一个实体中可能作为实体，在另一个视图中可能作为属性或联系。
　　（b）同一实体在不同的分E-R图中所包含的属性个数和属性排列次序不完全相同。
　　（c）不同的视图可能有不同的约束。例如，对?quot;选课"这个联系，大学生和研究生对选课的最少门数和最多门数要求可能不一样。
　(2) 修改和重构生成基本E-R图
　　修改和重构消除不必要的冗余，生成基本E-R图。
　　冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其它联系导出的联系。
　　消除了冗余后的初步E-R图称为基本E-R图。
　　例如，在下面的图5-22中，Q3可由Q1、Q2导出，Q4可由Q5导出，产品和材料之间的使用联系是冗余联系。 　
  　(3) 视图集成的要求视图集成要尽可能合并对应的部分，保留特殊的部分，删除冗余部分，必要时对模式进行适当的修改，力求使模式简明清晰。
　　视图集成后，要对整体概念结构进行验证：
　· 整体概念结构必须具有一致性，不存在矛盾；
　· 整体概念结构要反映单个视图的结构，包括实体及实体之间的联系；
　· 整体概念结构必须满足需求分析阶段确定的所有要求。如果两个实体在不同的视图中存在着不同的联系，集成时，所有联系都要保留。例如，维修部门视图中的职工和设备的保养联系以及生产部门视图中的职工与设备的使用联系，如图5-23所示。
另一种形式的E-R图集成如图5-24，把职工分为保养工和使用工。
　　各个局部应用所面向的问题不同，且通常是由不同的设计人员进行局部试图设计，这就导致各个分E-R图之间必定会存在许多不一致的地方，称之为冲突。因此合并分E-R图时并不能简单的将各个分E-R图画到一起，而是必须着力消除各个分E-R图中的不一致，已形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。合理消除各分E-R图中的冲突是合并分E-R图的主要工作与关键所在。

　6. 数据库概念设计总结
　· 用E-R数据模型进行概念设计，首先必须根据需求说明，确认实体、联系和属性。
　· 采用E-R方法进行数据库的概念设计，可以分成三步进行：首先设计局部E-R图；然后合并各局部E-R图，并解决可能存在的冲突，得到初步E-R图；最后修改和重构初步E-R图，消除其中的冗余部分，得到最终的全局E-R图，即概念模式。o设计全局E-R模式的目的不在于把若干局部E-R模式形式上合并为一个E-R模式，而在于消除冲突使之成为能够被全系统总所有用户共同理解和接受的统一的概念模型。
　　在需求分析和逻辑设计之间增加概念设计阶段，使设计人员仅从用户角度看待数据及处理要求和约束，产生一个反映用户观点的概念模式。这样做有三个好处：
　(1) 数据库设计各阶段的任务相对单一化，设计复杂程度得到降低，便于组织管理。
　(2) 概念模式不受特定DBMS限制，也独立于存储安排，因而比逻辑设计得到的模式更为稳定。
　(3) 概念模式不含具体的DBMS所附加的技术细节，更容易为用户所理解，因而能准确反映用户的信息需求。
　　在初步E-R图中，可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余的数据和冗余联系容易破坏数据库的完整性，为数据库的维护增加困难，应当予以消除。消除了冗余后的初步E-R图称为基本E-R图。
　　但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。因此在设计数据库概念结构时，那些冗余信息必须消除，那些冗余信息允许存在，需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。

[ 本帖最后由 cayean 于 2007-1-29 13:39 编辑 ]

　　逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构。逻辑结构设计的过程如图5-25所示。
由于各种DBMS产品一般都有许多限制，提供不同的环境与工具，因此，逻辑设计分为如下几步：
(1) 将概念模型向一般关系、网状和层次模型转化；
(2) 将得到的一般关系、网状和层次模型向特定的DBMS产品所支持的数据模型转化；
(3) 依据应用的需求和具体的DBMS的特征进行调整和完善。
　　某些早期设计的应用系统中还在使用网状或层次数据模型，而新设计的数据库应用系统都普遍采用支持关系数据模型的RDBMS，所以这里只介绍E-R图像关系数据模型的转换原则与方法。

　1．关系数据库的逻辑设计过程　
　　由于DBMS目前一般采用关系数据模型，因此数据库的逻辑设计，就是将概念设计中所得到的E-R图转换成等价的关系模式。关系数据库的逻辑设计过程如图5-26所示。
　　概念设计是对客观世界的描述，与实现无关；而逻辑设计依赖于实现的基础DBMS。
　　从数据库逻辑设计导出的数据库结构是DBMS能接受的数据库定义，这种结构有时也称为逻辑数据库结构。
　　概念设计是对客观世界的描述，与实现无关；而逻辑设计依赖于实现的基础DBMS。
　 　2. E-R模型转换为关系模型　
　　关系数据据库的逻辑结构由一组关系模式组成,因而从概念结构到关系数据库逻辑结构的转换就是从E-R图转换为关系模式。具体的转换过程和转换规则分为如下两类：
　A、 实体和实体属性的转换。一个实体对应一个关系模式，实体的属性对应关系的属性，实体的码对应关系模式的候选码。
　B、 实体之间的联系和联系属性的转换：由于实体之间的联系有多种情况，下面分几种情情况进行讨论。
　① 实体类型之间联系的转换1：1联系的转换
　· 实体类型之间一个1：1联系转换为一个独立的关系模式，则与该联系相连的实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。
　· 实体类型之间一个1：1联系与任意一端实体对应的关系模式合并。则需要在该关系模式的属性中加入另一关系模式的码和联系本身的属性。
　　例如，图5-27所示的E-R图，有两类实体E1和E2，分别转换为关系模式R1和R2。它们之间的联系r和联系的属性s可以合并到R1或R2中（此处合并到R1中），或者转换为独立的关系模式R3，R3的候选码有h和k两个。
　　例如，车间和车间主任之间的1：1的联系，有三种方法转换：
　　在双方表中增加对方表的关键字列属性。车间表中增加"车间主任号"属性，车间主任表中增加"车间号"属性。
　　在其中一个表中增加对方表的关键字列属性。例如，车间表中增加"车间主任号"属性，或在车间主任表中增加"车间号"属性。
　增加新关系。例如，车间和车间主任（车间号，车间主任号）。
　 ② 1：n联系的转换
　· 一个1：n联系可以转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为新关系的属性，而新关系的码为n端实体的码。
　· 一个1：n联系也可以与n端对应的关系模式合并。 在n端的子表中增加父表的关键字列。例如，在间成员表中增加所属"车间号"属性。
　　例如，图5-28所示的E-R图，有两类实体E1和E2，分别转换为关系模式R1和R2。它们之间的联系r和联系的属性s可以合并到R2中，或者转换为独立的关系模式R3，R3的候选码有h。可以转换的关系模式如下：
　③ m：n联系的转换一个m：n联系必须转换为一个新关系模式，与该联系相连的各实体的码以及联系本身的属性均转为新关系的属性，而新关系的码是各实体码的组合。例如，供应者和零件之间m：n的联系，增加供应零件表：
　　供应零件表（供应者号，零件号，供应数量）。
　　如图5-29所示的E-R图，有两类实体E1和E2，分别转换为关系模式R1和R2。它们之间m：n的联系转换为独立的关系模式R3，联系r的属性s是属性，R3的候选码是k和h的组合。可以转换的关系模式如下：　
(2) 实体类型内实体之间联系的转换④ 1：1联系的转换在实体关系表中增加联系的列属性
　· 建立新关系。例如，图5-30所示的情况，可以在职工表中增加"配偶"属性或者建立职工配偶表（职工号，配偶的职工号）。
　 ⑤ 1：n联系的转换
　· 在n端实体关系表中增加父结点的关键字。
　· 增加新关系表。例如，如图5-31所示，在职工内部存在领导和被领导的1：n关系。可以将该联系与职工实体合并，这时主码职工号将多次出现，但作用不同，可用不同的属性名加以区分，比如在合并后的关系模式中，再增设一个"领导职工号"属性。主码仍为"职工号"。或者是建立职工领导表
　　(职工号，领导职工号)。
　⑥ m：n联系的转换
　· 增加新关系。
　　例如，图5-32所示的零件之间的构成联系，可以建立零件构成表。
　　零件构成表（零件号1（主），零件号2（子）,数量）。
　　实际设计中，每个组装零件都有一个子零件的明细表(BOM表--Bill Of Material)。
　 (3)多元联系的转换在多元联系中，如果M，N，P中这些基数最多只有一个大于1，则可以由一个实体的主键识别一个多元联系，在转换时可将联系合并在此实体的关系中。
　· 对于其它情况，可以通过增加新关系进行转换。例如，图5-33所示的E-R图，有三类实体E1、E2和E3，分别转换为关系模式R1、R2和R3。它们之间m：n：P的联系转换为独立的关系模式R4，联系r的属性s转换为R4的属性，R4的候选码是k、h和j的组合。可以转换的关系模式如下：
　　例如，对于图5-34所示的零件、供应者和工程之间的三元联系，可以建立四个关系表： 零件表（零件号，零件名，………）。
　　供应者表（供应者号，供应者名，……）
　　工程表（工程号，工程名，………）
　　工程供应零件表（供应者号，零件号，工程号，供应数量）
　(3) 多重联系的转换
　　对于多重联系要一重一重的考虑。转换规则与单重联系相同。
　　例如，职工与设备之间的联系，有两个m：n的联系。每重增加一个新关系，即职工与设备之间的使用联系，以及职工与设备之间的保养联系：
　· 使用表（职工号，设备号，设备数量）
　· 保养表（职工号，设备号，设备数量） 　(4) 弱实体的处理
　· 弱实体不能独立存在，它必须依附于一个所有者实体。
　· 在转换成关系模式时，弱实体所对应的关系中必须包含所有者实体的主键。
　　例如，图3-35是一个弱实体的例子。家属是一个弱实体，职工是其所有者实体。转换成关系模式时，家属所对应的关系中必须包含职工号。职工号与家属的姓名构成家属的主键。
　E-R图转换为关系模式后，得到一般的关系数据模型。下一步就是向特定的DBMS规定的模型转换。设计人员必须熟悉所用DBMS的功能与限制。

　3. 数据模型的调整与完善
　　关系数据据库逻辑设计的结果不是唯一的。在逻辑结构设计的基础上，根据需要对设计结构进行适当的调整和完善，以期提高系统的性能。
　　关系数据模型的调整通常包括两个方面：
　· 根据数据字典中对信息查询响应时间的要求和查询频率要求，适当调整数据结构。如增加必要的冗余数据；或把经常进行查询连接的两个关系合并为一个关系。这些调整需要仔细考虑后再进行修改。
　· 根据局部应用要求，设计用户外部模型。就是设计用户视图。如设计符合用户习惯的属性别名；对不同级别的用户定义不同的视图，提高系统的安全性要求；为简化用户的对系统的使用，可以把某些复杂的查询定义为视图，用户可以直接对视图进行查询，使用户自觉简单、直观。
5.3.5 物理结构设计
　　数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系统和DBMS。
　　为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。
　　数据库的物理设计通常分为两步：
　(1) 确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构；
　(2)对物理结构进行评价，评价的内容是系统的时间和空间效率。
　　如果评价结果满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。
　1. 数据库物理设计的目标
　　不同的DBMS所提供的物理环境、存取方法和存储结构有很大差别，提供给设计人员使用的设计选择范围也很不相同，因此没有通用的物理设计方法可遵循，只能给出一般的设计内容和原则。希望设计优化的物理数据库结构，使得在数据库上运行的各种事务响应时间小、存储空间利用率高、事务吞吐率大。
　　综合数据库物理设计的目标是：
　(1) 提高数据库应用系统的性能，特别是满足主要应用的性能要求。
　(2) 有效地利用存储空间。
　　为此，首先须要对主要的运行事务进行详细分析，获得选择物理数据库设计所需要的参数。其次，要充分了解所用的RDBMS的内部特征，特别是系统提供的存取方法和存储结构。了解查询和更新事务是确定关系的存取方法的主要依据。
　　对于数据库查询事务，需要得到如下信息：
　● 经常查询的关系和查询条件所涉及的属性；
　● 连接条件所涉及的属性和查询的属性。
　　对于数据更新事务，需要得到如下信息：
　● 被更新的关系，每个关系上的更新操作条件所涉及的属性；
　● 修改操作经常要改变的属性值。
　　应注意的是，数据库上运行的事务会不断变化、增加或减少，以后需要根据上述设计信息的变化调整数据库的物理结构。
　2. 选择关系模式的存取方法
　　存取方法是快速存取数据库中数据的关键技术，物理设计的任务之一就是要确定选择哪些存取方法。常用的存取方法有索引方法和聚簇(Cluster)方法。
　(1) 索引存取方法
　　索引存取方法就是根据应用要求确定对关系的哪些属性列建立索引、哪些属性列建立组合索引、哪些索引要设计为唯一索引等。
　　选择索引的启发式规则是：
　①凡是满足下列条件之一的属性或表，不宜建立索引：
　· 不出现或很小出现在查询条件中的属性。
　· 属性值很少的属性。
　· 属性值分布严重不均的属性。
　· 经常更新的属性或表
　· 过长的属性
　· 太小的表
　②凡符合下列条件之一，可以考虑在有关属性上建立索引：
　· 主键或外键上一般都建有索引；
　· 对于以读为主或只读的表，如果存储空间允许，可以多建索引；
　· 对于等值查询，如果满足条件的元组是少量的，则可以考虑在有关属性上建立索引；
　· 对于范围查询，最好在有关的属性上建立簇集索引，如果已在其它属性上建立簇集索引，可以考虑建立非簇集索引。
　· 有些查询可以直接从索引直接得到结果，不必访问数据块。对于这种查询，可以考虑在有关属性上建立索引。
　这些查询包括：
　a)查询某属性的MIN、MAX、AVG、SUM、COUNT等聚集函数值(无GROUP BY子句)。
　b)查询某属性值EXIST或NOT EXISTS。
　(3) 聚簇存取方法:
　　为了提高某个属性(或属性组)的查询速度，把这个或这些属性(称为聚簇码)上具有相同值的元组集中存放在连续的物理块称为聚簇。
　　创建聚簇可以提高按聚簇码进行查询的效率。
　　例如：设要查询信息系的所有学生名单，如果信息系有500学生，在极端情况下，这500名学生所对应的数据元组分布在500个不同的物理块上，尽管可以按系名建立索引，由索引找到信息系学生的元组标识，但由元组标识去访问数据块时就要存取500个物理块，执行500次I/O操作。如果在系名这个属性上建立聚簇，则同一系的学生元组将集中存放，将显著地减少访问磁盘的次数。
　　使用聚簇需要注意的问题：
　· 一个关系最多只能加入一个聚簇；
　· 在一个关系上建立聚簇，将使此关系上的原有的索引无效，必须重建；
　· 在聚簇码中，应至少有一个属性，其说明为NOT NULL。
　· 聚簇对于某些特定应用可以明显地提高性能，但建立聚簇和维护聚簇的开销很大。
　　选择聚簇的启发式规则：
　①凡符合下列条件之一，可以考虑建立聚簇：
　· 通过聚簇码进行访问或连接是该表的主要应用，与聚簇码无关的其它访问很少或者是次要的。尤其当语句中包含与聚簇码有关的ORDER BY， GROUP BY， UNION， DISTINCT等语法成分时。
· 如果一个关系的一个或一组属性上的值的重复率很高。
　②凡存在下列条件之一，应考虑不建立聚簇：
　· 需要经常对全表进行扫描。
　· 在某属性列上的更新操作远多于查询和连接操作的表。
　　必须强调的是，聚簇只能提高某些应用的性能，而且建立与维护聚簇的开销是相当大的。对已有关系建立聚簇，将导致关系中元组移动其物理存储位置，并使此关系的存储位置也要做相应移动，聚簇码值要相对稳定，以减少修改聚簇码值所引起的维护开销。
　3.评价物理结构
　　在数据库物理设计过程中，需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
　　评价物理数据库的方法依赖于所选用的DBMS，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修改设计。
　　注释：物理设计也分为两部分：物理数据库结构的选择和逻辑设计中程序模块说明的精确化。这一阶段的工作成果是一个完整的能实现的数据库结构。

[ 本帖最后由 cayean 于 2007-1-29 14:14 编辑 ]

天那 ..真多哈。..