数据库系统（3）

Valois

已于 2023-03-24 20:16:20 修改

阅读量957

点赞数 2

文章标签：数据库 sql

于 2023-02-12 11:04:01 首次发布

本文链接：https://blog.csdn.net/qq_43783708/article/details/128992760

版权

数据库系统原理专栏收录该内容

4 篇文章 0 订阅

订阅专栏

数据库完整性

实体完整性

定义实体完整性

定义：在关系模型中的实体完整性定义在CREATE TABLE 中用PRIMARY KEY定义。单属性码可以用列级定义、表级定义；多属性码只能表级定义。
示例：

单属性码：										多属性码：
CREATE TEABLE Student							CREATE TABLE SC
(Sno CHAR(9) PRIMARY KEY, 列级定义				(Sno CHAR(9) NOT NULL,
Sname CHAR(20) NOT NULL);						Cno CHAR(4) NOT NULL,
												Grade SMALLINT
												PRIMARY KEY(Sno,Cno); 只能表级定义

实体完整性检查和违约处理

当更新或插入一条元组时，需要检查主码值是否唯一，如果不唯一则拒绝插入或更新。
检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改。

参照完整性

定义参照完整性

定义：使用CREATE TABLE语句中的FOREIGN KEY短语定义哪些列为外码，用REFERENCES短语指明这些外码所参照的表的主码。
示例：

CREATE TABLE SC
(Sno CHAR(9) NOT NULL,
Cno CHAR (4)NOT NULL,
Grade SMALLINT,
PRIMARY KEY(Sno,Cno),                          在表级定义实体完整性
FOREIGN KEY (Sno) REFERENCES Student(Sno),		在表级定义参照完整性
FOREIGN KEY (Cno) REFERENCES Course(Con)		在表级定义参照完整性
);

参照完整性检查和违约处理

规则：

用户自定义完整性

定义：针对某一具体应用的数据必须满足的语义要求。

属性上的约束

定义：在CRETE TABLE时，对属性值限制，包括列值非空、列值唯一、用CHECK短语指定列值应该满足的条件
属性上的约束条件的检查和违约处理：违约时，拒绝执行

元组上的约束

定义：在CRETE TABLE时，使用CHECK短语定义元组上的约束条件。
元组上的约束条件的检查和违约处理：当插入或修改时，约束条件不满足则拒绝执行。
示例：

当学生的性别是男时，其名字不能以Ms.开头：
CREATE TABLE Student
(Sno CHAR(9),
Sname CHAR(8) NOT NULL,
Ssex CHAR(2),
Sage SMALLINT,
Sdept CHAR(2),
PRIMARY KEY (Sno),
CHECK (Ssex = '女' OR Sname NOT LIKE 'MS.%')
); 
性别检查：当为女性时，CHECK为真；当为男性时，当且仅当名字不为“MS.”开头时为真。

断言

作用：在SQL中可以使用树定义语言中的CREATE ASSERTION 语句，通过申明性断言来指定更一般性的约束。
注意：断言创建以后，任何对断言中所涉及关系的操作都会触发DBMS对断言的检查，任何使断言不为真值的操作都会被拒绝执行。
一般格式： CREATE ASSERTION <断言名> <CHECK子句>;每个断言都被赋予一个名字。
删除断言：DROP ASSERTION <断言名>;

限制数据库课程最所60名学生选修：
CREATE ASSERTION ASSE_SC_DB_NUM
	CHECK (60>=(SELECT count(*) 
				FROM Course,SC
				WHERE SC.CNO = COURSE.CNO AND COURSE.CNAME='数据库')
		);
每当在SC表中插入一条元组时，ASSE_SC_DB_NUM断言会被触发检查。
如果选课人数已经超过60人，则CHECK返回值为“假”，对SC表的操作拒绝执行。

触发器

引入：触发器（trigger）是用户定义在关系表上的一类由事件驱动的特殊过程。一旦定义，触发器将被保存在数据库服务器中。任何用户对表的增、删、改操作均有服务器自动激活相应的触发器，在DBMS核心层进行集中的完整性控制。

定义触发器

触发器：又叫事件-条件-动作规则。当特定的系统事件发生时，对规则的条件进行检查，如果条件成立则执行规则中的动作，否则不执行该动作。动作体可以很复杂，通常是一段SQL存储过程。
一般格式：
语法说明：
①只有基本表的拥有者才能在表上创建触发器，并且一张表上触发器的数量有限制。
②同一模式下，触发器名必须是唯一的，并且触发器名和表名在同一模式下。
③触发器只能定义在基本表上。当基本表的数据发生变化时，将激活定义在该表上相应触发事件的触发器。
④触发事件可以是INSERT、DELETE、UPDATE，也可以是几个事件的集合。AFTER/BEFORE指明了触发器的触发时间。
⑤按照触发动作的间隔尺寸可以分为行级触发器和语句级触发器
⑥触发器被激活时，只有当触发器条件为真时触发动作体才执行。如果省略WHEN条件，则触发动作体立即执行。
⑦可以是一个SQL块，也可以是对已创建存储过程的调用。

激活触发器

触发器：是由触发事件激活，并由数据库服务器自动执行的，同一个表上可能会有多个触发器，它们之间遵循一定的执行顺序。
执行顺序：
- 执行该表上的BEFORE触发器
- 激活触发器的SQL语句
- 执行该表上的AFTER触发器
- 对于同一个表上的多个BEFORE(AFTER)触发器，则按照创建时间的先后顺序执行。

当对表SC的Grade属性进行修改时，若分数增加了10%，则将此次操作记录到另一个表SC_U(Sno,Cno,Oldgrade,Newgrade)中：
CREATE TRIGGER SC_T  /*触发器的名字*/ 
AFTER UPDATE OF Grade ON SC 
			/*表示当对SC的Grade属性修改完后再触发下面的规则*/
REFERENCING
	OLDROW AS OldTuple
	NEWROW AS NewTuple
FOR EACH ROW	/*行级触发器，即每执行一次Grade的更新，下面的规则将被执行一次*/
WHEN (Newtuple.Grade >1.1 * OldTuple.Grade)				/*触发条件，只有该条件为真时才执行下面的INSERT操作*/
	INSERT INTO	SC_U (Sno,Sname,OldGrade,NewGrade)
	VALUES(OldTuple.Sno,OldTuple.Con,OldTuple.Grade,NewTuple.Grade)

删除触发器

一般格式：DROP TRIGGER <触发器> ON <表名> ;
注意：触发器必须由具有权限的用户删除

关系数据理论

引入

问题的提出：由于关系模型有严格的数学理论基础，并且可以向别的数据模型转换。因此，人们以关系模型为背景来研究如何让构造合适的数据模式（逻辑结构的问题）。
关系模型的形式化定义：R(U,D,DOM,F) 五元组

R为关系名，U为一组属性，D为属性组U中的属性来自的域，DOM为属性到域的映射，F为属性组U上的一组数据依赖。由于D、DOM与模式设计关系不大，所以在本章中看作一个 R<U,F>三元组，当且仅当U中的一个关系r满足F时，r称为关系模式R<U,F>的一个关系。
数据依赖：指一个关系内部属性与属性之间的一种约束关系，通过属性间值的相等与否体现出来的数据间的联系，是对现实世界属性间相互联系的抽象，包括函数依赖、多值依赖。

例如：建立一个描述学校教务的数据库，该数据库涉及的对象包括学生的学号、所在系、系主任姓名、课程号、成绩。
假设用一个单一的关系模式Student来表示，则该关系模式的属性集合为U = {Sno,Sdept,Sname,Cno,Grade}
现实世界的已知事实告诉我们：
①一个系有若干学生，但一个学生只属于一个系
②一个系只有一名负责人
③一个学生可以选修多门课程，每门课程有若干学生选修。
④每个学生学习每一门课程有一个成绩。
于是得到属性组U上的一组函数依赖F = {Sno->Sdept,Sdept->Mname,(Sno,Cno)->Grade}
如果仅考虑函数依赖这一种数据依赖，可以得到一个描述学生的关系模式Student<U,F>。
但是，该关系模式存在以下问题：
①数据冗余：每个系主任名字重复出现，浪费大量空间。
②更新异常：由于数据冗余，更新数据库时维护的待价很大，修改系主任名导致每个元组都要修改
③插入异常：如果一个系刚成立尚没有学生，则无法把这个系及其系主任的信息存入数据库。
④删除异常：如果某个系学生全部毕业，删除学生信息的同时，这个系和系主任信息丢失。
好的关系模式：没有插入异常、删除异常、更新异常，且数据冗余尽可能少。

改进：把单一模式进一步细分为三个关系模式：
S(Sno,Sdept,Sno->Sdept);
SC(Sno,Cno,Grade,(Sno,Cno)->Grade);
DEPT(Sdept,Mname,Sdept->Mname);
这三个模式都不会出现插入异常、删除异常，数据冗余也得到改善。

规范化

函数依赖

定义：设R(U)是属性集U上的一个关系模式，X,Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称X函数确定Y或Y函数依赖于X，记作X->Y。
注意：函数依赖是指R的一切关系都要满足的约束条件，不仅仅是其中部分关系的约束。
非平凡的函数依赖：X->Y，但是Y⊄X
平凡的函数依赖：X->Y，但是Y⊂X，对于任一的关系模式，平凡函数依赖必定成立。

X-Y，则X称为决定因素；若X->Y,且Y->X,则X<–>Y；若Y不依赖于X，则X-/>Y；
完全函数依赖：在R(U)中，如果X->Y，并且对于X的任何一个真子集X’，都有X’-/>Y，则称为Y对X的完全函数依赖，记作 $X\stackrel{Full}{\longrightarrow}Y$ 。（X确定Y的最小属性集）
部分函数依赖：若X->Y，但Y不完全依赖于X，记作 $X\stackrel{Partial}{\longrightarrow}Y$ 。 (X中的某个子集即可唯一确定Y)
传递函数依赖：在R(U)中，如果X->Y(Y⊄X),Y-/>X,Y->Z(Z⊄Y),，则 $X\stackrel{传递}{\longrightarrow}Z$

码

候选码：设K为R<U,F>中的属性或属性组合，若 $K\stackrel{Full}{\longrightarrow}U$ ，则K为R的候选码。
超码：设K为R<U,F>中的属性或属性组合，若 $K\stackrel{Partial}{\longrightarrow}U$ ，则K为R的超码。候选码是最小的超码。
主码：当有多个候选码时，选定一个作为主码。
外码：关系模式R中的属性（属性组）X不是R的码，但却是另一关系模式的码，则称X为R的外部码。主码和外码提供了一个表示关系间联系的手段。
主属性：包含在任何一个候选码中的属性称为主属性；不包含在任何候选码中的属性称为非主属性。

范式

定义：关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同的范式。

范式关系

5NF⊂4NF⊂BCNF⊂3NF⊂2NF⊂1NF
规范化：一个低一级范式的关系模式经过模式分解可以转换为若干个高一级范式的关系模式的集合，称为规范化的过程。

1NF

定义：关系中每一个分量必须是不可分的数据项。

2NF

定义：满足1NF，进一步每个非主属性完全函数依赖于任何一个候选码。
不属于2NF带来的问题：插入异常、删除异常、修改复杂
解决办法：将原来非主属性对码的部分函数依赖，删除无关主属性，修改为非主属性对码的完全函数依赖。
示例：

有关系模式S-L-C（Sno,Sdept,Sloc,Cno,Grade）,其中Sloc为学生的住处，并且每个系的学生住在同一个地方。则有函数依赖关系为：
$(Sno,Cno)\stackrel{Full}{\longrightarrow}Grade$
Sno -> Sdept, $(Sno,Cno)\stackrel{Partial}{\longrightarrow}Sdept$
Sno -> Sloc, $(Sno,Cno)\stackrel{Partial}{\longrightarrow}Sloc$
Sdept -> Sloc
非主属性Sdept、Sloc不是完全依赖于码，所以关系模式S-L-C ∉ 2NF

投影分解：使得S-L的码为Sno,非主属性对码的完全函数依赖。
SC（Sno,Cno,Grade）和S-L（Sno,Sdept,Sloc）

3NF

定义：满足1NF的关系模式R<U,F>，若R中不存在这样的码X、属性组Y、非主属性Z(Y⊄Z)，使得X->Y(Y->X)，Y->Z成立，则称为R<U,F>为3NF。
结论：若R属于3NF，则每一个非主属性既不传递依赖于码，也不部分依赖于码。R属于3NF，则R必然属于2NF。
不属于3NF带来的问题：插入异常、删除异常、修改复杂
解决办法：将存在传递依赖的关系模式进一步模式分解为不含有传递的多个模式。
示例：

在上图中，SC关系模式没有传递依赖，但是S-L关系模式中存在传递依赖。所以S-L∉3NF。
投影分解：S-L分解后不存在传递依赖
S-D（Sno,Sdept）和D-L（Sdept,Sloc）

BCNF

定义：扩充的第三范式，关系模式R<U,F>满足1NF，若X->Y且Y⊄X时，X必然含有码，则R<U,F>称为BCNF。即每一个决定因素都包含码。
结论：满足BCNF的关系模式有
①所有非主属性对每一个码都是完全函数依赖
②所有主属性对每一个不包含它的码也是完全函数依赖
③没有任何属性完全函数依赖于非码的任何一组属性。
④R属于BCNF，则R必然属于3NF。属于3NF不一定属于BCNF。
5：在原来基础上，消除了主属性对码的部分依赖和传递依赖
示例：

例1：关系模式C（Cno,Cname,Pcno）所有非主属性对码没有传递依赖且是完全函数依赖，所以C∈3NF。同时Cno是唯一的决定因素，故C∈BCNF。

例2：关系模式SC（Sno,Cno,Grade）同上，SC∈BCNF。

例3：关系模式S（Sno,Sname,Sdept,Sage），假设Sname也具有唯一性，所以Sno、Sname都是候选码。非主属性不存在对主码的传递依赖、部分依赖，所以S∈3NF。同时S中除了Sno、Sname外没有其他决定因素，所以S∈BCNF。

例4：关系模式SJP(S,J,P)中，S是学生，J是课程，P是排名。每一个学生的每一门课都有一个排名，每门课程中一个名次只有一个学生。则有函数依赖为：
(S,J)->P； (J,P)->S
其中 (S,J)、(J,P)都可以作为候选码，这两个码都是由两个属性组成，而且它们是相交的。其中没有属性对码传递依赖或部份依赖，所以SJP∈3NF。而且除了 (S,J)、(J,P)外没有其他决定因素，所以SJP∈BCNF。

例5：关系模式STJ（S,T,J）S是学生，T是教师，J是课程。每个老师只教一门课程，每门课有若干老师，某一学生选定某门课，就对应一个固定老师。故有以下函数依赖：
(S,J)->T, (S,T)->J ,T->J
其中(S,J)、(S,T)都可以是候选码，因为非主属性没有对码的传递依赖或部分依赖，所以STJ∈3NF。但是STJ ∉ BCNF，因为T是决定因素，但T不包含码。

多值依赖

定义：在关系模式R（U），X、Y、Z是U的子集，并且Z=U-X-Y。关系模式R（U）中多值依赖X→→Y成立，当且仅当对R（U）的任一关系r，给定的一对（x,z）值，有一组Y的值，这组值仅仅决定于x的值而与z值无关。

在关系模式Teaching（C,T,B），Teaching∈ BCNF。
对于一组（物理，光学原理）对应T值为{李勇，王军}；同样对于（物理，物理习题集）也对应T值为{李勇，王军}。所以T值仅仅决定于课程C的值，因此T多值依赖于C，即C→→T。
平凡的多值依赖：在关系模式R（U），X、Y、Z是U的子集，并且Z=U-X-Y。若X→→Y，并且Z = ∅，则称X→→Y为平凡的多值依赖。b即对于R（X,Y），如果X→→Y成立，则X→→Y为平凡的多值依赖。
多值依赖的性质：
- 具有对称性：即若X→→Y，则X→→Z，其中Z = U-X-Y
- 具有传递性：即若X→→Y，则Y→→Z，其中X→→Z-Y
- 函数依赖可以看作是多值依赖的特殊情况，即若X→Y，则X→→Y
- 若X→→Y，X→→Z，则X→→YZ
- 若X→→Y，X→→Z，则X→→Y∩Z
- 若X→→Y，X→→Z，则X→→Y-Z，X→→Z-Y
多值依赖于函数的区别：
- 多值依赖的有效性与属性集的范围有关。
- 若函数依赖X→Y在R(U)上成立，则对于任何Y’⊂Y，均有X→Y’成立。但是多值依赖X→→Y若在R(U)上成立，却不能断言对于任何Y’⊂Y有多值依赖X→→Y’成立。
- 仅使用函数依赖，最高可达到BCNF；使用多值依赖，最高可达到4NF

4NF

定义：关系模式R(U,F)∈1NF，如果对于R的每个非平凡多值依赖X→→Y(Y⊄X)，X都含有码，则称R<U,F>∈4NF.
结论：4NF就是限制关系模式的属性之间不允许有非平凡的多值依赖。属于4NF，必然属于BCNF。
不属于4NF带来的问题：数据冗余较大。
解决方法：使用投影分解小区非平凡的多值依赖。
示例：

关系模式WSC（W,S,C）有W→→S,W→→C都是非平凡多值依赖，但是W不是码。因为WSC的码是全码！所以WSC∉4NF
投影分解：WSC分解为平凡的多值依赖
WS(W,S) , WC(W,C)

5NF

连接依赖：数据依赖除了函数依赖和多值依赖外，还有其他的数据依赖。函数依赖属于特殊的多值依赖，多值依赖属于特殊的连接依赖。但是连接依赖不可由语义直接导出，而是在关系的连接运算时才反应出来。
定义：在4NF的基础上消除连接依赖。

规范化过程总结

数据库设计

数据库设计概述

数据库设计：广义上指数据库及其应用系统的设计；狭义上讲是设计数据库本身，即设计数据库的各级模式并建立数据库
数据库设计的一般定义：指对于一个给定的应用环境，构造优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，是指能够有效地存储和管理数据，满足各种用户的应用需求。
数据库设计的目标：为用户和各种应用系统提供一个信息基础设施和高效的允许环境。

数据库系统设计的基本步骤

需求分析：首先必须准确了解与分析用户需求，关系到整个数据库建设
概念结构设计：对用户需求进行综合、归纳和抽象，形成一个独立于具体DBMS的概念模型
逻辑结构设计：将概念结构转换为某个具体DBMS所支持的数据模型，并对其进行优化
物理结构设计：为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）
数据库实施阶段：开发人员根据逻辑设计和物理设计的结果，使用数据库语言编写和调试应用程序。
数据库运行和维护：数据库应用系统经过试运行后，即可投入正式运行。在运行期间不断对其进行评估、调整和修改。

需求分析

任务：通过详细调查现实世界要处理的对象，充分了解原系统的工作概况，明确用户的各种需求，确定新系统的功能。
重点：调查的重点是“数据”和“处理”，即数据库需要存储什么数据，处理数据时的要求
步骤：
- 调查组织机构的情况。如部门组成、各部门职责等
- 调查各部门的业务活动。如输入/输出什么数据，如何处理数据、数据格式等
- 协助用户明确新系统的各种要求。如信息要求、处理要求、安全性等
- 确定新系统的边界。对前面调查结果进行初步分析，确定哪些是必须由计算机做，哪些由人工完成。由计算机完成的功能是新系统需要实现的功能。
调查方法：
①跟班体验：亲自参与到甲方的业务工作中了解情况
②开调查会：通过和用户座谈，了解用户需求
③请专业人士介绍。
④设计调查表请用户填写。
⑤查阅系统的数据记录。

数据字典

定义：数据字典是进行详细的收据收集和数据分析的成果，是需求分析阶段建立的。它是数据库中对数据的描述，是元数据。
组成：数据项、数据结构、数据流、数据存储、处理过程。
数据项：数据的最小组成单位。
数据项描述 = {数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}
数据结构：若干个数据项组成数据结构，数据结构反应了数据之间的组合关系。
数据结构描述 = {数据结构名，含义说明，组成：{数据项或数据结构}}
数据流：数据结构在系统内传输的路径。
数据流描述 = {数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}
数据存储：数据结构停留或保存的地方，它可以是手工文档或手工凭单，也可以是计算机文档。
数据存储描述 = {数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}
处理过程：说明处理过程的功能和处理要求。
处理过程描述 = {处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}

概念结构设计

定义：将需求分析的结果抽象为信息结构，是独立于任何一种数据模型的信息结构。

概念模型

特点：能真实、充分反映现实世界；便于用户理解；易于更改、易于向关系、网状、层次等各种数据模型的转换。

E-R模型

定义：使用E-R图来描现实世界的概念模型
实体之间的联系：实体内部属性之间的联系，实体之间的联系。
- 两个实体型之间的联系：一对一，一对多，多对多
- 两个以上的实体型之间的联系：一对一，一对多，多对多
- 单个实体型内的联系：一对一，一对多，多对多
E-R图：E-R图提供了实体型、属性、联系的方法，分别用矩形、椭圆型、菱形表示。注意：联系也可能具有属性，使用无向边将菱形与椭圆形连接起来。
实例：

某个工厂物资管理的概念模型：
实体包括：
①仓库：仓库号、面积、电话号码；
②零件：零件号、名称、规格、单价、描述；
③供应商：供应商号、姓名、地址、电话、账号；
④项目：项目号、预算、开工日期；
⑤职工：职工号、姓名、年龄、职称；
实体之间的联系包括：
①一个仓库可以存放多个零件，一个零件可以存放在多个仓库中，因此仓库和零件具有多对多的联系。使用库存量来表示某种零件在某个仓库中的数量
②一个仓库有多个职工当仓库保管员，一个职工只能在一个仓库工作，因此仓库和职工之间是一对多的联系。
③职工之间具有领导与被领导的关系，即仓库主任领导若干保管员，因此职工实体型内部具有一对多的联系。
④供应商、项目和零件三者之间具有多对多的联系。
实体属性图：

实体联系图：

完整的E-R图：

UML

UML：使用类图来建立概念模型，UML中的类对应于E-R图中的视图，UML中的类具有面向对象的特点，不仅描述对象的属性，还包括对象的方法。
使用说明：
- 实体型：矩形框中实体名放在上部，下面列出属性名。
- 实体的码：在类图中的属性后面用 "PK"标识。
- 联系：用类图之间的“关联”表示，关联的两个类之间用无向边连接，上面写出关联的名称。
- 基数约束：使用一个数对min…max 表示类中的任何一个对象可以在关联中出现的最少次数和最多次数。
- UML中的子类：面向对象技术支持超类—子类概念，子类可以继承超类的属性，也可以有自己的属性。
实例：

概念结构设计

引入：在设计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图

逻辑结构设计

引入：概念结构设计是独立于任何一种数据模型的信息结构。逻辑结构设计就是将概念结构阶段设计好的基本E-R图转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构。

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

任务：如何将实体型、实体的属性、实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。
原则：关系的属性就是实体的属性，关系的码就是实体的码。
实体间的联系的情况：
- 一个1：1的联系转换为一个独立的关系模式，或者与任意一端对应的关系模式合并。
- 一个1：n的联系转换为一个独立的关系模式，或者与n端对应的关系模式合并。
- 一个m:n联系转换为一个关系模式。
- 三个或三个以上实体间的一个多元联系可以转化为一个关系模式。
- 具有相同码的关系模式可以合并。
实例：工厂管理信息系统的E-R图转化为关系模型

设计用户子模式——外模式

将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体DBMS的特点设计用户的外模式，即利用视图设计用户的外模式。
要求：定义数据库模式考虑的是系统的时间效率、空间效率、易维护等角度；定义外模式则考虑用户的习惯、方便程度。
- 使用更符合用户习惯的别名
- 可以对不同级别的用户定义不同的视图
- 简化用户对系统的使用

物理结构设计

物理结构：数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，依赖于具体的DBMS。
步骤：确定数据库的物理结构、对物理结构进行评价

关系模式存取方法选择

数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的不同应用要求。物理结构设计的任务之一就是根据关系DBMS支持的存取方法确定选择哪些存取方法。
常用的存取方法：
- B+树索引存取
- hash索引存取：如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，则可以选择hash索引。
- 聚簇索引：为了提高某个属性（属性组）的查询速度，把这个或这些属性上具有相同值的元组集中存放在连续的物理块中称为聚簇。