第六章 数据库设计

第六章 数据库设计 6.1 数据库设计概述 6.2 需求分析 6.3 概念结构设计 6.4 逻辑结构设计 6.5 数据库的物理设计 第六章 数据库设计 6.1 数据库设计概述 6.2 需求分析 6.3 概念结构设计 6.4 逻辑结构设计 6.5 数据库的物理设计 6.6 数据库实施 6.7 数据库运行与维护 6.8 小结

6.1数据库设计的步骤（1） 目前主要采用以逻辑数据库设计和物理数据库设计为核心的规范设计方法。 逻辑数据库设计-设计全局逻辑结构和每个用户的局部逻辑结构，将概念结构转换为某个DBMS支持的数据模型并优化 物理数据库设计-为逻辑数据模型选一个最适合应用环境的物理结构，设计数据库的存储结构、存取方法及其他实现细节

6.1数据库设计的步骤（2） 选定参加设计的人员： 数据库分析设计人员-核心，自始至终 用户-重要，需求分析(头)，运行和维护(尾) 程序员-编制程序 操作员-准备软硬件环境

数据库设计过程图 概念结构设计 需求分析 逻辑结构设计 数据库物理设计 数据库实施 数据库运行和维护

6.2需求分析 6.2.1任务 重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性和完整性要求 信息要求-用户需从库中获得信息的内容和性质，存储哪些信息于库中 处理要求-要求完成的功能、响应时间、方式是批处理还是联机处理

6.2需求分析 6.2.1任务 困难在： 用户缺少计算机知识，无法准确表达自己的需求，需求往往不断变化 设计人员缺乏用户的专业知识，不易理解甚至误解用户的需求。 软硬件技术的出现会使用户需求发生变化

6.2需求分析 6.2.2需求分析的方法（1） 调查与初步分析用户需求需四步： 调查组织机构情况：部门组成、职责，为分析信息流程做准备 调查各部门业务活动情况：输入和使用什么数据，如何加工处理这些数据，输出什么信息、到哪里、输出结果的格式 协助用户明确对新系统的要求 确定新系统边界，哪些是计算机完成的功能

6.2需求分析 6.2.2需求分析的方法（2） 常用的调查方法： 跟班作业 开调查会-用户彼此启发 请专人介绍 询问-专人 设计调查表请用户填写 查阅记录-与原系统有关的数据记录

6.2需求分析 分析和表达用户需求的方法主要包括：自顶向下（SA）和自底向上方法

数据存储 数据流 数据流 数据来源 处理 数据输出

然后将处理功能分解，不停分解，直至系统工作过程被表达清楚；数据也逐级分解，形成若干层次的数据流图。 数据流图表达了数据和处理过程的关系 数据借助数据字典描述 处理过程的处理逻辑借助判定表或判定树来描述

实例：开发学校管理系统 高层数据流图 管理信息系统 后勤管理子系统 教师管理子系统 学生管理子系统 课程管理 学籍管理

实例（续） 学生管理子系统的主要功能：学籍管理和课程管理。包括：学生报到、入学、毕业、上课情况管理。通过详细的信息流程分析和数据收集后，生成该系统的数据流图。见188-189

6.3概念结构设计 6.3.1概念结构设计方法与步骤 概念结构设计--将需求分析得到的用户需求抽象为概念模型的过程 6.3概念结构设计 6.3.1概念结构设计方法与步骤 概念结构设计--将需求分析得到的用户需求抽象为概念模型的过程 概念结构独立于数据库逻辑结构，也独立于DBMS 四类方法： 自顶向下 自底向上—经常采用。即自顶向下进行需求分析，再自底向上设计概念结构。 逐步扩张-先定义核心概念，然后向外扩充 混合策略

6.3.2分E-R图设计（1） 在多层数据流图中选择一个适当层次的数据流图，让每一部分对应一个局部应用，因为中层的数据流图能较好地反映系统中各局部应用的子系统组成，所以一般作为分E-R图的依据 参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型。

