PostgreSQL从菜鸟到专家系列教程(5)什么是数据库管理系统

数据库管理系统

韦氏在线字典（Merriam-Webster online dictionary，http://www.merriam-webster.com）定义数据库为一个为（通过计算机）高速搜索和检索的而特别组织的大量数据集。

数据库管理系统（database management system，DBMS）通常是一套用来让程序开发人员从繁重的数据存储细节和管理中解脱出来的程序库、应用程序以及工具套件。它还提供了用来搜索和更新记录的能力。多年来，数据库管理系统发展出大量的特点用来解决各种各样特别的数据存储问题。

数据模型

从1960年代到1970年代，开发人员通过很多不同的方法建立数据库来解决重复单元的问题。这些方法从术语上说就是数据库系统模型。IBM在这方面的研究为这些模型提供了大量的基础，这些一直被用到现在。

一个早期的数据库系统设计的主要驱动力是效率。一个是系统效率更高的通用方法是强制使用固定长度的数据库记录。或至少每个记录有固定的元素（每行有固定的列数）。这可以有效的避免重复单元的问题。如果你是一个过程语言的程序员，你早就知道这种情况了，你可以将每个数据库记录读到一个简单的C数据结构中。现实世界中很少有这样的简单的情况，所以我们需要找到一些处理复杂结构的数据的方法。数据库系统设计者通过引入不同类型的数据库实现了这种需求。

层次数据库模型

1960年代晚期IBM的信息管理系统介绍了数据库的层次模型。在这种模型中，把数据记录看成是其他记录的集合以解决重复单元的问题。

该模型可以用来比较描述如何制造一个复杂的产品组成的材料清单。例如，假设一辆车是一个底盘，一个机构，一个发动机，四个轮子组成。这些主要设备都进一步分解。包括一些汽缸发动机，汽缸头，曲轴。这些组件是进一步分解，直到我们得到螺母和螺栓构成的每一个汽车零件。

层次数据库模型到今天一直在使用，包括Software AG公司的适配数据库系统（Adaptable Database System，ADABAS）。

层次数据库系统有能力通过优化数据存储在某些具体问题上更加高效；例如判断哪个汽车使用一个特别的部件。

网状数据库模型

网状模型在数据库中引入了指针。记录可以包含到其他记录的引用。例如，你可以为你公司的每个客户保留一条记录。每个客户随着时间的过去，给你发了很多订单（一个重复单元）。由于数据已经排序，所以客户记录只包含一个到一条订单的指针。每个订单记录包含该特定订单的订单数据，以及到其他订单记录的指针。

回到我们的货币程序，我们可以通过图1-1的样子通过记录结构终止记录。

图1-1 货币程序记录类型

一旦数据被加载，我们使用一个语言用的链表（这里，就是网络模型）来终止该列信息，就像图1-2显示的一样。这里展示的两种不同的记录类型应该分别存储，各自一张表。
当然，为了在存储方面更有效率，在实际上数据库不会一次次重复语言名字，而可能包含一个第三方表用来存储语言名，并且针对语言名给一个标识符（通常是一个小整数），这个标识符用来在其他记录中指出对应的语言项目。它被叫做键。

图1-2 汇率程序数据结构

一个网络模型数据库有一些很强的优势。如果你需要查找关联到某个记录的一种类型的所有的记录（本例中，一个国家的语言），你可以通过开始记录的指针快速找到他们。

当然，这也有一些不足。如果你需要列出讲法语的国家，你需要扫描所有国家的语言链表，这种情况在大数据库中非常慢。这可以通过使用另一个指向语言的指针链表来处理，但这很快就变得相当复杂，而且很明显不能作为一种通用的解决方案，因为你需要预先确定要设计多少指针。编写使用网状模型数据库的程序也非常令人厌恶，因为应用程序通常需要为记录的修改和删除而设置和管理指针。

关系数据库模型

随着1970年E. F. Codd 提出 “一个大型共享数据仓库的数据的关系模型（A Relational Model of Data for Large Shared Data Banks，请阅读http://www.acm.org/classics/nov95/toc.html），数据库管理系统的理论发生了迅猛的发展。这篇革命性的文章介绍了关系的概念以及表格（通过其存储的数据）怎样用于表现现实世界的对象。

现在，一个比驱动最初的数据库设计和性能更值得关注的东西逐渐变得明晰：数据一致性。该模式比任何更多的早期模型更强调数据完整性的关系。参照完整性是指确保数据库中的数据在任何时候都合理，因此，例如，所有的订单都有客户（我们将在12章讨论数据库设计的时候更详细地讨论完整性）。

