数据库管理系统DBMS概论

数据库管理系统（DataBase Management System,DBMS）由一个互相关联的数据的集合（数据库）和一组用以访问这些数据的程序组成。DBMS的主要目标是提供一种可以方便高效的存取数据库信息的途径。

数据库系统特点

---

在信息化社会，充分有效地管理和利用各类信息资源，是进行科学研究和决策管理的前提条件。实际上，除了使用数据库，我们还可以用其他的方法来持久化数据，比如：文件系统。但为什么最终选择使用数据库呢？因为它具有其他存储系统所不具备的很多优势。

我们通过数据库系统与文件系统的比较来分析数据库系统操作数据的优势：

避免冗余&避免数据不一致

在工作的项目中，很多个程序员都会对持久层进行访问。在使用文件系统的情况下，不同的程序员可能创建出不同结构的文件。更让人头痛的是，如果每个人都需要使用同一份信息，可能在两份文件中维护了一份内容相同的数据，造成不必要的冗余。而且冗余数据在修改上也会带来很多麻烦：如果你要修改其中之一，就不得不把所有冗余信息全部修改一遍，否则会出现数据不一致的情况。在文件系统中，数据冗余和不一致的情况会经常发生。但数据库系统通过对表的连接，可以很方便的查询到每个表中的属性，通过数据库操作，删除某个表中不必要的冗余信息或者从一开始就能避免冗余的发生。

便于数据访问

在文件系统中，如果让你从文件中提取出“某地区年龄大于60岁的所有公民的家庭电话”的信息列表，那么你可以编写程序进行处理，但是下一次又让你查询“某地区身高大于180cm的男性的家庭住址”的信息。这个时候你发现：每当有一个需求，都需要重新编写程序查询信息。传统的文件系统不支持以一种方便高效的方式去获取所需数据，数据库采用的面向结果查询语句能对变化的需求更快的做出反应。对持久层数据最频繁的操作就是查询，我们使用数据库系统的查询语句从原理上快过传统文件系统面向过程的代码编写。

完整性约束问题

数据库中存储数据的值必须满足某些特定的一致性约束。假设银行中维护一个账户，并要求每个账户的余额不能小于0。开发者通过在不同的应用程序中加入适当的约束来满足这一条件。但如果涉及多个文件中多个数据共同以某些条件来决定另外一个文件中的数据时，通过编写程序来完成约束是几乎不可能实现的。如果使用数据库系统，在多个表中表示条件并设定约束并不是一件难事。

原子性问题&并发异常问题

当有多个进程或是线程同时访问持久层数据，就会涉及到并发异常和原子性的问题。如果两个进程同时对一个文件中银行账户的余额信息进行操作，很有可能发生错误：一个进程刚读取余额并将其增加一个数值时被切断，另外一个进程读取余额并减去一个值后将结果写回余额中，第一个进程再将增加后的数值写回余额中，这样这个账户余额并没有完成第二个进程的操作，从而引发错误。除了多进程/线程引发的错误，计算机的突然掉电，和一些外部因素导致的问题都有可能让文件系统发生未知的错误。数据库系统在这个方面进行了处理，确保了并发的安全性，确保了操作的原子性。

安全性问题

并非数据库系统的所有操作者都可以访问所有数据，通过权限的控制来控制不同的操作者对数据的可见性。如果采用文件系统，这种需求很难实现，数据库系统采用视图的方法很好的解决了此类问题。

数据库三层抽象层次

---

一个好用的数据库系统必须能高效的检索数据，这种高效性的需求促使设计者在数据库中使用复杂的数据结构来表示数据。就如同OSI七层模型一样，每一次都对下层进行封装，上层不需要知道下层的具体实现，只需要知道调用的接口即可。在数据库中，为了方便操作，我们将其封装成三层抽象结构：

物理层

物理层是最低的抽象层次，描述数据在计算机中实际上是怎么存储的。物理层详细描述复杂的的底层数据结构。

逻辑层

比物理层的层次稍高的抽象，描述数据库中存储什么数据以及这些数据之间存在什么关系。通过物理层的封装，逻辑层得以在稍微简单的表示下描述了整个数据库的结构。

视图层

最高的抽象层次，只描述了整个数据库的某个部分。尽管在逻辑层使用了比较简单的结构，但是因为一个大型系统具有复杂和多样性，仍然很难表示。而数据库系统的很多用户并不关心全部的数据库结构，此时通过视图层看到用户希望得到的数据就显得方便高效。

我们通过一个例子更加深刻的描述三个抽象层：

create table table_name    
(name char(8),  
age int(3), 
address varchar(20));

上面的这段代码是用SQL语句创建一个张表，即使你看不懂SQL语句也没关系，因为这里只是以这件事为例来表述三个层次。
这张表中定义了很多个字段，当我们把数据按照这个规则存放到数据库中时，真正的数据可能被存放在一串连续的硬盘存储块中，这种计算机、系统级别的数据值存放属于物理层，从最底层描述了数据的存放位置，但是我们并不需要太多关系数据到底存放在内存还是磁盘还是高速缓存中，因为我们只需要得到获取数据的方式即可，物理层的存放对我们操作数据库意义不大。
在逻辑层上，每个这样字段和表通过定义的类型进行描述，正如前面的代码段所示。在逻辑层上同时还定义了这些记录类型的相关关系。程序的设计人员正是在逻辑层上用某种语言进行工作。数据库管理员也常常在这个抽象层次上工作。
如果我们只想要普通用户看到所有人的年龄，而不告诉他们姓名和地址。那么我们可以取出其中的age字段作为视图发送给用户，视图层只是展示一个数据库中的某个部分。这样可以确保安全性机制。

数据库结构基础——数据模型

---

数据库是一种操作数据的概念，真正能把这种概念付诸实现的是数据库结构的基础——数据模型（data model）。数据模型是指一个描述数据，数据联系，数据语义以及一致性约束的概念的工具的集合。仅仅了解SQL语法就认为自己精通了数据库，这是完全不正确的想法。事实上，SQL语法所代表的关系模型只是数据库中的一种数据模型。到目前为止，我们熟悉的数据模型一共可以被划分为下面四类：

关系模型 relation model

关系模型用表的集合来表示数据和数据之间的联系。每个表有很多个列，每个列有唯一的列名。关系模型是基于记录的模型的一种。基于记录的模型的名称的由来是因为数据库是由若干个固定格式的记录来构成的。每个记录类型定义了固定数目的字段。关系数据模型是使用最广范的数据模型，当今大量的数据库系统都是基于这种关系模型。

实体—联系模型 entity-relationship model

E-R模型是基于对现实实现的一种认识，通过一些实体和实体之间的连线（联系）来表示事物之间的关系。实体是现实世界中可区别于其他对象的一件“事情”或者一个“物体”。实体-联系模型被广泛用于数据库设计。

基于对象的数据模型 object-based data model

面向对象的程序设计，比如c++，c#，java已经成为主导的软件开发方法。这导致面向对象的数据模型飞速发展。面向对象数据模型可以看成是E-R模型增加了封装、方法和对象表示等概念后的扩展。这类模型中比较出名的是“对象-关系模型”。

半结构化数据模型 semistructured data model

半结构化数据模型允许那些相同类型的数据项含有不同的属性集的数据定义。这和早先提到的数据模型形成了对比。在半结构化数据模型发展中，可扩展标记语言（eXtensible Markup Language，XML）被广泛的用来表示半结构化数据。