CN105518670B

CN105518670B - 用于模型查询的数据模型索引

Info

Publication number: CN105518670B
Application number: CN201480048972.6A
Authority: CN
Inventors: Z·刘; C·C·B·麦克; 邓小民; Y·L·胡耶恩; N·王
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2014-07-15
Filing date: 2014-07-15
Publication date: 2021-09-07
Anticipated expiration: 2034-07-15
Also published as: EP3170101A4; US10140323B2; EP3170101B1; WO2016008086A1; US20160019246A1; EP3170101A1; CN105518670A

Abstract

使用数据模型索引来协助对数据模型查询的高效响应。数据模型查询标识数据模型本身并参考数据模型的模式，而非参考底层数据源的模式。索引通过将对数据模型的先前模型查询与对这些先前模型查询的相关联的响应相关来协助。因此，如果遇到类似的模型查询，来自先前模型查询的响应可依然被认为是新鲜的，该索引可被用于更高效地检索针对该类似的模型查询的结果。数据管理***可包括多个数据模型，每个数据模型都具有对应的数据模型索引。

Description

用于模型查询的数据模型索引

背景

计算***和相关联的网络彻底改变了人类工作、游戏和通信的方式。我们生活的几乎每个方面都在某种方式上受到计算***的影响。网络的扩增允许计算***共享数据并通信，从而快速地增加信息访问。出于这个理由，现在的时代通常被称为“信息时代”。

数据模型描述经结构化的数据的结构(即，定义、格式、关系、约束等)以供存储在数据管理***(诸如关系数据库)中。在操作期间，各个执行软件在确定要检索的数据、数据的含义、数据与其它数据的关系、数据的属性或特性等时可参考数据模型。

当设计针对组织的数据***时，通常首先设计相对独立于底层数据管理***(例如，相对独立于底层数据库管理***)的逻辑数据模型。逻辑数据模型通常包括描述业务实体的数据对象。例如，如果组织是刨冰公司，则业务实体可包括刨冰站、雇员、口味、大小、价格、营业收入、销售量等。当然，这些术语独立于任何底层物理数据管理***。

一旦逻辑数据模型被设计，数据管理***的其余部分就被设计来满足逻辑数据模型的需要。例如，物理数据模型位于逻辑数据模型之下，并还描述实体、关系、属性等，但是以更加对准底层数据管理***的工具和约束的方式。逻辑数据模型内的实体和属性被映射到物理数据模型内的实体和属性。

此处要求保护的主题不限于解决任何缺点或仅在诸如上述环境这样的环境中操作的各实施例。相反，提供该背景仅用于例示其中可实现所述一些实施例的一个示例性技术领域。

简要概述

本文中描述的至少一些实施例涉及使用数据模型索引来用于协助对数据模型查询的高效响应。数据模型查询标识数据模型本身并参考数据模型的模式，而非参考底层数据源的模式。索引通过将对数据模型的先前模型查询与对这些先前模型查询的相关联的响应相关来协助。因此，如果遇到类似的模型查询，来自先前模型查询的响应可依然被认为是新鲜的，该索引可被用于更高效地检索针对该类似的模型查询的结果。

在一些实施例中，数据管理***可包括多个数据模型，每个数据模型都具有对应的数据模型索引。例如，一个数据模型可以是逻辑数据模型，而另一个数据模型可以是物理数据模型，每个数据模型都具有其自己的数据模型索引。甚至可以存在映射到某一物理数据模型的多个逻辑数据模型，并且每个数据模型索引将再次具有其自己的数据模型索引。在一些实施例中，可向高速缓存提供来自在先模型查询的结果。

该概述不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在被用来帮助确定所要求保护的主题的范围。

附图简述

为了描述能够获得上述和其它优点和特征的方式，各实施例的更具体的描述将通过参考各附图来呈现。可以理解，这些附图只描绘了示例实施例，并且因此不被认为是对其范围的限制，将通过使用附图并利用附加特征和细节来描述和解释各实施例，在附图中：

图1抽象地解说了其中可采用本文中所描述的一些实施例的计算***；

