使用UIMA和DB2数据库进行的文本挖掘 （7）

   来源：IBM developerWorks 中国网站    作者：知识管理技术主管

将 UIMA_RELATIONS 视图创建为两个 SQL 选择语句的联合。一个选择语句为 “Mentioned_in” 谓词创建行，另一个为 “Has_name” 谓词创建行。第一个选择语句将人和文档联系起来。它从 EIDB 中的 INSTANCES 表中取出人实例，并通过与其他表进行联结，寻找提到这个人实例的文档。证据 URI 是文档 URI。第二个 SQL 选择语句为 “Has_name” 谓词创建行，它将人实例与他们的名字字符串联系起来。因为这个谓词所需的所有信息都在 INSTANCES 表中，因此构造一个证据 URI 指向这个表中的相关行。

　　Preston 中的数据挖掘要寻找关联，它需要定义另一个视图 MINING_VIEW，这个视图的格式根据下面描述的 DB2 Intelligent Miner 工具的需求进行定义。它是通过对 UIMA_RELATIONS 视图进行自我联结建立的。挖掘视图只包含两列，见 表 2。第一个列是人可读的实体标识符，在这个例子中是人名。第二个列是出现此人的 “事务” 的惟一 ID。在这个例子中是提到此人的文档的 URI。

表 2. MINING_VIEW 视图的模式。两个列的类型都是 VARCHAR。

列名	说明
name	一个描述实体的字符串，例如一个 人实例的名字。
transaction_id	出现此实体的事务的惟一标识符， 例如文档的 URI。

　　如果我们考虑到关联挖掘最初的动机 —— Market Basket Analysis，那么事务 ID 的重要性就很明显了。如果把购物篮（Market Basket，例如超级市场中的购物车）看作 “事务”，把它的标识符看作事务 ID，那么关联挖掘就可以用来寻找购物车中两个或多个商品之间的关联。在 Preston 中，文档相当于购物车，文档中提到的人相当于购物车中的商品。如果还有其他关系，尤其是采用 “人-关系-人” 形式的二元关系，那么关系实例相当于购物车，关系中的主体和对象是购物车中的商品，事务标识符是关系实例的标识符。

　　关联挖掘的输出是一组采用以下形式的规则

　　entity1, entity2 => entity 3

　　这表示，在一个事务中如果同时存在 entity1 和 entity2，那么 entity3 可能以一定的概率存在。这个例子是一个长度为 3 的规则。在 Preston 中，我们寻找的规则只是将两个人联系起来，比如：

　　personA => personB,

　　这种规则的长度是 2。这个规则的强度表示 personA 和 personB 在同一个文档中一起出现的可能性。强度的几种度量由关联的挖掘算法进行计算。