《视图更新与关系数据库理论》——2.5 MATCHING,NOT MATCHING以及EXTEND

2.5 MATCHING,NOT MATCHING以及EXTEND

就本书的主体部分而言,我当然会讨论一些关系代数的运算符(及其代表的操作)的细节,而基本上我会认为你们理所当然已经对这些运算符及其操作(如果你需要,可以在附录B中找到它们的定义)很熟悉了。但是这里有一些我经常提及的特定操作你们可能并不熟悉;它们被Tutorial D所支持并且很有用处,但是在大多数常见的教材中却并未被讨论过(可能因为它们并不能直接被SQL支持)。第一个我们要说的就是MATCHING,下面是它的定义。

定义:表达式rl MATCHING r2所返回的关系等于表达式rl JOIN r2所返回的关系,都投影到rl的属性上。
这里有一个例子(“求得最近供应过至少一个零部件的供应商”)。

S MATCHING SP

给定我们经常使用的样本值,那么结果应该像下面这样:

Tutorial D同时也支持一个“非”格式的操作NOT MATCHING。下面是它的定义。

定义:表达式r1 NOT MATCHING r2所返回的关系等于表达式r1 MINUS (r1 MATCHING r2)所返回的关系。18[18]
这里有一个例子(“求得最近没有供应任何零部件的供应商”)。

S NOT MATCHING SP

给定我们经常使用的样本值,那么结果应该像下面这样:

另外一个我想给大家介绍的操作是EXTEND。EXTEND有2种形式。第1种形式的定义如下。

定义:令关系r没有任何一个属性叫作A。那么表达式EXTEND r__:{A := exp}所返回的关系的关系头是扩展了属性A之后的r的关系头,关系体则是数组t,t是扩展了A的值之后的r的数组,而A的值是通过将r的数组应用表达式exp计算后得出的值。
那么现在我们来看,假设关系P中零部件的重量一般使用磅为单位,现在我们想用克为单位来显示这些重量信息。克与磅的换算关系是454克为1磅,所以我们可以这么写:

E XTEND P : { GMWT := WEIGHT * 454 }

给定我们经常使用的样本值,那么结果应该像下面这样:

EXTEND的第2种形式主要瞄准的是“假设情况”查询。换句话说,它可以直接浏览特定变化带来的效果,而不需要对目标对象做出实际变化(可能然后再撤消)来实现。这里有个例子(“要是零部件的重量单位使用的是‘克’而不是‘磅’会怎么样?”)。

EXTEND P : { WEIGHT := WEIGHT * 454 }

这里的重点在于在大括号中的赋值目标属性并不像上一个例子中那样是一个“新”的属性,而是一个已经存在于特定关系(在这里这个关系就是关系变量P目前的值)中的属性。整体来讲,这个表达式被定义成与下面所列出的表达式等价。

( ( EXTEND P : { GMWT := WEIGHT * 454 } ) { ALL BUT WEIGHT } )
                                                     RENAME { GMWT AS WEIGHT }

 

正如你所见,这个展开式中使用了Tutorial D RENAME操作。我想这个操作已经差不多人尽皆知了,当然如果你需要的话还是可以在附录B中找到相应的定义。更多关于它的讨论请参阅《SQL and Relational Theory》。
让我们用第2种形式的定义来作为本节的结尾。

定义:令关系r拥有属性A。那么表达式EXTEND r :{A := exp} 所返回的关系的关系头与r相同,关系体则是数组t,t是由替换A值后的r的数组得出的,而替换后的A值则是该数组经由表达式exp计算得出的。

时间: 2024-09-20 13:41:24

《视图更新与关系数据库理论》——2.5 MATCHING,NOT MATCHING以及EXTEND的相关文章

《视图更新与关系数据库理论》导读

前言 视图更新与关系数据库理论本书是这个系列的第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本书的目标读者是所有种类数据库的从业人员,书中解释了关系理论

《视图更新与关系数据库理论》——第2章 技术背景

第2章 技术背景 视图更新与关系数据库理论适合我的一切也应该能适合你. --Walt Whitman<Leaves of Grass>(1885) 上一章的讨论是基于SQL的,因为大家对它都很熟悉.但实际上很可惜,SQL并不适合作为这种探究的基础,也无法满足目前手上课题对细节技术讨论的要求.一方面来讲,我们需要检验的概念很多时候完全无法用SQL语句表达:从另一方面来看,即使是可以表达的时候,SQL通常也会引入一大堆与之毫无关系而又没有必要的复杂内容,很容易使人一叶障目,不见森林.由于以上原因,

