er图转换为关系模型的方法_一种模型驱动的关系数据库知识图谱构建方法

00

摘要

    关系数据库是构建垂直领域知识图谱的主要数据源之一。如何建立关系数据库中概念与知识图谱中相应概念之间的映射关系，是提高垂直领域知识图谱构建效率的关键。针对这一问题，本文提出了一种基于模型驱动体系结构(MDA)的从关系数据库中自动构造知识图谱的模型驱动方法。首先，提出了一个模型驱动的框架，用标准XML模式描述关系数据库和知识图谱。然后，提出了一种模型驱动方法，将数据库模型和数据提取为XML，定义转换函数，将数据库中的模型和数据转换为知识图谱，并根据表示形式构建知识图谱。最后，通过实例验证了该方法的有效性。本文采用模型驱动的思想，实现了关系数据库到知识图谱的高质量转换。

01

介绍

      知识图谱是利用图模型来描述知识与建模世界之间关系的一种技术方法。它由节点和边[1]组成。节点代表世界上的一切事物，边代表一切事物之间的关系。近年来，知识图谱在语义搜索、智能问答、语言理解等领域发挥着越来越重要的作用。垂直领域知识图谱是面向特定领域的知识图谱，通常采用自顶向下的构造方法来构造。领域专家利用proté gé、 WebOnto等本体编辑工具构建领域知识，通过对领域的理解来填充具体数据。一方面，手动操作会浪费大量的时间和精力。另一方面，很难保证领域专家知识的完整性和正确性。如何从数据中自动地、高质量地获取领域知识成为一个难题。

      垂直领域知识图谱的源数据主要来自非结构化数据、半结构化数据和结构化数据。非结构化数据中存在大量的领域无关信息，干扰了领域知识的提取。如果要构建一个完整的领域知识，就需要大量的文本支持，而且构建效率低[2]。半结构化数据主要是百科全书数据或web数据，其中包含一定的结构化信息。它有助于知识的提取。结构化数据具有严格的结构化信息，大多存储在关系数据库中。通常，每个域或企业都有自己的关系数据库。领域知识比较完整。从关系数据库中提取领域知识可以有效地提高建立垂直领域知识图谱的正确性。目前，相关的标准和工具支持关系数据库数据转换为RDF数据、OWL本体等。W3C的RDB2RDF工作组发布了两种映射语言:DM[3](直接映射)和R2RML[4]。许多OBDA (Ontology Based Database Access基于本体的数据库访问)系统支持以知识图谱的形式直接访问关系数据库，如D2RQ、Mastro等。本文提出了一种从关系数据库中构造垂直领域知识图谱的方法，并从企业关系数据库中获取知识。本文提出了一种从关系数据库中构造垂直领域知识图谱的方法，并从企业关系数据库中获取知识。

02

相关工作

      W3C的直接映射规范定义了从关系数据库到RDF图数据的简单转换，并为定义和比较更复杂的转换[5]提供了基础。R2RML映射语言是一种表示从关系数据库到RDF数据集[6]的自定义映射的语言。两者之间的区别是直接映射只能使用数据库模式元素的名称，而R2RML可以灵活地使用定制的目标视图。除了简单地从关系数据库中提取数据外，一些学者还关注从关系数据库中提取语义关系。基于文献[7]中教育信息的关系数据库使用D2RQ映射工具从数据中提取语义元数据。参考文献[8]提出了一种基于随机森林发现和转换数据库实体之间语义关系的方法，将关系数据转换为RDF。

OWL作为描述知识图谱的另一种语言，也得到了国内外的研究。参考[9]通过提取关系模式和数据实例，形成本体和对应的实例数据，并使用OWL语言构建本体。参考[2]提出了OWL本体的自动构建方法，实现了从关系数据库到OWL本体的自动构建。除了关系数据库的转换，参考文献[10]引入了ER模型转换为OWL本体的方法，参考文献[11]引入了XML模式到OWL本体模型的转换方法，参考文献[12]引入了XML模式到RDF的转换规则。

03