图2示出数据管理环境，该数据管理环境包括数据存储***、物理数据模型层、包括多个逻辑数据模型的逻辑数据模型层以及在物理数据模型层和逻辑数据模型层之间作为中介的映射层；

图3示出在示例逻辑数据模型上执行的四种不同的逻辑数据模型结构更改类型的示例；

图4示出用于扩充已经包括展示数据存储***的一个或多个逻辑数据模型的数据模型的方法的流程图；

图5示出类似于图2的数据管理环境的数据管理环境，并且其中模型查询引擎用作用于处理模型查询的中枢；

图6示出用于模型查询引擎对接收到的模型查询进行操作的方法的流程图；以及

图7示出类似于图2的数据管理环境的数据管理环境，除了附加的逻辑数据模型被示出，逻辑和物理数据模型中的每一个具有相关联的索引，并且存在用于模型查询的高速缓存。

详细描述

将参考图1描述对计算设备的一些介绍性讨论。接着，将参考之后的附图来描述多个逻辑数据模型的结构和使用以展示数据存储***以及在使用数据模型索引的上下文中针对该多个逻辑数据模型的查询。

计算***现在越来越多地采取多种多样的形式。例如，计算***可以是手持式设备、电器、膝上型计算机、台式计算机、大型机、分布式计算***、数据中心、或甚至是常规上不被认为是计算***的设备(诸如可穿戴设备(如眼镜))。在本说明书以及权利要求书中，术语“计算***”被广义地定义为包括任何设备或***(或其组合)，该设备或***包含至少一个物理且有形的处理器以及其上能具有可由处理器执行的计算机可执行指令的物理且有形的存储器。存储器可以采取任何形式，并可以取决于计算***的性质和形式。计算***可以分布在网络环境中，并可包括多个组分计算***。

如图1所例示，在其最基本的配置中，计算***100通常包括至少一个硬件处理单元102和存储器104。存储器104可以是物理***存储器，该物理***存储器可以是易失性的、非易失性的、或两者的某种组合。术语“存储器”也可在此用来指示诸如物理存储介质这样的非易失性大容量存储器。如果计算***是分布式的，则处理、存储器和/或存储能力也可以是分布式的。如本文中所使用的，术语“可执行模块”或“可执行组件”可指可在计算***上执行的软件对象、例程或方法。此处所描述的不同组件、模块、引擎以及服务可以实现为在计算***上执行的对象或进程(例如，作为分开的线程)。

在随后的描述中，参考由一个或多个计算***执行的动作描述了各实施例。如果这样的动作是以软件实现的，则执行动作的相关联计算***的一个或多个处理器响应于已经执行了计算机可执行指令来引导计算***的操作。例如，这样的计算机可执行指令可以在形成计算机程序产品的一个或多个计算机可读介质上实现。这样的操作的示例涉及对数据的操纵。计算机可执行指令(以及***纵的数据)可以存储在计算***100的存储器104中。计算***100还可包含允许计算***100例如通过网络110与其他计算***通信的通信信道108。计算***100还包括显示器112，显示器112可被用于向用户显示视觉表示。

本文所述的实施例可包括或利用专用或通用计算***，该专用或通用计算***包括诸如举例来说一个或多个处理器和***存储器等计算机硬件，如以下更详细讨论的。本文中描述的各实施例还包括用于承载或存储计算机可执行指令和/或数据结构的物理和其他计算机可读介质。这样的计算机可读介质可以是可由通用或专用计算***访问的任何可用介质。存储计算机可执行指令的计算机可读介质是物理存储介质。承载计算机可执行指令的计算机可读介质是传输介质。由此，作为示例而非限制，本发明的各实施例可包括至少两种显著不同的计算机可读介质：存储介质和传输介质。

计算机可读存储介质包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁存储设备，或可用于存储计算机可执行指令或数据结构形式的所需程序代码手段且可由通用或专用计算***访问的任何其他物理且有形存储介质。

“网络”被定义为允许在计算***和/或模块和/或其他电子设备之间传输电子数据的一个或多个数据链路。当信息通过网络或另一通信连接(硬连线、无线、或者硬连线或无线的组合)传输或提供给计算***时，该计算***将该连接适当地视为传输介质。传输介质可以包括可以用来携带所需要的以计算机可执行的指令或数据结构的形式存在的程序代码手段并可以被通用或专用计算***访问的网络和/或数据链路。上述的组合应当也被包括在计算机可读介质的范围内。

