《Expert MySQL》翻译——chapter2.解剖数据库系统(3)

接上文

MySQL是一个关系型数据库系统吗？
    许多数据库专家都会跟你说这个世界上只有极少数的真正的关系型数据库系统。他们同时也会指出你需要的功能在多大程度上能够被数据库系统支持。他们并不会跟你说这个数据库有多符合Codd提出的关系模型。
    从一个纯市场的角度来说，MySQL提供了很多关系型数据库所应当支持的功能。它们包括通过外键使表与表之间建立关系，以及基于关系算法的查询机制，还有在数据库中使用索引和缓存机制等。很明显，MySQL提供的功能还不止这些。
    那么MySQL到底是个关系型数据库吗？呵呵，这就取决于你对关系的定义了。如果你从应用演化的角度上看，MySQL还确实是个正儿八经的关系型数据库。但是呢，如果你严格按照Codd的关系模型去对比的话，你就会发现MySQL并没有完全实现Codd提出的模型中的所有功能。而且一些其他的关系型数据库也并没有真正完全地实现了Codd提出的关系模型。

关系型数据库系统架构
关系型数据库是个复杂的系统，它由许多组件构成，这些组件是为处理所有有关存储和检索所必须的功能而特别设计的。一个关系型数据库系统的架构经常被拿来和操作系统的架构做比较。你想想关系型数据库的使用场合，尤其是作为服务端向客户端提供服务的时候，你会发现它和普通的操作系统有很多相同之处。比如说，在多客户端的场合下，就要求系统必须支持多请求处理，这些请求可能导致系统对同一条数据同时做读写操作，也有可能是针对同一区域（也就是表）中的数据同时做读写操作。因此，关系型数据库必须支持并发才能高效运作。类似的，它也需要支持每一个客户端对数据的高速访问。这都需要合理地使用文件缓存技术来保证最近或经常使用的数据能够驻留内存来实现高效访问。并发技术也需要类似于操作系统中的虚拟内存机制来在数据库中对内存进行管理。其他类似的方面也包括提供操作系统那样的网络连接支持和针对提高查询语句执行效率的优化算法。
我会从用户使用查询语句来检索数据的角度开始我们的数据库架构探索之路。接下来的小节你可以挑你感兴趣的部分看，如果你对某部分小节涉及的技术很熟悉，那就跳过。不过我还是希望你能够全部都看一轮，这些小节提供了一个典型关系型数据库是如何架构的细节。
客户端应用
大部分关系型数据库的客户端应用都是可独立执行的程序，他们通过某些方式（比如说基于套接字的网络连接，或者管道等）来与数据库交流。有些情况是直接在程序中访问数据库的，这时候数据库就属于这个客户端应用的一部分。在这种情况下，我们称之为嵌入式数据库。第六章介绍了更多有关嵌入式数据库的信息。
对于哪些通过某些渠道来与数据库交换信息的应用，大部分链接都建立在数据库连接器（database connectors）提供的协议上。大部分数据库连接器都是基于开放数据库互连（Open DataBase Connectivity,ODBC）模型的。MySQL也支持基于java和.NET的数据库互连。大部分基于开放数据库互连模型的数据库连接器也支持通过网络协议来连接数据库。

ODBC是什么？
    ODBC是一种应用程序接口(API)，ODBC被设计用于解析SQL语句来使服务端去检索数据，并且也将服务端返回的数据展现给客户端。一个ODBC的实现包括通过使用API调用ODBC库函数来扮演中间人的功能，以及一个针对特定数据库设计的数据库驱动。我们从字面上可以将ODBC理解成一个提供用户访问，应用程序接口以及数据库驱动的一个连接器。因此，一个ODBC连接器扮演了服务端和客户端之间的翻译人的角色。ODBC差不多已经成为了所有关系型数据库的标准，并且现在也有各种支持一大堆不同类型的客户端和不同类型的服务端的连接器。

当我们提到客户端应用时，我们只是普遍地假设它仅仅是从服务器检索数据或者让服务器存储数据的程序。但是，我们用来设置/维护服务器的程序也算客户端程序。大部分这些程序跟数据库应用使用相同的交流渠道来连接服务器。有些使用ODBC连接器，也有些使用其基于J***A的变体（JDBC）来连接数据库。其中有些用来管理服务器的特殊协议是基于一些特殊的管理需求而设计的。其他的一些比如说phpMyAdmin就使用端口或者套接字。
先不管他们怎么实现的，总之客户端应用通过给服务端发送命令来检索这些命令指向的数据，并且翻译和处理这些数据之后再返回给用户。标准的命令语句就是SQL。客户端通过使用SQL命令，经过连接器的翻译，以及连接器维护的基于数据库驱动的网络链接来传达给数据库并从中获得数据。图2-1描述了这一流程。




查询接口
查询语言，比如说SQL，是一种可被用来向数据库提交请求的语言（因为它有自己的语法和语义）。事实上，在数据库中使用SQL被认为是数据库能够成功的主要原因之一。查询语言通过一些语句集合奠定了能够方便使用数据库的基础。数据描述语言（Data Definition Language， DDL）被用来创建和管理数据库，它的任务包括改变表结构，定义索引，和管理约束。数据操作语言（Data Manipulation Language， DML）可被用来查询和更新数据库中的数据，它的任务包括添加，查询，和修改数据。这两种语言集合构成了数据库能够支持的主要命令。
SQL命令使用特殊的语法。下面显示的是SQL中SELECT语句的语法。

SELECT [DISTINCT] listofcolumns
FROM listoftables
[WHERE expression (predicates in CNF)]
[GROUP BY listofcolumns]
[H***ING expression]
[ORDER BY listof columns];

这条指令的语义是这样：

　　1.在FROM语句中构成表的笛卡尔积，从而形成了那些在其他语句中所需要的参照。(Form the Cartesian product of the tables in the FROM clause, thus forming a projection of only those references that appear in other clauses.)

　　2.如果WHERE语句存在的话，使用这些表达式来给出参照表。(If a WHERE clause exists, apply all expressions for the given tables referenced.)

　　3.如果GROUP BY语句存在的话，根据GROUP BY语句提供的属性来给查询结果分组。

　　4.如果H***ING语句存在的话，针对这组数据进行过滤。

　　5.如果ORDER BY语句存在的话，就对查询结果进行排序。

　　6.如果DISTINCT语句存在的话，就从查询结果中去除相同的元素。

上面的代码样例展示了大部分SQL命令的元素，所有的这种命令都有其必需的部分，和有些基于关键字的可选部分。
一旦这些命令被传送到了服务器，数据库服务器立马就开始解析并执行这些命令。从这点上看，查询语句之所以被简单地被称为查询，是因为它将问题描述提交给服务器，然后服务器基于这些描述来返回一个答案。在接下来的小节中，我们假设“查询”就类似于SELECT语句这样，是有数据返回的。事实上，任何查询不管是数据操作还是数据定义，都是跟上面的流程一样地去执行。从这一点上讲，我们可以认为是服务端自己执行了这些流程。流程的第一步就是去解析客户端需要的是什么，也就是说，查询语句需要从语法上分析这些语句，并且将语句分割成能够独立执行的小部分。

（未完待续）