关联数据库中多张表_关联数据

最新推荐文章于 2024-06-18 06:11:37 发布

cuyi7076

最新推荐文章于 2024-06-18 06:11:37 发布

阅读量1k

点赞数

文章标签：大数据编程语言数据库 python 人工智能

原文链接：https://www.ibm.com/developerworks/web/library/wa-data-integration-at-scale_linked-data/index.html

版权

本文介绍了如何利用RDF和SPARQL在关联数据库中处理多张表，实现大规模数据集成。作者详细阐述了Tim Berners-Lee提出的链接数据的四个原则，并通过DBpedia等案例展示了如何实现数据的链接和查询。文章还探讨了链接数据在数据集成中的优势和实际应用。

摘要由CSDN通过智能技术生成

关联数据库中多张表

在本系列的前两篇文章（“ 使用RDF创建数据网 ”和“ 使用SPARQL查询RDF数据 ”）中，您了解了资源描述框架（RDF）以及SPARQL协议和RDF查询语言（SPARQL）—两个万维网联盟（W3C）标准，用于创建可移植的，可查询的，网络友好的数据。通过RDF的图形模型，可以轻松地从各种来源收集有关主题的信息。现在，您知道如何通过HTTP将RDF数据提取给您以进行本地查询，或将查询推送到符合标准的服务器，以避免传输不相关的数据。在此大规模数据集成文章中，您将学习RDF和SPARQL如何与Web的体系结构相结合来创建和使用Linked Data 。

关联数据原则

为了鼓励在网络上发布数据的方式的一致性，Tim Berners-Lee定义了链接数据的四个原则：

使用统一资源标识符（URI）作为事物的名称。
使用HTTP URI，以便人们可以查找这些名称。
当某人查找URI时，请使用标准（RDF *，SPARQL）提供有用的信息。
包括指向其他URI的链接，以便他们可以发现更多内容。

关于本系列

本系列介绍，探索和应用全球标准，以解决开发人员，架构师和数据经理每天面临的大规模数据集成挑战。该系列涵盖的跨平台，独立于语言和与应用程序无关的技术使数据库，文档，电子表格和服务API中的信息集成成为可能。您将学习的数据模型和工具可以使您的工作更加轻松，并对您的组织产生实质性影响。

这些原则背后的动机在本系列文章中不需要太多解释，但是为了清楚起见，我将快速进行介绍。

首先，命名方案的目的是在共享上下文中进行引用。这些引用应一致，明确且无冲突。 URI标准提供了一种命名方案：一种用于创建命名方案的方案。只要您知道如何在系统中解析，表示和潜在地存储URI，就可以接受任何其他遵守该标准的系统的标识符。这样的系统可以包括今天编写和部署的代码，将来可以接受对新的，符合URI的名称的名称引用。

URN

URI的使用并不意味着ISBN对语义Web毫无用处。统一资源名称（URN）是URI的一种，它允许外部命名方案通过名称空间前缀映射到URI空间。一本书的有效URN可能是：urn：isbn：978-1608454303。

存在其他全局命名系统。常见的方案是国际标准书号（ISBN）。多年来，ISBN对于标准化书籍参考至关重要。该计划的成功主要是由于对命名系统的支持减少了书籍出版和发行市场的成本和错误。不幸的是，ISBN号仅指书籍。杂志，乐谱和视听产品（电影，电视节目，广播体育赛事）都有单独的标识符方案。可以使用诸如Dewey十进制分类系统的分层分类方案来指定书籍的主题，但这是另一个不兼容的标识符系统。可以通过ORCID标识符识别学术研究人员，但非学术界没有此类系统可用。因此，要表明某个特定的研究人员针对某个已知主题写了一本（学术）书，不仅涉及三个单独的标识符，还涉及三个单独的方案！有一个标准的方案来引用所有这些东西显然很有意义。

