使用RDF和本体重新思考数据库架构

最新推荐文章于 2023-02-08 10:31:14 发布

danpu0978

最新推荐文章于 2023-02-08 10:31:14 发布

阅读量450

点赞数

文章标签：数据库大数据 python mysql java

10年前加入该行业时，我的第一个项目使用关系数据库。之后，我的下一个项目也使用了关系数据库。您可能会猜到，我的下一个项目也使用关系数据库。这种情况持续了很长时间，以至于我几乎忘记了表只是一种存储数据的格式。

四年前，当我的公司慢慢转向BigData分析和知识管理时，我才发现自己对其他类型的数据库感兴趣。这些年来，我对RDF和Ontology的了解使我急于重新考虑和重新思考构建数据库的方法和原则。

在本文的范围内，我将仅将思想集中在数据库架构的作用上。即使您对RDF和Ontology一词不熟悉，也请不要担心，我将尽力在本文中介绍这些概念。

背景

图表作为知识数据库

众所周知，创建关系数据库始于定义数据库架构。不管选择哪个数据库，我们仍然需要在插入数据之前定义表，列和任何外键。显然，我们需要在制作数据之前决定数据的外观。

但是，这对于我们构建知识数据库时不适合。因为系统假设存储的是未来的知识而不是当前的知识，所以无法弄清楚数据的外观。因此，我们将重点从关系数据库中移出，并寻找其他解决方案。

有许多NoSQL数据库可以支持无模式数据，但是大多数数据库都不符合我们的要求，因为我们要存储链接的数据。因此，图数据库似乎是我们最感人的选择。

资源描述框架

市场上的一轮购物使我们感到不安，因为查询语言还没有被广泛采用的标准。如果选择图形数据库，则最终可能会写出特定于供应商的实现，这似乎不是一个好的开始策略。

为了找到一些通用标准，我们设法找到Resource Description Framework，这是一个W3C规范，用于对Web资源中的信息进行建模。对于我们来说，这似乎是最好的选择，因为资源描述框架带有一种非常简单的机制来描述资源链接。唯一的副作用是，每个资源都需要由URI标识。

例如，要描述Apple生产的iPhone 5（售价为600美元），我们需要生成两个如下所示的三元组。

<http://example.org/Apple> <http://example.org/produce> <http://example.org/iPhone5>
<http://example.org/iPhone5> <http://example.org/price> '600 USD'@en

我们对使用URI作为资源标识符没有兴趣，但是仍然需要这样做以符合标准。但是，我们不能责怪RDF，因为它是为Web发明的。作者梦dream以求的是，我们可以按照资源的URI进行检索。显然，这个想法没有实现。

将RDF的原始想法放在一边，对我们来说，主要的好处是查询语言SPARQL。例如，要弄清楚任何苹果手机的价格，查询应为：

select ?phone ?price where {
       <http://example.org/Apple> <http://example.org/produce> ?phone .
       ?phone <http://example.org/price> ?price
}

但是，RDF只是一个概念。为了使用RDF和SPARQL，我们仍然需要找到一个不错的API或实现，最好使用Java。这导致我们选择了2个受欢迎的选择，即芝麻和Apache Jena。两种API均被广泛接受，并具有多种供应商实现。更好的是，一些供应商为他们两个提供了实现。

本体论

在上面的示例中，很容易看到要进行有意义的查询，我们需要知道数据的外观。因此，我们仍然最终应该拥有某种数据模式。但是，此架构应更像元数据，而不是数据定义。通常，我们不需要在插入数据之前预先定义架构。

为了解决这个问题，有两种策略。人们从为RDF定义通用词汇开始。因为大多数时候，我们已经知道资源之间的关系，但不知道资源本身，所以词汇表应该足以帮助形成SPARQL查询。但是，由于描述世界的范围很广，因此没有一个词汇足以表达每个领域。因此，存在许多领域特定的词汇表。

虽然第一种方法仅处理描述资源之间的可能关系，但是第二种方法也尝试描述资源。例如，为了描述上一个示例中的资源，我们可以定义一个名为智能手机的类和一个名为制造商的类。此后，我们可以指定制造商可以生产电话。

<http://example.org/Apple> <http://example.org/type> <http://example.org/Manufacturer>
<http://example.org/iPhone5> <http://example.org/type> <http://example.org/Phone>
<http://example.org/Manufacturer> <http://example.org/produce> <http://example.org/Phone>

上面的那些三元组构成一个本体。与词汇相比，我们发现本体是描述数据模式的一种更具描述性的方式，因为它可以告诉我们哪种关系适用于哪种资源。因此，我们不会浪费时间弄清楚iPhone 5是生产Apple还是Apple生产iPhone 5。

