联邦式知识图谱上的自然语言检索引擎数据库设计心得-T5队

根据我们小组讨论设计数据库的整个过程,可以将数据库的设计分为两个部分:准备部分、设计部分和总结部分。下面根据所分的阶段,对三个阶段所需的准备和注意事项进行阐述。

一、 准备部分:

设计工具

数据库的设计过程之中会使用到一些软件,在软件工程导论这门课上,周老师使用的是powerdesigner进行UML图的设计。数据库设计实验上讲授用powerdesigner来设计数据库。在学习使用该软件的时候,建议观看演示的视频进行学习,没有什么比实际的例子更加容易进行学习的了。

用例图

用例图在明确各类Actor的时候是非常有效的。通常会优先设计出用例图,有了用例图之后,就可以清晰项目所需要完成的功能。将这些功能进行模块的划分,再设计与之对应的数据库,是比较常用的一种思路。在进行模块划分的时候,不仅方便了数据库的设计,还会便于对类图、活动图的设计。在设计数据库的时候,对于不同的用户,相当于是功能操作的执行者,但是在设计cdm的时候,通常会陷入一种误区:cdm的每一个实体和实体之间仅仅是一种并列的关系,而不是和用例图一样是一种拥有功能的关系。

这个用例图是根据之前俞师杰同学的功能清单进行设计的,主要设计的人员是黄子峻同学。在设计完之后,小组的成员又进行了讨论和修改。

可以看到我们的项目之中,用户又两个类:游客和普通用户。其中普通用户衍生出一个管理员的用户的类。游客功能有注册和搜索。普通用户有用户搜索模式之下的登录、查看个人信息、查看历史记录、修改密码、修改手机号码,找回密码等功能。管理员用户在普通用户的基础之上还多了管理用户权限,查看在线用户和搜索其他用户历史记录的功能。看了别的组的用例图,实际上我们在这一部分的工作量和其他的组是差不多的。

后来边老师在群里说了,可以使用starUML,在使用了这个软件之后,发现starUML相比于powerdesigner来说,简直就是设计之光。更容易的操作,更简洁的图像。在上述的基础上,又重新用starUML设计了一个用例图来阐述我们的功能:

这个用例图是根据之前俞师杰同学的功能清单进行设计的,主要设计的人员是黄子峻同学。在设计完之后,小组的成员又进行了讨论和修改。

可以看到我们的项目之中,用户又两个类:游客和普通用户。其中普通用户衍生出一个管理员的用户的类。游客功能有注册和搜索。普通用户有用户搜索模式之下的登录、查看个人信息、查看历史记录、修改密码、修改手机号码,找回密码等功能。管理员用户在普通用户的基础之上还多了管理用户权限,查看在线用户和搜索其他用户历史记录的功能。看了别的组的用例图,实际上我们在这一部分的工作量和其他的组是差不多的。

后来边老师在群里说了,可以使用starUML,在使用了这个软件之后,发现starUML相比于powerdesigner来说,简直就是设计之光。更容易的操作,更简洁的图像。在上述的基础上,又重新用starUML设计了一个用例图来阐述我们的功能:

需求分析(文档)

需求分析是软件计划阶段的重要活动,也是软件生存周期中的一个重要环节。在这一环节,我们要考虑好我们需要实现的功能,基本明确功能和项目大体框架,为任务分配和项目设计做好铺垫。以我们的项目为例,对于个人中心的设计,在功能上自然是要实现“信息查询”、“信息修改”、“检索结果”等等,而数据库的设计自然是要围绕着这几个功能来设计。

二、  设计部分:

在数据库的设计部分最重要的就是进行概念数据模型的设计,即所称的CDM。

在设计CDM的初期的时候,因为数据库部分的图相比于其他的组会少一点,所以在设计的初期遇到了一些问题。于是,我们去咨询了数据库系统设计实验老师柳杨。因为我们在设计的时候,总是会在想一个主键只能在一张表中充当,然而柳杨老师说:数据库的设计需要主要还是需要根据用例图和原型来,有的数据库的设计并不是一定要严格的根据范式的要求,而是要根据实际的情况和功能来进行设计。这样的话给了我们不少的灵感。

