《视图更新与关系数据库理论》——2.4 关系变量谓词

2.4 关系变量谓词

在第1章中,当我介绍抛砖引玉的例子(供应商与零部件数据库)时,曾提到了这样一件事:

表S的内容列出了签过合同的供应商。每个供应商有一个唯一的供应商编号SNO、可能不唯一的供应商名字SNAME(尽管图1.1中的样本值恰好是唯一的),以及状态值STATUS和位置CITY。

当然,在第1章中的“表S”似乎应该叫作“关系变量S”更加准确,不过这并不是重点。重点在于:第一,目前的文字代表了关系变量S的意义,并且更容易被用户理解;第二,这种意义的措辞实际上是“谓词”(有时候也说“解释”或者“预期解释”,但在本书中我还是主要使用“谓词”这种说法)。换句话来讲,可以说每一个关系变量都有一个相对应的谓词,我们称之为这个关系变量的“关系变量谓词”,而关系变量谓词的本质是用户对与之对应的关系变量的理解。下面我们来举个例子,这里我选择声明关系变量S的谓词。

S:供应商SNO是已经签约的,名字为SNAME,有状态STATUS,位置在CITY城市。

下面是关系变量P和SP的谓词。

P:零部件PNO在公司内使用,名字为PNAME,有COLOR颜色和WEIGHT重量,并且存储在CITY城市。

SP:供应商SNO供应零部件PNO,数量为QTY。

作者注:14[14]也许我应该对我在本书中所使用的“谓词”这个词语多做一些说明。首先一点,在SQL中这个词被广泛地用来表示布尔值或真值表达式(比如比较谓词、IN谓词、EXISTS谓词等),所以你可能对它已经很熟悉了。但是,虽然这种用法在SQL上并不是完全错误的,但它确实滥用了一个非常通用的词汇,这个词汇在数据库环境中非常重要,并且给了它一个特别具体的意思,这也是为什么我决定不沿用这种用法的原因。

第二,为了信息准确我应该来解释一下,谓词并不是像上面我们写的,就是自然语言中的几个句子。相反,谓词是由这些句子所决定的。换个说法就是关系变量S的谓词该是什么就是什么,不管你是用英语或者西班牙语,还是其他任何语言来表达,它的核心内容都是一样的。但是在后面的文章中,为了表达简明,我会假设谓词就是1句话,一个(通常)用自然语言表达的句子。(类似的标注也会用到命题上,看下面。)

最后,我已经解释了这个词的意思,尽管有前面一段的解释,但是你还是需要知道,对于谓词“到底”是什么,即使逻辑学家们也很难有非常一致的答案。尤其是有些作者认为谓词是一个单纯的概念,它本身并无意义,而认为我上面所写的应当是预期解释,而不是谓词。我不想在这里对这些事情做过多的争辩。如果想看更多的讨论,我推荐你去看“What’s a Predicate?(什么是谓词)”这篇文章,你可以在Hugh Darwen和我合著的著作《Database Explorations: Essays on The Third Manifesto and Related Topics》(Trafford,2010)中找到它。

你可以把谓词想成是一个“真值函数”。和所有的函数一样,它也有一系列参数。当它被调用的时候会返回一个结果,而(因为是真值函数,所以)结果是TURE或者FALSE。那么在关系变量S的谓词这个例子中,这些参数就是SNO、SNAME、STATUS和CITY(对应的显然是这个变量的属性),它们的值分别是相应的类型(分别是CHAR、CHAR、INTEGER和CHAR)。当我们引用调用该函数时,逻辑学家们会说当我们“实例化谓词”时,我们把一组确定的值代入参数。假设我们代入的值分别是S1、Smith、20和London。那么可得:

供应商S1签约了,名字是Smith,状态是20,位于城市London。

这句话其实是一个“命题”,在逻辑上它并没有参数,也无法得出一个明确的“ture”或“false”的结果。(当然对于手中这个例子,命题为真,或者至少我们这样假设。)这把我们引入另一个非常重要的原则中,它就是闭域假设(The Closed World Assumption)。

定义:令关系变量R拥有谓词P。那么闭域假设(The Closed World Assumption,CWA)规定(a)当数组t在T时刻出现在R中,那么我们就假设P中对应于t的实例p在T时刻为真;相反地,(b)当数组t与R拥有相同的关系头,但在T时刻并未出现在R中,那么我们就假设P中对应于t的实例p在T时刻为假。换句话说,当且仅当数组t在给定的时刻满足R的谓词时,数组t才会在该时间出现在R中。15[15]
举个例子,我们再次参看图2.1,数组(S1,P1,300)出现在关系变量SP中,因此供应商S1可以提供P1零部件,数量300 就成为一个“真正的事实”。但是如果我们从该变量中删除该数组,那么我们就会说(实际上)供应商S1可以提供P1零部件,数量300“不再是个事实”。

