首页> 中国专利> 一种基于逻辑程序的关系型数据库搜索方法

一种基于逻辑程序的关系型数据库搜索方法

摘要

本发明的一种基于逻辑程序的关系型数据库搜索方法属于人工智能和计算机技术领域,包含两个步骤:第一步,首先基于分层搜索方法对搜索请求和关系型数据库进行匹配筛选处理,得到目标数据;第二步,然后将筛选后的目标数据自主映射成逻辑程序可识别的形式,即事实表,再结合所要搜索的请求和目标,生成相应的逻辑规则,并组合事实和规则进行求解。本发明提供一种动态的搜索模式,能够自主完成对数据库数据的映射及搜索,实现更人性化的查询,更好满足用户搜索需求。该方法还解决了因数据、条件、规则变更、系统维护以及数据知识推理需求的出现,普通查询无法解决的这种动态变化问题。

著录项

  • 公开/公告号CN112948374B

    专利类型发明专利

  • 公开/公告日2022-07-08

    原文格式PDF

  • 申请/专利权人 吉林大学;

    申请/专利号CN202110134783.2

  • 申请日2021-01-29

  • 分类号G06F16/22(2019.01);G06F16/2455(2019.01);G06F16/28(2019.01);

  • 代理机构长春吉大专利代理有限责任公司 22201;

  • 代理人王恩远

  • 地址 130012 吉林省长春市长春高新技术产业开发区前进大街2699号

  • 入库时间 2022-08-23 13:59:52

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2022-07-08

    授权

    发明专利权授予

说明书

技术领域

本发明属于人工智能和计算机技术领域,尤其涉及一种基于逻辑程序的关系型数据库搜索方法。

背景技术

近年来随着信息技术的快速发展,数据库技术应用越来越广泛,已成为信息化建设的核心。当前广泛使用的数据库分为两大类:[1]关系数据库,主要代表有SQL Server,Oracle,MySQL(开源),PostgreSQL(开源);[2]非关系数据库(NoSQL),主要代表有MongoDB,Redis,CouchDB。SQL数据存在特定结构的表中;而NoSQL则更加灵活和可扩展,存储方式可以是JSON文档、哈希表或者其他方式。在需要进行大量数据储存和查询的今天,人们对数据库的查询以及搜索的效率要求更高,查询是数据库操作最普通最常用的操作之一。当前关系型数据库主要实现结构化查询语言的接口来对存储的数据进行查询,而SQL的统一性和易用性也使它在数据库操作中有着不可替代的地位,但是在系统维护和条件、规则变更时,SQL查询无法适应这种动态变化,也随着一些数据的知识表征和推理功能需求的出现,SQL查询则满足不了需求。为了扩展数据查询时的推理特性和应对这种变化,本文使用逻辑程序对关系型数据库中存储的数据进行查询,提出了关系型数据库数据到逻辑程序的映射方法,给出了逻辑程序查询数据的一般框架和规范。

发明内容

本发明的目的是,克服背景技术存在的不足,提供一种基于逻辑程序的关系型数据库搜索方法,扩展了数据查询时的推理特性以及解决了应对条件、规则变化时,SQL适应不了这种动态变化的问题。

本发明的技术问题通过以下技术方案解决:

一种基于逻辑程序的关系型数据库搜索方法,包含两个步骤:第一步,首先基于分层搜索方法对搜索请求和关系型数据库进行匹配筛选处理,得到目标数据;第二步,然后将筛选后的目标数据自主映射成逻辑程序可识别的形式,即事实表,再结合所要搜索的请求和目标,生成相应的逻辑规则,并组合事实和规则进行求解。

基于分层搜索方法对搜索请求和关系型数据库进行匹配筛选处理,得到目标数据,具体过程如下:

首先建立两种特定的规则范式:

(1)将用户的搜索请求定义成subject(attribute 1,..attribute n)这种特定的范式,例如想要搜索一个身高一米七,年龄23岁,体重60kg的学生,按照上述规范表示搜索请求为student(1.7,23,60);