注意，Berners-Lee的指导并不是每个人都需要使用相同的 URI。您只需使用URI标准即可获得基本的互操作性。当人们确实同意如何称呼事物时，这是很好的，但并非必须如此。 RDF图中的节点和链接标识符均是如此。

其次，即使任何支持URI的系统都可以使用对外部数据集中URI标识符的引用，但是系统的用户可能无法识别该标识符。陌生的标识符需要一种方法来查找其指向的内容。为了找出有关命名实体的任何信息，摄取系统必须知道这种服务或有发现它的方法。结果，消费者应用程序必须支持使用特定命名方案的依赖关系和耦合。

第二个原则为交换数据增加了巨大的价值。如果您的系统可以使用URI（如果它们是可解析的URI（URL）），那么-要了解有关它们的更多信息，您可以将它们像其他任何Web资源一样对待，并向它们发出GET请求。不需要发现单独的服务，除了HTTP及其统一接口之外，没有新的依赖项。该名称既是标识符，也是您可以了解更多信息的句柄。

第三个原则阐明-除了解析资源时要返回的其他任何自定义格式外，如果您允许标准数据模型的标准序列化，则解析系统不需要了解任何其他信息即可解析结果结构。系统可能不知道标识符是什么，但是根据第二个原理，只要想了解更多信息，它就可以解析它们。除了标准的序列化格式之外，支持标准查询机制（例如SPARQL协议）的客户端还可以使客户询问您的数据问题。

“链接数据是一种根本不同的方法，可以在生产力，规模和灵活性水平上工作，如果您拥有的一切都是与企业和编程语言相关的解决方案，那么很难想象。 ”

因为第一个原则不需要使用标准标识符（仅使用标准标识符方案），所以可以确保在不同数据集中对同一事物赋予多个名称。这个问题可以通过多种方式解决，但是我不会花时间解释它的深度。通常，可以使用Web本体语言（OWL）中的owl:sameAs等高阶语义关系来永久地等同于标识符。从那时起，您可以使用理解OWL语义的任何推理系统来查询任何等效资源并从所有这些资源中获取属性。这里的重点是，这种机制为您提供了将术语与其他术语联系起来的方法。这样做可以丰富您的数据，并有助于支持数据集之间的可发现性。

总体而言，这些原则适用于公共和私人数据。不要将所有这些技术都看作只是要提供的免费公共数据。归根结底，它们都是Web资源，您可以将它们放在防火墙，收费墙以及身份验证和授权模型之后。目的是解决使用大规模工作的技术将各种数据源之间的信息连接起来的许多问题。与不基于网络友好标准的更昂贵，易碎且耗时的技术相比，实现该目标有助于将集成成本降低到几乎没有。

您只需要看Linking Open Data社区项目就可以看到这些想法的大规模实施。

链接开放数据项目

2007年，一小群人-链接开放数据（LOD）社区项目-开始连接一系列公共数据集。在图1中，您将看到捆绑在一起的前12个数据集-包括DBpedia ， GeoNames和美国人口普查信息。

图1. 2007年的Linking Open Data项目云

我将在一分钟内再谈DBpedia。现在，首先从DBpedia获得从Wikipedia中提取的有关加利福尼亚州奥本的信息。有关Auburn的其他信息可能是在2000年美国人口普查中收集的，而某些信息可能来自GeoNames项目。这三个数据集对同一事物（Auburn）使用不同的标识符，但是在后台进行了一些摸索之后，您可以看到DBpedia使用OWL sameAs关系来连接术语。现在，您可以使用这三个术语中的任何一个来通过基于OWL的推理器查询数据并检索所有结果。（同样，这种方法的工作方式和原因超出了本文的范围。）

在清单1中，Auburn的GeoNames项目中的URI等同于英语上下文中的Auburn DBpedia资源。然后，我将Auburn的Freebase标识符连接到DBpedia资源。最终，我将日语DBpedia语言上下文中的Auburn标识符连接到英语。此时，所有这四个名称都彼此等同。现在，将其中任何一个指定为主题的三元组都适用。