到目前为止,我们讨论了谓词和关系变量的具体关系。不过,实际上目前所有的概念都自然而然地向关系型表达式延伸。例如,考虑到供应商在除了CITY以外的所有属性上都有投影(注意Tutorial D对投影的语法)。16[16]

S { SNO , SNAME , STATUS }

这个表达式表明一个关系包含所有形如(s,n,t)的数组,而一个形如(s,n,t,c)的数组现在出现在关系变量S中,CITY值是c。换句话说,就是结果包含且仅包含所有对应下面谓词中真值实例的数组。

这里存在着这样的城市CITY,供应商SNO已签约,名字是SNAME,状态为STATUS,并且位于城市CITY。

这个谓词代表了一个表达式—一个关系表达式S{SNO,SNAME,STATUS}。观察这个表达式你会发现,这里有3个参数,而对应的关系本身有3个属性。CITY 并不是该谓词的参数,而是被逻辑学家们称为“约束变量”,因为实际上它被“这里存在着这样的城市CITY”这句话所“量化”了。注意:这里可能有一个更清楚的方式来说明这点(也就是,谓词有3个参数,而不是4个),那就是这个谓词效果上等价于下面这一个。

供应商SNO已签约,名字是SNAME,有状态STATUS,并且位于某处(意思是它位于某个城市,但是我们不知道具体是哪一座城市)。

注意类似的方式可以应用到任意可能的关系表达式中。具体来说就是:任意关系表达式rx总是有一个对应的意义,或谓词;而且rx的谓词总是可以被表达式中的关系变量的谓词决定,与表达式中关系操作的语义保持一致。17[17]

作者注:再次重申,除了CITY之外,所有供应商的属性的投影都可以用Tutorial D表示为形式S {SNO,SNAME,STATUS}。而为了更加方便地表达,Tutorial D也允许在表达式中利用被移除的属性代替被保留的属性进行表达。因此,以上面的表达式为例,它和表达式S {ALL BUT CITY}是等价的。在适当的情况下,在Tutorial D范围内类似的情况可以应用于所有的操作。

就我目前为止对关系变量谓词的描述来看,好像它们很不正规,实际上它们只是在自然语言中对关系变量拥有特定的属性(当然,是特定的类型)这一事实的陈述和表达。不过我们也可以使用更加正式一点的表达方式。例如,给定供应商关系变量S有属性SNO、SNAME、STATUS和CITY,并且给定{SNO}是该关系变量的单键,那么我们说相应的谓词应该如下面这样。

is_entity   ( SNO ) AND
has_SNAME   ( SNO , SNAME ) AND
has_STATUS ( SNO , STATUS ) AND
has_CITY    ( SNO , CITY )

假设数组t出现在关系变量S。那么这个谓词表达的意思是:

SNO在t中的值确定了一个实体。
这个实体拥有一个SNAME的属性,而该属性的值是由SNAME在t中对应的值给定的。
这个实体同时也拥有一个STATUS的属性,它的值是由STATUS在t中对应的值给定的。
这个实体同时也拥有一个CITY的属性,它的值是由CITY在t中对应的值给定的。
当然,系统并不知道这个实体,即被SNO确定的实体,其实就是现实世界中的一个供应商,实际上是一个“已签约”的供应商,也不知道它的意思是拥有SNAME属性、STATUS属性或CITY属性。

类似地,我们也可以说除了CITY之外所有供应商属性的投影的谓词为:

is_entity  ( SNO ) AND
has_SNAME  ( SNO , SNAME ) AND
has_STATUS ( SNO , STATUS ) AND
EXISTS CITY ( has_CITY ( SNO , CITY ) )

最后,在结束本节的时候我要向大家坦白,到目前为止我所讲的所有关于关系变量谓词的内容都故意地进行了简化。不过当然,我相信这样略有简化的内容对于做介绍来说是足够的了。而对于更详细的内容—“真实的故事”,或者至少是比现在的“真实一点”的,我建议你参看我的另一本书《Logic and Databases: The Roots of Relational Theory》(Trafford,2007)第4章(“闭域假设”)。

时间: 2024-09-03 16:14:09

《视图更新与关系数据库理论》——2.4 关系变量谓词的相关文章

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

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

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

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

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

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

《视图更新与关系数据库理论》——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

《视图更新与关系数据库理论》——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

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

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

《视图更新与关系数据库理论》——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