10、编译IBM业务系统12中的Horn子句规则：声明性的早期实验-优快云博客

编译IBM业务系统12中的Horn子句规则：声明性的早期实验

1 伟大的构想

演绎数据库诞生于20世纪80年代，源于三种在70年代末走向成熟的技术的融合：
- 关系数据库 ：到1980年，关系数据库已成为数据库技术的首选模型。其成功的主要原因在于它基于一个易于理解的数学模型，具有清晰的概念语义，关系是域的笛卡尔积的子集。
- 人工智能 ：由于专家系统的初步成功，人工智能再度受到关注。
- 逻辑编程 ：随着Prolog语言的普及，逻辑编程的概念在人工智能领域，甚至在整个计算机科学领域都变得十分突出。

人们发现，尽管这三种概念信息处理方法在概念框架上存在显著差异，但它们在信息存储和组合方式上有相似之处。于是，便产生了用一个领域的计算策略替代另一个领域较慢方法的想法。例如，可以使用关系数据库系统的数据库引擎来计算Prolog中回溯产生的结果。

这种技术的交叉融合为所有相关领域带来了巨大的前景：
- 数据库对人工智能的助力 ：数据库在处理原始数据方面比基于解释的Prolog系统强大得多，数据库技术的一些附加优势，如安全性、共享性和持久性，几乎可以免费为人工智能所用。
- Prolog对数据库的助力 ：数据库技术可以从Prolog的声明性中受益，在Prolog中可以引入新的概念，并像直接存储在系统中的概念一样使用它们。这也为向数据库提供数据结构信息和约束的异构临时形式主义提供了一种单语言替代方案。

1.1 舞台

关系数据库

关系数据库模型由Codd提出，其成功的关键在于基于清晰的数学模型，关系是域笛卡尔积的子集。它可用于描述实体及其关系，系统设计师的概念世界可映射到关系数据库方案，这是数据库基础课程的基本内容。

关系在数学中用于表示一阶谓词逻辑中谓词的含义，因此自然地使用一阶逻辑作为讨论数据库内容的语言。到1980年，合适的一阶谓词逻辑片段已被描述，如今以不同语法方言被称为域演算或元组演算，SQL语言的核心就是元组演算的一种方言。

这些演算可用于根据数据库中存储的原始关系对派生关系进行声明性描述。派生关系通过对原始关系进行合适的代数运算来求值，这些运算存在于被称为关系代数的数学结构中，常见的关系运算包括选择、投影、并、积、（自然）连接和差。查询优化器的任务是为给定的逻辑或代数表达式生成具有最优处理成本的等效表达式。

然而，关系数据库模型存在一个重要缺点，即在域级别缺乏抽象机制，一个观察者认为的原始值对另一个观察者可能是复合结构化对象。关系模型中属性值仅从原子值组成的域中选择，对复合结构化值的需求催生了嵌套关系模型。计算机行业则走向了另一个方向，面向对象世界中复合结构化对象是常态，通过使其持久化得到面向对象数据库，但这样一来，数据库的所有附加功能都需要重新创建，同时也失去了关系模型的良好特性，尤其是其清晰的数学语义和声明性。对象 - 关系数据库试图保留两者的优点。

数据库系统的主要目的是提供一个安全、稳定和持久的环境，让用户群体可以并发地访问、查询和更新大量共享数据，数据库技术主要关注实现这些“附加”功能的技术问题。

人工智能与逻辑编程

本文中的人工智能项目是涉及某种形式的符号逻辑推理的项目，其他重要的人工智能活动，如自然语言处理、图像处理、机器人技术、知识表示和提取或对人类思维模型的计算研究将被忽略。

在人工智能早期发展中，符号推理和定理证明的研究人员使用一阶谓词逻辑作为通用表示语言，基于归结的定理证明器有时能取得合理的结果。归结是一种定理证明策略，与人类使用的策略不同。该策略需要几个步骤，将假设和（否定的）结论的逻辑表达式转换为从具有项作为参数的文字构建的子句集合，然后对得到的项列表进行迭代的合一、替换和归结步骤，目标是推导出空子句。如果成功，则得到一个反驳证明，表明否定的结论与假设不一致，从而证明所需结果；如果归结证明失败，计算得到的替换可用于构建结论的反模型。

但归结策略具有高度的不确定性，不定子句会导致需要探索所有情况的分支结构，而且子句中项的迭代替换可能导致组合爆炸。最糟糕的是，该方法是不完备的，因为一些可满足的公式只有无限模型，在归结证明中永远无法完全搜索到。

在许多实际情况中，这种组合爆炸不会发生，这使得人工智能的实际工作成为可能。原因是经常使用的公式属于Horn子句片段，即最多只有一个正文字的子句。这种性质将子句可以进行归结的可用文字数量减少到最多一个，从而消除了组合爆炸的一个重要来源。归结方法的不确定性可以被现在称为SLD归结的确定性深度优先搜索回溯策略所取代。Prolog语言实际上将Horn子句片段的SLD归结作为其计算模型。

