CN1768325A - 公开内容的抽象数据库抽象中的规则应用管理 - Google Patents

公开内容的抽象数据库抽象中的规则应用管理 Download PDF

Info

Publication number
CN1768325A
CN1768325A CNA2004800088089A CN200480008808A CN1768325A CN 1768325 A CN1768325 A CN 1768325A CN A2004800088089 A CNA2004800088089 A CN A2004800088089A CN 200480008808 A CN200480008808 A CN 200480008808A CN 1768325 A CN1768325 A CN 1768325A
Authority
CN
China
Prior art keywords
data
query
condition
abstract
database
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.)
Pending
Application number
CNA2004800088089A
Other languages
English (en)
Inventor
理查德·D·德廷杰
理查德·J·史蒂文斯
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.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Publication of CN1768325A publication Critical patent/CN1768325A/zh
Pending legal-status Critical Current

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/2457—Query processing with adaptation to user needs
    • 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/242—Query formulation
    • G06F16/2425—Iterative querying; Query formulation based on the results of a preceding query
    • 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/2452—Query translation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99932—Access augmentation or optimizing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching
    • Y10S707/99934—Query formulation, input preparation, or translation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation

Landscapes

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

Abstract

一种方法、***和制造产品，用于处理对数据库(156)执行的查询，并且更具体地说，用于在对数据库(156)执行查询时，将数据库(156)中的可查询数据限制为该数据库中的所有可用数据的子集。一个实施例包括：提供所有可用数据的逻辑表示(148)，该逻辑表示定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段(208)；接收包括所述多个逻辑字段的至少一个逻辑字段的抽象查询(202)；检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件(722)；将所述至少一个条件(722)与抽象查询(202)相关联；以及在执行该抽象查询(202)时，根据所述至少一个条件(722)，将可查询数据(732)限制为所有可用数据(730)的子集。

Description

