联邦式知识图谱上的自然语言检索引擎数据库设计心得-T5队
联邦式知识图谱上的自然语言检索引擎数据库设计心得-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来进行设计。数据库的设计还须要参考用例图和原型的设计，根据这些进行数据库的设计会让开发人员在进行开发的时候更加的方便。数据库的设计并不是一个简单的事情，要做好非常充分的准备，特别是在建立表的时候，一定要详细的考虑这些表中的主键、属性、域约束等问题，还须要注意表和表之间的关系问题。
虽然学习了数据库的相关知识，但是在正真在做的时候会出现不少的问题，因此所有的知识只用通过去运用才是更能够更加好的掌握。这也是体会到做中学的第一步吧。整个的设计过程，小组开了不少次会，进行了深入的学习交流讨论，还和老师进行了讨论咨询。觉得好的一个好的设计绝不是由一个人能够轻松的完成的，重要的是大家一起努力，它必定是大家一起合作努力的智慧结晶。