6.3.2设计分E-R图（2） 现实世界中一组具有共同特性和行为的对象可抽象为一个实体，例，张三、李斯、王五可抽象为学生实体 对象的组成成分可抽象为实体的属性，例，学号、姓名、年级等可抽象为学生实体的属性，其中学号为标识实体的码 实体与属性很难划分界限。例，系是学生实体的属性，在需要考虑系主任、教师人数、学生人数、办公地点时就需要作为实体了。

6.3.2设计分E-R图（3） 属性和实体区别的原则： 属性不能再具有需要描述的性质。即为不可再分的数据项 属性不能与其他实体具有联系。联系只能发生在实体之间。 能做属性对待尽量作属性。

“职称”分别作为实体和属性 评定 教师 职称 教师 分配 姓名 性别 姓名 性别 职称 住房

学籍管理分E-R图草图 管理 上课 班主任 班级 教室 指导 组成 住宿 归档 学生 档案材料 宿舍

对学籍管理E-R草图调整 一般，性别应作为学生实体的属性，本应用中由于宿舍分配与性别有关，依据准则2-属性不能与其他实体有联系，性别应作为实体对待 数据存储“学生登记表”由手工完成，有用部分转入学生档案材料中，因此这里不必作为实体。

学籍管理分E-R图草图调整后 管理 上课 班主任 班级 教室 指导 组成 住宿 拥有 学生 归档 宿舍 性别 档案材料

课程管理的E-R图 开设 选修 教室 课程 学生 成绩 教学 讲授 教师 教科书

6.3.3E-R图的集成（1） 不同设计人员进行局部视图设计，这导致各分E-R图之间存在许多不一致的地方，因此着力消除冲突是主要工作与关键所在 1.属性冲突-讨论协商解决 属性域冲突：属性值的类型、取值范围、取值集合不同 属性取值单位冲突

6.3.3E-R图的集成（2） 2.命名冲突-讨论协商解决 同名异义 异名同义 3.结构冲突 同一对象在不同应用中具有不同的抽象-例，“课程”在某一局部应用中当作实体，另一局部应用中当作属性 解决办法：使同一对象有相同的抽象，遵守前面的属性原则

6.3.3E-R图的集成（3） 3.结构冲突 同一实体在不同E-R图中所包含的属性不完全相同，或排列次序不完全相同 实体间联系在不同视图中呈现不同类型 解决办法：根据应用的语义对实体联系的类型进行综合或调整

学籍管理与课程管理E-R图的合并 存在的冲突： 1.班主任也属于教师，两图存在异名同义，统一为教师实体，属性构成为： 教师{职工号，姓名，性别，职称，优秀班主任否} 2.班主任改为教师后，教室和学生之间的联系为两类，因为“指导”包含在“教学”中，所以综合为教学联系 3.性别在学籍管理为实体，在课程管理中为属性，合并后只能作为实体，否则无法与宿舍实体发生联系 4.二者中学生实体属性组成及次序都存在差异，应将所有属性综合并重新调整次序。

6.3.3E-R图的修改与重构（1） 修改与重构-消除不必要的冗余信息,生成基本E-R图 冗余数据-可由基本数据导出 冗余的实体间联系-可由其它联系导出 冗余信息易破坏数据库的完整性，给数据维护增加困难，但有时为了提高某些应用的效率不得不以冗余信息为代价。

6.3.3E-R图的修改与重构（2） 消除冗余主要采用分析方法，例如教师工资单里的实发工资，可以推算 消除冗余还可采用规范化理论 例， 学生实体的年龄可由生日推算，属冗余数据 教室实体与班级实体的上课联系可由教室与课程间的开设联系、课程与学生间的选修联系、学生与班级之间的组成联系推导出来，属于冗余联系 学生实体中平均成绩可由选修联系中的成绩属性推算，但经常查询，为维护数据一致性，应设置触发器