公开内容的抽象数据库抽象中的规则应用管理
技术领域
本发明一般地涉及数据库中的数据处理，特别涉及处理对数据库执行的查询。
背景技术
数据库是计算机化的信息存储和检索***。关系数据库管理***是使用用于存储和检索数据的关系技术的计算机数据库管理***(DBMS)。最普遍的数据库类型是关系数据库——一种将数据定义为使得可以用多种不同方式重新组织和访问它的表式数据库。
无论具体架构是什么，在DBMS中，请求实体(例如应用程序或操作***)通过发出数据库访问请求来要求访问指定数据库。例如，这种请求可包括简单目录查找请求或用来在数据库中读取、改变和添加指定记录的事务或事务的组合。使用诸如结构化查询语言(SQL)的高级查询语言来做出这些请求。作为说明，SQL用来进行交互式查询，所述交互式查询用于从诸如国际商业机器公司(IBM)的DB2、Microsoft的SQL Server、以及来自Oracle、Sybase和Computer Associates的数据库产品的数据库中获取信息，并更新该数据库。术语“查询”是指一组用于从所存储的数据库中检索数据的命令。查询采用命令语言的形式，该命令语言使程序员和程序选择、***、更新、找出数据的位置等。
通常，数据挖掘和数据库查询应用程序所面对的一个问题是它们与给定数据库大纲(schema)(例如，关系数据库大纲)的密切关系。这种关系使得当对相应的底层数据库大纲进行了改变时难以支持应用程序。此外，禁止将应用程序移植到替换的底层数据表示。在当今的环境中，前述缺点主要是因为应用程序对SQL所具有的依赖，其中，SQL假定使用关系模型来表示正被查询的信息。此外，由于在SQL查询表示中引用(reference)了特定的数据库表、列和关系，因此给定的SQL查询依赖于特定关系大纲。
一个难点在于：底层关系数据模型的改变需要改变在其上构造对应的应用程序的SQL基础。因此，应用程序设计者要么必须放弃改变底层数据模型以避免应用程序维护，要么必须改变应用程序以反映底层关系模型的改变。另一难点在于：将应用程序扩展为可在多个关系数据模型下工作需要单独的应用程序版本来反映由每个唯一的关系大纲驱动的唯一SQL需求。因为SQL是为与关系***一起使用而设计的，因此另一难点在于将应用程序演变为可在替换数据表示下工作。将应用程序扩展为支持诸如XML的替换数据表示需要重新写入应用程序的数据管理层，以使用非SQL数据访问方法。
用来解决上述问题的一种典型方法是软件封装。软件封装包括使用软件接口或组件来将访问方法封装为特定的底层数据表示。在作为Java 2企业版(J2EE，Java 2 Enterprise Edition)技术套件的组成部分的企业JavaBean(EJB，Enterprise JavaBean)规范中有一个示例。在EJB的情况中，实体组件(bean)用来封装给定的一组数据，披露(expose)可用来访问此信息的一组应用程序接口(API)。这是一种高度专业化的方法，其中，无论何时要访问一组新数据或者当希望新的数据访问模式时，该方法都需要(以新实体EJB的形式)写入软件。该EJB模型还需要代码更新、应用程序构造和部署周期来对底层物理数据模型的重新组织作出反应或支持替换数据表示。由于涉及到更为高级的Java编程技术，因此EJB编程还需要专业技巧。因而，对于访问演变中的物理数据模型的通用查询应用程序，EJB方法和其它类似的方法相当僵化，并且维护较为昂贵。
现有技术的另一缺点在于可以将信息呈现给用户的方式。很多软件解决方案支持使用用户定义的查询，其中，给用户提供了建立满足用户的特定数据选择需求的查询的工具。在基于SQL的***中，当构造查询时，给用户提供底层数据库表和列的列表以从中进行选择。用户必须根据由数据库管理员使用的命令习惯来决定访问哪些表和列。这一方法没有提供对呈现给用户的一组信息进行子集构造(subset)的有效方式，并因此使查询的构造复杂化为甚至向用户显示了不重要的内容。
如果采用对上述困难的解决方案，另一个必须解决的问题是查询结果的分析。一般而言，分析是意味着对一个或多个先前的步骤的结果进行研究的重复过程。在数据库的环境中，所述一个或多个先前的步骤通常是从底层数据库返回了结果的查询。在很多传统***中，分别对数据库执行每个查询，使得将每个执行的查询的不同查询结果呈现给用户。如果用户有兴趣通过发出附加查询来分析先前执行的查询的查询结果，则该用户通常需要手动地组合该附加查询和先前执行的查询，并执行该组合查询以获得新的查询结果。因此，可能希望将数据库中的可访问数据限制为该数据的子集，以便将研究和分析收缩或集中在某些字段的数据的子集上，使得可以对数据库发出后续查询而无需手动组合查询。例如，出于研究治疗和药物疗法的效力的目的，可能希望将医疗数据库环境中的病人库(warehouse)限制为心脏病人，而不需要用户通过将对应的条件输入对医疗数据库发出的每个查询来手动地将搜索限制为心脏病人。
因此，需要用于处理数据库环境中的、由请求实体随后对数据库发出的相关查询的改进且更加灵活的技术。
发明内容
本发明一般地旨在一种方法、***和制造产品，其用于处理对数据库执行的查询，并且更具体地说，用于在对数据库执行查询时，将数据库中的可查询数据限制为该数据库中的所有可用数据的子集。
用于在对数据库执行查询时将数据库中的可查询数据限制为该数据库中的所有可用数据的子集的一个实施例包括：提供所有可用数据的逻辑表示，该逻辑表示定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；接收包括所述多个逻辑字段的至少一个逻辑字段的抽象查询；检索定义可查询数据的多个物理实体所共有的至少一个性质(property)的至少一个条件；将所述至少一个条件与该抽象查询相关联，以及在执行该抽象查询时，根据所述至少一个条件，将可查询数据限制为所有可用数据的子集。
另一实施例包括：接收对所有可用数据的查询；检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；将所述至少一个条件与该查询相关联；以及当执行该查询时，根据所述至少一个条件，将可查询数据限制为所有可用数据的子集。
另一实施例包括：提供所有可用数据的逻辑表示，该逻辑表示定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；使用所述至少一个条件将可查询数据限制为所有可用数据的子集；接收包括所述多个逻辑字段的至少一个逻辑字段的抽象查询；以及对可查询数据执行该抽象查询。
另一实施例包括：检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；使用所述至少一个条件将可查询数据限制为所有可用数据的子集；接收对所有可用数据的查询；以及对可查询数据执行该查询。
另一实施例提供了一种用于在对具有多个表的数据库执行查询时将数据库中的可查询数据限制为数据库中的所有可用数据的子集的方法。该方法包括：接收对所有可用数据的查询；确定该查询是否结合(join)了数据库中的两个或更多表；并且，如果查询结合了两个或更多表，则检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件，所述至少一个条件与至少一个先前的查询相关；将所述至少一个条件与该查询相关联；以及，在执行该查询时，根据所述至少一个条件，将可查询数据限制为所有可用数据的子集。
另一实施例提供了一种用于将数据库中的可查询数据限制为数据库中的所有可用数据的子集的方法。该方法包括：提供所有可用数据的第一逻辑表示，该第一逻辑表示定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；以及将至少一部分逻辑字段修改为抽象地描述可查询数据的所述多个物理实体，以便使用所述至少一个条件从第一逻辑表示提供可查询数据的第二逻辑表示。
另一实施例提供了一种包含程序的计算机可读介质，当被处理器执行时，该程序进行用于在对数据库执行查询时将数据库中的可查询数据限制为该数据库中的所有可用数据的子集的操作。该操作包括：响应于接收到包括在所有可用数据的逻辑表示中定义的多个逻辑字段的至少一个逻辑字段的抽象查询，检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；将所述至少一个条件与抽象查询相关联；以及在执行该抽象查询时，根据所述至少一个条件，将可查询数据限制为所有可用数据的子集，其中，所述逻辑表示定义抽象地描述所有可用数据的相关物理实体的所述多个逻辑字段。
另一实施例提供了一种包含程序的计算机可读介质，当被处理器执行时，该程序进行用于将数据库中的可查询数据限制为该数据库中的所有可用数据的子集以对数据库执行查询的操作。该操作包括：响应于接收到包括在所有可用数据的逻辑表示中定义的多个逻辑字段的至少一个逻辑字段的抽象查询，检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；使用所述至少一个条件，将可查询数据限制为所有可用数据的子集；接收包括所述多个逻辑字段的至少一个逻辑字段的抽象查询；以及对可查询数据执行该抽象查询，其中，所述逻辑表示定义抽象地描述所有可用数据的相关物理实体的所述多个逻辑字段。
另一实施例提供了一种包含程序的计算机可读介质，当被处理器执行时，该程序进行用于将数据库中的可查询数据限制为该数据库中的所有可用数据的子集的操作。该操作包括：响应于用户输入，产生所有可用数据的第一逻辑表示，该第一逻辑表示定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；以及将至少一部分逻辑字段修改为抽象地描述可查询数据的所述多个物理实体，以便使用所述至少一个条件从第一逻辑表示产生可查询数据的第二逻辑表示。
另一实施例提供了一种计算机，包括：数据库，包含可用数据；数据抽象模型，定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；查询构造应用程序，用于根据数据抽象模型构造抽象查询；运行时间组件，被配置为将抽象查询变换为具有与数据一致的形式的具体查询；以及规则应用管理器，被配置为将定义所有可用数据的相关物理实体的至少一部分所共有的至少一个性质的至少一个条件与给定抽象查询相关联，以便在对数据库执行对应于变换后的给定抽象查询的具体查询时，使用所述至少一个条件将数据库中的可查询数据限制为所有可用数据的子集。
另一实施例提供了一种计算机，包括：数据库，包含可用数据；数据抽象模型，定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；查询构造应用程序，用于根据数据抽象模型构造抽象查询；运行时间组件，被配置为将抽象查询变换为具有与数据一致的形式的具体查询；以及规则应用管理器，用于在对数据库执行对应于变换之后的抽象查询的具体查询时，使用定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件，将数据库中的可查询数据限制为所有可用数据的子集。
另一实施例提供了一种计算机，包括：数据库，包含可用数据；第一数据抽象模型，定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；以及规则应用组件，用于从第一数据抽象模型产生第二数据抽象模型，使用定义可查询数据的多个物理实体的至少一个性质的至少一个条件，将数据库中的可查询数据限制为所有可用数据的子集。
附图说明
为了能够详细了解实现本发明的上述特征、优点和目的的方式，可以通过参考在附图中示出的本发明的实施例来获得在上面简要概括的本发明的更加具体的描述。
然而，应当注意，附图仅仅图示了本发明的典型实施例，因此不应被认为是限制本发明的范围，这是因为本发明可以容纳其它同样有效的实施例。
图1是根据本发明使用的计算机***的一个实施例；
图2A-B是本发明一个实施例的软件组件的关系视图；
图3A图示多个数据储存库抽象组件共存于单个应用程序空间的一个实施例；
图3B图示单个数据储存库抽象组件的多个实例共存于单个应用程序空间的一个实施例；
图4图示具有多个数据存储库抽象组件的环境；
图5是图示运行时间组件的操作的流程图；
图6是图示运行时间组件的操作的流程图；
图7是本发明一个实施例的软件组件的关系视图；
图8是图示处理所接收的抽象查询的流程图；
图9是图示根据本发明实施例的修改抽象查询的方法的流程图；
图10是图示根据本发明实施例的产生临时表的方法的流程图；以及
图11是图示根据本发明实施例的修改数据储存库抽象组件的方法的流程图。
具体实施方式
引言
本发明一般地旨在一种***、方法和制造产品，其用于处理对数据库执行的查询，并且更具体地说，用于在对数据库执行查询时，将数据库中的可查询数据限制为该数据库中的所有可用数据的子集。在一个实施例中，数据储存库抽象层提供与物理地表示数据的特定方式无关的底层数据库的逻辑视图。数据储存库抽象层表示定义多个逻辑字段的数据抽象模型，其中所述逻辑字段抽象地定义数据。还提供查询抽象层，并且其基于数据储存库抽象层。查询抽象层包括查询构造应用程序，用于根据数据抽象模型构造抽象查询。该查询构造应用程序作为数据查询构造器来实现，其中，例如，作为单个应用程序来提供该数据查询构造器，所述单个应用程序访问数据储存库抽象，仿佛它是物理数据库一样。表示数据查询抽象组件的运行时间组件进行将抽象查询转换为具有与数据一致的形式的具体查询。可以对特定物理数据表示使用具体查询。数据查询抽象组件为数据查询构造器的逻辑数据访问请求服务，而不向数据查询构造器提供物理数据表示存在的知识，也不提供关于物理查询——即从抽象查询得到的具体查询——的知识。规则应用管理组件实现一种规则应用机制，该机制用于在对数据库执行查询时，将数据库中的可查询数据限制为该数据库中的所有可用数据的子集。
在一个实施例中，数据储存库抽象层包括在单个应用程序空间内共存(以及，在一些实施例中，协作)的多个数据储存库抽象组件/实例。提供数据储存库抽象的多个数据抽象组件/实例使得能向不同的用户披露不同的数据集合。
本发明的一个实施例作为用于与计算机***(例如在图1中示出并在下面描述的计算机***)一起使用的程序产品来实现。该程序产品的程序定义了实施例(包括在此描述的方法)的功能，并且可被包含在各种信号承载介质上。说明性的信号承载介质包括但不限于：(i)永久存储在不可写入存储介质(例如，诸如可由CD-ROM驱动器读取的CD-ROM盘的计算机内的只读存储设备)上的信息；(ii)存储在可写入存储介质(例如，盘驱动器中的软盘或硬盘驱动器)上的可改变信息；或(iii)通过通信介质，例如通过计算机或包括无线通信的电话网络，而传送给计算机的信息。后面的实施例具体包括从因特网和其它网络下载的信息。当这种信号承载介质承载指引本发明的功能的计算机可读指令时，其代表本发明的实施例。
通常，被执行以实现本发明实施例的例行程序可以是操作***或特定应用程序、组件、程序、模块、对象或指令序列的一部分。本发明的软件通常包括大量指令，所述指令将被本地计算机转换为机器可读的格式，并因此被转换为可执行指令。此外，程序包括局部存在于该程序中或者在存储器中或存储设备上找到的变量和数据结构。此外，在本发明的特定实施例中，可以基于为之实现在下文中描述的各种程序的应用程序来识别所述各种程序。然而，应当认识到，以下任何特定术语都仅仅是为了方便而使用，因而本发明不应被限制为仅用于由这样的术语指出和/或暗含的任何特定应用程序。
环境的物理视图
图1示出了可实现本发明实施例的联网***100的方框图。通常，联网***100包括客户端(例如，用户的)计算机102(示出了3台这种客户端计算机102)、和至少一台服务器104(示出了一台这种服务器104)。客户端计算机102和服务器计算机104通过网络126连接。通常，网络126可以是局域网(LAN)和/或广域网(WAN)。在特定实施例中，网络126是因特网。
客户端计算机102包括通过总线120连接到存储器112、存储设备114、输入设备116、输出设备119以及网络接口设备118的中央处理单元(CPU)110。输入设备116可以是向客户端计算机102提供输入的任何设备。例如，可以使用键盘、小键盘、光笔、触摸屏、轨迹球、或语音识别单元、音频/视频播放器等。输出设备119可以是向用户提供输出的任何设备，例如，任何传统显示屏。尽管输出设备119被示出为与输入设备116分离，但是可以将输出设备119和输入设备116组合在一起。例如，可以使用具有集成触摸屏的显示屏、具有集成键盘的显示器、或组合了文本语音转换器的语音识别单元。
网络接口设备118可以是被配置为允许客户端计算机102和服务器计算机104之间通过网络126进行网络通信的任何登录/退出设备。例如，网络接口设备118可以是网络适配器或其它网络接口卡(NIC)。
存储设备114优选是直接存取存储器设备(DASD)。尽管它被示出为单个单元，但它可以是固定和/或可拆卸存储设备如固定的盘驱动器、软盘驱动器、磁带驱动器、可拆卸存储卡、或光学存储器的组合。存储器112和存储设备114可以是跨越多个主和辅存储设备的一个虚拟地址空间的一部分。
存储器112优选是足够大以保存本发明的必要程序设计和数据结构的随机存取存储器。尽管存储器112被示出为单个实体，但应当理解，存储器112实际上可包括多个模块，并且存储器112可以以从高速寄存器和高速缓冲存储器到速度较低但较大的DRAM芯片的多个等级存在。
作为说明，存储器112包含操作***124。可有利地使用的说明性操作***包括Linux和Microsoft的Windows。更一般地，可以使用支持在此公开的功能的任何操作***。
存储器112还被示出为包含浏览器程序122，当在CPU 110上执行浏览器程序122时，浏览器程序122提供对于在各种服务器104之间遨游、并将网络地址定位于一个或多个服务器104上的支持。在一个实施例中，浏览器程序122包括基于网络的图形用户界面(GUI)，其允许用户显示超文本标记语言(HTML)信息。然而，更一般地，浏览器程序122可以是能够呈现从服务器计算机104传送的信息的任何基于GUI的程序。
可以按照类似于客户端计算机102的方式来物理地配置服务器计算机104。因此，服务器计算机104被一般地示出为包括通过总线136而互相耦接的CPU 130、存储器132和存储设备134。存储器132可以是足够大以保存位于服务器计算机104上的必要程序设计和数据结构的随机存取存储器。
服务器计算机104通常受被示出为驻留在存储器132中的操作***138的控制。操作***138的示例包括IBM OS/400、UNIX、Microsoft Windows等。更一般地，可以使用能够支持在此描述的功能的任何操作***。
存储器132还包括一个或多个应用程序140、抽象查询接口146和规则应用管理器160。应用程序140、抽象查询接口146和规则应用管理器160是具有多个指令的软件产品，所述指令在各种时刻驻留在计算机***100内的各种存储器和存储设备中。当被服务器104中的一个或多个处理器130读取并执行时，应用程序140、抽象查询接口146和规则应用管理器160使计算机***100进行执行实施本发明各种方面的步骤或元素(element)所必需的步骤。应用程序140(以及更一般地，包括操作***138以及处于最高等级上的用户的任何请求实体)发出对数据库(例如，统称为数据库156的数据库1561...156N)的查询。作为说明，数据库156被示出为存储设备134中的数据库管理***(DBMS)的一部分。数据库156代表与特定物理表示无关的任何数据集合。作为说明，可以根据(可通过SQL查询访问的)关系大纲或根据(可通过XML查询访问的)XML大纲来组织数据库156。然而，本发明不限于特定大纲，并且考虑了向当前未知的大纲的扩展。如在这里使用的那样，术语“大纲”一般地指数据的特定排列。
在一个实施例中，根据每个应用程序140包括的应用程序查询规范142来定义应用程序140发出的查询。应用程序140发出的查询可被预先定义(即，被硬编码为应用程序140的一部分)、或者可以响应于输入(例如，用户输入)而产生。在任一情况中，使用抽象查询接口146定义的逻辑字段来组成查询(在此称为“抽象查询”)。具体地说，在抽象查询中使用的逻辑字段由抽象查询接口146的数据储存库抽象组件148定义。抽象查询由运行时间组件150执行，其中，例如，运行时间组件150首先通过将抽象查询转换为具体查询来将抽象查询变换为与DBMS 154中包含的数据的物理表示一致的形式。规则应用管理器160实现规则应用机制，其中所述规则应用机制用于将可查询数据限制为DBMS 154中包含的所有可用数据的子集。在一个实施例中，规则应用管理器160通过重新定义对数据库执行的查询来限制可查询数据，以便对可查询数据执行重新定义的查询。可替换地，当执行所接收的查询时，规则应用管理器160使用从存储器中检索到的条件来限制可查询数据。可替换地，规则应用管理器160通过修改数据储存库抽象组件来限制可查询数据。参考图2A-B和图7来进一步描述应用程序查询规范142、抽象查询接口146和规则应用管理器160。
在一个实施例中，用户通过图形用户界面(GUI)指定查询的元素。GUI的内容由应用程序140产生。在特定实施例中，GUI内容是可利用浏览器程序122而在客户端计算机***102上呈现的超文本标记语言(HTML)内容。因此，存储器132包括适配成为来自客户端计算机102的请求服务的超文本传输协议(HTTP)服务器进程152(例如，网络服务器)。例如，进程152可响应请求以访问说明性地驻留在服务器104上的数据库156。到来的对来自数据库156的数据的客户端请求调用应用程序140。当被处理器130执行时，应用程序140使服务器计算机104执行实施本发明各种方面的步骤或元素，包括访问数据库156。在一个实施例中，应用程序140包括多个配置为构造随后由浏览器程序122呈现的GUI元素的小服务程序(servlet)。
图1只是联网的客户端计算机102和服务器计算机104的一种硬件/软件配置。本发明的实施例可应用于任何相似的硬件配置，而不管计算机***是复杂的多用户计算装置、单用户工作站、还是不具有其自己的非易失性存储器的网络设备。此外，应当理解，尽管参考了包括HTML的特定标记语言，但本发明不限于特定的语言、标准或版本。因此，本领域技术人员将认识到，本发明可适应其它标记语言以及非标记语言，并且，本发明还可适应特定标记语言未来的改变、以及目前未知的其它语言。同样，图1示出的HTTP服务器进程152只是说明性的，并且已考虑到适配为支持任何已知和未知协议的其它实施例。
环境的逻辑/运行时间视图
图2A-B示出了本发明的组件的说明性关系视图200。请求实体(例如，图1的应用程序140之一)发出如该请求实体的各个应用程序查询规范142定义的查询202。在这里，因为根据抽象(即，逻辑)字段而不是通过直接引用DBMS 154中的底层物理数据实体来组成所产生的查询202，所以该查询通常被称为“抽象查询”。因此，可以定义与所使用的特定底层数据表示无关的抽象查询。在一个实施例中，应用程序查询规范142可既包括用于数据选择的标准(选择标准204)又包括基于选择标准204要返回的字段的明确规范(返回数据规范206)。
由应用程序查询规范142指定并用来组成抽象查询202的逻辑字段由数据储存库抽象组件148定义。通常，数据储存库抽象组件148将信息作为可在应用程序140发出的查询(例如，抽象查询202)中使用的一组逻辑字段来进行披露，以指定数据选择标准，并指定从查询操作返回的结果数据的形式。该逻辑字段被与DBMS 154中使用的底层数据表示无关地定义，从而允许形成松散地结合到底层数据表示的查询。
通常，数据储存库抽象组件148将信息作为可在应用程序140发出的查询(例如，抽象查询202)中使用的一组逻辑字段来进行披露，以指定数据选择标准，并指定从查询操作返回的结果数据的形式。该逻辑字段被与数据库156中使用的底层数据表示无关地定义，从而允许形成松散地结合到底层数据表示的查询。
在一个实施例中，数据储存库抽象组件148包括统称为字段规范208的多个字段规范2081、2082、2083、2084和2085(作为示例，示出了5个字段规范)。具体地说，为可用于组成抽象查询的每个逻辑字段提供字段规范。每个字段规范包含逻辑字段名2101、2102、2103、2104、2105(统称为字段名210)和相关的访问方法2121、2122、2123、2124、2125(统称为访问方法212)。这些访问方法将逻辑字段名关联(即，映射)到数据库(例如，数据库156)中的特定物理数据表示2141、2142...214N。作为说明，示出了两种数据表示，即XML数据表示2141和关系数据表示2142。然而，物理数据表示214N表明考虑了任何其它已知或未知的数据表示。在一个实施例中，单个数据储存库抽象组件148包含用于两种或更多物理数据表示214的字段规范(和相关的访问方法)。在替换实施例中，为每个单独的物理数据表示214提供不同的单个数据储存库抽象组件148。
根据要支持的不同类型逻辑字段的数目，构思任何数目的访问方法。在一个实施例中，提供了针对简单字段、过滤字段和组合字段的访问方法。字段规范2081、2082和2085分别例示了简单字段访问方法2121、2122和2125。简单字段被直接映射到底层物理数据表示中的特定实体(例如，映射到给定数据库表和列的字段)。作为说明，图2B示出的简单字段访问方法2121将逻辑字段名2101(“FirstName(名)”)映射到名称为“contact(联系人)”的表中名称为“f_name”的列。字段规范2083例示了过滤字段访问方法2123。过滤字段标识相关的物理实体，并提供用来定义该物理数据表示中的特定条目子集的过滤器。在图2B中提供了这样的示例，其中，过滤字段访问方法2123将逻辑字段名2103(“AnyTownLastName”)映射到名称为“contact”的表中名称为“l_name”的列中的物理实体，并定义对于城市“Anytown”中的个人的过滤器。过滤字段的另一示例是纽约邮政编码字段，该字段映射到邮政编码的物理表示，并将数据限制为仅仅为纽约州定义的那些邮政编码。字段规范2084例示了组合字段访问方法2124。组合访问方法使用作为访问方法定义的一部分而提供的表达式来从一个或多个物理字段计算逻辑字段。以这一方式，可以计算出底层数据表示中不存在的信息。在图2B图示的示例中，组合字段访问方法2124将逻辑字段名2104“AgeInDecades”映射到“AgeInYears/10”。另一示例是通过将销售价格字段乘以营业税率而组成的营业税字段。
已经考虑到底层数据的任何给定数据类型(例如，日期、十进制数等)的格式可能变化。因此，在一个实施例中，字段规范208包括反映底层数据格式的类型属性(attribute)。然而，在另一实施例中，字段规范208的数据格式与相关底层物理数据不同，在此情况下，需要将底层物理数据转换为逻辑字段的格式。
作为示例，图2示出的数据储存库抽象组件148的字段规范208代表被映射到关系数据表示2142中表示的数据的逻辑字段。然而，数据储存库抽象组件148的其它实例将逻辑字段映射到其它物理数据表示，例如XML。
在下面的表I中示出了对应于图2B示出的抽象查询202的说明性抽象查询。作为说明，使用XML来定义该说明性抽象查询。然而，可以有利地使用任何其它语言。
                  表I-抽象查询示例