1、 实体的建立:

CDM的建立中,最为重要的就是要确立实体,设计好实体的各个属性,实体的属性要符合实际情况,也要符合当前功能设计的需求。在进行普通用户和管理员部分设计的时候,组内产生了比较大的意见分歧,一部分认为应该建立一个实体,划分出权限这样的属性,一部分认为应该建立两个实体,因为它们的功能是不一样的。在经过和老师的讨论之后,觉得应该是两个更加的妥当。具体如下:

建立好CDM的第二部,就是要确立好实体之间的关系,对应于上述的用户信息表和管理员信息表,采用的方式为建立一个登录信息表和角色表将两个实体联系起来,这样就可以做到在进行登录时通过角色进行区分:

相较于普通用户,管理员所能查看的历史记录的内容是多于其他的表的,因此这个时候它们的历史记录的内容也是需要区分开的,都功能指向一个历史记录的实体,一个是可以查询自己的历史记录,一个是可以查询所有用户的历史记录。这些历史记录是对应于RDF数据集所提供的查询链接的:

注:1、这里所有展示图均为CDM生成的PDM,为了更加直观的效果。

1、 CDM和PDM的设计都是需要注意命名的规范,可以使用脚本一键完成。

2、 图数据库

这个项目的特殊的地方,在于数据库的一部分的内容需要设计为图数据库的,因为所需要处理的数据集是联邦式RDF的数据集,它们是无法用关系型数据库进行存储的,因此是设计为图数据库的形式。这次一共有9个图数据库,从github上有开源的别人建立的图数据库:

在需要描述大量关系时,传统的关系型数据库已经不堪重负。它所能承担的是较多实体但是实体间关系略显简单的情况。而对于这种实体间关系非常复杂,常常需要在关系之中记录数据,而且大部分对数据的操作都与关系有关的情况,原生支持了关系的图形数据库才是正确的选择。它不仅仅可以为我们带来运行性能的提升,更可以大大提高系统开发效率,减少维护成本。

在一个图形数据库中,数据库的最主要组成主要有两种,结点集和连接结点的关系。结点集就是图中一系列结点的集合,比较接近于关系数据库中所最常使用的表。而关系则是图形数据库所特有的组成。因此对于一个习惯于使用关系型数据库开发的人而言,如何正确地理解关系则是正确使用图形数据库的关键。

从上图中可以看到,在需要表示多对多关系时,我们常常需要创建一个关联表来记录不同实体的多对多关系,而且这些关联表常常不用来记录信息。如果两个实体之间拥有多种关系,那么我们就需要在它们之间创建多个关联表。而在一个图形数据库中,我们只需要标明两者之间存在着不同的关系,例如用DirectBy关系指向电影的导演,或用ActBy关系来指定参与电影拍摄的各个演员。同时在ActBy关系中,我们更可以通过关系中的属性来表示其是否是该电影的主演。而且从上面所展示的关系的名称上可以看出,关系是有向的。如果希望在两个结点集间建立双向关系,我们就需要为每个方向定义一个关系。

也就是说,相对于关系数据库中的各种关联表,图形数据库中的关系可以通过关系能够包含属性这一功能来提供更为丰富的关系展现方式。因此相较于关系型数据库,图形数据库的用户在对事物进行抽象时将拥有一个额外的武器,那就是丰富的关系。

因此在为图形数据库定义数据展现时,我们应该以一种更为自然的方式来对这些需要展现的事物进行抽象:首先为这些事物定义其所对应的结点集,并定义该结点集所具有的各个属性。接下来辨识出它们之间的关系并创建这些关系的相应抽象。

   因此一个图形数据库中所承载的数据最终将有类似于下图所示的结构:

在了解了图形数据库的基础知识之后,我们就要开始尝试使用图形数据库了。首先我们要搞清楚一个问题,那就是如何为我们的图形数据库定义一个设计良好的图?实际上这并不困难,您只需要了解图数据库设计时所使用的一系列要点即可。