整体概念结构（总E-RT图）必须验证 整体概念结构内部必须具有一致性 整体概念结构能准确反映原来的每个视图结构 整体概念结构能满足需求分析阶段所确定的所有要求

6.4 逻辑结构设计 逻辑结构设计的任务 概念结构是各种数据模型的共同基础 6.4 逻辑结构设计 逻辑结构设计的任务 概念结构是各种数据模型的共同基础 为了能够用某一DBMS实现用户需求，还必 须将概念结构进一步转化为相应的数据模型 ，这正是数据库逻辑结构设计所要完成的任 务。

6.4 逻辑结构设计 逻辑结构设计的步骤 将概念结构转化为一般的关系、网状、层次模型 6.4 逻辑结构设计 逻辑结构设计的步骤 将概念结构转化为一般的关系、网状、层次模型 将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换 对数据模型进行优化

逻辑结构设计 概念结 构设计 数据库 物理设计 转化为一般数据模型 转化为特定DBMS支持下的据模型 逻辑 模型 优化方法如规范化理论 优化模型 概念结 构设计 数据库 物理设计 基本E-R图 转换规则 特定DBMS的特点与限制 优化方法如规范化理论 逻辑 模型

6.4 逻辑结构设计 6.4.1 E-R图向关系模型的转换 6.4.2 向特定DBMS规定的模型进行转换 6.4.3 数据模型的优化 6.4 逻辑结构设计 6.4.1 E-R图向关系模型的转换 6.4.2 向特定DBMS规定的模型进行转换 6.4.3 数据模型的优化 6.4.4 设计用户子模式

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

E-R图向关系模型的转换（续） 转换内容 E-R图由实体、实体的属性和实体之间的联 系三个要素组成 关系模型的逻辑结构是一组关系模式的集合

E-R图向关系模型的转换（续） 转换原则 ⒈ 一个实体型转换为一个关系模式。 关系的属性：实体型的属性 关系的码：实体型的码 例，学生实体可以转换为如下关系模式： 　　学生（学号，姓名，出生日期，所在系， 年级，平均成绩） 性别、宿舍、班级、档案材料、教师、课程、教室、教科书等实体都分别转换为一个关系模式。

学生 学号 出生 日期 年级 所在系 平均 成绩 姓名

E-R图向关系模型的转换（续） ⒉ 一个m:n联系转换为一个关系模式。 关系的属性：与该联系相连的各实体的码以及联系本身的属性 关系的码：各实体码的组合 例，“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码： 　　选修（学号，课程号，成绩）

学生 选修 成绩 课程 学生的码为学号，课程的码为课程号，选修的属性为成绩

E-R图向关系模型的转换（续） ⒊ 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。 1) 转换为一个独立的关系模式 关系的属性：与该联系相连的各实体的码 以及联系本身的属性 关系的码：n端实体的码

E-R图向关系模型的转换（续） ⒊ 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。 合并后关系的码：不变 可以减少系统中的关系个数，一般情况下更倾向于采用这种方法

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

班级 1 组成 n 学生 学生的码为学号，班级的码为班级号，选修的属性为成绩

E-R图向关系模型的转换（续） ⒋ 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。 1) 转换为一个独立的关系模式 关系的属性：与该联系相连的各实体的码 以及联系本身的属性 关系的候选码：每个实体的码均是该关系 的候选码

E-R图向关系模型的转换（续） ⒋ 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。 2) 与某一端对应的关系模式合并 合并后关系的属性：加入对应关系的码和 联系本身的属性 合并后关系的码：不变

E-R图向关系模型的转换（续） 例，“管理”联系为1:1联系，可以有三种转换方法： （1）转换为一个独立的关系模式： 管理（职工号，班级号） 或 管理（职工号，班级号） （2）“管理”联系与班级关系模式合并，则只需在班级关系中加入教师关系的码，即职工号： 　　 班级（班级号，学生人数，职工号） （3）“管理”联系与教师关系模式合并，则只需在教师关系中加入班级关系的码，即班级号： 教师（职工号，姓名，性别，职称，班级号， 是否为优秀班主任）

