数据库理论

前言

本篇只讲述数据库相关的各种概念理论，具体代码实践不在本篇讨论范围之内，此后会另起一篇写代码和例题

由于是还有几天就要考试了，所以本篇内容尽量精简，采用的语言也并不官方，尽可能通俗易懂。

数据库发展史

什么，竟然要考这个？

数据库发展经过了四个阶段：

时间	内容
人工管理阶段	20世纪40年代中–50年代中
文件系统阶段	20世纪50年代末–60年代中
数据库系统阶段	20世纪60年代末–现在
新一代数据库管理系统	20世纪90年代–未来

（看到最后这里的年代我迷惑了一下，但是咱也不敢问啊）

人工管理阶段

背景

硬件上没有直接存取的设备，软件上没有操作系统，处理方式为批处理

应用程序和数据的对应关系

应用程序和数据集一一对应

特点

数据仅面向某一个应用程序，不保存不共享，内容冗余度高，且不独立无结构，完全被程序控制

文件管理阶段

背景

硬件上有了磁盘和磁鼓（？什么鬼），软件上有了操作系统，处理方式上有了联机实时处理

应用程序和数据的对应关系

允许一个应用程序对应一个数据文件，
也可以多个应用程序对应一个文件管理系统，再对应多个文件

特点

数据依旧面向某一程序，可以长期保存，共享性较差且冗余度大，记录有结构整体无结构，独立性差，依旧是应用程序控制数据

数据库系统阶段

这里更多的是指传统的文件系数据库
背景

出现了大规模管理的需求，硬件上有了更大容量的磁盘和磁盘阵列，软件上有了数据库管理系统，处理方式有了分布式处理

应用程序和数据的对应关系

（此处主要指的是文件系数据库阶段）多个应用程序对应一个数据库操作系统，这个数据库操作系统对应一个数据库

新一代数据库管理系统

比如
分布式数据库: 数据分布在网络上，但是逻辑上属于一个系统，
空间数据库：主要描述、存储和处理空间数据及其属性，
NoSQL数据库…，
面向对象数据库…，
…

数据模型

概念
数据模型是对现实世界的模拟和抽象，用来描述数据如何组织、操作和存储的。

分类

分为三类：概念模型、逻辑模型、物理模型
分别对应现实世界，信息世界（第一层抽象），机器世界（第二层抽象）

组成
分为三部分： 数据结构、数据操作、数据完整性约束条件

概念模型

现实世界到机器世界的一个中间层次
主要描述有哪些实体和关系
简单说就是描述是什么，E-R图

涉及一些前置的概念：

实体Entity
客观存在并且相互区别的事物称为实体，包括事物和概念
比如张三、汽车、运动、喜好这些名词都是实体
属性Attribute
实体所具有的某一特性
码Key
唯一标识实体的属性
域Domain
属性的取值范围称
实体集Entity Set
同一类型实体的集合称为实体集
实体型Entity Type
用实体名及其属性名集合来抽象和刻画同类实体

比如学生(学号，姓名，性别，院系，专业)，表示学生实体，
全体学生则是实体集
实体集之间的联系

联系
实体内部的联系通常是指的组成实体的各属性之间的联系
实体之间的联系通常是指的不同实体集之间的联系
联系分为一对一，一对多，多对多

E-R图

矩形
表示实体
椭圆
表示属性
菱形
表示联系

比如这样

有时候，联系本身也是一种实体，可以有属性

存在多个实体间多对多联系的时候

单个实体型内的联系

逻辑模型

从数据的组织方式来描述数据，即用什么样的数据结构来组织
简单说就是在概念模型基础上，进一步考虑实体的属性
也就是定义做什么

逻辑模型可以分为三类：
非关系模型（早期数据库）

主要是指层次模型和网状模型

关系模型（当下流行数据库）

以严格的数学理论为基础：谓词逻辑、集合论
（什么？竟然是离散数学）

关系型数据库则采用关系模型
其中，关系通常对应一张表，该表包含数个属性和数个元组，而关系模式则是对关系的一种描述，格式为

关系名字（属性1，属性2，属性3…）

当然，也可以用E-R图描述，此处不再赘述

面向对象模型

未来的方向，不知道是什么意思，或许是以能够存对象为基础吧

物理模型

在逻辑模型的基础上，考虑存储空间等问题，即数据类型，长度大小等等
也就是怎么做

三级模式

由概念模式、外模式、内模式

概念模式
数据库用户看见和使用的局部数据的逻辑结构和特征的描述
所有用户的公共数据视图，综合所有用户的需求

