4.3 概念结构设计
在需求分析阶段，设计人员充分调查并描述了用户的需求，但这些需求只是现实世界的具体要求，应把这些需求抽象为信息世界的结构，才能更好地实现用户的需求。
概念结构设计就是将需求分析得到的用户需求抽象为信息结构，即概念模型。
4.3.1 概念结构设计的必要性
在早期的数据库设计中，概念结构设计并不是一个独立的设计阶段。当时的设计方式是在需求分析之后，接着就进行逻辑设计。这样，设计人员在进行逻辑设计时，考虑的因素太多，既要考虑用户的信息，又要考虑具体DBMS的限制，使得设计过程复杂化，难以控制。为了改善这种状况，设计了基于E-R模型的数据库设计方法，即在需求分析和逻辑设计之间增加了一个概念设计阶段。在这个阶段，设计人员仅从用户角度看待数据及处理要求和约束，产生一个反映用户观点的概念模型，然后再把概念模型转换成逻辑模型。这样做有以下3个好处。
1）从逻辑设计中分离出概念设计以后，各阶段的任务相对单一化，设计复杂程度大大降低，便于组织管理。
2）概念模型不受特定的DBMS的限制，也独立于存储安排和效率方面的考虑，因而比逻辑模型更为稳定。
3）概念模型不含具体的DBMS所附加的技术细节，更容易为用户所理解，因而更有可能准确反映用户的信息需求。
4.3.2 概念模型的特点
概念模型作为概念结构设计的表达工具，为数据库提供一个说明性结构，是设计数据库逻辑结构即逻辑模型的基础。因此，概念模型必须具备以下特点：
1）语义表达能力丰富。概念模型能表达用户的各种需求，充分反映现实世界，包括事物和事物之间的联系、用户对数据的处理要求，它是现实世界的一个真实模型。
2）易于交流和理解。概念模型是DBA、设计人员和用户之间的主要界面，因此，概念模型要表达自然、直观和容易理解，以便和不熟悉计算机的用户交换意见，用户的积极参与是保证数据库设计成功的关键。
3）易于修改和扩充。概念模型要能灵活地加以改变，以反映用户需求和现实环境的变化。
4）易于向各种数据模型转换。概念模型独立于特定的DBMS，因而更加稳定，能方便地向关系模型、网状模型或层次模型等各种数据模型转换。
人们提出了许多概念模型，其中最著名、最实用的一种是E-R模型，它将现实世界的信息结构统一用属性、实体及它们之间的联系来描述。
4.3.3 概念结构设计的方法与步骤
1.概念结构设计的方法
概念结构设计的方法通常有四种。
1）自顶向下。首先定义全局概念结构的框架，然后逐步细化。
2）自底向上。首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构。
3）逐步扩张。首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构。
4）混合策略。将自顶向下和自底向上的方法相结合，用自顶向下策略设计一个全局概念结构的框架，以它为框架集成由自底向上策略中设计的各局部概念结构。
其中最常采用的策略是混合策略，即自顶向下进行需求分析，然后再自底向上设计概念结构，其方法如图4-4所示。
图4-4 自顶向下分析需求与自底向上概念结构设计
2.概念结构设计的步骤
按照图4-4所示的自顶向下需求分析与自底向上概念结构设计的方法，概念结构的设计可分为两步。
1）进行数据抽象，设计局部E-R模型。
2）集成各局部E-R模型，形成全局E-R模型，其步骤如图4-5所示。
图4-5 概念结构设计的步骤
3.数据抽象和局部E-R模型设计
概念设计是对现实世界的抽象。所谓抽象就是对实际的人、物、事和概念进行人为的处理，它抽取人们共同关心的特性，忽略非本质的细节，并将这些概念加以精确的描述。
（1）数据抽象
在系统需求分析阶段，最后得到了多层的数据流图、数据字典和系统分析报告。建立局部E-R模型，就是根据系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，作为设计分E-R图的出发点，让这组图中的每一部分对应一个局部应用。在前面选好的某一层次的数据流图中，每个局部应用都对应了一组数据流图，局部应用所涉及的数据存储在数据字典中。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，确定每个局部应用包含哪些实体，这些实体又包含哪些属性，以及实体之间的联系及其类型。
设计局部E-R模型的关键就是正确划分实体和属性。实体和属性之间在形式上并无可以明显区分的界限，通常是按照现实世界中事物的自然划分来定义实体和属性的，对现实世界中的事物进行数据抽象，得到实体和属性。数据抽象主要有两种方法：分类和聚集。
1）分类（Classification）
分类就是定义某一类概念作为现实世界中一组对象的类型，并将一组具有某些共同特性和行为的对象抽象为一个实体。
例如，在教学管理中，“王艳”是学生当中的一员，她具有学生们共同的特性和行为：在哪个班、学习哪个专业、年龄有多大等。
2）聚集（Aggregation）
聚集就是定义某一类型的组成部分，并将对象类型的组成部分抽象为实体的属性。
例如，学号、姓名、性别、年龄、系别等可以抽象为学生实体的属性。
（2）局部E-R模型设计
设计E-R图首先需要根据系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，让这组图中的每一部分对应一个局部应用，然后以这一层次的数据流图为出发点，设计E-R图。将各局部应用涉及的数据分别从数据字典中抽取出来，参照数据流图，确定各局部应用中的实体、实体的属性、标识实体的码、实体之间的联系及其类型（1∶1，1∶n，m∶n）。
实际上实体和属性是相对而言的。同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就有可能作为“实体”。
如图4-6所示，大学中的“系”，在某种应用环境中，它只是作为“学生”实体的一个属性，表明一个学生属于哪个系；而在另一种环境中，由于需要考虑一个系的系主任、教师人数、学生人数、办公地点等，因而它需要作为实体。
图4-6 “系”由属性上升为实体的示意图
因此，为了解决这个问题，应当遵循如下两条基本准则：
1）属性不能再具有需要描述的性质，即属性必须是不可分的数据项，不能再由另一些属性组成。
2）属性不能与其他实体具有联系。联系只发生在实体之间。
符合上述两条特性的事物一般作为属性对待。为了简化E-R图的处理，现实世界中的事物凡能够作为属性对待的，应尽量作为属性。
【例4-1】设有如下实体。
学生：学号、系名称、姓名、性别、年龄、选修课程名。
课程：编号、课程名、开课单位、任课教师号。
教师：教师号、姓名、性别、职称、讲授课程编号。
单位：单位名称、电话、教师号、教师姓名。
上述实体中存在如下联系：
1）一个学生可选修多门课程，一门课程可为多个学生选修。
2）一个教师可讲授多门课程，一门课程可为多个教师讲授。
3）一个系可有多个教师，一个教师只能属于一个系。
根据上述约定，可以得到学生选课局部E-R图和教师授课局部E-R图，分别如图4-7和图4-8所示。
4.全局E-R模型设计
各个局部E-R图建立好后，还需要对它们进行合并，集成为一个整体的概念数据结构，即全局E-R图。局部E-R图的集成有两种方法。
图4-7 学生选课局部E-R图
图4-8 教师授课局部E-R图
1）多元集成法，也叫一次集成，一次性将多个局部E-R图合并为一个全局E-R图，如图4-9a所示。
2）二元集成法，也叫逐步集成，首先集成两个重要的局部E-R图，然后用累加的方法逐步将一个新的E-R图集成进来，如图4-9b所示。
图4-9 局部E-R图集成的两种方法
在实际应用中，可以根据系统复杂性选择这两种方案。如果局部图比较简单，可以采用一次集成法。在一般情况下，采用逐步集成法，即每次只综合两个图，这样可降低难度。
无论使用哪一种方法，E-R图集成均分为如下两个步骤：
1）合并，消除各局部E-R图之间的冲突，生成初步E-R图。
2）优化，消除不必要的冗余，生成基本E-R图。
（1）合并分E-R图，生成初步E-R图
这个步骤将所有的局部E-R图综合成全局概念结构。全局概念结构不仅要支持所有的局部E-R模型，而且必须合理地表示一个完整、一致的数据库概念结构。
由于各个局部应用所面向的问题不同，并且通常由不同的设计人员进行局部E-R图设计，因此，各局部E-R图不可避免地会有许多不一致的地方，通常把这种现象称为冲突。
因此，当合并局部E-R图时并不是简单地将各个E-R图画到一起，而是必须消除各个局部E-R图中的不一致，使合并后的全局概念结构不仅支持所有的局部E-R模型，而且必须是一个能为全系统中所有用户共同理解和接受的统一的概念模型。合并局部E-R图的关键就是合理消除各局部E-R图中的冲突。
E-R图中的冲突有三种：属性冲突、命名冲突和结构冲突。
1）属性冲突。属性冲突又分为属性值域冲突和属性的取值单位冲突。
①属性值域冲突。即属性值的类型、取值范围或取值集合不同。例如，学生的学号，通常用数字表示，这样有些部门就将其定义为数值型，而有些部门则将其定义为字符型。
②属性的取值单位冲突。比如零件的重量，有的以千克为单位，有的以斤为单位，有的则以克为单位。
属性冲突属于用户业务上的约定，必须与用户协商后解决。
2）命名冲突。命名不一致可能发生在实体名、字段名或联系名之间，其中属性的命名冲突最为常见。一般表现为同名异义或异名同义。
①同名异义，即同一名字的对象在不同的局部应用中具有不同的意义。例如，“单位”在某些部门表示为人员所在的部门，而在某些部门可能表示物品的重量、长度等属性。
②异名同义，即同一意义的对象在不同的局部应用中具有不同的名称。例如，对于“房间”这个名称，在教务管理部门中对应教室，而在后勤管理部门中对应学生宿舍。
命名冲突的解决方法同属性冲突的相同，需要与各部门协商、讨论后加以解决。
3）结构冲突。
①同一对象在不同应用中有不同的抽象，既可能为实体，也可能为属性。例如，教师的职称在某一局部应用中被当作实体，而在另一局部应用中被当作属性。这类冲突在解决时，就是使同一对象在不同应用中具有相同的抽象，或把实体转换为属性，或把属性转换为实体，但都要符合4.3.3节所介绍的两条准则。
②同一实体在不同局部应用中的属性组成不同，可能是属性个数或属性的排列次序不同。解决办法是，合并后的实体的属性组成为各局部E-R图中的同名实体属性的并集，然后再适当调整属性的排列次序。
③实体之间的联系在不同局部应用中呈现不同的类型。例如，局部应用X中E1与E2可能是一对一联系，而在另一局部应用Y中既可能是一对多或多对多联系，也可能是在E1、E2、E3三者之间有联系。解决方法：根据应用语义对实体联系的类型进行综合或调整。
如何消除各局部E-R图之间的冲突，并进行局部E-R模型的合并，从而生成初步E-R图？首先，这两个局部E-R图中存在命名冲突，学生选课局部E-R图中的实体“系”与教师任课局部E-R图中的实体“单位”都是指系，即所谓异名同义，合并后统一改为“系”，这样属性“名称”和“单位名称”即可统一为“系名”。其次，还存在结构冲突，实体“系”和实体“课程”在两个局部E-R图中的属性组成不同，合并后这两个实体的属性组成为各局部E-R图中的同名实体属性的并集。解决上述冲突后，合并两个局部E-R图，就能生成初步的全局E-R。
（2）消除不必要的冗余，生成基本E-R图
在初步的E-R图中，可能存在冗余的数据和冗余的实体之间的联系。冗余的数据是指可由基本数据导出的数据，冗余的联系是指由其他联系导出的联系。冗余的存在容易破坏数据库的完整性，给数据库的维护增加困难，应该消除。当然，不是所有的冗余数据和冗余联系都必须消除，有时为了提高某些应用的效率，不得不以冗余信息作为代价。
设计数据库概念模型时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。把消除了冗余的初步E-R图称为基本E-R图。
通常采用分析的方法消除冗余。数据字典是分析冗余数据的依据，还可以通过数据流图分析出冗余的联系。
如在图4-7和图4-8所示的初步E-R图中，“课程”实体中的属性“教师号”可由“讲授”这个教师与课程之间的联系导出，而学生的平均成绩可由“选修”联系中的属性“成绩”中计算出来，所以，“课程”实体中的“教师号”与“学生”实体中的“平均成绩”均属于冗余数据。
另外，“系”和“课程”之间的联系“开课”，可以由“系”和“教师”之间的“属于”联系与“教师”和“课程”之间的“讲授”联系推导出来，所以，“开课”属于冗余联系。
这样，图4-7和图4-8的初步E-R图在消除冗余数据和冗余联系后，便可得到基本的E-R模型，如图4-10所示。
图4-10 优化后的基本E-R图
最终得到的基本E-R模型是企业的概念模型，它代表了用户的数据要求，是沟通“要求”和“设计”的桥梁，它决定数据库的总体逻辑结构，是成功创建数据库的关键。如果设计不好，就不能充分发挥数据库的功能，无法满足用户的处理要求。
因此，用户和数据库人员必须对这一模型反复讨论，在用户确认这一模型已正确无误地反映了他们的要求之后，才能进入下一阶段的设计工作。