首先就是,分清图中结点集,结点以及关系之间的相互联系。在以往的基于关系型数据库的设计中,我们常常会使用一个表来抽象一类事物。如对于人这个概念,我们常常会抽象出一个表,并在表中添加表示两个人的记录,Alice和Bob:

而在图数据库中,这里对应着两个概念:结点集和结点。在通常情况下,图形数据库中的数据展示并不使用结点集,而是独立的结点:

而如果需要在图中添加对书籍的支持,那么这些书籍将仍然被表示为一个结点:

也就是说,虽然在一个图数据库中常常拥有结点集的概念,但是它已经不再作为图数据库的最重要抽象方式了。甚至从某些图形数据库已经允许软件开发人员使用Schemaless结点这一点上来看,它们已经将结点集的概念弱化了。反过来,我们思考的角度就应该是结点个体,以及这些个体之间所存在的一系列关系。

那么我们是不是可以随便定义各个结点所具有的数据呢?不是的。这里最为常用的一个准则就是:Schemaless这种灵活度能为你带来好处。例如相较于强类型语言,弱类型语言可以为软件开发人员带来更大的开发灵活度,但是其维护性和严谨性常常不如强类型语言。同样地,在使用Schemaless结点时也要兼顾灵活性和维护性。

这样我们就可以在结点中添加多种多样的关系,而不用像在关系型数据库中那样需要担心是否需要通过更改数据库的Schema来记录一些外键。这进而允许软件开发人员在各结点间添加多种多样的关系:

因此在一个图形数据库中,结点集这个概念已经不是最重要的那一类概念了。例如在某些图形数据库中,各个结点的ID并不是按照结点集来组织的,而是根据结点的创建顺序来赋予的。在调试时您可能会发现,某个结点集内的第一个结点的ID是1,第二个结点的ID就是3了。而具有2这个ID的结点则处于另一个结点集中。

针对上述所描述的内容,在图数据库中存储的内容实际上就是一个源或者是一个类,它们的链接的内容,对应的出度和入度,从而表明上述的图中所指向的方向,它们的优先级这些内容,将这一个个点和一个个边进行连接起来从而构成模式图。因此实际上这个图是设想的图,是假定设定出来的图,实际上仍旧是一条条的数据,但是因为关系型数据库没法存储这样的数据,因此这样的数据用图数据库来存储。并不能够看到这样的图数据库。目前这九个数据集已经上传到服务器中,只要在运行程序的时候,建立的SPQRAL拆线呢和这些数据集进行对接,就可以使用了。

部分的图数据库的内容的显示:

University class <http://dbpedia.org/ontology/University> dbpedia 10748

PrimeMinister class <http://dbpedia.org/ontology/PrimeMinister> dbpedia 1581

IceHockeyLeague class <http://dbpedia.org/ontology/IceHockeyLeague> dbpedia 127

Olympics class <http://dbpedia.org/ontology/Olympics> dbpedia 52

MusicFestival class <http://dbpedia.org/ontology/MusicFestival> dbpedia 604

ShoppingMall class <http://dbpedia.org/ontology/ShoppingMall> dbpedia 1730

GrandPrix class <http://dbpedia.org/ontology/GrandPrix> dbpedia 721

Game class <http://dbpedia.org/ontology/Game> dbpedia 1136

Senator class <http://dbpedia.org/ontology/Senator> dbpedia 901

Muscle class <http://dbpedia.org/ontology/Muscle> dbpedia 276

Gnetophytes class <http://dbpedia.org/ontology/Gnetophytes> dbpedia 27

SpeedwayLeague class <http://dbpedia.org/ontology/SpeedwayLeague> dbpedia 7

Monarch class <http://dbpedia.org/ontology/Monarch> dbpedia 1517

Saint class <http://dbpedia.org/ontology/Saint> dbpedia 2344

AmericanFootballTeam class <http://dbpedia.org/ontology/AmericanFootballTeam> dbpedia 32

Bird class <http://dbpedia.org/ontology/Bird> dbpedia 12334

Reptile class <http://dbpedia.org/ontology/Reptile> dbpedia 5737

Airline class <http://dbpedia.org/ontology/Airline> dbpedia 2457

Album class <http://dbpedia.org/ontology/Album> dbpedia 94033

