作者：whisper

链接：http://proprogrammar.com:443/article/587

声明：请尊重原作者的劳动，如需转载请注明出处

    7.4 逻辑结构设计

    逻辑结构设计的任务
    把概念结构设计阶段设计好的基本E-R图转换为与选用的DBMS产品所支持的逻辑结构
    目前主要使用关系模型，关系模型的逻辑结构是一组关系模式的集合

    7.4.1 E-R图向关系模型的转换

• 转换内容

    将E-R图转换为关系模型：
    将实体型、实体的属性和实体型之间的联系转化为关系模式。

• 转换原则

    E-R图向关系模型的转换原则

    1. 实体型的转换：一个实体型转换为一个关系模式

• 关系模式的属性：实体的属性
• 关系模式的码：实体的码

    2. 实体型间的1:1联系：
    可以转换为一个独立的关系模式

• 关系模式的属性：与该联系相连的各实体的码以及联系本身的属性
• 关系模式的候选码：每个实体的码均是该关系模式的候选码

    也可以与相连的任意一端对应的关系模式合并

• 关系模式的属性：

    与某一端关系模式合并，则在该关系模式的属性中加入另一端关系模式的码和联系的属性

• 合并后关系模式的码：不变

    E-R图向关系模型的转换示例

    [例]“管理”联系为1:1联系：
    (1)转换为一个独立的关系模式：
    管理(职工号，班级号) 或
    管理(职工号， 班级号)
    (2)“管理”与“班级”关系模式合并：
    班级(班级号，学生人数， 职工号)
    在“班级”中加入“教师”的码，即职工号
    (3)“管理”与“教师”关系模式合并

    教师(职工号，姓名，性别，职称， 班级号，是否为优秀班主任）
    在“教师”中加入“班级”的码，即班级号

    （1）转换为一个独立的关系模式

• 关系模式的属性：与该联系相连的各实体的码以及联系本身的属性
• 关系模式的候选码：每个实体的码均是该关系模式的候选码

    （2）（3）与任意一端实体所对应的关系模式合并

• 合并后关系模式的属性：原模式属性+另一个关系模式的码+联系的属性
• 合并后关系模式的码：不变

    [例]“组成”联系为1:n联系。
    将其转换为关系模式的两种方法：
    (1)使其成为一个独立的关系模式：
    组成（学号，班级号）
    (2)将其与“学生”合并：
    学生（学号，姓名，出生日期，所在系，年级， 班级号，平均成绩）

    3. 实体型间的1:n联系：
    转换为一个独立的关系模式

• 关系模式的属性：与该联系相连的各实体的码 + 联系本身的属性
• 关系模式的码： n端的 实体的码

    与n端对应的关系模式合并

• 合并后关系模式的属性：在n端关系模式中 + 1端关系的码 + 联系本身的属性
• 合并后关系模式的码：不变

    可以减少系统模式中的关系个数，一般情况下更倾向于采用这种方法

    [例]“选修”联系是一个m:n联系，将它转换为:
    选修（学号，课程号，成绩） , 其中学号与课程号为关系的组合码

    4. 实体型间的m:n联系：
    一个m:n联系转换为一个关系模式

• 关系的属性：与该联系相连的各实体的码以及联系本身的属性
• 关系的码：各实体码的组合

    [例] “讲授”联系是一个三元联系，可以将它转换为：
    讲授（课程号，职工号，书号）
    其中课程号、职工号和书号为关系的组合码

    5. 三个或三个以上实体间的一个多元联系
    转换为一个关系模式

• 关系模式的属性：与该多元联系相连的各实体的码 + 联系本身的属性
• 关系模式的码：各实体码的组合

    6.具有相同码的关系模式可合并
    目的：减少系统中的关系个数
    合并方法：

• 将其中一个关系模式的全部属性加入到另一个关系模式中
• 然后去掉其中的同义属性（可能同名也可能不同名）
• 适当调整属性的次序

    按照上述转换原则，学生管理子系统中的实体（9）和联系（9）转换为下列关系模型：

    7.4.2 数据模型的优化

    数据库逻辑设计的结果不是唯一的。
    得到初步数据据模式后，还应该适当地修改、调整数据库逻辑结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。
    关系数据模型的优化通常以规范化理论为指导。

    优化数据模型的方法:
    （1）确定数据依赖

• 按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。

    （2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
    （3）按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
    （4）按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。
    包括水平分解和垂直分解。

    几点注意
    对于一个具体应用来说，到底规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊来决定。
    当查询经常涉及两个或多个关系模式的属性时，系统必须经常地进行连接运算，连接运算的代价是相当高的。这种情况下，需要降低规范化程度。
    非BCNF的关系模式会存在不同程度的更新异常。如果在实际应用中对此关系模式只是查询，并不执行更新操作，就不会产生实际影响。

    7.4.3 设计用户子模式

    数据库模式——全局模式。
    考虑系统全局应用需求， 时间效率、空间效率、易维护等。
    用户子模式——视图机制
    考虑局部应用的特殊需求和用户体验。
    （1）使用更符合用户习惯的别名

• 合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。
• 在设计用户子模式时可以设计子模式时重新定义某些属性名，使其与用户习惯一致，以方便使用。

    （2）针对不同级别的用户定义不同的视图，提高系统的安全性
    假设有关系模式:
    产品（产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级）
    为一般顾客、为产品销售部门和管理部门建立不同的视图。
    （3）简化用户对系统的使用
    某些局部应用中经常要使用一些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。

    逻辑结构设计总结

    思考

    1. 从理论上讲， 1:1联系可以与任意一端对应的关系模式合并。在实际应用中，与不同的关系模式合并会有区别吗？
    2. 请对我们使用的示例——学生管理子系统基本E-R图以及转换的关系模式提出改进建议。

亲爱的读者：有时间可以点赞评论一下