CN101535990A - 高效的搜索结果更新机制 - Google Patents

高效的搜索结果更新机制 Download PDF

Info

Publication number
CN101535990A
CN101535990A CNA2007800383045A CN200780038304A CN101535990A CN 101535990 A CN101535990 A CN 101535990A CN A2007800383045 A CNA2007800383045 A CN A2007800383045A CN 200780038304 A CN200780038304 A CN 200780038304A CN 101535990 A CN101535990 A CN 101535990A
Authority
CN
China
Prior art keywords
condition
index
inquiry
value
row
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CNA2007800383045A
Other languages
English (en)
Other versions
CN101535990B (zh
Inventor
G·贾根内森
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
INNOVATIVE SOLUTION Inc
Original Assignee
INNOVATIVE SOLUTION Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by INNOVATIVE SOLUTION Inc filed Critical INNOVATIVE SOLUTION Inc
Publication of CN101535990A publication Critical patent/CN101535990A/zh
Application granted granted Critical
Publication of CN101535990B publication Critical patent/CN101535990B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种允许数据库查询被保存方法/算法，以及一种每当向所有保存的查询中添加记录或修改记录时匹配记录，并且一旦添加或修改了记录，就返回匹配给定记录的那些查询的列表的高效机制。如果在在线搜索门户示例中使用(例如，工作搜索站点)，本发明将允许搜索者提交并保存他的搜索准则一次，应用程序将返回在该时间点匹配搜索准则的列表，还将自动地匹配在查询被保存之后添加的任何新的列表，一旦添加了列表，如果存在匹配，就将把列表通知给用户。这种新的列表与保存的搜索的匹配将会持续地进行，直到删除该搜索。根据本发明的一个方面，通过对添加或修改到数据库中的记录与所有保存的查询进行匹配，它给用户带来了方便，它还降低了计算成本，以与针对相同情况的其他现有技术相比取得相同的结果。

Description

高效的搜索结果更新机制
对相关申请的交叉引用
[0001]本申请基于2006年8月23日提出的美国临时申请No.60/823,370，并要求该申请的优先权，该专利申请的全部内容以引用的方式并入本文中。
技术领域
[0002]本发明涉及计算机搜索系统，具体来说，涉及允许保存数据库查询的方法以及每当记录被添加或修改到所有保存的查询中时对记录进行匹配的高效的机制。
背景技术
[0003]在全世界的包括搜索引擎及其他搜索站点(例如，工作搜索、自动和国内销售站点、约会站点，等等)在内的计算机应用程序中，广泛地使用数据库和结构化查询语言(SQL)来管理大量的相关信息。数据库常常包含一个或更多个表，这些表包含存储数据的行(即，记录)。每一个表都由名称唯一地标识，每一行通常都由一个或多个标识符唯一地标识。表存储有关数据的类别的信息，例如，将存储人的姓名和地址的Person表。地址表中的行存储人的不同实例，如“President George W.Bush，1600 Pennsylvania Ave NW，Washington DC 20500”。表还被组织成若干个列，这些列唯一地描述了使用表来进行定义的数据类别的属性。Person表通常是使用“Name、Street Address、City、state和Zip”这些列来组织的。
 
Name Street Address City State Zip
George W Bush 1600 Pennsylvania Ave Washington DC 20500
John Doe 1 Main street New York NY 10001
Jane Doe 10 Maple Ave Hollywood CA 90210
[0004]使用SQL查询来有效地存储信息和从这些表中检索信息。在计算机应用程序中广泛地使用SQL Select语句从数据库表中检索数据。使用SQL Select语句来从表中选择数据。它返回结果集，该结果集又具有表的形式。select语句通常是下列形式。
Select Column name[，column name...]
From Table name
Where[Columnname operator Value[and/or Column nameoperator Value]]
[0005]在上文的语句中，括号对(＂[＂和＂]＂)之间的一切都是可选的。使用SQL Select语句中的Where子句来指定选择准则，该选择准则用于过滤从表中选择的数据。每一个列名称运算符值都是作为过滤结果集中的要返回的数据的过滤器(sieve)的准则条件。
[0006]例如，使用上面所示的示例Person表，下列SQL Select语句
Select Name
From Person
Where STATE＝′NY′or
      STATE＝′CA′
[0007]将从上面的表返回下列值：
 
Name
John Doe
Jane Doe
[0008]在此示例中，不返回第一条记录，因为该记录中的STATE的值不匹配任何一个条件，因此其未通过过滤。
[0009]下面是每个SQL标准允许的合法运算符。
 
运算符 描述
＝ 等于
<> 不等于
> 大于
< 小于
>＝ 大于等于
<＝ 小于等于
BETWEEN 在包含性范围之间
相似 搜索一种模式
[0010]在where子句中使用布尔运算符“AND”和“OR”，来连接简单条件，以形成复合条件。“AND”运算符返回匹配通过它连接的所有条件的行。“OR”运算符返回匹配通过它连接的任何一个条件的行。
[0011]这类SQL查询在全世界的计算机应用中非常普遍。最终用户输入被转换成SQL查询的一个共同领域是因特网上的分类搜索中。在线工作门户(求职者可以通过在搜索表单中输入搜索准则，搜索工作列表)中可以找到这种情况的示例。然后，站点返回匹配输入的准则的所有工作列表。在此情况下，用户在搜索表单中输入的准则被转换成SQL查询，并被执行。然后，格式化由查询返回的结果集，并显示给用户。
[0012]此方法存在固有的缺陷。搜索以及基础的SQL查询返回结果的时间点快照。同时，被搜索的数据被连续地更新。这会导致这样的情况：需要多次执行搜索功能，这是通过重新执行SQL查询来完成的。在“工作搜索”示例中，要么求职者必须间歇性地重新提交搜索，要么必须间歇性地重新执行SQL查询。第一选项给用户带来不便，两个选项就计算资源而言都是昂贵的。
[0013]执行搜索的用户期望保存搜索，并且期望每当有匹配该搜索的任何新的数据被添加到数据库中时，应用程序都通知用户。大多数当前应用程序都缺乏此功能，几乎没有支持此功能的应用程序使用间歇性地多次执行SQL查询的技术。尽管此昂贵的选项避免了用户间歇性地并频繁地重新提交搜索的必要性，但是在时间很重要的情况下，不是一添加了匹配记录就会通知用户。
发明内容
[0014]本发明提出了允许数据库查询被保存的方法/算法，并且提出一种如下的高效机制，即，每当向所有保存的查询中添加记录或修改记录时匹配记录，并且一旦添加或修改了记录，就返回匹配给定记录的那些查询的列表。如果在在线搜索门户示例中使用(例如，工作搜索站点)，本发明将允许搜索者提交并保存他的搜索准则一次，然后应用程序将返回在该时间点匹配该搜索准则的列表，还将自动地匹配在查询被保存之后添加的任何新的列表，如果存在匹配，一旦添加了列表，就将把列表通知给用户。这种对新列表与所保存的搜索的匹配将会持续地进行，直到删除该搜索。
[0015]根据本发明的一个方面，通过对添加或改变到数据库中的记录与所有保存的查询进行匹配，它给用户带来了方便，它还降低了计算成本，与针对相同情况的其他现有技术相比，可以取得相同的结果。
[0016]为促进这些及其他方面，根据本发明的方法包括接收用于标识多组数据之中的一组数据的查询，根据多个条件索引对查询进行分析，存储通过分析步骤更新的条件索引，并将该查询与所存储的条件索引关联，并将新的或改变后的数据组与所存储的条件索引进行比较，并且如果有匹配则标识关联的查询。
[0017]为进一步促进这些及其他方面，根据本发明的方法包括提供了一种查询工具以及可以通过在线门户进行访问的记录的数据库，通过在线门户从用户那里接收查询，使用查询工具对数据库进行搜索，并向用户返回搜索结果，对查询进行分析以提取其条件，并保存查询以及其关联的提取的条件，接收新的或变更的记录以存储在数据库中，将接收到的记录与提取的条件进行比较，以判断关联的查询的搜索结果是否被接收到的记录更改，以及，如果判断搜索结果已经被更改，则通知用户。
[0018]为进一步促进这些及其他方面，根据本发明的用于搜索表中的记录的设备包括：查询处理器，用于根据多个条件索引，分析接收到的查询，存储通过分析而更新的条件索引，并将查询与存储的条件索引关联；以及，查询匹配处理器，用于将新的或变更的记录与存储的条件索引进行比较，并且如果有匹配则标识关联的查询。
附图说明
[0019]在结合附图阅读了本发明的具体实施例的下列描述之后，本发明的这些及其他方面和特点，对于本领域普通技术人员来说，将变得显而易见，其中：
[0020]图1是显示了根据本发明的一般情况的示例算法的流程图。
[0021]图2A到2E说明了根据本发明的实施例的创建范围索引条件表的过程；
[0022]图3说明了根据本发明的实施例的创建较高阶范围索引表的过程；
[0023]图4A到4E说明了根据本发明的实施例的创建“相似”条件的节点和节点分支表的过程；
[0024]图5说明了根据本发明的实施例如何实现节点和节点分支表；
[0025]图6是说明了根据本发明的实施例的将输入字符串匹配到“相似”条件索引表的过程的流程图；以及
[0026]图7是说明本发明在搜索门户中的一个可能的实现方式的功能方框图。
具体实施方式
[0027]现在将参考附图，详细描述本发明，这些附图是作为本发明的说明性示例提供的，以便可使所属领域的技术人员来实施本发明。值得注意的是，下面的附图和示例不将本发明的范围限制于单个实施例，而是可以通过互换一些或所有描述的或说明的要素获得其他实施例。此外，本发明的某些要素还可以部分地或完全地使用已知的组件来实现，将只描述这样的已知组件的对于理解本发明所需的那些部分，将不对这样的已知组件的其他部分进行详细描述，以便不至于使本发明变得模糊。在本说明书中，显示了单个组件的实施例不应该被视为限制性的；相反，本发明可以涵盖包括多个相同组件的其他实施例，反之亦然，除非这里明确地声明。此外，申请人不希望说明书或权利要求中的任何术语归于不平常的或特殊含义，除非如此明确地阐述。此外，本发明包含这里通过图例引用的已知组件的现在和将来的已知的等效组件。
[0028]根据一个一般的方面，本发明包括以高效的方式将数据与保存的搜索或过滤规则匹配的算法。在下面的段落中，将结合作为数据库中的记录而存储的数据组的一个示例应用，描述本发明，搜索或过滤规则包括诸如SQL查询之类的查询。然而，本发明不仅限于此示例应用，而是包括任何形式的数据和用于分析该数据的规则，如数据流和带有关联的字段的数据组，以及带有这些字段的不同组合的条件的诸如布尔规则之类的规则。所属领域的技术人员将认识到在得到本公开内容的教导之后本发明的各种应用。
[0029]为了简化根据本发明的算法的一个示例的说明，使用带有其数据的下列求职者表1作为说明性示例。
表1
 
RowNumID-1 NameID-2 SkillsID-3 LocationID-4     EducationLevelID-5      CareerLevelID-6   WorkstatusID-7   Job TypeID-8    CompanyCategoriesID-9      
1 JohnDoe  Java，.netJ2EE       NY M XP FT C IT
2 JaneDoe .net，MCSE，MSACCESS NJ B XP FT E IT
3 JohnSmith CPA，IRS andState Audit MA M M FT E ACCT
4 JaneSmith CPN，FirstAid，Physicaltherapy    MA A XP FT E HC
5 JackSmith ORACLE，10G，Datawa rehouse CA B E FT E IT
6 JillSmith IP，Corporate，Legal Asst    DC B S PT I LG
7 JimSmith SalesManager，Marketingstrategist IL M EX FT E INS
8 JackieDoeSmith  Airbus，Boeing，Mechanic TX B XP FT E AIR
[0030]上面的示例表中的值遵循下面所描述的约定。对于Location，使用州的缩写代码。对于Education Level，使用下列缩写：M-硕士；B-学士；A-大专。对于Career Level，使用下列缩写：XP-有经验，非经理；M-经理；E-入门水平；S-学生；EX-高级管理人员。对于Work Status，使用下列缩写：FT-专职；PT-兼职。对于Job Type，使用下列缩写：C-合同；I-见习；E-雇员。对于Company Categories，使用下列缩写：IT-信息技术；ACCT-会计；HC-卫生保健；LG-法律；INS-保险；AIR-航空公司。
[0031]表中的每一行都对应于一个记录。例如，下列行对应于姓名为John Doe的求职者的完整的记录：
 
姓名 技能 位置 教育程度 职业程度     就业状况     工作类型     公司类别
John Doe Java，.netJ2EE       NY M XP FT C IT
[0032]在更详细地说明根据本发明的示例算法之前，概述一下简单查询如何与数据库表中的多个记录进行匹配是十分有用的。在此情况下，考虑下面的查询：
Select＊from Jobseekers where
CONTAINS(Skills，′.net′)and
Locationin(′NY′，′NJ′)and
(Job Type＝′E′or
Work Status＝′FT′)
[0033]通过执行此查询，将从表1返回下面的行(即，记录)：
 
行编号 姓名 技能 位置 教育程度 职业等级     就业状况 工作类型 公司类别
1 JohnDoe  Java，.netJ2EE       NY M XP FT C IT
2 JaneDoe  .net，MCSE，MSACCESS   NJ B XP FT E IT
[0034]表中的所有其他行都不匹配查询的“where”子句中的表达式。下面显示了对该查询的一种分解(breakup)：
Select＊from Jobseekers where
CONTAINS(Skills，′.net′)and -- 条件1
Location in(′NY′，′NJ′)and-- 条件2
(Job Type＝′E′or            -- 条件3
Work Status＝′FT′)；        -- 条件4
[0035]对于要选择的表中的任何行，条件1和2两者都必须为真，条件3和4中的任何一个必须是真。在此示例中，只有行编号1和2满足“where”子句中的表达式。
[0036]当搜索带有大量的记录的表时，搜索算法通常使用有关数据的索引。例如，上面的表，如果按关键字进行索引，将帮助快速地检索匹配条件1的所有记录。一旦标识了匹配条件1的所有行，则针对其他条件，对这些行进行评估。在处理结束时，将作为结果集，返回匹配该表达式的所有行(在此情况下是行1和2)。
[0037]类似地，根据某些一般方面，根据本发明的算法，通过利用基于给定条件在属性的特定值上构建的索引来削减查询的过程，将大量的查询匹配到单一记录。这些条件索引是如此构建的，以便当给定某个属性的不同的值时，它们会快速地返回所有匹配条件，以及相应地，这些匹配条件所依据的所有查询。
[0038]图1是显示了根据本发明的一般方面的一个示例算法的流程图。
[0039]如图1所示，算法中有两个主要的处理流程。“保存查询”处理流程(方框1.1到1.3)描述了当保存每一个查询时执行的所有步骤，“将记录与保存的查询匹配”处理流程(方框2.1到2.3)描述了当在应用中添加或更新任何记录时执行的步骤。
[0040]一般而言，在“保存查询”处理流程中，在在步骤1.1中接收到任何新查询或更改了任何查询之后，在步骤1.2中，分析该查询，创建所有所需的索引，并存储在快速检索数据存储库中(方框1.3)。在“将记录与保存的查询匹配”处理流程中，使用索引，匹配(在步骤2.1中接收到的)新的或变更的记录的任何查询都被标识，并在结果集中返回(步骤2.2和2.3)。
[0041]现在，将参考图1中的处理流程，提供根据本发明的某些实施例的算法的示例实现方式的细节。
[0042]步骤1.1涉及可以调用本发明的算法的任何触发步骤。根据应用，无论是从数据库内还是从外部数据库，将会把新的或变化的查询通知给处理。此事件会触发“保存查询”处理流程。在一个示例中，来自调用应用程序的接口将提供完整的查询表达式，并且本处理将随着适当的消息，返回成功或故障通知。
[0043]“保存查询”处理流程中的第一个步骤是分析查询步骤1.2。在一个示例实现方式中，在此步骤中，将SQL查询的where子句中的表达式分析为分开的各个条件。然后，使用经过分析的条件名称，以其布尔形式来表达where子句中的表达式。然后，将布尔表达式简化为其析取(disjunctive)范式(normal form)。最后，将表达式转换为代数析取范式，以有助于评估。
[0044]例如，考虑来自其where子句中的表达式的示例查询1：
CONTAINS(Skills，′.net′)and -- 条件-C1
Location in(′NY′，′NJ′)and-- 条件-C2
(Job Type＝′E′or            -- 条件-C3
Work Status＝′FT′)；       -- 条件-C4
[0045]如此，这些条件被标识为如下：
C1＝CONTAINS(Skills，′.net′)
C2＝{Location in(′NY′，′NJ′)}
C3＝{Job Type＝′E′}
C4＝{Work Status＝′FT′}
[0046]然后，表达式以其布尔形式被表达为：
Q1＝C1and C2 and(C3 or C4)。
[0047]将表达式的布尔形式简化为其析取范式的过程，涉及使表达式为乘积之和。例如，查询Q1的析取范式是：
Q1＝(C1 and C2 and C3)or(C1 and C2 and C4)。
[0048]在此形式中要注意的一件事是，当通过“OR”运算符分隔的表达式的任何子部分变为真时，该表达式变为真。将此转换为代数析取范式涉及将“OR”替换为+符号并且将“AND”替换为＊符号。这样，查询Q1的代数析取范式是：
Q1＝(C1＊C2＊C3)+(C1＊C2＊C4)。
[0049]此外，当把表达式简化为析取范式时，使用德摩根定律简化not条件。德摩根定律的一个规则(observation)是：
·NOT(C1 AND C2)＝(NOT(C1)OR NOT(C2))
·NOT(C1 OR C2)＝(NOT(C1)AND NOT(C2))
[0050]这允许表达式只具有与单个条件关联的NOT，而不具有连结的或析取的集合。
[0051]为优化性能，维护了将属性ID映射到条件类型的主表。这表示对于给定属性必须搜索的所有可能的条件类型。在本发明的一个示例中，它是作为“属性条件(Attribute Condition)XREF”表来实现的。它具有两个列：“属性ID”和“条件类型”。向对应于示例查询Q1的分析的此表中插入下面的行，假设它是添加到系统的第一条查询：
表2
 
属性ID 条件类型
3 CONTAINS(包含)
4 IN(在...中)
8 EQUALS(等于)
7 EQUALS
[0052]请回头参看图1，分析步骤包括创建条件索引的步骤1.2.1。在SQL中，在表上创建索引，以更快速并高效地定位行。在表的一列或多列上创建SQL的索引。任何给定表都可以具有多个索引，给每一个索引都赋予唯一的名称。索引一般是作为附加表来实现的，附加表具有被索引的列的值，带有指向出现了这些值的实际行的指针。
[0053]在本发明的一个示例中，一旦简化了where子句中的表达式，则将查询分析为其多个组成条件创建索引，这些组成条件对应于每一个唯一条件。条件索引取决于条件中所使用的属性和运算符。将存在与条件中所使用的属性和运算符的每一个唯一的组合相对应的索引。
[0054]条件索引是作为表实现的，这些表具有指向对于给定“值或值集合”为真的条件的指针，和使用这些条件的查询。条件索引存储不同的值或值的范围，以及指向对于这些值将为真的实际条件的指针，以及使用这些条件的查询。条件索引的类型由条件中所使用的运算符来规定。
[0055]在运算符之中，以下运算符被视为范围运算符，所有的这些运算符都可以简化为下面的表所示的BETWEEN形式。
 
运算符 描述 操作数 等效between(介于...之间)                  
> 大于 N BETWEEN(N+1 and+∞)(介于N+1与+∞之间)
< 小于 N BETWEEN(-∞ and N-1)
>＝ 大于等于 N BETWEEN(N and+∞)
<＝ 小于等于 N BETWEEN(-∞ and N)
[0056]LIKE(相似)运算符实际具有三个变种：(1)Begins with(以...开始)；(2)Ends with(以...结束)；以及(3)Part of(作为...的一部分)。由于在本发明的一个示例中如何处理这些的差异，单独地索引LIKE运算符的这些变种。此外，还使用EQUALS索引的变种，索引IN运算符。下面的描述说明了用于每一种条件的索引机制。
[0057]“等于”条件索引在一组表中映射列的所有不同的值，这些值被用在具有“等于”运算符和唯一条件标识符的条件中。列的唯一标识符、条件的值和唯一标识符、及其他与条件相关的字段被存储在等于索引中。通过使用此索引，给定列不同的值，返回对于给定列值都为“真”的所有“等于”条件。
[0058]在一个示例实现方式中，有两个表，每一个表都用于为每一种属性(如文本、数字和日期)创建“等于”条件索引。使用下面所描述的“文本值索引”和“索引条件”表，来实现文本“等于条件索引”。
[0059]“文本值索引”表包括下面的列：(1)“索引ID”，数据类型Numeric(数值)；(2)“属性ID”，数据类型Numeric；以及，(3)“TextValue”，数据类型Text(文本)。此表应该具有主键“索引ID”。每次添加属性和值的新的唯一的组合时，都会生成索引ID，作为运行(running)序列号。
[0060]“索引条件”表在各种条件索引之间是共同的，它包括下面的列：(1)“索引ID”，数据类型Number(数字)；(2)“QueryNumber”，数据类型Numeric；(3)“Query Part Number”，数据类型Numeric；(4)“Number of Conditions in Part”，数据类型Numeric。此表具有由“索引ID”、“Query Number”和“Query Part Number”组成的主键。
[0061]这两个表使用“索引ID”列，链接起来。例如，考虑示例查询Q1.C3＝{Job Type＝′E′}的条件C3。这是“等于”条件。值“E”第一次和“等于”条件中的列“Job Type”一起使用时，向“文本值索引”表中添加一行。在示例求职者表1中，Job Type列的属性ID为8。如此，在“文本值索引”表中添加带有下列值的行
 
索引ID 属性ID 值
1 8 ′E′
[0062]示例查询Q1的条件C4＝{Work Status＝′FT′}将导致在“文本值索引”表中添加下列行。
 
索引ID 属性ID 值
2 7 ′FT′
[0063]类似地，创建“数值等于”条件索引和“日期等于”条件索引，唯一区别是“Numeric Value”和“Date Value”列代替了“TextValue”列。下面将描述“数值索引”和“日期值索引”表的结构。
[0064]“数值索引”表包括下面的列：(1)“索引ID”，数据类型Numeric；(2)“Atrribute(属性)ID”，数据类型Numeric；以及，(3)“Number Value”，数据类型Numeric。此表应该具有主键“索引ID”。
[0065]“日期值索引”表包括下面的列：(1)“索引ID”，数据类型Numeric；(2)“属性ID”，数据类型Numeric；以及，(3)“DateValue”，数据类型Date(日期)。
[0066]此表应该具有主键“索引ID”。“日期值索引”和“数值索引”表也使用“索引ID”列链接到“索引条件”表。“日期值索引”用于Date的包括所有格式的所有变种，如DateTime，Julian Date。
[0067]也使用用于“等于”运算符的相同表的集合，处理“In”运算符。尽管使用“等于”运算符的条件会得到“值索引”表中的一行，但是，将存在与条件中的操作数的数量相同数量的“值索引”行。对应于“In”条件中的每一项，向“值索引”表中插入一行，其带有列的唯一标识符、该项的值、以及“索引ID”。
[0068]例如，考虑示例查询Q1.C2＝{Location in(′NY′，′NJ′)}中的条件C2。这是“In”条件。在操作数中，它具有两个项“NY”和“NJ”。在示例表中，列Location的ID为4。对应于此条件，按如下方式向TEXT Value索引中插入两行。
 
索引ID 属性ID 值
3 4 ′NY′
4 4 ′NJ′
[0069]同样，在“索引条件”表中，条件将被映射到“索引ID”3和4。类似于“等于条件”索引，“In Condition”索引也使用“文本值索引”、“数值索引”和“日期值索引”表，取决于条件中所使用的列的数据类型。
[0070]“不等于”条件索引用于将具体列值映射到“不等于”条件。“不等于”条件索引中所使用的原理是，所有“不等于”条件始终是“真”，除非在值-“列ID”配对上存在匹配。给定列-值对，可以使用此索引快速地检索涉及该列的所有“Not Conditions”。这是通过使用Index来定位使用了等于给定值的值的条件，并从涉及给定列的NOT条件的全部集合中删除这些，来实现的。
[0071]在本发明的一个示例中，“Not Condition”索引是与“索引条件”表一起使用“非文本值索引”、“非日期值索引”和“非数值索引”表来实现的。
[0072]“非文本值索引”表包括下面的列：(1)“索引ID”，数据类型Numeric；(2)“属性ID”，数据类型Numeric；以及，(3)“TextValue”，数据类型Text。此表应该具有主键“索引ID”。此表使用“索引ID”列来链接到“索引条件”表。
[0073]例如，请看下面的示例条件，所有这些条件都与列CareerLevel(ID＝6)有关。
C5＝{Career Level Not＝＂XP＂}
C6＝{Career Level Not＝＂M＂}
C7＝{Career Level Not＝＂E＂}
C8＝{Career Level Not＝＂S＂}
C9＝{Career Level Not＝＂EX＂}
[0074]对应于这些条件，将按如下方式填充“非文本值索引”表。
 
索引ID 属性ID 值
5 6 ＂XP＂
6 6 ＂M＂
7 6 ＂E＂
8 6 ＂S＂
9 6 ＂EX＂
[0075]在此示例中，如果在“Career Level”列中对于值“M”必须检索“真”条件，则首先从“非文本值索引”中检索对应于“CareerLevel”列的所有索引ID。这会得到集合5，6，7，8和9。现在，从该集合中删除对应于“M”的索引ID(其为6)。这会得到5，7，8和9的索引ID集合。现在，从“索引条件”表中检索针对这4个索引ID的所有条件。
[0076]类似地，创建“数值不等于”条件索引和“日期不等于”条件索引，唯一区别是“Numeric Value”和“Date Value”列代替了“TextValue”列。下面将描述“非数值索引”和“非日期值索引”表的结构。
[0077]“非数值索引”表包括下面的列：(1)“索引ID”，数据类型Numeric；(2)“属性ID”，数据类型Numeric；以及，(3)“NumberValue”，数据类型Numeric。此表应该具有主键“索引ID”。
[0078]“非日期值索引”表包括下面的列：(1)“索引ID”，数据类型Numeric；(2)“属性ID”，数据类型Numeric；(3)“DateValue”，数据类型Date。此表应该具有主键“索引ID”。“非日期值索引”和“非数值索引”表也使用“索引ID”列链接到“索引条件”表。
[0079]还结合“Not In XREF”表一起使用用于“不等于”运算符的同一表集合，来处理“Not In”运算符。尽管使用“等于”运算符的条件会得到“非值索引”表中的一行，但是，将存在与“Not in”条件中的操作数的数量相同数量的“非值索引”行。对应于“Not In”条件的每一项，向“非值索引”表中插入一行。向“非值索引”表中插入列的唯一标识符、项的值和“索引ID”。在“Not In XREF”表中，插入每一个“NotIn”条件的唯一索引ID，被映射到对应于“Not In”条件的每一项的每一个索引Id。索引条件表将条件映射到“Not In XREF”表的索引ID。
[0080]例如，请看条件C10＝{Career Level Not in(＂M＂，＂E＂)}。这是“NotIn”条件。在操作数中，它具有两个项“M”和“E”。对应于此条件，如果这些值在表中不存在，则按如下方式向“非文本值索引”中插入两行。
 
索引ID 属性ID 值
10 6 ＂M＂
11 6 ＂E＂
[0081]此外，还向“Not In XREF”表中插入下面的行。
 
索引ID 属性ID 值索引ID
12 6 10
12 6 11
[0082]同样，在“索引条件”表中，条件C10将被映射到“索引ID”12。
[0083]如果在“非文本值索引”中已经存在任何值，则不插入行，而是在“Not In XREF”表中，条件将被映射到对应于现有的行的索引ID。
[0084]换句话说，例如，假设在添加条件C10＝{Career LevelNot in(＂M＂，＂E＂)}之前“非文本值索引”表看起来如下：
 
索引ID 属性ID 值
5 6 ＂XP＂
6 6 ＂M＂
7 6 ＂E＂
8 6 ＂S＂
9 6 ＂EX＂
[0085]在此情况下，不添加新的行，“Not In XREF”应该具有如下所示的行。
 
索引ID 属性ID 值索引ID
12 6 6
12 6 7
[0086]类似于“不等于条件”索引，“Not In Condition(不在...之中条件)”索引也使用“非文本值索引”、“非数值索引”和“非日期值索引”表，除了取决于“Not In XREF(不在...之中XREF)”表之外，还取决于条件中所使用的列的数据类型。
[0087]如分析查询部分所讨论的，以下运算符被视为范围运算符，所有的这些都可以规范化为如下所示的between形式。
 
运算符 描述 操作数 等效between
> 大于 N BETWEEN(N+1 and+∞)
< 小于 N BETWEEN(-∞ and N-1)
>＝ 大于等于 N BETWEEN(N and+∞)
<＝ 小于等于 N BETWEEN(-∞ and N)
[0088]此外，NOT BETWEEN(N and M)还被规范化为{BETWEEN(-∞ and N-1)OR BETWEEN(M+1 and+∞)}。
[0089]这类规范化要求对于所有这些范围运算符都只有一个索引。“Between Condition Index(在...之间条件索引)”，也叫做“Rangeindex(范围索引)”，允许快速而高效地确定对于列的给定值为“真”的所有范围条件。由于范围的连续性质，这些通常仅对于Numeric和DATE属性可以实现。对于TEXT属性范围，可以通过选择现有技术中已知的任何一个标准字符序列(如ASCII，等等)来实现。
[0090]范围是通过下限和上限指定的。在本发明的一个示例中，针对查询的所有范围都被转换为一个全包括性(all-inclusive)between范围，其中所有范围的上下限都在经转换的范围内。范围索引表本质上是几个不相交叠的区间与对于该区间内的任何值都为“真”的条件之间的映射。如此，对于特定列的任何给定值，如果确定了此值所在的区间，那么，可以非常快速地确定对于该列值为“真”的所有条件。
[0091]例如，考虑不动产数据库，其具有“Home price(住宅价格)”作为一个列，以及下列条件。
C1＝{＂Home Price＂Between 200001 and 300000}
C2＝{＂Home Price＂Between 250001 and 400000}
C3＝{＂Home Price＂Between 200001 and 400000}
C4＝{＂Home Price＂Between 500001 and 600000}
C5＝{＂Home Price＂Between 350001 and 600000}
[0092]通过利用200001到300000的区间在”范围”索引表中创建一行，来索引第一条件C1。此行被映射到条件C1。在图2A用图形方式显示了结果，显示了在向“Home Price”范围索引中添加了此条件之后会发生什么。此时使用此索引，条件C1将被认为对于落在此区间(200001～300000)内的任何“Home Price”值都为真，所有其他值都将没有“真”条件。
[0093]通过添加条件C2，会导致现有行的区间被修改，并向范围索引表中再添加一行。新的条件的下限250001落于区间{200001～300000)的中间。如图2B所示，这会导致原始行被分离为两行，这两行的区间为R1(200001～250000)和R2(250001～300000)。还创建另一个带有区间R3(300001～400000)的行，以覆盖条件中指定的范围。现在，条件C1被映射到行R1和R2，而条件C2被映射到行R2和R3。
[0094]此时使用此索引，条件C1将被认为对于落在区间(200001～250000)内的“Home Price”的任何值都为“真”，C1和C2将被认为对于落在区间(250001～300000)内的所有值都为“真”，条件C2将被认为对于落在区间(300001～400000)内的所有值都为“真”，而所有其他值都没有“真”条件。
[0095]当添加条件C3时，整个范围被行R1、R2和R3中的三个区间覆盖，因此，没有添加新范围索引行。条件C3被映射到所有这三行。如图2C所示。
[0096]此时使用此索引，条件C1和C3将被认为对于落在区间(200001～250000)内的“Home Price”的任何值都为“真”，C1、C2和C3将被认为对于落在区间(250001～300000)内的所有值都为“真”，条件C2和C3将被认为对于落在区间(300001～400000)内的所有值为“真”，而所有其他值都没有“真”条件。
[0097]条件C4具有完全在所有现有的行区间以外的范围，因此，当添加它时，将会添加新的行R4，其区间等于该条件范围，并将条件C4映射到此行。如图2D所示。
[0098]此时使用此索引，条件C1和C3将被认为对于落在区间(200001～250000)内的“Home Price”的任何值都为“真”，C1、C2和C3将被认为对于落在区间(250001～300000)内的所有值都为“真”，条件C2和C3将被认为对于落在区间(300001～400000)内的所有值都为“真”，条件C4将被认为对于落在区间(500001～600000)内的所有值都为“真”，而所有其他值都没有“真”条件。
[0099]通过添加条件C5，会导致现有行(R3)的区间被修改，并向范围索引表中再添加一行。新的条件的下限350001落在区间{300001～400000)的中间。这会导致将原始行(R3)分离成带有区间R3(300001～350000)和R5(350001～400000)的两个行。还创建另一个带有区间R6(400001～500000)的行，以覆盖该条件中指定的其余范围。现在，将条件C1映射到行R3，R5，R6和R4。如图2E所示。
[0100]此时使用此索引，条件C1和C3将被认为对于落在区间(200001-250000)内的“Home Price”的任何值都为“真”，C1、C2和C3将被认为对于落在区间(250001～300000)内的所有值都为“真”，条件C2和C3将被认为对于落在区间(300001～350000)内的所有值为“真”，条件C2，C3和C5将被认为对于落在区间(350001～400000)内的所有值都为“真”，C5将被认为对于落在区间(400001～500000)内的所有值都为“真”，C4和C5将被认为对于落在区间(500001～600000)内的所有值都为“真”，而所有其他值都没有“真”条件。
[0101]在根据本发明的示例实现方式中，假设“Home Price”列的属性ID为10，数值范围索引表如下。
 
索引ID 属性ID 下限 上限
21 10 200001 250000
22 10 250001 300000
23 10 300001 350000
24 10 500001 600000
25 10 350001 400000
26 10 400001 500000
[0102]如此设计NumericRangeIndex和DateRangeIndex表，以便没有交叠的范围。当向AttributeList表中添加数值或日期属性时，向NumericRangeIndex或DateRangeIndex表中添加适当的通用范围。与属性关联的任何范围将是此通用范围的子集。当添加范围时，包含新范围的下限和上限的现有的范围会被拆分。例如，考虑必须添加到数据库中的范围(L，U)，L是其下限，U是其上限。如果数据库中有覆盖范围(L，U)的一部分，例如，(L，u)，的范围(l，u)，则范围(l，u)被分成两个范围(l，L-l)和(L，u)。如此，每当添加一个范围时，至多创建两个现有的范围，即，一个覆盖所述范围的上限的范围，和一个覆盖所述范围的下限的范围。
[0103]条件中指定的范围通常映射到RangeIndex表中的一组范围。RangeIndex表中的每个范围都在IndexXRef表中具有对应的条目。随着数据库的增长，范围倾向于变得越来越小，数量变得越来越多。如果希望向巨大的数据库中插入宽的范围，则IndexXRef表中的要被更新的记录的数量会非常大。如此，处理范围的如前所述的过程被证明是昂贵的。为克服此问题，本发明的一个示例包含一组表，即，HigherOrderNumericRangeIndex和HigherOrderDateRangeIndex表。
[0104]在此示例中，每一个数值和日期属性都与范围的层次结构关联。此后，此层次结构将被称为“树”。该树的每一个节点都代表一个范围。根代表通用范围。子节点是它们的父节点的不相交子集，以子节点为代表的范围的并集完全覆盖父范围。如此，最宽的范围由根代表，最窄的范围由一个叶子代表。
[0105]应该指出的是，不必对一个节点可以具有的范围的宽度或子节点的数量施加任何规则性。基于对属性的性质的分析，以及它们的值在业务问题中的分布，可以对整个树预先播种。每一个节点还都具有“范围级”编号，这是节点从树的底部起的高度。根获得最高的范围级，叶子获得最小的范围级。当需求一个作为树的叶子的子集的范围时，向该叶子添加代表该范围的特殊节点(例如，叫做0级节点)。0级节点是向RangeIndex表中添加的那些节点。在HigherOrderRangeIndex表中预先播种了所有其他较高级的节点。
[0106]假设对于特定属性，树看起来像如图3所示的那样。如此示例所示，2-级范围0-50k被分成五个1-级范围，而2级范围200k-∞被分成两个1级范围(原因是0-50k范围中的命中频率很高)。根0-∞范围具有最高级(3)，级沿着树降低。
[0107]如果希望向系统中添加范围，那么，从根开始，本处理开始从顶部向下对树进行分析。如果一个节点完全在添加的范围内，那么，它直接就包括在该节点中。如果一个节点比添加的范围本身更宽，或比添加的范围的一部分更宽，那么，探查该节点的子节点。如果一个节点不与添加的范围交叠，那么，忽略该节点。如此，如果添加范围35，001-250k，则本处理探查根的子节点，因为根范围(0-∞)比给定范围更宽。现有的2级节点50-100k，100-150k和150-200k完全在给定范围内。如此，这些被直接包括。由于现有的2级节点0-50k和200-∞包含给定范围的一部分，因此本处理探查它们的子节点。
[0108]在0-50k节点的子节点中，节点40-50k完全在该范围内，而30-40k包括该范围的一部分。注意，30-40k节点是叶子，没有任何子节点要探查。如此，向现有的0级30-40k节点中添加0级节点(30-35k)，以便不与所包括的节点中的任何一个节点交叠，但是，完全覆盖添加的范围。类似地，向现有的0级节点200-500k添加0级节点200-250k。
[0109]由于树是作为HigherOrderRangeIndex表中的记录存储的，因此，对应于包括的节点，更新IndexXRef表中的记录。如前一部分所描述的，向RangeIndex表中添加0级节点。如此，HigherOrderRangeIndex表被保持静态，而随着添加查询，0级节点被插入到RangeIndex表中。HigherOrderRangeIndex表的RangeOrder列标识节点的高度。
[0110]以这样的方式播种范围，以便发现预先播种的范围的可能性对于频繁出现的范围比较高。如果有的话，这还将缩小0-级范围的宽度。换句话说，如果特定预先播种的范围内的范围的出现概率比较高，则该范围被分成较小的子范围。如果预计特定范围的子范围很少出现，则该范围被分成较大的(较少的)子范围。
[0111]例如，考虑给出一个人的工资的数值属性。此属性的通用范围将是0到∞。预计工资的分布具有大约70k的中值。考虑2个范围60-80k和0-30k。可以预期，在前一范围内，有较高的命中频率，在后一范围内，有较低的命中频率。如此，范围60-80k被分为，例如，二十个范围，每一个的宽度为1000，而范围0-30k被分为仅两个范围。根据某些方面，优选情况下，本发明避免了重新分割现有的范围，因为这会导致记录的拷贝。
[0112]在SQL中，使用“LIKE”运算符来部分地匹配列中的文本字符串。“LIKE”运算符有三个变种。考虑下列条件。
[0113]C20＝{Name Like′John％′}。这将返回表中的所有具有以“John”开始的姓名列的行。在示例表中，这将是行1和3。这类条件叫做“以...开始(Starts with)”条件。
[0114]C21＝{Name Like′％Smith′}。这将返回表中的所有具有以“Smith”结尾的姓名列的行。在示例表中，这将是行3，4，5，6，7和8。这类条件叫做“包含(Contains)”条件。
[0115]C22＝{Name Like′％Doe％′}。这将返回表中的所有具有姓名列的如下行，即，其中，“Doe”是它的位于任意位置的一部分。在示例表中，这将是行1，2和8。这类条件叫做“作为...的一部分(Part of)”条件。
[0116]“LIKE”条件索引和对应的匹配算法的设计目标是快速地检索匹配一个列的任何给定值的所有“相似”条件。
[0117]与作为表实现的其他条件索引不同，在本发明的一个示例中，使用“双链接的树”数据结构，实现“相似条件索引”。由于必须执行局部匹配，简单表不足以作为“LIKE”条件索引。使用“相似”条件中所使用的所有项，来构建字母表的树。构建三组树，三种“相似”条件中的每一个都有一组树。
[0118]在物理上，这些树可以以存储器结构或使用物理数据库表来实现。这里将讨论物理数据库实现方式。用两个表—节点和节点分支表—来实现树。构建对应于开始属性和每个起始字母的每一个组合的根节点。
[0119]图4A到4E和下面的描述显示了这些表的结构的一个示例。
[0120]为说明树的结构，考虑添加下列“以...开始”的“相似”条件，假设这些条件是第一条件。
C30＝{Name Like′John％′}
C31＝{Name Like′Jack％′}
C32＝{Name Like′Joan％′}
C33＝{Name Like′Johnson％′}
[0121]所有这些条件的根节点是“J”。在添加第一项“John”之前，根节点“J”没有子节点，“J”树看起来像如图4A所示的那样。如图4A所示，节点402被标记为“J”，其地址被初始化为1，父节点地址是NULL，由于此根节点没有父节点，子节点的数量最初是0，“N”用于表明，此节点不用于一个项的端点。此外，子节点的列表最初是空的。
[0122]在一个示例中，通常预先为每一个属性(在应用中，允许对其施加“相似”条件)创建所有根节点。例如，可以创建78个根节点，对于字母表的每一个字母，有三个节点，对应于三种“相似”条件。或者，取决于特定的应用，可以避免这种情况。至少，当在以字符开始的“相似”条件中使用一个项时，创建根节点。
[0123]在创建根节点402之后，数据库中的节点表看起来如下。
 
索引ID 节点字符串 项端点
1001 J N
[0124]此时没有“节点分支”(Node Branch)记录。
[0125]在添加第一条件C30＝{Name Like′John％′}之后，子节点404被添加，根节点402被适当地更新，树看起来如图4B所示。注意，对于子节点404，项端点标记被标记为Y，因为条件C30中的项以“JOHN”结束。下面将比较详细地说明此字段的意义。如进一步所显示的，根节点402进一步被更新，以显示它具有1个子节点，并向子节点的列表中的第一个条目中添加子节点路径和地址。更具体来说，对于“J”后面的第一个字母，节点路径被标记了“O”，子节点地址被初始化为11。相应地，子节点404被标记了“JOHN”，其地址被初始化为11，其父节点地址被设置为1，而其子节点的数量被初始化为0。
[0126]在数据库中，向节点表中添加一行，在此接合点，在“节点分支”表中创建一行，如下所例示。
[0127]节点表：
 
索引ID 节点字符串 项端点
1001 J N
1002 JOHN Y
[0128]节点分支表：
 
父索引ID 分支路径 子索引ID
1001 O 1002
[0129]通过添加条件C31＝{Name Like′Jack％′}，修改了树，如图4C所示。此时，有两个可以从根节点402遍历的路径，一个导向项“John”的子节点404，另一个导向项“Jack”的新添加的节点406。如进一步所显示的，根节点402进一步被更新，以显示它具有2个子节点，并向子节点的列表中的第二个条目中添加新的子节点路径和地址。更具体来说，对于“J”后面的第一个字母，节点路径被标记了“A”，子节点地址被初始化为12。相应地，新的子节点406被标记了“JACK”，其地址被初始化为12，其父节点地址被设置为1，而其子节点的数量被初始化为0。
[0130]数据库表被修改为如下。节点表被修改为如下：
 
索引ID 节点字符串 项端点
1001 J N
1002 JOHN Y
1003 JACK Y
[0131]节点分支表被修改为：
 
父索引ID 分支路径 子索引ID
1001 O 1002
1001 A 1003
[0132]通过添加条件C32＝{Name Like′Joan％′}，会导致对树进行修改，如图4D所示。注意，因为“Joan”以“Jo”开始，类似于“John”，这要求向节点404添加两个子节点，并将节点404改变为父节点。如图所示，节点404被更新，以具有标记“JO”，还显示了它具有2个子节点，端点字段被改变成“N”，(因为现在该项不以“JO”结束)，并且向节点404中的子节点列表中的第一个条目添加两个子节点路径和地址。更具体来说，对于“JO”后面的第一个字母，第一节点路径被标记了“A”，第一子节点地址被初始化为111。对于“JO”后面的第一个字母，第二节点路径被标记了“H”，第二子节点地址被初始化为112。相应地，第一子节点408被标记了“JOAN”，其地址被初始化为111，其父节点地址被设置为11，而其子节点的数量被初始化为0。类似地，第二子节点410被标记了“JOHN”，其地址被初始化为112，其父节点地址被设置为11，而其子节点的数量被初始化为0。
[0133]数据库表被修改为如下。节点表被改变成：
 
索引ID 节点字符串 项端点
1001 J N
1002 JOHN Y
1003 JACK Y
1004 JO N
1005 JOAN Y
[0134]节点分支表被改变为：
 
父索引ID 分支路径 子索引ID
1001 O 1004
1001 A 1003
1004 H 1002
1004 O 1005
[0135]通过添加条件C33＝{Name Like′Johnson％′}，改变了树，如图4E所示。注意，因为“Johnson”以“John”开始，类似于“John”，这要求向节点410添加一个子节点，将节点410改变为父节点。如图所示，节点410的标记仍是“JOHN”。同时，它被更新，以显示它具有1个子节点，端点字段仍是“Y”(因为“John”的项仍以“JOHN”结束)，并向节点410中的子节点的列表中的第一个条目中添加子节点路径和地址。更具体来说，对于“JOHN”后面的第一个字母，节点路径被标记了“S”，第一子节点地址被初始化为1121。相应地，新的子节点412被标记了“JOHNSON”，其地址被初始化为1121，其父节点地址被设置为112，而其子节点的数量被初始化为0。数据库表被按如下方式修改。
[0136]节点表被修改为：
 
索引ID 节点字符串 项端点
1001 J N
1002 JOHN Y
1003 JACK Y
1004 JO N
1005 JOAN Y
1006 JOHNSON Y
[0137]节点分支表被修改为：
 
父索引ID 支路 子索引ID
1001 O 1004
1001 A  1003
1004 H 1002
1004 O 1005
1002 S 1006
[0138]通过将树的“节点键”连接到索引条件表的“索引ID”列，链接了这些树和索引条件表。
[0139]在此示例中，索引了“以...开始”的“相似”条件。在其自己的树中，也以完全相同的方式索引了“包含”的“相似”条件。
[0140]对于“以...结束”型的“相似”条件，操作数中的项被颠倒，以最后一个字符开始，后面是倒数第二个字符，依次类推，直到使用第一个字符和颠倒的项来构建树。节点中的树本身和字段，对于所有三种“相似”条件，是相同的。
[0141]此外，对于每一个所使用的列(属性ID)，构建一个单独的树。然而，在物理实现方式中，不同的列的不同的树可以存储在一个物理数据库或存储器结构中。
[0142]使用“不相似”条件索引，将具体列值映射到“不相似”条件。可以以完全相同的方式，向“相似”条件中嵌入“不相似”条件索引。与列(属性ID)关联的所有“不相似”条件都被视为“真”，从此集合中，排除了被发现使用“不相似匹配算法”的匹配的所有条件。
[0143]在本发明的一个示例中，“不相似”条件索引的实现方式可以与“LIKE”条件索引的实现方式完全相同。下面比较详细地描述的匹配算法说明了在“相似”和“不相似”条件中如何使用两个索引树的区别。
[0144]前几年，大多数数据库供应商在他们的数据库引擎中集成了文本搜索，作为SQL的一部分。全文搜索功能允许SQL用户快速地搜索数据库列中的关键字。数据库引擎关键字提取算法从特定列中提取关键字，并对这些关键字进行索引。当SQL查询使用CONTAINS运算符时，数据库引擎查询该索引，并返回包含该关键字的所有行。
[0145]示例查询Q1的条件C1{CONTAINS(Skills，′.net′)}使用CONTAINS运算符。此条件对于表的在“Skills”列中具有项“.net”的任何行都为“真”。在示例表1中，此条件将对于行1和2都为“真”。通常在应用中，对于本质上冗长的列，如工作说明、经验总结等等，使用全文本索引和CONTAINS运算符。
[0146]在本发明的一个示例中，对于在CONTAINS条件中所使用的每一个关键字，创建将关键字映射到条件的简单索引。在一个优选的实现方式中，使用两个表来创建“包含”条件索引。使用“包含关键字索引(Contains Keyword Index)”和“索引条件(IndexConditions)”表，来实现“包含”条件索引。
[0147]“包含关键字索引”表包括下面的列：(1)“索引ID”，数据类型Numeric；(2)“属性ID”，数据类型Numeric；以及，(3)“Keyword Value”，数据类型Text。此表应该具有主键“索引ID”。每次添加属性和关键字值的新的唯一的组合时，都生成索引ID，作为运行序列号。此表使用列“索引ID”链接到“索引条件”表。
[0148]考虑示例查询Q1的条件C1{CONTAINS(Skills，′.net′)}。这是“包含”条件。第一次值“.net”和列“Skills”一起用于“包含”条件中时，向“包含值索引(Contains Value Index)”表中添加一行。在该示例中，Skills列的属性ID为3。如此，在“包含关键字索引”表中添加带有下列值的一行：
 
索引ID 属性ID 值
101 3 ＂.net＂
[0149]当添加新的一行时，对列skills执行关键字提取，“包含关键字索引”表中的每一个关键字，都用于确定所有“真”条件。
[0150]使用“不包含关键字索引”表，来实现“不包含”条件索引。该索引的创建可以与针对“包含”条件的索引的创建相同。“不包含”条件中所使用的关键字被映射到表中的“索引ID”。
[0151]使用“不包含关键字索引”和“索引条件”表，来实现“不包含”条件索引。“不包含关键字索引”表包括下面的列：(1)“索引ID”，数据类型Numeric；(2)“属性ID”，数据类型Numeric；以及，(3)“Keyword Value”，数据类型Text。此表应该具有主键“索引ID”。每次添加属性和关键字值的新的唯一的组合时，都生成索引ID，作为运行序列号。此表使用列“索引ID”链接到“索引条件”表。
[0152]“包含”和“不包含”条件实现方式之间的区别主要在于“查找匹配条件”步骤，下面将比较详细地对这一区别进行描述。
[0153]返回到图1，在查询被分析，规范化为析取范式(步骤1.2)并为每一个条件创建所有索引(步骤1.2.1)之后，利用有关条件和查询的信息填充索引条件交叉引用表(步骤1.3)。此索引条件交叉引用的存在的理由是，在给定了一组“真”条件的情况下，快速地确定所有匹配查询。此表与上文所讨论的所有索引表关联。
[0154]查询的析取范式用于填充索引条件表。在“创建条件索引”步骤中，对应于每一个唯一条件，在一个索引表中创建索引记录，并通过“索引ID”的值，唯一地标识该索引记录。在此步骤中，在对应于查询表达式中的每一个条件的索引ID与析取范式中的条件的每次出现之间创建映射。
[0155]考虑上面所显示的示例查询Q1。从此查询中，标识下列条件：
C1＝CONTAINS(Skills，′.net′)
C2＝{Location in(′NY′，′NJ′)}
C3＝{Job Type＝′E′}
C4＝{Work Status＝′FT′}
[0156]如前面所讨论的，索引这些条件，下面是条件到索引的示例映射。
 
条件 索引类型 索引ID
C1＝CONTAINS(Skills，′.net′) 包含关键字索引 101
C2＝{Location in(′NY′，′NJ′)} 文本值索引 3，4
C3＝{Job Type＝′E′} 文本值索引 1
C4＝{Work Status＝′FT′}； 文本值索引 2
[0157]查询表达式的代数析取范式是
Q1＝(C1＊C2＊C3)+(C1＊C2＊C4)。
[0158]这进一步通过将每一个乘积简化为其自己的一部分来进一步规范化：
Q1＝P1+P2
P1＝(C1＊C2＊C3)；
P2＝(C1＊C2＊C4)
[0159]换句话说，当P1是“真”或者P2是“真”时，Q1是“真”。
[0160]一旦查询被简化为其析取范式，就在查询、部分和条件之间创建交叉引用，例如，如下所示。
 
查询编号 部分号 条件编号 部分中的条件数
1 1 1 3
1 1 2 3
1 1 3 3
1 2 1 3
1 2 2 3
1 2 4 3
[0161]向此交叉引用映射索引ID，并导出索引条件表的行。在此示例中，将条件1映射到索引ID 101。因此，向具有条件1的每一行映射索引ID 101。向包含条件2的每一行映射“索引ID”3和4。如此，导出下面的索引条件表，如下面的表3所显示的。
表3
 
索引ID 查询编号 部分号 条件编号 部分中的条件数
101 1 1 1 3
3 1 1 2 3
4 1 1 2 3
1 1 1 3 3
101 1 2 1 3
3 1 2 2 3
4 1 2 2 3
2 1 2 4 3
[0162]一旦完成了此步骤，则查询的处理过程完成。如上文所提及的，根据本发明的一个示例，这可以在其中一个触发步骤之后完成处理过程。应该指出的是，可以以许多方式实现如上文所描述的创建和更新的索引和表。例如，它们可以保留在永久的或固定的存储器中，或者，它们可以被高速缓存或保留为blob，或以Java或C++作为数组或集合来实现。所属领域的技术人员将理解各种可能的替代实现方式。
[0163]此外，取决于应用，从数据库内或从外部数据库，新的或变更的记录将被通知给本发明。此事件应该触发图1的步骤2.1所显示的“匹配记录到查询”处理流程。在一个示例中，用于调用应用程序的接口将提供完整的记录，并且本发明的引擎将返回匹配此记录的所有查询的标识符，或者，如果在匹配过程中存在失败，则它将返回适当的错误消息。
[0164]接着，在步骤2.2中，标识对于给定记录为“真”的所有条件。这是利用参考上面的步骤1.2.1所讨论的各种条件索引表来完成的。将新记录的每一列与和该列关联的适当索引进行匹配，然后检索匹配该列的给定值的所有“索引ID”。通过使用在步骤1.2中创建的“属性条件XREF”表，确定每一个属性的条件类型。这避免了可能不会返回行的表查找(lookup)。
[0165]例如，考虑添加下面的记录。
 
RowNumID-1 NameID-2 Skills ID-3 LocationID-4     EducationLevelID-5      CareerLevelID-6   WorkstatusID-7   JobTypeID-8 CompanyCategoriesID-9      
11 JohnnySmith  .net，SQLSERVER，MSACCESS  NY M XP FT E IT
[0166]假设只有查询1此时被添加到系统中，“属性条件XREF”表看起来如下所示。
 
属性ID 条件类型
3 CONTAINS
4 IN
8 EQUALS
7 EQUALS
[0167]这将表示，3，4，8和7的属性(即，列)将用于匹配算法中，以检索此记录的有效“索引ID”。下面几节描述了使用条件索引检索不同类型的条件的示例方法。
[0168]对于“属性条件XREF”表中的具有条件类型“等于”的每个属性，执行步骤2.2中的“查找匹配等于条件”处理。
[0169]给定一个列的值，通过对三个“值索引表”中的一个执行简单查询，来确定此值的匹配“索引ID”，其中，属性ID等于给定列的属性ID，值等于给定值。如果该列是文本数据类型的，则使用“文本值索引”。“数值索引”和“日期值索引”表分别用于Date和Number字段。
[0170]例如，在Johnny Smith的记录(11)中，“Job Type”列(属性ID＝8)具有“E”值。为确定对此列和等于条件有效的“索引ID”，使用“文本值索引”表。在添加示例查询Q1之后，“文本值索引”表看起来如下所示。
 
索引ID 属性ID 值
1 8 ＂E＂
2 7 ＂FT＂
3 4 ＂NY＂
4 4 ＂NJ＂
[0171]相应地，下面的SQL语句，当执行时，将检索出索引ID1：
Select Index ID
From Text V alue Index
Where Attribute ID＝8(parameter 1)and
Value＝＂E＂(parameter 2)
[0172]类似地，对应于示例中的就业状况列(属性ID＝7)(其具有值“FT”)，利用参数7和“FT”来执行相同的查询：
Select Index ID
From Text Value Index
Where Attribute ID＝7(parameter 1)and
Value＝＂FT＂(parameter 2)
[0173]这将得到索引ID 2。
[0174]类似地，对于数值属性，对于给定列(属性ID＝N)和值(M)而检索与“等于”条件相对应的所有有效索引ID的查询是
Select Index ID
From Numeric Value Index
Where Attribute ID＝N(parameter 1)and
Value＝M(parameter 2)
[0175]对于日期/时间属性，对于给定列(属性ID＝N)和值(DTTM)而检索与“等于”条件相对应的所有有效索引ID的查询是
Select Index ID
From Date Value Index
Where Attribute ID＝N(parameter 1)and
Value＝DTTM(parameter 2)
[0176]对于“属性条件XREF”表中的具有条件类型“不等于”的每个属性，执行查找匹配“不等于”条件处理。
[0177]给定文本列的值，通过从“非文本值索引”表中检索给定列的所有“索引ID”，来确定此值的匹配“索引ID”，其中，属性ID等于给定列的属性ID。从此列表中，删除匹配给定值的所有“索引ID”。所产生的列表代表与匹配该列的给定值的所有“不等于条件”相对应的索引ID。如果该列是文本数据类型的，则使用“非文本值索引”。“非数值索引”和“非日期值索引”表分别用于Date和Number字段。
[0178]例如，考虑下面的“非文本值索引”表。
 
索引ID 属性ID 值
5 6 ＂XP＂
6 6 ＂M＂
7 6 ＂E＂
8 6 ＂S＂
9 6 ＂EX＂
[0179]在上面的Johnny Smith的示例记录(行11)中，“CareerLevel”列(属性ID＝6)具有“XP”值。假设“属性条件XREF”表具有带有属性ID＝6并且条件类型＝“NOT EQUALS”的行，则按如下方式执行查找匹配“不等于”条件步骤。
[0180]下面的SQL语句，当执行时，将检索出索引ID{5，6，7，8以及9}：
Select Index ID
From Not Text Value Index
Where Attribute ID＝6(parameter 1)
[0181]现在，执行下面的SQL语句，以检索索引Id 5：
Select Index ID
From Not Text Value Index
Where Attribute ID＝6(parameter 1)
And Value＝＂XP＂(parameter 2)
[0182]此索引ID 5现在从初始集合{5，6，7，8以及9}中删除，以获得对于具有值“XP”的“Career Level”列(属性ID＝6)与不等于条件相对应的匹配索引ID{6，7，8以及9}。
[0183]或者，得到相同结果的下面的SQL也可以用于查找对于具有值“XP”的“Career Level”列(属性ID＝6)与不等于条件相对应的匹配索引ID{6，7，8以及9}。
Select Index ID
From Not Text Value Index
Where Attribute ID＝6(parameter 1)
And Value!＝＂XP＂(parameter 2)
[0184]对于带有Numeric和Date数据类型的列，该步骤可以完全相同，只是将分别使用“非数值索引”和“非日期值索引”。
[0185]对于“属性条件XREF”表中的具有条件类型“In”的每个属性，执行查找匹配“In”条件处理。该步骤可以与查找匹配“等于”条件步骤相同。
[0186]给定一个列的值，通过对三个“值索引表”中的一个执行简单查询，来确定此值的匹配“索引ID”，其中，属性ID等于给定列的属性ID，值等于给定值。如果该列是文本数据类型的，则使用“文本值索引”。“数值索引”和“日期值索引”表分别用于Date和Number字段。
[0187]例如，在上面的Johnny Smith的示例记录(11)中，“Location”列(属性ID＝4)具有“NY”值。为确定对此列和“In”条件有效的“索引ID”，使用“文本值索引”表。在添加示例查询Q1之后，“文本值索引”表看起来如下所示。
 
索引ID 属性ID 值
1 8 ＂E＂
2 7 ＂FT＂
3 4 ＂NY＂
4 4 ＂NJ＂
[0188]下面的SQL语句，当执行时，将检索出索引ID3。
Select Index ID
From Text Value Index
Where Attribute ID＝4(parameter 1)and
Value＝＂NY＂(parameter 2)
[0189]类似地，对于数值属性，对于给定列(属性ID＝N)和值(M)而检索与“In”条件相对应的所有有效索引ID的查询是
Select Index ID
From Numeric Value Index
Where Attribute ID＝N(parameter 1)and
Value＝M(parameter 2)
[0190]对于日期/日期时间属性，对于给定列(属性ID＝N)和值(DTTM)而检索与“In”条件相对应的所有有效索引ID的查询是
Select Index ID
From Date Value Index
Where Attribute ID＝N(parameter 1)and
Value＝DTTM(parameter 2)
[0191]对于“属性条件XREF”表中的具有条件类型“Not In”的每个属性，执行查找匹配“Not In”条件处理。
[0192]给定特定列的值，从“Not In XREF”表中检索对应于此列的所有“索引ID”。从此“索引ID”的集合中，删除被映射到对应于给定值的“值索引”的任何索引ID。如果该列是文本数据类型的，则使用“非文本值索引”。“非数值索引”和“非日期值索引”表分别用于Date和Number字段。
[0193]例如，在下列状态下考虑“Not In XREF”表：
 
索引ID 属性ID 值索引ID
12 6 6
12 6 7
[0194]在上面的示例记录(11)中，“Career Level”列(属性ID＝6)具有“XP”值。假设“属性条件XREF”表具有带有属性ID＝6并且条件类型＝“NOT IN”的行，按如下方式执行查找匹配“Not In”条件步骤。
[0195]下面的SQL语句将检索出集合1作为{12}
Select Distinct Index ID
From Not In XREF
Where Attribute ID＝6(parameter 1)
[0196]执行第二个SQL语句，以检索索引ID的空集{}作为Set2：
Select Distinct Index ID
From Not In XREF
Where Attribute ID＝6(parameter 1)
And Value Index ID in
   {Select Index ID
   From Not Text Value Index
   Where Attribute ID＝6(parameter 1)
   And Value＝＂XP＂(parameter 2)
[0197]Set1-Set2＝{12}是“Career Level”列的给定值(“XP”)的所有“真”“Not In”条件的集合。
[0198]对于带有Numeric和Date数据类型的列，该步骤可以完全相同，只是将分别使用“非数值索引”和“非日期值索引”来代替“非文本值索引”表。
[0199]对于“属性条件XREF”表中的具有条件类型“范围”的每个属性，执行查找匹配“范围”条件处理。
[0200]给定Numeric列以及其值，从对应于此列的数值范围索引表和较高级数值范围索引表中检索对应于此值的所有索引ID，其中，给定值落在行的区间内。如果该列是Date数据类型的，那么，使用日期范围索引和较高级日期范围索引表。
[0201]例如，考虑如上面的示例所描述的“数值范围索引”表：
 
索引ID 属性ID 下限 上限
21 10 200001 250000
22 10 250001 300000
23 10 300001 350000
24 10 500001 600000
25 10 350001 400000
26 10 400001 500000
[0202]假设利用等于$275000的“Home Price”列(属性ID＝10)的值添加了一个不动产记录，通过执行下面的SQL来检索对应于此的索引ID：
Select Index ID
From Numeric Range Index
Where Attribute ID＝10(parm1)and
Lower Limit<＝275000(parm2)and
Upper Limit>＝275000(parm2)
[0203]在此示例中，返回索引ID 22。
[0204]也对较高级数值范围索引表执行此相同的SQL语句，以获取对应于指定的列的给定值的所有索引ID。
[0205]对于“属性条件XREF”表中的具有条件类型“相似”的每个属性，执行查找匹配“相似”条件处理。如上文所阐述的，“相似”条件被分成3种类型：(1)“相似-以...开始”；(2)“相似-以...结束”；以及(3)“相似-作为...的一部分”。
[0206]给定文本列的值，使用“节点”和“节点分支”表，检索对应于“相似”条件的“索引Id”。下面说明了检索三种“相似”条件的“索引Id”的步骤。
[0207]对于“属性条件XREF”表中的具有条件类型“相似-以...开始”的每个属性，执行查找匹配“相似-以...开始”条件处理。对于该的给定值，“节点”和“节点分支”表用于标识包含列的给定值的与“相似-以...开始”条件关联的所有“索引ID”。这是通过遍历与给定列关联的“相似-以...开始”树来实现的。
[0208]图5中显示了在使用这两个表时涉及到什么的示例。如图5所示，节点表502包括每一个索引ID的条目，包括关联的属性ID(即，列)和树类型(例如，“以...开始”)。如上文所描述的，节点表502中的每一个条目也包括节点字符串和项端点指示器。如图5所进一步显示的和上文所描述的，节点分支表504可以包括链接到节点表中的一个或更多个父条目的多个条目，包括关联的属性ID(即，列)和树类型(例如，“以...开始”)，其应该与节点表502中的父条目相同。每一条目也包括如上文所描述的节点路径。
[0209]如图6所示的流程图说明了根据本发明的一个示例算法，其可以用来检索匹配“相似-以...开始”条件。通过如在此流程图中所讨论的那样针对该列的给定值对“相似-以...开始”树进行遍历，来检索所有“索引ID”。
[0210]下面将参考下面的示例比较详细地描述如图6所示的步骤。考虑在上文所描述的示例中添加的条件，以及在添加这些条件之后节点和节点分支表的状态。
C30＝{Name Like′John％′}
C31＝{Name Like′Jack％′}
C32＝{Name Like′Joan％′}
C33＝{Name Like′Johnson％′}
[0211]在添加这些条件之后节点表看起来像：
 
索引ID 节点字符串 项端点
1001 J N
1002 JOHN Y
1003 JACK Y
1004 JO N
1005 JOAN Y
1006 JOHNSON Y
[0212]节点分支表看起来像：
 
父索引ID 支路 子索引ID
1001 O 1004
1001 A 1003
1004 H 1002
1004 A 1005
1002 S 1006
[0213]现在，考虑上面的示例中的新记录：
 
RowNumID-1 NameID-2 SkillsID-3 LocationID-4     EducationLevelID-5      CareerLevelID-6   WorkstatusID-7   JobTypeID-8 CompanyCategoriesID-9      
11 JohnnySmith  .net，SQLSERVER，MSACCESS  NY M XP FT E IT
[0214]“姓名”列2具有Johnny Smith值。参考图6，下面的步骤涉及遍历图4E的示例所显示的“相似以...开始”树以及标识“索引ID”。首先，输入值是在步骤602中接收到的“Johnny Smith”。接下来，在步骤604中，输入值被分析为一串字符：
 
字符位置 值
1 ′J′
2 ′o′
3 ′h′
4 ′n′
5 ′n′
6 ‘y’
7 ″
字符位置 值
8 ′S′
9 ′m′
10 ‘i’
11 ′t
12 ′h′
[0215]接下来，在步骤606中，确定此值的根节点(“J”)。如果存在根节点(在步骤608中检查)，则处理继续，否则，匹配结束。在步骤610中，确定在输入字符串中是否存在更多字符。如果是，则通过确定输入字符串中的下一个字符，标识带有下一个字符的支路的节点分支，来在步骤612中继续本处理。在此示例中，下一个字符是“o”，存在根节点的带有等于“o”的支路的节点分支。相应地，如在步骤614中所检查的，存在分支，然后本处理继续进行到步骤616。在此步骤中，发现此分支的子节点，并确定其长度。在此示例中，此子节点中的字符串是“John”，其长度是4。接下来，在步骤618中，确定输入值的具有与子节点字符串相同长度的子字符串。在此示例中，输入值的长度为4的子字符串产生“John”。接下来，在步骤620中，将输入值子字符串与子节点字符串进行比较，然后在步骤622中，确定是否有匹配。在此示例中，子字符串匹配子节点的节点字符串。相应地，下一步骤624判断匹配子节点是否是项端点。在此示例中，回答是“是”，则子节点是项端点。相应地，在下一步骤624中，向匹配的索引ID中添加索引ID 1002，然后本处理返回到步骤610。此时，在“John”之后，输入字符串中存在更多字符。然而，不存在到节点“JOHN”的带有等于“n”(其为输入字符串中的如在步骤612中确定的下一个字符)的节点路径的节点分支。相应地，匹配结束，匹配算法的结果指向索引ID 1002。
[0216]对于“属性条件XREF”表中的具有条件类型“相似-以...结束”的每个属性，执行查找匹配“相似-以...结束”条件处理。对于列的给定值，“节点”和“节点分支”表用于标识包含列的给定值的与“相似-以...结束”条件关联的所有“索引ID”。该值中的字符被颠倒，颠倒后的字符串用于遍历“相似-以...结束”树。一旦颠倒了列值的字符串，匹配算法完全与“相似-以...开始”匹配算法相同。
[0217]例如，考虑必须使用“相似-以...结束”树匹配的“姓名”列的“Johnny Smith”的输入值。第一个步骤是将输入值颠倒为“thimSynnhoJ”。然后，以与在查找匹配“相似-以...开始”条件部分描述的算法相同的方式，匹配此颠倒的字符串。
[0218]对于“属性条件XREF”表中的具有条件类型“相似-作为...的一部分”的每个属性，执行查找匹配“相似-作为...的一部分”条件处理。对于列的给定值，“节点”和“节点分支”表用于标识包含该列的给定值的与“相似-作为...的一部分”条件关联的所有“索引ID”。将如与在匹配“相似-以...开始”条件部分中所描述的完全相同的算法用于标识匹配“索引ID”，只是递归地调用该算法，对于整个字符串、头两个字符被删除后的整个字符串，每一个字符串都调用一次该算法，依次类推，直到使用此方法匹配了输入值id的最后一个字符。
[0219]例如，考虑必须使用“相似-作为...的一部分”树匹配的“姓名”列的“Johnny Smith”的输入值。为做到这一点，对于下面的字符串中的每一个，递归地调用在查找匹配“相似-以...开始”条件部分所描述的算法：′Johnny Smith′；′ohnny Smith′；′hnny Smith′；′nny Smith′；′ny Smith′；′y Smith′；′Smith′；′Smith′；′mith′；′ith′；′th′；以及′h′。
[0220]对于“属性条件XREF”表中的具有条件类型“不相似”的每个属性，执行查找匹配“不相似”条件处理。类似于“相似”条件，“不相似”条件也被分成三种类型：(1)＂不相似-以...开始＂；(2)＂不相似-以...结束＂以及(3)＂不相似-作为...的一部分＂。
[0221]给定文本列的值，使用“节点”和“节点分支”表，检索对应于“不相似”条件的“索引Id”。原则上，所有“不相似条件”都被视为“真”，只是使用在查找匹配“相似”条件部分所描述的算法匹配给定值的那些除外。对于给定列，检索对应于“不相似”条件和该属性ID的所有“索引Id”。随后，从此集合中，删除通过如前面的部分所描述的那样使用列值遍历三个“不相似”树而确定的所有“索引ID”。
[0222]对于“属性条件XREF”表中的具有条件类型“包含”的每个属性，执行查找匹配“包含”条件处理。给定列的值，对列的文本执行列关键字提取。一旦提取了关键字，通过对“包含关键字索引”表执行简单查询(其中，属性ID等于给定列的属性ID，值等于每一个提取的关键字)，将返回对列的给定值有效的所有“索引ID”。
[0223]例如，在上面的的示例记录(11)中，“Skills”列(属性ID＝3)的值为“.net，SQL SERVER，MSACCESS”。通过对此值执行关键字提取，将返回关键字“.net”、“SQL SERVER”和“MSACCESS”。
[0224]为确定对此列和“包含”条件有效的“索引ID”，使用“包含关键字索引”表。在添加示例查询Q1之后，“包含关键字索引”表看起来如下所示。
 
索引ID 属性ID 值
101 3 ＂.net＂
[0225]下面的SQL语句因此将检索出索引ID101：
Select Index ID
From Contains Keyword Index
Where Attribute ID＝3 and
Value in(＂.net＂，＂SQL SERVER＂，＂MSACCESS＂)
[0226]对于“属性条件XREF”表中的具有条件类型“不包含”的每个属性，执行查找匹配“不包含”条件处理。对于给定列，与包含给定列的属性ID的所有“不包含条件”相对应的所有“索引ID”都被视为“真”，使用在匹配“包含”条件算法中所讨论的步骤所匹配的索引ID除外。
[0227]给定一个列，从“不包含关键字索引”表中检索出具有等于该列的“属性ID”的“属性ID”的所有“索引ID”，作为SET 1。
[0228]对于给定列，对该列的文本执行关键字提取。一旦提取了关键字，通过对“不包含关键字索引”表执行简单查询(其中，属性ID等于给定列的属性ID，值等于每一个提取的关键字)，将得到所有匹配“索引ID”，作为SET 2。
[0229]SET1-SET2会得到对于列的给定值的所有有效的“不包含”“索引ID”。
[0230]在此时，在处理添加的新记录时，确定关联到所有“真”条件的所有“索引ID”。现在，将这些“索引ID”用于查找对应于新添加的记录的所有匹配查询。
[0231]返回到图1，在所有匹配条件在步骤2.2中被查找到之后，本处理流程在步骤2.3中继续查找匹配的查询。相应地，一旦识别了与对于给定记录为“真”的条件相对应的所有“索引ID”，就通过对“索引条件”表执行下面的SQL，来确定匹配的查询：
Select Query Number
Where Index ID in(Matched Index IDs)
Group by Query Number，Part Number
Having count(＊)＝Condition Count
[0232]例如，考虑上面的示例表3的下列状态下的索引条件表：
 
索引ID 查询编号 部分号 条件编号 条件计数
101 1 1 1 3
3 1 1 2 3
4 1 1 2 3
1 1 1 3 3
101 1 2 1 3
3 1 2 2 3
4 1 2 2 3
2 1 2 4 3
[0233]同样，考虑下面的示例记录：
 
RowNutnID-1 NameID-2 SkillsID-3 LocationID-4     EducationLevelID-5      CareerLevelID-6   WorkstatusID-7   JobTypeID-8 CompanyCategoriesID-9      
11 JohnnySmith  .net，SQLSERVER，MSACCESS  NY M XP FT E IT
[0234]如上文所讨论的，在搜索带有此记录中的各种属性的条件索引之后，返回“索引ID”1、2、3和101。
[0235]相应地，通过执行下列SQL，将返回查询编号1：
Select distinct Query Nu mber
Where Index ID in(1，2，3，101)
Group by Query Number，Part Number
Having count(＊)＝Condition Count
[0236]根据应用的需求，然后查询编号1可以自动地在数据库上执行，并且/或者可以通知与查询关联的用户，已经更改或添加了查询结果信息，并且/或者向该用户呈现新的或变更后的记录。
[0237]在一个可能的示例中，本发明是作为关系数据库管理系统(RDBMS)加载项产品来实现的。相应地，“保存查询”处理流程和/或“将记录与保存的查询匹配”处理流程可以作为在数据库服务器上执行的软件程序或处理器来实现。例如，这样的软件可以使用Java技术来构建，以便可以独立于平台，并可以与任何商业化RDBMS产品(如ORACLE、MS SQLServer、DB2等等)一起使用。在通过阅读这里的描述之后，所属领域的技术人员将理解如何实现这样的各种及其他实现方式。
[0238]图7显示了本发明在在线分类门户700(例如，求职、不动产、汽车搜索门户等等)中的一个可能的用途，传统上，门户700为客户提供如下能力：通过网络(如因特网和万维网)，使用常规的搜索引擎、查询工具和界面以及所属领域的技术人员所知道的关联的Web页面，对记录的数据库702进行在线搜索。尽管这些搜索会产生通常是某时间的快照的结果，但是，基础数据库702持续地利用新记录进行更新(新的工作、住宅、汽车、求职者等等的列表)。
[0239]根据本发明的某些方面，不要求用户定期重新执行搜索以检索匹配它们的准则的新的列表，本发明允许在线门户700创建定期(每晚、每周等等)自动地执行的搜索代理，以确定自从第一次创建搜索查询以来的新的匹配。作为另一个示例，在线门户700可以在每次更新或添加数据库702中的记录时，或在更新或添加了某一阈值数量的记录之后，执行搜索代理。显而易见的，除保存客户的查询之外，在线门户700还可以具有用于创建和维护用户帐户的功能，和/或用于标识客户并将他们与保存的查询关联起来的其他机制。由门户700维护的客户信息也可以包括电子邮件地址，及其他配置文件或信息，这些信息允许用户指定首选项和/或用来通知更改的搜索结果的手段。所属领域的技术人员将理解，可以有可以用来实现这样的机制和/或功能的各种已知的方法和替代方案。
[0240]如图7所示，带有本发明的功能的门户700允许在每次向数据库702中添加新记录(工作、住宅、汽车)时，匹配和检索所有保存的搜索/查询704。如上文所描述的，在客户保存他们的搜索准则之后，查询被保存在列表704中，并创建条件索引和交叉引用表，并存储在索引706中。
[0241]此后，当新的/变更的记录存储在数据库702中时(例如，使用如上文所提及的自动化搜索代理，或手动通过管理员界面，或通过其他用户，通过由门户700所提供的Web界面，通过因特网或WWW)，门户700使用上文所描述的匹配算法，来判断列表704中哪些保存的查询会受到影响。然后，门户可以通知与保存的查询关联的用户，并且/或者通过多个已知的信号发送方法或机制中的任何一个(例如，通过电子邮件或者RSS反馈发送消息，通过Ajax等动态地更新屏面)将所述新的结果推向关联的用户。
[0242]通过向保存的搜索提供新记录的立即的和递增的匹配，本发明增强了诸如700之类的搜索门户的用户体验，还在对时间敏感的领域(如，工作、不动产、汽车等等)向客户提供竞争优势。
[0243]虽然这里是参考优选实施例具体描述本发明的，但是，对那些本领域的普通技术人员显而易见的，在不偏离本发明的精神和范围的情况下，可以对形式和细节进行各种变化和修改。所附的权利要求包含这样的变化和修改。

Claims (20)

1.一种方法，包括：
接收用于标识多组数据之中的一组数据的查询；
根据多个条件索引对所述查询进行分析；
存储通过所述分析步骤更新的所述条件索引，并将所述查询与所述存储的条件索引关联；以及
将新的或更改后的数据组与所述存储的条件索引进行比较，并且如果存在匹配，则标识关联的查询。
2.根据权利要求1所述的方法，进一步包括：
如果有匹配，则返回所述标识的关联的查询的更新的搜索结果。
3.根据权利要求1所述的方法，其中，所述数据组是数据流的一部分，每一组都具有一个或更多个字段，并且所述查询是要应用于某些字段的布尔规则。
4.根据权利要求1所述的方法，其中，所述分析步骤包括：
标识所述查询中的各个条件；
利用所述标识的各个条件，生成布尔形式的表达式；以及
基于所述生成的表达式，标识所述多个条件索引。
5.根据权利要求4所述的方法，其中，所述数据组是数据库记录，并且其中，所述多个数据组包括表，并且其中，所述查询是SQL查询，并且通过所述SQL查询中的where子句来标识所述各个条件。
6.根据权利要求5所述的方法，其中，所述各个条件包括数值等于值、文本等于值、日期等于值、数值范围、文本范围、日期范围以及文本串比较中的一个或更多个。
7.根据权利要求4所述的方法，其中，所述表包括与每一个记录关联的多个属性，该方法还包括：
维护主表，所述主表将某些属性映射到所述条件中的多种条件；以及
基于所述标识的各个条件，更新所述主表。
8.根据权利要求7所述的方法，其中，所述比较步骤包括：
判断所述新的或变更后的记录是否包含所述更新的主表中的所述某些属性中的任何一个；以及
基于对所述新的或变更后的记录包含所述某些属性中的任何一个的判断，限制是否有匹配的判断。
9.根据权利要求4所述的方法，进一步包括：
维护索引条件交叉引用表，所述索引条件交叉引用表将所述查询与所述标识的多个条件中的每一个关联；以及
基于所述分析步骤的结果，更新所述索引条件交叉引用表。
10.根据权利要求9所述的方法，其中，所述比较步骤包括：
利用所述标识多个条件索引的步骤，查询更新的索引条件交叉引用表。
11.根据权利要求1所述的方法，其中，所述数据组包括文本属性，并且其中，如果所述查询包括文本串，则所述分析步骤包括：
基于所述文本串，更新节点表；以及
基于所述文本串内的支路，更新节点分支表。
12.根据权利要求11所述的方法，进一步包括：
维护多个所述节点表，以及分别与多个文本条件中的每一个文本条件关联的所述节点分支表，
其中，所述文本条件至少包括以...开始、包含，以及作为...的一部分。
13.一种方法，包括：
提供能够通过在线门户进行访问的查询工具和记录的数据库；
通过所述在线门户，从用户那里接收查询；
使用所述查询工具对所述数据库进行搜索，并将搜索结果返回到所述用户；
对所述查询进行分析以提取其条件，并保存所述查询以及其关联的提取的条件；
接收新的或变更的记录以存储在所述数据库中；
将所述接收到的记录与所述提取的条件进行比较，以判断所述的关联的查询的所述搜索结果是否被所述接收到的记录更改；以及
如果判断更改了所述搜索结果，则通知所述用户。
14.根据权利要求13所述的方法，其中，所述通知步骤包括给用户提供所述更改的搜索结果。
15.根据权利要求13所述的方法，其中，所述通知步骤包括以下步骤中的一个或更多个：向所述用户发送电子邮件、通过在线反馈给用户发出信号以及更新搜索结果屏面。
16.一种用于搜索表中的记录的设备，包括：
查询处理器，用于根据多个条件索引来分析接收到的查询，存储通过所述分析更新的所述条件索引，并将所述查询与所述存储的条件索引关联；以及
查询匹配处理器，用于将新的或变更的记录与存储的条件索引进行比较，并且如果有匹配则标识所述关联的查询。
17.根据权利要求16所述的设备，其中，所述表包括关系数据库，并且其中查询是SQL查询，并且所述各个条件由所述查询处理器通过所述SQL查询中的where子句进行标识。
18.根据权利要求17所述的设备，其中，所述各个条件包括数值等于值、文本等于值、日期等于值、数值范围，文本范围、日期范围，以及文本串比较中的一个或更多个。
19.根据权利要求16所述的设备，进一步包括：
在线门户，用于通过网络从用户那里接收所述查询，并通过网络向用户返回搜索结果。
20.根据权利要求19所述的设备，其中，所述在线门户进一步用于，如果所述查询匹配处理器判断有所述新的或变更的记录的匹配，则通知用户。
CN2007800383045A 2006-08-23 2007-08-23 高效的搜索结果更新机制 Expired - Fee Related CN101535990B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US82337006P 2006-08-23 2006-08-23
US60/823,370 2006-08-23
PCT/US2007/076651 WO2008024917A2 (en) 2006-08-23 2007-08-23 Efficient search result update mechanism

Publications (2)

Publication Number Publication Date
CN101535990A true CN101535990A (zh) 2009-09-16
CN101535990B CN101535990B (zh) 2013-05-29

Family

ID=39107685

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2007800383045A Expired - Fee Related CN101535990B (zh) 2006-08-23 2007-08-23 高效的搜索结果更新机制

Country Status (4)

Country Link
US (1) US7979453B2 (zh)
EP (1) EP2062168A4 (zh)
CN (1) CN101535990B (zh)
WO (1) WO2008024917A2 (zh)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011132076A1 (zh) * 2010-04-23 2011-10-27 广州市西美信息科技有限公司 数据库查询和控制方法
CN104102685A (zh) * 2013-04-11 2014-10-15 波音公司 识别关联存储器内的上下文关联结果
CN105574031A (zh) * 2014-10-16 2016-05-11 国际商业机器公司 用于数据库索引的方法和系统
CN107257973A (zh) * 2015-02-18 2017-10-17 起元技术有限责任公司 查询网络上的数据源
CN108268537A (zh) * 2016-12-30 2018-07-10 北京国双科技有限公司 数据过滤方法及装置
CN109117435A (zh) * 2017-06-22 2019-01-01 索意互动（北京）信息技术有限公司 一种客户端、服务器、检索方法及其系统
CN109791542A (zh) * 2016-09-28 2019-05-21 迈克菲有限责任公司 查询优化的分布式分类账系统
CN111414359A (zh) * 2019-01-07 2020-07-14 奥普塔姆软件股份有限公司 稀疏数据索引表
US11093223B2 (en) 2019-07-18 2021-08-17 Ab Initio Technology Llc Automatically converting a program written in a procedural programming language into a dataflow graph and related systems and methods
CN113380356A (zh) * 2021-05-10 2021-09-10 广州零端科技有限公司 分支链式溯源的医疗检查数据记录方法、查询方法及装置
US11593369B2 (en) 2010-01-15 2023-02-28 Ab Initio Technology Llc Managing data queries

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090125799A1 (en) * 2007-11-14 2009-05-14 Kirby Nathaniel B User interface image partitioning
US9563657B2 (en) * 2008-01-08 2017-02-07 International Business Machines Corporation Generating data queries using a graphical selection tree
US20090259934A1 (en) * 2008-04-11 2009-10-15 Go Hazel Llc System and method for rendering dynamic web pages with automatic ajax capabilities
JP5473250B2 (ja) * 2008-05-29 2014-04-16 キヤノン株式会社 検索装置の制御方法、検索装置
US9424339B2 (en) * 2008-08-15 2016-08-23 Athena A. Smyros Systems and methods utilizing a search engine
US8965881B2 (en) * 2008-08-15 2015-02-24 Athena A. Smyros Systems and methods for searching an index
US8209338B2 (en) * 2009-01-08 2012-06-26 David Robert Wallace Interest-group discovery system
US20110078166A1 (en) * 2009-09-29 2011-03-31 Nokia Corporation Method and apparatus for creating and utilizing information representation of queries
CN102053993B (zh) 2009-11-10 2014-04-09 阿里巴巴集团控股有限公司 一种文本过滤方法及文本过滤系统
US8417707B2 (en) * 2009-12-24 2013-04-09 Pagebites, Inc. System and method for serving search results of textual data in response to a query as it is typed
US10748119B2 (en) 2010-02-01 2020-08-18 Microsoft Technology Licensing, Llc Social network search
US8468119B2 (en) * 2010-07-14 2013-06-18 Business Objects Software Ltd. Matching data from disparate sources
CN101957857B (zh) * 2010-09-30 2013-03-20 华为终端有限公司 一种信息主动推送方法及服务器
CN102117323A (zh) * 2011-02-21 2011-07-06 深圳埃斯欧纳信息咨询有限公司 一种推荐求职简历的处理方法和系统
US10540403B1 (en) * 2011-09-22 2020-01-21 Veritas Technologies Llc Method and system to automatically resume linear review of search results
US9075498B1 (en) 2011-12-22 2015-07-07 Symantec Corporation User interface for finding similar documents
US20140081982A1 (en) * 2012-09-18 2014-03-20 Jiun Hung Method and Computer for Indexing and Searching Structures
CN103853773A (zh) * 2012-12-04 2014-06-11 厦门亿联网络技术股份有限公司 一种Ｍysql数据库下树形数据结构的检索方法
US8583631B1 (en) * 2013-01-31 2013-11-12 Splunk Inc. Metadata tracking for a pipelined search language (data modeling for fields)
US9218379B2 (en) 2013-03-15 2015-12-22 Informatica Llc Method, apparatus, and computer-readable medium for efficiently performing operations on distinct data values
US20160086159A1 (en) * 2014-09-24 2016-03-24 Stmicroelectronics, Inc. Application identifier (aid) prioritization of security module applications
WO2016067471A1 (ja) * 2014-10-31 2016-05-06 株式会社東芝 通信制御装置、通信制御方法およびプログラム
US11093564B1 (en) 2016-09-26 2021-08-17 Splunk Inc. Identifying configuration parameters for a query using a metadata catalog
US11157498B1 (en) * 2016-09-26 2021-10-26 Splunk Inc. Query generation using a dataset association record of a metadata catalog
CN108108374B (zh) * 2016-11-25 2021-11-16 百度在线网络技术（北京）有限公司 一种数据仓库的存储方法及装置
US10685047B1 (en) 2016-12-08 2020-06-16 Townsend Street Labs, Inc. Request processing system
US10817483B1 (en) * 2017-05-31 2020-10-27 Townsend Street Labs, Inc. System for determining and modifying deprecated data entries
US11416563B1 (en) 2017-10-20 2022-08-16 Amazon Technologies, Inc. Query language for selecting and addressing resources
US10795886B1 (en) 2018-03-30 2020-10-06 Townsend Street Labs, Inc. Dynamic query routing system
US11392578B1 (en) 2018-04-30 2022-07-19 Splunk Inc. Automatically generating metadata for a metadata catalog based on detected changes to the metadata catalog
US11573955B1 (en) 2018-04-30 2023-02-07 Splunk Inc. Data-determinant query terms
US11238049B1 (en) 2018-04-30 2022-02-01 Splunk Inc. Revising catalog metadata based on parsing queries
US11430077B2 (en) 2019-02-13 2022-08-30 The Toronto-Dominion Bank System and method for searching and monitoring assets available for acquisition
US11715051B1 (en) 2019-04-30 2023-08-01 Splunk Inc. Service provider instance recommendations using machine-learned classifications and reconciliation
CN111079036B (zh) * 2019-11-25 2023-11-07 罗靖涛 一种字段式搜索方法
US20210357458A1 (en) * 2020-05-18 2021-11-18 Microsoft Technology Licensing, Llc Generating near real-time notifications using an asynchronous matching system
CN114896271B (zh) * 2022-06-09 2023-06-23 城云科技（中国）有限公司 一种高效维护节点全路径的方法、装置及应用

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5157783A (en) * 1988-02-26 1992-10-20 Wang Laboratories, Inc. Data base system which maintains project query list, desktop list and status of multiple ongoing research projects
WO1992016903A1 (en) * 1991-03-12 1992-10-01 Wang Laboratories, Inc. Database management system graphical query front end
JPH04299459A (ja) * 1991-03-27 1992-10-22 Nec Corp データベースアクセスシステム
US5727196A (en) * 1992-05-21 1998-03-10 Borland International, Inc. Optimized query interface for database management systems
US5548770A (en) * 1993-02-25 1996-08-20 Data Parallel Systems, Inc. Method and apparatus for improving retrieval of data from a database
US5560007A (en) * 1993-06-30 1996-09-24 Borland International, Inc. B-tree key-range bit map index optimization of database queries
US5745882A (en) * 1995-01-09 1998-04-28 Us West Marketing Resources Group, Inc. Electronic classified advertising interface method and instructions with continuous search notification
US5893125A (en) * 1995-01-27 1999-04-06 Borland International, Inc. Non-modal database system with methods for incremental maintenance
US5664173A (en) * 1995-11-27 1997-09-02 Microsoft Corporation Method and apparatus for generating database queries from a meta-query pattern
US6105025A (en) * 1996-03-08 2000-08-15 Oracle Corporation Method for using an index as a workspace for deferred enforcement of uniqueness constraints
US5870747A (en) * 1996-07-09 1999-02-09 Informix Software, Inc. Generalized key indexes
US5864863A (en) * 1996-08-09 1999-01-26 Digital Equipment Corporation Method for parsing, indexing and searching world-wide-web pages
CN1253643A (zh) * 1997-03-12 2000-05-17 明德特里尔股份有限公司 动态建立、修改、删除和维持数据库信息的计算机化方法、
US6266663B1 (en) * 1997-07-10 2001-07-24 International Business Machines Corporation User-defined search using index exploitation
US6061678A (en) * 1997-10-31 2000-05-09 Oracle Corporation Approach for managing access to large objects in database systems using large object indexes
US5999943A (en) * 1997-10-31 1999-12-07 Oracle Corporation Lob locators
US6366904B1 (en) * 1997-11-28 2002-04-02 International Business Machines Corporation Machine-implementable method and apparatus for iteratively extending the results obtained from an initial query in a database
US6421662B1 (en) * 1999-06-04 2002-07-16 Oracle Corporation Generating and implementing indexes based on criteria set forth in queries
US6353821B1 (en) * 1999-12-23 2002-03-05 Bull Hn Information Systems Inc. Method and data processing system for detecting patterns in SQL to allow optimized use of multi-column indexes
US6643636B1 (en) * 2001-06-05 2003-11-04 Ncr Corporation Optimizing a query using a non-covering join index
WO2003060771A1 (en) * 2002-01-14 2003-07-24 Jerzy Lewak Identifier vocabulary data access method and system
US7127467B2 (en) * 2002-05-10 2006-10-24 Oracle International Corporation Managing expressions in a database system
US6999958B2 (en) * 2002-06-07 2006-02-14 International Business Machines Corporation Runtime query optimization for dynamically selecting from multiple plans in a query based upon runtime-evaluated performance criterion
US6915291B2 (en) * 2002-06-07 2005-07-05 International Business Machines Corporation Object-oriented query execution data structure
FR2841072A1 (fr) * 2002-06-14 2003-12-19 France Telecom Systeme de consultation et/ou mise a jour de serveurs dns et/ou d'annuaires ldap
US7155459B2 (en) * 2002-06-28 2006-12-26 Miccrosoft Corporation Time-bound database tuning
EP1567928A4 (en) * 2002-09-03 2008-04-30 X1 Technologies Llc DEVICES AND METHOD FOR FINDING DATA
US11392588B2 (en) * 2003-09-04 2022-07-19 Oracle International Corporation Active queries filter extraction
US7849063B2 (en) * 2003-10-17 2010-12-07 Yahoo! Inc. Systems and methods for indexing content for fast and scalable retrieval
US7406477B2 (en) * 2004-03-12 2008-07-29 Sybase, Inc. Database system with methodology for automated determination and selection of optimal indexes
US8046354B2 (en) * 2004-09-30 2011-10-25 International Business Machines Corporation Method and apparatus for re-evaluating execution strategy for a database query
US20060074875A1 (en) * 2004-09-30 2006-04-06 International Business Machines Corporation Method and apparatus for predicting relative selectivity of database query conditions using respective cardinalities associated with different subsets of database records
US7499917B2 (en) * 2005-01-28 2009-03-03 International Business Machines Corporation Processing cross-table non-Boolean term conditions in database queries
US7457797B2 (en) * 2005-03-30 2008-11-25 International Business Machines Corporation Method and apparatus for associating logical conditions with the re-use of a database query execution strategy
US8051045B2 (en) * 2005-08-31 2011-11-01 Sap Ag Archive indexing engine
US20070219980A1 (en) * 2006-03-20 2007-09-20 Polycarpe Songfack Thinking search engines
US7644066B2 (en) * 2006-03-31 2010-01-05 Oracle International Corporation Techniques of efficient XML meta-data query using XML table index
US20070250517A1 (en) * 2006-04-20 2007-10-25 Bestgen Robert J Method and Apparatus for Autonomically Maintaining Latent Auxiliary Database Structures for Use in Executing Database Queries

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11593369B2 (en) 2010-01-15 2023-02-28 Ab Initio Technology Llc Managing data queries
WO2011132076A1 (zh) * 2010-04-23 2011-10-27 广州市西美信息科技有限公司 数据库查询和控制方法
CN104102685A (zh) * 2013-04-11 2014-10-15 波音公司 识别关联存储器内的上下文关联结果
US10467235B2 (en) 2013-04-11 2019-11-05 The Boeing Company Identifying contextual results within associative memories
CN104102685B (zh) * 2013-04-11 2019-05-21 波音公司 识别关联存储器内的上下文关联结果
US10146819B2 (en) 2014-10-16 2018-12-04 International Business Machines Corporation Database indexes
CN105574031B (zh) * 2014-10-16 2019-01-04 国际商业机器公司 用于数据库索引的方法和系统
CN105574031A (zh) * 2014-10-16 2016-05-11 国际商业机器公司 用于数据库索引的方法和系统
CN107257973B (zh) * 2015-02-18 2022-03-04 起元技术有限责任公司 查询网络上的数据源
CN107257973A (zh) * 2015-02-18 2017-10-17 起元技术有限责任公司 查询网络上的数据源
US11308161B2 (en) 2015-02-18 2022-04-19 Ab Initio Technology Llc Querying a data source on a network
CN109791542A (zh) * 2016-09-28 2019-05-21 迈克菲有限责任公司 查询优化的分布式分类账系统
CN109791542B (zh) * 2016-09-28 2023-10-27 迈克菲有限责任公司 查询优化的分布式分类账系统
CN108268537A (zh) * 2016-12-30 2018-07-10 北京国双科技有限公司 数据过滤方法及装置
CN109117435B (zh) * 2017-06-22 2021-07-27 索意互动（北京）信息技术有限公司 一种客户端、服务器、检索方法及其系统
CN109117435A (zh) * 2017-06-22 2019-01-01 索意互动（北京）信息技术有限公司 一种客户端、服务器、检索方法及其系统
CN111414359A (zh) * 2019-01-07 2020-07-14 奥普塔姆软件股份有限公司 稀疏数据索引表
US11093223B2 (en) 2019-07-18 2021-08-17 Ab Initio Technology Llc Automatically converting a program written in a procedural programming language into a dataflow graph and related systems and methods
CN113380356A (zh) * 2021-05-10 2021-09-10 广州零端科技有限公司 分支链式溯源的医疗检查数据记录方法、查询方法及装置
CN113380356B (zh) * 2021-05-10 2024-04-16 广州零端科技有限公司 分支链式溯源的医疗检查数据记录方法、查询方法及装置

Also Published As

Publication number Publication date
EP2062168A4 (en) 2010-03-31
WO2008024917A3 (en) 2008-11-06
EP2062168A2 (en) 2009-05-27
US7979453B2 (en) 2011-07-12
CN101535990B (zh) 2013-05-29
WO2008024917A2 (en) 2008-02-28
US20080071769A1 (en) 2008-03-20

Similar Documents

Publication Publication Date Title
CN101535990B (zh) 高效的搜索结果更新机制
CA2602564C (en) Model-driven event detection, implication, and reporting system
US8010567B2 (en) Federated ontology index to enterprise knowledge
US6757670B1 (en) Method and system for query processing
CN101421725A (zh) 用于关联企业实体的方法与系统
US10095766B2 (en) Automated refinement and validation of data warehouse star schemas
US9075881B2 (en) System and method for identifying the owner of a document on the world-wide web
US20020038306A1 (en) Method of managing slowly changing dimensions
US20070162414A1 (en) System and method for using external references to validate a data object&#39;s classification / consolidation
US20060026114A1 (en) Data gathering and distribution system
US20070055691A1 (en) Method and system for managing exemplar terms database for business-oriented metadata content
US20070005658A1 (en) System, service, and method for automatically discovering universal data objects
KR101505858B1 (ko) 대용량 데이터를 용이하게 분석하기 위하여 테이블 관계 및 참조의 템플릿을 검색하여 제공하는 템플릿 기반 온라인 분석보고서 작성 지원 시스템
US20100138447A1 (en) System and method for improving resolution of channel data
Pérez-Martínez et al. Contextualizing data warehouses with documents
US20060010108A1 (en) Method and system for collecting and posting local advertising to a site accessible via a computer network
KR20050061597A (ko) 버저닝된 데이터베이스에 대한 리포트를 생성하기 위한시스템 및 방법
Salim et al. Towards data quality into the data warehouse development
US10360239B2 (en) Automated definition of data warehouse star schemas
US8793268B1 (en) Smart key access and utilization to optimize data warehouse performance
US9111284B2 (en) Maintaining a history of query results
Fan Extending dependencies with conditions for data cleaning
Bergamaschi et al. Dimension matching in peer-to-peer data warehousing
McClean et al. Using background knowledge with attribute-oriented data mining
CN116662460A (zh) 一种基于元属性标签多维分类的设备信息描述与存储方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20130529

Termination date: 20140823

EXPY Termination of patent right or utility model