11、在IBM商业系统12中编译霍恩子句规则

在IBM商业系统12中编译霍恩子句规则

1. 演绎数据库与递归无关安全Datalog

手动将Prolog定义转换为相应的关系表达式是一项艰巨的任务，但这个过程可以自动化，具备这种自动化能力的系统被称为演绎数据库。演绎数据库的理想目标是将Prolog友好的声明式世界与现有关系数据库系统强大的信息处理能力相结合。

其中，能进行这种转换的Prolog核心片段被称为递归无关安全Datalog。它由非递归的霍恩子句系统定义的谓词规则组成，基于有限的基本关系集合，且项中不包含函数符号。同时，规则需满足安全条件，防止Prolog解释器给出的答案中出现自由变量，以确保派生关系有界。对于这类规则，定义的谓词范围可以用代数关系表达式描述，翻译过程也能实现机械化。

不过，在20世纪80年代左右，大多数相关项目采用的是一次处理一个元组的方法。虽然AI系统可以将事实存储在关系数据库中，但信息的组合处理仍在AI推理引擎端进行，导致数据库系统的能力严重未被充分利用，数据库技术的诸多次要优势也无法为AI系统所用。推测其原因，可能是当时缺乏合适的关系数据库系统。

2. Prolog - BS12接口项目

受日本第五代项目的启发，项目人员注意到Prolog中的回溯与关系数据库中表达式求值之间的对应关系。最初的想法在1984年初阿姆斯特丹自由大学的一个研讨会上提出，但当时一次处理一个元组方法的支持者众多，这一想法并未得到广泛认可。

尽管如此，项目人员坚信IBM的商业系统12（BS12）适合实现这一想法，于是安排了学生C.J.F. Doedens在IBM进行实习。Doedens在9个月内开发出了一个可用的原型。

3. 商业系统12（BS12）介绍

BS12是IBM荷兰公司在20世纪80年代初开发的关系数据库系统，基于英国彼得利一个团队的工作成果。早期开发阶段，它与美国的数据库开发项目（如系统R）互动较少。1983年，BS12的第一个版本投入使用，它以服务形式通过荷兰Zoetermeer的国际网络提供，用户在分时环境下访问该系统。后来，IBM管理层决定不再支持该产品，但由于一个金融项目（基于XSHARE数据库，存储了约100000家公司五年的股票汇率，数据量达5GB）难以在不损失性能和功能的情况下迁移到DB2，BS12一直使用到了约1996年。

BS12具有以下特点：
- 数据结构 ：表是关系，是域的笛卡尔积的子集，列由命名属性标识，行对应关系中的元组。域是与五种基本类型（字符、数字、名称、位、时间戳）之一相关的有限集合，“名称”类型有特定的规范化约定，用于表和属性名，每个域可分配默认值。表中不允许有重复行，且是同质的，行的顺序无关紧要。
- 系统架构 ：由于运行在分时环境中，多个客户同时使用系统，为保护客户之间的信息访问和服务可用性，系统没有全局的表和/或视图目录，每个用户有自己的私有字典，可选择共享部分项目。
- 系统接口 ：具有单语言结构，专注于表（关系被解释为集合），进程、函数等也由表（语言表）表示，这使得这些对象可被关系运算符访问，系统信息（如表、列或视图的目录）也存储在表中。
- 代数特性 ：系统具有完全代数特征，名称中的“12”代表有12个关系运算符，具体如下表所示：
| 运算符 | 功能 |
| — | — |
| SELECT | 基于选择标准对表进行集合推导（行子集） |
| PRESENT | 结合投影和重命名的混合操作（列子集） |
| CALCULATE | 通过新属性扩展表，新属性与其他属性存在函数依赖，依赖关系由显式公式给出 |
| GENERATE | 从常数值计算生成单行关系 |
| SUMMARY | 用于分组、求和等的聚合构造 |
| JOIN | 自然连接 |
| MERGE | 外连接的一种，不匹配的行用默认值而非空值扩展 |
| QUAD | 关系的笛卡尔积 |
| DIFFERENCE | 相对集合差 |
| EXCLUSION | 两个表的对称差 |
| INTERSECTION | 交集 |
| UNION | 并集 |

布尔运算（列表中的后四个）不要求两个参数关系具有并兼容性，若不兼容，结果表会投影到两个操作数共享的属性上。BS12代数完备，基本关系能作为操作数的地方，关系表达式也可以。每个关系表达式代表数据库的一个视图，视图不仅可以求值，定义视图的表达式还能存储在语言表中，并可在会话期间存储和修改。

4. 安全非递归霍恩子句到视图定义的翻译

给定一组霍恩子句规则和基本谓词集合，目标是将其解释为用基本谓词定义的谓词集合，并为派生关系获得基于基本表的关系表达式。