(2)将关系型数据库可以抽象表示为R(D1,...Dn)这种范式;例如关系型数据库表格数据含有一个学生的身高、体重、年龄、性别、成绩等等,将其抽象成R(height,weight,age,grade...),各个字段名下存储了一列数据;

通过上述两种范式的内联关系,先进行搜索主题subject与抽象后的数据表表头R的遍历式比对找出相应的数据表,在比对过程中,若找不到其比对的数据表表头R,系统将反馈未查找到,提示请重新增加知识或重新搜索,若比对上,再将搜索主题subject的属性attribute与表单字段名D再进行遍历式对比,从中找出需要的具体字段名Di,删除不需要的字段名,将需要的字段名重新组合成所需要的目标数据并表示为R(D1,..Di..Dx)的范式储存在自主定义的文件数据库里进行下一步的数据转换操作。

所述的将筛选后的目标数据自主映射成逻辑程序可识别的形式,即事实表,再结合所要搜索的请求和目标,生成相应的逻辑规则,并组合事实和规则进行求解,具体如下:

(1)搜索请求处理模块对自然语言形式的搜索请求进行初步处理,生成对应特定的范式subject(attribute 1,..attribute n)给到格式转换器;

(2)格式转换器首先将筛选后存放在文件数据库里的目标数据自主映射成逻辑程序可识别的形式,这里称为事实表,并将其再次存放文件数据库中,再接收来自搜索处理模块处理的特定形式化范式subject(attribute 1,..attribute n),结合所要搜索的请求和目标,并将其生成相应的逻辑规则,最后在格式转换器中组合事实表和规则后生成可以求解的逻辑程序并交给求解器;所述的文件数据库是自主定义的数据库,用来储存关系型数据库抽象化的结构形式R(D1,...Dn)和储存经过筛选后的目标数据R(D1,...Dx)以及经过格式转换器映射过来的逻辑程序可识别的形式,即事实表;

(3)求解器用来接收格式转换器组合过来的逻辑程序,根据两者进行推理计算进行求解,最终将结果输出给应用系统。

其中,所述的搜索请求处理模块是对搜索语句进行初步处理,将自然语言形式的搜索请求生成对应形式化范式给到格式转换器,例如想要搜索一个身高一米七,年龄23岁,体重60kg的学生,搜索请求处理模块将其处理成student(1.7,23,60)这种范式。搜索请求的处理其实相当开放,但是根据应用场景和应用需求的不同却决定了处理的难易程度,这里可能会涉及一些自然语言处理的内容,对自然语言的处理过程此处不作具体描述跳过处理过程,直接将搜索语句处理后得到的形式化范式输入到格式转换器中。

所述的格式转换器有两个工作:一是接收前面的搜索处理模块处理的形式化范式subject(attribute 1,..attribute n)来组成一系列规则和把储存在文件数据库中经过筛选过后目标数据自主映射成逻辑程序可识别的形式,这里称之为事实,另一个是组合事实和规则生成求解器可以求解的逻辑程序;同时在大数据的情况下,为减少实时映射带来的时间消耗,本发明提出了分区映射的方法,此方法保证了数据修改不用映射全部的数据而只映射一部分;

所述的求解器,用来接收格式转换器组合过来的逻辑程序,并对其进行求解,类似于对逻辑程序进行求解的clingo求解器,这里首先将把原始回答集程序中的变量全部替换成事实中出现的常量,最后来真正进行非单调推理;

所述的关系型数据库、文件数据库用来储存对应的数据。搜索请求经过搜索请求处理模块和格式转换器后变成逻辑程序的若干规则后,最终以表的形式存储在文件数据库中,称之为规则表,同时,经过筛选后的目标数据通过格式转换器后映射成逻辑程序可识别的形式即事实表也储存在文件数据库中,最终将其事实表和规则表交给格式转换器处理。

有益效果:

