数据库底层理论基础小结

        这几天又重温了一下数据库的基础.大体又总结了以下几点:

1. 什么是数据库?什么是数据库管理系统?其实以前是没有数据库这样一个概念的，后来随着技术的发展,才逐步出现了这样一个事物,现在最流行的应该算是关系型的数据库.因为大家可以从市面上的数据库管理系统中找到答案,你象现在业界非常流行的SQL SERVER,ORACLE,MYSQL,DB2等,都是关系型的.

2.为什么关系型数据库会大行其道？是因为有非常令人信服的理论基础，那就是关系代数（其实可能没有这样一个概念，姑且这么叫吧）。那么在这里面就必然要提到几个概念：（1）域，也叫字段或者属性，是具有相同类型的值的集合，如果从数据库的角度讲，也可以认为其就是等同于列。（2）关系，这是核心。我认为关系就可以理解为数据库中的一张表或视图。关系的元组对应行，关系的域内容对应列，关系的码对应键。然而，关系是“粗糙”的（想来想去，我只能用这个词了），所谓粗糙是因为关系是必须经过一定的加工过程才能真正转换成数据库中的表。那么这个转换过程其实就是建模的过程，其实是很复杂的，那就必然要牵涉到（3）范式：第一，第二，第三，BC范式。简单复述一下概念：关系中的各个域都是原子的，那么称关系符合第一范式；在第一范式的基础上，如果消除了每个非主属性对候选码的部分依赖，那么就可以称之为第二范式；在第二范式的基础上，如果消除了每个非主属性对候选码的传递依赖，就可以是第三范式了。如果各个属性都不传递依赖于候选码，就是BC范式。具体的例子有很多，如R(ID,观测点代号，观测点，观测点程度，每个程度的票数）存在大量数据冗余，是第一范式，那么分解：R1(观测点代号，观测点),R2(ID,观测点代号，观测点程度，每个程度的票数）消除了部分依赖，就是第二范式。如果再分：R1(观测点代号，观测点),R2(ID,观测点代号，观测点程度),R3(ID,每个程度的票数),消除了传递依赖，就是第三范式了。在刚才那个例子中，提到了（4）函数依赖，从关系理论的角度，如果对于一个关系R,U是其域的集合，如果对于任意的元组u，都有u(i)（其中i是U中的第i个域）＝u(j)（其中j是U中的第j个域），那么称U(i)函数决定U(j),或者称U(j)函数依赖于U(i)。函数依赖可以有三种类型：完全函数依赖，部分函数依赖，传递函数依赖，具体的含义可以参考上面的例子去理解。

 3.如何在关系理论的基础指导设计符合规范的数据库？所谓符合规范的数据库，业界通常有这样一个说法，数据库中的各个关系要满足第三范式。大家都知道，进行数据库设计的前提是首先要照准业务领域当中的数据模型，建立ER图。有了ER图相当于已经把业务领域需要用到的数据信息和各个实体之间的关系基本上都找到了。但这还只是一个概念模型，如何转换为逻辑模型，就要充分挖掘数据和数据之间的关系，然后在关系理论的指导下，进行关系分解，那么最终分解的依据就是各个关系之间要满足第三范式。只有逻辑模型抽象成功后，才进一步将其映射到某一个DBMS，形成用户模型（也即设计开发人员可以直接使用的模型）。

       有了关系代数的理论知识，关系型数据库才有这么辉煌的今天，这又应了一句话，如果你对某个知识不能从数学的角度去描述它，说明还没有真正的理解它。温故而知新，无论正确与否，对数据库的理解又加深了一些。