|
|
51CTO旗下网站
|
|
移动端

前言

《视图更新与关系数据库理论》本书详细介绍了数据库架构的设计和实现,同时讨论了视图更新及关系数据库理论。本节为前言。

作者:田远帆 译来源:人民邮电出版社|2018-01-25 17:03

前言

本书是这个系列的第3本书,它的两位“前辈”是:

《SQL and Relational Theory: How to Write Accurate SQL Code》(第2版)

《Database Design and Relational Theory: Normal Forms and All That Jazz》

以上两本书于2012年由O’Reilly出版发行。第1本书的目标读者是所有种类数据库的从业人员,书中解释了关系理论的基本原理,以及以此为基础如何将SQL当作一个关系型数据库使用(在那本书中我使用的一条准则是“关系化地使用SQL”)。第2本书则针对性强一些,它瞄准的读者群是那些对数据库设计感兴趣的行业专家,书中解释了关系型数据库设计的一些理论,并展示了为什么这些理论如此重要。而第3本书,也就是本书,则针对性更强。本书专注于对一个非常关键的问题的研究,而这个问题则涉及关系型数据库应该如何运行(与目前大部分商业SQL数据库系统的运行表现恰恰相反)这一核心内容。这个问题就是“更新理论”。这个理论正如本书的题目显示的那样,适用于视图的更新——不论是在一般情况下,还是特定情况下。同时,本理论也适用于“基础数据”的更新。

注意:尽管我的理论包含上面的最后一句话,但我还是决定在本书的题目中更加强调对视图的更新,因为据我观察,一般数据库从业者相信他们自己能够理解对于基础数据为对象的更新是如何运作的,而一旦对象变成视图,他们的典型反应就是极度怀疑无论使用什么办法,对视图的更新能否真的实现。其实我一直很奇怪,关于视图更新的讨论居然曾经是并且依旧是一个有争议性的话题,当然这也是最初让我决定撰写这本书的一个重要原因。

顺带说一句,关于前两本书,我要对本书中大量引用它们(特别是第1本)而表示歉意。目前,本书中大部分引用的其他出版物都会给出全名,例如下面的例子。

David McGoveran:“Accessing and Updating Views and Relations in a Relational Database”美国,专利号7263512(2007年8月28日)

不过从现在开始,当我提到之前出版的著作时会使用简称,即《SQL and Relational Theory》和《Database Design and Relational Theory》。

作者注:我说过我会用全名引用其他的著作,不过其实也没有多少能引用的。虽然大量关于视图更新的论文、著作或者其他文章在最近30年内层出不穷,但它们中大多数,包括David McGoveran发表的某些例外的特定著作,所主张的论调和本书所体现的论点大相径庭(请参看前言后面部分关于这一点的讨论)。因此大多数时候,我都觉得不适合引用这些著作,除了偶尔因需要提及一下。如果你有兴趣详细地了解一下这些“其他的论调”,那么可以在《An Introduction to Database Systems》(第8版,Addison-Wesley,2004)的第10章中找到一个关于这些书籍名称的简短列表。

在这里我需要强调的是本书假定你们完全了解《SQL and Relational Theory》所讨论的内容。举例来说,我认为你们理应知道什么是关系,什么是属性,什么是数组,所以,我不会因为未对这些基础名词做提前解释而道歉。本书的目标读者是数据库相关专业人士,而专业人士应该对我之前的书所包含的这些基础知识很熟悉才对。为了使本书内容更加独立,我会在第2章“技术背景”中对前面的书的相关部分做一个简短的回顾。同时我也会在第3章“视图概念:近距离观察”中给出一个关于什么是视图以及它们应该如何运作的详细综述。

本书的目标读者

