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

2.6 数据库与数据库变量

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

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

2.6 数据库与数据库变量

这是本章的最后一节。在本节中,我希望你们能注意一个重要的事实,正如关系值与关系变量(relvars)之间有逻辑区别一样,数据库值和数据库变量(dbvars)之间也存在着逻辑差异。下面一段引自《宣言》那本书。

第 1 版的“宣言”将数据库的本质(也就是数据库的值)与数据库变量进行了区分……[同时也]指出未明确定义的词汇“数据库”应该就是明确地代表数据库的值,并介绍了作为“数据库变量”的缩写来使用的词汇“dbvar”。虽然我们依然相信这个区别本身是真实有效的,但随即我们发现其实它与“宣言”所要讲的其他方面内容几乎没什么关系。因此我们决定,为了文章的易读性,还是在文中使用传统的说法。[19]

于是,当我们“更新某些关系变量”(在某个数据库内部)时,实际上我们更新的是相应的数据库变量。(为了表述清晰,在本节的其余部分我都将使用数据库变量这个词。)例如,Tutorial D声明

  1. DELETE ( SP WHERE QTY < 150 ) FROM SP ; 

“更新设备供应关系变量SP”其实是更新了整个供应商-零部件数据库变量——对这个数据库变量的“新的”数据库值和“老的”值基本一样,除了特定的“设备供应”数组被移除了。换句话说,有时候我们会说一个数据库“包含变量”,即相应的关系变量,其实这种说法很笼统,而且很不正式。更加正式的并且更准确的描述方式应该是这样的:

数据库变量就是数组变量。

数组变量对该数据库变量中的每一个关系变量都拥有一个唯一的属性(并且没有其他属性),并且每个属性都有关系值。我们举例来说,在供应商-零部件数据库中,我们可以将整个数据库变量想象成一个数组变量(也可以用“tuplevar”表示),数组类型如下:

  1. TUPLE { S RELATION { SNO CHAR , SNAME CHAR ,  
  2.                      STATUS INTEGER, CITY CHAR } ,  
  3.         P RELATION { PNO CHAR , PNAME CHAR ,  
  4.                      COLOR CHAR , WEIGHT RATIONAL , CITY CHAR } ,  
  5.         SP RELATION { SNO CHAR , PNO CHAR , QTY INTEGER } } 

让我们暂时称供应商-零部件数据库变量(或者也可以叫它数组变量)为SPDB。[20]那么上面我们刚刚看到过的DELETE声明可以作为下面的“数据库”(以及数组)赋值。

  1. SPDB :TUPLE { S ( S FROM SPDB ) ,  
  2.                 P ( P FROM SPDB ) ,   
  3.                 SP ( ( SP FROM SPDB ) WHERE NOT ( QTY < 150 ) ) } ; 

解释说明:这个赋值右侧的表达式表示一个数组拥有3个属性分别叫作S、P以及SP,每一个属性都拥有关系值。[21]在数组内,属性S的值就是当前关系变量S的值,属性P的值就是当前关系变量P的值,而属性SP的值则是在当前关系变量SP的值的基础上,减去那些数量小于150的数组。

我们来看另一个例子,这里我们再次使用“双删除(DELETE)”,我在本章早些时候介绍多重赋值概念的时候曾经使用过。

  1. DELETE ( S WHERE SNO = 'S1' ) FROM S ,  
  2. DELETE ( SP WHERE SNO = 'S1' ) FROM SP ; 