E-R图向关系模型的转换（续） 注意： 从理论上讲，1:1联系可以与任意一端对应的关系模式合并。 但在一些情况下，与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。 由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。 例如，如果经常要查询某个班级的班主任姓名，则将管理联系与教师关系合并更好些。

E-R图向关系模型的转换（续） ⒌ 三个或三个以上实体间的一个多元联系转换为一个关系模式。 关系的属性：与该多元联系相连的各实体的码以及联系本身的属性 关系的码：各实体码的组合 例，“讲授”联系是一个三元联系，可以将它转换为如下关系模式，其中课程号、职工号和书号为关系的组合码： 　　讲授（课程号，职工号，书号）

E-R图向关系模型的转换（续） ⒍ 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。 教师：｛职工号，姓名，性别，职称，系主任｝

E-R图向关系模型的转换（续） ⒎ 具有相同码的关系模式可合并。 目的：减少系统中的关系个数。 合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序。

E-R图向关系模型的转换（续） 例，“拥有”关系模式： 与学生关系模式： 都以学号为码，可以将它们合并为一个关系模式： 拥有（学号，性别） 　拥有（学号，性别） 与学生关系模式： 学生（学号，姓名，出生日期，所在系，年级， 班级号，平均成绩） 都以学号为码，可以将它们合并为一个关系模式： 　学生（学号，姓名，性别，出生日期，所在系， 年级，班级号，平均成绩）

E-R图向关系模型的转换（续） 实例 按照上述七条原则，学生管理子系统中的18个实体和联系可以转换为下列关系模型： 学生（学号，姓名，性别，出生日期，所在系， 年级，班级号，平均成绩，档案号） 性别（性别，宿舍楼） 宿舍（宿舍编号，地址，性别，人数） 　班级（班级号，学生人数） 教师（职工号，姓名，性别，职称，班级号， 是否为优秀班主任）　　

E-R图向关系模型的转换（续） 教学（职工号，学号） 课程（课程号，课程名，学分，教室号） 选修（学号，课程号，成绩） 　　课程（课程号，课程名，学分，教室号） 　　选修（学号，课程号，成绩） 　　教科书（书号，书名，价钱） 　　教室（教室编号，地址，容量） 　　讲授（课程号，教师号，书号） 　　档案材料（档案号，……）

E-R图向关系模型的转换（续） 该关系模型由12个关系模式组成。 其中： 学生关系模式包含了“拥有”联系、“组成”联系、“归档”联系所对应的关系模式 教师关系模式包含了“管理”联系所对应的关系模式； 宿舍关系模式包含了“住宿”联系所对应的关系模式； 课程关系模式包含了“开设”联系所对应的关系模式。

6.4 逻辑结构设计 6.4.1 E-R图向关系模型的转换 6.4.2 向特定DBMS规定的模型进行转换 6.4.3 数据模型的优化 6.4 逻辑结构设计 6.4.1 E-R图向关系模型的转换 6.4.2 向特定DBMS规定的模型进行转换 6.4.3 数据模型的优化 6.4.4 设计用户子模式

6.4.2 向特定DBMS规定的模型进行转换 一般的数据模型还需要向特定DBMS规定的模型进行转换。 对于关系模型来说，这种转换通常都比较简单。

6.4 逻辑结构设计 6.4.1 E-R图向关系模型的转换 6.4.2 向特定DBMS规定的模型进行转换 6.4.3 数据模型的优化 6.4 逻辑结构设计 6.4.1 E-R图向关系模型的转换 6.4.2 向特定DBMS规定的模型进行转换 6.4.3 数据模型的优化 6.4.4 设计用户子模式

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

数据模型的优化（续） 优化数据模型的方法 ⒈ 确定数据依赖 按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。

