具体实施方式
提供下面的说明以使得本领域的任何技术人员能够做出和使用所描述的实施例,并且阐述预期实现一些实施例的最优模式。但是,各种修改对于本领域技术人员来说也仍是清楚的。
图1的系统100包括用于定义与关系数据源120关联的信息空间元数据110的架构。关系数据源120可以包括任意回应性查询(query-responsive)数据源或者已知或变为已知的关系数据的源,包括但不局限于结构化查询语言(SQL)关系数据库管理系统。
元数据设计器130可以包括用于基于关系数据源120创建信息空间元数据110的软件应用。元数据设计器130可以包括运行在任意计算设备或已知或变为已知的设备上的独立的、基于Web或其它的应用。图1中使用虚线来表示关系数据源120与元数据设计器130之间的连接在生成信息空间元数据110之前、期间或之后不需要存在。如果建立了该连接,这样的连接可以包括任何适合的数据库连接(例如,Java数据库连接器、QT/连接服务器)。
元数据设计器130可以通过数据库管理器或通过其它手段,直接从关系数据源120、从结构化列表、从其手动入口来确定关系数据源120的表格结构。表格结构可以包括数据源120的表格列表、它们的组成列及它们之间的接合点(join)。这样的结构可以被称作数据基础,本领域已知用于检索(retrieval)该数据基础的系统。
下面提供根据一些实施例的信息空间元数据110的具体例子。但是,简言之,信息空间元数据110可以包括连接属性定义和信息空间SQL语句(statement),连接属性定义包括用于与关系数据源120通信的信息,信息空间SQL语句用于描述数据源120的数据库表格的结构。信息空间元数据110还可以包括描述与数据源120关联的抽象层的业务对象的元数据。
美国专利No.5,555,403描述了这样一种抽象层,在该专利中称作语义层。简言之,抽象层定义一组在数据源的数据中表示的“业务对象”,其代表诸如消费者、产品、商店、时间(time)、销售图(sales figures)等等之类的业务实体。业务对象可以被分类为维度(人们可能想要依照其来执行分析或报告)、细节(例如,有关维度的其它信息)和量度(例如,指示符,经常是数字的,可以针对给定的维度值组合而确定指示符的值)。经普通转让的美国专利NO.7,181,440描述了一种基于关系数据源生成业务对象的系统。
因此,信息空间元数据110还可以包括与维度对象和量度对象关联的元数据。对于维度对象中的每一个来说,元数据可以指定与该维度对象关联的数据源120的关系表格、以及与该维度对象关联的关系表格的一个或多个列名。对于量度对象中的每一个,元数据可以指定与该量度对象关联的关系表格、与该量度对象关联的关系表格的一个或多个列名、以及与该量度对象关联的聚合方法(例如,SUM(求和))。
系统100的组件可以通过硬件和/或软件的任意适合组合来实现。每个组件都可以位于远离一个或多个其它组件之处。可以在单个器件和/或软件包中实现多于一个的组件。
图2示出了以示例为目的的数据源的结构200。结构200包括产品表格210、商店表格220、日期表格230和事实(facts)表格240,其中每一个都包括关联数据列。销售表格240包括针对产品表格210的外来密钥ProdId、针对商店表格220的外来密钥StoreId以及针对日期表格230的外来密钥DateId。实施方式并不局限于结构200。在一些实施例中,产品表格210、商店表格220和日期表格230之间可以存在一个或多个外来密钥关系。
图3示出了根据一些实施例的、用于定义信息空间元数据的界面300。界面300可以由元数据设计器130提供,以生成信息空间元数据110,但是实施方式并不局限于此。界面300的区域310显示了将在元数据中描述的维度对象和量度对象。区域310的维度对象和量度对象可以是根据已知或变为已知的抽象技术、基于结构200已经生成的。
区域320允许操作员指定在区域310中选择的维度对象的属性。这些属性可以包括、但不局限于名称、描述和列(也即,与维度对象关联的数据源的列)。还示出了搜索属性窗口330,用于定义搜索维度的SQL查询。可替换地,窗口330可以基于在字段340中指定的列来指定基于表格的搜索属性。复选框350用于指示是否要索引维度的真实值以供后续的搜索。
界面400可以由元数据设计器130提供,以生成量度对象元数据。在界面400的区域410中选择量度对象,在区域420中指定该量度对象的属性。这些属性可以包括、但不局限于名称、描述和列(也即,与量度对象关联的数据源的列)。下拉菜单430允许操作员指示与该量度对象关联的聚合方法(例如,SUM(求和)、COUNT(计数)、MIN(最小)、MAX(最大)、AVG(平均))。下面描述根据一些实施例的指定聚合方法的使用。
图5示出了用于定义主题(subject)数据源的表格的结构(也即,数据基础)的界面500。在界面500中示出了定义该结构的SQL语句,但是在一些实施例中可以使用表格/视图定义该结构。
图6示出根据一些实施例的运行时架构600。信息空间元数据610与关系数据源620的关系表格相关联。根据一些实施例,关系数据源620支持基于标准的查询(例如,SQL查询)。信息空间元数据610可以是已经使用界面300、400和500、由元数据设计器130生成的,但是实施例不局限于此。
如图所示,信息空间元数据610包括数据库连接属性定义。数据库连接属性定义包括用于与关系数据源620通信的信息。下面是根据一些实施例的、基于界面300-500中选择的数据源的数据库连接属性定义的例子:
<datasource>
<property name=′datasource-name′value=′eFashion_star_big_olbia′/>
<property name=′datasource-description′value=′eFashion_star_big_olbia from SQL
Server 2005 database′/>
<property name=′jdbc-driver-class′
value=′com.microsoft.sqlserver.jdbc.SQLServerDriver′/>
<property name=′connection-url′
value=′jdbc:sqlserver://eii06:1533;databaseName=eFashion_star;user=user1;password=passwo
rd2;′/>
还继续图2至图5的例子,将业务对象与数据库列关联的元数据可以部分显现如下:
<dimension name=″Year″description=″Year description″type=″TEXT″columnName=″Year″
>
<statement tableName=″dates″columnName=″year″fulltext=″false″/>
</dimension>
<dimension name=″Quarter″description=″Quarter description″type=″TEXT″
columnName=″Quarter″>
<statement tableName=″dates″columnName=″quarter″fulltext=″true″/>
</dimension>
<dimension name=″Month″description=″Month description″type=″TEXT″
columnName=″Month″/>
<dimension name=″Store name″description=″Store name description″type=″TEXT″
columnName=″Store_name″>
<statement columnName=″store_name″fulltext=″true″>
<![CDATA[
SELECT
store_name
FROM
stores
WHERE
CONTAINS (store_name,′%CONTAINS%′)
]]>
</statement>
</dimension>
<measure name=″Revenue″description=″Revenue description″type=″NUMERIC″
columnName=″Revenue″aggregationMethod=″SUM″/>
如上所述,该元数据指定了与维度对象关联的关系表格、以及与该维度对象关联的关系表格的一个或多个列名。对于每个量度对象来说,该元数据指定与量度对象关联的关系表格、与该量度对象关联的关系表格的一个或多个列名、以及与该量度对象关联的聚合方法。
信息空间610还包括信息空间SQL语句。该语句可以反映如图5的界面500中所指定的结构。例如:
<statement>
<![CDATA[
SELECT
year AS Year,quarter AS Quarter,month AS Month,store_country AS Store_country,
store_city AS Store_city,store_name AS Store_name,family AS Family,article_label AS
Article_label,quantity_sold AS Quantity_sold,revenue AS Revenue
FROM
facts,dates,stores,products
WHERE
facts.store_id=stores.store_id
AND facts.date_id =dates.date_id
AND facts.product_id =products.product_id
]]>
</statement>
</datasource>
如上所述,该语句可以以具体化的表格(也即,<table name=”table”/>)具体实施。
导航模块630包括用于基于信息空间元数据610的元数据来显示关系数据源620的数据的硬件和/或软件。该数据是通过查询技术640的硬件和/或软件且也是基于信息空间元数据610的元数据得到的。在一些实施例中,导航模块630还可以操作为通过其它数据650的数据来显示及提供导航。其它数据650可以包括诸如在背景技术中描述的索引之类的数据源,可以使用导航模块630的本地(native)数据访问机制来访问其数据。
图7是根据一些实施例的过程700的流程图。过程700可以由导航模块630和查询技术640实现,但是具体实施例不限于此。在这点上,过程700可以以存储在有形的计算机可读介质上的计算机可执行程序代码具体实施。
一开始,在710处,确定表示关系数据库的结构的元数据。例如,可以通过创建元数据来确定,如针对图2-5所述,或者通过访问表示关系数据库的结构且存储在信息空间元数据610中的已创建元数据来确定。
接下来,在720处,基于元数据生成一个或多个结构化查询语言查询。该一个或多个结构化查询语言将用于从关系数据库中检索关系数据库的多个方面(facet)中每个方面的方面值。在这点上,术语“方面(facet)”用于描述特定类别数据,在本例中其对应于维度对象。具体来说,参照本例,年份、商店城市、商店名称和生产线是方面,而2003、休斯顿、e-fashion NewYork和服装是方面值。
一个或多个结构化查询语言查询也将用于从关系数据库中检索多个方面中每个方面的每个方面值的量度的聚合值。量度对应于元数据中指定的量度对象。
根据720的一些实施例,导航模块630向查询技术640请求方面、方面值以及聚合值。然后,查询技术640使用信息空间元数据来生成一个或多个结构化查询语言查询,以从关系数据源620检索出所请求的数据。
例如,查询技术640可以基于上面所示的示例元数据,在720生成下列查询,其中“(...)”代表上述信息空间SQL语句。因为示例包括四个方面,所以查询技术640生成以“SELECT TOP 25”开头的四个查询。
SELECT COUNT(*)FROM(...)AS exploration_space
SELECT TOP 25″exploration_space″.″Lines″AS name,SUM(″exploration_space″.″Quantity_sold″)AS value,COUNT(*)AS count FROM (...)AS exploration_space GROUP BY ″exploration_space″.″Lines“ORDER BY 3DESC,2ASC
SELECT TOP 25″exploration_space″.″Store_name″AS name,SUM(″exploration_space″.″Quantity_sold″)AS value,COUNT(*)AS count FROM (...)AS exploration_space GROUP BY ″exploration_space″.″Store_name”ORDER BY 3DESC,2ASC
SELECT TOP 25″exploration_space″.″Store_city″AS name,SUM(″exploration_space″.″Quantity_sold″)AS value,COUNT(*)AS count FROM (...)ASexploration_space GROUP BY ″exploration_space″.″Store_city“ORDER BY 3DESC,2ASC
SELECT TOP 25″exploration_space″.″Year″AS name,SUM(″exploration_space″.″Quantity_sold″)AS value,COUNT(*)AS count FROM (...)AS exploration_space GROUP BY ″exploration_space″.″Year″ORDER BY 3DESC,2ASC
在720处从关系数据源620检索出的方面将在730用以确定检索出的方面的显示次序。注意,显示次序至少部分地基于关系数据源620的已存储的数据,而非单独基于用户喜好。显示次序可以基于每个方面的优质值(merit value),如前述的美国专利No.7,493,330中所述。如这里所述,方面的优质值基于与方面关联的熵值和作用范围值(coverage value)。
针对数据仓库620的每个方面(也即,类别)计算熵值。一个方面的熵值是基于与该方面关联的不同方面值(也即,特性)的数目以及存储的数据记录的总数目。注意,上面列出的SQL查询导致计算每个方面的熵所需的信息(也即,记录的总数目、每个方面的方面值以及每个方面值的出现的次数)的检索。
然后,针对每个方面确定作用范围值。与方面关联的作用范围值是包括该方面的方面值的总数据记录的百分比。接下来,针对每个方面,将熵值乘以作用范围值,并且将乘积规一化来产生优质值。在730处确定的显示次序可以反映根据降序优质值的方面的次序。一些实施例可以采用其它技术,在730处基于方面值确定显示次序。
在740处,生成以所确定的显示次序显示多个方面的方面值的界面。该界面还以所确定的显示次序与对应的资质值(asset value)相关联地显示与每个方面值对应的每个聚合值。
图8示出根据一些实施例的、用于显示方面值和聚合值的界面800。在一些实施例中,用户访问由导航模块630提供且与关系数据源620关联的网页。作为响应,导航模块630和查询技术根据过程700操作以生成界面800。然后,界面800被发送给用户,以便由Web浏览器显示。任何客户机应用都可以用来显示界面800,而不限于以基于Web的格式。
界面800的区域810以所确定的显示次序显示方面以及它们的方面值。例如,针对每个所显示的方面确定的优质值可以是如下:年份:0.49,商店城市:0.35,商店名称:0.23,生产线:0.18,从而导致显示次序:年份,商店城市,商店名称,生产线。每个方面值都与销售量量度的对应聚合值一起显示。
再有,显示在区域810中的信息可以使用上面列出的SQL查询来确定,所列出的SQL查询又是从信息空间的元数据610确定的。因此,一些实施例可以有效地基于描述SQL数据库的结构的元数据生成一个界面来以可理解方式显示该SQL数据库的存储的数据。
界面800的区域820显示与第一方面(也即,年份)的每个方面值(2001、2002、2003)对应的聚合量度值的图形可视化825。按钮830允许选择图形可视化类型,每个图形可视化类型还显示与每个方面值对应的聚合量度值。可以在过程700的720处通过生成下列SQL查询来检索图形可视化825的数据:
SELECT TOP 25″exploration_space″.″Year″AS Facet,SUM(″exploration_space″.″Quantity_sold″)AS Value0 FROM (...)AS exploration_space GROUPBY ″exploration_space″.″Year″ORDER BY 2DESC,1ASC
SELECT COUNT(DISTINCT(″exploration_space″.″Year″))FROM (...)AS exploration_space
可以在前述SQL查询中引用除了年份之外的任何方面。在一些实施例中,图形可视化对应于显示次序的第一方面。在这些情况中,在过程700的740处确定了显示次序之后生成上述SQL查询。
根据一些实施例,也可以通过导航模块630和查询技术640来执行图9的过程900。可以在过程700的740处生成界面(例如,界面800)之后执行过程900。
在910处接收方面值的选择(例如,通过导航模块630)。方面值的选择可以包括选择显示在界面800的区域810(或区域820)中的方面值。然后,经由已知的用户界面控制技术将选择发送到导航模块630。
响应于方面值的选择,基于表示关系数据库的结构的元数据,在920处生成一个或多个结构化查询语言查询。一个或多个结构化查询语言查询将用于检索每个方面的每个方面值的量度的第二聚合值。通过所选择的方面值来过滤该聚合值。
继续图8的例子,假定用户已经选择了显示在区域810中的方面值“2003”。导航模块630在910处接收该选择,并且作为响应,在920处基于信息空间元数据610生成下列查询:
SELECT COUNT(*)FROM(...)AS exploration_space WHERE ″exploration_space″.″Year″=′2003′
SELECT TOP 25″exploration_space″.″Lines″AS name,SUM(″exploration_space″.″Quantity_sold″)AS value,COUNT(*)AS count FROM (...)AS exploration_space WHERE ″exploration_space″.″Year″=′2003′GROUP BY″exploration_space″.″Lines″ORDER BY 3DESC,2ASC
SELECT TOP 25″exploration_space″.″Store_name″AS name,SUM(″exploration_space″.″Quantity_sold″)AS value,COUNT(*)AS count FROM (...)AS exploration_space WHERE″exploration_space″.″Year″=′2003′GROUP BY″exploration_space″.″Store_name″ORDER BY 3DESC,2ASC
SELECT TOP 25″exploration_space″.″Store_city″AS name,SUM(″exploration_space″.″Quantity_sold″)AS value,COUNT(*)AS count FROM (...)AS exploration_space WHERE″exploration_space″.″Year″=′2003′GROUP BY″exploration_space″.″Store_city″ORDER BY 3DESC,2ASC
SELECT TOP 1′Year′AS facet,″exploration_space″.″Year″AS name,SUM(″exploration_space″.″Quantity_sold″)AS value,COUNT(*)AS count FROM (...)AS exploration_space WHERE″exploration_space″.″Year″=′2003′GROUP BY″exploration_space″.″Year“ORDER BY 3DESC,2ASC
前述SQL查询检索经方面值“2003”过滤的每个方面(除了年份方面之外)的每个方面值的销售量量度的独立的聚合值。在930处生成用于显示与对应的方面值相关联的这些聚合值的界面。
图10的界面1000是根据本例在930处生成的界面的一个例子。如图所示,在区域1010中选择年份2003,并且结果是,区域1010还示出经方面“2003”过滤的商店城市、商店名称和生产线方面的每个方面值的销售量量度的聚合值。在一些实施例中,通过上述SQL查询得到的经过滤的方面值和记录计数将用于先于930确定新的显示次序,并且根据新的显示次序显示这些方面。
界面1000的区域1020显示与第二方面(也即,州)的每个方面值对应的聚合量度值的图形可视化1025。可以通过生成下列SQL查询来检索图形可视化1025的数据:
SELECT TOP 25″exploration_space″.″Store_city″AS Facet,SUM(″exploration_space″.″Quantity_sold″)AS Value0 FROM (...)AS exploration_space WHERE″exploration_space″.″Year″=’2003’GROUP BY″exploration_space″.″Store_city″ORDER BY 2DESC,1ASC
SELECT COUNT(DISTINCT(″exploration_space″.″Store_city″))FROM (...)AS exploration_space WHERE ″exploration_space″.″Year″=′2003′
商店城市方面可以以图形可视化1025表示,因为以区域1010中反映的显示次序,该方面出现在年份方面之后。在一些实施例中,图形可视化1025中表示的第二方面是用户可选择的(也即,图形可视化1025可以显示每个生产线在2003年的聚合销售量)。
图11示出根据一些实施例的、可以由导航模块630和查询技术640执行的过程1100。过程1100可以在过程700的740处生成界面(例如,界面800)之后执行。与基于所选择的方面值过滤所呈现的(presented)量度的聚合值相反,过程1100提供了对于已呈现的方面值的第二量度的聚合值的呈现。因此,过程1100和过程900可以相互结合运用,以便提供对存储在数据源中的数据的有效导航。
在1110处接收第二量度的选择。方面值的选择可以包括选择界面1000的量度条1015中的新量度。响应于第二量度的选择,基于表示本关系数据库的结构的元数据,在1120处生成一个或多个结构化查询语言查询。一个或多个结构化查询语言查询将用于检索每个方面的每个方面值的第二量度的第二聚合值。
继续本例,假定用户已经选择了量度条1015中的收入量度。导航模块630在1120处接收该选择,并且作为响应,基于信息空间元数据610在步骤1120处生成下列查询:
SELECT COUNT(*)FROM(...)AS exploration_space
SELECT TOP 25″exploration_space″.″Lines″AS name,SUM(″exploration_space″.″Revenue″)AS value,COUNT(*)AS count FROM (...)AS exploration_space GROUP BY ″exploration_space″.″Lines“ORDER BY 3DESC,2ASC
SELECT TOP 25″exploration_space″.″Store_name″AS name,SUM(″exploration_space″.″Revenue″)AS value,COUNT(*)AS count FROM (...)AS exploration_space GROUP BY ″exploration_space″.″Store_name”ORDER BY 3DESC,2ASC
SELECT TOP 25″exploration_space″.″Store_city″AS name,SUM(″exploration_space″.″Revenue″)AS value,COUNT(*)AS count FROM (...)AS exploration_space GROUP BY ″exploration_space″.″Store_city“ORDER BY 3DESC,2ASC
SELECT TOP 25″exploration_space″.″Year″AS name,SUM(″exploration_space″.″Revenue″)AS value,COUNT(*)AS count FROM (...)AS exploration_space GROUP BY ″exploration_space″.″Year″ORDER BY 3DESC,2ASC
这些SQL查询检索每个方面的每个方面值的收入量度的聚合值。在本例中,假定信息空间元数据160将收入量度与数据源610的适合表格列关联,将SUM(求和)聚合方法与收入量度关联。
在1130处生成用于显示与对应方面值相关联的这些聚合值的界面。图12的界面1200是根据本例在1130处生成的界面的一个例子。量度条1215指定收入量度,并且区域1210还示出针对年份、商店城市、商店名称和生产线方面的每个方面值的收入量度的聚合值。
由于通过上述SQL查询得到的方面值和记录计数与过程700的例子中查询的一样,因此方面的显示次序也不发生变化。但是,实施例并不局限于此,特别是在使用不同方法来确定显示次序的情况下。
界面1200的区域1220显示与年份方面的每个方面值(也即,2001、2002、2003)对应的聚合量度值的图形可视化1225。实施例并不局限于第一次序排序的方面的图形可视化。可以通过生成下列SQL查询来检索图形可视化1225的数据:
SELECT TOP 25″exploration_space″.″Year″AS Facet,SUM(″exploration_space″.″Revenue″)AS Value0 FROM (...)AS exploration_space GROUP BY ″exploration_space″.″Year“ORDER BY 2DESC,1ASC
SELECT COUNT(DISTINCT(″exploration_space″.″Year″))FROM(...)AS exploration_space
这里所描述的实施例只是为了说明的目的。本领域技术人员将认识到,可以通过对上面所述的进行修改和变更来实践其它实施例。