Protein class <http://dbpedia.org/ontology/Protein> dbpedia 1689

Activity class <http://dbpedia.org/ontology/Activity> dbpedia 1234

FilmFestival class <http://dbpedia.org/ontology/FilmFestival> dbpedia 165

Currency class <http://dbpedia.org/ontology/Currency> dbpedia 313

Lake class <http://dbpedia.org/ontology/Lake> dbpedia 8174

Park class <http://dbpedia.org/ontology/Park> dbpedia 847

GridironFootballPlayer class <http://dbpedia.org/ontology/GridironFootballPlayer> dbpedia 15284

CollegeCoach class <http://dbpedia.org/ontology/CollegeCoach> dbpedia 3520

Website class <http://dbpedia.org/ontology/Website> dbpedia 1852

Lymph class <http://dbpedia.org/ontology/Lymph> dbpedia 81

Settlement class <http://dbpedia.org/ontology/Settlement> dbpedia 239630

Ontology class <http://www.w3.org/2002/07/owl#Ontology> dbpedia 1

President class <http://dbpedia.org/ontology/President> dbpedia 2105

Enzyme class <http://bio2rdf.org/ns/kegg#Enzyme> kegg 4245

Property class <http://www.w3.org/1999/02/22-rdf-syntax-ns#Property> drugbank 117

targets class <http://www4.wiwiss.fu-berlin.de/drugbank/resource/drugbank/targets> drugbank 4553

SoccerLeague class <http://dbpedia.org/ontology/SoccerLeague> dbpedia 168

Species class <http://dbpedia.org/ontology/Species> dbpedia 146082

Judge class <http://dbpedia.org/ontology/Judge> dbpedia 911

Moss class <http://dbpedia.org/ontology/Moss> dbpedia 331

EducationalInstitution class <http://dbpedia.org/ontology/EducationalInstitution> dbpedia 31297

AnatomicalStructure class <http://dbpedia.org/ontology/AnatomicalStructure> dbpedia 3851

Comedian class <http://dbpedia.org/ontology/Comedian> dbpedia 622

Congressman class <http://dbpedia.org/ontology/Congressman> dbpedia 1922

Device class <http://dbpedia.org/ontology/Device> dbpedia 19626

Thing class <http://www.w3.org/2002/07/owl#Thing> dbpedia 1477796

Musical class <http://dbpedia.org/ontology/Musical> dbpedia 1010

Bacteria class <http://dbpedia.org/ontology/Bacteria> dbpedia 163

SoftballLeague class <http://dbpedia.org/ontology/SoftballLeague> dbpedia 1

AdministrativeRegion class <http://dbpedia.org/ontology/AdministrativeRegion> dbpedia 67005

PlayboyPlaymate class <http://dbpedia.org/ontology/PlayboyPlaymate> dbpedia 652

Model class <http://dbpedia.org/ontology/Model> dbpedia 836

AmericanFootballLeague class <http://dbpedia.org/ontology/AmericanFootballLeague> dbpedia 69

SkiArea class <http://dbpedia.org/ontology/SkiArea> dbpedia 432

Place class <http://dbpedia.org/ontology/Place> dbpedia 413404

Single class <http://dbpedia.org/ontology/Single> dbpedia 32937

VolleyballLeague class <http://dbpedia.org/ontology/VolleyballLeague> dbpedia 27

River class <http://dbpedia.org/ontology/River> dbpedia 18412

Book class <http://dbpedia.org/ontology/Book> dbpedia 20490

EthnicGroup class <http://dbpedia.org/ontology/EthnicGroup> dbpedia 2534

Beverage class <http://dbpedia.org/ontology/Beverage> dbpedia 488

SportsEvent class <http://dbpedia.org/ontology/SportsEvent> dbpedia 2656

FictionalCharacter class <http://dbpedia.org/ontology/FictionalCharacter> dbpedia 8635

Planet class <http://dbpedia.org/ontology/Planet> dbpedia 12348

Chancellor class <http://dbpedia.org/ontology/Chancellor> dbpedia 85

Language class <http://dbpedia.org/ontology/Language> dbpedia 3059

