数据库系统 DBS 的组成:数据库、硬件、软件、人员。

数据库管理系统 DBMS 的功能:数据定义、数据库操作、数据库运行管理、数据的存储管理、数据库的建立和维护等

DBMS的分类：关系数据库系统RDBS、面向对象的数据库系统OODBS、对象关系数据库系统ORDBS

数据库系统的体系结构:

集中式数据库系统(所有东西集中在 DBMS 电脑上)、客户端/服务器体系结构(客户端负责请求和数据表示，服务器负责数据库服务)、并行数据库系统(多个物理上在一起的 CPU)、分布式数据库系统(物理上分布在不同地方的计算机)。

1三级模式一两级映像

内模式:管理如何存储物理的数据，对数据的存储方式、优化、存放等

模式:又称为概念模式，就是我们通常使用的表这个级别，根据应用、需求将物理数据划分成一张张表。

外模式:对应数据库中的视图这个级别，将表进行一定的处理后再提供给用户使用，例如，将用户表中的用户名和密码组成视图提供给登录模块使用，而用户表中的其他列则不对该模块开放，增加了安全性。

外模式一模式映像:是表和视图之间的映射，存在于概念级和外部级之间，若表中数据发生了修改，只需要修改此映射，而无需修改应用程序。

模式一内模式映像:是表和数据的物理存储之间的映射，存在于概念级和内部级之间，若修改了数据存储方式，只需要修改此映射，而不需要去修改应用程序。

以上的数据库系统实际上是一个分层次的设计，从底至上称为物理级数据库(实际为一个数据库文件)、概念级数据库、用户级数据库，各层情况如下:

 

2数据库设计

需求分析:即分析数据存储的要求，产出物有数据流图、数据字典、需求说明书。

概念结构设计:就是设计 E-R 图，也即实体-联系图，与物理实现无关，就是说明有哪些实体，实体有哪些属性。

逻辑结构设计:将 E-R 图，转换成关系模式，也即转换成实际的表和表中的列属性，这里要考虑很多规范化的东西。

物理设计:根据生成的表等概念，生成物理数据库

具体各个设计阶段的产出物、要求等如下所示:

3 E-R模型

数据模型的三要素:数据结构、数据操作、数据的约束条件。在 E-R 模型中，使用圆表示属性 (一般没有)、长方形表示实体、菱形表示联系，联系的两端

要填写联系类型，示例如下图:

联系类型:一对一1:1、一对多 1:N、多对多 M:N。

属性分类: 简单属性和复合属性(属性是否可以分)，单值属性和多值属性(属性有多个取值)NULL 属性 (无意义)、派生属性 (可由其他属性生成)。

那么 E-R 模型如何转换为关系模型呢(实际就是转换为多少张表)?

每个实体都对应一个关系模式;

联系分为三种:1:1 联系中，联系可以放到任意的两端实体中，作为一个属性 (要保证 1:1 的两端关联): 1:N 的联系中，联系可以单独作为一个关系模式，也可以在 N 端中加入1端实体的主键M:N 的联系中，联系必须作为一个单独的关系模式，其主键是 M 和 N 端的联合主键。

以上，明确了有多少关系模式，就知道有多少张表，同时，表中的属性也确定了，注意联系是作为表还是属性，若是属性又是哪张表的属性即可。

4关系代数运算

关系模式在代数运算时可以理解为数据库中的表，两个概念通用

并:结果是两张表中所有记录数合并，相同记录只显示一次。

交:结果是两张表中相同的记录。

差:S1-S2，结果是 S1表中有而S2表中没有的那些记录设有 S1 和 S2 关系如下图，其并交差结果如下图:

笛卡尔积:S1S2，产生的结果包括 S1 和 S2 的所有属性列，并且 S1 中每条记录依次和 S2 中所有记录组合成一条记录，最终属性列为 S1+S2 属性列，记录数为 S1S2 记录数投影:实际是按条件选择某关系模式中的某列，列也可以用数字表示。选择:实际是按条件选择某关系模式中的某条记录设有 S1 和 S2 关系如下图，其笛卡尔积、投影、选择结果如下图:

自然连接:结果显示全部的属性列，但是相同属性列只显示一次，显示两个关系模式中属性相同且值相同的记录。自然联接结果如下;

效率问题: 关系代数运算的效率，归根结底是看参与运算的两张表格的属性列数和记录数，属性列和记录数越少，参与运算的次数自然越少，效率就越高。因此，效率高的运算一般都是在两张表格参与运算之前就将条件判断完。如:

π1,2,3,8 (σ2='大数据'¹⁼⁵3=6^8='开发平台'(RXS))和