001    <？xml version＝“1.0”？>
002    <！--Query string representation：(FirstName＝“Mary”AND LastName＝
003    “McGoon”)OR State＝“NC”-->
004    <QueryAbstraction>
005     <Selection>
006      <Condition internalID＝“4”>
007       <Condition field＝“FirstName”operator＝“EQ”Value＝“Mary”
008    internalID＝“1”/>
009       <Condition field＝“LastName”operator＝“EQ”value＝“McGoon”
010    internalID＝“3”reloperator＝“AND”></Condition>
011      </Condition>
012      <Condition field＝“State”operator＝“EQ”Value＝“NC”internalID＝“2”
013    relOperator＝“OR”></Condition>
014    </Selection>
015    <Results>
016         <Field name＝“FirstName”/>
017         <Field name＝“LastName”/>
018         <Field name＝“Street”/>
019     </Results>
020    </QueryAbstraction>
作为说明，表I示出的抽象查询包括含有选择标准的选择规范(第005-014行)和结果规范(第015-019行)。在一个实施例中，选择标准由(逻辑字段的)字段名、比较运算符(＝、＞、＜等)以及(所述字段与之进行比较的)值表达式组成。在一个实施例中，结果规范是将作为查询执行结果返回的抽象字段的列表。抽象查询中的结果规范可由字段名和分类标准组成。
下面的表II示出了说明性数据储存库抽象。作为说明，使用XML来定义该说明性数据储存库抽象。然而，可以有利地使用任何其它语言。
                表II-数据储存库抽象示例