清单1.用OWL连接标识符

# Connecting the DBpedia resource for Auburn, CA to three other
# resources using owl:sameAs

@prefix owl:   <http://www.w3.org/2002/07/owl#> .

<http://sws.geonames.org/5325223/>
  owl:sameAs  <http://dbpedia.org/resource/Auburn,_California> .
<http://rdf.freebase.com/ns/m.0r2rz> 
  owl:sameAs  <http://dbpedia.org/resource/Auburn,_California> .
<http://ja.dbpedia.org/resource/オーバーン_(カリフォルニア州)>
  owl:sameAs  <http://dbpedia.org/resource/Auburn,_California> .

值得记住的是，这些数据集来自不同的组织，不一定由LOD项目的成员生成。但是它们是使用标准来表示的，这使得使各种客户都可以使用数据变得很重要。一些数据以RDF的形式本机存储在文件中，一些数据以三重存储形式存储，一些存储在关系数据库中，并根据需要作为RDF进行投影。链接数据技术的使用通常不会增加信息源的负担。这些技术仅仅是解放信息并将其轻松连接到相关内容的渠道。数据集之间的链接可以与其余内容结合在一起，也可以在链接集中保持分离。

请记住，在上一篇文章中，您可以通过SPARQL从多个数据源中收集信息，只需使用FROM关键字引用它们即可。现在，您可以想象不打乱原始数据，而是将标识符链接存储在文件中，如清单1所示，并参考SPARQL查询中的链接集，如清单2所示。对于查询而言，每个数据源中的术语都将包含在图中，并可用于基于推理的集成。

清单2.具有数据集和链接集的SPARQL查询

SELECT variable-list
FROM dataset1
FROM dataset2
FROM linkset
WHERE {
   graph pattern
}

LOD项目的最初12个数据集以这种方式连接。然后添加更多。然后更多。该项目增加了涉及学术研究引证的新数据集类别；生命科学; 政府生产的数据；有关演员，导演，电影，餐厅的信息；和更多。到2014年，已连接代表十亿个RDF三元组的570个数据集。您可以在图2中看到截止到2014年的LOD云图摘要。在启用SVG的浏览器中探索交互式版本将带来更多乐趣。如果单击大多数单独的数据集，您将被带到其相应的Datahub页面。

LOD云图

LOD图根据CC-BY-SA许可证发布，可从云的各个历史阶段获得。链接开放数据云图2014，作者：Max Schmachtenberg，Christian Bizer，Anja Jentzsch和Richard Cyganiak。

图2. 2014年的LOD项目云

其中许多数据集都使用来描述-还有什么？ —用于描述互连数据的RDF词汇表：互连数据集的词汇表（VoID）。谁生产的？他们什么时候上次修改的？他们多大？在哪里可以找到将它们连接到其他数据的链接集？ VoID描述回答了这些问题。

让我们更深入地研究这些数据源之一： DBpedia 。 DBpedia是从Wikipedia提供结构化元数据的最早尝试之一。 DBpedia的VoID描述将包含清单3之类的元数据。

清单3. DBpedia的示例VoID描述

@prefix void: <http://rdfs.org/ns/void#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix wv: <http://vocab.org/waiver/terms/norms> .        
@prefix sd: <http://www.w3.org/ns/sparql-service-description#> .
@prefix : <#> .

:DBpedia a void:Dataset;
    dcterms:title "DBPedia";
    dcterms:description "RDF data extracted from Wikipedia";
    dcterms:contributor :FU_Berlin;
    dcterms:contributor :University_Leipzig;
    dcterms:contributor :OpenLink_Software;
    dcterms:contributor :DBpedia_community;
    dcterms:source <http://dbpedia.org/resource/Wikipedia>;

    dcterms:modified "2008-11-17"^^xsd:date;
    .
    