π1,2,3,8 (σ1=5^3=6 (2='大数据'(R) Xσ4=开发平台'(S)))

后者效率比前者效率高很多。

5关系数据库的规范化

5.1 函数依赖

给定一个X，能唯一确定一个Y，就称X确定Y，或者说Y依赖于X，例如 Y=X*X函数。函数依赖又可扩展以下两种规则:

部分函数依赖:A 可确定 C，(A,B)也可确定 C，(A,B)中的一部分(即 A)可以确定 ，称为部分函数依赖。

传递函数依赖:当A 和B 不等价时，A 可确定 B，B 可确定 C，则A可确定 ，是传递函数依赖若 A 和 B 等价，则不存在传递，直接就可确定 C。

Armstrong公理系统

设U 是关系模式 R的属性集，F 是 R 上成立的只涉及 U 中属性的函数依赖集。函数依赖的推理规则有:

自反律:若属性集 Y 包含于属性集 ，属性集  包含于 U，则 X-Y 在 R 上成立。(此处 XY是平凡函数依赖)

增广律:若X一Y 在R 上成立，且属性集Z 包含于属性集 U，则XZ-YZ 在 R 上成立传递律:若X一Y 和 Y一Z在R 上成立，则X -Z在R 上成立。合并规则:若X-Y，X一Z 同时在 R 上成立，则X一YZ在R 上也成立。分解规则:若X-W在R上成立，且属性集包含于 W，则X一Z在R上也成立伪传递规则:若X-Y在R上成立，且WY-Z，则XW-Z

5.2 键与约束

超键:能唯一标识此表的属性的组合

候选键:超键中去掉冗余的属性，剩余的属性就是候选键

主键:任选一个候选键，即可作为主键。

外键:其他表中的主键

候选键的求法: 根据依赖集画出有向图，从入度为 0 的节点开始，找出图中一个节点或者一个节点组合，能够遍历完整个图，就是候选键。

主属性:候选键内的属性为主属性，其他属性为非主属性。

实体完整性约束:即主键约束，主键值不能为空，也不能重复。

参照完整性约束:即外键约束，外键必须是其他表中已经存在的主键的值，或者为空。

用户自定义完整性约束:自定义表达式约束，如设定年龄属性的值必须在0到 150 之间。

触发器:通过写脚本来规定复杂的约束。本质属于用户自定义完整性约束。

5.3 范式

数据库中的范式总体概论如下图:

 

第一范式1NF

关系中的每一个分量必须是一个不可分的数据项。通俗地说，第一范式就是表中不允许有小表的存在。比如，对于如下的员工表，就不属于第一范式:

1NF 可能存在的问题:1NF 是最低一级的范式，范式程度不高，存在很多的问题。比如用一个单-的关系模式学生来描述学校的教务系统:学生(学号,学生姓名,系号,系主任姓名,课程号,成绩)

这个表满足第一范式，但是存在如下问题:

数据冗余:一个系有很多的学生，同一个系的学生的系主任是相同的,所以系主任名会重复出现。

更新复杂:当一个系换了一个系主任后，对应的这个表必须修改与该系学生有关的每个元组。

插入异常:如果一个系刚成立，没有任何学生，那么这个无法把这个系的信息插入表中。

删除异常:如果一个系的学生都毕业了，那么在删除该系学生信息时，这个系的信息也丢了。

第二范式2NF如果关系R 属于 1NF，且每一个非主属性完全函数依赖于任何一个候选码，则 R属于 2NF。通俗地说，2NF 就是在 1NF 的基础上，表中的每一个非主属性不会依赖复合主键中的某一个列。按照定义，上面的学生表就不满足 2NF，因为学号不能完全确定课程号和成绩(每个学生可以选多门课)。将学生表分解为:

学生(学号,学生姓名,系编号,系名,系主任)选课(学号,课程号,成绩)。

每张表均属于 2NF。

第三范式3NF

在满足 1NF 的基础上，表中不存在非主属性对码的传递依赖

继续上面的实例，学生关系模式就不属于 3NF，因为学生无法直接决定系主任和系名，是由学号->系编号，再由系编号->系主任，系编号->系名，因此存在非主属性对主属性的传递依赖，将学生表进一步分解为:

统架构

学生(学号，学生姓名，系编号)

系(系编号，系名，系主任)

选课(学号,课程号,成绩)

每张表都属于3NF。

BC范式BCNF

所谓 BCNF，是指在第三范式的基础上进一步消除主属性对于码的部分函数依赖和传递依赖。通俗的来说，就是在每一种情况下，每一个依赖的左边决定因素都必然包含候选键，如下:

上图中，候选键有两种情况:组合键(S,)或者(S,J)，依赖集为J-T，T一J，可知，ST] 三个属性都是主属性，因此其达到了 3NF(无非主属性)，然而，第二种情况，即(S,J)为候选键的时候，对于依赖T->J，T在这种情况不是候选键，即T 的决定因素不包含任意候选码，因此上图不是 BCNF要使上图关系模式转换为 BCNF 也很简单，只需要将依赖T-J变为 TS即可，这样其左边决定因素就包含了候选键之一

5.4模式分解

范式之间的转换一般都是通过拆分属性，即模式分解，将具有部分函数依赖和传递依赖的属性分离出来，来达到一步步优化，一般分为以下两种:

保持函数依赖分解

对于关系模式 R，有依赖集 F，若对 R 进行分解，分解出来的多个关系模式，保持原来的依赖集不变，则为保持函数依赖的分解。另外，注意要消除掉冗余依赖(如传递依赖)。

实例:设原关系模式 R(A,B,C)，依赖集 F(A-B,B-C，A-C)，将其分解为两个关系模式 R1(A,B)和R2B,C)，此时 R1 中保持依赖 A-B，R2 保持依赖 B-C，说明分解后的 R1和 R2是保持函数依赖的分解，因为 A->C 这个函数依赖实际是一个几余依赖，可以由前两个依赖传递得到，因此不需要管。保持函赖的判断(补充，第2点不强

1、如果F上的每一个函数依赖都在其分解后的某一个关系上成立，则这个分解是保持依赖的(这是一个充分条件)。 也即我们课堂上说的简单方法，看函数每个依赖的左右两边属性是否都在同一个

分解的模式中。2、如果上述判断失败，并不能断言分解不是保持依赖的，还要使用下面的通用方法来做进一步判断。

该方法的表述如下:

算法二:

对F上的每一个a一B使用下面的过程:

result;= a ;

while(result 发生变化)do

for each 分解后的 Ri

t=(resultA Ri)+ ARi

result=resuit Ut

以下面的例题纠错作为讲解:正确答案是无损分解，不保持函数依赖。