001    <？xml version＝“1.0”？>
002    <DataRepository>
003     <Category name＝“Demographic”>
004      <Field queryable＝“Yes”name＝“FirstName”displayable＝“Yes”>
005       <AccessMethod>
006         <Simple co1umnName＝“f_name”
tableName＝“contact”></Simple>
007       </AccessMethod>
008       <Type baseType＝“char”></Type>
009    </Field>
010    <Field queryable＝“Yes”name＝“LastName”displayable＝“Yes”>
011       <AccessMethod>
012         <Simple columnName＝“l_name”
tableName＝“contact”></Simple>
013       </AccessMethod>
014       <Type baseType＝“char”></Type>
015    </Field>
016    <Field queryable＝“Yes”name＝“State”displayable＝“Yes”>
017       <AccessMethod>
018         <Simple columnName＝“State”
tableName＝“contact”></Simple>
019       </AccessMethod>
020       <Type baseType＝“char”></Type>
021     </Field>
022    <Category>
023   </DataRepository>
如上所述，一个实施例提供了共存于单个应用程序空间内的多个数据储存库抽象组件。图3A示出了说明这种环境的一个实施例。图3A示出的环境一般地包括应用层310(由应用程序140定义)、数据抽象层320和物理数据层330。该环境示出了使用例如图1的应用程序140、通过应用层320(例如通过发出图2的抽象查询202)来访问物理数据层330的两个用户340、350。因此，应用层320可包括适配为使用户能够构造抽象查询的数据查询构造器组件。
用户340、350通过公共的应用层320访问同一物理数据层330。然而，被披露给各个用户340、350的数据并不相同。而是，根据数据抽象层320的定义，向每个用户披露物理数据层330的所选部分。更具体地说，数据抽象层320说明性地包括两个数据储存库抽象组件，即DRA1 342和DRA2 352，其定义将通过应用层310而分别向用户340、350披露的数据。数据抽象层320可包括数据查询抽象组件，其为数据查询构造器组件提供对物理数据层330中的物理数据的逻辑数据访问服务。
在本示例中，第一数据储存库抽象342(DRA1)披露第一数据库344(注册数据库)的全部和第二数据库354(薪金名册(payroll)数据库)的表1，而第二数据储存库抽象352(DRA2)披露整个第二数据库354和第一数据库344的表2。应当注意，由各个数据储存库抽象组件披露的特定数据仅仅是说明性的。更一般地，可以披露数据库344、354的任何部分，以及物理数据层330的任何其它数据库。作为说明，图3A的环境示出了两个用户(340、350)。然而，更一般地，可以有任何数目的用户访问物理数据层330的数据。
现在参考图3B，图示了单个数据储存库抽象组件(例如，数据储存库抽象组件148)的多个实例共存于单个应用程序空间内的实施例。根据图3B，用户362(用户A)、364(用户B)、366(用户C)、368(用户D)、...、370(用户N)的组360访问(如箭头346所示)单个数据储存库抽象342，而与只有一个还是有多个数据储存库抽象存在无关。在本图示中，用户组360的所有用户都访问数据储存库抽象DRA1。
对于访问数据储存库抽象342(DRA1)的每个用户362、364、366、368、...、370，产生数据储存库抽象342的实例(如箭头347所示)，从而产生数据储存库抽象实例组348。相应地，分别为用户362、364、366、368、...、370产生实例372(DRA1-A)、374(DRA1-B)、376(DRA1-C)、378(DRA1-D)、...、380(DRA1-N)，如箭头382、384、386、388和390所示。为每个用户提供数据储存库抽象342的实例使得能使对应的实例适应用户的需要和特定需求，而不会全局地改变用于组360中的所有用户的数据储存库抽象342。
图4图示了多个数据储存库抽象组件互相引用的实施例。具体地说，图3A的第二数据储存库抽象组件DRA2 352被图示为相对于第三数据储存库抽象组件DRA3 420(子)和第四数据储存库抽象组件DRA4 430之父。在这一关系中，第三和/或第四数据储存库抽象组件DRA3 420、DRA4 430可以继承第二数据储存库抽象组件DRA2 352的一部分定义。更详细地说，通过继承，可以将第三和/或第四数据储存库抽象组件DRA3 420、DRA4 430中所不包括的、在第二数据储存库抽象组件DRA2 352中提供的一部分逻辑字段包括在内。可替换地，第三和/或第四数据储存库抽象组件DRA3 420、DRA4 430可以与第二数据储存库抽象组件DRA2 352的多个部分重叠，并且/或者包括附加定义，例如在第二数据储存库抽象组件DRA2 352中没有发现的逻辑字段。可替换地，可以通过在第三和第四数据储存库抽象组件DRA3 420、DRA4 430中包括的定义和/或逻辑字段的组合来构建第二数据储存库抽象组件DRA2352。
图5示出了例示图1的运行时间组件150的操作的一个实施例的说明性运行时间方法500。当运行时间组件150接收到抽象查询(例如图2示出的抽象查询202)的实例作为输入时，在步骤502进入方法500。在步骤504，运行时间组件150读取和分析抽象查询的实例，并定位单独的选择标准和所希望的结果字段。在步骤506，运行时间组件150进入用于处理在抽象查询中呈现的每个查询选择标准语句的循环(包括步骤506、508、510和512)，从而构造具体查询的数据选择部分。在一个实施例中，选择标准由(逻辑字段的)字段名、比较运算符(＝、＞、＜等)以及(所述字段与之进行比较的)值表达式组成。在步骤508中，运行时间组件150使用来自抽象查询的选择标准的字段名来在数据储存库抽象148中查找字段定义。如上所述，字段定义包括用来访问与该字段相关的物理数据的访问方法的定义。然后，运行时间组件150为正被处理的逻辑字段构造(步骤510)具体查询组分(contribution)。如同在这里定义的那样，具体查询组分是用来基于当前逻辑字段进行数据选择的具体查询的一部分。具体查询是采用如SQL和XML的语言表示的查询，并与给定物理数据储存库(例如，关系数据库或XML储存库)的数据一致。因此，使用具体查询来从由图1示出的DBMS 154表示的物理数据储存库中定位和检索数据。然后，将为当前字段产生的具体查询组分添加到具体查询语句中。然后，方法500返回步骤506，以便开始对抽象查询的下一字段的处理。因此，对抽象查询中的每个数据选择字段重复在步骤506进入的过程，从而向要进行的最终查询贡献出(contribute)附加内容。
如上所述，在一个实施例中，抽象查询定义在这里称为结果规范的、将作为查询执行结果返回的抽象字段的列表。抽象查询中的结果规范可由字段名和分类标准组成。
因此，方法500在步骤514处进入循环(由步骤514、516、518和520定义)，以便将结果字段定义添加到所产生的具体查询中。在步骤516，运行时间组件150在数据储存库抽象148中查找(来自抽象查询的结果规范的)结果字段名，然后从数据储存库抽象148中检索结果字段定义，以便识别将为当前逻辑结果字段返回的数据的物理位置。然后，运行时间组件150为该逻辑结果字段构造(如步骤518)(识别要返回的数据的物理位置的具体查询的)具体查询组分。然后，在步骤520，将具体查询组分添加到具体查询语句中。一旦处理了抽象查询中的每个结果规范，就在步骤522执行该查询。
参考图6来描述用于根据步骤510和518为逻辑字段构造具体查询组分的方法600的一个实施例。在步骤602，方法600查询与当前逻辑字段相关的访问方法是不是简单访问方法。如果是，则基于物理数据位置信息构造(步骤604)具体查询组分，随后，处理根据上述方法500继续进行。否则，处理继续进行到步骤606，以查询与当前逻辑字段相关的访问方法是否是过滤访问方法。如果是，则基于某个物理数据实体的物理数据位置信息来构造(步骤608)具体查询组分。在步骤610，利用用于对与该物理数据实体相关的数据进行子集构造的附加逻辑(过滤器选择)来扩展具体查询组分。然后，处理根据上述方法500继续进行。
如果该访问方法不是过滤访问方法，则处理从步骤606前进到步骤612，在步骤612，方法600查询访问方法是不是组合访问方法。如果该访问方法是组合访问方法，则在步骤614，定位并检索组合字段表达式中每个子字段引用(reference)的物理数据位置。在步骤616，用组合字段表达式的物理字段位置信息代替该组合字段表达式的逻辑字段引用，由此产生具体查询组分。然后，处理根据上述方法500继续进行。
如果该访问方法不是组合访问方法，则处理从步骤612前进到步骤618。步骤618代表作为本发明的实施例而构思的任何其它访问方法类型。然而，应当理解，构思了并不实现所有可用的访问方法的实施例。例如，在特定实施例中，仅使用简单访问方法。在另一实施例中，仅使用简单访问方法和过滤访问方法。
如上所述，如果逻辑字段指定了与底层物理数据不同的数据格式，则可能有必要进行数据转换。在一个实施例中，当根据方法600构造逻辑字段的具体查询组分时，对于每一个访问方法，分别进行初始转换。例如，可以作为步骤604、608和616的一部分或紧跟其后进行转换。在步骤522执行了查询之后，进行随后从物理数据的格式到逻辑字段的格式的转换。当然，如果逻辑字段定义的格式与底层物理数据相同，则没有必要进行转换。
现在参考图7，图示了规则应用管理器160和本发明的组件的关系视图。规则应用管理器160实现了规则应用机制，该机制用于在对所有可用数据730发出抽象查询701(例如，图2的抽象查询202)时，将可搜索数据732(即，可查询数据)限制为所有可用数据730的子集。为此，由规则应用管理器160处理抽象查询701。具体地说，规则应用管理器160进行相关性检查，即，使用相关性确定单元169来确定对数据库156执行抽象查询701是否需要将预先定义的规则167应用到抽象查询701、数据储存库抽象148和/或数据库156中的所有可用数据730的一个或多个物理实体。
在一个实施例中，规则应用管理器160使用条件提取单元162读取和分析所接收的抽象查询701(如箭头741所示)，以识别和提取由抽象查询701定义的一个或多个查询条件721。所提取的条件721被存储在条件存储单元164(例如，其可以是高速缓冲存储器或图1示出的存储设备114的一部分)中。使用数据储存库抽象148，将抽象查询701变换为与数据库中的所有可用数据730的底层物理表示一致的查询(如虚箭头762所示)。在该变换之后，可以对所有可用数据730执行抽象查询701(如虚箭头763所示)。
如果接收到另一抽象查询，作为说明，接收到图2的抽象查询202，则规则应用管理器160读取和分析抽象查询202，以便从抽象查询202识别和提取一个或多个查询条件，如上所述。在一个实施例中，在抽象查询701之后接收到抽象查询202。使用相关性确定单元169，规则应用管理器160确定可能已经从一个或多个先前执行的抽象查询中提取的、存储在条件存储单元164中的一个或多个查询条件(例如，抽象查询701的条件721)是否与抽象查询202相关。在一个实施例中，识别相关条件可包括：通过某个标识符如唯一的关键字(key)(例如，外部关键字)，确定与同一数据库表有关的条件和/或与关联到该数据库表的表有关的条件。如果规则应用管理器160确定至少一个所存储的条件与抽象查询202有关，则规则应用管理器160使用条件检索单元166来检索所述至少一个所存储的条件。然后，规则应用管理器160使用条件应用单元168访问抽象查询202(如箭头742所示)，以便将所述至少一个条件722与抽象查询202相关联，以产生(如箭头743所示)包括所述至少一个条件722的修改后的抽象查询703，如下面参考图9所解释的那样。使用数据储存库抽象148，将修改后的抽象查询703变换为与数据库中的所有可用数据730的底层物理表示一致的查询(如虚箭头766所示)。然后，可以对所有可用数据730执行修改后的抽象查询703(如虚箭头763所示)。
在另一实施例中，在检索到所述至少一个存储的条件之后，规则应用管理器160可以使用条件应用单元168来访问数据储存库抽象148，以便在所述至少一个条件的基础上修改数据储存库抽象148，从而产生(如箭头745所示)修改后的数据储存库抽象705，如下面参考图11所解释的那样。作为该修改的结果，修改后的数据储存库抽象705的逻辑字段指向数据库中可搜索数据732的子集的物理实体，而不是所有可用数据730的整个集合。然后，可以将抽象查询202变换为与可搜索数据732一致的查询(如虚箭头764所示)，以对可搜索数据732执行(如虚箭头765所示)。
在一个方面，由于可搜索数据732是所有可用数据730的子集，因此这一方法在运行时间获得了提高的性能。应当注意，在此实施例中，由于所有可用数据本身未以任何方式被改变或被限制，因此“可搜索数据”是指可有效使用的数据。确切地说，由于查询被限制为中间的修改后的数据储存库抽象705使其可用的那些，因此有效地减少了可查询数据。
在另一实施例中，可以修改所有可用数据730本身，如下面参考图10描述的那样。例如，在检索到所述至少一个存储的条件之后，规则应用管理器160可以从所述至少一个条件确定性质734，该性质描述要搜索的数据的特性。例如，假设在医学环境中具有多个记录的病人数据库表，其中，每个记录与医院中的病人的个人数据有关。在该表中，列“Age(年龄)”可以指向病人的年龄，并包括指明对应病人的年龄的每个病人的条目。因此，与年龄为“20”的病人相关的表中的每个记录将具有性质“年龄＝20”。使用该性质，可以将所有可用数据限制为可搜索数据732。
然后，规则应用管理器160可以访问所有可用数据730(如箭头746所示)，以便使用条件应用单元168在所述至少一个条件的基础上修改所有可用数据730。具体地说，将所有可用数据730限制为(如箭头747所示)可搜索数据732，其中，被图示为临时表733的可搜索数据732的至少多个物理实体具有所确定的性质734。此外，数据储存库抽象148可被修改为修改后的数据存储库抽象705，以便指向数据库中的可搜索数据732的物理实体，从而允许将抽象查询202变换为与可搜索数据732一致的查询。
应当注意，在图7中包括的组件之问的上述关系仅仅是说明性的，而不应被解释为将本发明限制为所描述的这些关系。取而代之的是，已考虑到不同组件之间的任何可能关系。例如，可以将修改后的抽象查询703变换为与使用修改后的数据储存库抽象705的底层物理表示一致的查询(如虚箭头768所示)。此外，可以与先前接收的抽象查询无关地提供条件，并将其存储在条件存储单元164中，以便将可搜索数据732限制为所有可用数据730的子集。可以使用条件检索单元166来从条件存储单元164中检索这些存储的条件，并将其与抽象查询202相关联并且/或者应用到数据储存库抽象148和/或所有可用数据730。另外，当处理来自所接收的抽象查询的条件时，可以自动地从对应的条件中提取性质734，并将存储为预先定义的规则167。此外，可以将预先定义的规则167与有关条件一起存储在条件存储单元168中。而且，可以将条件应用单元168和相关性确定单元169作为执行相关功能性的单个组件来实现。
图8是图示方法800的实施例的流程图，其中，方法800用于确定是否需要将预先定义的规则(例如，图7的预先定义的规则167)应用到所接收的抽象查询(例如，图7的抽象查询701或图2的202)、数据储存库抽象(例如，图1的数据储存库抽象组件148)和/或所有可用数据(例如，图7中的可用数据730)的一个或多个物理实体。在一个实施例中，由规则应用管理器(例如，图1的规则应用管理器160)执行方法800。仅仅作为示例，参照具有多个数据库表的关系数据库大纲来解释方法800，其中，所述多个数据库表是相关的，并因此可被结合在一起，并且其中，对这些表发出SQL查询。
方法800开始于步骤810。在步骤820，接收到抽象查询。在步骤830，规则应用管理器160确定所接收的抽象查询是否结合了数据库中的两个或更多表。具体地说，如果所接收的抽象查询结合了两个或更多表，则可以假设按照下面参考图10所解释的那样产生单个临时表(步骤890)是不合适的。例如，这一假设是考虑到底层关系数据库大纲而做出的，其中，出于组织的目的而故意分别实现了所述两个或更多表。这样，从所述两个或更多结合的表仅产生单个临时表将损害预期的关系组织。
如果确定所接收的抽象查询结合了数据库中的两个或更多表，则方法800在步骤850继续进行，在步骤850，规则应用管理器160识别在所接收的抽象查询中包含的所有查询条件。规则应用管理器160提取所识别的查询条件，并将其复制到存储设备(例如，图7的条件存储设备164)，以便永久存储所复制的条件。这样，所存储的条件表示预先定义的规则，其中，如果该预先定义的规则与对应的随后接收的抽象查询有关，则可以将该预先定义的规则应用于随后接收的抽象查询。在步骤860，规则应用管理器160修改所接收的抽象查询，并随后在步骤870如上面参考图5所解释的那样处理修改后的抽象查询。根据步骤860修改所接收的抽象查询的一个实施例在下面参考图9进行描述。
例如，设想接收到在下面的表III中示出的示例抽象查询伪简单起见，仅示出与以下解释有关的部分)：
                  表III-所接收的抽象查询
