|
|
|
|
移动端

1.1 可交换性原则

《视图更新与关系数据库理论》本书详细介绍了数据库架构的设计和实现,同时讨论了视图更新及关系数据库理论。本节为大家介绍可交换性原则。

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

技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同探讨小程序电商实战

第1章 抛砖引玉

身教胜于言教。

——Samuel Johnson《Rasselas》(1759)

本书中所涉及的大多数范例都是基于我们耳熟能详的(可别说是老掉牙的)“供应商与零部件”数据库而来的。我为再一次把这个老生常谈的例子拿出来表示歉意,但正如我在其他地方所说,我认为在各种不同的出版物上使用同样的例子对于学习而言是有利无害的。就SQL来说[1],数据库包含3张表,更确切地说,是3张基表,分别称为供应商表S(“suppliers”)、零部件表P(“parts”)和设备供应表SP(“shipments”)。样本值如图1.1所示。

这几张表简要的语义如下。

表S的内容列出了签过合同的供应商。每个供应商有一个唯一的供应商编号SNO、可能不唯一的供应商名字SNAME(尽管图1.1中的样本值恰好是唯一的),以及状态值STATUS和位置CITY。注意:在本书的其余部分,我将把“签过合同的供应商”简称为“供应商”。

表P的内容表示各种各样的零部件。每一种零件都有唯一的零件编号PNO、名称PNAME、重量WEIGHT和用于存储同种类零部件的位置CITY。注意:在本书其余部分,我将把“各种各样的零部件”简称为“零部件”。

表SP的内容表明了供应情况,即显示了哪种零件被哪一家供应商运输或供应。每一次运输都有供应商编号SNO、零件编号PNO以及数量QTY。同时,对于特定的供应商和零件,在某一时期,最多只能有一次运输。并且像这样的供应商编号和零件编号组合对任意一次运输都是唯一的。注意:本书的其余部分,我将假设QTY值总是大于零的。

现在让我们把重心放在表S上。在本章的其余部分,我们基本上不再关注表P和表SP,只在个别地方提及。以下是表S的SQL定义。

  1. CREATE TABLE S  
  2.    ( SNO VARCHAR(5)    NOT NULL ,  
  3.      SNAME VARCHAR(25) NOT NULL ,  
  4.      STATUS INTEGER    NOT NULL ,  
  5.      CITY VARCHAR(20)  NOT NULL ,  
  6.      UNIQUE ( SNO ) ) ; 

如前所述,虽然表S是基表,但我们仍然可以定义任意数量的“基于”这个基表的视图。这里有两个例子——伦敦供应商LS(“London suppliers”)和非伦敦供应商NLS(“non London suppliers”)。

  1. CREATE VIEW LS /* London suppliers */ AS  
  2.    ( SELECT SNO , SNAME , STATUS , CITY  
  3.      FROM S  
  4.      WHERE CITY = ‘London’ ) ;  
  5.  
  6. CREATE VIEW NLS /* non London suppliers */ AS  
  7.    ( SELECT SNO , SNAME , STATUS , CITY  
  8.      FROM S  
  9.      WHERE CITY <> ‘London’ ) ; 

这两个视图的样本值与图1.1基表的对应关系如图1.2所示。

我将在本章中以视图LS和NLS为基础来阐述整个范例,以求抛砖引玉。实际上,我相信视图都是可更新的,这似乎与本领域内的流行说法和最常见的认知格格不入,但在这里我将向大家展示一些关于这个问题基本的理念,以及为什么我会这样想。(不过请注意:在现阶段我只会对这个吸引眼球的想法做必要的说明,详细的探讨我们放到后面的章节再来进行。)

1.1 可交换性原则

到目前为止,表S是基表,LS和NLS是视图。现在仔细观察,你会发现其实我们还可以用另一种方式来看它们,那就是把LS和NLS作为基表,而S作为视图,具体如下所示。

  1. CREATE TABLE LS   
  2.    ( SNO    VARCHAR(5)  NOT NULL ,  
  3.      SNAME  VARCHAR(25) NOT NULL ,  
  4.      STATUS INTEGER NOT NULL ,  
  5.      CITY   VARCHAR(20) NOT NULL ,  
  6.      UNIQUE ( SNO ) ) ;  
  7.  
  8. CREATE TABLE NLS  
  9.    ( SNO VARCHAR(5) NOT NULL ,  
  10.      SNAME VARCHAR(25) NOT NULL ,  
  11.      STATUS INTEGER NOT NULL ,  
  12.      CITY VARCHAR(20) NOT NULL ,  
  13.      UNIQUE ( SNO ) ) ;  
  14.  
  15. CREATE VIEW S AS  
  16.    ( SELECT SNO , SNAME , STATUS , CITY  
  17.      FROM LS  
  18.      UNION  
  19.      SELECT SNO , SNAME , STATUS , CITY  
  20.      FROM NLS ) ; 

为了保证现在这个设计与原先的设计完全等价,我应该声明并且让数据库满足特定的完整性约束,当然其中应该包括针对CITY值的一致性约束,以保证LS中每一个CITY值都是London,NLS中CITY值都不是London。但是现在我们暂时不考虑这些细节,稍后我会对这些问题做更详细的解释。

那么现在,做出上面这个变化所要表明的内容可以概括为:对基表和视图的设定是没有限制的,是可以互换的(至少从正式的角度来看是这样)。换句话说,对于这个例子,我们至少可以用两种方式设计数据库,这两种方式逻辑上不同,但包含的信息是等价的。(这里的等价信息,是指两个设计代表了相同的信息,也就是说对于在一种设计执行的查询,一定有在逻辑上和它等价的查询可以在另一种设计上执行。第3章将详细阐述这个概念。)而“可交换性原则”就是对上面内容的总结。

定义:可交换性原则说明在基表和视图之间一定不能存在不确定的和不必要的区别。换句话说,在用户看来,视图与基表应该看起来感觉是很像的。
关于这个原则,下面几点值得注意。

正如我所阐述的,视图与基表一样,受完整性约束的限制(我们通常认为完整性约束是专门应用于基表的,但是可交换性原则证明这种想法有失偏颇)。

特别要说的是,视图是有键的(我确实应该在视图的定义中包括键的声明。但可惜的是,SQL并不允许这样声明)[2]。同时,视图也可能有外键,而外键也可能引用自视图。

很多SQL产品和SQL标准,提供了某种叫作row ID的特性(在标准中,此特性被称为REF类型和引用值)。如果这个特性只对基表有效,而对视图无效(实际上,这种情况非常有可能发生),那就明显违反了可交换性原则。

最后,也许最重要的是,我们必须能够更新视图,因为如果不能实现更新,那就等于“可交换性原则”内部自相矛盾了。


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

51CTO读书频道二维码


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

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

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

读 书 +更多

The Ruby Way(第二版)中文版

本书采用“如何解决问题”的方式阐述Ruby编程,涵盖了以下内容:Ruby术语和基本原理;数字、字符串等低级数据类型的操作;正则表达式;国际...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