再论元组关系演算与SQL的论文.docVIP

　　再论元组关系演算与SQL的论文 摘 要　针对一些文献存在的问题，本文指明了特性谓词在元组关系演算中的表达形式，给出了含量词的元组关系演算表达式到sql语句的转化过程，并通过具体实例加以说明。 关键词　元组关系演算；特性谓词；全称量词；存在量词；sql 1　引言 20世纪60年代诞生的数据库技术，经过近半个世纪的发展，形成了坚实的理论基础、成熟的商业产品和广泛的应用领域。e.f codd 提出的关系数据模型为当今主流的数据库管理系统提供了坚实的数学基础。关系数据模型有三种等价的操作语言：关系代数、sql、关系演算(元组关系演算和域关系演算)，它们的非过程化程度依次递增，主要应用领域也不同。sql是关系数据库的标准语言，关系代数和关系演算是它的理论基础。大多商用的dbms先把用户提交的sql查询转化成等价的扩展关系代数表达式，在执行之前需要根据等价规则对其优化[9]。关系演算是以数理逻辑中的谓词演算为中心的，按谓词变元的不同，分为元组关系演算和域关系演算。在实际应用中，元组关系演算通常用来辅助生成带量词的sql语句[3][4][6]，域关系演算以著名的qbe为代表，直观易学，适合于非专业人员使用，目前在access、po 将用户提出的查询要求转化为可执行的sql语句，是一个非形式化描述向形式化规范转变的过程，完全借助计算机来实现是非常困难的，一般由专业技术人员根据经验来完成。sql语言是非过程化的，与常用的过程化的命令式语言有很大的区别。用户要完成一个查询，只需要用sql语言提出要求，无须指明怎么做。在实际应用中，用户往往提出含有“全部”、“至少”等条件的查询，它们不容易采用sql表达，这时可求助于元组关系演算，大致过程为：①写出查询的元组关系演算表达式；②根据等价转化规则得到不含全称量词的元组关系演算表达式；③将元组关系演算表达式转化为sql语句。迄今为止，国内外有很多文献和书籍都讨论过相关的内容，然而有些理论细节并没有详细解释，在一定程度上妨碍了人们对数据库知识的理解和应用，产生了一些错误[1][2][5]。本文将就这一问题进行讨论。 2　元组关系演算与sql 确定一个元组关系演算表达式，首先要分析需要使用的关系模式，确定相互之间的参照完整性约束。在特殊情况下，一个关系模式还有可能使用多次，则可通过引入不同的元组变量来区分。其次，将赋值和限定条件加入到元组关系演算表达式中。关于限定条件如何表示这一问题，很多数据库教材和文献中并没有仔细讨论，结果产生了一些问题。 在谓词逻辑中，全总个体域包含了所有个体变元的所有个体域，它统一了个体变元的取值范围，但不同论述对象需用不同的特性谓词加以再刻画[8]。对于全称量词，特性谓词作为蕴涵式的前件加入；对于存在量词，特性谓词作为合取项加入。在元组关系演算表达式中，元组的限定条件即是特性谓词，书写时也必须遵循上述两条基本规则。在文献[1]、[2]、[5]中，对于全称量词，均将限定条件作为合取项，这样造成元组关系演算表达式的语义不符合查询要求，无法表示正确的查询结果。我们经常会遇到这样的情况：对于同一个查询，从不同的角度理解，可以写出不同的元组关系演算表达式。假定有两个不同的表达式a和b，且a是正确的，那么根据谓词逻辑的完备性，如果由a无法通过推理规则得到b，则a与b的语义不同，那么b一定是一个错误的表达式。这种方法通常被用来判断一个元组关系演算表达式是否正确。 在上述分析的基础上，对于含“全部”、“至少”等条件的查询，从分析入手，得到元组关系演算表达式，再转化为sql语句，一般要经历下面三个过程： 根据查询的语义，以元组变量为主导，写出一个“规范”的元组关系演算表达式。这里所谓的“规范”，是指针对每个元组变量，其后的原子公式均以关系模式、限定条件和赋值的顺序出现，在最大的限度上保证量词辖域收缩到最小情况。特别需要注意的是限定条件(关系模式也可认为是一种特殊的限定条件)针对全称量词和存在量词的不同表示方法。 将元组关系演算表达式中的全称量词#8704;全部转化为存在量词#8707;。因为在sql语言中不存在全称量词，只有与存在量词对应的exists谓词，需要使用下列的等价式将元组关系演算表达式中的全称量词转化为存在量词。 将元组关系演算表达式转化为sql语句，处理的过程由外向内，依次为： (1)将最外层的#8707;、本层的限定条件和最后的赋值部分转换为select、from、、e， status， city)，各属性分别表示供应商代码、供应商姓名、供应商状态、供应商所在城市；零件表p(pno， pname， color， e， city)，各属性分别代表工程项目代码、项目名、项??所在城市；供应情况表spj(sno， pno， jno， qty)，各属性分别代表供