001    select<...>
002          from demographic，diagnosis
003          where age＞18 and result＝232.33
所接收的查询包含第002行中指明所查询的表“demographic(人口统计)”和“diagnosis(诊断)”的语句、以及第003行中指明应当从这些表中检索具有性质“年龄＞18”并且“结果＝232.33”的记录。因此，由于确定所接收的查询结合了两个表，因此在步骤850将条件“年龄＞18并且结果＝232.33”复制到永久存储设备中，并在步骤860修改该查询。在此示例中，注意，“232.33”是诊断代码，而不是表达式的特定值。
如果确定所接收的抽象查询没有结合数据库中的两个或更多表，即，对单个数据库表执行所接收的抽象查询，则方法800在步骤840继续进行，在步骤840，规则应用管理器160确定性能(performance)标准值。在一个实施例中，性能标准值是有可能包含在所期望的查询结果中的行或记录的估计数目。可替换地，性能标准值可以表示执行抽象查询直到获得查询结果为止所需的时间。性能标准值的确定可以在抽象查询的前一次执行的基础上、或使用传统数据库技术来进行。此外，规则应用管理器160在步骤880确定所确定的性能标准值是否满足预定标准。在一个实施例中，该预定标准可以是特定于应用程序的，或者可替换地，可以通过用户输入来定义。在一个实施例中，该预定标准是要返回的记录的最大数目。如果估计的记录数目(来自步骤840)超过了预定标准，则可以假设临时表的产生将消耗过多的***资源，并因此将不会产生临时表(即，处理前进到步骤850)。否则，临时表的产生是合适的，并且处理前进到步骤890。在另一实施例中，所述预定标准是最大允许执行时间。该阈值可以根据在其上执行查询分析的计算机***的性能参数来确定。即使临时表的产生将消耗相当大的存储空间，超过预定标准的估计性能标准值也表明：抽象查询的执行(再次执行)将是非常费时的。因此，临时表的产生是合适的，并且处理前进到步骤890。另一方面，取而代之的是，未超过预定标准的估计性能标准值可以朝着执行查询扩张(query augmentation)的方向减小，在这种情况下，处理前进到步骤850。记录的数目、查询执行时间或二者的组合是否被视为方法800的一部分是可以从一个应用程序改变为另一个的实现决策。
因此，如果确定所确定的性能标准值不在预定值范围内，则方法800如上所述在步骤850继续进行。如果确定所确定的性能标准值处于预定值范围内，则方法800在步骤890继续进行，在步骤890，产生至少一个临时表(例如，图7的临时表733)，并将其永久存储在存储设备中，使得所存储的临时表表示可应用于任何随后接收的抽象查询的预先定义的规则。用于在步骤890产生临时表的一个实施例在下面参考图10进行描述。
参考图9来解释用于根据步骤860修改所接收的抽象查询的方法900的一个实施例。在步骤910，规则应用管理器160分析所接收的抽象查询，以识别要查询的数据库表，即由所接收的抽象查询访问的表。在步骤920，规则应用管理器160从永久条件存储设备(例如，图7的条件存储设备164)中识别并检索相关的条件，并在步骤930将所检索的条件添加到所接收的抽象查询中。例如，识别相关条件可包括通过某个标识符例如唯一的关键字确定与要查询的同一数据库表有关的条件、和/或与关联到要查询的数据库表的表有关的条件。然后，处理如上面参考图8所述的那样继续进行。
在表III示出的所接收的查询的情况中，规则应用管理器160将表“demographic”和“diagnosis”识别(在步骤910)为要查询的表。现在，假设在所接收的查询之前执行了在下面的表IV中示出的示例抽象查询(同样，为简单起见，仅示出与以下解释有关的部分)：
                 表IV-先前的抽象查询
001    select<...>
002          from demographic，test
003          where(test.hemoglobin＞10 and test.hemoglobin＜14)and
004               (demographic.city＝‘Rochester’ordemographic.city＝‘LaCrosse’)
在先前的查询中，在下面的表V中示出的查询条件(称为条件C1和C2)已经被识别和复制到永久存储设备中：
                     表V-查询条件
C1：(test.hemoglobin＞10 and test.hemoglobin＜14)
C2：(demographic.city＝‘Rochester’or demographic.city＝‘LaCrosse’)
在步骤920，因为条件2定义了对于也被所接收的查询所查询的表“demographic”的规则，所以规则应用管理器将条件C2识别为与所接收的查询相关。因此，规则应用管理器将条件C2添加到所接收的查询中，从而产生下面的表VI中示出的修改后的抽象查询。
                   表VI-修改后的抽象查询
001    select<...>
002          from demographic，diagnosis
003          where age＞18 and result＝232.33 and
004                (demographic.city＝‘Rochester’ordemographic.city＝‘LaCrosse’)
参照图10来解释用于根据步骤890产生临时表(例如，图7的临时表733)的方法1000的一个实施例。在步骤1010，如上面参考图5所解释的那样，对一个或多个数据库表处理所接收的抽象查询以获得查询结果。在步骤1020，将所获得的查询结果作为临时表永久存储在存储设备(例如，图7的条件存储设备164)中，该临时表表示用于将随后对所述一个或多个数据库表执行的抽象查询限制到临时表中包含的数据的规则。在步骤1030，修改对应的数据储存库抽象组件(例如，图2的数据储存库抽象组件148)，如下面参考图11所解释的那样。然后，处理在步骤1040退出。
作为示例，接收到下面的表VII示出的查询名称为“demographic”的单个数据库表的示例抽象查询(为简单起见，仅示出了与以下解释有关的部分)：
                     表VII-单个表查询
001    select<patient_id>
002          from demographic
003          where age＞＝20 or result＞136
将对下面的表VIII中示出的数据库表“demographic”执行表VII的单个表查询。
            表VIII-数据库表“DEMOGRAPHIC”
  001   Patient_id   年龄   结果   血   城市
  002   1   17   136   9   Rochester
  003   2   17   136   9   LaCrosse
  004   3   17   136   10   Rochester
  005   4   18   136   10   LaCrosse
  006   5   18   128   9   Rochester
  007   6   18   128   9   LaCrosse
  008   7   18   128   10   Rochester
  009   8   19   152   10   LaCrosse
  010   9   19   136   9   Rochester
  011   10   19   136   9   LaCrosse
  012   11   19   136   10   Rochester
  013   12   19   136   10   LaCrosse
  014   13   19   152   9   Rochester
  015   14   19   152   9   LaCrosse
  016   15   20   136   10   Rochester
  017   16   20   152   10   LaCrosse
假设性能标准是估计的记录数目，并且阈值为“5”，因此值的预定范围是[0；5]。如果在所期望的查询结果中估计的记录数目是“5”，从而没有超过阈值，则对表VIII示出的数据库表执行表VII中示出的单个表查询，并将查询结果作为下面的表IX示出的临时表永久存储在存储设备中：
                          表IX-临时表
 001   Patient_id   年龄   结果   血   城市
 002   8   19   152   10   LaCrosse
 003   13   19   152   9   Rochester
 004   14   19   152   9   LaCrosse
 005   15   20   136   10   Rochester
 006   16   20   152   10   LaCrosse