此外，在到达各种计算***组件之后，计算机可执行指令或数据结构形式的程序代码手段可从传输介质自动转移到存储介质(或反之亦然)。例如，通过网络或数据链路接收到的计算机可执行指令或数据结构可被缓存在网络接口模块(例如，“NIC”)内的RAM中，然后最终被传送到计算***RAM和/或计算***处的较不易失性的存储介质。因而，应当理解，存储介质可被包括在还利用(或甚至主要利用)传输介质的计算***组件中。

计算机可执行指令例如包括，当在处理器处执行时使通用计算***、专用计算***、或专用处理设备执行某一功能或某组功能的指令和数据。计算机可执行指令可例如是二进制或甚至是在被处理器直接执行之前经受某种转换(诸如编译)的指令，诸如中间格式指令(诸如汇编语言或甚至是源代码)。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述特征或动作。相反，上述特征和动作是作为实现权利要求的示例形式而公开的。

本领域的技术人员将理解，本发明可以在具有许多类型的计算***配置的网络计算环境中实践，这些计算机***配置包括个人计算机、台式计算机、膝上型计算机、消息处理器、手持式设备、多处理器***、基于微处理器的或可编程消费电子设备、网络PC、小型计算机、大型计算机、移动电话、PDA、寻呼机、路由器、交换机、数据中心、可穿戴设备(诸如眼镜)等等。本发明也可在其中通过网络链接(或者通过硬连线数据链路、无线数据链路，或者通过硬连线和无线数据链路的组合)的本地和远程计算***两者都执行任务的分布式***环境中实施。在分布式***环境中，程序模块可以位于本地和远程存储器存储设备二者中。

图2示出包括数据存储***210的数据管理环境200，该数据存储***210包含数据。数据管理环境200可使用图1的计算***100来实现。数据存储***210可具有单个构成数据存储***211(也称为“存储”)。例如，存储可以是数据库或其它统一存储。替换地，省略号212表示可以存在多个存储。例如，数据存储***210还可以是混合数据存储***，在这种情况下存在多个存储，该多个存储中的至少一些具有不同的类型。例如，构成数据存储***的一个可以是经结构化的数据，而构成数据存储***中的另一个可以是未经结构化的数据。

物理数据模型层220包括零个或更多个物理数据模型。例如，物理数据模型层220被示出为包括一个物理数据模型221，但是省略号222表示在物理数据模型层220中可以存在多个物理数据模型(或甚至零个物理数据模型)。在本描述和权利要求书中，“物理数据模型”是将特定数据管理***(诸如数据库管理***)的工具和约束考虑在内的数据模型。在数据存储***210是混合数据存储***的情况下，可能存在多个物理数据模型，每个物理数据模型将相应数据管理***的工具和约束考虑在内，该相应数据管理***促进相应构成数据存储***。

传统地，只有一个逻辑数据模型被用于映射到特定物理数据模型或数据存储***。然而，根据本文中描述的原理，可以存在展示某一特定数据存储***的多个逻辑数据模型。因此，逻辑数据模型层230被示出为包括(直接地或经由物理数据模型层220中的物理数据模型中的一个或多个)展示底层数据存储***210的两个逻辑数据模型231和232。然而，省略号233在符号上表示可能存在单个逻辑数据模型，或潜在地三个或更多个各自展示数据存储***210的逻辑数据模型。

在本说明书和权利要求书中，“逻辑数据模型”是具有被映射到物理数据模型层220中的物理数据模型的至少一个实体集或属性集的至少一个实体集或属性集的数据模型。在本说明书的剩余部分和权利要求书中，关于数据模型的“实体”是数据模型中的节点(例如，对象)或数据模型中的节点的属性(例如，特征)。