一个数据库只有一个模式

外模式
数据库用户看见和使用的局部数据的逻辑结构和特征
描述一个数据库可以有多个外模式
外模式是保证数据库安全性的一个有力措施

内模式（存储模式）
是数据结构和存储方式的描述
是数据在数据库内部的表示方式

具体示例

二级映像

为了实现三级模式之间的转换而出现的二级映像：
外模式/概念模式映像
保障了数据的逻辑独立性
对每一个外模式，数据库都有一个外模式/概念模式映像
概念模式/内模式映像
保障了数据的物理独立性
对于每一个概念模式，数据库都有一个概念模式/内模式映像

函数依赖

数据依赖的主要类型有函数依赖，多值依赖, 连接依赖等
这里主要讨论函数依赖

在属性（或属性组）X的值确定的情况下，必定能够确定属性Y的值
记为 X->Y
例如：学号->学生姓名，代表学生姓名函数依赖于学号

可以细分为部分函数依赖、完全函数依赖、传递函数依赖

部分函数依赖

比如， 存在一个属性组{学号，年龄}，其中有学号满足学号->姓名，即可称姓名部分函数依赖于{学号， 年龄}
即属性组（集合）存在真子集满足一个函数依赖时，就称为部分函数依赖。
严格地说应该记为A-P->B，P表示Part部分

完全函数依赖

类似于部分函数依赖，但是要求是该属性组没有多余的属性，
也就是说，
比如存在一个属性组{a, b, c}, 要求a->x, b->x, c->x，{a, b}->x, {a, c}->x,{b, c}->x也就是x函数依赖于其中所有真子集
严格地说应该记为A-F->B，Full表示Full全部

传递函数依赖

比如， a->b, b->c, 可以间接推导出a->c，这就称为c传递函数依赖于a
严格地说应该记为A-T->B，T表示Transition传递

码

概念

当问起一张表有没有码的时候，这并不是骂它

码是可以确定一个元组所有信息的属性或者属性组

其中，元组是指一个表里面的某一行，而属性其实就是一个表里的某一列

比如，存在一个属性组{学号，姓名，年龄，专业}，那么其他所有属性都可以函数依赖于学号，那么就可以把学号称为主码或者主键，不能为空
如果不考虑重名，那么姓名也能推出其他信息，但是由于只能有一个主码，所以姓名只能做候选码，当然主码被看做是特殊的候选码
如果某个属性部分函数依赖于某个属性组，那么这个属性组就是超码
注意，候选码是最小的码（最小的超码），即候选码的真子集不能有码

主属性和非主属性

包含在任何一个候选码中的属性，称为主属性
不包含在任何码中的属性称为非主属性
如果整个属性组都是码，那么成为全码

举个全码的例子：

关系模式R（P,W,A）,P是演奏者，W是作品，A是听众
一个演奏者->多个作品 一个作品->多个演奏者 多个听众->多个演奏者、多个作品
需要同时确定三者才能推导出整行的信息，码表示为（P,W,A），即为全码

上述内容提到的关系模式可以看做是一张表，包含了PWA三个属性

外部码（外码）

举个例子

两个关系模式中，
学生选课表(学号，课程号，成绩)，以下称为表A
学生信息表(学号，专业，年龄), 以下称为表B
表A中，需要同时确定学号和课程号才能确定一个元组，所以候选码是（学号，课程号）
表B中，只需要确定学号就能确定一个元组，所以候选码是（学号）
可以看到，学号不是A的码，但是是B的码，那么把学号称为A的外码

关系

不仅是生活中的关系，也指离散数学中集合间的关系，更指关系型数据库中的关系

关系型数据库

关系模式
对关系的描述即为关系模式，表示为
关系名（属性1， 属性2 …）

关系型数据库则是建立在关系模型上的数据库，在关系数据库中面实体和实体间以关系的形式进行描述

关系的形式具体指的是以表格的形式

完整性约束

完整性约束时为了保证数据库中数据的正确性和相容性，对关系模型提出的某种约束条件或规则
其中，完整性包括了四个部分：
1.域完整性
2.实体完整性
3.参照完整性
4.用户定义完整性
其中，123是关系模型必须满足的完整性约束条件

1.域完整性

指约束数据类型、格式、取值范围、是否允许空值等。

2.实体完整性

指关系型数据库中所有表都必须有主码，且不允许存在与其他记录的主码相同的记录（主码是唯一的标识）

3.参照完整性