如果从Prolog中去除项中的函数符号（以及许多位于计算核心之外的具有副作用的内置谓词），就得到了现在被称为Datalog的“纯”核心语言。Prolog的一个优点是其声明性，Prolog程序是一阶公式的列表，表达了要构建的模型的结构，只是用一种相当非常规的谓词逻辑方言编写。同时，存在一个Prolog解释器来实际构建规则描述的模型，用户无需关心解释器如何获得结果。但需要注意的是，它与普通数学家使用的逻辑解释有重大语义差异，在谓词逻辑中，一组公式描述了一族模型，而Prolog解释器产生一个首选的最小模型，对于人工智能工作者来说，这并不是问题，因为他们本来就寻找最小模型作为解释，而且这种最小模型也被认为是（关系）数据库内容的自然解释。

Prolog受欢迎的一个重要原因是20世纪80年代初日本选择它作为第五代项目的工具，这对全球计算机科学研究产生了影响。逻辑编程领域致力于对上述直观概念进行研究和形式化，直到20世纪90年代初，才出现了一种完全令人满意的、没有语法和语义交互错误的逻辑编程理论的数学正确形式化。

1.2 参与者

我们用人类家庭关系的传统例子来说明上述不同计算机科学领域的相似性和差异。

考虑“Dorothy是Jessica的姑姑”这一陈述，它可能有两种不同的关系：Dorothy是Jessica父母之一的姐妹，或者Dorothy的丈夫Fred是Jessica父母之一的兄弟，甚至可能两种关系同时存在。姐妹关系也是一个定义关系，Dorothy是Thomas的姐妹，因为他们有共同的父母且不是同一人，并且Dorothy是女性。父母关系和婚姻关系是未根据其他关系定义的关系，人的性别、出生日期和姓名也是如此。假设存在一组称为“人”的实体，并且可以通过姓名来识别他们，这些概念在谈论家庭关系时被认为是基本概念。进一步区分，性别、出生日期和姓名是人的一元属性，而父母关系和婚姻关系是二元关系，婚姻关系具有混合性质，它连接两个人，同时本身也是一个具有结婚日期（可能还有终止日期）等属性的实体。

一阶逻辑表示

可以用一阶逻辑来表达这些关系，例如：

parent(Gerti; Jessica) ∧ sister(Gerti; Dorothy) → aunt(Dorothy; Jessica)

或者使用逻辑变量，写成更通用的规则：

∀G, J, D [parent(G, J) ∧ sister(G, D) → aunt(D, J)]

姐妹关系的规则类似：

∀X, Y, Z [parent(Z, X) ∧ parent(Z, Y) ∧ X ≠ Y ∧ female(X) → sister(X, Y)]

关于原始关系的信息通过原子断言来表达，如 female(Gerti) 或 parent(Gerti, Jessica) 。

Prolog表示

在Prolog中，相应的规则如下：

aunt(D,J) :- parent(G,J), sister(G,D).
sister(X,Y) :- parent(Z,X),parent(Z,Y),X \= Y, female(X).
female(X):- person(X,'F',Any).

这里，蕴含的顺序被颠倒，并且省略了量词（按照惯例，自由变量被理解为全称量化）。基本信息以事实的形式存储在Prolog数据库中，实际上就是程序中的一行行代码，例如：

person(Gerti,'F',19240713).
marriage(Fred,Dorothy,19411013).

这表明实体的一元属性以类似于数据库元组的格式编写，而不是使用一组一元谓词。

关系数据库表示

在关系数据库模型中，人由一个存储的数据库表表示，其结构可以用如下的结构声明来表达：