数据管理环境200还包括在逻辑数据模型层230和物理数据模型层220之间的映射层240。对于逻辑数据模型层230内的逻辑数据模型中的至少一些中的每一个，语义映射集将逻辑数据模型层230中对应的逻辑数据模型的一个或多个实体集与物理数据模型层220中的物理数据模型中的一个或多个中的一个或多个实体相映射。

例如，语义映射集241对应于逻辑数据模型231，其中逻辑数据模型231使用语义映射集241来展示数据存储***210(通过映射到物理数据模型层220中的物理数据模型中的一个或多个的一个或多个实体，和/或通过直接映射到数据存储***210的一个或多个实体本身)。类似地，语义映射集242对应于逻辑数据模型232，其中逻辑数据模型232使用语义映射集242来(直接地或经由一个或多个物理数据模型间接地)展示数据存储***210。省略号243示出可以存在与逻辑数据模型层230中的逻辑数据模型的数量大致相关的更多或更少的语义映射集。

每个逻辑数据模型可针对不同的纵向(vertical)方案(有时也称为“域”或简单地称为“纵向”)。例如，第一逻辑数据模型231被显示为向第一纵向A展示数据，而第二逻辑数据模型232被显示为向第二纵向B展示数据。因此，不同的语义被应用到针对不同纵向的数据。例如，一个数据片段在不同的域中可表示不同的事物。例如，在医学域中，姓名字段具有值“John Doe”可能与其在与John Doe被雇佣的地方相关联的域中(其中相同的数据可具有含义“雇员”)有稍微不同的含义(例如，“病人”的含义)。当然，术语“病人”和“雇员”具有非常不同的语义。针对每个逻辑数据模型的语义映射集提供适当的映射来支持被应用到相同数据的不同语义。

数据管理环境200还包括公共符号组件250，其被配置成允许每个逻辑数据模型(以及语义映射集)具有不同的建模符号。在较高层，公共符号组件250允许用户使用他们希望的任何建模符号(也称为“表示框架”)来经由他们的逻辑数据模型访问数据。公共符号组件250通过将不同的建模符号中的全部或部分翻译为用于用在物理数据模型层220处和/或数据存储***210处的公共建模符号来这么做。因此，任意给定物理数据模型可依赖于对公共建模符号的使用，而不管使用该物理数据模型的逻辑数据模型具有不同的建模符号。

数据管理环境200还包括逻辑数据模型生存周期跟踪组件260，其被配置成跟踪具有多个逻辑数据模型结构更改类型的逻辑数据模型结构更改。当具有特定逻辑数据模型结构更改类型的特定更改被执行时，逻辑数据模型生存周期跟踪组件260致使适当的反映被作出在适当的语义映射集中。例如，图3示出四种不同类型的逻辑数据模型结构更改类型。在每种情况下，更改由虚线表示。

第一逻辑数据模型结构更改类型由箭头301总得表示，其中逻辑数据模型(在这种情况下为逻辑数据模型300A)的新组件实体被创建(也被称为“出生”、“传播”或“增强”)。跟踪组件260由此将潜在地在针对逻辑数据模型300A的语义映射集内创建(如由箭头311表示)新实体的表示以供将来映射到物理数据模型层220内的物理数据模型221中的一个或多个实体和/或以供直接映射到数据存储***210中的一个或多个实体。

第二逻辑数据模型结构更改类型总得由箭头302表示，其中逻辑数据模型(在这个情况下为逻辑数据模型300D)的一实体从逻辑数据模型中引退(或移除)。跟踪组件260由此将在针对逻辑数据模型300D的语义映射集内移除(如由箭头312表示)所引退的实体的表示，由此消除任何涉及所引退的实体的映射或使这些映射呈现为没有实际意义。

第三逻辑数据模型结构更改类型由箭头303总得表示，其中两个逻辑数据模型(在这个情况下为逻辑数据模型300A和300B)被合并到单个数据模型内。跟踪组件260由此将适当地合并(如由箭头313表示)两个语义映射集来反映这个合并操作。

第四逻辑数据模型结构更改类型由箭头304总得表示，其中一个逻辑数据模型(在这个情况下为逻辑数据模型300C)从另一逻辑数据模型(在这个情况下为逻辑数据模型300B)中分出。跟踪组件260由此将适当地将一语义映射集拆分(如由箭头314表示)成两个语义映射集来反映这个拆分操作。