指的是外码的值必须参考主码的值，关系中不能引用不存在的记录
比如存在两个关系（也就是表），A和B，A中的a属性参照B中的b属性（参照，大概就是类似于平时说的左外/右外连接那样）
则对于a的值，必须为空或者B中某个元组中属性b的取值

4.用户自定义完整性

指的是针对某一具体关系数据库的约束条件，反映某一具体应用所涉及的数据必须满足的语义要求
可以看做是一种随机应变的规范，比如银行卡取款金额不能超过余额

关系代数

运算符

集合运算符（4）
交 并 差 笛卡尔积
专门关系运算符（4）
选择 投影 连接 除
算术比较符（6）
大于 大于等于 小于 小于等于 等于 不等于
逻辑运算符（3）
或 且(与) 非
其他运算符（2）
更名运算符 赋值运算符

关系代数操作的是一个序列形成的关系代数表达式，运算对象是关系，运算结果也是一个关系

下文节选部分关系代数运算提供示例

集合运算：并
具有相容性

并运算的关系必须有相同的属性个数，并且每个相对应的属性都有相同的域
对应的属性名称不一定一致，在不一致的时候会取参与运算前者的属性名。

集合运算：差

集合运算：笛卡尔积

运算的结果是具有n+m个属性，r * s个元组

（图没截全）

专门关系运算：选择
看做SELECT语句就好，针对的是元组

专门关系运算：投影
和选择类似，但是针对的是列
具有重复消除性

如果投影运算的属性列表中只包含关系的非键属性，那么结果关系中就有可能出现重复的元组（如下图，是因为必须要有新的主键产生，但是又不能和主键的定义矛盾）
这时候，就会消除重复的元组，所以投影运算得到的关系的元组数量小于等于关系的元组个数

专门关系运算：连接
连接运算根据情况分为θ连接或自然连接

θ连接
当连接运算的条件是形如AθB的时候，就称为θ连接
当θ为=时，则该连接称为等值连接
当有连接的关系存在共同的属性时，可以简化为自然连接，即以共同的属性进行自动匹配

与笛卡尔积的区别
主要区别是运算结果的元组数目不同：
对于笛卡尔积，两个关系所有元组的组合都会出现在笛卡尔积的结果中，而只有符合连接条件额度元组才会出现在连接结果中

专门关系运算：除

这里有两个关系R(A1…An, B1…Bm), S(B1…Bm,C1…Ck)
其中存在共同的属性：（B1…Bm）
在R中取(A1…An)取值相同的所有元组中的(B1…Bm)属性的值作为一个集合RB
在S这边取(B1…Bm)上所有取值作为一个集合SB
如果有SB是RB的子集，则R中(A1…An)的取值便构成了R÷S的一个元组

上面的描述挺复杂的，记起来也很麻烦，还是看个例子吧

首先表R和S都有的属性是C和D
那么把R中A和B属性中值相等的C和D属性的值作为一个集合，得到这个集合并记为

RS = {{(c, d), (e, f), (h, k)}，{(e, f), (d, l)}，{(c,d),(e,f)}}

而S这边得把C和D作为一个集合，记为

SS = {{(c,d),(e,f)}}

很显然，SS是RS的子集，所以满足这个关系的RS的C和D属性对应的A和B属性即成为该运算结果的属性

其他运算：赋值
其实就是修改关系名以便引用，当然也可以修改属性名

其他运算：更名
给关系代数的运算结果命名，也可以修改运算结果的属性名
注意，别被运算的名字误导了！

范式

定义为
符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。一般我们用NF代表范式。
（很晦涩…）

数据库范式有1NF，2NF，3NF，BCNF，4NF，5NF
但是一般我们只需要考虑到BCNF就够了

第一范式1NF

关系中的属性不可再分，即属性不能具有属性。

1NF是对所有关系型数据库的最基本要求

但是仅仅符合1NF的设计可能会存在数据冗余过大，插入异常，删除异常，修改异常等问题

第二范式2NF

消除了非主属性对于码的部分函数依赖
要求每个实例或者行必须唯一地被区分，每一行数据只能与其中一列相关，如果出现重复的数据，那么就要把它拆分开来。

第三范式3NF

3NF在2NF基础上，消除了非主属性对于码的传递函数依赖
即存在非主属性对于码的传递函数依赖，则不符合3NF

3NF 基本 解决了数据冗余过大，插入异常，删除异常的问题

BCNF范式

在3NF的基础上，消除主属性对于码的部分函数依赖和传递函数依赖

总结一下大概就是这样

例题