目录.
概念结构设计宏观步骤.
依据案例的数据流图DFD以及数据字典DD：
- 建立局部E-R模型
- 合并优化多个局部E-R模型
- 得到全局E-R模型
局部E-R模型设计.
以学校中的教师任课以及学生选课关系为例，分析其中所涉及的数据结构以及多个数据结构间的联系，可以得到如下所示的实体间的语义约定：
- 一名学生可以选修多门课程，一门课程也可以被多名学生选修，所以课程实体与学生实体之间的选课关系是一个1:n的联系；
- 一个系别可以拥有多名学生，而一个学生只能属于一个系别，所以学生实体和系别实体之间的属于关系是一个n:1的联系；
- 一个系别可以开设多门课程，而一门课程只能由一个系别开设，所以系别实体和课程实体之间的开设关系是一个1:n的联系；
- 一名教师可以教授多门课程，一门课程也可以由多名教师合作教授，所以课程实体与教师实体之间的任课关系是一个m:n的联系；
- 一个系别可以聘请多名教师，而一个教师却只能被一个系别所聘请，所以系别实体和教师实体之间的聘请关系是一个1:n的联系；
将上述合乎常理的语义约定中，涉及的数据结构转化为E-R图中的实体，涉及的联系转化为E-R图中的联系，得到的部分E-R图如下所示：
E-R图冲突.
1.属性冲突.
- 【值域冲突】属性的类型、取值范围或取值集合不同，以学号为例，可以将其定义为数值型，也可以将其定义为字符型；再比如年龄，既可以用出生年月暗示，也可以之间使用数值表示的年龄；
- 【取值单位冲突】例如学生体重，可使用Kg为单位衡量，又可以使用g为单位衡量。
属性冲突属于用户业务上的约定，与用户进行协商后具体解决即可，例如统一学生的学号为字符型，因为可能包括A、B、C，体重统一用T为单位衡量，因为学生不愿意看到自己的体重是一个大数值。
2.命名冲突.
有关命名的冲突可能发生在实体名、属性名和联系名之间，最为常见的属性名之间的冲突，大多表现为同名异义或异名同义的语义歧义问题，也不知道语文是怎么学的。
- 【同名异义】源于中华文化的博大精深，例如“单位”这个属性，在某些情况下代表一个人工作的组织；另外的应用环境中又表示衡量物体某种属性的基准；
- 【异名同义】再一次源于中华文化的博大精深，比如说我的手机号码是12345678999，它可以被称为“联系方式”，也可以被称为“手机号码”，还能被称为“取件凭证”。
命名冲突和属性冲突类似，需要与用户协商后具体解决。
3.结构冲突.
- 同一个对象在不同的应用中有不同的抽象，可能既是实体又是属性，例如系别作为一个表示学校中某个专业的实体，也可以是学生实体的属性之一。
这类冲突在解决时需要统一对于对象的抽象，或将实体转换为属性，或将属性转换为实体。 - 同一个实体在不同应用场景下的组成属性不同。
解决方法是统一属性集为各个局部E-R图中属性集的并集。 - 同一个联系在不同的应用场景下呈现不同的类型，可能在一个局部E-R图中是1:n的联系，在另外的E-R图中是1:1的联系。
解决这类冲突时需要根据语义对联系进行调整。
合并局部E-R模型.
首先我们发现，学生选课局部E-R图和教师任课局部E-R图中存在实体的【异名同义】现象，前者的【系】实体和后者的【单位】实体实际上代表的都是学院中的某个专业，并且这两个实体还存在属性组成的冲突，其中的属性【名称】和【单位名】还属于属性的异名同义，需要进行统一以及对属性集的求并操作。
再观察发现两个局部图中的【课程】实体存在结构冲突，它们的属性集不一致，需要进行求并操作。
解决上述的冲突之后，得到的初步E-R图如下所示：
E-R图冗余.
冗余分为数据冗余和实体联系冗余。
- 【数据冗余】可以由基本数据导出的数据，例如学生选修各门课程的单项成绩以及平均成绩，后者就是可以由前者导出的冗余数据。
- 【联系冗余】可以由其他联系导出的联系，例如支付宝提供共享单车、共享单车方便人类以及支付宝服务人类，第三个联系就是可以由前两个联系导出的冗余联系。不是打广告，就是想不出好的例子了。
消除冗余的方法基于分析得出，这就是前面数据库规范化理论的意义所在了。
优化初步E-R图.
上面给出的初步E-R图中存在着冗余数据和冗余联系，例如教师号这一属性，在教师实体中出现了一次，而在课程实体中又出现了一次(仔细思考发现课程实体，和教师号并没什么必然联系，每一年不同的老师教同一门课程，每一个老师也教着不同的课程)；学生的平均成绩属性可以由选修关系的成绩属性经过处理得出。【教师教授课程】以及【教师属于系别】两个联系能够推导出【系别开设课程】这一联系，所以第三者属于冗余的联系。
经过优化之后，得到的基本E-R图如下所示，至此可以开始逻辑结构的设计。
关系模式转换.
前面的得到了教务管理系统的基本E-R图，后续进行关系数据库逻辑设计就是要得到一组关系模式的集合，所以将E-R图转换为关系模型就是将实体、属性以及联系转换成关系模式。转换时的原则如下所示：
- 【实体-关系模式】实体的属性就是关系的属性，实体的主码就是关系的主码。
- 【联系-关系模式】关系的属性是该联系本身的属性以及联系涉及到的那些实体的主码，关系的主码需要根据联系的类型来确定：
①1:1关系的主码可以是涉及到实体中任意一个的主码；
②1:n关系的主码是n那端实体的主码；
③m:n关系的主码是每个实体主码的组合。 - 【特殊情况】三个及以上的实体组成的多元联系，转换的具体方法是将所有实体的主码组合，成为多元关系模式的主码，多元关系模式的属性集即为所有实体的主码集合并上关系本身的属性集合。
回顾前面得到的基本E-R图，我们对于其中的实体进行转化：
- 学生(学号、姓名、性别、年龄)
- 课程(课程号、课程名)
- 系(系编号、系名、电话)
- 教师(教师号、姓名、性别、职称)
后续对于其中的联系进行转化：
- 选修(学号、课程号、成绩)
- 讲授(教师号、课程号)
- 属于(教师号、系编号)
- 拥有(学号、系编号)
上述关系模式的转化是基于全局E-R模型得到的，因此上述关系模型满足3NF，后续如果有更严格的要求，可以继续向BCNF以及4NF规范化。
合并关系模式.
上面依据全局E-R图转化得到的关系模式集合中，存在一些能够合并的关系模式。原则是合并那些具有相同主码的关系模式，例如【学生】与【拥有】、【教师】与【属于】，合并之后的关系模式如下所示：
- 学生(学号、姓名、性别、年龄、系编号)
- 教师(教师号、姓名、性别、职称、系编号)
最后整个教务管理系统的关系模式集合如下：
- 教师(教师号、姓名、性别、职称、系编号)
- 学生(学号、姓名、性别、年龄、系编号)
- 课程(课程号、课程名)
- 系(系编号、系名、电话)
- 选修(学号、课程号、成绩)
- 讲授(教师号、课程号)