Sam*_*Sam 40 semantic-web sparql relational-database jena
我想知道在关系数据库中使用Triple Stores有什么好处？
Ste*_*ris 46
商业CTO在商业上广泛使用RDF Triplestores的观点:
架构灵活性 - 可以对RDF实体进行架构更改,而不需要任何停机或重新设计 - 这不是免费午餐,您需要小心软件的工作方式,但这很容易去做.
更现代化 - 通常通过HTTP查询RDF存储,很容易将它们安装到服务架构中,而不会出现黑客桥接解决方案或性能损失.他们还比典型的SQL数据库更好地处理国际化内容 - 例如,您可以使用不同语言的多个值.
标准化 - 使用RDF和SPARQL的实现标准化水平远高于SQL.可以将一个三元商店换成另一个三元商店,但你必须要小心,不要超出标准.在商店之间移动数据很容易,因为它们都使用相同的语言.
表达性 - 在RDF中比在SQL中建模复杂数据要容易得多,而查询语言使得更容易执行LEFT JOIN(在SPARQL中称为OPTIONAL)之类的操作.相反,如果您的数据非常表格,那么SQL就容易多了.
源代码 - SPARQL允许您跟踪每条信息的来源,并且您可以存储有关它的元数据,让您轻松地执行复杂查询,仅考虑来自某些日期范围的来自某些来源或具有特定信任级别的数据等等
但有一些缺点.SQL数据库通常更加成熟,并且具有比典型RDF数据库更多的功能.像交易这样的东西往往更粗糙,或者不存在.此外,存储在RDF v的SQL中的每单位信息的成本明显更高.很难概括,但如果您拥有大量数据,这可能会很重要 - 尽管至少在我们的情况下,考虑到灵活性和功能,这在整体上是有利的.
Mic*_*ael 10
两个评论者都是正确的,特别是因为语义Web不是数据库,它比这更通用.
但我想你可能意味着三重存储,而不是一般的语义网,因为三重存储v.关系数据库是一个更有意义的比较.我将通过注意到我不是关系数据库系统的专家来解释我的其余部分,但我对三重存储有一点了解.
三(或四)存储基本上是语义网上数据的数据库,特别是RDF.这就是三元组商店和关系数据库之间的相似性结束的地方.两种商店数据都有查询语言,两者都可以用来构建应用程序; 所以我想如果你眯着眼睛看,它们非常相似.但是每个存储的数据类型都是完全不同的,因此这两种技术针对不同的用例和数据结构进行了优化,因此它们并不是真正可以互换的.
许多人已经完成了在关系数据库之上覆盖世界三重视图的工作,这可以工作,并且还比专用于存储和检索三元组的系统慢.部分问题是,三重存储使用的标准查询语言SPARQL可能需要大量自连接,而关系数据库并未进行优化.如果您查看基准测试,例如SP2B,您可以看到,与其本身支持RDF的系统相比,Oracle在其关系系统上只覆盖了SPARQL支持,运行在中间或后端.
当然,如果他们对关系数据进行SQL查询,那么RDF系统可能会被Oracle粉碎.但这就是重点,您选择的工具非常适合您要构建的应用程序.
因此,如果您正在考虑构建语义Web应用程序,或者只是想在该领域熟悉一下,我建议最终选择专门的三重存储.
我不会深入研究推理以及它如何在三重存储中进行查询回答,因为这是另一个讨论,但它是关系系统和三重存储之间进行推理的另一个重要区别.
一些三重存储(Virtuoso,Jena SDB)基于关系数据库,只是提供RDF/SPARQL接口.因此,为了重新解释这个问题,三重商店是从三头商店建立起来的,而不是那些没有的三重商店 - @ steve-harris肯定知道答案;)但我打赌是的.
其次,三重存储具有RDBMS不具备的功能.简单的答案是支持SPARQL,RDF,OWL等(即语义Web技术堆栈)并使其公平对抗,更好地定义基于SPARQL 1.1的SPARQL值(它具有比1.0更多的功能) .这为联邦提供了支持(如此酷),属性路径表达式和蕴涵制度以及一套标准的更新协议,图形管理协议(SPARQL 1.0没有,而且非常缺乏).此外,@ steve-harris指出交易不是标准(蠕虫病毒)的一部分,尽管许多供应商提供非标准化的交易机制(Virtuoso支持JDBC和Hibernate兼容的连接池和管理以及Hibernate的所有事务功能)
我认为最大的缺点是没有多少三层商店支持所有SPARQL 1.1(因为它仍然不在推荐中),而这正是真正的好处所在.
话虽如此,我一直都是一个用三重存储和平台替代RDBMS的倡导者,我提供了完全脱离三重存储的运行(大众汽车在我的上一个角色就是一个例子),不赞成对RDBMS的需求.另一个优点是,对象到RDF的映射比传统的ORM(也称为在圆孔中放置方形挂钩)更灵活,并提供更多选项和灵活性.