数据模型的优化（续） 例，课程关系模式内部存在下列数据依赖： 课程号→课程名 课程号→学分 课程号→教室号 选修关系模式中存在下列数据依赖： 　　 课程号→课程名 　　 课程号→学分 课程号→教室号 　 选修关系模式中存在下列数据依赖： 　　 （学号，课程号）→成绩

数据模型的优化（续） 学生关系模式中存在下列数据依赖： 学号→姓名 学号→性别 学号→出生日期 学号→所在系 学号→年级 学号→班级号 　 学号→姓名 　 学号→性别 　 学号→出生日期 　 学号→所在系 学号→年级 　 学号→班级号 　 学号→平均成绩 　 学号→档案号

数据模型的优化（续） 学生关系模式的学号与选修关系模式的学号之间存在数据依赖： 学生.学号→选修.学号　　

数据模型的优化（续） ⒉ 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。

数据模型的优化（续） ⒊ 按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。 　 例如经过分析可知，课程关系模式属于BC范式。

数据模型的优化（续） ⒋ 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。

数据模型的优化（续） 并不是规范化程度越高的关系就越优。 当一个应用的查询中经常涉及到两个或多个关系模式的属性时，系统必须经常地进行联接运算，而联系运算的代价是相当高的，可以说关系模型低效的主要原因就是做联接运算引起的，因此在这种情况下，第二范式甚至第一范式也许是最好的。

数据模型的优化（续） 非BCNF的关系模式虽然从理论上分析会存在不同程度的更新异常，但如果在实际应用中对此关系模式只是查询，并不执行更新操作，则就不会产生实际影响。 对于一个具体应用来说，到底规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊才能决定。一般说来，第三范式就足够了。

数据模型的优化（续） 例：在关系模式 学生成绩单(学号,英语,数学,语文,平均成绩) 中存在下列函数依赖： 学号→英语 学号→数学 　 学号→英语 　 学号→数学 　 学号→语文 　 学号→平均成绩 (英语, 数学, 语文)→平均成绩

数据模型的优化（续） 显然有： 学号→(英语,数学,语文) 因此该关系模式中存在传递函数信赖，是2NF关系。 虽然平均成绩可以由其他属性推算出来，但如果应用中需要经常查询学生的平均成绩，为提高效率，我们仍然可保留该冗余数据，对关系模式不再做进一步分解。

数据模型的优化（续） ⒌ 按照需求分析阶段得到的各种应用对数据处理的要求，对关系模式进行必要的分解或合并，以提高数据操作的效率和存储空间的利用率 常用分解方法 水平分解 垂直分解

数据模型的优化（续） 水平分解 什么是水平分解 把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。

数据模型的优化（续） 水平分解的适用范围 1. 满足“80/20原则”的应用 1. 满足“80/20原则”的应用 80/20原则：一个大关系中，经常被使用的数据只是关系的一部分，约20% 把经常使用的数据分解出来，形成一个子关系，可以减少查询的数据量。

数据模型的优化（续） 水平分解的适用范围 2. 并发事务经常存取不相交的数据 如果关系R上具有n个事务，而且多数事务存取的数据不相交，则R可分解为少于或等于n个子关系，使每个事务存取的数据对应一个关系。

数据模型的优化（续） 水平分解 什么是水平分解 把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。 水平分解的适用范围 满足“80/20原则”的应用 并发事务经常存取不相交的数据

数据模型的优化（续） 满足“80/20原则”的应用 80/20原则：一个大关系中，经常被使用的数据只是关系的一部分，约20% 把经常使用的数据分解出来，形成一个子关系，可以减少查询的数据量。 并发事务经常存取不相交的数据 如果关系R上具有n个事务，而且多数事务存取的数据不相交，则R可分解为少于或等于n个子关系，使每个事务存取的数据对应一个关系。

数据模型的优化（续） 垂直分解 什么是垂直分解 把关系模式R的属性分解为若干子集合，形成若干子关系模式。 垂直分解的原则

