本节书摘来自异步社区出版社《你不可不知的关系数据库理论》一书中的第1章，第1.2节，作者：【美】C.J.Date，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.2 什么是数据库管理系统
从现在开始，每当我提到“给出一个典型的数据库”，如图1.1所示，意味着给出一个如用户想象的那样的数据库（有时称之为逻辑数据库［logical database］）。逻辑数据库与物理数据库是相对而言的，物理数据库是被数据库管理系统（DBMS，Database Management System）所理解的（即它是实际存储在计算机中的数据）。因此，需要进一步强调的是，这里所谓的逻辑和物理数据库并不是两个完全不同的事情，相反，它们是从不同视角来看待的同一事情，如图1.2所示。
从图1.2可以看出，DBMS（即管理数据库的软件）作为系统逻辑层和物理层之间的一个媒介，可以有效地提供以下服务：用户向数据库发出请求的格式可以依据逻辑数据库的形式来标识，然后依据对应的物理数据库，DBMS会一一实现这些请求。
DBMS提供的一个通用功能就是向用户隐藏系统物理级别的实现细节（大多数的程序设计语言也是在物理级别向用户隐藏实现细节），换句话说，DBMS给用户提供了一个更抽象的数据库概念，相比物理数据库级别而言，这种方式会更友好。例如：以实际存储在系统中的方式来表示数据库概念3。
现在我们知道了DBMS是一个复杂的软件，它包含很多构件。但是有一个构件我现在必须提一下，因为它是这本书的主题，它就是优化器（optimizer）。优化器是DBMS的构件之一，其主要职责是决定如何正确执行用户的请求。大多数请求（实际上几乎是所有的请求）都能够通过各种不同的方法来实现。而且，这些不同的方法一般在性能特点上有很大区别。特别是在执行时间上它们确实有很大区别，可以从几微秒到几天。因而，对于优化器来说，选择一个“好”方法去实现特定的请求是非常重要的，这里的“好”实际上是指好的性能（good performance）。
前文中存在一个直接而且重要的暗示就是假设优化器能很好地发挥它的作用，用户根本不必考虑性能的问题。但有一个事实我必须在这里声明一下（这是突然在我脑海中闪现的一个想法），记录一直是关系模型中的一个主要目标，性能问题应该是系统所担忧的，而不是用户应该关心的。从某种程度上来说，如果这个目标没有达到，就说明系统是失败的（或者确切地说，至少是不成功的）。
1.2.1 数据依赖
逻辑数据库和物理数据库是有区别的，要严格进行区分，但这个事实也允许我们实现一个重要的目标，就是数据独立性（data independence）。数据独立性（顺便说一下，这其实不是一个很恰当的数据，但似乎我们也只能坚持使用它）意味着我们可以随意改变数据在系统中的存储和访问方式，而对于用户看到的数据库却不需要做任何相应的变化。其实我们可能想改变数据库存储或访问方式的原因就是性能（performance）。我们做这样的改变而不用去修改用户看到的数据库，这意味着已存在的一些应用程序、查询等都可以在变化之后仍然按照原来的方式工作。因此，非常重要的一点是数据独立性可以保护已存在的资产，这些资产可以存在于已有的应用程序、用户培训、数据库设计或者其他事情中。
1.2.2 DBMS的其他功能
再重复一下，DBMS是逻辑数据库和物理数据库之间的一个媒介。换句话说，它支持通向数据库的接口（interface）（在本书中的其他地方，我一直不加限制地使用数据库［database］来专门表示逻辑数据库，除非在上下文环境中另有要求）。因此，DBMS 的主要职责包括：（a）负责接收用户请求，这些请求可以是查询或者修改，具体形式要根据逻辑数据库的要求来决定；（b）通过解释或执行的方式对这些请求做出响应，换句话说，就是根据物理数据库的形式来执行这些请求。注意：在极少的情况下4，术语修改（update）一般用来指的是插入新数据、删除或修改已存在的数据等这类请求。
因此，DBMS可以“保护用户已有的数据”（例如，可以保护数据在系统内部真正的存储形式等细节）。我们可以有些得意地说，它保护了用户数据。但是我的真正意思是，它提供了安全性（security）、并发性（concurrency）、完整性（integrity）和恢复等（recovery）控制。简要说明如下。
安全控制：用来保证用户请求的合法性。即有疑问的用户正在请求一个操作，允许他或她来操作有权利访问的数据。例如，在供应商和零件数据库中，某些用户可能不会被允许查看供应商状态数据；某些用户可能根本就不允许查看供应商表；某些用户可以被允许查看伦敦的供应商，但不允许查看其他城市的供应商；某些用户可以被允许检索供应商信息但不允许修改，等等。简而言之，必须限制用户执行那些他们允许被执行的操作。注意：安全当然是很重要的，但对安全控制的更多细节介绍已经超出了本书的范围（在第7章中将给出一个简短的描述）。
并发控制：就是要处理同一时间可能会有多个用户使用同一数据库的问题。假设你要查询数据库中是否有供应商S1供应的商品，得到肯定回答后继续提问供应的零件数量平均值是多少，当被告知根本没有这样的供应关系时，这是一个让人很讨厌的事情。推测一下，可能是因为一些其他用户删除了这些数据。并发控制的目的就是要处理这样的问题，我将在本书的第二部分对其进行详细讲解。
完整性控制：就是要保证数据库中的数据是正确的（因为在某种程度上提供这样的保证是可能的）。例如，要向供应关系的表中插入一条供应商S6的供应关系记录，如果供应商表中没有S6供应商，则这个请求一定会被拒绝。同样，要把供应商S1的状态值修改为200时，如果这个状态值规定不能超过100，则这个请求也会被拒绝。这些例子还不足以说明完整性控制是相当重要的，我将在第3章和第6章中对其进行详细讲解（在第13章也会涉及完整性控制）。
恢复控制：就是假设数据库从不会忘记任何事情，它会一直记得所有的事情。也就是说，一旦数据被插入到数据库中，就再也不会被删除了（除非用户有特别明确的要求），即使发生一些失败的操作，如系统被破坏或者磁盘被破坏。我将在本书的第二部分对其进行讲解。
最后，关于DBMS，我还要说一件事情。从我前面讲解的每一件事情中可以看出，有一点是相当清楚的，那就是数据库之间的逻辑结构是有区别的，它是存储数据的仓库，而DBMS是管理这个仓库的软件。不幸的是，在数据库领域使用术语数据库（database）表示DBMS已经很普遍了5，但我想强调的是，这个术语已经非常非常普通了，在本书中我不会再采用此种说法。因为如果要把DBMS称为数据库，那真正的数据库又是什么呢，这是个问题。