关系数据库里头的一个表里头的一条记录被认为是一个元组的组合，这是你将看到在PostgreSQL文档的某些部分使用的术语。一个元组是一个有序的组成部分或属性群，他们每一个都有一个定义的类型。

几个重要的规则定义一个关系数据库管理系统（RDBMs）。所有的元组群必须符合同样的模式，也就是它们必须拥有相同数量和类型的组成部分，以下是一个元组集的例子：

{“France”, “FRF”, 6.56}

{“Belgium”, “BEF”, 40.34}

每个元组集都有三个属性：国家名（字符串），货币（字符串）以及汇率（一个浮点数）。在关系数据库中，所有插入这个表的记录都必须使用相同的格式，所以以下的情况是不

允许的：

{“Germany”, “DEM”}

这里的属性太少。

{“Switzerland”, “CHF”, “French”, “German”, “Italian”, “Romansch”}

这里的属性太多。

{1936.27, “ITL”, “Italy”}

这里的属性类型错误（顺序错误）。

此外，对于元组集的表，不应该有重复的元组。这意味着任何正确设计的关系数据库里头的任何表格，不应该有任何重复的行或者记录。这似乎是一个相当苛刻的限制。例如，在一个记录客户的订单的系统里，它似乎不允许相同的客户订相同的产品两次。在下一章，我们会发现有一种简单的方法来解决这种需求，通过添加一个属性。

记录中的每个属性必须是原子的，也就是说，它必须是单独的一块数据，而不是另一条记录或者其他属性的列表。而且，表中的每条记录的相应属性必须相同。技术上来讲，这意味着他们必须来自于相同的值的集合或者域。实际上，它意味着他们必须是一个字符串，一个整数，一个浮点值或其他的数据库系统支持的类型。

用于从一个表中区从其他所有的记录中区分某一条特殊的记录的属性（或属性集）叫做主键。在关系数据库中，每个关系，或者表，必须有一个主键用来使一条记录唯一——也就是从表里的其他记录中区别出来。

最后一条确定一个关系数据库的构造的是参照完整性。就像我们开始说的，这要求数据库中的每一条数据在任何时候都有意义。数据库应用程序员必须确保他们的代码不会破坏数据库的这种完整性。想想我们删除一个客户的时候将发生的事情。如果我们尝试从客户表删除一条客户的信息，我们还需要从订单表删除他所有的记录。否则，我们将留下一些没有有效客户的订单记录。

我们将在后面的章节读到更多的关于关系数据库的理论。到这里，我们足以理解数据库的关系模型是基于针对集合和关系的一些数学概念，以及这种模型上的一些需要数据库系统监视的规则。

查询语言

关系数据库管理系统（RDBMS）诚然提供一些方法用于修改数据，但是它们真正的力量来源于它们有能力允许用户针对存储的数据以查询语句的形式提出问题。不同于很多早期的数据库设计，这些早期数据库经常针对数据需要回答的结果构造问题（查询），关系数据库对于在数据库设计时未知的问题的回答上更加灵活。

Codd关于关系数据库的提案使用以下事实：关系定义数据集，数据集能够被数学方式操作。他建议查询应该使用一个叫谓词演算的理论逻辑的分支，并且查询语言应该是它们的基础。这将使搜索和选择数据集前拥有所未有的能力。现代数据库系统，包括PostgreSQL，在一种富于表现力，易于学习的查询语言后隐藏所有的数学逻辑。

第一个实现的查询语言是QUEL，在1970年代晚期开发的Ingres数据库中使用。使用不同方法另一种查询语言是QBE（Query By Example，通过示例查询）.就在这同时，IBM的研发中心的一个团队开发了SQL（Structured Query Language，结构化查询语言），通常读作“sequel”。

SQL标准和变化

SQL作为一种数据库查询语言的标准已经非常广泛地采用，并定义有一系列的国际标准定义。最通用的定义是在ISO/IEC 9075:1992中，“数据库语言SQL”中。这被简单的称为SQL92。这个标准替代了早期的SQL89标准。最新的SQL标准是ISO/IEC 9075:2003，简称为SQL2003。

当前，大多数关系数据库管理系统遵循SQL92标准，或者ANSI X3.135-1992（在美国登记的标准，只有几页封面不同）。SQL92有三个一致性级别：入门级SQL，动态SQL和完备级。

到目前为止，最常见的一致性级别为入门级SQL。

注：PostgreSQL非常接近SQL92的入门级一致性，只有少量的轻微差异。开发人员保持密切关注有关标准，这使得PostgreSQL在每次发布版本后变得更加兼容标准。