基于模型驱动的知识图谱构建框架

       OMG发布了模型驱动体系结构(model driven architecture, MDA)来解决软件开发过程中的非标准问题。MDA是一种构造业务逻辑抽象模型和自动生成完整应用程序的方法。MDA分为四层，即元-元模型层、元模型层、模型层和实例层。基于模型驱动的知识图谱构建方法适用于数据源为关系数据库的垂直领域。数据的特点是具有严格的结构信息，能够很好地实现模型和数据的提取和转换。知识图谱可以看作是一种半结构化数据。利用统一的描述语言，可以屏蔽不同类型的关系数据库和知识图谱之间的差异，然后利用建立的规则实现转换。从数据源到知识图谱的转换需要基于模型驱动的数据源和知识图谱的详细描述和转换规则的制定。转换如图1所示。

      数据源包括各种关系数据库，如MySQL、Oracle等。这些数据库有自己的定义语言和相应的元模型元素。用户使用元模型元素构建不同的场景来解决行业需求。实例层是特定场景中的特定数据，由用户根据模型设计填充。

      知识图谱逻辑上分为两层:模式层和数据层，分别对应于MDA的模型层和实例层。在数据层，知识以事实为单位存储，其基本形式为“实体-关系-实体”和“实体-键-值”三元组。实体通过关系相互连接，形成网络化的知识结构。模式层高度精炼了数据层的知识。知识图谱也有多种存储形式。这三种存储形式都有自己的定义语言，定义的元模型元素是围绕三元组展开的。本文所述的知识图谱也指不同类型的知识图谱存储形式。

图1 从数据源到知识图谱的转换

04

基于XML的建模方法

4.1.元元模型层描述

本文采用XML Schema作为元-元模型层的描述语言。我们使用XML Schema来描述元模型层所需的元素和关系。我们利用元模型层的元素和关系来描述模型层和实例层形成XML文件。为了更好地定义元模型层，我们将XML模式抽象模型定义为一个五元组[13]，如公式(1)所示。

                       (E,A,T,P,C)                          (1)

在公式(1)中:·

·E是一个集合包含所有XML模式元素名称。

·A是一个集合，它包含XML模式中的所有属性名。我们使用@作为属性前缀。

·T是数据类型的集合，它指定了XML模式中所有数据的类型。T分为简单数据类型(ST)，复合数据类型 (CT)和空数据类型 (ET).

·类型函数P,P(A)=T指定A中的属性的数据类型，P(E)=T指定E中元素的数据类型

·属性包含函数C, C(E)=[a1，…，an]。E中的每个元素都包含一组属性，并且这些属性不重复。

4.2数据库元模型层描述

我们将各种关系数据库中使用的元素和关系描述如下:

·数据源是关系数据库,和根元素被定义为’database’。

·对于'database'，它使用属性'source'， 'version '，'dbName'和'dbType'来标识源，版本，名称和类型。如果‘database’表示模型层，‘dbType’的值就是‘model’，如果‘database’表示实例层，‘dbType’就是‘Data’。

·元素'database' 包含多个子元素'table'。·

·'table' 包含的实体表表示具体的事物和关系表,表示事物之间的关系。对于' table'，我们使用属性' tableName '来标识它的名称。元素'table'包含多个子元素“row”和“foreignKey”。

·我们使用元素'row'来表示模型层中的定义或实例层中的数据。元素'row'包含一个或多个子元素'column'。

·元素“列”代表一个字段。我们使用属性' colName '和'colType '来标识名称和类型。如果在模型层中，“列”可以用默认值填充。·元素“foreignKey”反映了各个表之间的关系,它包含子元素‘fkName’，‘fkField’，‘fkCitedTable’和‘fkCitedField’。

·元素“fkName”代表关系的名称。元素' fkField '表示由表中的关系指定的字段。元素' fkCitedTable '表示与该关系关联的表。元素' fkCitedField '表示表中与该关系关联的字段。我们可以使用这四个元素来确定两个表中特定数据之间的关系。

根据上述描述，我们使用五元组来描述数据库。

·元素定义:

·属性定义:

·数据类型定义

·类型函数定义:

·属性包含函数定义:

使用Altova XMLSpy绘制元素和关系，如图2所示

图2  数据库的元模型层

4.3 知识图元模型层描述

      因为不同的知识图使用不同的表示方式，比如Neo4J使用节点、关系、属性的概念，而RDF使用资源、属性、关系的概念。通过分析，我们发现它们的基本概念是三元组，因此我们在定义知识图元模型的元素时使用三元组。我们对它们的描述如下:

·根元素是‘knowledgeGraph’。

·我们使用属性“kgType”来区分元素“knowledgeGraph”是模式层还是数据层。“kgType”有两个可选值，即“Model”和“Data”。我们使用属性“kgName”来标识名称。

·元素“knowledgeGraph”包含多个子元素“entity”和“relationship”。

·元素‘entity’指的是上面提到的实体概念。它使用“entityType”属性来确定其类型。如果是数据层的具体数据，需要用‘entity name’属性来命名。“entity”包含多个子元素“property”。

·元素“relationship”是指实体之间的关系。属性“relationName”用于确定关系名，子元素“head”和“tail”用于确定关系的两个实体。

·元素“property”表示实体的属性，这是上面提到的“key-value”的概念，使用属性“key”指定键。

根据以上描述，我们使用五元组来描述知识图。

使用Altova XMLSpy绘制元素和关系，如图3所示

图3 知识图的元模型层

05

从数据库到知识图的转换规则

      在定义了元模型层的元素和关系之后，就需要在特定的场景中转换模型和实例。模型层的转换规则由元模型层的元素对应关系决定，模型层的转换决定了实例层的转换。

      从数据库到描述文件，基本上存在一对一的对应关系，这在4.2节中进行了描述。如果具体到某一数据库，则对模型或数据的提取方式的描述是不同的，因此我们在此不再描述。

      知识图谱描述与知识图的对应关系在章节4.3中描述。为了将描述文件转换为知识图，需要将描述文件中的模型和数据提取出来，结合不同知识图的特点形成相应的模型和数据。

      本章的重点是数据库描述与知识图谱描述的对应关系。我们定义多态函数β，如式(2)所示，其中D、ED和AD表示数据源描述，元模型元素和属性，K、EK和AK表示知识图描述，元模型元素和属性。

β(D)=K ,D={ED,AD},K={EK,AK}                    (2)

表1 数据库与知识图之间的对应关系

06

物流领域的一个案例

        在本文中，我们使用MySQL数据库和Neo4J图形数据库在具体场景中验证了该方法的正确性。我们设计了一个后勤验证场景，其中MySQL模型和数据如图4所示。共6个表，关系如下。

·表' province '的外键' country_id '与表' country '的' id '相关联。

·表‘ city’的外键“province_id”与表“province”的“id”关联。

·表“district”的外键“city_id”与表“city”的“id”关联。

·表“price”的外键“start_id”和“end_id”与表“city”的“id”关联，外键“company_id”与表“company”的“id”关联。

图4 MySQL的模型和数据

图5 Neo4J的模式和数据

      转换后，模型和数据在Neo4J中获得，并以图形的形式显示。如图5所示，圆圈代表不同类型的实体，线条代表关系。实体的属性包含在实体中，不反映在图形中。

      在图5中，左侧是模式层，右侧是数据层。“country”表对应于Neo4J模式层中的实体“country”，其数据“China”对应于Neo4J数据层中的实体“China”。其他表和实体之间的对应关系类似。表“province”的外键“国家_id”对应于实体“province”和实体“country”之间在Neo4J的模式层中的关系，以及实体“ShanDong、”和实体“China”之间在Neo4J的数据层中的关系。其他关系也差不多。

07

结论

      本文利用模型驱动的概念，将关系数据库转化为知识图谱，将分散的知识图形化，可以帮助用户更好地理解领域知识；用XML和XML Schema描述数据源和知识图谱，实现了从数据源到知识图谱的转换。实验结果表明，该方法能够很好地实现垂直领域知识图谱的构建。