我的目标读者群是数据库相关专业人士,进一步说也可以是所有对关系模型、关系型技术或者关系型系统感兴趣的人。如前所述,对《SQL and Relational Theory》熟悉的话会对阅读本书有很大帮助,不过我相信本书无论对关系理论整体而言,还是对视图更新具体来讲,都会有新鲜的见解。而且,我认为值得指出的是,我很有可能可以利用这里面的一些想法在没有数据库管理系统(DBMS) [1]支持的情况下来指导一个“自助式”的实施(针对视图更新)。但在这里其实我真心希望数据库管理系统工程师们能够看到这本书,并由此能在他们自己的产品中提供对视图更新的支持。注意:我同时也想提一下,我会举行一场基于书中内容的现场研讨会。想了解更多内容,请访问下面网址:www.justsql.co.uk/chris_date/chris_date.htm

本书的结构

如之前所说,我假设你知道什么是关系、属性、数组。更进一步来讲,我假设你也至少大体知道什么是视图。视图最初被讨论(当时并不用“视图”这个名字)是在Codd的第一篇关于关系模型的论文中:

E.F.Codd: “Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks,” IBM 研究报告 RJ599(1969年8月19日)

现在,正如Codd自己在这篇论文中所预见的,支持视图最主要的理由,是原则上可以通过它们来达成逻辑数据独立这个重要目标(逻辑数据独立指的是能够改变一个数据库的逻辑,而不需要相应改变用户的使用习惯的能力,由此可以保护针对既有用户培训、既有应用以及其他部分的投入。在第3章我们会有更深入的讨论)。换句话说,视图存在的主要理由,严格来讲就是为了实现逻辑数据独立这个目标。但如果我们想在实际中实现它,而不仅仅是停留在原则上,那么视图必须是可更新的。

所以针对视图的更新是一个很重要的问题。由此重要性导致的结果是,无论是对商业领域,还是研究领域而言,视图已经成为大家关注的焦点有一段时间了(至少有35年左右),而且一些不同的方案已经被提出,有些甚至被实施过。但可惜的是,所有这些方案都没能对视图更新给出一个令人满意的解决办法(这里我要强调,不仅仅是我,其他作者也这么认为)。我们举例来说,在当今主流的SQL产品中,视图更新机制具有以下两个典型的缺陷。

不完整,也就是说,它们没能使理论上应该能够更新的视图全都实现更新。

不正确,也就是说,即使对那些能够实现更新的视图,它们的实施方式也不对路,至少在某些情况下是这样的。

(再次说明,第3章中有关于这些问题的深度讨论。)至于那些研究文献,我觉得它们通常都会忽视一些重要因素,这些因素对于一个系统化的、综合性的以及正确的解决方案至关重要。与前面的例子不同,我相信在本书中将要详细讲解的,恰恰就是一个“系统化的、综合性的以及正确的” 解决方案。同时我也相信(在这里我必须说明,我本身并不是一名工程师),这个解决方案可以被整合进关系型数据库管理系统,并给系统架构带来适度的概念化扩展。

作者注:请注意我很谨慎地提到“关系型数据库管理系统”。在后面你将会看到,我提出的这个解决方案非常依赖对完整性约束的声明(当然,这需要数据库管理系统的强制执行能力来做保障)。从我的角度来说,我认为这些能力是构成一个真正的关系型系统的必要条件。不过相信大家都知道,当今绝大部分的SQL产品在这个环节都有缺陷。现在我正式介绍一下本书的大体结构。

第1章给出了一个抛砖引玉的例子,表明了在大家熟知的简单条件下(其实就是SQL的条件下)如何看待视图更新,在后面的章节中我们还会有更具体的说明。具体来说,它证明了“更新就是更新”,无论被更新的是视图还是基础数据。这就是为什么我之前说这本书所涉及的问题应该被称为“更新理论”(一种既适用于视图,同时又适用于基础数据的理论)的原因。

接下来如前所述,第2章对关系理论的相关内容做了简要的回顾。其中特别强调了数据库的本质就是“一个真正的变量”,而它这个特质也恰恰让它成为对所有更新操作都适合的目标对象。

第3章对视图概念和相关内容做了更具体的描述。当然我前面说过我假定你了解视图的基本概念,但这一章包含了你可能不太熟悉的内容,而这些内容对于正确理解后面的内容至关重要。