现在我们观察这个关系赋值,很明显是个多重赋值,会发现它逻辑上等价于下面的“单一”数据库(以及数组)赋值。

  1. SPDB :TUPLE { S   ( ( S FROM SPDB ) WHERE NOT ( SNO = 'S1' ) ,  
  2.                 P   ( P FROM SPDB ) ,  
  3.                 SP  ( ( SP FROM SPDB ) WHERE NOT ( SNO = 'S1' ) ) } ; 

换句话说,目标变量全部都是同一个数据库(或者说同一个数据库变量)中的关系变量,多重赋值其实仅仅就是一个语法工具,它可以让我们将逻辑上的“数据库”赋值表达成一个一系列独立“关系”赋值的组合(请参看下面关于此点更多的讨论)。而一个“单一”的关系赋值,例如由只针对一个单独的数据库变量进行的一个单独的赋值所组成的“多重”赋值——仅仅是个特例。从根本上来说,事实上目前对数据库更新来讲,数据库变量是唯一真正的变量。这就是说,数据库更新其实“总是”对某些数据库变量进行更新,而对单一一个数据库关系变量的更新仅仅是特例而已。

根据上面所有的内容,如果目标关系变量是一个数据库关系变量(就是说,如果这个目标关系变量是某个数据库中的关系变量),那么即使一个“单一”关系赋值其实也是一个数据库赋值。当然,这个数据库赋值像所有的赋值一样,都必须遵循“赋值原则”,并且正由于它是一个数据库赋值,它也同样需要遵循“黄金法则”。

我们前面讲到的这些想法太重要了,它值得我们再次复习一遍,只是说法有轻微的不同。首先,数据库变量是数组变量,数据库(也就是在给定的时间,给定的数据库变量所具有的值)是所有属性都有关系值的数组。第二,给定一个关系赋值如下面格式。

  1. :rx 

(这里R是一个关系变量参考量,从语法上讲就是一个关系变量的名称,指出了一些数据库关系变量,而rx是一个关系表达式,表示关系r与R具有相同类型)这个关系变量参考量R其实是一个“伪变量”参考量(请立刻参看本段下面的注解)。换句话说,关系赋值其实是针对相对应数据库变量(再次重申它就是数组变量)的一个部分进行“替换”的简称化表达方式。因此我们推断出“关系变量”(至少是在数据库中的关系变量)并不是真正的变量,它们只是一些让人觉得很便利的虚构的变量,能够制造出这种假象:数据库或数据库变量可以一点一点地、一个关系变量一个关系变量地被更新。我们进一步可以推断出,在某种意义上,“关系赋值”(不管是不是多重的)也同样是个方便的假象,具体来说就是它是一个虚拟操作,让我们感觉好像可以通过一系列针对这个数据库内的单独的关系变量的更新,来实现对数据库变量的更新。[22]

关于伪变量的注解:从本质上讲,伪变量是这样一个概念,或者是这个概念的象征性的名字,它看起来像是个可操作的表达式,但不同的是它并不表示任何值;相反地,它出现在某些赋值中的目标位置,来表示“变量的一部分”。我们举个例子,令X为一个CHAR类型的变量,并令X目前的值是“antimony”。那么赋值表达式SUBSTR(X,5,3) := ‘nom’的效果就是“替换”X的第5~7个字符,将“mon”替换成“nom”,并因此将X的“旧的”值(“antimony”)完全替换成“新的”值(“antinomy”)。这个赋值左侧的SUBSTR(X,5,3)就是一个伪变量参考量,而这个赋值本身则是下面表达式的简化版:X := SUBSTRX(X,1,4) || ‘nom’ || SUBSTR(X,8,1),在这里符号“||”表示字符串连接。注解完毕。

为了本书的易读性和定义的明确性,虽然有违我的最佳判断,但我还是决定在本书余下的部分不再使用数据库变量和“dbvars”这两个专用术语,至少不会用很多次,而是使用大家熟悉的“数据库”,希望我要表达的意思在上下文中总是很清楚。读者要擦亮眼睛。


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

51CTO读书频道二维码


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

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

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

读 书 +更多

SQL Server 2005数据挖掘与商业智能完全解决方案

本书以BI解决方案的体系结构为中心,以SQL Server 2005为载体,将着眼点放在数据挖掘和商业智能上,详细讲解了数据报表、数据分析和数据挖...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