1.3 什么是关系型DBMS
现在我们已经知道了什么是DBMS，但什么是关系型DBMS呢？当然，首先它是一个DBMS，它要提供本章介绍的DBMS具备的所有功能：数据存储、查询、修改、恢复控制、并发控制、安全控制和完整性控制，以及本书中没有讨论的其他功能。但是第二点要注意的是，它又是关系型的，这就意味着用户接口在真正实现时必须是关系模型。换句话说，关系模型被看作是DBMS中实现用户接口的一种方法。
在继续讲解之前，还要强调一点，这个方法（即关系模型）其实很简单！关系模型的这些方法并不是紧身衣，相反，它们是一种规则，对用户来说可以是生活更加容易的一种规则（在某些方面，对系统来说也更简单，但是重点是针对用户的）。现在，虽然这种方法有时看上去稍复杂些，但最重要的是，关系模型是很正规的。既然正规就需要有正规的术语，正规的术语有时会令人却步。但是术语中的这些定义实际上相当简单（别忘了，供应商和零件数据库就相当容易理解，不是吗？）。事实上，我们谈论的这些定义要比过去使用的类似定义简单得多，就像IMS和IDMS这样的前期关系系统或非关系系统6。
再重复一下，关系型数据库管理系统是支持真正实现关系模型的用户接口的DBMS。对用户而言，其含义如下。
数据看上去是关系型的。
可以使用关系运算符（如，采用关系运算来处理数据）作为检索请求和修改请求的基础。举个简单的例子，如：
S WHERE CITY = 'London'
这个表达式表示查询供货地点在London的供应商，它使用了关系型的“限定”运算符。规范的表达就是，它请求在表S中查询地点在London的供应商集合。
然后，在本书的第一部分中，我们将仔细看看“数据看上去是关系型的”的真正含义，我们也要检验各种关系运算符，看它们是否能起到作用。然后，要注意的是，这种解释也不一定是非常详尽的（这些主题的详尽解释可以参照 SQL and Relational Theory），但是就现状来说，它是非常综合的，也是非常准确的。
不幸的是，这里还有一个问题。为了说明这些定义，我们还要讨论一些问题，即我需要明确给出一些编码实例。为了表达这些实例，我需要采用正式的语言来描述，但是关系模型没有规定任何一种这样的语言，而且它是在很高的抽象级别上定义的，原则上是能够来具体实现任何不同的语法形式。现在，一种标准的、具体的语言确实存在了，即SQL，目前在市场上它也或多或少地获得了所有主流数据库产品的支持。然而就像在前言中提到的，SQL是有很多缺点的，比如它的复杂性、不完整性、难掌握，在很多方面还容易造成误导。因此我计划编写本书的目的如下。
第一，我会在根本不使用SQL的情况下来解释关系模型（见本书的第一部分）。作为替代，我使用了一种叫做Tutorial D的语言，它是专门为此目的设计的一种语言。注意：我相信Tutorial D是一种可以自我说明的语言。然而，如果需要更容易理解这种表述的话，可以参考Databases, Types, and the Relational Model: The Third Manifesto（第三版，Addison- Wesley, 2007）7。
第二，我将展示关系模型的思想是如何具体用SQL实现的（见本书的第三部分），因此可以肯定的是，我并不是要在本书中全面介绍SQL语言，只要够用即可，即我在前言中提到的语言的核心特征。
（第二部分是对前言中提到的问题所做的简短说明）注意：也许我应该声明一下，由于前面提到的计划，接下来进行的工作可能与目前市场上的大部分书籍或报告不太一样，所以我打算叫做“关系数据库的介绍”。
在结束本节前，再说明一点。你也许知道，但也许不知道（但是我希望你知道）：关系模型最早是由E.F.Codd发明的，当时他还是IBM的一名研究人员（E代表Edgar，F代表Frank，但他一直喜欢用首字母签名，作为他的朋友，我也感到很骄傲）。1968年末，Codd已经成为了一名数学家，他第一次实现了数学定律可以用来把一些固有的原理用在某一领域中，例如，数据库管理，而在以前这些都是做不到的。他在关系模型上最初产生的一些思想可以在1969年IBM的研究报告中找到（进一步的研究可以参见附录E）。