参考回图2，数据管理***200还被示出为包括扩充组件270，其允许新的逻辑数据模型被添加到逻辑数据模型层230。图4示出用于扩充数据管理***的方法400的流程图，该数据管理***包括展示数据存储***的一个或多个逻辑数据模型以及也展示该数据存储***的附加逻辑数据模型。方法400可由图2的扩充组件270执行。

首先，将该附加逻辑数据模型与数据存储***相关联，该数据存储***已经具有至少一个与该数据存储***相关联的先前逻辑数据模型(动作401)。例如，针对语义映射集的模板可被创建以供之后填充。接着，随着时间，语义映射集针对该附加逻辑数据模型来定义(动作402)，使得该附加逻辑数据模型也可展示该数据存储***。注意，语义映射集可能针对每个逻辑数据模型而不同，并且由此这个新的语义映射集可以与被用于其它逻辑数据模型的其它语义映射集中的任一个不同。此外，用户可能指定建模符号(动作403)以一般地在参考特定附加逻辑数据模型的数据时或针对使用特定逻辑数据模型来参考数据来使用。

因此，已经描述了数据管理环境，其中灵活数量的逻辑数据模型可被用于展示数据存储***。现在，将描述用于使用数据管理环境的机制。针对使用任意数据管理环境的主要用处是针对数据管理环境来执行查询。由此，本描述现在将转向用于针对数据管理环境200来执行查询以从而具有来自数据存储***210的返回的数据的机制。

数据管理环境200还包括模型查询引擎280。图5示出了类似于图2的数据管理环境200的数据管理环境500，除了模型查询引擎501被显示为图2的模型查询引擎280的一个示例。此外，模型查询引擎510被示出为被更居中地定位，作为用于处理模型查询的中枢。此外，与处理模型查询相关联的各个流被示出。附加地，虽然可能存在各个逻辑数据模型，但是仅示出了一个逻辑数据模型231。虽然可能存在各个物理数据模型(或不存在物理数据模型)，但是仅示出了一个物理数据模型221。由于模型查询引擎501可使用、包括或可以是映射层240，所以映射层240也被显示为被包括在模型查询引擎501内。

图6示出用于模型查询引擎对接收到模型查询进行操作的方法600的流程图。方法600可由图2的模型查询引擎280和/或由图5的模型查询引擎501来执行。因此，方法600现在将参考图2和5来进行描述。

模型查询引擎280和/或501可在接收模型查询之际来执行方法600。在本描述和权利要求书中，“模型查询”是指定逻辑数据模型身份以及潜在地一个或多个逻辑数据模型实体(例如，节点)的身份和/或一个或多个逻辑数据模型实体属性(例如，特征)的身份的查询。由此，用户能够直接针对逻辑数据模型中的一个或多个来进行查询，而非具有关于底层数据存储***的模式的任何知晓。

本文中描述的原理并不限制到针对模型查询的任一特定格式。然而，以下是一般化的模型查询的示例，并且被提供为它们遵循类似于对于基于表格的查询的结构，但针对模型，而非表格：

示例1：

SELECT Attribute(1),Attribute(2),…

FROM Model(1)

示例2:

SELECT Attribute(1),Attribute(2),…

FROM Model(1)

WHERE Attribute(1)＝‘{criteria}’

示例3：

SELECT Model(1).Attribute(1),Model(1).Attribute(2),Model(2).Attribute(1),…

FROM Model(1)JOIN Model(2)

ON Model(1).Attribute(1),Model(2)Attribute(1)

示例4：

SELECT Attribute(1),Attribute(2),…

FROM Model(1)

UNION{ALL}

SELECT Attribute(1),Attribute(2),…

FROM Model(2)

