3.3数据库设计
数据库设计的过程是将数据库系统与现实世界密切地、有机地、协调一致地结合起来的过程。
数据库的设计质量与设计者的知识、经验和水平密切相关。
数据库设计是数据库应用系统的重要组成部分，数据库设计的成败往往直接关系到整个应用系统的成败。
以数据库为基础的数据库应用系统与其他计算机应用系统相比，所具有的特点：
- 数据量庞大
- 数据保存时间长
- 数据关联复杂
- 用户要求多样化等。
数据库设计中面临的主要困难和问题：
- 同时具备数据库知识与应用业务知识的人很少。
- 懂得计算机与数据库的人一般都缺乏应用业务知识
- 熟悉应用业务的人又往往不懂计算机和数据库。
- 项目初期往往不能确定应用业务的数据库系统的目标。
- 缺乏完善的设计工具和设计方法。
- 需求的不确定性。
- 用户总是在系统的开发过程中不断提出新的要求，甚至在数据库建立之后还会要求修改数据库结构或增加新的应用。
- 应用业务系统千差万别，
- 很难找到一种适合所有业务的工具和方法，这就增加了研究数据库自动生成工具的难度。
- 因此，研究适合一切应用业务的全自动数据库生成工具是不可能的。
3.3.1数据库设计的方法
目前已有的数据库设计方法可分为四类：
- 直观设计法（又称：单步逻辑设计法）
- 它依赖于设计者的知识、经验和技巧，
- 缺乏工程规范的支持和科学根据，设计质量不稳定。因此越来越不适应信息管理系统发展的需要。
- 规范设计法
- 为了改变直观设计法的缺陷，1978年10月来自30多个欧美国家的主要数据库专家在美国新奥尔良市讨论了数据库设计问题，提出了数据库设计规范。
- 将数据库设计分为：
- 需求分析
- 概念结构设计
- 逻辑结构设计
- 物理结构设计 共4个阶段。
- 将数据库设计分为：
- 常用的规范设计方法大多起源于新奥尔良方法，如基于：
- 3NF的设计方法 （架构设计师考试中，主要了解该方法即可）
- LRA方法
- 面向对象的数据库设计方法
- 基于视图概念的数据库设计方法 等
- 为了改变直观设计法的缺陷，1978年10月来自30多个欧美国家的主要数据库专家在美国新奥尔良市讨论了数据库设计问题，提出了数据库设计规范。
- 计算机辅助设计法
- 自动化设计法。
基于3NF的数据库设计方法是由S.Atre提出的数据库设计的结构化设计方法，
基本思想是：在需求分析的基础上，识别并确认数据库模式中的全部属性和属性间的依赖，将他们组织成一个单一的关系模型，然后再分析模式中不符合3NF的约束条件，用投影和连接的版本将其分解，使其达到3NF条件。
具体设计步骤分为5个阶段：
（1）设计企业模式。
利用上述得到的3NF关系模型画出企业模式，具体包括：
分析应用环境，并设定环境中所使用的各种资料。
确定每一种报表各自所包含的数据元素。
确定数据元素之间的关系，如确定主关键字和一般的数据元素。
对每一组或若干组元素数据元素推导出3NF的关系模型。
在3NF关系模型的基础上画出数据库的企业模式。
（2）设计数据库逻辑模式
根据上一步得到的企业模式选定数据模型，从而得出适用于某个DBMS的逻辑模式。根据逻辑模式导出各种报表与事务处理所使用的外模式。
（3）设计数据库物理模式（存储模式）。根据数据库的逻辑模式和给定的计算机系统 设计物理模式。
（4）评价物理模式。对物理模式估算空间利用情况，并推算输入输出的概率。必要时 根据物理模式调整各种报表与事务处理的外模式。对外模式进行存取时间的估算。
（5）数据库实现。
3.3.2 数据库设计的基本步骤
分步设计法遵循自顶向下、逐步求精的原则，
将数据库设计过程分解为若干相互独立又相互依存的阶段，每一阶段采用不同的技术与工具，解决不同的问题，从而将问题局部化，减少局部问题对整体设计的影响。
在分步设计法中，通常将数据库的设计分为需求分析、概念结构设计、逻辑结构设计和数据库物理设计4个阶段。
1、需求分析
需求分析是指收集和分析用户对系统的信息需求和处理需求，得到设计系统所必需的需求信息，建立系统说明文档。
目标是：通过调查研究，了解用户的数据要求和处理要求，并按一定格式整理形成需求说明书。
需求说明书是需求分析阶段的成果，也是今后设计的依据，它包括数据库所涉及的数据、数据的特征、使用频率和数据量的估计，如数据名、属性及其类型、主关键字属性、保密要求、完整性约束条件、更改要求、使用频率、数据量估计等。
这些关于数据的数据称为元数据。在设计大型数据库时，这些数据通常由数据字典来管理。用数据字典管理元数据有利于避免数据的重复或重名，以保持数据的一致性及提供各种统计数据，因而有利于提高数据库设计的质量，同时可以减轻设计者的负担。
2.概念结构设计
它是数据库设计的第二阶段，其目标是对需求说明书提供的所有数据和处理要求进行抽象与综合处理，按一定的方法构造反映用户环境的数据及其相互联系的概念模型，及用户的数据模型或企业数据模型。
这种概念数据模型与DBMS无关，是面向现实世界的、极易为用户所理解的数据模型。
进行概念结构设计时，可先设计各个应用的视图view，即各个应用所看到的数据及其结构，然后再进行视图集成，以形成一个单一的概念数据模型。这样形成的初步数据模型还要经过数据库设计者和用户的审查与修改，最后形成所需的概念数据模型。
3.逻辑结构设计
该阶段将概念设计阶段的得到的应用视图转换成外部模式，即特定DBMS下的应用视图。在转换过程中要进一步落实需求说明，并满足DBMS的各种限制。
该阶段的结果是用DBMS所提供的数据定义语言（DDL）写成的数据模式。
逻辑设计的具体方法与DBMS的逻辑数据模型有关。逻辑模型应满足数据库存取、一致性及运行等各方面的用户需求。
4.数据库物理设计
物理设计阶段的任务是把 逻辑设计阶段得到的满足用户需求的已确定的逻辑模型 在物理上加以实现。
主要内容：根据DBMS提供的各种手段，设计数据的存储形式和存取路径，如文件结构、索引设计等，即设计数据库的内模式或存储模式。
数据库的内模式对数据库的性能影响很大，应根据处理需求及DBMS、操作系统和硬件的性能进行精心设计。
实际上，数据库设计的基本过程与任何复杂系统开发一样，在每一阶段设计基本完成后，都要进行认真检查，看是否满足应用需求，是否符合前面已执行步骤的要求和满足后续步骤的需要，并分析设计结果的合理性。
在每一步设计中，都可能发现前面步骤的遗漏或处理不当之处，此时，往往需要返回去重新处理并修改设计有关文档。所以，数据库设计过程通常是一个反复修改、反复设计的迭代过程。
3.3.3需求分析
需求分析是数据库设计过程的第一步，是整个数据库设计的依据和基础。
阶段任务：
1.确认需求、确定设计目标
2.分析和收集数据
3.整理文档
3.3.4概念结构设计
概念结构设计目标：产生一个用户易于理解的，反映系统信息需求的整体数据库概念结构。
概念结构设计任务：在需求分析中产生的需求说明书的基础上按照一定的方法抽象成满足应用需求的用户的信息结构，即通常所称的概念模型。
概念结构的设计过程就是正确选择设计策略、设计方法和概念数据模型并加以实施的过程。
概念数据模型的作用：提供能够识别和理解系统要求的框架；为数据库提供一个说明性结构，作为设计数据库逻辑结构，即逻辑模型的基础。
概念结构的设计策略主要有：自底向上、自顶向下、由里向外和混合策略。
具体实现设计目标时有两种极端的策略或方案，一是：建立一个覆盖整个单位所有功能域的全局数据库，称之为全局方案或全局策略；
另一种是：对每一个应用都建立一个单独的数据库，称之为应用方案或应用策略。
由于各个部门对于数据的需求和处理方法各不相同，对同一类数据的观点也可能不一样，它们有自己的视图，所以可首先根据需求分析阶段产生的各个部门的数据流图和数据字典中的相关数据设计出各自的局部视图，然后进行视图集成。
1.视图设计
整个过程分为4个步骤：确定局部视图的范围；识别实体及其标识；确定实体间的联系；分配实体及联系的属性。
（1）确定局部视图的范围。需求说明书中标明的用户视图范围可作为确定局部视图范围的基本依据，但它通常与子模式范围相对应。
有时因为过大而不利于局部信息结构的构造，可根据情况修改，
不宜分得过小，过小会造成局部视图的数量太大及大量的数据冗余和不一致性，给以后的视图集成带来很大的困难。
局部视图范围确定的基本原则是：
1、各个局部视图支持的功能域之间的联系应最少。
2、实体个数适量。
一个局部视图所包含的实体数量反映了该局部视图的复杂性。
按照信息论中“7 2”的观点，人们在同一时刻可同时顾及的事情一般在5~9之间，以6或7最为适当。一个局部视图内的实体数不宜超过9个，否则就会过于复杂，不便于人们理解和管理。
（2）识别实体及其标识。
在确定的局部视图范围内，识别哪些数据对象作为局部视图的基本实体及其标识，并定义有关数据对象在E-R模型中的地位。
（3）确定实体间的联系。
实际上，识别联系的主要任务是在需求分析阶段完成的。这里的工作一是从局部视图的角度进行一次审核，检查有无遗漏之处，二是确切地定义每一种联系。
现实世界中，诸多形式的联系大致可分为三类：存在性联系、功能性联系和事件联系。
存在性联系，如：学校有教师、教室有学生、工厂有产品、产品有顾客等；
功能性联系，如：教师讲授课程、教师参与科研、仓库管理员管理仓库等；
事件联系，如：学生借书、产品发运等。
根据上述分类仔细检查在给定的局部视图范围内是否有未识别的联系，在确认所有的联系都已识别并无遗漏之后，还需对联系进行正确的定义。
定义联系就是对联系语义的仔细分析，识别联系的类型，确定实体在联系中的参与度。
①二元联系的类型与定义。
二元联系是指两个实体类之间的联系。
根据参与联系的两个实体类值之间的对应关系分为一对一、一对多及多对多三种类型。
实体类内部的联系：这种联系发生在同一类实体的不同实体之间，因此称为：内部联系或自联系，它也是一种二元联系，其表示方式与前面的二元联系并无不同，要注意仔细区别同一实体类中的不同实体在联系中扮演的不同角色及联系标识的选择。
②多元联系的识别与定义。
两个以上的实体类之间的联系称为多元联系。
2.视图集成
视图集成就是要将反映各用户组数据的局部数据模式综合成单位中某个确定范围内的单一数据视图，即全局数据模式，又称模式汇总。
该全局数据模式是未来数据库结构的基础，(☆☆☆)是数据库设计过程中一个十分重要的步骤，也是一项较为复杂和困难的任务。
当所有局部视图设计完毕，就可开始视图集成。集成过程中会发生一些冲突，冲突的表现和处理策略：
①同名异义。为了发现不同视图间的同名异义问题，可列出所有同名数据对象，
逐一判别语义。
处理：换名。
既可对同名者之一换名，也可对两者都以重新命名。
识别语义的主要方法是：进行值域分析。
②异名同义。识别比较困难，通常识别方法：由设计者对所有对象一个不漏地逐一鉴别。
处理：换名。
若归并时试图将两者合并为一个对象，则可把其中之一的名称作为合并后的对象名；
③同名不同层次。
如果两个对象同名，但其中之一是作为一个视图中的实体，而另一个是另一视图中的属性，则在集成时就会发生同名不同层次的冲突。
解决方法：
1.将属性转换为实体。2.将实体变换成属性。（？？）
希赛专家提示：
实体变换为属性时，通常需要满足一些特定条件，
例如，该实体通常只含有一个与同名属性具有共同特征的属性，且一定存在一与该实体存在联系的另外的实体。
④虽同名同义，但对象联系测度不同。
联系测度，是指实体的联系是一对一、一对多、还是多对多。
若同名同义对象在一个局部视图中为一对多联系，在另一局部视图中为多对多联系，则在集成时将发生联系测度冲突。
一般而言：一对多包含一对一，多对多包含一对多。
所以解决这种冲突的方法往往取较高测度为集成后的相应联系的测度。