如可以从表IX中看出的那样，只有表VIII的第009行和第014-017行中的记录满足表VII的单个表查询的第003行中的查询条件，并因此被存储在临时表(第002-006行)中。然后，可以对该临时表执行表VIII中示出的针对数据库表“demographic”的任何后续抽象查询，其中，所述临时表相应地实现了用于对于任何随后接收的抽象查询而将可搜索数据限制为所有可用数据的子集的规则。
参考图11来解释用于根据步骤1030修改数据储存库抽象组件(例如，图1的数据储存库抽象组件148)的方法1100的一个实施例。在步骤1110，规则应用管理器160访问数据储存库抽象组件，并读取和分析其中包括的逻辑字段。在步骤1120，规则应用管理器160检索引用数据库(例如，图1中的数据库156)中的数据的底层物理实体的逻辑字段的属性。在步骤1130，规则应用管理器160将该属性修改为指向临时表，以便将可使用数据储存库抽象组件访问的数据限制为可搜索数据。然后，处理以上述图10继续进行。
作为示例，在上面的表II中示出的说明性数据储存库抽象组件的情况中，规则应用管理器160在步骤1120从第006行(006<Simple columnName＝“f_name”tableName＝“contact”></Simple>)中检索访问方法属性，其中，第006行引用了具有列“f_name”的数据库表“contact”。假设临时表具有表名“TMPcontact”，则数据储存库抽象将被修改为指向“TMPcontact“表。具体地说，来自上面示出的表II的第006行的访问方法属性被修改为<SimplecolumnName＝“f_name”tableName＝“TMPcontact”></Simple>。
在各种实施例中，提供了优于现有技术的众多优点。根据本发明，提供了一种用于写入自由互动的查询的易于使用和灵活的***。更具体地说，当对底层数据库执行时，所有这样的查询都可以彼此互动。例如，如果对数据仓库执行查询并且获得了查询结果，则可以使这一查询结果可用于所有随后发出的查询。因此，将对该数据仓库执行任何随后发出的查询，就像先前的查询是该数据仓库的定义一样。此外，在查询中按照不同的顺序组合不同的条件可能产生不同的结果，它们是同样有用的。分别执行这种查询也将产生有效和可能有用的查询结果。
此外，在一个方面，通过定义应用程序查询规范和底层数据表示之间的松散结合来获得优点。代替利用特定的表、列和关系信息将应用程序编码的是，如使用SQL的情况中那样，应用程序以更为抽象的形式定义数据查询需求，其中，在运行时间，所述需求被随后绑定到特定的物理数据表示，本发明的这一松散的查询-数据结合使得即使修改了底层数据表示、或者即使请求实体将和与开发该请求实体时使用的物理数据表示相比为全新的物理数据表示一起使用，请求实体(例如，应用程序)也能够发挥作用。在修改或重建了给定物理数据表示的情况中，更新对应的数据储存库抽象，以便反映对底层物理数据模型进行的改变。相同的逻辑字段的集合可供查询使用，并且仅仅被绑定到物理数据模型中的不同实体或位置。作为结果，即使对应的物理数据模型已经遭受重大改变，被写入抽象查询接口的请求实体也继续不加改变地发挥作用。在请求实体将和与开发该请求实体时使用的物理数据表示相比为全新的物理数据表示一起使用的情况下，可以使用相同的技术(例如，关系数据库)但是遵循不同的命名和组织信息的策略(例如，不同的大纲)来实现新的物理数据模型。新大纲将包含可被映射到由应用程序使用简单、过滤和组合字段访问方法技术所需的逻辑字段集合的信息。可替换地，新物理表示可以使用用于表示类似信息的替换技术(例如，相对于关系数据库***，使用基于XML的数据储存库)。在任一情况中，被写入以使用抽象查询的现有请求实体可以容易地移植为使用新物理数据表示，并且提供将查询中引用的字段与新物理数据模型中的位置和物理表示相映射的替换数据储存库抽象。
在另一方面，促进了应用程序构造器和最终用户的使用便利。使用抽象层来表示底层数据储存库中的逻辑字段使应用程序开发者能够将精力集中于关键的应用程序数据需求，而不关心底层数据表示的细节。因此，在应用程序开发期间，获得了更高的生产率和减少的错误率。对于最终用户，数据储存库抽象提供了数据过滤机制，从而披露相关数据并隐藏开发给定查询的特定级别的最终用户所不需要的不重要的内容。
应当注意，这里对特定值、定义、程序设计语言和示例的任何引用仅仅是出于说明的目的。因此，本发明不受任何特定说明和示例限制。此外，尽管参考选择操作描述了本发明的多个方面，但是也考虑其它输入/输出操作，包括诸如更新、***、删除等众所周知的操作。当然，某些访问方法可以对可利用使用特定访问方法的字段来定义的抽象查询功能的类型做出限制。
尽管前述内容针对的是本发明的实施例，但是在不脱离本发明的基本范围的情况下，可以设计本发明的其它和另外的实施例，而本发明的范围由所附权利要求确定。

Claims (63)