Fungus class <http://dbpedia.org/ontology/Fungus> dbpedia 6960

Mountain class <http://dbpedia.org/ontology/Mountain> dbpedia 8479

Airport class <http://dbpedia.org/ontology/Airport> dbpedia 9520

LacrosseLeague class <http://dbpedia.org/ontology/LacrosseLeague> dbpedia 13

Magazine class <http://dbpedia.org/ontology/Magazine> dbpedia 2182

Monument class <http://dbpedia.org/ontology/Monument> dbpedia 3

PopulatedPlace class <http://dbpedia.org/ontology/PopulatedPlace> dbpedia 310970

............................................................................................................................................

.............................................................................................................................................

三、 总结部分:

数据库的设计是和需求紧密联系在一起的,在数据库设计之前,需求文档不一定要求完成,到那时一定要明确自己的需求,只有将需求明确了才能够将数据库设计好。在使用powerdesigner的时候应该要注意cdm中实体之间的关系问题,注意是一对多还是多对一或者是多对多。在设计表的时候可以使用外键关系,如果是多对多的关系要建立Asscocaition来进行设计。数据库的设计还须要参考用例图和原型的设计,根据这些进行数据库的设计会让开发人员在进行开发的时候更加的方便。数据库的设计并不是一个简单的事情,要做好非常充分的准备,特别是在建立表的时候,一定要详细的考虑这些表中的主键、属性、域约束等问题,还须要注意表和表之间的关系问题。

虽然学习了数据库的相关知识,但是在正真在做的时候会出现不少的问题,因此所有的知识只用通过去运用才是更能够更加好的掌握。这也是体会到做中学的第一步吧。整个的设计过程,小组开了不少次会,进行了深入的学习交流讨论,还和老师进行了讨论咨询。觉得好的一个好的设计绝不是由一个人能够轻松的完成的,重要的是大家一起努力,它必定是大家一起合作努力的智慧结晶。

原文地址:https://www.cnblogs.com/990203ok/p/11823988.html

时间: 2024-10-11 02:51:18

联邦式知识图谱上的自然语言检索引擎数据库设计心得-T5队的相关文章

一文详解达观数据知识图谱技术与应用——技术直播回顾

讲师 | 桂洪冠来源 | AI科技大本营在线公开课 本文根据达观数据桂洪冠在"达观杯"文本智能处理挑战赛期间的技术直播分享整理而成,内容略有删减. ▌一.知识图谱的概述 我们先直观的来看一下什么是知识图谱,下面有一张图,从这张图里可以看到,这个图里圆圈是节点,节点之间有一些带箭头的边来连成,这个节点实际上相当于知识图谱里的实体或者概念,边连线表示实体之间的关系. 知识图谱本质上是一种大型的语义网络,它旨在描述客观世界的概念实体事件以及及其之间的关系.以实体概念为节点,以关系为边,提供一

知识图谱研究进展

在原文<知识图谱研究进展>基础上上做了相应的调整和补充 本文首先简要回顾知识图谱的历史,探讨知识图谱研究的意义.其次,介绍知识图谱构建的关键技术,包括实体关系识别技术.知识融合技术.实体链接技术和知识推理技术等.然后,给出现有开放的知识图谱数据集的介绍.最后,给出知识图谱在情报分析中的应用案例. - 漆桂林.高桓.吴天星 东南大学计算机科学与工程学院 本文节选自<情报工程>2017 年第 1 期,知识图谱专题稿件. 1 知识图谱构建技术 ??本节首先给出知识图谱的技术地图,然后介绍

(转)知识图谱研究综述: 表示学习、知识获取与应用

摘要 人类知识提供了对世界的认知理解.表征实体间结构关系的知识图谱已经成为认知和人类智能研究的一个日益流行的方向.在本次综述论文中,我们对知识图谱进行了全面的综述,涵盖了知识图谱表示学习.知识获取与补全.时序知识图谱.知识感知应用等方面的研究课题,并总结了最近的突破和未来的研究方向.我们提出对这些主题进行全视角分类和新的分类法.知识图谱嵌入从表示空间.得分函数.编码模型和辅助信息四个方面进行组织.对知识获取,特别是知识图谱的补全.嵌入方法.路径推理和逻辑规则推理进行了综述.我们进一步探讨了几个新

