编译Horn子句规则的数据库技术实践
编译Horn子句规则：数据库技术探索与实践
1. 数据库评估方法
在数据库操作中，从空关系开始，不断将当前结果提交给函数，直到结果中不再出现新的元组。理论上，这个过程可能需要无限步，但在数据库中，由于域是有限的，该过程必定会在有限步后终止。当递增链在某点变得稳定时，满足 $X_i = \Phi(X_i)$ 的第一个链元素 $X_i$ 就是最小不动点。
不过，这种被称为朴素评估方案的方法在实际应用中效率极低，因为它会反复重新计算相同的元组。为了避免部分重复计算，半朴素评估方案通过重写函数，只计算“增量部分”。
在构建能够处理递归定义的数据库接口方面，人们投入了大量精力。在相关项目中，采用了基于编译的方法来处理递归规则。不再将中间结果作为表重新提交给函数，而是编译一系列越来越复杂的表达式，这些表达式代表规则 k 次应用的结果，并将其编译为关系代数。这种方法得益于 BS12 的架构，用户可以通过语言表访问视图定义。此外，BS12 中的优化器以动态方式处理代数表达式的树表示，使得表达式的递归展开和优化能够以增量方式协同工作，从而在构建时就可以对表达式进行优化。
2. 超越 Datalog：术语处理
Datalog 中谓词的参数仅支持常量和变量，而完整的 Prolog 还允许通过将函数应用于多个术语来构建术语。从语义上讲，术语违反了数据库中第一范式的条件，即所有属性值必须是原子值。
例如，Prolog 事实
owns(Lucy,Mug).
和
owns(Lucy,book(Homer,Ilias)).
表明，Lucy 拥有一个没有结构信息的杯子，以及一本有明确作者和标题的书。在数据库中，第一种情况很容易表示，只需在
OWNS
表中存储元组
(Lucy,Mug)
即可。而第二种情况则需要引入另一个
BOOK
表来存储书籍信息，然后在
OWNS
表中存储元组
(Lucy,X)
，其中
X
类似于指向
BOOK
表的外键值，从更高的抽象层面看，
X
可被视为对象标识符，这意味着从关系模型向嵌套关系或完全面向对象的模型转变。
然而，将 Prolog 术语纳入编译方法的范围仍存在一些问题：
-
对象标识符生成
：存储外键或对象标识符需要一种生成这些值的机制，由于 Prolog 中不需要这些值，因此数据库系统需要承担此任务。数据库是否能够判断是否为已经处理过的元组创建新的对象标识符是一个问题，重复项的去除变得更加困难，就像在面向对象领域一样。
-
属性域定义
：定义包含可能成为属性的实体的域并非易事，因为属性可以是无结构的，也可以是有结构的。而 Prolog 作为一种无类型语言，不存在这个问题。
1986 年，阿姆斯特丹大学的学生 S.J.C. Elbers 在 IBM Uithoorn 进行硕士论文项目，旨在构建 Prolog - BS12 接口的扩展以处理术语。第一个问题通过利用 BS12 内部结构为所有元组生成对象标识符（称为伪键）并将其提供给用户来解决。第二个问题通过系统地将列替换为三个列的集合来解决，这样所有属性都可以选择原子值或对象标识符。对于原子值，第一列存储该值，其余两列采用默认值；对于对象标识符，第一列是默认值，第二列和第三列分别包含表引用和该表的伪键值。
通过这种表的扩展，编译器可以处理非递归术语，从而使查询得到正确的答案。但又遇到了与 Prolog 本身相关的问题。Prolog 在语法上几乎不区分函数和谓词，例如添加事实
book(Vergil,Aeneas).
后，查询
?-book(X,Y)
可能只会返回
Aeneas
，因为
Ilias
仅作为术语出现，与谓词的统一会失败。为了保留 Prolog 系统的这种行为，Elbers 将数据库中的每个关系分为两部分，一部分对应谓词信息，另一部分表示所谓的参数信息。
这个过程可以用以下 mermaid 流程图表示：
graph TD;
A[开始] --> B[处理简单 Prolog 事实];
B --> C[处理含术语的 Prolog 事实];
C --> D[解决对象标识符和属性域问题];
D --> E[扩展表结构];
E --> F[处理非递归术语];
F --> G[遇到 Prolog 语法问题];
G --> H[分割关系为两部分];
H --> I[结束];
3. 约束与消除：RL 项目
数据库中的数值属性引发了对这些数值进行计算的需求，但标准数据库对此提供的支持有限。一方面，有简单的计算操作，如 BS12 中的
CALCULATE
运算符，可根据指定公式为关系中的每个元组添加新的数值属性值，但该运算符不属于关系代数的核心部分，扩展后的关系是否能进行进一步的代数运算尚不明确。另一方面，有聚合运算符，它根据一个属性的值对表进行分组，并对每个组中的其他属性进行求和等操作。聚合运算符的集合是固定的，取决于所选择的数据库系统，且通常不能用一阶逻辑表示，其存在主要是为了满足实际应用中生成公司报告等需求。大多数系统不允许用户定义自己的聚合运算符，Stonebraker 的 Illustra 是一个例外。
目前数据库在计算支持方面缺乏一个重要特性：可逆性。在设计数据库方案时，无法预知会提交哪些查询。查询时，系统需要根据输入和输出属性选择导航策略来生成答案。但计算指令通常是按照定义的方向进行评估，大多数系统缺乏智能，无法根据已知属性推断出其他属性的值。例如，已知
C = A + B
，大多数系统无法从
A
和
C
的输入值计算出
B
的输出值。更复杂的情况是，对于方程组
C = A + B
和
D = A - B
，需要符号方程求解器才能让系统发现可以从
C
和
D
的值计算出
A
和
B
的值。
在 Prolog 中，内置谓词
sum(A,B,C)
只有在
A
和
B
有绑定值时才能为
C
获得绑定值，符号方程求解是不可能的。虽然现在有扩展逻辑编程的方法提供了额外的功能（约束逻辑编程领域），但在 1986 年左右，这方面的工作还很少，且当时的研究主要是为了扩展逻辑编程的约束能力，而不是将约束纳入数据库技术的范围。
在 1985 年，相关作者在 IBM 圣何塞担任访问科学家，参与了由 Peter Lucas 主持的办公自动化研究小组。其任务是发明一种语言来表达业务规则存储库的内容，最终提出了名为 RL 的语言。RL 规则有三种格式：
| 规则格式 | 对应内容 |
| ---- | ---- |
| 表格规则 | 对应关系数据库表达式（视图定义） |
| 子句 | 对应 Datalog 中的 Horn 子句 |
| 约束 | 表示符号属性上的代数约束 |
RL 的语法和语义基于“一切都是关系，但并非所有关系都相同”的原则。例如，表格和子句描述命名关系，而约束描述未命名的“世界”关系。表格是程序范围内的全局定义，而现有谓词可以添加新的子句，添加子句在语义上相当于并集，添加约束相当于交集。
该语言的提议最初未得到积极响应，预计实现这些想法至少需要三年时间，IBM 没有开展相关工作，办公自动化项目在作者离开几个月后也终止了。但 RL 项目在阿姆斯特丹大学得以复兴，S.J. van Denneheuvel 为一个无关项目编写的符号方程求解器正好满足了实现 RL 的需求。构建一个具有预期功能的小型原型只需要几个月时间，更广泛的实现和相关理论成为了他博士论文的主题。
RL 系统同样基于编译。RL 查询由符号方程求解器分析，然后转换为
select - join - calculate - project
表达式，可提交给数据库系统。BS12 原本是理想的数据库后端，但当时 IBM 荷兰公司对实验 BS12 失去了兴趣。
van Denneheuvel 在完成论文后，为系统构建了一个前端，将 RL/1 编译为 SQL。即使不使用约束，这个工具也很有用，因为数据库应用的 RL/1 代码比其 SQL 等效代码更加紧凑，该语言曾被用作荷兰高科技软件公司 Syllogic 一个重大开发项目早期的快速原型工具，但由于性能问题，在实际应用中并不实用。
最后，还有一个与 RL 相关的面向对象扩展项目 OORL，由阿姆斯特丹大学的 E. Rotterdam 博士在 1994 - 1997 年作为博士后进行研究，描述该语言的报告尚未完成。
这些项目证明了基于编译的演绎数据库方法在理论上是可行的，但尚未确定该方法在实际应用中是否能提供可接受的性能，这需要更多的投资和研究。同时，从清晰的数学模型出发，可以在 Datalog 之外的领域添加功能，并保持所使用语言的一定透明度。这些项目得益于特定的环境，使得可以不受主流方法的压力，而 BS12 为实验这些想法提供了理想的工具。
编译Horn子句规则：数据库技术探索与实践（续）
4. 项目总结与展望
在 1983 年至 1997 年期间开展的这些项目，虽然在理论上验证了基于编译的演绎数据库方法的可行性，但对于该方法在实际应用中能否达到可接受的性能，还需要更多的投入和研究。以下是对这些项目的一些总结和展望。
4.1 项目成果总结
-
技术实现方面
- 在处理递归规则时，采用编译一系列复杂表达式并转化为关系代数的方法，借助 BS12 的架构和优化器特性，实现了一定程度的优化。
- 针对 Prolog 术语在数据库中的应用问题，通过扩展表结构、分割关系等方式，解决了部分技术难题，使得编译器能够处理非递归术语。
- RL 项目构建了一种新的语言，为业务规则的表达和处理提供了新思路，并且基于编译的方式将查询转化为可提交给数据库系统的表达式。
-
方法创新方面
- 半朴素评估方案的提出，旨在减少朴素评估方案中的重复计算，提高效率。
- 将不同格式的规则（表格规则、子句、约束）纳入统一的语言框架，体现了对数据库语义和语法的创新理解。
4.2 面临的挑战
- 性能问题 ：虽然理论上可行，但在实际应用中，这些方法的性能是否能满足需求还不确定，例如 RL 项目构建的系统在实际应用中因性能问题而受限。
- 复杂性问题 ：如处理 Prolog 术语时，将数据库关系分割为两部分的做法使系统变得复杂，证明系统的正确性也变得困难。
- 兼容性问题 ：部分项目原本期望使用 BS12 作为数据库后端，但由于 IBM 政策等原因，无法充分利用其优势，反映出技术在实际应用中的兼容性挑战。
4.3 未来展望
- 性能优化 ：未来可以进一步研究如何优化编译过程和查询处理，以提高系统的性能，使其能够更好地应用于实际场景。例如，可以探索更高效的符号方程求解算法，减少计算时间。
- 系统简化 ：尝试简化复杂的系统设计，提高系统的可维护性和可扩展性。例如，寻找更简洁的方式来处理 Prolog 术语和规则，避免过度分割关系。
- 跨平台兼容性 ：研究如何使这些技术在不同的数据库系统和平台上都能有效运行，提高技术的通用性和适用性。
以下是一个简单的列表总结项目的关键要点：
- 递归规则处理：编译表达式，借助 BS12 架构优化。
- Prolog 术语处理：扩展表结构，分割关系。
- RL 项目：构建新语言，基于编译处理查询。
- 面临挑战：性能、复杂性、兼容性。
- 未来展望：性能优化、系统简化、跨平台兼容。
5. 实际应用案例分析
为了更直观地理解这些技术在实际中的应用，我们可以分析一些可能的实际应用案例。
5.1 商业规则管理
在企业的业务运营中，存在大量的商业规则需要管理和执行，例如税收计算、折扣规则等。RL 语言可以很好地应用于这种场景，以下是一个简单的操作步骤说明：
1.
规则定义
：使用 RL 语言的表格规则、子句和约束来定义商业规则。例如，定义税收计算规则可以使用约束来表示税率和计算方式。
2.
规则编译
：将定义好的规则通过符号方程求解器进行分析，并转换为
select - join - calculate - project
表达式。
3.
规则执行
：将编译后的表达式提交给数据库系统进行执行，根据输入的数据计算出相应的结果。
5.2 医疗模型应用
在医疗领域，需要处理各种复杂的生理模型和决策支持规则。RL 项目中的相关技术可以用于构建医疗模型，以下是具体的操作流程：
graph TD;
A[定义医疗规则] --> B[使用 RL 语言表示规则];
B --> C[编译规则为表达式];
C --> D[提交表达式到数据库];
D --> E[根据患者数据计算结果];
E --> F[提供决策支持];
- 定义医疗规则 ：根据医学知识和临床经验，定义各种医疗规则，如疾病诊断规则、治疗方案选择规则等。
- 使用 RL 语言表示规则 ：将这些规则用 RL 语言的不同格式（表格规则、子句、约束）进行表示。
- 编译规则为表达式 ：利用符号方程求解器将规则编译为数据库可执行的表达式。
- 提交表达式到数据库 ：将编译后的表达式提交给数据库系统，结合患者的实际数据进行计算。
- 根据患者数据计算结果 ：数据库系统根据输入的患者数据和编译后的表达式，计算出相应的结果，如疾病诊断结果、治疗建议等。
- 提供决策支持 ：将计算结果反馈给医生，为医疗决策提供支持。
通过这些实际应用案例可以看出，这些数据库技术在不同领域都有潜在的应用价值，但同时也需要不断地优化和改进，以适应实际应用的需求。
综上所述，这些关于编译 Horn 子句规则的项目为数据库技术的发展提供了宝贵的经验和思路。虽然目前还存在一些挑战，但随着技术的不断进步和研究的深入，相信这些技术将在未来的数据库应用中发挥更大的作用。
扫一扫
1165
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
