4.3 概念结构设计
将需求分析得到的用户需求抽象为信息结构，即概念模型的过程就是概念结构设计。概念结构设计是整个数据库设计的关键。概念模型独立于计算机硬件结构，独立于数据库的DBMS。
4.3.1 概念结构设计的必要性及要求
在进行数据库设计时，如果将现实世界中的客观对象直接转换为机器世界中的对象，会很不方便。注意力往往被转移到更多的细节限制方面，而不能集中在最重要的信息的组织结构和处理模式上。因此，通常是将现实世界中的客观对象首先抽象为不依赖于任何具体机器的信息结构，这种信息结构不是DBMS所支持的数据模型，而是概念模型。然后再把概念模型转换为具体机器上DBMS支持的数据模型，设计概念模型的过程称为概念设计。
1．将概念设计从数据库设计过程中独立出来的优点
将概念设计从数据库过程中独立出来具有以下优点。
1）各阶段的任务相对单一，设计复杂程度大大降低，便于组织管理。
2）不受特定的DBMS的限制，也独立于存储安排和效率方面的考虑，因而比逻辑模式更为稳定。
3）概念模式不含具体的DBMS所附加的技术细节，更容易为用户所理解，因而才有可能准确地反映用户的信息需求。
2．概念模型的要求
1）概念模型是对现实世界的抽象和概括，应真实、充分地反映现实世界中事物和事物之间的联系，有丰富的语义表达能力，能表达用户的各种需求，是现实世界的一个抽象模型。
2）概念模型应简洁、清晰、独立于机器，易于理解，方便数据库设计人员与应用人员交换意见，用户的积极参与是数据库设计成功的关键。
3）概念模型应易于更改，当应用环境和应用要求改变时，容易对概念模型进行修改和扩充。
4）概念模型应该易于向关系、网状、层次等各种数据模型转换，易于从概念模式导出与DBMS有关的逻辑模式。
选用何种概念模型完成概念设计任务，是进行概念设计前应该考虑的首要问题。用于概念设计的模型既要有足够的表达能力，使之可以表示各种类型的数据及其相互间的联系和语义，又要简单易懂。这种模型有很多，如E-R模型、语义数据模型和函数数据模型等。其中，E-R模型提供了规范、标准的构造方法，成为应用最广泛的概念结构设计工具。
4.3.2 概念结构设计的方法与步骤
1．概念结构设计的方法
概念结构设计的方法有如下4种。
（1）自顶向下方法
根据用户要求，先定义全局概念结构的框架，然后分层展开，逐步细化，如图4-7所示。
图4-7 自顶向下方法
（2）自底向上方法
根据用户的每一项具体需求，先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构，如图4-8所示。
自底向上设计概念结构如图4-9所示，通常分为以下两步。
1）抽象数据并设计局部视图。
2）集成局部视图，得到全局概念结构。
（3）逐步扩张方法
首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至全局概念结构，如图4-10所示。
图4-8 自底向上方法
图4-9 自底向上设计概念结构两步法
图4-10 逐步扩张方法
（4）混合策略方法
混合策略方法即将自顶向下和自底向上方法相结合，先用自顶向下策略设计一个全局概念结构的框架，再以它为骨架集成由自底向上策略中设计的各局部概念结构。
在需求分析中，较为常见的方法是采用自顶向下描述数据库的层次结构，而在概念结构的设计中最常采用的策略是自底向上方法。即自顶向下地进行需求分析，然后再自底向上地设计概念结构，如图4-11所示。
2．概念结构设计的步骤
概念结构设计的步骤如下。
1）进行局部数据抽象，设计局部概念模式。局部用户的信息需求是构造全局概念模式的基础，因此，需要先从个别用户的需求出发，为每个用户建立一个相应的局部概念结构。在建立局部概念结构时，常常要对需求分析的结果进行细化补充和修改，如有的数据项要分为若干子项，有的数据定义要重新核实等。
2）将局部概念模式综合成为全局概念模式。综合各局部概念模式可以得到反映所有用户需求的全局概念模式。在综合过程中，主要处理各局部模式对各种对象定义的不一致性问题，包括同名异义、异名同义和同一事物在不同模式中被抽象为不同类型的对象等问题。把各个局部结构连接、合并，还会产生冗余问题，有可能导致对信息需求的再调整与分析，以确定准确的含义。
图4-11 混合策略方法
3）评审。消除了所有冲突后，就可以把全局概念模式提交评审。评审分为用户评审与DBA及应用开发人员评审两部分：用户评审的重点放在确认全局概念模式是否准确完整地反映了用户的信息需求和现实世界事物的属性间的固有联系；DBA和应用开发人员评审则侧重于确认全局概念模式是否完整，各种成分划分是否合理，是否存在不一致性等。
4.3.3 采用E-R模型设计概念结构的方法
实体联系模型简称E-R模型，由于通常用图形表示，又称E-R图。它是数据库设计中最常用的概念模型设计方法之一。采用E-R模型设计方法分为如下3步。
1．设计局部E-R模型
基于E-R模型的概念设计是用概念模型描述目标系统涉及的实体、属性及实体间的联系。这些实体、属性和实体间联系是对现实世界的人、事、物等的抽象，它是在需求分析的基础上进行的。
抽象的方法一般包括如下3种。
（1）分类（classification）
将现实世界中具有些种共同特征和行为的对象作为一个类型。它抽象了对象值和型之间的“is member of”（是……的成员）的语义。例如，在学校环境中，学生是具有某些共同特征和行为的对象，可以将其视为一个类型。王芮是学生，它是这个类中一个具体的值，如图4-12所示。
（2）概括（generalization）
定义类型之间的一种子集联系。它抽象了类型之间的“is subset of”（是……的子集）的语义。例如课程是一个实体型，必修课、选修课也是一个实体型，必修课和选修课均是课程的子集，如图4-13所示。
图4-12 分类
（3）聚集（aggregation）
定义某一类型的组成成分。它抽象了对象内部类型和成分之间“is part of”（是……的一部分）的语义，如图4-14所示。
图4-13 概括
图4-14 聚集
局部E-R模型的设计过程如图4-15所示。
图4-15 局部E-R模型设计过程
（1）确定局部结构范围
设计各个局部E-R模型的第一步是确定局部结构的范围划分。划分的方式一般有两种：一种是依据系统的当前用户进行自然划分；另一种是按用户要求数据提供的服务归纳为几类，使每一类应用访问的数据明显区别于其他类，然后为每一类应用设计一个局部E-R模型。
局部结构范围确定时要考虑以下因素。
1）范围的划分要自然，易于管理。
2）范围之间的界限要清晰，相互之间的影响要小。
3）范围的大小要适度。太小了，会造成局部结构过多，设计过程烦琐；太大了，则容易造成内容结构复杂，不便于分析。
（2）实体定义
每一个局部结构都包括一些实体，实体定义的任务就是从信息需求和局部范围定义出发，确定每一个实体的属性和码。
事实上，实体、属性和联系之间并无形式上可以截然区分的界限，划分的依据通常有以下3条。
1）采用人们习惯的划分。
2）避免冗余，在一个局部结构中，对一个对象只取一种抽象形式，不要重复。
3）根据用户的信息处理需求。
（3）联系定义
联系用来刻画实体之间的关联。一个完整的方式是对局部结构中任意两个实体，依据需求分析的结果，考察两个实体之间是否存在联系。若有联系，进一步确定是1:1、1:n还是m:n联系。还要考察一个实体内部是否存在联系，多个实体之间是否存在联系等。
在确定联系类型时，应防止出现冗余的联系（即可用从其他联系导出的联系），如果存在，要尽可能地识别并消除这些冗余联系。
联系在命名时，应能反映联系的语义性质，通常采用某个动词命名，如“选修”“授课”等。
（4）属性分配
实体与联系确定后，局部结构中的其他语义信息大部分可以用属性描述。属性分配时，首先要确定属性，然后将其分配到相关的实体和联系中去。
确定属性的原则是：属性应该是不可再分解的语义单位；实体与属性之间的关系只能是1:n的；不同实体类型的属性之间应无直接关联关系。
属性不可分解可以使模型结构简单，不出现嵌套结构。当多个实体用到一个属性时，将导致数据冗余，从而影响存储效率和完整性约束，因而需要确定把它分配给哪个实体。一般把属性分配给那些使用频率最高的实体，或分配给实体值少的实体。
有些属性不宜归属于任何一个实体，只说明实体之间联系的特性。例如，学生选修某门课程的成绩，既不能归为学生实体的属性，也不能归为课程实体的属性，应作为“选修”联系的属性。
2．设计全局E-R模型
所有的局部E-R模型设计好后，接下来就是把它们综合成一个全局概念结构。全局概念结构不仅要支持所有局部E-R模型，而且必须合理地表示一个完整、一致的数据库概念结构。把局部E-R模型集成为全局E-R模型时，有两种方法：一种是多个分E-R图一次集成，通常用于局部视图比较简单时使用。也可以逐步集成，用累加的方式一次集成两个分E-R图，从而降低复杂度。
全局E-R模型的设计过程如图4-16所示。
图4-16 全局E-R模型的设计过程
（1）确定公共实体
为了给多个局部E-R模型的合并提供基础，首先要确定局部结构的公共实体。一般把同名实体作为公共实体的一类候选，把具有相同码的实体作为公共实体的另一类候选。
（2）局部E-R模型的合并
合并的顺序有时会影响处理效率和结果。建议的合并原则是：首先进行两两合并：先合并那些现实世界中有联系的局部结构；合并从公共实体开始，最后再加入独立的局部结构，从而减少合并工作的复杂性，并使合并结果的规模尽可能小。
（3）消除冲突
由于各个局部应用所面向的问题不同，且通常是由不同的设计人员进行局部E-R模型设计，导致各个分E-R图之间存在许多不一致的地方，称为冲突。解决冲突是合并E-R模型的主要工作和关键所在。
各分E-R图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。
1）属性冲突。
属性域冲突，即属性值的类型、取值范围或取值集合不同。例如学号，有的部门把它定义为整数，有的部门把它定义为字符型，不同的部门对学号的编码也不同。
属性取值单位冲突。例如，成绩有的用百分制，有的用五级制（A、B、C、D、E）。
2）命名冲突。
同名异义：不同意义的对象在不同的局部应用中具有相同的名字。
异名同义（一义多名）：同一意义的对象在不同的局部应用中具有不同的名字。
3）结构冲突。
同一对象在不同应用中具有不同的抽象。例如，教师在某一局部应用中被当作实体，而在另一局部应用中被当作属性。
实体之间联系在不同的局部E-R图中呈现不同类型。例如，E1与E2在某一个应用中是多对多联系，而在另一个应用中是一对多联系。
属性冲突和命名冲突通常采用讨论、协商等行政手段解决，结构冲突则要认真分析后才能解决。
3．优化全局E-R图
得到全局E-R图后，为了提高数据库系统的效率，还应进一步依据需求对E-R图进行优化。一个好的全局E-R图除了能准确、全面地反映用户功能需求外，还应满足如下条件：
● 实体个数尽可能少；
● 实体所包含的属性尽可能少；
● 实体间的联系无冗余。
但是这些条件不是绝对的，要视具体的信息需求与处理需求而定。全局E-R模型的优化原则如下。
（1）实体的合并
这里实体合并指的是相关实体的合并，在公共模型中，实体最终转换成关系模式，涉及多个实体的信息要通过连接操作获得。因而减少实体的个数，可减少连接的开销，提高处理效率。
（2）冗余属性的消除
通常，在各个局部结构中是不允许冗余属性存在的，但是，综合成全局E-R图后，可能产生局部范围内的冗余属性。当同一非主属性出现在几个实体中，或者一个属性值可以从其他属性的值导出时，就存在冗余属性，应该把冗余属性从全局E-R图中去掉。
冗余属性消除与否，取决于它对存储空间、访问效率和维护代价的影响。有时为了兼顾访问效率，有意保留冗余属性。
（3）冗余联系的消除
在全局E-R图中，可能存在冗余的联系，可以利用规范化理论中的函数依赖的概念消除冗余联系。