本体加RDF是构建知识数据库的不错选择。虽然存储库可以是可以容纳任何三元组的RDF存储，但是我们可以在单独的空间中构建另一个本体以对主存储库中的知识进行建模。

从我们的角度来看，最好使用本体来形成查询而不是数据验证，因为这将有助于稍微分离数据和架构。实际上，只要不矛盾，插入不适合本体的数据是完全可以接受的。

例如，使用前面定义的本体，我们应该允许插入诸如

<http://example.org/Apple> <http://example.org/produce> <http://example.org/iPod>
<http://example.org/Apple> <http://example.org/produce> <http://example.org/iPad>

但是我们可以拒绝任何知识，例如：

<http://example.org/iPhone5> <http://example.org/produce> <http://example.org/Apple>

使用这种方法，我们可以先导入数据，然后再建模。

数据库架构

令人耳目一新的想法

将我们建立知识数据库与关系数据库的方法联系起来，使我感到，在数据插入之前定义数据模式的要求是由实现驱动的。如果我们暂时忘记了诸如数据索引之类的实际问题，则可以先插入数据，然后再定义数据模式。

这也让我想到了对同一数据具有多个数据模式是否可行。首先，这个想法听起来很尴尬，但如果我们看一下建模世界的艰巨任务，那将是相当现实的。例如，如果我们认为奥巴马是美国总统，我们可能会在意他何时开始任职，他何时离职；但是，如果我们将奥巴马视为其他任何美国公民，那么我们会更在乎出生日期，居住区，安全号码等……这样，该方案将成为我们检查和修改资源的视角。

因此，如果我可以回到人们讨论数据库通用查询语言的时代起，我建议向SQL添加一些功能以丰富它，或者引入一种不太严格的新型查询语言：

允许没有表定义的插入。根据插入命令参数自动创建表定义。
使记录的ID对每个数据库唯一，而不是对每个表唯一。一条记录可以出现在许多具有相同ID的表中。插入命令需要指定哪个字段是记录的ID。
数据定义更通用，没有大小限制（varchar和int代替varchar（255）或int（11））。
select命令必须符合表定义。
可以在两个表之间共享同一记录的字段。

在总结本文之前，让我们尝试快速构建一个可以实现这些扩展功能的数据库。底层存储系统可以是任何无模式引擎，但是为了简单起见，我们可以使用RDF存储。

要求

将奥巴马插入美国公民表格，并输入姓名，年龄和性别。标识符字段是名称。
将奥巴马姓名，年龄和当选年份插入美国总统表。标识符字段是名称。
使用字段名称和年龄定义美国公民表。
用名称，年龄和当选年份定义美国总统表。
从“美国公民”表中选择记录将仅显示姓名和年龄，因为表定义中未定义性别。
用新的年龄更新奥巴马在美国总统表中的记录将影响美国公民表中的年龄，因为这是一个共享领域。

实作

步骤1

SQL： 插入公民（姓名，性别，年龄）值（“巴拉克·奥巴马”，“男性”，53岁）
三元组：
- <巴拉克·奥巴马> <类型> <公民>

第2步

SQL： 插入总统（姓名，当选年份）值（“ Barrack Obama”，“ Male”，53）
三元组：
- <巴拉克·奥巴马> <类型> <总统>

第三步

SQL： 创建表citizen（“名称” varchar，“ age” int，主键（“名称”））
三元组：
- <公民> <字段> <名称>

第四步

SQL： 创建表总裁（“名称” varchar，“ elected_year” int，主键（“名称”））
三元组：
- <总统> <字段> <名称>

第5步

SQL：从公民中选择*
SPARQL： 选择？record？field_name？field_value，其中{
- 记录<类型> <公民>
}

第6步

SQL： 更新主席设置年龄= 54，其中名称=“巴拉克·奥巴马”
用<巴拉克·奥巴马> <年龄> 54覆盖<巴拉克·奥巴马> <年龄> 53

结论

我认为，如果听众不熟悉RDF或本体论，那么上面的一些想法将难以理解。不过，我希望它能引起更多关于弥合关系数据库和知识数据库之间差距的想法。

翻译自: https://www.javacodegeeks.com/2015/05/rethinking-database-schema-with-rdf-and-ontology.html

danpu0978

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
使用RDF和本体重新思考数据库架构

10年前加入该行业时，我的第一个项目使用关系数据库。之后，我的下一个项目也使用了关系数据库。您可能会猜到，我的下一个项目也使用关系数据库。这种情况持续了很长时间，以至于我几乎忘记了表只是一种存储数据的格式。四年前，当我的公司慢慢转向BigData分析和知识管理时，我才发现自己对其他类型的数据库感兴趣。这些年来，我对RDF和Ontology的了解使我急于重新考虑和重新思考构建数据...
复制链接

扫一扫