翻译前需要进行预处理，将共享头部谓词的子句分组，定义在某个子句体中作为子目标出现的谓词的组应排在包含该子句的组之前。对于非递归的霍恩子句系统，可以通过拓扑排序实现这种排序；而对于递归的霍恩子句家族，这种排序则不存在。

此外，还需注意一种情况：规则头部出现的变量若未在体中出现或仅出现在内置谓词中，可能导致无界关系。为避免这种情况，需要对Prolog程序实施安全条件，即规则中头部出现的所有变量必须在体中有界。

Ullman描述的霍恩子句到视图定义的翻译过程分为三个阶段：
1. 第一阶段 ：为每个基于关系谓词的子目标构建关系表达式，内置子目标在第二阶段单独处理。这些表达式主要由表示子目标中谓词的关系或视图组成，若存在常量参数或单个变量多次出现的情况，需调用SELECT运算符。
2. 第二阶段 ：将对应子目标的各种表达式连接起来，得到对应规则体范围的表达式。内置谓词（主要是数值参数的不等式）转换为另一个选择操作。为适应基于命名属性的关系代数中按位置指定的参数，子目标对应的表达式常需重命名，以确保子目标之间的共享变量对应JOIN表达式中的公共列。
3. 第三阶段 ：将某个谓词的各种规则的贡献组合起来，定义该谓词。若子目标表达式具有并兼容性且与头部谓词签名相同，对规则头部出现的变量进行投影后取并集即可。但由于单个规则头部可能出现重复变量和常量，子目标表达式通常不具有并兼容性。Ullman采用规则修正的预处理阶段解决此问题，这会使体的表达式包含更多选择条件。

从上述翻译过程可以推断出，支持Datalog编译器的关系数据库管理系统（RDMS）需满足以下要求：
1. 关系运算符SELECT、PROJECT、JOIN、RENAME和UNION能以任意嵌套方式在表达式中使用。
2. 能够像调用基本表一样方便地调用已定义的视图，视图应具有一等公民的地位。
3. 会话期间可方便地添加、删除和修改规则，相应的视图能在数据库中插入、删除和修改，且无需每次更改都重构整个数据库，即存储视图及其定义的目录应在运行时易于访问和更新。

而BS12完全满足这三个要求，PRESENT运算符结合了投影和重命名功能，其他所需的SELECT、JOIN和UNION运算符也都可用。相比之下，1984年基于SQL的系统都不满足这些要求，这也解释了为什么BS12是构建原型的理想RDMS，以及其他团队为何未选择完全基于编译的演绎数据库方法。

下面是霍恩子句翻译流程的mermaid流程图：

graph LR
    A[预处理] --> B[第一阶段：构建子目标关系表达式]
    B --> C[第二阶段：连接子目标表达式]
    C --> D[第三阶段：组合规则贡献]

5. 编译方法功能的扩展

完整的Datalog包含递归定义谓词的功能，这是之前翻译过程未涉及的，由于演绎数据库在学术环境中很受欢迎，递归功能是首先想要添加到接口的特性。

完整的Prolog使用函数符号构建复杂项来表示复杂实体，这些结构与嵌套关系模型中的结构相似，因此将编译方法迁移到嵌套关系模型是第二个扩展方向。

Prolog支持使用否定子目标，通过失败即否定策略实现；而关系数据库模型中通过DIFFERENCE运算符提供了一种较弱的否定形式，因此需要研究是否可以在接口中添加一些“温和”的否定运算符使用方式。

数据库中的数值若不能进行计算则用处不大，理想情况下希望数据库系统能具备电子表格程序的功能，通过符号表达式进行数值计算，这一功能扩展在如今的约束逻辑编程领域得到研究。

在1984年至1997年期间，相关研究项目针对上述扩展进行了探索。递归和（非递归）项在原型系统中已得到处理，否定问题在理论上有解决方案，但未在原型中实现。约束扩展成为了RL项目的焦点，该项目于1985年在IBM圣何塞研究中心启动，并在阿姆斯特丹大学继续进行。

6. 超越关系代数：递归

Prolog中谓词的递归定义与数学代数中不允许用自身定义对象的原则相悖，但逻辑学家、计算机科学家和数学家已经学会理解和处理递归定义。这些“定义”更应被视为方程，而方程可能有解，并且为了有意义，最好有唯一或至少是首选的解。

在计算机科学中，首选解的存在常基于Knaster和Tarski提出的最小不动点原则。在某个抽象数学结构Ω上，递归定义可以用方程X = Φ(X)表示，其中Φ是从Ω到自身的映射。假设Ω上定义了部分顺序⊑，存在唯一的最小元素⊥，且可数递增链有最小上界。若X₀ ⊑ X₁ ⊑ X₂ … 是可数递增链，则 ⋃ₙ₌₀^∞ Xₙ 表示这个最小上界。