:DBpedia_Geonames a void:Linkset
    ...
    .
    
:FU_Berlin a foaf:Organization;
    rdfs:label "Freie Universität Berlin";
    foaf:homepage <http://www.fu-berlin.de/>;
.
.
.

从描述中，您发现DBpedia是从Wikipedia中提取的信息。尽管Wikipedia上的大多数内容都是非结构化的，但该站点包含大量受编辑控制的结构。尤其是，文章中的信息框是一致的，并易于以结构良好的方式产生其信息。结果，使用来自119种本地化语言上下文的25亿个RDF三元组来独特地描述了超过1,260万种事物，其中包括：

830,000人
640,000个地方
370,000件创意作品
210,000个组织
226,000种
5,600种疾病

这些主题中的每一个都是具有自己可解析标识符的自身资源。在思考此处描述的主题的范围和多样性时，请记住，此多域数据集是由志愿者维护和策划的。它包括2500万个图像链接，2800万个文档链接和4500万个其他RDF数据集链接。将近四分之三的资源按来自多个本体的类别进行组织。

这些资源中的每一个都有一个逻辑标识符，一个HTML呈现的页面以及一个指向RDF / XML序列化的直接链接：

http://dbpedia.org/resource/Auburn,_California     # logical identifier
http://dbpedia.org/page/Auburn,_California         # HTML-rendered page
http://dbpedia.org/data/Auburn,_California.rdf     # direct RDF link

如果您单击指向逻辑资源的链接，则会将您重定向到HTML呈现的视图。发生这种情况的原因是，当您单击该链接时，浏览器会请求以HTML作为其首选来源的响应。 DBpedia服务器将您重定向到呈现的表单。从那里，您可以探索奥本与相关资源的联系，例如其报纸，所在县和在此出生的著名人物。

这些URI都是资源参考，并且使用从Wikipedia中提取的RDF描述每个资源。单击时看到的是RDF数据HTML呈现，而不是该资源的网页。例如， Auburn Journal拥有自己的网页，可以通过从报纸资源中删除http://dbpedia.org/ontology/wikiPageExternalLink关系来发现该网页。

我提到过，大多数DBpedia资源都来自多个本体。具体而言，这意味着资源是属于RDF资源的类的实例。如果仔细查看Auburn的资源页面，您会发现它是几个类的rdf:type ，包括：

请注意，这些是来自不同方案的不同类。通过断言新的rdf:type实例关系到任何有意义的地方，很容易看出可以随时添加更多类别。但是，这是一个集合成员关系。这意味着可以查询属于该集合（或该类的实例）成员的任何东西。如果点击http://dbpedia.org/page/Category:Cities_in_Placer_County,_California类别，则会看到Placer County的其他城市，包括Loomis ， Rocklin和Roseville 。在这里，您会看到一组相关城市，它们基于它们属于同一县的收容关系。

http://dbpedia.org/page/Category:County_seats_in_California类包含一个更大的类。在这里，加州各县的席位被归类在一起，通过关系，您可以从一个州到其他您知道的州。您正在浏览的链接实际上是在后台处理的隐式SPARQL查询。等效查询为：

SELECT ?s WHERE {
 ?s a <http://dbpedia.org/class/yago/CountySeatsInCalifornia>
}

因为DBpedia支持我在上一篇文章中介绍的SPARQL协议，所以该查询可以变成直接链接。扩展形式为：

http://dbpedia.org/snorql/?query=SELECT+%3Fs+WHERE+%7B%0D%0A+%3Fs+a+%3Chttp%3A \
%2F%2Fdbpedia.org%2Fclass%2Fyago%2FCountySeatsInCalifornia%3E%0D%0A%7D

现在，我将向您展示的一些内容组合到一个新查询中：