由此，模型查询语言可以、但不需要、类似于传统的查询语言，但参考逻辑数据模型实体和/或属性，而非数据存储***表格和/或属性。例如，模型查询语言可具有针对集合表达式的规定(诸如“UNION(并集)”、“JOIN(联结)”、“DIFFERENCE(差)”、“INTERSECTION(交集)”等)。模型查询中的每一个都可具有跨多个逻辑数据模型中的全部的公共模式。由此，查询者根本不需要具有关于数据存储***的用于生成模型查询的任何知晓，而是仅参考逻辑数据模型、逻辑数据模型实体和/或逻辑数据模型实体属性，并在适当时，将约束、集合表达式等应用到模型查询。然而，如果查询者熟悉特定逻辑数据模型的建模符号，则查询者可依然使用建模符号来生成直接针对逻辑数据模型的逻辑数据模型查询。

模型查询引擎接收所生成的模型查询(动作601)。例如，在图5中，模型查询引擎501接收模型查询502(如由箭头511表示的)。

模型查询引擎接着解释该模型查询(动作602)。模型查询引擎接着可检查高速缓存(动作603)来查看是否相同模型查询的全部或部分已经在过去作出并且足够近到该高速缓存中相关联的结果可被认为是新鲜的。

例如，图7示出类似于图2的数据管理环境200的数据管理环境700。然而，在此，示出了存在四个逻辑数据模型731到734。因此，逻辑数据模型731和732可表示图2的逻辑数据模型231和232的示例。逻辑数据模型733和734可由图3中的省略号233表示。每个逻辑数据模型被示出为具有不同形状的元素，其符号地表示逻辑数据模型可各自由不同的建模符号来表示。示出了存在高速缓存710，其中先前作出的模型查询的结果(或这样的查询结果的部分)可至少保持到这样的结果不再认为是新鲜的。图5的模型查询引擎501由此可咨询高速缓存710来查看是否模型查询的一部分或全部已经在高速缓存710内具有新鲜的结果。

模型查询引擎接着标识被标识在查询中的一个或多个逻辑数据模型(动作604)。例如，在图5的示例中，假设被标识的唯一逻辑数据模型是逻辑数据模型231。对模型查询的解释还涉及标识被指定在模型查询中的任意逻辑数据模型实体和/或属性。

对于所标识的逻辑数据模型中的每一个，模型查询引擎与所标识的逻辑数据模型进行交互(动作610)。在图5的示例中，只有一个逻辑数据模型231被标识在模型查询中，并且由此模型查询引擎501通过适当的通道与逻辑数据模型231进行交互，如由箭头512和513表示的。

作为该交互的一部分，模型查询引擎501标识逻辑数据模型所使用的建模符号(动作611)。例如，逻辑数据模型提供者可在图4的动作403中指定了这个建模符号。替换地或附加地，模型查询引擎501可自动地检测逻辑数据模型所使用的建模符号。

模型查询引擎501接着制定逻辑数据模型查询(动作612)，该逻辑数据模型查询符合针对该逻辑数据模型的建模符号并对应于模型查询中对应于该特定逻辑数据模型的该部分。

模型查询引擎501可接着检查与该逻辑数据模型相关联的索引(动作613)，以查看是否该查询的结果先前已经被返回和/或是否存在将协助简化与该逻辑数据模型的交互的索引。在一个示例中，每个逻辑数据模型具有相关联的不同索引。例如，在图7的示例中，注意，逻辑数据模型731到734中的每一个都具有相关联的索引701到704。在图5的示例中，由于只存在一个与其交互的逻辑数据模型231，只有相关联的逻辑数据模型索引521被显示。例如，如果图5的逻辑数据模型231是图7的逻辑数据模型731，则图5的逻辑数据模型索引521将是图7的逻辑数据模型索引701。因此，本文中描述的原理可通过对多模型索引的使用来加速。

如果必要(由于逻辑数据模型查询的结果没有被完整地高速缓存在索引中)，模型查询引擎501接着将逻辑数据模型查询(或由针对该逻辑数据模型的索引所允许的逻辑数据模型查询的简化版本)提交(动作614)到对应的逻辑数据模型。这个提交由图2中的箭头512表示。

无论是根据针对该逻辑数据模型的索引还是根据与该逻辑数据模型的并发交互，模型查询引擎501都接收来自对应的逻辑数据模型的逻辑数据模型查询的结果(动作615)。对逻辑数据模型查询结果的这一接收由图5中的箭头513被表示在图5中。