1.一种用于在对数据库执行查询时将数据库中的可查询数据限制为该数据库中的所有可用数据的子集的方法，包括：
提供所有可用数据的逻辑表示，该逻辑表示定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；
接收包括所述多个逻辑字段的至少一个逻辑字段的抽象查询；
检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；
将所述至少一个条件与该抽象查询相关联；以及
在执行该抽象查询时，根据所述至少一个条件，将可查询数据限制为所有可用数据的子集。
2.如权利要求1所述的方法，其中，检索所述至少一个条件包括：
从至少一个先前执行的抽象查询中检索所述至少一个条件。
3.如权利要求1所述的方法，还包括，在接收到抽象查询之前：
接收包括所述多个逻辑字段的至少一个逻辑字段和所述至少一个条件的先前执行的抽象查询；
从该先前执行的抽象查询中提取所述至少一个条件；以及
存储所述至少一个条件。
4.如权利要求1所述的方法，还包括：
提供多个条件，每个条件定义所有可用数据的至少一个物理实体的至少一个性质。
5.如权利要求4所述的方法，其中，检索所述至少一个条件包括：
访问所述多个条件；以及
从所述多个条件中确定定义可查询数据的所述多个物理实体所共有的至少一个性质的所述至少一个条件。
6.如权利要求4所述的方法，其中，提供所述多个条件包括：
接收多个先前执行的抽象查询；以及
对于所述多个先前执行的抽象查询的每个先前执行的抽象查询：
确定该先前执行的抽象查询是否包括条件；以及
如果是，则从该先前执行的抽象查询中提取所述条件。
7.如权利要求1所述的方法，其中，所述执行包括：
将抽象查询变换为与可查询数据的物理数据表示一致的查询；以及
对可查询数据执行该与物理数据表示一致的查询。
8.一种用于在对数据库执行查询时将数据库中的可查询数据限制为该数据库中的所有可用数据的子集的方法，包括：
接收查询；
检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；
将所述至少一个条件与该查询相关联；以及
在执行该查询时，根据所述至少一个条件，将可查询数据限制为所有可用数据的子集。
9.一种用于在对具有多个表的数据库执行查询时将数据库中的可查询数据限制为该数据库中的所有可用数据的子集的方法，包括：
接收查询；
确定该查询是否结合了数据库中的两个或更多表；以及
如果该查询结合了两个或更多表，则
检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件，所述至少一个条件与至少一个先前的查询相关；
将所述至少一个条件与该查询相关联；以及
在执行该查询时，根据所述至少一个条件，将可查询数据限制为所有可用数据的子集。
10.如权利要求9所述的方法，还包括，如果查询没有结合两个或更多表，则：
检索所述至少一个条件；
使用所述至少一个条件将可查询数据限制为所有可用数据的子集；以及
对可查询数据执行该查询。
11.如权利要求9所述的方法，还包括，如果查询没有结合两个或更多表，则：
确定与查询执行有关的性能标准值；
确定所确定的性能标准值是否满足预定标准；以及
如果所确定的性能标准值满足预定标准，则
检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件，所述至少一个条件与至少一个先前的查询相关；
将所述至少一个条件与该查询相关联；以及
在执行该查询时，根据所述至少一个条件，将可查询数据限制为所有可用数据的子集。
12.如权利要求11所述的方法，还包括，如果所确定的性能标准值不满足预定条件，则
检索所述至少一个条件；
使用所述至少一个条件将可查询数据限制为所有可用数据的子集；以及
对可查询数据执行查询。
13.一种用于将数据库中的可查询数据限制为该数据库中的所有可用数据的子集以便对数据库执行查询的方法，包括：
提供所有可用数据的逻辑表示，该逻辑表示定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；
检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；
使用所述至少一个条件，将可查询数据限制为所有可用数据的子集；
接收包括所述多个逻辑字段的至少一个逻辑字段的抽象查询；以及
对可查询数据执行抽象查询。
14.如权利要求13所述的方法，其中，限制可查询数据包括：
使用所述至少一个条件从所有可用数据中确定可查询数据；以及
将可查询数据复制到将在执行抽象查询时访问的临时数据结构中。
15.如权利要求14所述的方法，其中，限制可查询数据还包括：
将至少一部分逻辑字段修改为抽象地描述临时数据结构的相关物理实体，以便将所有可用数据的逻辑表示变换为可查询数据的临时数据结构的逻辑表示。
16.如权利要求13所述的方法，其中，数据库包括具有所有可用数据的至少一个数据库表，并且其中，限制可查询数据包括：
使用所述至少一个条件从所有可用数据中确定可查询数据；以及
将可查询数据复制到将在执行抽象查询时访问的至少一个临时表中，每个临时表对应于应用了所述至少一个条件的数据库表。
17.如权利要求13所述的方法，其中，限制可查询数据包括：
使用所述至少一个条件从所有可用数据中确定可查询数据；以及
将至少一部分逻辑字段修改为抽象地描述临时数据结构的相关物理实体，以便将所有可用数据的逻辑表示变换为可查询数据的临时数据结构的逻辑表示。
18.如权利要求13所述的方法，其中，检索所述至少一个条件包括：
从至少一个先前执行的抽象查询中检索所述至少一个条件。
19.如权利要求13所述的方法，还包括，在检索所述至少一个条件之前：
接收包括所述多个逻辑字段的至少一个逻辑字段和所述至少一个条件的先前执行的抽象查询；
从该先前执行的抽象查询中提取所述至少一个条件；以及
存储所述至少一个条件。
20.如权利要求13所述的方法，还包括：
提供多个条件，每个条件定义所有可用数据的至少一个物理实体的至少一个性质。
21.如权利要求20所述的方法，其中，检索所述至少一个条件包括：
访问所述多个条件；以及
从所述多个条件中确定定义可查询数据的所述多个物理实体所共有的至少一个性质的所述至少一个条件。
22.如权利要求20所述的方法，其中，提供所述多个条件包括：
接收多个先前执行的抽象查询；以及
对于所述多个先前执行的抽象查询的每个先前执行的抽象查询：
确定该先前执行的抽象查询是否包括条件；以及
如果是，则从该先前执行的抽象查询中提取所述条件。
23.如权利要求13所述的方法，其中，所述执行包括：
将抽象查询变换为与可查询数据的物理数据表示一致的查询；以及
对可查询数据执行该与物理数据表示一致的查询。
24.一种用于在对数据库执行查询时将数据库中的可查询数据限制为该数据库中的所有可用数据的子集的方法，包括：
检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；
使用所述至少一个条件将可查询数据限制为所有可用数据的子集；
接收对所有可用数据的查询；以及
对可查询数据执行该查询。
25.一种用于将数据库中的可查询数据限制为该数据库中的所有可用数据的子集的方法，包括：
提供所有可用数据的第一逻辑表示，该第一逻辑表示定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；
检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；以及
将至少一部分逻辑字段修改为抽象地描述可查询数据的所述多个物理实体，以便使用所述至少一个条件从第一逻辑表示提供可查询数据的第二逻辑表示。
26.如权利要求25所述的方法，其中，修改至少一部分逻辑字段包括：
产生第一逻辑表示的实例；以及
修改该实例的至少一部分逻辑字段，以便将该实例变换为第二逻辑表示。
27.如权利要求25所述的方法，还包括：
接收包括所述多个逻辑字段的至少一个逻辑字段的抽象查询；以及
对可查询数据执行该抽象查询。
28.如权利要求27所述的方法，还包括，在检索所述至少一个条件之前：
接收包括所述多个逻辑字段的至少一个逻辑字段和所述至少一个条件的先前执行的抽象查询；
从先前执行的抽象查询中提取所述至少一个条件；以及
存储所述至少一个条件。
29.如权利要求25所述的方法，其中，检索所述至少一个条件包括：
从至少一个抽象查询中检索所述至少一个条件。
30.如权利要求25所述的方法，还包括：
提供多个条件，每个条件定义所有可用数据的至少一个物理实体的至少一个性质。
31.如权利要求30所述的方法，其中，检索所述至少一个条件包括：
访问所述多个条件；以及
从所述多个条件中确定定义可查询数据的所述多个物理实体所共有的至少一个性质的所述至少一个条件。
32.如权利要求30所述的方法，其中，提供所述多个条件包括：
接收多个抽象查询；以及
对于所述多个抽象查询的每个抽象查询：
确定该抽象查询是否包括条件；以及
如果是，则从该抽象查询中提取所述条件。
33.如权利要求25所述的方法，还包括：
接收包括所述多个逻辑字段的至少一个逻辑字段的抽象查询；
将该抽象查询变换为与可查询数据的物理数据表示一致的查询；以及
对可查询数据执行该与物理数据表示一致的查询。
34.一种包含程序的计算机可读介质，当被处理器执行时，该程序进行用于在对数据库执行查询时将数据库中的可查询数据限制为该数据库中的所有可用数据的子集的操作，该操作包括：
响应于接收到包括在所有可用数据的逻辑表示中定义的多个逻辑字段的至少一个逻辑字段的抽象查询，其中，该逻辑表示定义抽象地描述所有可用数据的相关物理实体的所述多个逻辑字段：
检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；
将所述至少一个条件与该抽象查询相关联；以及
在执行该抽象查询时，根据所述至少一个条件，将可查询数据限制为所有可用数据的子集。
35.如权利要求34所述的计算机可读介质，其中，检索所述至少一个条件包括：
从至少一个先前执行的抽象查询中检索所述至少一个条件。
36.如权利要求34所述的计算机可读介质，还包括：
在接收到该抽象查询之前，响应于接收到包括所述多个逻辑字段的至少一个逻辑字段和所述至少一个条件的先前执行的抽象查询：
从该先前执行的抽象查询中提取所述至少一个条件；以及
存储所述至少一个条件。
37.如权利要求34所述的计算机可读介质，还包括：
存储多个条件，每个条件定义所有可用数据的至少一个物理实体的至少一个性质。
38.如权利要求37所述的计算机可读介质，其中，检索所述至少一个条件包括：
访问所存储的多个条件；以及
从所存储的多个条件中确定定义可查询数据的所述多个物理实体所共有的所述至少一个性质的所述至少一个条件。
39.如权利要求37所述的计算机可读介质，其中，存储所述多个条件包括：
响应于接收到多个先前执行的抽象查询：
对于所述多个先前执行的抽象查询的每个先前执行的抽象查询：
确定该先前执行的抽象查询是否包括条件；以及
如果是，则从该先前执行的抽象查询中提取所述条件。
40.如权利要求34所述的计算机可读介质，其中，所述执行包括：
将抽象查询变换为与可查询数据的物理数据表示一致的查询；以及
对可查询数据执行该与物理数据表示一致的查询。
41.一种包含程序的计算机可读介质，当被处理器执行时，该程序进行用于将数据库中的可查询数据限制为该数据库中的所有可用数据的子集以便对该数据库执行查询的操作，该操作包括：
响应于接收到包括在所有可用数据的逻辑表示中定义的多个逻辑字段的至少一个逻辑字段的抽象查询，其中，该逻辑表示定义抽象地描述所有可用数据的相关物理实体的所述多个逻辑字段：
检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；
使用所述至少一个条件，将可查询数据限制为所有可用数据的子集；
接收包括所述多个逻辑字段的至少一个逻辑字段的抽象查询；以及
对可查询数据执行该抽象查询。
42.如权利要求41所述的计算机可读介质，其中，限制可查询数据包括：
使用所述至少一个条件从所有可用数据中确定可查询数据；以及
将可查询数据复制到将在执行抽象查询时访问的临时数据结构中。
43.如权利要求42所述的计算机可读介质，其中，限制可查询数据还包括：
将至少一部分逻辑字段修改为抽象地描述临时数据结构的相关物理实体，以便将所有可用数据的逻辑表示变换为可查询数据的临时数据结构的逻辑表示。
44.如权利要求41所述的计算机可读介质，其中，数据库包括具有所有可用数据的至少一个数据库表，并且其中，限制可查询数据包括：
使用所述至少一个条件从所有可用数据确定可查询数据；以及
将可查询数据复制到将在执行抽象查询时访问的至少一个临时表中，每个临时表对应于应用了所述至少一个条件的数据库表。
45.如权利要求41所述的计算机可读介质，其中，限制可查询数据包括：
使用所述至少一个条件从所有可用数据确定可查询数据；以及
将至少一部分逻辑字段修改为抽象地描述临时数据结构的相关物理实体，以便将所有可用数据的逻辑表示变换为可查询数据的临时数据结构的逻辑表示。
46.如权利要求41所述的计算机可读介质，其中，检索所述至少一个条件包括：
从至少一个先前执行的抽象查询中检索所述至少一个条件。
47.如权利要求41所述的计算机可读介质，还包括，在检索所述至少一个条件之前：
响应于接收到包括所述多个逻辑字段的至少一个逻辑字段和所述至少一个条件的先前执行的抽象查询；
从该先前执行的抽象查询中提取所述至少一个条件；以及
存储所述至少一个条件。
48.如权利要求41所述的计算机可读介质，还包括：
存储多个条件，每个条件定义所有可用数据的至少一个物理实体的至少一个性质。
49.如权利要求48所述的计算机可读介质，其中，检索所述至少一个条件包括：
访问所存储的多个条件；以及
从所存储的多个条件确定定义可查询数据的所述多个物理实体所共有的至少一个性质的至少一个条件。
50.如权利要求48所述的计算机可读介质，其中，存储所述多个条件包括：
响应于接收到多个先前执行的抽象查询：
对于所述多个先前执行的抽象查询的每个先前执行的抽象查询：
确定该先前执行的抽象查询是否包括条件；以及
如果是，则从该先前执行的抽象查询中提取所述条件。
51.如权利要求41所述的计算机可读介质，其中，所述执行包括：
将抽象查询变换为与可查询数据的物理数据表示一致的查询；以及
对可查询数据执行该与物理数据表示一致的查询。
52.一种包含程序的计算机可读介质，当被处理器执行时，该程序执行用于将数据库中的可查询数据限制为该数据库中的所有可用数据的子集的操作，该操作包括：
响应于用户输入，产生所有可用数据的第一逻辑表示，该第一逻辑表示定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；
检索定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件；以及
将至少一部分逻辑字段修改为抽象地描述可查询数据的所述多个物理实体，以便使用所述至少一个条件从第一逻辑表示产生可查询数据的第二逻辑表示。
53.如权利要求52所述的计算机可读介质，其中，修改至少一部分逻辑字段包括：
产生第一逻辑表示的实例；以及
修改该实例的至少一部分逻辑字段，以便将该实例变换为第二逻辑表示。
54.如权利要求52所述的计算机可读介质，还包括：
响应于接收到包括所述多个逻辑字段的至少一个逻辑字段的抽象查询：
对可查询数据执行该抽象查询。
55.如权利要求54所述的计算机可读介质，还包括，在检索所述至少一个条件之前：
响应于接收到包括所述多个逻辑字段的至少一个逻辑字段和所述至少一个条件的先前执行的抽象查询：
从该前执行的抽象查询中提取所述至少一个条件；以及
存储所述至少一个条件。
56.如权利要求52所述的计算机可读介质，其中，检索所述至少一个条件包括：
从至少一个抽象查询中检索所述至少一个条件。
57.如权利要求52所述的计算机可读介质，还包括：
存储多个条件，每个条件定义所有可用数据的至少一个物理实体的至少一个性质。
58.如权利要求57所述的计算机可读介质，其中，检索所述至少一个条件包括：
访问所存储的多个条件；以及
从所存储的多个条件中确定定义可查询数据的所述多个物理实体所共有的至少一个性质的所述至少一个条件。
59.如权利要求57所述的计算机可读介质，其中，存储所述多个条件包括：
接收多个抽象查询；以及
对于所述多个抽象查询的每个抽象查询：
确定该抽象查询是否包括条件；以及
如果是，则从该抽象查询中提取所述条件。
60.如权利要求52所述的计算机可读介质，还包括：
响应于接收到包括所述多个逻辑字段的至少一个逻辑字段的抽象查询：
将该抽象查询变换为与可查询数据的物理数据表示一致的查询；以及
对可查询数据执行该与物理数据表示一致的查询。
61.一种计算机，包括：
数据库，包含可用数据；
数据抽象模型，定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；
查询构造应用程序，用于根据数据抽象模型构造抽象查询；
运行时间组件，被配置为将抽象查询变换为具有与数据一致的形式的具体查询；以及
规则应用管理器，被配置为将定义所有可用数据的相关物理实体的至少一部分所共有的至少一个性质的至少一个条件与给定的抽象查询相关联，以便在对数据库执行对应于变换后的给定抽象查询的具体查询时，使用所述至少一个条件将数据库中的可查询数据限制为所有可用数据的子集。
62.一种计算机，包括：
数据库，包含可用数据；
数据抽象模型，定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；
查询构造应用程序，用于根据数据抽象模型构造抽象查询；
运行时间组件，被配置为将抽象查询变换为具有与数据一致的形式的具体查询；以及
规则应用管理器，用于在对数据库执行对应于变换之后的抽象查询的具体查询时，使用定义可查询数据的多个物理实体所共有的至少一个性质的至少一个条件，将数据库中的可查询数据限制为所有可用数据的子集。
63.一种计算机，包括：
数据库，包含可用数据；
第一数据抽象模型，定义抽象地描述所有可用数据的相关物理实体的多个逻辑字段；以及
规则应用组件，用于从第一数据抽象模型产生第二数据抽象模型，使用定义可查询数据的多个物理实体的至少一个性质的至少一个条件，将数据库中的可查询数据限制为所有可用数据的子集。
CNA2004800088089A 2003-04-17 2004-04-14 公开内容的抽象数据库抽象中的规则应用管理 Pending CN1768325A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/418,592 US7089235B2 (en) 2003-04-17 2003-04-17 Method for restricting queryable data in an abstract database
US10/418,592 2003-04-17