用户的搜索请求首先经过搜索语句的处理生成框架可识别的形式化范式,格式转换器通过将其与数据库中数据表的关系形式表示进行比对找出具体的搜索字段名,删除冗余部分后将其映射成逻辑程序数据的形式,这里称之为事实表。同时根据具体的搜索要求和目标,格式转换器找到相应规则进行参数替换从而变成逻辑程序的若干规则存储在文件数据库中,这里且把规则存储的表称为规则表,事实表和规则表结合输入求解器中,求解器根据两者进行推理计算,最终将结果输出给应用系统。本发明实施的技术方案,不同于以往对数据库查询的方法,本发明利用分层搜索方法,根据实际搜索请求、目标,建立一种特定的形式规范,再与抽象后的关系型数据库数据进行遍历匹配,把需要的目标数据储存在文件数据库中,将文件数据库中的数据转换为逻辑程序可识别的形式,并结合所要搜索的请求和目标,以及背景知识建立的规则,这样可以把数据当做程序的一部分输入求解器中进行搜索推理得到稳定模型;另外这里使用传统的数据库存储数据,利用了数据库可以对知识库进行修改和增删,直观的说,使用逻辑程序修改数据显然是不合适的,此外在应用方面,这样可以使回答集搜索很好的嵌入到现有的应用系统中,具有很好的灵活性。该方案解决了SQL查询无法适应条件、规则改变时,动态修改查询语句问题;同时解决了一些数据的知识表征和推理功能需求的出现,扩展数据查询时的推理特性问题。此外,本方案还提出分区映射的方法,保证了数据修改不用映射全部的数据而只映射一部分,减少了时间消耗。

附图说明:

图1为本发明数据搜索系统方法的整体结构框架图。

图2为本发明数据搜索方法中分层搜索方法实施过程图。

图3为本发明数据搜索方法中格式转换器的工作具体过程图。

图4为本发明数据搜索方法和普通查询方法比较图。

图5为本发明数据搜索方法的工作流程图。

具体实施方式

以下将结合实施例和附图对本发明的构思、具体结构及产生的技术效果进行清楚、完整的描述,以充分地理解本发明的目的、方案和效果。应当理解,此处所描述的具体实施例仅仅用以解释本发明专利,并不用于限定本发明专利。

实施例1本发明的数据搜索系统整体结构

本发明的数据搜索系统整体结构如图1所示。整个系统包括五个部分:搜索语句处理模块、格式转换器、求解器、关系型数据库、文件数据库。搜索请求处理模块是面向搜索请求,对搜索请求的初步处理,生成相应的形式化范式到格式转换器格式,格式转换器转化和映射成规则表和事实表,并将其组合给到求解器求解,是最重要的一步。求解器是面向逻辑程序的,求解来自格式转化器的逻辑程序。关系型数据库、文件数据库分别用来储存数据和逻辑程序。

实施例2分层搜索的具体实施方法

关系型数据库是采用关系模型来组织数据的数据库,它以数据表的形式进行储存,可以抽象表示为R(D1,...Dn)这种形式,R表示数据表的表头,D表示此数据表的字段名,也称作是表头的属性或者关系,n是属性或关系的目或度。

用户的搜索请求往往包含两个关键部分,一个是想要搜索的主题subject,比如学生,另一个是主题所拥有的属性或者关系,用attribute表示,比如年龄和身高等等。此搜索请求的形式化范式来表示用户的搜索请求。定义规则如下:

将搜索主题作为谓词

想要搜索主题的属性有attribute 1,..attribute n

则定义如下格式:subject(attribute 1,..attribute n),来表示用户的搜索请求。

示例:假如想要搜索一个身高一米七,年龄23岁,体重60kg的学生,按照上述规范表示搜索请求为student(1.7,23,60)。

结合上面表述,进行搜索请求的形式化范式和关系型数据库数据抽象表示形式相对应,再通过比对找出相应的知识进行到逻辑程序的数据的映射,如图2所示,具体的实现过程如下:

先进行搜索主题subject与抽象后的数据表表头R的遍历式比对找出相应的数据表,在比对过程中,若找不到其比对的数据表表头R,系统将反馈未查找到,提示请重新增加知识或重新搜索(过程由python程序来实现),若比对上,再将搜索主题subject的属性attribute与表单字段名D再进行遍历式对比,从中找出需要的具体字段名Di,删除不需要的字段名,将需要的字段名重新组合成所需要的目标数据并表示为R(D1,..Di..Dx)的范式储存在自主定义的文件数据库里进行下一步的数据转换操作。

实施例3搜素请求处理模块的具体过程

搜素请求处理模块是对搜索请求的初步处理,生成相应的形式化范式到格式转换器。搜素请求处理模块是分层搜索方法重要的一步,整合实际搜索请求、目标,建立一种特定的形式规范,为后续比对和生成规则做了初步处理。搜索请求的处理其实相当开放,但是根据应用场景和应用需求的不同却决定了处理的难易程度,这里可能会涉及一些自然语言处理的内容,本申请对自然语言的处理过程不作具体描述跳过处理过程,直接将查询语句处理后得到的形式化范式输入到格式转换器中。

实施例4数据格式转换器的具体过程

所述的格式转换器有两个工作,一个是接收前面的搜索请求处理模块生成相应的形式化范式来组成一些规则,将其规则以表的形式储存在文件数据库里,此表称之为规则表,是可以进行更改和变化的,然后把关系型数据库中与请求属性相关的数据映射成逻辑程序可识别的形式,此形式称之为事实表,另一个是组合事实和规则生成求解器可以求解的程序,过程如图3所示。如何组合指的一个查询语句生成的规则如何找到指定的事实表中的文件组合成回答集程序,这个问题最分两种情况,第一种查询语句已经根据一定的规范生成,规范可以是强制的也可以是一种约定,那么就可以直接分析规则中的谓词、变量、常量等来寻找对应的事实表,比如一般说来,需要的数据库表名会出现在规则的头部,那么可以分析搜索规则的体部,收集体部中出现的的谓词(对应数据库表明),与现有的数据库表匹配,加载相应的映射好的事实表;第二种情况则相对复杂,查询语句没有受到一些规范的约束,简单直觉的想法是分析查询语句中的关键词,然后进行词法分析选择对应的事实表。在其映射过程中,本发明采取分区映射的方法。

实施例5求解器的构成

本文所述的求解器用来接收格式转换器组合过来的逻辑程序,并对其进行求解,回答集求解器有clingo,DLV等,本文所用的求解器类似postdam大学开发clingo求解器,都是先把原始回答集程序中的变量全部替换成事实中出现的常量,最后输出来真正进行非单调推理。

实施例6文件数据库和关系型数据库储存

关系型数据库存储了需要用回答集搜索的数据,而文件数据库用来储存关系型数据库抽象化的结构形式R(D1,...Dn)和储存经过筛选后的目标数据R(D1,...Dx)以及经过格式转换器映射过来的逻辑程序可识别的形式,即事实等。这里需要指出的是文件数据库的建立方式取决于应用的大小,如果应用小到不足以用到数据,把程序文件放在目录下即可,但是如果文件多而复杂,那么可以使用例如mongodb这样的专业的数据库。

上面的框架只是给出了一般的基于逻辑程序的关系型数据库的搜索系统的模块构成,具体架构和实现细节实际上相当灵活。例如不同的应用搜索语句的要求会有不同、数据转换的格式会有增加一些元组元素来为数据提供额外的信息等。因此具体的系统实现相当开放。

实施例7关系型数据库数据到逻辑程序格式数据的转换

关系数据库理论是构建在关系模型理论上的,关系表示为R(D1,..Dn),R表示关系的名字,n是关系的目或度。ASP的一阶谓词表达为P(x1,..xn),P是谓词符号,刻画主题性质或个体之间关系的词,x1..xn表示个体的词。所以建立关系数据库(mysql)中数据到逻辑程序格式数据的映射。使用一阶谓词逻辑形式表达数据库表中的数据,定义规则如下:

(1)将关系型数据库中存储的数据表的表名作为谓词;

(2)对于一张与搜索请求比对过后的表有相应的列名D1..Dx,则定义如下逻辑程序格式:tablename(D1,..,Dx)

示例:数据库中一个名为student的表,student表有若干字段:id,name,age,height,weight,该表中有两行记录(1,jerry,14,1.7,60),(2,tom,15,1.8,80),经过与搜索请求的比对,假设要查询表中的前三项信息,按照上述规则进行数据映射,使用映射结果student(1,jerry,14).student(2,tom,15).来表示数据。

实施例8回答集编程

ASP是一种声明性的编程方式,它是研究非单调推理的产物,使用逻辑编程中稳定模型的语义,其基本形式如下:

Fact:A0.

Rule:A0:-L1,:::,Ln.

Integrity Constraint::-L1,:::,Ln.

A0表示规则的头部原子集合或者单独的原子集合,而规则的体部是由所谓的文字Lj(1<=j<=n)组成,而文字L是由原子A和缺省否定的原子(not A)组成,没有头部的规则叫做完整性约束,用来去除生成的稳定模型中的一些不想要的结果,稳定模型是是由逻辑程序生成的满足程序中所有规则、事实和完整性约束的一组原子集合。回答集编程的标识符是建立在一阶谓词逻辑的基础上的。原子基本形式为P(X1,X2,..,Xn),P叫做谓词,X可以是变量或常量,常量一般叫术语。

实施例9分区映射方法

比如关系型数据库中某一条记录被修改,而这时ASP搜索功能被调用需要映射这张表,这时搜索功能调用的时间就变成了映射时间加上搜索求解时间。但是可以通过分区映射来解决,将数据库中的不同范围内的数据映射到多个逻辑程序文件上,当数据修改是不用映射全部的数据而只映射一部分。

例如一个user表有100万条记录,原来只映射到一个文件中user.lp中,分区映射的策略是每10万条记录映射到一个文件中,分别为user-1.lp、user-2.lp、…user-10.lp,当第10万1200条记录删除或者修改时,只需要重新加载user-2.lp文件,而不要加载全部100万条记录。

实施例10关系型数据库中的数据变化时对应的事实表的变化应对策略

假设有如下的一个场景,在一个小型的信息系统中,存储了一些人员的信息,通常查询时会首先会写API接口,这样对应用的扩展和部署带来压力,如果使用SQL语句直接在数据库中搜索,一方面SQL语句需要学习成本,另一方面对新手用户不是那么友好。而ASP逻辑程序语言标准则更接近于人的自然语言,这就在一些场景和应用上存在优势。

示例有一个用户表user,有字段pid,username,age,gender,married,property,如果要查询在25到35随之间,性别男,未婚,财产大于20万的用户,那么使用逻辑程序则很容易表达搜索过程:

user_meet_conditions(P,U,A,G,M,PRO):-user(P,U,A,G,M,PRO),

2520

同时在增加或减少条件的时候,搜索语句也是容易修改的,可以把查询规则设置为一条条逻辑程序的规则库,当需要调用时,直接选择规则即可,这种方式简单方便。

那么调用的功能实际上选择对应的功能即可。事实上可以运用一种策略组合的方式来应对复杂的查询,多条规则的输入将会提高查询的效率,这也是ASP搜索的优势所在。

上述策略组合在应用中和传统应用的区别如图4所示,左边是ASP搜索应用的结构图,右边是普通查询系统的结构图。在右边的查询系统中,如果要实现查询功能通常要先写API函数的功能然后编译再增加到系统中,对于系统的维护会有一些麻烦,但是在左边查询时只需要更改一下规则库或者按照ASP的逻辑程序规范编写规则就可以直接使用,相当于SQL语句查询接口,而不需要实现API功能。但是相应的,规则库和应用层之间需要一个解释器来适应应用的需求,具体情况依据应用的复杂程度赫尔需求决定。

本发明的操作过程的流程图如图5所示。

以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号