【数据库原理 • 四】数据库设计和规范化理论
前言
数据库技术是计算机科学技术中发展最快，应用最广的技术之一，它是专门研究如何科学的组织和存储数据，如何高效地获取和处理数据的技术。它已成为各行各业存储数据、管理信息、共享资源和决策支持的最先进，最常用的技术。
当前互联网+与大数据，一切都建立在数据库之上，以数据说话，首先需要聚集数据、分析数据和管理数据，数据库技术已成为各种计算机系统的核心技术。数据库相关知识也已成为每个人必须掌握的知识。
目录
- 一、关系数据库规范理论
-
- 1.1 什么是“好” 的关系模式？
- 1.2 数据依赖
-
- 1.2.1 函数依赖
- 1.2.2 函数依赖的分类
- 1.2.2.1 平凡函数依赖和非平凡函数依赖
- 1.2.2.2 完全函数依赖和部分函数依赖
- 1.2.2.3 传递函数依赖
- 1.3 码
-
- 1.3.1 候选码
- 1.3.2 主码
- 1.3.3 主属性与非主属性
- 1.4 范式
-
- 1.4.1 第一范式
- 1.4.2 第二范式
- 1.4.3 第三范式
- 1.4.3 BCNF（修正的第三范式）
- 二、数据库设计概述
-
- 2.1 数据库设计的方法
- 2.2 数据库设计的步骤
- 三、系统规划阶段
-
- 3.1 系统规划的任务
- 3.2 系统规划的成果
- 四、需求分析阶段
-
- 4.1 需求分析的任务
- 4.2 需求分析的步骤
- 4.3 需求分析的调查方法
- 4.4 数据流图
- 4.5 数据字典
- 五、概念结构设计
-
- 5.1 概念结构设计方法
- 5.2 E-R设计方法的介绍
- 5.3 局部概念结构设计
- 5.4 全局概念结构设计
- 六、逻辑结构设计
-
- 6.1 逻辑结构设计的步骤
- 6.2 E-R图向关系模型的转换原则
- 6.3 数据模型的优化
- 七、物理结构设计
-
- 7.1 确定物理结构
- 7.2 评价物理结构
- 八、数据库的实施
- 九、数据库的运行和维护
一、关系数据库规范理论
1.1 什么是“好” 的关系模式？
某学校要建立一个数据库以描述学生选修课程的情况。由现实世界的已知事实可以得到如下对应关系：每一名学生可以选修多门课程，每一门课程可以被多名学生所选修；每一名学生选修一门课程都会有一个成绩。
针对上述情况可能设计出以下两种关系模式
- 只产生一个关系模式
学生选课关系模式（学号，姓名，性别，年龄，系别，课程号，课程名，教师名，学分，成绩）
- 产生三个关系模式
学生关系模式（学号，姓名，性别，年龄，系别）
课程关系模式（课程号，课程名，教师名，学分）
选课关系模式（学号，课程号，成绩）
比较分析这两种关系模式，发现第一种设计方法可能带来如下问题：
- 数据冗余
- 更新异常（Update Anomalies）
- 插入异常（Insertion Anomalies）
- 删除异常（Deletion Anomalies）
出现的原因： 由存在于模式中的某些数据依赖引起的。我们可以用规范化理论改造关系模式来消除其中不合适的数据依赖
1.2 数据依赖
数据依赖是一个关系内部属性与属性之间的一种约束关系，这种约束关系是通过属性间值的相等与否体现出来的数据间的相互关系。数据依赖有多种类型，常用的数据依赖有函数依赖和多值依赖，其中函数依赖是最重要也是最基本的一种数据依赖
1.2.1 函数依赖
函数依赖普遍地存在于现实生活中，它反映属性或属性组合之间相互依存、相互制约的关系
什么是函数依赖？
设R(U)是属性集U上的关系模式，X与Y是U的子集，r是R(U)的任意一个可能的关系（即一个二维表）。如果对于r中的任意两个元组（即两个记录，或两行数据）t和s，由t[X]=s[X]导致t[Y]=s[Y],则称X函数决定Y，或称Y函数依赖于X，记作X→Y。
函数依赖的相关术语和记号如下：
- 若X→Y，则称X为决定因素。
- 若X→Y,Y→X，则记作X←→Y。
也就是说只要在X上取值相等，则在Y上的取值一定是相等的
1.2.2 函数依赖的分类
关系数据库中函数依赖主要有以下几类：
平凡函数依赖和非平凡函数依赖
完全函数依赖和部分函数依赖
传递函数依赖
1.2.2.1 平凡函数依赖和非平凡函数依赖
设R(U)是属性集U上的关系模式，若对于任何X、Y∈U，有X→Y且Y∉X，则称X→Y是非平凡的函数依赖。反之，如果Y包含于X，则称X→Y是平凡的函数依赖。
例如
在学生关系模式（学号，姓名，年龄，性别，所在系别）中，学号→性别，（学号，姓名）→年龄，均为非平凡函数依赖。（学号，姓名）→姓名，为平凡函数依赖。
1.2.2.2 完全函数依赖和部分函数依赖
设R(U)是属性集U上的关系模式，如果X→Y，并且对于X的任何一个真子集X′，都不存在X′→Y，则称X→Y是一个完全函数依赖，即Y完全函数依赖于X，用F表示。
如果存在X′→Y成立，则称X→Y是一个部分函数依赖，即Y部分函数依赖于X，用P表示。
例如
在学生关系模式（学号，姓名，年龄，性别，所在系别）中：
（学号，姓名）→年龄，为部分函数依赖。因为（学号，姓名）属性组合中存在真子集学号，使得“学号→年龄”也成立，所以它是部分函数依赖。
学号→年龄，为完全函数依赖。
简答理解就是说 属性组 X 的所有属性一起（即完全）才能决定属性 Y，去掉任何一个属性都不行。相反的，部分函数依赖就是说 属性组 X 中的 部分属性就可以决定 Y ，用不着全部。
1.2.2.3 传递函数依赖
设R(U)是属性集U上的关系模式，如果X→Y，Y→Z，Y∉X，Z∉X，Z∉Y并且不存在Y→X，则称X→Z是一个传递函数依赖，即Z传递函数依赖于X。
例如
在职工关系模式（职工编号，姓名，所在车间，车间主任）中，职工编号→所在车间，所在车间→车间主任，并且不存在所在车间→职工编号，则车间主任传递函数依赖于职工编号。
注意上述定义中的条件不存在Y→X。如果不加上这一限制，当X→Y时允许Y→X，则X←→Y。而在X←→Y的条件下，Y→Z就等于X→Z。这样X就直接函数决定Z，而不是通过Y传递决定Z了，即非传递函数依赖。
1.3 码
1.3.1 候选码
设K为R(U) 中的属性或属性组合。若K完全依赖于U，则K称为R的一个候选码(CandidateKey)
对于关系 R(U) 中的属性（组）K，如果 U 完全函数依赖于 K，即 K 中的所有属性一起才能决定 U，则称 K 为 R(U) 的候选键
1.3.2 主码
若关系模式R有多个候选码，则选定其中的一个做为主码(Primary key)。
1.3.3 主属性与非主属性
包含在任何一个候选码中的属性 ，称为主属性 （Prime attribute）
不包含在任何码中的属性称为非主属性（Nonprime attribute）或非码属性（Non-key attribute）
例如
- S(Sno, Sdept, Sage)，单个属性Sno是码
- SC(Sno, Cno, Grade)中，(Sno, Cno)是码
1.4 范式
在关系数据库中，关系模式设计的好坏取决于它的函数依赖是否满足特定的要求。满足特定要求的模式称为范式，满足不同程度要求的为不同范式。
一般地，关系模式R为第几范式就可以写成R∈xNF。对于各种范式之间的联系有5NF⊂ 4NF⊂BCNF ⊂3NF⊂2NF⊂1NF成立。
通过关系模式分解，可以将一个低一级范式的关系模式转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化
1.4.1 第一范式
如果关系模式R中的每一个属性都是不可分解的，则称R属于第一范 式，记作R∈1NF。
例如
设关系模式R（系别名称，高级职称人数）表示某学校系别的基本信息，假设系别信息状况如表
可以看出，“高级职称人数”属性是可以分解的，所以R不满足1NF。解决问题的办法是：将“高级职称人数”属性拆开，形成关系模式R1（系别名称、教授人数、副教授人数）。
显然，此时关系模式R1中的每一个属性列都是不可再分的，所以R1∈1NF
1.4.2 第二范式
如果关系模式R∈1NF，且每一个非主属性都完全函数依赖于候选码，则称R属于第二范式，记作R∈2NF。
例如
设关系模式R（仓库号，设备号，数量，地点）表示仓库设备的存储情况。候选码是（仓库号，设备号）属性组合，由于关系模式R中的每一个属性都不可再分，所以R∈1NF。因为非主属性“数量”完全函数依赖于候选码。非主属性“地点”部分函数依赖于候选码。即有（仓库号，设备号）→地点，仓库号→地点，所以R不满足2NF。
关系模式R中存在异常，比如某一个仓库只有一种设备，当这种设备被移走后，在删除此设备信息的同时将这个仓库的信息也删除了。
解决问题的办法是：用投影分解把关系模式R分解为两个关系模式。将部分函数依赖关系的决定方属性和非主属性从关系模式中提出，单独构成一个关系模式；将余下属性加上码（仍要保留部分函数依赖的决定方属性）构成另一关系模式。
按照上述方法分解，将关系模式R分解为R1(仓库号,设备号，数量)和R2(仓库号，地点)两个关系模式。此时，R1和R2均属于第二范式
1.4.3 第三范式
如果关系模式R∈2NF，且每一个非主属性都不传递函数依赖于候选码，则称R属于第三范式，记作R∈3NF。
例如
设关系模式R（仓库号，仓库面积，所在城市，所在省）表示不同仓库在各省市分布情况。候选码是仓库号，由于关系模式R中的每一个属性都不可再分，所以R∈1NF。又因为R中每一个非主属性都完全函数依赖于候选码，所以R∈2NF。又因为函数依赖有仓库号→所在城市，所在城市→所在省，所以仓库号→所在省，R中存在传递函数依赖，所以R不满足3NF。
关系模式R中存在异常，比如要在辽宁省大连市设立一个仓库，此时想先存入有关所在城市的信息，但由于没有仓库号，主码为空，则插入是失败的。
解决问题的办法是：用投影分解把关系模式R分解为两个关系模式，将传递函数依赖的属性分解出来，消除传递函数依赖。
按照上述方法分解，将关系模式R分解为R1（仓库号，仓库面积，所在城市）和R2（所在城市，所在省）两个关系模式。此时，R1和R2均属于第三范式。
1.4.3 BCNF（修正的第三范式）
如果关系模式R∈3NF，且没有一个属性部分函数依赖或传递函数依赖于候选码，则称R属于修正的第三范式，记作R∈BCNF。
规范化的基本思想是，逐步消除数据依赖中不合理的部分，使每一个关系模式更趋于完美。但并不是范式越高越好，范式越高，模式分解的越多，我们在进行数据查询的时候往往要进行许多张表的连接，系统开销较大，查询效率较低。所以，在进行关系模式规范化的过程中，关系模式一般分解到3NF就认为是比较好的了。
在银行管理系统的数据库中，有一关系模式为R（BNO，SSNO，BNAME，ADDRESS，CITY，SNAME，SEX，AGE，ACCOUNT），其中属性分别表示银行编号，身份证号，银行名称，银行所在地点，银行所在城市，顾客姓名，性别，年龄，账户号。我们写出该关系模式的主码，并对其进行规范化，以达到3NF
该关系模式R的主码为（BNO，SSNO）。由于关系模式R中的每个分量都是不可再分的数据项，所以R满足1NF。关系模式R中存在以下函数依赖：
（BNO，SSNO）→BNAME， BNO→BNAME，
（BNO，SSNO）→ADDRESS， BNO→ADDRESS，
（BNO，SSNO）→CITY， ADDRESS→CITY，
（BNO，SSNO）→ACCOUNT， BNO→CITY，
（BNO，SSNO）→SNAME， SSNO→SNAME，
（BNO，SSNO）→SEX， SSNO→SEX，
（BNO，SSNO）→AGE， SSNO→AGE，
-
首先，关系模式R满足1NF，但存在部分函数依赖，所以，R不满足2NF,将其分解为：
R1（BNO，SSNO，ACCOUNT）∈2NF；
R2（BNO，BNAME，ADDRESS，CITY）∈2NF；
R3（SSNO，SNAME，SEX，AGE）∈2NF； -
其次，关系模式R1、R3均已满足第三范式，但关系模式R2存在传递函数依赖，R2不满足第三范式，将R2分解为：
R4（BNO，BNAME，ADDRESS）∈3NF；
R5（ADDRESS，CITY）∈3NF； -
最后，R1、R3、R4、R5满足第三范式，总结为：
R1（BNO，SSNO，ACCOUNT）；
R3（SSNO，SNAME，SEX，AGE）；
R4（BNO，BNAME，ADDRESS）；
R5（ADDRESS，CITY）。
二、数据库设计概述
2.1 数据库设计的方法
早期数据库设计主要采用手工与经验相结合的方法。设计的质量往往与设计人员的经验与水平有直接的关系，设计质量难以保证。人们通过运用软件工程的思想和方法，提出了各种数据库设计方法，以及各种设计准则和规程，这些都属于规范设计方法。
例如
- 关系模式的设计方法
- 新奥尔良（New Orleans）方法
- 基于E-R模型的数据库设计方法
- 3NF（第三范式）的设计方法
- 基于抽象语法规范的设计方法
- 计算机辅助数据库设计方法
2.2 数据库设计的步骤
从数据库应用系统设计和开发的全过程来考虑，一般将数据库设计的步骤分为七个阶段：
- 系统规划阶段
- 需求分析阶段
- 概念结构设计阶段
- 逻辑结构设计阶段
- 物理结构设计阶段
- 实施阶段
- 运行和维护阶段
三、系统规划阶段
3.1 系统规划的任务
系统规划阶段的主要任务就是进行系统的必要性和可行性分析。包括明确应用系统的基本功能，划分数据库支持的范围；规划人力资源调配；拟定设备配置方案；选择合适的操作系统、DBMS和其他软件；设备配置方案要在使用要求、系统性能、购置成本和维护代价各方面综合权衡；对系统的开发、运行、维护的成本作出估算；预测系统效益的期望值；拟定开发进度计划，还要对现行工作模式如何向新系统过渡作出具体安排。
3.2 系统规划的成果
规划阶段的工作成果是写出详尽的可行性分析报告和数据库应用系统规划书。内容应包括：系统的定位及其功能、数据资源及数据处理能力、人力资源调配、设备配置方案、开发成本估算、开发进度计划等。
可行性分析报告和数据库应用系统规划书经审定立项后，成为后续开发工作的总纲
四、需求分析阶段
4.1 需求分析的任务
需求分析是整个数据库设计过程中最重要的步骤之一，是后续各阶段的基础。需求分析的主要任务是通过详细调查所要处理的对象，包括某个组织、某个部门、某个企业的业务管理等，充分了解原手工或原计算机系统的工作状况以及工作流程，明确用户的各种需求，生成业务流程图和数据流图，然后在此基础上确定新系统的功能，并撰写系统说明书。新系统不能只按当前应用需求来设计数据库，必须充分考虑今后可能的扩充和改变。
4.2 需求分析的步骤
调查、收集和分析用户要求的具体步骤如下：
1．调查组织机构情况
调查这个组织由哪些部门组成，各部门担当的职责是什么。
2．调查各部门的业务活动情况
调查各部门所需输入和使用的数据，如何加工处理这些数据，输出什么信息，输出到哪个部门，输出结果的格式等。
3．协助用户明确对新系统的各种要求
进一步明确用户对数据管理中的信息要求、处理要求、安全性与完整性要求。
4．确定新系统的边界
确定哪些功能由计算机完成或将来准备让计算机完成，哪些功能由人工完成。由计算机完成的功能就是新系统应该实现的功能。
4.3 需求分析的调查方法
根据不同的问题和条件，调查方法也可以不同。常用的调查方法有以下几种。
1．跟班作业
通过亲身参加业务工作来了解业务活动的情况，这种方法可以比较准确地了解用户的需求，但比较耗费时间。
2．开调查会
通过与用户座谈的方式来了解业务活动情况及用户需求。
3．请专人介绍
通过邀请熟悉业务的专业人士来了解业务活动情况。
4．询问
对调查中的某些问题，可以找专人询问。
5．设计调查表请用户填写
如果调查表设计合理，这种方法易于用户接受并且会很有效。
6．查阅记录
查阅与原系统有关的数据记录，包括原始的单据、报表等。
当需求分析完成后，最终产生阶段性的成果：系统需求说明书，包括数据流图、数据字典、数据表格、系统功能结构图和必要的说明。
4.4 数据流图
数据流图(Data Flow Diagram, 简记为DFD) 是用图形方式来表达系统的逻辑功能，以及数据在系统内部的逻辑流向和逻辑变换过程。任何一个系统都可以抽象为数据流图形式。
数据流图的基本符号
→：箭头，表示数据流；
□ ：方框，表示数据的源点或终点；
○ ：圆或椭圆，表示加工或处理；
＝：双杠，表示数据存储。
（1）数据流： 是数据在系统内传播的路径，因此由一组成分固定的数据组成。例如订票单由旅客姓名、年龄、单位、身份证号、日期、目的地等数据项组成。由于数据流是流动中的数据，所以必须有流向，除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。
（2）数据源点或终点： 代表系统之外的实体，可以是人、物或其他软件系统。
（3）对数据的加工（处理）： 是对数据进行处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。
（4）数据存储： 表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等。
在画数据流图时须注意的原则
（1）一个加工的输出数据流不应与输入数据流同名，即使它们的组成成分相同。
（2）保持数据守恒，即一个加工的所有输出数据流中的数据必须能从该加工的输入数据流中直接获得。
（3）每个加工必须既有输入数据流，又有输出数据流。
（4）所有的数据流必须以一个加工开始，或以一个加工结束。
数据流图的实例
这是一个飞机机票预订系统的数据流图，它反映的功能是：旅行社把预订机票的旅客信息 (姓名、年龄、性别、身份证号码、旅行时间、目的地等)输入机票预订系统。系统为旅客安排航班，打印出取票通知单(附有应交的账款)。旅客在飞机起飞的前一天凭取票通知单交款取票，系统检验无误，输出机票给旅客。
4.5 数据字典
数据字典是系统中各类数据描述的集合，是对数据流图中包含的所有元素的定义的集合。
数据存放于物理数据库中，由数据库管理系统进行管理。数据字典有助于对这些数据进一步管理和控制，为设计人员和数据库管理员在数据库设计、实现和运行阶段控制有关数据提供一定的依据。
数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分。
（1）数据项是数据的最小组成单位，是不可再分的数据单位。包括项名、含义说明、别名、数据类型、长度、取值范围、与其他数据项的逻辑关系等。
（2）数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。包括数据结构名、说明、组成等。
（3）数据流是数据结构在系统内传输的路径。包括数据流名、说明、数据流来源、数据流去向、组成、平均流量、高峰期流量等。
（4）数据存储说明数据流中需要存储的数据，包括数据存储名、说明、流入数据流、流出数据流、组成、数据量、存取频度、存取方式等。
（5）处理过程的具体处理逻辑通常用判定表或判定树来描述。包括处理过程名、说明、输入数据流、输出数据流、处理简要说明等。
五、概念结构设计
5.1 概念结构设计方法
概念结构的设计方法通常有以下四种。
自顶向下： 先定义全局概念结构E-R模型的框架，再逐步细化。
自底向上： 先定义各局部应用的概念结构E-R模型，然后将它们集成，得到全局概念结构E-R模型。
逐步扩张： 先定义最重要的核心概念E-R模型，然后向外扩充，以滚雪球的方式逐步生成其他概念结构E-R模型，直至总体概念结构。
混合策略： 该方法采用自顶向下和自底向上相结合的方法，先自顶向下定义全局框架，再以它为骨架集成自底向上方法中设计的各个局部概念结构。
5.2 E-R设计方法的介绍
描述概念模型的有力工具是E-R模型。有关E-R模型的基本概念已经在第一章介绍过了，下面将用E-R模型来描述概念结构。
E-R方法是“实体—联系方法”（Entity-Relationship Approach）的简称。它是描述现实世界概念结构模型的有效方法。用E-R方法建立的概念结构模型称为E-R模型，或称为E-R图。
E-R图的三要素是实体、属性和联系
（1）实体： 用矩形框表示，框内标注实体名称。
（2）属性： 用椭圆形框表示，框内标注属性名称。
（3）联系： 用菱形框表示，框内标注实体之间的关系。有1:1，1:n和m:n三种联系类型。例如系主任领导系，学生选修课程，教师讲授课程，工人生产产品，这里“领导”、“选修”、“讲授”、“生产”表示实体之间的联系，可以作为联系名称。联系用菱形框表示，框内标注联系名称。
E-R图的表示
在E-R图的描述中，用矩形表示实体，用椭圆表示属性，用菱形表示联系。在各框图内标注它们的名称，它们之间用无向线连接，表示联系时需在线上标明属于哪种类型的联系。
5.3 局部概念结构设计
概念结构设计首先要根据需求分析得到的结果（数据流图、数据字典等）对现实世界进行抽象，设计各个局部E-R模型。在系统需求分析阶段，最后得到了多层数据流图、数据字典和系统分析报告。建立局部E-R模型，就是根据系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，作为设计局部E-R图的出发点，让这组图中每一部分对应一个局部应用。在前面选好的某一层次的数据流图中，每个局部应用都对应了一组数据流图，局部应用所涉及的数据存储在数据字典中。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，确定每个局部应用包含哪些实体，这些实体又包含哪些属性，以及实体之间的联系及其联系类型。
以工厂管理为例，描述局部E-R图的设计。从技术科获知，每种产品由多种零件组成，每种零件可用在不同的产品上，每种产品由一定数量的零件组成。从供应科获知，每种零件使用多种材料制成，每种材料也可应用在不同的零件上，每种零件在使用材料上有一个使用量；每个仓库可以存放多种材料，每种材料只能放在一个仓库里，每个仓库存放材料有一个库存量。
根据E-R图的建立过程：
第一步：确定实体类型
产品、零件、材料和仓库四个实体类型。
第二步：确定联系类型
产品和零件之间是m:n组成的联系，零件和材料之间是m:n使用的 联系，仓库和材料之间是1:m存放的联系。
第三步：确定实体类型和联系类型的属性。
在技术科中，产品实体的属性有：产品号、产品名、性能参数等。
在技术科中，零件实体的属性有：零件号、零件名、价格等。
在供应科中，零件实体的属性有：零件号、规格等。
在供应科中，材料实体的属性有：材料号、价格等。
在供应科中，仓库实体的属性有：仓库号、仓库名、地址等。
产品和零件之间m:n组成的联系属性是零件数，零件和材料之间m:n使用的联系属性是使用量，仓库和材料之间1:m存放的联系属性是库存量。
第四步，根据实体类型和联系类型画出局部E-R图
第五步，用下划线标注出实体的码。
5.4 全局概念结构设计
全局概念结构设计的实质是把局部概念结构设计中所有的局部概念模型统一起来，形成一个完整的系统模型。
全局E-R模型的建立过程如下：
1．合并
将局部概念模型整理合并成全局概念模型。
（1）先找出具有相同实体的两个E-R图。
（2）以该相同实体为基准进行合并。
（3）如果还有相同实体的E-R图，再次合并。
（4）这样一直下去，直到所有的具有相同实体的局部E-R图都被合并，从而得到全局的E-R图。
2．消除冲突
解决各种局部E-R图之间的冲突问题，生成初步E-R图。
（1）属性冲突
属性值的类型、取值范围及取值单位不一致造成的冲突。如：生日和年龄，厘米和米，学生编号的方式等。
（2）结构冲突
如在某局部E-R图中系主任是属性，而在另一个局部E-R图中系主任是实体等。
（3）命名（实体、属性、联系）冲突
同名异义：教室和宿舍均称为房间；
异名同义：如教材和课本。
将技术科和供应科的两个局部E-R图合并成全局E-R图
一个好的全局E-R模型除了能准确、全面地反映用户功能外，还应满足下列条件：实体类型的个数尽可能少、实体类型所含属性的个数尽可能少、实体间联系的冗余最小。模型优化的目的是消除不必要的冗余，使其保持最小冗余度。
优化全局E-R模型的几个原则：
（1）实体类型的合并
（2）冗余属性的消除，如生日和年龄。
（3）冗余联系的消除
将下列所示的两个局部E-R图合并成一个全局E-R图，并进行优化。
局部E-R模型设计完成之后，根据全局E-R模型的建立步骤，将上述两个局部E-R模型合并成全局E-R模型
上例中对全局E-R模型进行优化，消除冗余，得到优化后的概念模型
如一个图书借阅信息管理系统有如下信息：
每一个借书人可以借阅多本图书，每一本图书可以被多个借书人借阅；借书人每借阅一本图书都有一个借书日期和还书日期；每一个出版社可以出版多本图书，每一本图书只能在一个出版社出版。其中：
借书人的属性有：借书证号、姓名、单位、电话；
图书的属性有：图书编号、书名、位置；
出版社的属性有：出版社名、地址、邮编、电话。
我们根据需求画出E-R图，并在E-R图中注明实体的属性、联系的类型以及实体的码。
六、逻辑结构设计
6.1 逻辑结构设计的步骤
数据库逻辑结构的设计过程
6.2 E-R图向关系模型的转换原则
关系模型的逻辑结构是一组关系模式的集合，而E-R图则是由实体、实体的属性和实体之间的联系三个要素组成的。所以将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为相应的关系模式，下面具体介绍转换的规则。
（1）一个实体类型转换为一个关系模式： 实体的属性就是关系的属性，实体的码就是关系的码。
学生实体和课程实体分别转换成如下两个关系模式：
学生关系模式(学号，姓名，年龄，性别)，学号为关系模式的主码。
课程关系模式(课程号，课程名，学分)，课程号为关系模式的主码。
（2）一个m:n联系转换为一个独立的关系模式： 与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
将上述E-R模型转换为相应的关系模式，先将学生和课程两个实体转换为关系模式，再将这两个实体间的联系转换为关系模式，如下：
学生关系模式(学号，姓名，年龄，性别)，学号为关系模式的主码。
课程关系模式(课程号，课程名，学分)，课程号为关系模式的主码。
选课关系模式（学号，课程号，成绩），学号和课程号的组合码为关系模式的主码。
（3）一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并： 如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而该关系的码为n端实体的码。如果与n端对应的关系模式合并，则只需要将联系本身的属性和1端实体的码加入到n端对应的关系模式中即可。
将上述E-R模型转换为相应的关系模式，先将班导师和学生两个实体转换为关系模式，再将这两个实体间的联系转换为关系模式，如下：
方法一：产生独立的关系模式
学生关系模式(学号，姓名，年龄，性别)，学号为关系模式的主码。
班导师关系模式(职工号，姓名，性别，电话)，职工号为关系模式的主码。
指导关系模式（学号，职工号），学号为关系模式的主码。
方法二：与n端对应的关系模式合并
学生关系模式(学号，姓名，年龄，性别，职工号)，学号为关系模式的主码。
班导师关系模式(职工号，姓名，性别，电话)，职工号为关系模式的主码。
（4）一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并： 如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
将上述E-R模型转换为相应的关系模式，先将班级和班长两个实体转换为关系模式，再将这两个实体间的联系转换为关系模式，如下：
方法一：产生独立的关系模式
班级关系模式(班级号，人数)，班级号为关系模式的主码。
班长关系模式(学号，姓名，性别，年龄)，学号为关系模式的主码。
任职关系模式（班级号，学号），班级号为关系模式的主码，也可以选学号作为关系模式的主码。
方法二：与任意一端对应的关系模式合并
班级关系模式(班级号，人数)，班级号为关系模式的主码。
班长关系模式(学号，姓名，性别，年龄，班级号)，学号为关系模式的主码。
或者
班级关系模式(班级号，人数，学号)，班级号为关系模式的主码。
班长关系模式(学号，姓名，性别，年龄)，学号为关系模式的主码。
（5）三个或三个以上实体间的一个多元联系转换为一个关系模式： 与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
（6）同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。
（7）具有相同码的关系模式可合并
例如
每个工厂生产多种产品，且每种产品可以在多个工厂中生产，每个工厂按照固定的计划数量生产产品；每个工厂聘用多名职工，且每个职工只能在一个工厂工作，工厂聘用职工有聘用期和工资。工厂的属性有工厂编号、厂名、地址，产品的属性有产品编号、产品名、规格，职工的属性有职工号、姓名。
（1）根据需求画出E-R图，并在E-R图中注明实体的属性、联系的类型以及实体的码。
（2）将E-R图转换成关系模式，并用下画线标出每个关系模式的主码。
工厂（工厂编号 ，厂名，地址）
产品（产品编号 ，产品名，规格）
职工（职工号 ，姓名，工厂编号，工资，聘用期）
生产（工厂编号 ，产品编号 ，计划数量）=
6.3 数据模型的优化
数据模型的优化方法为：
（1）确定数据依赖。
（2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
（3）按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
（4）按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。
（5）对关系模式进行必要的分解。
七、物理结构设计
数据库物理设计阶段的任务是根据具体计算机系统(DBMS和硬件等)的特点，为给定的数据库模型确定合理的存储结构和存取方法。所谓的“合理”主要有两个含义：一个是要使设计出的物理数据库占用较少的存储空间，另一个对数据库的操作具有尽可能高的速度。
数据库的物理设计通常分为两步：
首先，确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构。
其次，对物理结构进行评价，评价的内容是系统的时间和空间效率。
7.1 确定物理结构
1．确定数据的存储结构
确定数据库存储结构时要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，例如消除一切冗余数据虽然能够节约存储空间，但往往会导致检索代价的增加，因此必须进行权衡，选择一个折中方案。
2．设计数据的存取路径
在关系数据库中，选择存取路径主要是指确定如何建立索引。例如，应把哪些域作为次码建立次索引，建立单码索引还是组合索引，建立多少个为合适，是否建立聚集索引等。
3．确定数据的存放位置
为了提高系统性能，数据应该根据应用情况将易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。
4．确定系统配置
DBMS产品一般都提供了一些存储分配参数，供设计人员和DBA对数据库进行物理优化。初始情况下，系统都为这些变量赋予了合理的缺省值。但是这些值不一定适合每一种应用环境，在进行物理设计时，需要重新对这些变量赋值以改善系统的性能。
7.2 评价物理结构
数据库物理设计过程中需要对时间效率、空间效率、维护代价和各 种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
评价物理数据库的方法完全依赖于所选用的DBMS，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修改设计。
八、数据库的实施
数据库的实施主要包括以下工作：用数据定义语言（DDL）定义数据库结构，组织数据入库，编制与调试应用程序，数据库试运行四个部分。
1．定义数据库结构
2．数据装载
3．编制与调试应用程序
4．数据库试运行**
九、数据库的运行和维护
在数据库运行阶段，对数据库经常性的维护工作主要是由DBA完成的，包括：
1．数据库的转储和恢复
2．数据库的安全性、完整性控制
3．数据库性能的监督、分析和改进
4．数据库的重组织和重构造