Publications (1)

Publication Number Publication Date
CN1768325A true CN1768325A (zh) 2006-05-03

Family

ID=33159145

Family Applications (1)

Application Number Title Priority Date Filing Date
CNA2004800088089A Pending CN1768325A (zh) 2003-04-17 2004-04-14 公开内容的抽象数据库抽象中的规则应用管理

Country Status (6)

Country Link
US (2) US7089235B2 (zh)
EP (1) EP1616249A4 (zh)
KR (1) KR100843651B1 (zh)
CN (1) CN1768325A (zh)
CA (1) CA2520665A1 (zh)
WO (1) WO2004095171A2 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110019215A (zh) * 2017-10-26 2019-07-16 Sap欧洲公司 多重租赁数据库***中的键模式管理

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040215656A1 (en) * 2003-04-25 2004-10-28 Marcus Dill Automated data mining runs
US10354224B2 (en) * 2003-11-07 2019-07-16 Sysmex Corporation Clinical laboratory systems, methods and computer programs for managing clinical laboratory work, management devices, and terminal devices
US7650512B2 (en) * 2003-11-18 2010-01-19 Oracle International Corporation Method of and system for searching unstructured data stored in a database
US7966493B2 (en) 2003-11-18 2011-06-21 Oracle International Corporation Method of and system for determining if an electronic signature is necessary in order to commit a transaction to a database
US7600124B2 (en) * 2003-11-18 2009-10-06 Oracle International Corporation Method of and system for associating an electronic signature with an electronic record
US8782020B2 (en) 2003-11-18 2014-07-15 Oracle International Corporation Method of and system for committing a transaction to database
US7694143B2 (en) * 2003-11-18 2010-04-06 Oracle International Corporation Method of and system for collecting an electronic signature for an electronic record stored in a database
US20050108211A1 (en) * 2003-11-18 2005-05-19 Oracle International Corporation, A California Corporation Method of and system for creating queries that operate on unstructured data stored in a database
US7337164B2 (en) * 2004-03-31 2008-02-26 Sap Ag Fast search with very large result set
US8161037B2 (en) * 2004-06-03 2012-04-17 International Business Machines Corporation Method for autonomically generating a query implementation that meets a defined performance specification
US8161038B2 (en) * 2004-10-29 2012-04-17 International Business Machines Corporation Maintain optimal query performance by presenting differences between access plans
US8112459B2 (en) * 2004-12-17 2012-02-07 International Business Machines Corporation Creating a logical table from multiple differently formatted physical tables having different access methods
US7761440B2 (en) * 2005-09-29 2010-07-20 International Business Machines Corporation Methods, systems and computer program products for synthesizing diagnoses in healthcare databases
US7774300B2 (en) * 2005-12-09 2010-08-10 International Business Machines Corporation System and method for data model and content migration in content management applications
US7203677B1 (en) * 2006-01-05 2007-04-10 International Business Machines Corporation Creation of duration episodes from single time events
US20080222121A1 (en) * 2006-06-02 2008-09-11 Wolfgang Wiessler System for Adaptively Querying a Data Storage Repository
US20080016048A1 (en) * 2006-07-12 2008-01-17 Dettinger Richard D Intelligent condition pruning for size minimization of dynamic, just in time tables
US20080016047A1 (en) * 2006-07-12 2008-01-17 Dettinger Richard D System and method for creating and populating dynamic, just in time, database tables
JP4285704B2 (ja) * 2006-08-16 2009-06-24 ソニー・エリクソン・モバイルコミュニケーションズ株式会社 情報処理装置、情報処理方法、及び情報処理プログラム
US7818341B2 (en) * 2007-03-19 2010-10-19 Microsoft Corporation Using scenario-related information to customize user experiences
US20080235170A1 (en) * 2007-03-19 2008-09-25 Microsoft Corporation Using scenario-related metadata to direct advertising
US8078604B2 (en) 2007-03-19 2011-12-13 Microsoft Corporation Identifying executable scenarios in response to search queries
US7797311B2 (en) * 2007-03-19 2010-09-14 Microsoft Corporation Organizing scenario-related information and controlling access thereto
US7689612B2 (en) * 2007-04-19 2010-03-30 Sap Ag Handling of queries of transient and persistent data
US7836071B2 (en) * 2007-09-18 2010-11-16 International Business Machines Corporation Displaying relevant abstract database elements
JP5268508B2 (ja) * 2008-09-08 2013-08-21 キヤノン株式会社 情報処理装置及び検索方法
US8150882B2 (en) 2009-03-03 2012-04-03 Microsoft Corporation Mapping from objects to data model
US8229952B2 (en) * 2009-05-11 2012-07-24 Business Objects Software Limited Generation of logical database schema representation based on symbolic business intelligence query
AU2012203333A1 (en) 2011-06-15 2013-01-10 Agile Software Pty Limited Method and apparatus for testing data warehouses
US8676787B2 (en) 2011-12-22 2014-03-18 International Business Machines Corporation Distributed multi-step abstract queries
FR3061337A1 (fr) 2016-12-23 2018-06-29 Dhatim Moteur de regles universel et optimise pour le traitement de documents de gestion
US11048815B2 (en) * 2018-08-06 2021-06-29 Snowflake Inc. Secure data sharing in a multi-tenant database system

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5608899A (en) * 1993-06-04 1997-03-04 International Business Machines Corporation Method and apparatus for searching a database by interactively modifying a database query
US5911138A (en) * 1993-06-04 1999-06-08 International Business Machines Corporation Database search facility having improved user interface
US6134549A (en) * 1995-03-31 2000-10-17 Showcase Corporation Client/server computer system having personalizable and securable views of database data
US5870746A (en) * 1995-10-12 1999-02-09 Ncr Corporation System and method for segmenting a database based upon data attributes
US5897632A (en) * 1996-08-27 1999-04-27 At&T Corp Method and system for using materialized views to evaluate queries involving aggregation
US6725227B1 (en) 1998-10-02 2004-04-20 Nec Corporation Advanced web bookmark database system
JP4552242B2 (ja) * 1999-10-06 2010-09-29 株式会社日立製作所 仮想表インタフェースと該インタフェースを用いた問合せ処理システム及び方法
US6643645B1 (en) * 2000-02-08 2003-11-04 Microsoft Corporation Retrofitting recommender system for achieving predetermined performance requirements
US20020087798A1 (en) * 2000-11-15 2002-07-04 Vijayakumar Perincherry System and method for adaptive data caching
US6609126B1 (en) * 2000-11-15 2003-08-19 Appfluent Technology, Inc. System and method for routing database requests to a database and a cache
US20020107835A1 (en) * 2001-02-08 2002-08-08 Coram Michael T. System and method for adaptive result set caching
JP4306152B2 (ja) * 2001-06-26 2009-07-29 株式会社日立製作所 クラスタ化したアプリケーションサーバおよびデータベース構造を持つＷｅｂシステム
US7185317B2 (en) * 2002-02-14 2007-02-27 Hubbard & Wells Logical data modeling and integrated application framework
US6950823B2 (en) * 2002-12-23 2005-09-27 International Business Machines Corporation Transparent edge-of-network data cache
US20040148278A1 (en) * 2003-01-22 2004-07-29 Amir Milo System and method for providing content warehouse

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110019215A (zh) * 2017-10-26 2019-07-16 Sap欧洲公司 多重租赁数据库***中的键模式管理
CN110019215B (zh) * 2017-10-26 2023-10-20 Sap欧洲公司 多重租赁数据库***中的键模式管理

Also Published As

Publication number Publication date
KR100843651B1 (ko) 2008-07-04
US20060206468A1 (en) 2006-09-14
WO2004095171A2 (en) 2004-11-04
US7089235B2 (en) 2006-08-08
CA2520665A1 (en) 2004-11-04
US20040210579A1 (en) 2004-10-21
KR20060008296A (ko) 2006-01-26
EP1616249A2 (en) 2006-01-18
EP1616249A4 (en) 2008-06-11
WO2004095171A3 (en) 2005-04-28

Similar Documents

Publication Publication Date Title
CN1768325A (zh) 公开内容的抽象数据库抽象中的规则应用管理
CN100336059C (zh) 智能使用用户数据以抢先阻止违反访问控制的查询的执行
CN1823335A (zh) 抽象数据链接和联接接口
CN1786955A (zh) 用于管理相互相关的数据对象的方法和***
CN1705945A (zh) 全局查询相关属性
CN1759397A (zh) 对数据的函数应用的结果进行结构化索引
US7752197B2 (en) SQL query construction using durable query components
CN1573753A (zh) 数据库对象脚本生成方法和***
CN1361890A (zh) 观察改变索引对查询优化方案的影响的数据库***
CN1263314A (zh) 一种动态的基于对象格式的用于数据操纵的***和方法
CN1761962A (zh) 将非结构化数据实时聚集为结构化数据以便关系数据库引擎进行sql处理
US20050203940A1 (en) Database System with Methodology for Automated Determination and Selection of Optimal Indexes
CN1647076A (zh) 查询关系数据库的方法和设备
US8326848B2 (en) Proactive analytic data set reduction via parameter condition injection
CN1889076A (zh) 定制数据库模式的移植差异检测方法和***
CN1864159A (zh) 通过查询结果扩充和结果数据反馈的迭代数据分析过程
CN1708945A (zh) 用于可能的安全性暴露的早期告警指示的查询返回数据分析方法
CN1846207A (zh) 类型路径索引
CN1310824A (zh) 用于数据仓库的选择聚集层和交叉产品层的方法和装置
US20080228716A1 (en) System and method for accessing unstructured data using a structured database query environment
CN1794232A (zh) Crm数据库的安全视图
CN1647080A (zh) 多数据库环境中存取数据的方法、计算机程序和计算机
CN1786950A (zh) 处理抽象查询的方法和***
CN1804840A (zh) 数据访问层类生成器
CN1653452A (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
AD01 Patent right deemed abandoned

Effective date of abandoning: 20060503

C20 Patent right or utility model deemed to be abandoned or is abandoned