数据模型的优化（续） 垂直分解的优点 可以提高某些事务的效率 垂直分解的缺点 可能使另一些事务不得不执行连接操 作，从而降低了效率。

数据模型的优化（续） 垂直分解的适用范围 取决于分解后R上的所有事务的总效率是否得到了提高。 进行垂直分解的方法 简单情况：直观分解 复杂情况：用第五章中的模式分解算法 垂直分解必须不损失关系模式的语义(保持无损连接性和保持函数依赖)。

5.4 逻辑结构设计 5.4.1 E-R图向关系模型的转换 5.4.2 向特定DBMS规定的模型进行转换 5.4.3 数据模型的优化 5.4 逻辑结构设计 5.4.1 E-R图向关系模型的转换 5.4.2 向特定DBMS规定的模型进行转换 5.4.3 数据模型的优化 5.4.4 设计用户子模式

5.4.4 设计用户子模式 定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。 5.4.4 设计用户子模式 定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。 定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：

设计用户子模式（续） (1) 使用更符合用户习惯的别名 合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。 但对于某些局部应用，由于改用了不符合用户习惯的属性名，可能会使他们感到不方便，

设计用户子模式（续） (1) 使用更符合用户习惯的别名(续) 因此在设计用户的子模式时可以重新定义某些属性名，使其与用户习惯一致。 当然，为了应用的规范化，我们也不应该一味地迁就用户。 例：负责学籍管理的用户习惯于称教师模式的职工号为教师编号。因此可以定义视图，在视图中职工号重定义为教师编号

设计用户子模式（续） (2) 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。

设计用户子模式（续） 例： 教师关系模式中包括职工号、姓名、性别、出生日期、婚姻状况、学历、学位、政治面貌、职称、职务、工资、工龄、教学效果等属性。 学籍管理应用只能查询教师的职工号、姓名、性别、职称数据； 课程管理应用只能查询教师的职工号、姓名、性别、学历、学位、职称、教学效果数据； 教师管理应用则可以查询教师的全部数据。

设计用户子模式（续） 定义两个外模式： 教师_学籍管理(职工号，姓名，性别，职称) 教师_课程管理(工号，姓名，性别，学历， 学位，职称，教学效果) 授权学籍管理应用只能访问教师_学籍管理视图 授权课程管理应用只能访问教师_课程管理视图 授权教师管理应用能访问教师表 这样就可以防止用户非法访问本来不允许他们查询的数据，保证了系统的安全性。

设计用户子模式（续） (3) 简化用户对系统的使用 如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。

逻辑结构设计小结 任务 逻辑结构设计的步骤 将概念结构转化为具体的数据模型 将概念结构转化为一般的关系、网状、层次模型 将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换 对数据模型进行优化 设计用户子模式

逻辑结构设计小结 E-R图向关系模型的转换内容 将E-R图转换为关系模型：将实体、实体的 属性和实体之间的联系转化为关系模式。

逻辑结构设计小结 E-R图向关系模型的转换原则 ⒈ 一个实体型转换为一个关系模式。 ⒉ 一个m:n联系转换为一个关系模式。 ⒊ 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。 ⒋ 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。

逻辑结构设计小结 E-R图向关系模型的转换原则 ⒌ 三个或三个以上实体间的一个多元联系转换为一个关系模式。 ⒍ 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。 ⒎ 具有相同码的关系模式可合并。

逻辑结构设计小结 优化数据模型的方法 ⒈ 确定数据依赖 ⒉ 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。 ⒉ 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。 ⒊ 确定各关系模式分别属于第几范式。 ⒋ 分析对于应用环境这些模式是否合适，确定是否要对它们进行合并或分解。 ⒌ 对关系模式进行必要的分解或合并

逻辑结构设计小结 设计用户子模式 1. 使用更符合用户习惯的别名 2. 针对不同级别的用户定义不同的外模式，以满 足系统对安全性的要求。 3. 简化用户对系统的使用