如果该逻辑数据模型的建模符号还不是公共建模符号，则模型查询引擎接着将这些结果从该逻辑数据模型所使用的建模符号转换为公共建模符号(动作616)。公共建模符号的一个示例是统一建模语言(UML)，但是这仅仅是一个示例。因此，当与物理数据模型进行交互时，模型查询引擎可使用该公共建模符号，同时依然允许逻辑数据模型的提供者指定在参考相应逻辑数据模型时要被使用的建模符号。

这个逻辑数据模型查询的结果可潜在地被索引在对应的逻辑数据模型的索引中(动作617)。例如，在图5中，从逻辑数据模型231返回的结果(如被箭头513表示)可被索引在针对逻辑数据模型231的对应的索引521内。参考图7，逻辑数据模型索引701到704中的每一个可类似地对针对相应逻辑数据模型731到734作出的先前模型查询的结果进行索引。

基于这些结果，模型查询引擎还标识(动作618)要被交互以对模型查询进行响应的一个或多个物理数据模型(或直接地标识数据存储***)。为了这么作，模型查询引擎可参考针对从中可获得结果的对应的逻辑数据模型的语义映射集。

接着，模型查询引擎与所得到的一个或多个物理数据模型中的每一个进行交互(动作620)。相应地，动作620的内容针对一个或多个物理数据模型中的每一个或直接针对数据存储***(由于映射可指引)来执行。在对动作620的内容的剩余描述中，术语“物理数据模型”将与数据源***互换地使用，这是因为动作620的内容可被执行来与在数据源***上操作的特定物理数据模型进行交互或直接与数据源***本身进行交互。

为了这么作，模型查询引擎501咨询针对该逻辑数据模型的语义映射集(动作621)。通过使用这一咨询以及逻辑数据模型查询的结果，模型查询引擎501接着制定符合被用在物理数据模型层处(或被数据源***本身使用)的公共建模符号的物理数据模型查询(动作622)。

模型查询引擎501可接着检查与该物理数据模型相关联的索引(动作623)，以查看是否该查询的结果先前已经被返回和/或是否存在将协助简化与该物理数据模型(或根据情况由数据源***)的交互的索引。例如，在图5中，物理数据模型索引522对物理数据模型221进行服务。例如，在图7中，这个物理数据模型索引705也被示出。

如果必要(由于物理数据模型查询的结果没有被完整地高速缓存在索引522中)，模型查询引擎501接着将物理数据模型查询(或由针对该物理数据模型的索引所允许的物理数据模型查询的简化版本)提交(动作624)到对应的物理数据模型。这个提交由图5中的箭头524表示。

无论是从针对该物理数据模型的索引522还是从与该物理数据模型221的并发交互，模型查询引擎501都接收来自对应的物理数据模型的物理数据模型查询的结果(动作625)。对物理数据模型查询结果的这个接收由箭头515被表示在图5中。

这个物理数据模型查询的结果可潜在地被索引在对应的物理数据模型的索引中(动作626)。例如，在图5中，从物理数据模型221返回的结果(如被箭头515表示)可被索引在针对物理数据模型221的对应的索引522内。在图7的上下文中，结果可被索引在物理数据模型索引705中。

模型查询引擎接着将所有物理数据模型查询结果组装到结果集中(动作631)并将该结果集返回到查询者(动作632)。该结果集的这个返回使用箭头516被表示在图5中。该结果集由元素503被表示在图5中。

本文中描述的原理对于潜在地随着时间改变的大量数据(有时被称为“大数据”)尤其有用。这样的数据通常不根据太字节来描述，而通常根据拍字节(1024个太字节)、艾字节(1024个拍字节)，并且在将来可能根据泽字节(1024个艾字节)和尧字节(1024个泽字节)来描述。这样的数据在性质上通常更加全球性和分布化，并涉及大量通常被动态地改变、添加和替换的数据源。由此，“大数据”可被视为更加有机且发展的数据源***。

