从关系数据库到关联数据：W3C标准应用探析，本文主要内容关键词为：探析论文,关系论文,数据库论文,标准论文,数据论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
DOI：10.13663/j.cnki.lj.2015.05.014 0 引言 RDF(Resource Description Framework，资源描述框架)是W3C为促进语义万维网(Semantic Web，简称语义网)的应用而推出的一系列标准规范，包括RDF抽象模型和一组RDF编码格式规范如Turtle、N-Triples、JSON、N-Quod等[1]。RDF有利于数据的共享、重用和语义互操作，越来越多的系统和应用开始利用RDF改造底层数据的结构。而大量遗留系统中的数据存储在RDB(Relational Database，关系数据库)中，如何方便、快捷且准确地实现“关系数据库中的数据(RDB格式)转换成RDF数据格式(这个过程简称为RDB2RDF)”，是实际应用中经常被关注的问题。W3C因而成立了RDB2RDF工作小组，制定了DM(Derect Mapping，直接映射)和R2RML(RDB2RDF Mapping Language)这两个标准，来规范RDB2RDF的实现，已于2012年6月成为W3C的推荐标准。两年来，这两个标准已在一些关系数据库产品和许多RDB2RDF工具中得到应用，也有了一些实际应用案例。本文从关系数据库、RDB2RDF工具、实际应用案例这三个方面对DM和R2RML这两个标准规范的应用进行调研，并对各自的应用效果进行比较和分析，为基于关系数据库的语义应用提供参考。 1 DM和R2RML：作用与用法 W3C的RDB2RDF工作组推荐了两种RDB2RDF映射语言DM和R2RML，用于定义关系数据库中的数据如何转换为RDF数据的各种规则，包括URI的生成、RDF类和属性的定义、空节点的处理、数据间关联关系的表达等。[2] DM是直接映射的方式，它将关系数据库表结构和数据直接输出为RDF图(RDF Graph，可看做是多个三元组的集合)，该RDF图完全是关系数据库数据结构的反映，关系数据库中的一个表转换为一个RDF类(Class)，一个字段转换为一个RDF属性(Property)，用于表示类和属性的术语与关系数据库中的表名和字段名保持一致。DM映射一般会由程序自动生成。[3] 与DM不同的是，R2RML有高度的可定制性和灵活性，R2RML为RDB2RDF映射定义了系统性的逻辑框架，提出“逻辑表”(Logical Table)的概念，将关系数据库中的一个表、一个视图，甚至是一个有效的SQL查询定义为“逻辑表”，这就突破了关系数据库表的物理结构的限制，在生成RDF数据之前，就可以对RDB中的数据进行计算处理、筛选、清洗和整合，为不改变数据库原有的结构而灵活地按需生成RDF数据奠定了基础。R2RML映射一般作为一个可人工编辑的文本文件存在，以Turtle句法和格式编码，可将关系数据库的数据结构与已有的本体词表映射。通过R2RML映射，一个关系数据库可输出为一个RDF图，该RDF图中所用到的类名和属性名可来自己有的本体词表，如FOAF、DC、SKOS等，可灵活地根据具体需求选取现有本体词表中的术语。如需改变映射规则，R2RML文件可方便地由人工编辑。[4] RDB2RDF映射在实际应用系统中的实现一般有两种模式，Juan F.Sequeda在2013年的国际语义网大会(ISWC2013)的培训[5]中介绍了这两种模式，如图1所示。在有的应用系统架构设计中，需要将从RDB中转换而来的RDF数据集导出到本地后，再导入专业的RDF存储库(RDF Store，也叫TripleStore)，这种方式即也叫“抽取—转换—装载”(Extract Transform-Load，ETL)，简称为ETL模式。由于原有系统的数据仍在不断更新，这种方式往往无法实时提供最新的数据。在另一种应用系统架构设计中，只需提供一个虚拟的RDF数据视图和SPARQL查询接口，并返回RDF数据查询结果，即在原有服务器上增加一个RDF数据封装层(即图中的Wrapper System)；而在数据查询时，大多会经历将前台SPARQL查询请求根据事先定义好的映射规则转换成SQL查询语言，再将查询结果转换为RDF数据的过程，本文称为“实时转换”模式，这种模式往往会对系统的性能提出更多的考验。
图1 RDB2RDF的两种实现模式[5] 以上两种模式各有利弊，视具体需求而定。由于在实际应用中，如何设计RDB2RDF的实现方案、如何选择RDF数据存储和管理工具、如何提供数据消费服务，与RDB2RDF的实现模式有较为密切的关系，因而在考察几种关系数据库产品和各种RDB2RDF工具平台对DM和R2RML实现的方式时，对这两种模式的支持将作为一个重要考察点。 2 在关系数据库中的应用 关系数据库作为数据的存储和管理系统，其成熟稳定的功能和性能，仍被大量应用系统采用。虽然它并不是最适合RDF数据的数据管理系统，但仍有大量的数据存于其中，对于那些仍在生长和使用中的应用系统来说，最好能在不改变原有系统业务流程和数据结构的情况下，提供RDF数据和基于RDF数据的语义应用，这就要求从原关系数据库中适时生成或导出RDF数据，会涉及RDB数据格式到RDF数据格式的转换，即RDB2RDF。对于大多数关系数据库，均可通过第三方插件或工具实现RDF数据的管理和RDB2RDF的转换，本小节主要调研Oracle、IBM DB2、SQL Server、MySQL、PostgreSQL目前流行的几个关系数据库本身内置的对RDF数据管理的支持，尤其是对RDB2RDF的支持，以及是否支持W3C的两个推荐标准DM和R2RML，而通过第三方插件或工具实现RDF数据管理和RDB2RDF将在第4节中详细分析。 本小节的调研分三个层次：(1)数据库产品本身是否支持RDF数据的存储和SPARQL检索和更新？(2)数据库产品本身是否支持以RDB2RDF的方式生成或导出RDF数据？(3)如果支持RDB2RDF，是否支持W3C的DM或R2RML标准？ 2.1 Oracle 在几个商用数据库产品中，Oracle对RDF的支持最为突出，目前Oracle有两种方案来存储和检索RDF数据，一种基于RDB，另一种基于NoSQL。前者的代表产品是Oracle Spatial and Graph，是本文调研的主要对象。该产品除了支持地理空间数据外，还支持面向语义网和关联数据应用的RDF数据存储管理和SPARQL检索，支持原生RDF数据的创建、已有RDF数据的导入，也支持RDB2RDF方式，即存储在关系数据库表中已有的数据，根据事先定义的映射规则，实时转换为RDF数据，在转换规则的定义上，支持W3C的DM和R2RML标准。 根据Oracle技术文档[6]第10节中的说明，Oracle提供一组API——SEM_APIs来支持语义网应用，其中SEM_APIS.CREATE_RDFVIEW_MODEL这个API可以支持RDB2RDF的实现，该API可根据默认的映射规则DM，或根据用R2RML自定义的映射规则，生成虚拟的RDF视图并通过一个名为SEM_MATCH的API对RDF视图执行SPARQL查询。当使用DM时，只需要指定需要转换成RDF数据的表名以及RDF图的前缀和命名空间，即可根据默认的DM规则生成RDF视图。当使用R2RML时，需定义一个基于R2RML语法的映射文件，一般用Turtle格式编写，SEM_APIS.CREATE_RDFVIEW_MODEL这个API首先将该文件转换为N3格式并存储在数据库的一张表中，然后读取映射规则生成RDF视图。 这些虚拟的RDF视图并不存储真实的RDF数据，如果需要物理地存储RDF视图中的RDF数据，可以通过API从RDF视图中导出RDF数据并存储在Oracle的数据库表中。SEM_MATCH支持对RDF视图中的RDF数据进行SPARQL查询，还支持将RDF视图中的数据与原生的RDF数据源整合在一次SPARQL查询中，进行联邦SPARQL查询。 2.2 IBM DB2 IBM于2012年宣布在DB2第10版的更新(DB2 LUW 10.1)中嵌入支持RDF存储和检索的功能，基于DB2的RDF Store(下文简称DB2-RDF Store)被IBM官方称为IBM DB2NoSQL Graph Store，虽然被称为NoSQL，但其底层仍然是DB2的关系数据库结构，它用几个特殊的表来存储RDF数据，并通过一些内置的RDF命令和API来实现RDF数据的支持，这些API是对Apache Jeana API的扩展。DB2-RDF Store分为两种：一种是基本型，适用于从零开始逐步创建RDF数据，另一种是优化型，适用于导入已有的RDF数据。创建、编辑或维护RDF Store需要用到DB2的RDF命令或API，主要利用Jena API来实现对RDF数据的更新和SPARQL数据查询。在DB2 Version 10.1Fix Pack 2之后的版本中，除了支持SPARQL查询外，已可以支持SPARQL 1.1 UPDATE。但未有资料显示DB2支持RDB2RDF的方式，当然也就不支持DM和R2RML这两个标准。[7] 2.3 MySQL和PostgerSQL 通过使用RDFLib插件，MySQL和PostgreSQL数据库支持RDF的存储和检索功能。RDFLib存储接口提供了一个MySQLMassLoader模块实现RDF数据的导入和存储，对RDF数据的检索和更新是由RDFLib-SPARQL处理器来完成的。RDFLib-SPARQL处理器的原理是在后台将SPARQL查询语句翻译成相同的SQL查询后再执行，可以支持SPARQL 1.1检索和更新。MySQL和PostgreSQL目前仅支持通过第三方插件或者API来实现RDF数据的存储、检索和更新，不支持DM和R2RML这两个标准。 2.4 Microsoft SQLServer Microsoft SQLServer自嵌的配置文件管理器(Profile Manager)组件可以支持把RDF格式的配置信息存储到SQL Server数据库中。配置文件管理器只能存储特定的用户、服务或应用程序所需的属性。在把配置文件信息存储到数据库之前，连接服务框架(CSF)配置文件管理器会解析传入的数据，并转换成RDF三元组。配置文件管理器支持使用简单协议和SPARQL查询来检索。通过使用分面功能，配置文件管理器可优化检索性能。 Semantics.Server 2.0是基于Microsoft SQL Server存储RDF的解决方案，它利用SQL Server的搜索引擎和内存管理来支持RDF数据存储和SPARQL检索。目前不支持RDB2RDF的方式及DM和R2RML这两个标准。 综上所述，关于第一个问题：Oracle、SQL Server、IBM DB2这三种商业数据库产品，均已公开发布了支持RDF数据管理的产品及相应的技术文档。而两个开源的数据库MySQL和PostgreSQL可通过第三方API支持RDF数据的存储和管理。关于第二个问题：只有甲骨文公司的产品Oracle Spatial and Graph可以以RDB2RDF的方式生成和导出RDF数据。关于第三个问题：只有甲骨文公司的产品Oracle Spatial and Graph在RDB2RDF的过程中支持W3C的DM和R2RML标准，见表l。
3 在RDB2RDF工具中的应用 除了数据库本身内置了支持RDB2RDF的功能外，利用第三方RDB2RDF工具是一个更为灵活的选择。在W3C的RDB2RDF孵化小组的调研报告[8]中，分析了15种工具，这种工具较多，大部分为开源，且每种常见的数据库都能找到相应的工具。在DM和R2RML成为W3C的推荐标准后，RDB2RDF工作小组发布了实施报告[9]，列举了参与过测试的8种工具，也有一些支持这两种标准的RDB2RDF工具没有参与过测试，如R2RML Parser。其中有的同时支持DM和R2RML两种标准，有的只支持其中一种，大部分都支持实时转换模式，支持ETL模式的有5种。除ultrawrap是capsenta公司开发的商用产品外，其他都是开源的，各种工具的总体情况见下表2。 以下选取几个典型的RDB2RDF工具作简要介绍和分析。 D2RQ是DM和R2RML出现之前，最为人熟知的RDB2RDF开源工具平台，由著名的语义技术研究开发机构DERI和惠普实验室等机构开发维护。它包括D2R Server和一种私有的RDB2RDF映射语言D2Rq。D2R Server是一个HTTP Server，用于接收系统前端的SPARQL请求并作出响应。D2Rq提供一种可定制的映射语言，将RDB数据映射成RDF数据模型。D2R Server的SPARQL接口基于SPARQL协议，从前端传过来的SPARQL查询请求被D2R Server转换成关系数据库的SQL查询请求，返回的结果被D2R Server转换成RDF数据。它并没有将RDB发布成真实的RDF数据，而是使用D2RQ映射文件将其映射成虚拟的RDF视图。在2012年发布的v0.8.1版本中，开始支持DM，但仍不支持R2RML。除了实时生成RDF之外，它有一个dump-rdf插件，可以根据默认或定制的映射将整个RDB数据库导出为一个单独的RDF文件，因而也支持ETL模式。[10] Virtuoso利用自有的“元数据方案映射语言”，来实现RDB数据与RDF数据的映射，生成关联数据视图(Linked Data Views)，得到RDF数据，这种功能与R2RML异曲同工，是R2RML诞生之前各种私有映射语言的一种。由于认识到R2RML已经成为W3C的推荐标准，基于R2RML来实现RDB2RDF将成为各种RDB2RDF工具的一种趋势，因而Virtuoso也开始支持R2RML。它采用间接的方式，通过安装一个名为R2RML VAD的插件，将R2RML转换成它自己的关联数据视图的语法，最终还是基于私有的RDB2RDF映射语言和内置的功能来实现RDB2RDF的转换。数据库管理员可在Virtuoso后台把已定义好的R2RML脚本导入到Virtuoso，系统执行映射规则，便可在其关联数据视图中查阅RDF数据。[11]从W3C的RDB2RDF实施报告中看出，Virtuoso的测试用例通过率是较低的，62个测试用例中，只有33个通过，其余29个为“cannotTell”。另外，它不支持R2RML的rr：sqlQuery，该句法用于对基于SQL查询的逻辑表进行RDB2RDF映射定义，是R2RML的一大功能特色，不支持此功能意味着放弃了R2RML在数据转换之前进行数据筛选和整合的灵活性。在RDF数据的生成上，Virtuoso只支持实时转换模式，不支持ETL模式。 Ultrawrap是Capsenta公司开发的一款专用于RDB2RDF的商业软件，目的是在语义网环境下，最大限度地开发和利用RDB的潜力，将RDB中的数据发布到语义网中。Ultrawrap是全面支持DM和R2RML这两个标准的平台之一，在W3C的RDB2RDF用例测试中，全部为“通过”状态。Ultrawrap包括两个主要组件：RDB2RDF映射编译器和服务器。前者负责编译RDB2RDF映射并生成RDF或OWL数据；后者负责接收SPARQL查询请求并返回数据。在RDF数据的生成上，它支持实时转换和ETL这两种模式。在性能上，Capsenta公司声称Ultrawrap能够充分地利用现有的SQL基础架构，特别是数据库自带的元数据和SQL查询优化器，可使SPARQL检索达到SQL检索同样的性能和速度。[12]在Berlin SPARQL Benchmark的测试中，分别基于Ultrawrap和原生RDB对包含l亿条三元组的数据进行查询的结果表明，Ultrawrap执行SPARQL查询的速度，与RDB执行SQL查询的速度相当[13]。
Morph是一组语义技术工具套件，由“本体工程工作组”开发和维护，包括RDB2RDF组件morph-RDB，支持R2RML，不支持DM。在RDF数据的生成上，它支持实时转换模式和ETL模式。在实时转换模式中，它需要根据已定义好的R2RML映射将前端的每一次SPARQL查询请求转换为相应的SQL查询请求；在ETL模式中，它需要根据已定义好的R2RML映射一次性地将RDB中的数据转换为RDF数据。Moreph-LDP是morph家族的另一个组件，可以看做是morph-RDB的一个扩展[14]。它试图实现W3C的另一个标准——关联数据平台(Linked Data Platform，简称LDP)[15]，LDP是对关联数据四原则的进一步明确和扩展，规定了如何在通过资源的URI获取更多关于资源的信息之外，还能对这些信息进行更新，包括更新的方式和权限控制等。Morph-LDP的目的是基于R2RML来实现LDP，使得RDB中的数据能无缝地集成到LDP环境中。它根据R2RML映射从RDB中生成的RDF数据以LDP的标准封装，呈现给前台，并接收和处理客户端发送的按照LDP标准封装的SPARQL查询或更新请求。 4 在实际项目中的应用 4.1 音乐大脑关联数据项目(LinkedBrainz) 4.1.1 项目背景和需求 MusicBrainz是一个开放的音乐维基百科，允许任何人贡献数据和内容并在网站上公开发布，系统基于RDB构建，可批量下载MusicBrainz数据库的数据及应用软件，数据为SQL格式，可导人PostgreSQL数据库中，MusicBrainz不仅公开发布了数据，还公开发布了数据结构(Next Generatiion Schema，NGS)和数据间的关系定义(Advanced Relationships，ARs)。在MusicBrainz数据库中，艺术家、专辑、作品等已经被赋予了唯一ID并拥有丰富的关联关系，已经被关联数据社区广泛利用，但并未直接提供关联数据服务。 LinkedBrainz项目的目的是将MusicBrainz数据库以关联数据的形式发布，其任务包括：为NGS和ARs转换为RDF数据建立映射；为MusicBrainz服务器增加内容协商的功能以为资源的URI提供“解引”(dereference)服务；提供一个SPARQL端点(Sparql Endpoint)以响应SPARQL查询请求。由于MusicBrainz是一个数据不断更新并持续提供服务的系统，因而LinkedBrainz项目面临的一个挑战是在将MusicBrainz发布为关联数据时，不能影响系统已有的功能。项目最终选择了简便易行的RDB2RDF的解决方案，而非直接修改系统原有代码或利用现成的软件将PostgreSQL数据库转换为RDF。
图2 利用R2RML实现MusicBrainz数据和音乐本体的映射[16] 4.1.2 利用R2RML 为了更明确地表达MusicBrainz数据库中各类数据实体间的关系，NGS和ARs需要与包括“音乐本体”(Music Ontology，MO)在内的一系列本体词表建立映射。在2013年举行的第一届“语义音乐媒体”国际论坛上，Peter Haase的报告[16]介绍了如何利用R2RML为NGS和ARs与MO定义映射。R2RML正好满足了LinkedBrainz实现RDB2RDF的需求，它允许将RDB数据结构映射到一个或多个本体词表。如下图2所示，MusicBrainz数据库中的表“Recording”映射为音乐本体(其命名空间前缀为mo)的一个类：mo：recording。 用R2RML将表artist映射到音乐本体的mo：MusicArtist类的代码如下：
其中rr为R2RML命名空间的前缀，rr：tableName定义了需要映射的RDB表，rr：class定义了该表映射到哪个类，rr：template定义了一个mo：MusicArtist实体的URI生成规则。 用R2RML将字段映射到音乐本体的属性的代码如下：
这里用到了rr：csqlQuery来作为一个逻辑表(rr：logicalTable)，用一个SQL语句来获取RDB中不同表的字段，而不是如上例中直接用数据库中已有的表。正如上文所述，R2RML的这种功能为不改变RDB的原有结构，而灵活地生成RDF数据提供了便利。rr：predicate定义了artist_name字段映射到FOAF本体中的foaf：name属性。 4.1.3 系统实现 Peter Haase的报告[16]和Barry Norton在EUCLID项目的培训课程[17]中介绍了LinkedBrainz的技术架构，如图3所示。
图3 LinkedBrainz的技术架构[17] 在转换模式上，采用了典型的ETL模式，首先利用R2RML映射规则将RDB数据结构与领域本体建立好映射，再利用R2RML映射引擎(也即上文提到的RDB2RDF工具)，根据R2RML映射文件生成的RDF数据，导入到专用的RDF存储库(也叫三元组存储库，即Triplestore)中，基于RDF存储库提供SPARQL查询服务，在RDB2RDF工具的选择上，采用了商业平台ultrawrap。 在EUCLID培训课件介绍的MusicBrainz关联数据演示系统上，基于向RDF存储库发送SPARQL查询请求并返回RDF数据的模式，实现了各种数据可视化效果，如不同的视图浏览数据、分面检索、可视化标签云图功能等。 4.2 布鲁塞尔语义云项目(OSCB) 4.2.1 项目背景和需求 布鲁塞尔语义云(Open Semantic Cloud for Brussels，OSCB)项目始于2011年2月1日，其目标是为比利时的布鲁塞尔地区所发生的大事、旅游线路、公交站点等数据建立一个关联数据发布和消费平台，以便不同的数据提供者能够方便地发布他们的数据，最终用户或应用开发者也能以一种通用直接而简单的方式来利用这些数据。数据提供者一般以关系数据库表或XML格式提供原始数据，该项目采用了基于R2RML将这些数据转换为RDF三元组的方式。因为数据包含了大量的时间和空间信息，需要提供一个可检索时空数据的SPARQL端点，并需采用基于地图的可视化方式来展示数据，因而需要将原关系数据库或XML文档中的数据实体映射到空间或时间本体中的相应概念，R2RML也正好可以满足这一需求。[18] 4.2.2 利用R2RML 文献[18]举了三个不同数据源的例子，来说明如何利用R2RML将关系数据库、XML、地理空间数据库转换为RDF三元组。 以下R2RML映射的作用是将XML数据映射为RDF三元组。该XML数据中保存了布鲁塞尔的一些文化事件以及与事件相关的机构。首先利用R2RML的逻辑表(rr：logicTable)的功能，将XPATH查询XML的结果当做一个逻辑表，语句rr：class gospl：Address将一条XPATH查询结果记录映射为地理空间本体(前缀为gospl)中的Address类，作为三元组的主体(Subject)，语句rr：predicate geo：geometry将geo本体中的geometry作为谓词(Predict)，语句rr：objectMap定义了该三元组的客体(Object)，其取值为XPATH查询结果中的"Institution_Full_Address"字段值。 以下映射将关系数据库中的某一站点信息转换为RDF数据。它将一条SQL查询结果当做一个逻辑表，这条SQL查询获取表stop中的字段值并将其中两个字段值合并成一个字符串，起到了生成RDF数据之前的数据处理作用。在三元组映射定义中，将一条结果记录映射为地理空间本体中的Location类，这里用了来自两个不同本体中的术语当做谓词 gospl：Location_with_Latitude和rr：predicate geo：geometry，将生成两个三元组。
4.2.3 系统实现 该项目基于R2RML映射以ETL的方式生成了包含空间和时间信息的RDF数据，以stRDF格式(spatiotemporalRDF)存储于名为Strabon的专用时空数据存储库中。Strabon也提供SPARQL端点，允许以stSPARQL(spatiotemporal SPARQL)语言查询存储库中的RDF数据.stSPARQL语言是对SPARQL语言的扩展，允许在SELECT，FILTER，和HAVING子句中以空间术语为参数来辅助查询。 由于有的数据提供者所提供的原始数据中的地址没有包含经纬度等地理空间信息，该项目还整合了各种外部关联数据集中的数据，如DBPedia、GeoNames和LinkedGeoData。系统先利用这些数据集所提供的数据消费接口获取所需数据，并转换为stRDF格式，存储于Strabon中。数据检索的返回结果可在地图上可视化地呈现。 5 结语 W3C的两个RDB2RDF标准自推出以来，得到了该领域研究者和应用者的关注，其开发者在ISWC等国际会议上提供详尽的培训，在多种RDB2RDF工具上得到应用，甲骨文公司这样资深的关系数据库提供商也在Oracle数据库的新产品中植入了DM和R2RML的支持，还有了LinkedBrainz和OSCB这样的实际应用案例，但其应用范围仍然较为狭窄，局限在特定的需求和环境下，而且作为一种新兴的标准规范，其推广和应用仍需时间和市场的考验。比如像D2R这样应用广泛RDB2RDF平台，已有自己成熟的映射语言(D2Rq)，除了只是象征性地支持了DM外，两年多来并没有支持R2RML的动作。随着原生的RDF存储库和各种NoSQL数据库技术的进一步成熟，并得到越来越广泛的应用，基于RDB2RDF的语义应用架构可能将作为一种过渡性的解决方案而退居一隅。但对于目前大量的数据仍保存在关系数据库中这样的现实，若要方便快捷地从RDB中获取RDF数据，采用RDB2RDF方法及利用DM和R2RML这两个标准仍不失为一种可行的选择。
标签：语义分析论文; 对象关系映射论文; 数据库系统论文; 数据检索论文; rdf论文; sql数据库论文; sql语言论文; db2论文;
从关系数据库到关联数据：W3C标准的应用分析_语义分析论文
下载Doc文档