【架构师】【数据库基础】【笔记 01】快速了解数据库系统的重要概念01

1 数据库的架构组成：

下图为数据库的基本的架构图，这个图显然是从数据库的基本的功能块的划分逻辑来做的。

我们想象的数据库系统，包括软件和使用者，硬件和软件各个方面的角度。对于认为数据库到底是什么的定义，我觉得应该是对不同的需求定义的人群，对数据库的定义不同。



 站在软件的角度，数据库就是存储的数据的集合，而数据库的其他的方面的知识，这是就由数据库的其他角度考虑。上图的表述应该是比较从各个角度，大致的反映出数据库系统的机构和组织。数据库显然先从需要数据服务的终端用户出发，经过各种针对业务逻辑（比如销售、库管、数据存储、数据分析）等等的定义出发，然后，构建适合应用逻辑的数据库应用系统。在数据库应用系统则结合了应用的开发工具，应用开发工具连接到DBMS（数据库管理系统），DBMS和操作系统对接，操作系统通过接口和数据库对接。而所有的这些数据和控制都需要再和业务的人员组织结合（这一点是数据库应用非常特殊的地方，数据具有价值，具有保密性，具有私密性）脱离了业务逻辑，脱离了公司的组织架构的权限设计去考虑一个完整的数据库架构是有缺陷的。

2 数据库的模型：

讲到数据库的架构，需要考虑的数据库的模型主要有三种：

第一种：层次型

【待研究】层次型的数据模型显然和二叉树很像，我觉得作为数据的追溯非常有效率，但是，实际的应用需要花时间调查。

从应用上看，和组织架构图很类似，具体如何应用确实不得而知。

第二种：网状图：

网状图通过有向的线段表述了数据集主体之间的关系，感觉并没有很好的逻辑分类。没有梳理



这个网状图其实可以说是有向图的一个关系表述。

第三：关系模型

关系模型是我们目前广泛应用的一个模型，就是用二维表来表述数据的模型。

那么为什么叫关系呢，因为二维表把数据的属性、数据的元组通过一个行、列的表格关系起来了，这样就成为关系模型。

这个模型的特点，就是在设计数据库的时候，就把数据的属性和数据的元组（可以理解为数据的一个样本元数据）通过行列分开了。这样就避免了数据的元组和数据的属性的纠缠，降低了数据模型的复杂度。也就是通过数据库的规范定义，解决了数据庞大可能造成的混乱。

3 数据库的规范和意义：

那么关系数据模型如何规范定义呢：

3.1 关系数据库的三个基本元素

属性：就是数据集的基本可分为数据集的最小特征、特质。一般为数据库的列。

元组：就是数据集的一个实例，或者叫一个样本的值。一般为数据库的行。

域:就是这个数据集的属性的取值范围。

其实有了上面三个定义，关系数据库就已经可以确认了！是不是异常简单。

3.2 数据库的规范意义

数据库的建立显然和数据的应用要求有关，同时也和数据的复杂度有关。如果属性复杂的数据不进行规范定义，那么，数据库的设计就会有问题。降低设计效率。相反，如果一个简单的应用和数据类型集，你设计一个复杂的规范定义，那么，显然也会降低这个效率。

那么，解决的最好办法就是我们把数据库的规范定义按照标准分为不同的等级，数据库设计的时候，依据不同的需求，选择不同的规范等级来设计数据库。

那么范式的概念就出来了。

数据库的范式分为五个等级：

第一范式，

我们理解为第一级别的范式，也是最基本的范式，是这样定义的：

在一个关系中，消除重复字段，且各个字段都是最小的逻辑存储单位。

【案】字段的定义其实可以理解为二维表的列的属性，上面提到的。第一范式很简单的定义，其实就是消除数据库库冗余，并保证数据在数据库的属性唯一性。

下图各例子，为不符合第一范式的样子。



显然，上述C语言是重复字段，无法甄别数据，改变的方法增加学号字段。



显然，上述的C语言和Java语言是可以分别的数据项，不符合最小逻辑概念的定义，所以，不符合第一范式。

详细可再参阅参考链接获取修改。

第二范式，

在第一范式的基础上， 强调每一个非主关键字段都完全依赖于主关键字段，不能只依赖于主关键字的一部分。

【案】我理解为，数据库的依赖只来自于数据库的主键。

第三范式，

第三范式，在第一，第二范式的基础上，去掉了传递依赖。

到目前为止，我们还是只是研究了概念，对于第一，第二范式具体的定义区别在哪里呢？

我们再看一下下面的例子：

首先，我们构建一个学生信息的数据库，大致，一般都能构成这样的Excel的表格，这种办公表格很常见。



那么这个数据表格是否能够用来设计为数据库呢？是否符合范式的要求？

第一范式显然已经符合，对于第二范式的要求：

1 如何决定主属性（或者叫做关键字段）

我们看上图这一条元组，

如果我们要得到一个学生的C语言的分数，我们至少需要哪些属性呢？

1 学号 2课程名称 是不是知道了这两个属性就可以知道分数了，显然是的，也就是说（学号+课程名称）是数据库查询的最基本属性，我们可以称之为主属性（关键属性）

好，那么我们再来研究第二范式的要求，

第二范式要求是：

在第一范式的基础上， 强调每一个非主关键字段都完全依赖于主关键字段，不能只依赖于主关键字的一部分。

（上图例子里，我们知道，其实宿舍楼，系名都不能作为主属性，于是他们都是非关键属性）

那么对这两个非关键字段，是不是完全依赖于主关键字段了呢？ 我们前面已经分析得到，主关键字段，这里就是：（学号+课程名称）

那么（学号+课程名称）能决定宿舍楼吗？ 显然不能，我们知道要知道一个学生的宿舍楼，他必须知道这个学生的学号和这个学生所在的系，那么显然，

宿舍楼并不是完全依赖于我们刚才已经分析出来的主键（学号+课程名称）的。上图的关系表就不符合第二范式了。

同理，非关键字段系名，也不完全依赖于（学号+课程名称）。

那么，要让上图的二维关系表符合第二范式，我们就应该把这里两个不符合的字段单独拿出来成表。



再来分析第三范式是否符合：

第三范式，在第一，第二范式的基础上，去掉了传递依赖。

上图表2 里面我们知道，要知道宿舍楼的名称，我们必须知道你的学号、所在的系。也就是存在：

(学号) → (所在系) → (宿舍) 的一个传递依赖，这个依赖是第三范式不符合的原因。

去掉这个依赖后的数据二维表为：

参考：

1 第一、第二、第三范式之间的理解和比较
http://www.cnblogs.com/ktao/p/7775100.html
【注意】文章写的比较精辟，但是，讨论的部分还是有很多错误，也许是原作笔误。

2 关系数据库范式和非范式架构的利弊分析
http://blog.csdn.net/qxbailv15/article/details/9077537
【注意】文章对范式的几个说明并不正确存在错误。