PERSON(NAME:STRING(20),GENDER:{'M','F'},BIRTH:NUM(8) # KEY(NAME) )

Gerti可以用 PERSON 表中的一个元组 (Gerti,F,19240713) 来表示。其他描述父母关系和婚姻关系的基本关系也由关系表示：

PARENT(PAR:STRING(20),CHILD:STRING(20) # KEY(PAR,CHILD) )
MARRIAGE(HUSB:STRING(20),WIFE:STRING(20),DATE:NUM(8)
# KEY(HUS,DATE), KEY(WIFE,DATE) )

通过插入适当的元组，可以描述基本的家庭关系。

当我们希望计算机系统推导出“Gerti是Jessica的姑姑”这一事实时：
- Prolog查询 ：可以提交查询 ?- aunt(Dorothy,Jessica) ，Prolog解释器使用SLD归结，首先发现Gerti是Jessica的父母，然后尝试解决确定Dorothy和Gerti是姐妹的子目标，最终通过调用姐妹关系的规则成功，在此过程中还会推断出Dorothy是女性。
- 关系数据库查询 ：需要发明一个表示姑姑关系的代数或逻辑关系表达式。例如，姐妹关系可以描述为：

SISTER(A,B) =
SEL( PROJ(( PARENT(X,A) JN PARENT(X,B) ,(A,B) ), A ≠ B )
JN PROJ( SEL(PERSON(A,G,Arb), G = ‘F‘, (A) )

这个复杂的表达式必须与父母关系连接，以获得姑姑关系的两个贡献关系之一。一旦构建了姑姑关系的视图定义，就可以在数据库上对其进行求值，希望在结果表中出现元组 (Dorothy,Jessica) 。如果数据库中有大量人员，提交一个从描述姑姑关系的视图中选择元组 (Dorothy,Jessica) 的查询可能更有利，数据库优化器可以将选择操作下推到代数表达式中，从而减少中间结果的大小和查询的处理时间。

这个例子说明了声明性的含义：在Prolog中，我们只需指定规则，系统就会自动找到解决方案；而在关系数据库中，在提交正确的查询之前，需要进行大量的思考。

1.3 剧目

在上述例子中，Prolog方法具有一定程度的声明性。然而，如果Prolog推理过程在一个大量事实的数据库上运行，其计算过程可能效率低下。而且，Prolog系统没有实际的数据库系统支持，其事实数据库直接存储在程序中，因此无法获得数据库技术的附加优势，如持久性、安全性和共享性。

声明性也是数据库接口语言SQL的一个特性。由于SQL声称具有关系完备性，应该可以用它来表达与Prolog中定义等效的内容。然而，得到的表达式会比Prolog中的复杂得多。更糟糕的是，在1982年左右可用的SQL版本中，由于缺乏并运算符，无法用一个表达式表达姑姑关系，需要一个过程来计算这个关系。

即使数据库接口语言真正具有关系完备性，仍然存在如何获得所需关系表达式的问题。在Prolog中，就像在数学和逻辑中一样，一个复杂的定义会扩展成一系列更简单的定义，最终归结到基本概念。在关系数据库中，对应的特性应该是一个视图定义可以扩展成一系列其他视图定义，最终到达直接存储在数据库中的表。这要求视图定义能够像存储的关系一样容易调用，而1982年左右的数据库系统并不具备这一特性。

下面用mermaid流程图展示关系数据库中计算派生关系的过程：

graph TD;
    A[原始关系] --> B[代数运算];
    B --> C[派生关系];
    C --> D[查询优化];
    D --> E[结果输出];

技术领域	优点	缺点
关系数据库	处理原始数据能力强，有安全性、共享性和持久性	缺乏抽象机制，构建查询表达式复杂
Prolog	具有声明性，易于表达规则	计算效率低，缺乏实际数据库支持

1.4 编译方法构建演绎数据库

为了克服Prolog和传统关系数据库各自的缺点，我们可以采用编译的方法将Prolog规则编译到现有的数据库系统上。具体步骤如下：
1. 规则提取 ：从Prolog程序中提取Horn子句规则。例如，对于之前提到的家庭关系例子，提取出 aunt(D,J) :- parent(G,J), sister(G,D) 等规则。
2. 规则转换 ：将提取的Horn子句规则转换为关系数据库能够理解的代数表达式。以 aunt 规则为例，需要将其转换为类似于前面描述的关系代数表达式。
3. 表达式优化 ：使用查询优化器对转换后的代数表达式进行优化，以降低处理成本。
4. 数据库集成 ：将优化后的表达式集成到现有的关系数据库系统中，使其能够利用数据库的计算能力和附加功能。

下面是一个简单的mermaid流程图，展示了编译Prolog规则到关系数据库的过程：

graph TD;
    A[Prolog程序] --> B[规则提取];
    B --> C[规则转换];
    C --> D[表达式优化];
    D --> E[数据库集成];
    E --> F[演绎数据库];

1.5 项目实践

在1984年的一个项目中，我们将Prolog的一个片段编译到了现有的数据库系统上。具体来说，我们选择了IBM在荷兰开发的业务系统12（Business System 12），该系统于1983年投入使用，具有合适的功能。

项目目标

我们的目标是构建一个原型系统，实现演绎数据库的功能，即能够根据存储在数据库中的原始关系和编译后的规则推导出新的关系。

项目实现步骤

确定目标数据库系统 ：选择IBM业务系统12作为目标数据库系统，因为它具有良好的性能和稳定性，并且支持关系代数运算。
规则编译 ：将Prolog的Horn子句规则编译为关系代数表达式，并在业务系统12上实现这些表达式。
系统测试 ：使用家庭关系等示例数据对原型系统进行测试，验证其能够正确推导出派生关系。

项目成果

通过这个项目，我们成功地构建了一个演绎数据库的原型系统，证明了将Prolog规则编译到关系数据库系统上的可行性。该原型系统不仅能够利用数据库的强大计算能力，还能够提供Prolog的声明性编程优势。

1.6 功能扩展探讨

虽然我们的原型系统已经实现了基本的演绎数据库功能，但仍然有许多方面可以进行扩展。以下是一些可能的扩展方向：
1. 支持更复杂的规则 ：目前的原型系统只支持简单的Horn子句规则，未来可以扩展到支持更复杂的规则，如带有否定和递归的规则。
2. 增强查询功能 ：可以增加对更复杂查询的支持，如聚合查询、排序查询等。
3. 与其他系统集成 ：将演绎数据库与其他系统，如自然语言处理系统、机器学习系统等集成，以实现更强大的功能。

下面是一个列表，总结了功能扩展的方向：
- 支持更复杂的规则
- 增强查询功能
- 与其他系统集成