《视图更新与关系数据库理论》——第1章 抛砖引玉

第1章 抛砖引玉视图更新与关系数据库理论身教胜于言教. --Samuel Johnson<Rasselas>(1759) 本书中所涉及的大多数范例都是基于我们耳熟能详的(可别说是老掉牙的)"供应商与零部件"数据库而来的.我为再一次把这个老生常谈的例子拿出来表示歉意,但正如我在其他地方所说,我认为在各种不同的出版物上使用同样的例子对于学习而言是有利无害的.就SQL来说[1],数据库包含3张表,更确切地说,是3张基表,分别称为供应商表S("suppliers"

《视图更新与关系数据库理论》——2.3 一致性约束

2.3 一致性约束 每个关系变量都受制于一系列一致性约束,我们也可以把它们简称为约束.首先,我们在"关系和关系变量"这一节中已经知道,任何一个给定的关系变量都被约束为一个确定的类型(具体来说,是一个确定的关系类型),也就是说,在定义关系变量的时候,这个类型也就确定了.例如,我们再来看看供应商关系变量S的定义.11[11] VAR S BASE RELATION { SNO CHAR , SNAME CHAR , STATUS INTEGER , CITY CHAR } KEY { SN

《视图更新与关系数据库理论》——1.6 小结

1.6 小结 抛砖引玉到此就要告一段落了.我们所用到的这个例子非常简单,从中得出的结论也是显而易见的.而其实我是想通过这个例子引出下面的理念,就是根据实际的定义把视图看作与特定的表相附生的基表,这对于整体考虑如何解决视图更新的问题是很有建设性的.我认为它不仅具有建设性,而且是一种"逻辑上正确"的方法.[8]总体思路如下. 1.视图定义表达式包含了某些特定的约束.例如,视图LS("London suppliers")的视图定义表达式表明了LS等同于表S中CITY值为L

《视图更新与关系数据库理论》——1.4 视图:约束和补偿性操作

1.4 视图:约束和补偿性操作 现在我要开始讨论本章的核心概念.如果前面两段中所涉及的表中有一部分或者全部都是视图的话,那么我们讨论的所有结论依旧成立,没有改变.例如,像之前一样,假设S是表,LS和NLS是视图. CREATE TABLE S ( .............. , UNIQUE ( SNO ) ) ; CREATE VIEW LS AS ( SELECT ... WHERE CITY = 'London' ) ; CREATE VIEW NLS AS ( SELECT ... W

《视图更新与关系数据库理论》——1.5 规则至上

1.5 规则至上 现在我们假设用户只能看到视图LS(而不是视图NLS和基表S).可以想见这个用户仍然希望可以将视图LS当作基表一样操作.当然,这个用户知道表的语义. LS:供应商SNO是已经签约的,名称为SNAME,状态值为STATUS且位于城市CITY中(London). 并且了解如下约束. {SNO}是LS的键. LS中的每一行CITY值为London. 很明显,这个用户无法向这个表插入新行,也不能更新表中的供应商编码,因为这样的操作很可能违反约束规则,而用户并不知道这些约束(必须不知道)[

《视图更新与关系数据库理论》——2.2 关系赋值

2.2 关系赋值 Tutorial D中的关系赋值语法,不是像INSERT或DELETE一样的缩写,而是使用如下的通用格式. R := rx 在这里"R"是一个关系变量(从语法上来说,其实就是一个关系变量的名字),"rx"是一个关系表达式,表示关系"r"和关系变量"R"是同一类型的.现在显而易见的是(这里要感谢David McGoveran的观察)任何这类赋值都在逻辑上等价于下列格式之一. R := ( r MINUS d )

《视图更新与关系数据库理论》——2.1 关系和关系变量

2.1 关系和关系变量 每一个关系都有一个"关系头"和一个"关系体",其中关系头是一系列状态和特征,而关系体则是符合关系头的一系列数组.让我们再次使用"供应商与零部件"数据库(如图2.1所示,与第1章的图1.1完全一样),供应商关系的关系头是{SNO CHAR, SNAME CHAR, STATUS INTEGER, CITY CHAR}的集合,我们假设在这里确定属性SNO.SNAME.STATUS和CITY分别被定义为CHAR.CHAR.INT