通过使用大数据，具有多个使用这种数据量的纵向方案可以是非常有益的，因为这样的大数据表示对许多组织而言有价值的资源。此外，由于数据是非常大的，所以通过参考特定纵向方案所熟悉的逻辑数据模型，而非直接参考数据源的模式，有助于对该数据执行查询。因此，本文中描述的原理允许多个纵向方案使用不同的逻辑数据模型来访问相同的数据，并允许它们对该相同的大数据进行查询，即使查询者不熟悉数据源本身的底层模式的复杂性。

本发明可具体化为其它具体形式而不背离其精神或本质特征。所描述的实施例在所有方面都应被认为仅是说明性而非限制性的。从而，本发明的范围由所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变应被权利要求书的范围所涵盖。

Claims

1.一种***，包括：

多个逻辑数据模型，所述多个逻辑数据模型中的至少一者被映射到物理数据模型；

模型查询引擎，所述模型查询引擎被配置成接收指定所述多个逻辑数据模型中的逻辑数据模型的模型查询并制定逻辑数据模型请求；

逻辑数据模型索引，所述逻辑数据模型索引被配置成对多个逻辑数据模型请求以及对应的至少部分逻辑数据模型请求结果进行索引，经索引的逻辑数据模型请求是被发出到所述多个逻辑数据模型中的对应逻辑数据模型的请求，其中所述逻辑数据模型索引通过将对所述对应逻辑数据模型的先前逻辑模型查询与对这些先前逻辑模型查询的相关联的响应相关来协助确定这些先前逻辑模型查询的结果是否已经被返回。

2.权利要求1所述的***，其特征在于，进一步包括所述物理数据模型。

3.如权利要求2所述的***，其特征在于，进一步包括：

物理数据模型索引，所述物理数据模型索引被配置成通过至少部分地对针对所述物理数据模型作出的多个物理数据模型请求的结果进行索引来对针对所述物理数据模型作出的所述多个物理数据模型请求进行索引。

4.如权利要求3所述的***，其特征在于，进一步包括：

高速缓存，所述高速缓存被配置成对先前对所述逻辑数据模型和/或所述物理数据模型作出的至少一些模型查询的结果进行高速缓存。

5.如权利要求1所述的***，其特征在于，进一步包括：

高速缓存，所述高速缓存被配置成对先前对所述多个逻辑数据模型作出的至少一些逻辑模型查询的结果进行高速缓存。

6.一种用于对针对数据模型的模型查询进行响应的方法，所述方法包括：

将所述模型查询解释为标识多个逻辑数据模型中的被映射到物理数据模型的至少一个逻辑数据模型的动作；

对于至少一个标识出的逻辑数据模型中的一个或多个中的每一个，通过执行参考与所述多个逻辑数据模型中的对应逻辑数据模型相对应的逻辑数据模型索引的动作来制定对于所述对应逻辑数据模型的逻辑数据模型请求，所述逻辑数据模型索引被配置成对先前对所述对应逻辑数据模型作出的多个逻辑数据模型请求中的至少一些以及对应的至少部分逻辑数据模型请求结果进行索引，其中所述逻辑数据模型索引通过将对所述至少一个逻辑数据模型的先前逻辑模型查询与对这些先前逻辑模型查询的相关联的响应相关来协助确定这些先前逻辑模型查询的结果是否已经被返回。

7.如权利要求6所述的方法，其特征在于，所述逻辑数据模型索引是第一数据模型索引，所述对应逻辑数据模型是第一数据模型，其中所述方法进一步包括：

通过至少部分地对针对所述物理数据模型作出的多个物理数据模型请求的结果进行索引来对针对所述物理数据模型作出的所述多个物理数据模型请求进行索引。

8.如权利要求7所述的方法，其特征在于，所述方法进一步包括：

对先前对所述逻辑数据模型和/或所述物理数据模型作出的至少一些模型查询的结果进行高速缓存。

9.如权利要求6所述的方法，其特征在于，所述方法进一步包括：

对先前对所述多个逻辑数据模型作出的至少一些逻辑模型查询的结果进行高速缓存。

10.一种包括用于执行如权利要求6-9中的任一项所述的方法的装置的计算机***。

11.一种具有指令的计算机可读存储介质，所述指令在被执行时使机器执行如权利要求6-9中的任一项所述的方法。