SELECT ?s ?page WHERE {
 ?s a <http://dbpedia.org/class/yago/CountySeatsInCalifornia> ;
 <http://dbpedia.org/ontology/wikiPageExternalLink> ?page .
}

我向上一个查询添加了一个额外的关系。现在要问的是：“告诉我加利福尼亚州的所有县城以及与之相关的外部网页。” 这是一个强大的查询，能够对从Wikipedia自动提取的数据进行汇总。您可以在此处查看结果。

现在，在查询中更改一件简单的事情。而不是查询属于http://dbpedia.org/class/yago/CountySeatsInCalifornia类成员的资源，请使用http://dbpedia.org/class/yago/CapitalsInEurope ：

SELECT ?s ?page WHERE {
 ?s a <http://dbpedia.org/class/yago/CapitalsInEurope> ;
   <http://dbpedia.org/ontology/wikiPageExternalLink> ?page .
}

结果在这里可用。仅更改类名称，什么都不会导致结果现在反映出与欧洲大陆国家的首都相关的外部网页！

如果我要更改的关系与以这种方式分类的资源链接，则可以提出另一个完全不同的问题。此查询询问纬度和经度信息，而不是外部链接：

SELECT ?s ?lat ?long WHERE {
 ?s a <http://dbpedia.org/class/yago/CapitalsInEurope> ;
   <http://www.w3.org/2003/01/geo/wgs84_pos#lat> ?lat ;
   <http://www.w3.org/2003/01/geo/wgs84_pos#long> ?long .
}
ORDER BY ?s

结果可在此处获得。

想象从这样的查询中检索信息并将其显示在Google Maps上应该不是什么大的飞跃。这样做的结果如图3所示，您可以在此处与结果进行交互。考虑一下要更改多少代码才能找到并可视化欧洲国家所有国家元首的出生地。（提示：几乎没有。）

图3.来自DBpedia的欧洲首都城市

现在您已经具备了相应的机制，不难想象如何提出关于任意域的其他类型的问题。我最喜欢的DBpedia查询（是我从Bob DuCharme那里得到的）是从“辛普森一家”的每一集中找到每个黑板上的插科打ag。当您单击该链接时，请记住，每个剧集也是一个资源，其中包含指向该剧集的导演，特别嘉宾，特色人物等的链接。每个情节被归类为特定年份的一组电视节目的成员。通过关注这些课程的成员链接，您可以找到大致在同一时间播出的其他电视剧集。

在这一点上，DBpedia可以提出的问题种类有限。并且请记住，DBpedia只是LOD云中近600个数据集之一。链接数据只需花费很少的人力即可产生令人印象深刻的结果。

结论

考虑您的组织需要多长时间来集成单个新数据源。链接数据是解决问题的根本不同方法，该问题可以在生产力，规模和灵活性级别上起作用，如果您拥有的所有解决方案都是与企业和编程语言相关的解决方案，则很难想象。关于此方法的任何内容均不限制其适用于面向公众的数据。您可以轻松地在防火墙后面应用相同的想法。

链接数据片段

一群人提出了一种称为链接数据片段的新方法，以解决可靠查询链接数据的问题。这不是一个标准化的方法，但是它有很多很棒的想法，我鼓励您研究一下。

链接数据不是魔术。解析为标准数据模型的标准序列化的标准标识符是一组简单的概念（尽管可能不是直观的）。但是，从工程角度看，在网络上公开支持SPARQL协议是一件非常困难的事情。很难预测随机个体将对您的服务器施加什么样的负载。为了保持DBpedia的正常运行，我们付出了巨大的努力。您可以在网站上阅读有关该过程的更多信息。

在下一篇文章中，我将向您介绍基于这些思想的软件平台，最后开始向您介绍选择沿着这一道路前进的开放服务生命周期协作（OSLC）技术。

翻译自: https://www.ibm.com/developerworks/web/library/wa-data-integration-at-scale_linked-data/index.html

关联数据库中多张表

cuyi7076

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