技术领域
[0003] 本发明一般涉及业务智能,具体而言,涉及通过使用聚集(aggregates)来有效地访问数据。
相关背景技术
[0004] 近年来,业务智能工具被大型商业企业及其他组织机构越来越多地使用。业务智能通过分析组织机构的内部、结构化数据以及业务进程来提供业务操作的当前和历史视图。它常常用于创建未来的模型和预测,以便支持更好的业务决策。如此,业务智能工具可以使得许多公司的成本降低,效率、生产率以及利润率提高。
[0005] 业务智能通常被实现为软件和/或硬件工具,这些工具用于收集和分析数据,并将原始数据转换为用于实现更有效的战略性的、战术性的,以及运营性的洞察和决策的有意义的并且有用的信息。如此,典型的业务智能服务器依赖于可以驻留在各种位置的数据,包括,但不仅限于数据库、储存库、内容管理系统、应用服务器和许多其他源。
[0006] 在典型的业务智能服务器中,从这些源中的全部(或一些)收集数据,并将数据置于(虚拟或物理)数据仓库或数据集市中,在那里,可以对数据进行建模和分析,然后,呈现给用户。创建这样的数据集市可以大大地提高性能。例如,数据集市可以存储聚集表,这些聚集表是跨多个层级存储度量的聚集的物理表。这些聚集表可以被视为预先计算出的结果,这些结果是对一组维度属性聚集(通常是相加的)的度量。这样的聚集的持久性可以通过提供比通过执行完整的查询以收集底层数据来实现的速度更快的对特定数据的访问,来提高查询性能。换言之,通过预先计算并存储所需的聚集,缩短了查询响应时间,因为服务器不再需要在对查询的每一次执行时计算和收集全部结果。
[0007] 然而,在创建和自动化这样的数据集市和聚集时,仍存在许多缺点。手动创建聚集表的任务是繁琐的,通常需要编写复杂的数据定义语言(DDL)和/或数据操作语言(DML)来在涉及的数据库中创建表。另外,这些表还需要被映射到储存库元数据以便对查询可用。这是费时的,也许是易于出错的过程。另外,随着聚集表的数量增大,利用这样的聚集并很好地使用它们变得越来越困难。鉴于这些低效率,所希望的是最大程度地自动化聚集表的创建以及将它们映射到元数据的方式。
具体实施方式
[0016] 本发明的各实施例是作为示例说明的,而不仅限于各个附图的图形,在附图中,类似的参考编号表示类似的元件。在本发明中对各实施例的引用不一定是同一个实施例,而这样的引用意味着至少一个。尽管讨论了特定实现,但是,应该理解,这只是为了说明。那些精通相关技术的人员将认识到,在不偏离本发明的主题的范围和精神的情况下,可以使用其他组件和配置。
[0017] 在下面的描述中,阐述了很多具体细节,以便提供对本发明的详尽的描述。然而,对那些精通本技术的人员显而易见的是,本发明也可以在没有这些具体细节的情况下实施。在其他情况下,没有对已知的特征进行详细描述,以便不至于使本发明变得模糊。
[0018] 根据本发明的各实施例,描述了用于自动化企业内的数据集市和聚集的创建的系统和方法。在多个数据源中维护数据,所述数据源至少包括关系数据库以及多维数据库。系统包括业务智能服务器,该业务智能服务器提供虚拟逻辑语义模型以集成全部多个数据源中。用户通过使用虚拟逻辑语义模型来指定聚集的级别以及度量的列表。聚集包括来自多个数据源中的一个或多个的数据。用户也可以指定多个数据源中的将存储聚集矩阵的位置。一旦接收到用于创建聚集的输入,业务智能服务器就自动地创建多维数据集(cube)以存储聚集的数据并将多维数据集存储在由用户所指定的数据源位置处。
[0019] 图1是根据本发明的各实施例的数据集市自动化的图示。虽然此图将组件描绘为在逻辑上分离的,但是,这样的描绘只是为了说明。对本领域的技术人员显而易见的是,此图形中所描绘的组件可以被组合或分成单独的软件、固件和/或硬件。此外,对本领域的技术人员还显而易见的是,这样的组件,不管它们如何组合或分离,都可以在同一个计算设备上执行,或者也可以在通过一个或多个网络或其他合适的通信手段连接的不同的计算设备之间分布。
[0020] 根据各实施例,企业数据存储在多个不同的物理数据源中,这些物理数据源可包括关系数据库104、多维数据库管理系统(例如,Oracle Essbase 106)、在线分析处理工具(例如,Oracle AnalyticWorkspace 108)及其他数据源110。根据一个实施例,业务智能(BI)服务器102提供了用于跨企业的多个数据源为数据定义语义模型112的基础。此单个逻辑模型112可以适应企业的所有数据源。这可以通过提供呈现给用户的表示层来实现,该表示层被映射到直接建模数据源中的实体的物理层。如此,给用户提供了数据的一个逻辑视图,BI服务器将此视图映射到相应的源的每一个物理模型。
[0021] 根据各实施例,业务智能服务器可以使用聚集持久性来改善对多个数据源中的数据的访问。在一个实施例中,用户(例如,管理员)可以指定需要跨多个数据源聚集的度量以及级别。例如,用户100可以使用虚拟语义模型来定义聚集矩阵114。此聚集矩阵可以跨多个数据源将信息拉到一起。由于级别和度量是使用BI服务器的虚拟语义模型指定的,因此,可以使特定聚集横跨多个数据源这一事实对用户透明。换言之,BI服务器可以考虑所有适当的数据映射,且用户不需要指定(或知道)哪条数据驻留在哪个数据源中。
[0022] 根据一个实施例,在指定聚集的级别和度量时,用户还可以指定多个数据源之一中聚合数据将物理地存储的位置。
[0023] 一旦使用虚拟模型指定了级别和度量的列表,BI服务器就可以自动地生成包含聚集矩阵中所定义的数据的多维数据集并利用数据集来填充指定的数据源。根据一个实施例,BI服务器创建元数据、关系维度和数据集,并将该数据集存储在该位置中指定的数据源中。
[0024] 图2示出了根据本发明的各实施例的创建聚合体的典型的使用情况。虽然此图将组件描绘为在逻辑上分离的,但是,这样的描绘只是为了说明。对本领域的技术人员显而易见的是,此图形中所描绘的组件可以被组合或分成单独的软件、固件和/或硬件。此外,对本领域的技术人员还显而易见的是,这样的组件,不管它们如何组合或分离,都可以在同一个计算设备上执行,或者也可以在通过一个或多个网络或其他合适的通信手段连接的不同的计算设备之间分布。
[0025] 如图所示,储存库的管理员200登录并向实况分析服务器(例如,业务智能服务器)发出聚集创建请求。此过程可以根据需要通过外部装置(例如,使用批处理文件和Windows调度器)来自动化和调度。根据某些实施例,向分级分析服务器执行此聚集创建并测试一段时间,然后,移到生产系统中是有利的。
[0026] 在所示出的示例中,在每月的第一天运行提取、转换和加载(ETL)206过程。假设除新聚集添加以外没有元数据改变,通过删除系统所生成的聚集210(储存库文件包含表示分析模型的元数据),储存库文件208被带回其原始状态(201)。然后,管理员可以:
[0027] a.创建预先定义的聚集;
[0028] b.删除旧的聚集并用新聚集替换它们;或
[0029] c.将新聚集附加到现有的聚集中。
[0030] 根据一个实施例,翻译器组件202接收来自管理员200的输入,并创建适当的元数据,将结构化查询语言(SQL)语句提交到执行引擎204,以填充该聚集。根据一个实施例,执行引擎创建包含该聚集的多维数据集,并将聚集存储在指定的数据存储中。
[0031] 根据一个实施例,为创建聚集,业务智能服务器可以执行下列步骤:
[0032] ●为每一个级别创建单个聚集表(在BI服务器的物理层中以及在数据库中)。
[0033] ○此级别聚集表在该级别以及维度层次结构中的更高的所有级别中将包含列。
[0034] ○表键被设置为级别主键。
[0035] ●为每一个事实表创建单个聚集表(BI服务器和数据库)。
[0036] ●为输入请求中所指定的所有事实列创建单个聚集表(BI服务器和数据库)。
[0037] ●对于聚集事实表:
[0038] ○聚集列包括来自指定的级别中的主键的列。这些被设置为外部键(与对应的级别表中的主键结合)。
[0039] ○如果指定了整个事实表,则来自该事实表的键列不被包括为聚集表中的列。
[0040] ●在物理层中的级别表和聚集事实表之间创建外部键关系/联接。
[0041] ●填充数据库中的新创建的聚集表。
[0042] ●为创建的聚集表中的每一个创建并添加对应的逻辑表源。
[0043] ○为每一个逻辑表源指定聚集内容。
[0044] ●登记新创建的元数据对象。
[0045] 应该注意,提供上面步骤的列表纯粹是为了说明,并不旨在对此处所描述的所有实施例作出限制。对本领域的技术人员显而易见的是,可以通过服务器来实现其他步骤以在本发明的范围内执行聚集的创建。
[0046] 图3是根据本发明的各实施例的标识用于聚合的候选的图示。更具体而言,该示例示出了在推荐聚集时使用情况跟踪的使用。根据一个实施例,可以使用跟踪日志来记录分析储存库和各种查询的运行时间。然后,管理员可以使用此跟踪日志来标识哪些查询导致性能的瓶颈(产生比典型的响应时间慢的响应时间)并可能为那些查询创建聚集。
[0047] 如图所示,突出显示的查询(select"Fact-Purchase CycleLines"."Received Quantity","Time"."Year"from"Sourcing-Purchase Cycle Lines”)是最慢的,大约要花30秒来运行。根据一个实施例,为“Year”级别中的“Received Quantity”创建聚集将大大地有益于此查询。在为此查询创建聚集之后,该查询的运行时间将大大地缩短(例如,2秒)。
[0048] 图4是根据本发明的各实施例的标识用于聚集的候选的替换的图示。更具体而言,分析长时间运行的查询的另一种方式是分析生成的物理SQL语句。在此说明中,查询大约要花9分钟(543秒)来运行,因为它被分裂为四个单独的子查询。这些子查询中的最长的(ID:189425)要花506秒来执行。因此,为级别“Year”中的“AR_GRP_AMT”创建聚集将大大地缩短总的查询时间。根据一个实施例,可以通过使用类似于下列语句的语句来创建此聚集:
[0049]
[0050] 根据一个实施例,此聚集的创建缩短了子查询的运行时,因此缩短了查询的总时间。根据各实施例,也可以聚集第四子查询(ID:189350)(要花178秒)以及如图4所示的其他子查询的事实表。
[0051] 图5是根据本发明的各实施例的使用聚合持久性来自动化数据集市的创建的流程图。虽然此图形为了说明按特定顺序描绘功能步骤,但是,该过程不一定仅限于此特定顺序或步骤。所属领域技术人员将理解,此图形中所描绘的各个步骤可以被改变,重新排列,并行地执行或以各种方式修改。此外,还可以理解,在不偏离本发明的精神和范围的情况下,可以在此过程中添加或省略某些步骤或步骤序列。
[0052] 如步骤500所示,企业通常在各种不同的数据源中维护数据。这些数据源可包括关系数据库、多维数据库管理系统(MDBMS)、在线分析处理(OLAP)工具等等。根据一个实施例,BI服务器提供包括所有多个数据源的单个虚拟语义模型(步骤502)。
[0053] 在步骤504中,用户使用虚拟语义模型,指定横跨多个数据源中的一个或多个的聚集的级别的列表。可任选地,用户也可以提供度量的列表。另外,用户指定其中将存储聚集的目标数据源(步骤506)。根据一个实施例,此指定的目标数据存储是多个数据源中的一个。
[0054] 在步骤508中,业务智能服务器创建多维数据集以存储聚集的数据,并将多维数据集存储在指定的数据源中。根据一个实施例,这可以通过使用数据存储的应用编程接口(API)在目标存储中创建元数据、物理表,或通过生成适当的SQL语句以针对数据存储运行来执行。
[0055] 图6是根据本发明的各实施例的使用聚集持久性来自动化数据集市的创建的流程图。虽然此图形为了说明按特定顺序描绘功能步骤,但是,该过程不一定仅限于此特定顺序或步骤。所属领域技术人员将理解,此图形中所描绘的各个步骤可以被改变、重新排列、并行地执行或以各种方式修改。此外,还可以理解,在不偏离本发明的精神和范围的情况下,可以在此过程中添加或省略某些步骤或步骤序列。
[0056] 如步骤600所示,用户首先指定用于聚集的度量和级别。在一个实施例中,这是使用BI服务器上的虚拟模型来执行的。在步骤602中,BI服务器为底层多维数据库的维度和数据集创建元数据。接下来,在步骤604中,BI服务器为级别属性创建关系维度。一旦此完成,BI服务器可以基于来自关系维度的键,为底层数据源(例如,Essbase)创建维度,如步骤606所示。在步骤608中,BI服务器基于来自关系维度的键创建多维数据集,并将数据集存储在指定的目标数据源中。
[0057] 在本发明中所描述的各种上下文中,本发明的各实施例进一步包含被配置成执行前述的系统和方法的计算机设备、计算系统以及机器可读取的介质。对那些精通计算机技术的人显而易见的是,除包括专门设计的集成电路或其他电子器件的实施例之外,本发明还可以方便地使用常规的通用数字计算机或微处理器或根据本发明的原理编程的专门数字计算机或微处理器来方便地实现。
[0058] 对于那些精通软件技术的人来说显而易见的是,可以由熟练的程序员基于本发明的原理轻松地编制适当的软件代码。对本领域的技术人员显而易见的是,本发明还可以通过制造专用集成电路或通过互连常规组件电路的适当的网络来实现。
[0059] 各实施例包括计算机程序产品,该计算机程序产品是在其上存储了指令的存储介质,可以被用来编程通用或专门计算处理器/设备,以执行此处呈现的特征中的任何一个。存储介质可以包括,但不仅限于,下列各项中的一项或多项:任何类型的物理介质,包括软盘、光盘、DVD、CD-ROM、微驱动、磁光盘、全息存储器、ROM、RAM、PRAM、EPROM、EEPROM、DRAM、VRAM、FLASH存储器设备、磁卡或光卡,纳米系统(包括分子存储器IC);适于存储指令和/或信息的任何类型的介质或设备。计算机程序产品可以完全地或部分地通过一个或多个公共和/或私用网络传输,其中,传输包括可以被一个或多个处理器用来执行此处呈现的特征中的任何一个的指令。在各实施例中,传输可包括多个单独的传输。在一个实施例中,计算机可读存储介质是非瞬时的。
[0060] 前面的对本发明的优选实施例的描述只是为了说明和描述。它不是详尽的说明或将本发明限于所公开的准确的形式。那些本领域技术人员可以认识到,可以进行许多修改和变更。所选择和描述的实施例只是为了最好地说明本发明的原理以及其实际应用,并使精通相关领域的其他技术人员理解本发明。