若Φ满足X ⊑ Y 则 Φ(X) ⊑ Φ(Y)，则称Φ是单调的；若Φ(⋃ₙ₌₀^∞ Xₙ) = ⋃ₙ₌₀^∞ Φ(Xₙ)，则称Φ是连续的。Knaster - Tarski原则表明，对于单调连续的函数Φ，方程X = Φ(X)有最小不动点，且可通过 ⋃ₙ₌₀^∞ Φ⁽ⁿ⁾(⊥) 计算，其中Φ⁽ⁿ⁾(⊥) 表示对⊥进行n次Φ迭代。

在Prolog规则的语义及其在关系数据库模型中的解释中，取Ω为固定笛卡尔积域内的关系族，⊑表示集合包含，⊥表示空关系。可以发现，翻译过程中调用的五个关系运算符SELECT、PROJECT、JOIN、RENAME和UNION都是单调且连续的，翻译器生成的复杂表达式也是如此。

应用该原则时需注意，Prolog中的递归通常涉及一组谓词符号，翻译后会定义一组相互关联的关系。通过将这些关系进行笛卡尔积运算，可将系统替换为具有递归定义的单个关系，然后应用Tarski - Knaster原则。因此，我们不仅知道递归定义关系的含义，还知道如何计算其含义。

下面是递归定义关系计算流程的mermaid流程图：

graph LR
    A[定义递归关系方程X = Φ(X)] --> B[检查Φ的单调性和连续性]
    B --> C{满足条件?}
    C -- 是 --> D[计算最小不动点 ⋃ₙ₌₀^∞ Φ⁽ⁿ⁾(⊥)]
    C -- 否 --> E[调整或重新定义关系]
    E --> A

综上所述，从Prolog到关系数据库的转换以及相关功能扩展是一个不断发展和探索的过程，BS12在其中展现出了独特的优势，而递归等功能的处理也为演绎数据库的发展提供了重要的理论和实践基础。

在IBM商业系统12中编译霍恩子句规则

7. 迁移到嵌套关系模型

完整的Prolog使用函数符号构建复杂项来表示复杂实体，这与嵌套关系模型中的结构有相似之处。将编译方法迁移到嵌套关系模型是一个具有挑战性但有价值的扩展方向。

在嵌套关系模型中，关系可以包含其他关系作为属性值，这种结构能够更自然地表示复杂的数据和关系。对于Prolog中的复杂项，我们可以尝试将其映射到嵌套关系模型中的嵌套结构。

具体的迁移步骤如下：
1. 识别复杂项 ：在Prolog程序中，找出使用函数符号构建的复杂项。例如， person(name(John), age(30)) 就是一个复杂项，其中 name 和 age 是函数符号。
2. 设计嵌套关系结构 ：根据识别出的复杂项，设计对应的嵌套关系结构。对于上述例子，可以设计一个 person 关系，其中包含 name 和 age 两个嵌套关系。
3. 转换规则 ：将Prolog规则转换为适用于嵌套关系模型的规则。在转换过程中，需要考虑如何处理嵌套结构的查询和操作。例如，对于查询 ?- person(name(John), Age) ，需要将其转换为在嵌套关系模型中查找 name 为 John 的 person 记录，并返回其 age 属性。
4. 实现查询和操作 ：在嵌套关系模型中实现对嵌套结构的查询和操作。这可能需要使用一些特定的嵌套关系代数运算符，如嵌套投影、嵌套选择等。

下面是一个简单的示例，展示如何将Prolog规则转换为嵌套关系模型中的规则：

Prolog规则	嵌套关系模型规则
ancestor(X, Y) :- parent(X, Y).	在 ancestor 关系中，若 X 和 Y 满足 parent 关系，则 X 是 Y 的祖先
ancestor(X, Y) :- parent(X, Z), ancestor(Z, Y).	在 ancestor 关系中，若存在 Z 使得 X 是 Z 的父节点，且 Z 是 Y 的祖先，则 X 是 Y 的祖先

8. 温和否定的使用

Prolog支持使用否定子目标，通过失败即否定策略实现；而关系数据库模型中通过 DIFFERENCE 运算符提供了一种较弱的否定形式。因此，研究是否可以在接口中添加一些“温和”的否定运算符使用方式是有意义的。

在Prolog中，否定子目标的语义是：若一个子目标无法被证明，则认为其否定为真。例如， not(person(John)) 表示 John 不是一个人。在关系数据库中， DIFFERENCE 运算符用于计算两个关系的差集。例如， R1 - R2 表示在 R1 中但不在 R2 中的元素。