这是一份通俗易懂的知识图谱技术与应用指南

从一开始的Google搜索,到现在的聊天机器人.大数据风控.证券投资.智能医疗.自适应教育.推荐系统,无一不跟知识图谱相关.它在技术领域的热度也在逐年上升. 本文以通俗易懂的方式来讲解知识图谱相关的知识.尤其对从零开始搭建知识图谱过程当中需要经历的步骤以及每个阶段需要考虑的问题都给予了比较详细的解释. 对于读者,我们不要求有任何AI相关的背景知识. 目录: 概论 什么是知识图谱 知识图谱的表示 知识抽取 知识图谱的存储 金融知识图谱的搭建 定义具体的业务问题 数据收集 & 预处理 知识图谱的设计

ERNIE:知识图谱结合BERT才是「有文化」的语言模型

自然语言表征模型最近受到非常多的关注,很多研究者将其视为 NLP 最重要的研究方向之一.例如在大规模语料库上预训练的 BERT,它可以从纯文本中很好地捕捉丰富的语义模式,经过微调后可以持续改善不同 NLP 任务的性能.因此,我们获取 BERT 隐藏层表征后,可用于提升自己任务的性能. 但是,已有的预训练语言模型很少考虑知识信息,具体而言即知识图谱(knowledge graphs,KG),知识图谱能够提供丰富的结构化知识事实,以便进行更好的知识理解.简而言之,预训练语言模型只知道语言相关的「合理

知识图谱构建浅析

知识图谱应用如图所示,目前各大互联网公司已落地多个知识图谱产品,或者正在积极构建知识图谱,图谱技术成为"兵家必争"之地. 1. 什么是知识图谱? 知识图谱(Knowledge Graph)的概念由谷 歌 2012 年正式提出,旨在实现更智能的搜索引擎,并且于 2013 年以后开始在学术界和业界普及,并在智能问答.情报分析.反欺诈等应用 中发挥重要作用. 知识图谱以语义网( Semantic Web) 和领域本体( Ontology) 为其关键技术的大规模语义网络知识库. Knowled

搜索引擎和知识图谱那些事 (上).基础篇

这是一篇基础性文章,主要介绍搜索引擎和知识图谱的一些原理.发展经历和应用等知识.希望文章对你有所帮助~如果有错误或不足之处,还请海涵.(参考资料见后) 一. 搜索引擎 (一).搜索引擎的四个时代 根据张俊林大神的<这就是搜索引擎>这本书中描述(推荐大家阅读),搜索引擎从采取的技术划分为4个时代: 1.史前时代:分类目录的一代 这个时代成为"导航时代",Yahoo和国内hao123是这个时代的代表.通过人工搜集整理,把属于各个类别的高质量网站或网页分类,用户通过分级目录来查找

程序员进阶路上不能错过的史上最全技术知识图谱秘籍

今天在技术大海中游啊游游啊游,哇啊哈哈 ^_^发现了一份非常有用的超级技术图谱诶! 强烈推荐啊!!本文原作者是易宝支付技术经理/架构师李艳鹏,这是鹏哥多年来积累和收集的技术知识技能图谱,有的是鹏哥原创总结的最佳实践,有的是小伙伴们的分享. 其实,每个秘籍图谱里面的内容都是互联网高并发架构师应该了解和掌握的知识.鹏哥索性就把这些图谱都收集在一起,并且进行了归类,便于大家查找和学习.图谱也暗含着他的一个小目标:想把更多的技术图谱和思维导图汇集在一起,成为互联网上“最全的技术图谱”. 这份技术知识图谱

通用知识图谱VS行业知识图谱

??众所周知,知识图谱是Google于2012年提出,用来优化搜索结果.经过多年的发展,知识图谱在人工智能的许多行业都拥有了成熟落地的应用.按照知识图谱的覆盖面来看,主要分为通用知识图谱与行业知识图谱. This is why a "web" of notes with links between them is far more useful than a fixed hierarchical system-Cicles and arrows leaves one free to d