今天，几乎所有有用的数据库系统支持SQL到一定程度。理论上，SQL扮演成一个很好的统一者，因为使用SQL作为数据库接口的数据库应用程序可以被移植到其他数据库，而仅仅需要花费少量的时间和精力。但商业压力决定了数据库厂商刻意制造自己的数据库与其他数据库的区别。由于SQL标准未定义现实世界中必不可少的用于执行数据库管理任务的命令，这导致了SQL的变化。所以，Oracle、SQL Server、PostgreSQL以及其他的数据库管理系统使用的SQL都不尽相同。

SQL命令类型

SQL语言由三种命令组成：
数据操作语言（Data Manipulation Language，DML）：这是在你90%时间内会使用的SQL。这些命令用来在数据库中插入、删除、更新、查询数据。
数据定义语言（Data Definition Language，DDL）：有些命令用来建表、定义关系以及控制数据库的其他结构方面的信息。
数据控制语言（Data Control Language，DCL）：这是一套通常用来控制对数据的访问许可的命令集，例如定义访问权限。很多数据库用户从来不会使用这些命令，因为这通常在大公司使用，而通常情况下会有一个或者多个数据库管理员专门管理数据库，他们的工作之一就是控制访问许可。

 SQL命令简介

在本书中你将碰到大量的SQL。这里，我们将简单看几个例子作为介绍。我们将发现我们不需要担心我们缺少SQL基础知识而无法在这里使用。

以下有一些在数据库建立新表的SQL。以下为建立客户表的例子。
 

这张表需要一个由数据库自动生成的标记作为主键。它的类型是serial，这意味着每当一个客户被添加，一个唯一的customer_id将被按顺序建立。客户的title是一个4字节的文本类型，zipcode有10个字节。其他的属性都是最超不超过定义长度的变长字符串，某些是必须存在的（被标记为not null）。

接下来，我们有一些SQL语句用来填充我们刚才建立的表。它们非常简单：
 

SELECT语句是SQL的心脏。它用来建立一个匹配一组特定规则的记录组（或者记录的属性集）的结果集。这个规则可以是非常复杂的。这些结果集可以用来作为通过UPDATE语句修改或者通过DELETE语句删除的目标。

以下为一些SQL语句示例：
 

这些SELECT语句列出所有的客户，所有客户的订单，并分别计算每个客户造出来的订单。我们将在第二章看到这些SQL语句的结果，并在第四章中学习更多关于SELECT的资料。

注：SQL命令的关键字例如SELECT和INSERT不区分大小写，所以它们可以任意使用大小写。在本书中，为了阅读方便，使用大写。

当你阅读本书的时候，我们将教你大量的，所以当你读完本书的时候，你将熟悉大量的SQL语句并知道怎么使用它们。

 
数据库管理系统的责任

正如我们前面所述，一个数据库管理系统包括构建数据库的一组程序以及使用它们的应用程序。一个数据库管理系统的职责包括以下内容：

建立数据库：有些系统将管理一个大的文件，并在它里面创建一个或多个数据库；其他系统可能使用许多操作系统文件或直接使用裸磁盘分区。用户不必担心这些文件的低层次结构，因为数据库管理系统提供了开发者和用户访问所需要的所有功能。

提供查询和修改能力：一个数据库管理系统将拥有一个请求符合特殊规则数据方法，例如某个客户的所有未完成的订单。在引入SQL标准之前，每个数据库系统查询这种结果的方法都大不相同。

多任务：如果数据库 被多个应用程序使用，或者同时被多个用户访问，数据库管理系统需要确保每个用户的请求被处理而不影响其他的用户。这意味着用户需要在其他人正在写入他需要读取（或者写入）的数据时排队等待。它允许在同一时间有很多并发读取。实际上，不同的数据库系统支持不同基本的多任务，甚至允许可配置的级别，就像我们在第九章讨论的。

维护一个审计线索：一个数据库管理系统将保存一个近段时间内数据库中所有变动的日志。它可以用于调查错误，但其实可能更重要，可以用于在系统故障（例如一个非计划的断电）后重建数据。数据备份和事务的审计线索可以用于在磁盘故障后完全恢复数据库。

管理数据库的安全性：一个数据库管理系统将提供访问控制，因此只有授权的用户可以操作数据库中的数据以及维护数据库本身（的属性，表和索引）的结构。通常情况下，每个数据库都会通过一个可以改变任何东西的超级用户定义不同级别的用户，从可以添加删除数据的用户到只可以读取数据的用户。数据库管理系统架需要有能力添加和删除用户，并指定数据库的哪种功能这个用户可以使用。

维护参照完整性：就像前面所说，很多数据库提供用于维护参照完整性（数据的正确性）的功能。它将在一个查询或者修改会破坏关系模型规则的时候报告一个错误。

本文转自：http://www.mysqlops.com/2012/04/29/postgresql-dbms.html