第4~13章会针对各种各样你所熟悉(有的内容可能不那么熟悉)的关系操作逐个进行讨论——约束、投影、连接等。特别是在第4章,对于约束视图,我还介绍了很多额外的基础内容(其实,这几章也可以看作是第3章的一个继续)。第4章同时也给出了后面9章如何展开的计划。

第14章研究了合并操作(例如,更新一个由两个约束组成的连接,或者更新一个由两个连接组成的合并都需要什么)的问题,这个问题引发了一些相当有趣亦或出人意料的情况。

在整本书的讨论中,大家可能会对其中一些方案所提到的问题或内容不明确或产生混淆,最后在第15章我将为大家对这些不明确和混淆做出解释说明。

书后面还有两个附录。附录A的内容是关于所有重要的“关系赋值”操作的细节。附录B则收录了在本书主体中所使用或提到的大量关系操作的详细定义。

注意:目前给大家描述的大纲其实已经足以说明本书是按照循序渐进的方式来撰写的,我本人也强烈建议大家按照写作顺序来阅读本书。

技术性注释

还有几点我要在这里提前说明。首先请注意,在本书中我按照惯例使用一般术语,用小写字母表示的“更新”是代表包含“INSERT”“DELETE”以及“UPDATE”等所有操作语句的总称(正如我刚刚所提到的“所有重要的关系赋值操作”,详见第2章)。如果想表达“UPDATE”这个操作语句,我会全部使用大写字母表示,至于“INSERT”和“DELETE”操作就不会引起混淆。不过一味地使用大写会显得有些烦人,尤其是当它们作为修饰语使用的时候,例如“INSERT规则”(“插入规则”?)。所以,我决定在本书中两种格式一起使用,我会根据前后语境自我发挥(我也不会装作在这方面前后有多么一致)。

第二点,请注意我使用“SQL”来表示SQL语言的标准版,而不是什么专有的术语(另有明确说明的除外)。特别是按照标准读音“SQL”应该念为“ess cue ell”,而不是“sequel”(因为现在很多地方都按后者来发音),所以我对“一个SQL表”的书写会按照标准读音的写法。注意:SQL标准版随着时间推移出现了数个版本,在本书写作的时候最新版本是SQL:2011。以下是完整的版本信息。

国际标准化组织(ISO):Database Language SQL, Document ISO/IEC 9075:2011 (2011)

第三点也是最后一点,我需要对我所谓的“用户”做一下说明,特别是我需要解释一下经常用到的一些短语,如“用户看到的”或者“用户对数据库的感觉”。总体来说,你可以把“用户”这个词理解为一个交互用户 [2]、一个应用程序开发人员或者两者都是,请根据上下文理解。至于“用户看到的”和类似的短语中的用户,我指的是那些并未与整个数据库交互而更多的是与一些子集交互的用户,根据“子模式”定义。另外,根据视图的机制,子集可以并且经常参与到一些逻辑重建中。实际上,我们可以(至少我会这么做)简单而不失全面地假设,子集是由视图组成的,即使一些由基本数据转换而来的视图实际上跟导出它们的基本数据等价。当然,对于这个子集的用户来说,视图的集合就是数据库本身!换句话说,“数据库”在某种意义上来说是个相对项。所以,至少是为了本书使用,我们可以稍微有点随意但有效地把数据库定义为一个给定的数据,例如给定的基本数据的集合,或者是这个集合下的一些具体的,很可能是经过重构的子集。注意:当我在这里说到“随意”的时候,我考虑到的是这个数据库不仅仅只有数据,如相应的完整性约束也需要被考虑进去,我们在第2章和第3章将会见到。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目      下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

C#2005编程进阶与参考手册

本书非常详细而全面地介绍了C#程序设计语言。本书不是“5分钟学习C#”式的手册,也不是那种教您“照猫画虎”地创建一些与您的实际工作需要...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