为了在接口中添加温和否定的使用，可以考虑以下步骤：
1. 定义温和否定的语义 ：明确温和否定的含义，例如，在某些情况下，只否定部分属性或只在特定条件下进行否定。
2. 设计否定规则 ：根据定义的语义，设计适用于接口的否定规则。例如，可以定义一个规则：若某个属性的值不在某个范围内，则认为该属性的否定为真。
3. 实现否定操作 ：在关系数据库中实现温和否定的操作。这可能需要结合 DIFFERENCE 运算符和其他关系代数运算符。

下面是一个简单的示例，展示如何使用温和否定：

假设我们有一个 person 关系，包含 name 和 age 两个属性。我们想要找出年龄不在 20 到 30 岁之间的人。可以使用以下步骤：
1. 定义一个 age_range 关系，包含年龄在 20 到 30 岁之间的记录。
2. 使用 DIFFERENCE 运算符计算 person 关系和 age_range 关系的差集。

age_range = SELECT * FROM person WHERE age BETWEEN 20 AND 30;
not_in_age_range = person - age_range;

9. 约束逻辑编程扩展

数据库中的数值若不能进行计算则用处不大，理想情况下希望数据库系统能具备电子表格程序的功能，通过符号表达式进行数值计算，这一功能扩展在如今的约束逻辑编程领域得到研究。

约束逻辑编程（CLP）结合了逻辑编程和约束求解的思想，允许在程序中使用约束条件来限制变量的取值范围。在数据库系统中引入约束逻辑编程扩展，可以使数据库系统能够处理更复杂的数值计算和约束条件。

具体的扩展步骤如下：
1. 定义约束条件 ：在数据库中定义约束条件，例如， age > 20 AND age < 30 表示年龄在 20 到 30 岁之间。
2. 集成约束求解器 ：将约束求解器集成到数据库系统中，用于求解约束条件。常见的约束求解器有Choco、Gecode等。
3. 扩展查询语言 ：扩展数据库的查询语言，使其能够支持约束条件的查询。例如，在SQL中添加 WHERE 子句来指定约束条件。
4. 优化查询执行 ：优化查询执行过程，以提高约束查询的性能。例如，可以使用索引来加速约束条件的匹配。

下面是一个简单的示例，展示如何在数据库中使用约束逻辑编程：

假设我们有一个 person 关系，包含 name 和 age 两个属性。我们想要找出年龄在 20 到 30 岁之间的人。可以使用以下SQL查询：

SELECT * FROM person WHERE age > 20 AND age < 30;

在这个查询中， age > 20 AND age < 30 就是一个约束条件。数据库系统会使用约束求解器来求解这个约束条件，并返回满足条件的记录。

10. 总结与展望

从Prolog到关系数据库的转换以及相关功能扩展是一个不断发展和探索的过程。IBM的商业系统12（BS12）在这个过程中展现出了独特的优势，其代数完备性和单语言结构使其成为构建演绎数据库原型的理想选择。

递归、迁移到嵌套关系模型、温和否定的使用和约束逻辑编程扩展等功能的处理，为演绎数据库的发展提供了重要的理论和实践基础。然而，这个领域仍然存在许多挑战和问题需要解决。

未来的研究方向可以包括：
- 性能优化 ：进一步优化演绎数据库的性能，特别是在处理递归和复杂查询时。
- 新功能扩展 ：探索更多的功能扩展方向，如支持更复杂的否定形式、处理不确定性数据等。
- 与其他技术的集成 ：将演绎数据库与其他技术（如机器学习、大数据等）集成，以实现更强大的功能。

总之，演绎数据库作为一种结合了逻辑编程和关系数据库优势的技术，具有广阔的应用前景，值得我们继续深入研究和探索。

以下是整个编译及扩展流程的mermaid流程图：

graph LR
    A[Prolog程序] --> B[安全非递归霍恩子句翻译]
    B --> C[生成关系表达式和视图定义]
    C --> D[在BS12中执行]
    D --> E[功能扩展]
    E --> F1[递归处理]
    E --> F2[迁移到嵌套关系模型]
    E --> F3[温和否定使用]
    E --> F4[约束逻辑编程扩展]
    F1 --> G[应用Knaster - Tarski原则计算递归关系]
    F2 --> H[识别复杂项并设计嵌套结构]
    F3 --> I[定义温和否定语义并实现操作]
    F4 --> J[定义约束条件并集成求解器]
    G --> K[完成递归处理]
    H --> L[完成嵌套关系迁移]
    I --> M[完成温和否定使用]
    J --> N[完成约束逻辑编程扩展]

通过以上的流程和扩展，我们可以看到从Prolog到关系数据库的转换以及功能扩展是一个系统而复杂的过程，需要不断地进行研究和实践，以推动演绎数据库技术的发展。