报告OLTP数据的无ETL零冗余系统和方法

暂无

报告OLTP数据的无ETL零冗余系统和方法\n[0001] 相关申请交叉参考\n[0002] 本申请要求于2007年9月21日递交的标题为“报告OLTP数据的无ETL零冗余系统和方法”的美国临时申请第60/994,893号的优先权，其全部内容通过引用结合于此。\n技术领域\n[0003] 本发明涉及数据库系统，具体地，涉及事务型数据库系统和报告型数据库系统。\n背景技术\n[0004] 除非本文另有说明，在本部分所述的方法不是本申请中的权利要求的现有技术，并不因为包含在本部分中就承认其是现有技术。\n[0005] 商务智能(BI)系统为公司提供了对其数据进行收集、分析和访问的广泛功能。从公司内多个异构源和可能的附加外部源收集数据，以创建作为综合知识库并用于高效报告的集成数据集。\n[0006] 当前技术中BI系统的体系结构依靠集中式数据仓库(DW)或多个非集中式数据集市(data mart)来存储集成的数据集。从事务型系统收集数据并将其传输到专用存储器的过程称为抽取、转换和加载(ETL)。“它是迄今为止在任何BI项目中要设计和开发的最复杂的处理。”[见L.T.Moss和S.Atre，“商务智能路标：决策支持应用的完整项目生命周期”(Business Intelligence Roadmap：TheComplete Project Lifecycle for Decision-Support Applications)第229页(Addison-Wesley，2003).]根据Ankorion，传统地，基于每周一次或每月一次定期地运行ETL处理。[见I.Ankorion，改变数据捕获——用于实时BI的高效ETL(Change Data Capture-EfficientETL for Real-Time BI)，DM评论杂志(DM Review Magazine)(2005年1月)。]ETL处理通常在低系统负载窗口期间作为批量作业来运行，因为只可能在低质量下可用的转换和清理数据占用大量的资源。这意味着BI系统中的数据并非总是最新的，这可能对公司造成必须实时对问题作出反应的难题(例如，在银行业务中)。\n[0007] 参考Liang和Yu的文章，只需将所关心的数据复制到BI系统中，而不必将所有的数据复制到BI系统中。[见W.Liang和J.X.Yu，再访问数据仓库中的视图维护(Revisit on View Maintenance inData Warehouse)，第二届Web时代信息管理进展国际会议会刊(Proceedings of the Second International Conference on Advances inWeb-Age Information Management) 第 203-211 页，(Springer-Verlag，伦 敦，英国，2001)。]此外，通常地聚集数据以实现更高的数据访问性能。[见K.Becker和D.D.A.Ruiz的“用于多个实际数据仓库的聚集识别重定位算法(An Aggregate-Aware RetargetingAlgorithm for Multiple Fact data Warehouse)”，在Yahiko Kambayashi和Mukesh K.Mohania(Wolfram ，编辑)，DaWaK，计算机科学讲义(Lecture Notes in Computer Science)(LNCS)第3181卷第118-128页(Springer-Verlag，西班牙，2004年9月)。]在这种情况下，聚集级别必须预先确定。这导致某些问题。首先，可能对没有复制到BI系统中的信息进行查询。其次，系统可能无法为报告产生在限定聚集级别时没有预见到的某一级别的细节。在这种情况下，由于未完成知识库，ad-hoc报告(由用户自己创建和定制的特定报告)并非完全可能，而只是源系统中存储的数据的经过滤的形式。\n[0008] 虽然OLTP(在线事务型处理)系统存储最新的数据，由于性能的原因，在这些系统上的有效报告仍是不可行的。OLAP(在线分析处理)系统提供高级的报告功能，但通常不使用最新的数据：通用报告体系结构依赖于在低系统负载期间以批量作业的方式将OLTP数据复制到读-优化的数据结构中的复杂的、资源密集型ETL(抽取，转换和加载)处理。\n发明内容\n[0009] 本发明的实施例涉及执行处理事务型和报告型数据库信息的计算机程序的计算机系统以及相应的方法。\n[0010] 根据本发明的实施例的计算机系统执行处理事务型和报告型数据库信息的计算机程序。所述计算机程序包括以行格式存储所述数据库信息的关系数据库管理系统组件和以列格式存储所述数据库信息的列取向数据处理组件。\n[0011] 响应于数据库更新请求，所述关系数据库管理系统组件更新以所述行格式存储的所述数据库信息，所述关系数据库管理系统组件向所述列取向数据处理组件通知所述数据库更新请求，并且所述列取向数据处理组件更新以所述列格式存储的所述数据库信息。\n[0012] 此外，响应于查询请求，所述列取向数据处理组件基于以所述列格式存储的所述数据库信息生成查询响应。\n[0013] 在从属权利要求中限定根据本发明的计算机系统的优选实施例。\n[0014] 本发明的实施例还涉及处理事务型和报告型数据库信息的计算机执行的方法，包括以下步骤：以行格式存储所述数据库信息，以列格式存储所述数据库信息，响应于数据库更新请求，更新以所述行格式存储的所述数据库信息，锁定以所述行格式存储的所述数据库信息，更新以所述列格式存储的所述数据库信息，以及在更新以所述列格式存储的所述数据库信息之后解锁以所述行格式存储的所述数据库信息，以及响应于查询请求，基于以所述列格式存储的所述数据库信息生成查询响应。\n[0015] 在另外的实施例中，本发明涉及执行处理事务型和报告型数据库信息的计算机程序的计算机系统，其中，所述计算机程序包括以行格式存储所述数据库信息的关系数据库管理系统组件以及实施列取向数据处理组件的多个联网的计算机，列取向数据处理组件遍及所述多个联网的计算机以列格式存储所述数据库信息。\n[0016] 响应于数据库更新要求，所述关系数据库管理系统组件更新以所述行格式存储的所述数据库信息，所述关系数据库管理系统组件向所述列取向数据处理组件通知所述数据库更新请求，并且所述列取向数据处理组件更新以列格式存储的所述数据库信息。\n[0017] 此外，响应于查询请求，所述列取向数据处理组件基于以所述列格式存储的所述数据库信息生成查询响应。\n[0018] 本发明的实施例一个特征是消除了OLTP(在线事务型处理)系统和OLAP(在线分析型处理)系统之间的传统分裂。\n[0019] 本发明的实施例的另一个特征是消除了抽取、转换、以及加载(ETL)程序。\n[0020] 本发明的实施例的另一个特征是可对最新的数据执行报告。\n[0021] 本发明的实施例的另一个特征是，与传统的分离的OLTP和OLAP系统相比，编程代码的数量以及专用于代码维护的工作量减少了。\n[0022] 本发明的实施例针对一种用于基于OLTP数据进行报告的体系结构，其保留了OLAP系统的短响应时间。为此，通常在ETL期间执行的数据转换在列取向的主存储器数据库中在查询运行时执行。与传统的报告体系结构相比，一个优点是可以提供最新的数据，并不再需要附加的OLAP数据存储。该体系结构通过基于SAP的ERP(企业资源规划)和DW(数据仓库)产品的原型实施得到验证。介绍了来自财务会计领域的使用案例研究，并且使用案例研究用于将我们的原型性能与现有的产品作比较。\n[0023] 下面的详细描述和附图提供了对本发明的性质和优点的更好的理解。\n附图说明\n[0024] 图1是根据本发明的一个实施例的数据库系统的框图；\n[0025] 图2是根据本发明的一个实施例的数据库系统的框图；\n[0026] 图3示出了行取向与列取向的数据存储的实例；\n[0027] 图4示出了水平分段存储和垂直分段存储的实例；\n[0028] 图5示出了根据本发明的一个实施例的数据库系统；\n[0029] 图6示出了根据本发明的一个实施例的数据库系统；\n[0030] 图7示出了根据本发明的一个实施例的数据库系统；\n[0031] 图8示出了根据本发明的一个实施例的数据库系统；\n[0032] 图9是根据本发明的一个实施例的数据处理方法的流程图；\n[0033] 图10是用于实施本发明实施例的计算机系统和网络的实例的框图。\n具体实施方式\n[0034] 本文描述的是用于金融数据的实时报告的技术。在下面的描述中，为了解释的目的，描述了多个实例和具体细节以提供对本发明的透彻理解。然而，很显然，对本领域的技术人员来说，由权利要求所限定的本发明可以单独地包括这些实例中的一些或全部特征，或与以下描述的其他特征相结合，还可以包括本文描述的特征和构思的修改和等同物。\n[0035] 本发明提出了一种体系结构，其基于与列取向数据结构相结合的主存储器技术的使用。在该体系结构中，促进了数据检索和数据插入的性能，所以分析型系统和事务型系统可以对同一数据集起作用。本发明的一个实施例的目标在于，省略在分析型系统和事务型系统之间的数据复制。作为前一种ETL处理的一部分的用于报告的转换的具体步骤在其运行时间实时(on-the-fly)执行。为这两种情况只保留一个数据集产生的好处在于，完整的公司数据集是可用的并可用于报告。\n[0036] 相关工作\n[0037] 本发明的实施例引入了一种用于报告的新的、具有实时能力的体系结构。因此，理解现有DW体系结构是有帮助的。因此，将简要地描述这些现有DW体系结构。接下来，将讨论允许对事务型数据进行报告的现有体系结构。\n[0038] 普通数据仓库体系结构\n[0039] 下面描述DW系统的总体体系结构。DW系统的Inmon特性，即，数据仓库中的数据必须是面向主题的、集成的、时变的(timevariant)、以及稳定的(non-volatile)[Inmon，建立数据仓库(Buildingthe Data Warehouse)，第三版。John Wiley & Sons有限公司，纽约，NY，美国，2002，第31页]，导致将操作数据和分析数据分离的体系结构。根据关系模型(由Codd限定[大型共享数据库的关系数据模型(A Relational Model of Data for Large Shared Data Banks)。ACM通讯，13：377-387，1970年6月])，组织在线事务型处理(OLTP)系统中的数据，即，数据是高度标准化的以确保一致性以及对这些系统进行日常操作。与此相反，OLAP系统根据维度模型(dimensional model)来组织数据，例如使用星型或雪花型模式。这样做的原因主要是希望达到最佳的查询性能。既然OLAP系统是只读的，由于数据一致性没有OLTP系统中的重要，那么非规范化(denormalize)的数据存储是容许的。\n[0040] 这导致了如下的体系结构。DW包括从各OLTP源将数据抽取到中转区(staging area)的ETL处理器，在中转区中进行用于清理和集成的数据转换。一旦完成了这个过程，ETL处理器就根据维度数据存储范例(paradigm)存储数据，从而OLAP引擎可以针对此维度数据存储进行查询。\n[0041] 随着BI技术的发展，诸如数据集市或可操作数据存储(ODS)的概念已经扩展了这个通用的体系结构。数据集市旨在分散DW以优化某些主题区域周围的性能[W.H.Inmon。\n建立数据仓库(Buildingthe Data Warehouse)，第3版。John Wiley & Sons有限公司，纽约，NY，美国，2002]。缺点是，在数据集市的体系结构中，DW不再提供关于企业中的所有相关数据的一个一致性视图，这正是DW系统的原本目的。ODS储存OLTP数据，但是使用集成的数据模式；即，在将数据移入ODS之前应用数据映射和清理的ETL的步骤。结果是增加了可以对其完成报告的数据的及时性。这导致了将类似的特征包括进传统的DW系统中，使OLTP和OLAP系统之间的边界变得模糊。下面，我们将关注用于报告OLTP数据的相关体系结构。\n[0042] 减少延迟的报告体系结构\n[0043] 如上所述，ETL处理是在DW体系结构中连接(断开)OLTP和OLAP系统的点。一种可能的优化可以是将ETL运行之间的时间间隔缩短到最小。这种微批处理(microbatch)的方法的主要缺点[J.Adzic，V.Fiore，和S.Spelta.数据仓库总数平台(Data WarehousePopulation Platform)。计算机科学讲义(LNCS)，2209，2001]是频繁的ETL运行的资源消耗：ETL处理应只在一个限定的批处理窗口中运行，因为DW的查询性能在处理时间中受到显著的影响。\n[0044] 为了实现对事务型数据的实时报告，数据转换必须在查询运行时间完成。因此，提出了将数据转换移出ETL处理的体系结构。相反，在抽取和加载之后在仓库中完成转换。这种处理分别称为ETL[L.Moss和A.Adelman。数据仓库方法论(Data WarehouseMethodology)。数据仓库期刊(Journal of Data Warehousing)，5：23-31，\n2000]。此外，为了用商务或数据库事务层次上的Δ处理取代主体处理，提出了ETL的推进(push)体系结构，参阅[R.kimball和J.Caserta。数据仓库的ETL工具(Data Warehouse ETL Toolkit)：实用抽取、清理技术(Practical Techniques for Extracting，Cleaning)。\nJohn Wiley & Sons Inc.，纽约，NY，美国，2004年，第427]。Kimball还建议将数据仓库中的历史数据与近期的数据分离。近期的数据不断复制到使用上述推进方法的所谓的实时部分。这样做仍然可以对DW进行优化用于历史数据的查询，同时企业中的近期事件也记录在仓库中。Brobst建议以影响(leverage)上述ETL推进体系结构的方式，扩展典型的消息代理器的基础设施。[S.Brobst企业应用集成和主动数据仓库(Enterprise Application Integration and Active DataWarehousing)。数据仓库会刊(Processings of Data Warehousing)2002，15-23页，海德堡，德国，2000。Physica-Verlag有限责任公司]。这通过使DW适配器钩在消息总线中来完成，其中消息总线订阅与仓库中的数据有关的消息。以上还介绍了，与ELT的构思相似，在数据仓库中完成必要的数据转换。虽然所提出的方法比传统的、面向批处理的ETL体系结构具有更低的数据捕获延迟，但是OLTP系统中的变化仍必须传播到DW，此处，使用维度数据模型协调并冗余地存储上述变化。为了在报告中具有关于企业的实时视图，必须将OLTP和OLAP系统之间的复制减少到最小。\n[0045] 虚拟ODS的概念，与上述传统的、物理的ODS相反，描述了在查询运行时间收集所请求的信息的拉引导向(pull-oriented)的DW体系结构。ODS是虚拟的，意味着它将DW查询转换成对OLTP或第三方系统的下游查询，而不持续存储(persist)任何数据。Inmon认为，当源系统中的数据没有集成时，虚拟ODS体系结构具有有限的用途[W.H.Inmon。\n信息管理(Information Management)：世界级的商业智能(World-Class Business Intelligence)。DM评论杂志(DM Review Magazine)，2000年3月]。这是因为虚拟ODS系统在运行时间不提供ETL转换的事实，这对提供数据集成将是必要的。原因是ETL转换成本高，因此，存在虚拟ODS功能范围与终端用户响应时间之间的折中。然而，虚拟ODS是最接近事务型数据的报告方法的构思。\n[0046] 对OLTP数据的高性能报告\n[0047] 图1是根据本发明的实施例的数据库系统100的框图。使用基本建模概念(FMC)的框图符号[A. 、B. 和P.Tabeling。基本建模概念(Fundamental \nModeling Concept)：IT系统的高效通信(Effective Communication of IT Systems)。\nJohn Wiley & Sons，Inc.，2006年5月]。图1的实施例引入了用于报告的体系结构，其中，数据没有存储在除事务型系统以外的任何其他系统中。因此，没有发生至DW系统的复制，但当查询数据时，直接在事务型系统中访问数据。\n[0048] 数据库系统100包括分析引擎102、虚拟立方体104、主存储器数据库106以及数据存储108。数据存储108包括平面数据文件、OLTP数据、多维数据以及其他数据。分析引擎102和虚拟立方体104是商业智能系统的组件，而主存储器数据库106和数据存储108是操作系统的组件。\n[0049] 作为基础，数据库系统100使用主存储器数据库106访问所有数据。使用主存储器技术以提供直接对事务型数据进行报告的短的响应时间是根据本发明的实施例的解决方案的一个方面。另一方面是使用提供了快速读取访问和高效写入访问的数据结构。\n[0050] 实时数据转换\n[0051] 分析引擎102通过虚拟立方体104访问数据。虚拟立方体104在DW系统中可提供与由标准立方体给定的接口相同的接口用于分析。这包括各层级(hierarchy)的层次之间的钻取(drilling)以及关于不同度量的切片和取舍(slicing and dicing)。在根据本发明的实施例的实施中，虚拟立方体104插入SAP BI的OLAP引擎。因此，由SAP BI支持的所有报告前端可以用于发起对OLTP数据的查询。可用的前端包括HTML报告和微软基于Excel的报告。在SAP BI的情况下，预定的查询可以在这些报告前端内部运行。这些查询可以通过图形化地指定(使用查询设计工具)或者使用多维表达式(MDX)指定[见]。\n[0052] 与DW系统中的传统立方体相比，虚拟立方体104不存储任何数据。相反，虚拟立方体104是在报告的运行时间过程中执行的函数(function)的集合。虚拟立方体104将其暴露的报告接口映射到针对包含OLTP数据的下面的主存储器数据库106的调用中。查询被发送到OLAP引擎(分析引擎102)，其然后对虚拟立方体104执行OLAP查询。虚拟立方体104将输入的OLAP查询转换为对具有OLTP数据的主存储器数据库106的查询。由于直接将OLTP数据提供给OLAP引擎(分析引擎102)，所以由报告查询的数据总是最新的。\n虚拟立方体104可包括虚拟立方体接口组件，其将在线分析处理查询映射到聚集调用并将聚集调用作为查询请求发送到列取向的数据处理组件。\n[0053] 由于在主存储器数据库106中的OLTP数据可能位于最高的粒度层次，这意味着数据不包含聚集(aggregate)，虚拟立方体104将多数的OLAP查询映射到对主存储器106的聚集调用中。因此，实时创建层级中的特定层次所需要的聚集。不需要进一步的总数(totals)的存储，并且避免了预先计算每个可能的聚集值并将其存储在(虚拟立方体104的)立方体结构中的数据爆炸问题。\n[0054] 在案例研究的性能评估期间(其将在下面详细表述)，遇到了基于一千万行式项目(line items)创建的500,000总数。1总数与20行式项目的比率似乎是不够的(inefficient)。正如将在后面讨论的，粒度，例如，对于创建资产负债表报告(balance sheet report)来说，太高了：其中，之后仍然不得不在源代码中聚集从数据库中读取的总数。精确地读取报告所需的总数、而没有进一步的计算和访问数据库中的多字段，这一原始想法在这里没有满足。因而对于存储空间和更新性能来说，低比率是不够的。如果数据插入或更新，多种总数必须也更新，这通常发生在财务核算中的同一数据库事务中，以保持一致的视图。结果，实际的数据库事务被拖延，在行层次锁定的情况下，许多行为了写入访问而被排他地锁定。未存储任何总数减少了管理开销，此外，加速了行式项目写入访问的数据库事务。\n[0055] 财务数据的只插入特性\n[0056] 到目前为止，已讨论了具有用于OLTP和OLAP应用的两个物理地分离的数据存储的缺点。然而，将数据从操作系统复制到DW系统的重大好处是OLAP和OLTP操作不竞争数据的单个副本上的资源(即，锁)；由于OLAP操作通常触及大量的数据，所以这种争用(contention)通常是显著的。如果数据没有预先聚集在单独的副本中，且如果需要OLTP事务的ACID(原子性，一致性，隔离性，持久性)特性(其对财务数据来说尤其重要)，情况尤其如此。将数据拷贝到DW的另一个好处是许多报告考虑到历史，即，数据随时间的变化。\nOLTP数据通常只表示数据的最近的一致的快照。\n[0057] 在OLTP数据之上操作的报告方法必须处理争用和历史问题。以下将描述如何通过使用财务数据的只插入特性解决这两个问题。\n[0058] 财务核算(其是各种OLTP系统的主要目的)是要求记录数据的每个变化的活动。\n例如，如果固定资产的价值由于折旧原因必须调整，那么价值不更新；相反，创建将扣除资金从一个帐户移动到另一个帐户的纠正过账(correctional posting)。过账将作为固定资产账户的新行出现在记账员的日志中，表明存在特定值的扣除，以及存在增加了该值的折旧账户中的另一个新行。从数据库的角度来看，数据被读取或插入。更新和删除操作在这种模式下是不允许的，因为“会计师不使用橡皮”，如Pat Helland最近提出的[见]。因此不再需要数据库锁。在OLTP系统的正常操作中，用于OLTP数据的只插入数据模型与使用主存储数据库106作为对该数据的唯一持久存储的结合允许在OLTP数据之上的短响应时间的直接报告。诸如谷歌的Bigtable瞬时数据库(temporaldatabases)[F.Chang，J.Dean，S.Ghemawat，W.C.Hsieh，D.A.Wallach，M.Burrows，T.Chandra，A.Fikes，和R.E.Gruber.Bigtable：结构化数据的分布式存储系统(A Distributed StorageSystem for Structured Data)。在USENIX′06中：操作系统设计和实现的USENIX研讨会的第th\n七届会议会刊(Proceedings of the 7 conference on USENIX Symposium on Operation Systems Design andImplementation)，第15-15页，伯克利，CA，美国，2006年。USENIX协会(USENIX Association)]，例如，为只插入数据模型提供固有支持，因为它们将字段的更新视为与时间戳相关联的插入操作。\n[0059] 如上所述，本发明的实施例略微可与虚拟ODS相比较，其中，对OLTP系统重定向DW查询，而不物理地持续存储任何数据。与本发明的实施例相比，虚拟ODS是直接访问快照OLTP数据的构思，即，不考虑历史数据。由于如上所述用于OLTP的只插入数据模型，所以本发明的实施例固有地支持历史数据的报告：由于为每个帐户保持只添加(append-only)日志(journal)，所以不丢失先前的帐户值，但可以重建。\n[0060] 一种用于所有情况的数据存储\n[0061] 整个数据集可保存在主存储器106中以确保短响应时间。根据Yu[C.\nYu。高维度索引(High-Dimensional Indexing)：高维度范围和相似性搜索的转换方 法 (Transformational Approaches toHigh-Dimensional Range and Similarity Searches)，卷2341/2002。Springer-Verlag New York，Inc.，Secaucus，NJ，美国，2002，第137页]由于主存储器变得越来越便宜而且越来越大，所以数据库太大以至于无法适合于主存储器106的假设受到越来越多的挑战。另一方面，Gantz等[J.F.Gantz等。扩张的数字宇宙：对2010年全球信息增长的预测(Expanding Digital Universe：A Forecast ofworldwide Information Growth Through 2010)。IDC白皮书(IDCWhite Paper)-由EMC赞助，，March2007]认为在未来的几年中全球的组织将因他们所称的“信息爆炸”而蒙受损害。在2007年，已创建了更多的信息，但没有可存储该信息的足够能力。然而，产生爆炸的95％的信息是非结构化数据，如音乐、照片、视频、数字电话和电视、传感器数据或电子邮件。\n[0062] 对中等规模公司的过去5年的财务事务型数据进行了分析。公司数据的大小在文件系统中约为20GB的空间。在将其转换为主存储器数据库106的数据结构并对其压缩之后，其大小约为1GB。因此，至少对中小型公司来说，将整个事务型数据集完整地保存在主存储器是可行的。\n[0063] SAP的文本检索和信息抽取引擎(TREX)用于实现主存储器存储系统106。TREX最初被开发为用于对非结构化数据进行索引和检索的文本搜索引擎。根据本发明的实施例的解决方案暗示将TREX用作完备的(fully fledged)主存储器数据库。然而，TREX还没有完全支持ACID(原子性，一致性，隔离性，持久性)特性，然而这是事务型情况的先决条件。\n因此，将TREX与传统的关系数据库管理系统(RDBMS)相结合。图2示出TREX如何与MaxDB集成以及如何在TREX和MaxDB之间分配读取和写入访问。\n[0064] 图2是根据本发明的实施例的数据库系统200的框图。数据库系统200包括OLTP(和/或OLAP)系统202、关系数据库管理系统204(也称为MaxDB RDBMS，作为RDBMS \n204的具体实施)、列取向数据处理系统206(也称为TREX组件，作为CODPS 206的具体实施)、以及文件系统208。OLTP系统202经由DB更新220与RDBMS 204进行交互。OLTP系统202经由查询222与CODPS206进行交互。RDBMS 204经由Δ更新访问224与CODPS 206进行交互。CODPS 206经由持久数据访问226与RDBMS 204进行交互。\n[0065] MaxDB 204处理改变数据或插入新数据的请求，其确保ACID特性。MaxDB 204包括数据库内核212(在此具体实施中，也称为MaxDB内核)、数据库表214、以及索引对象的队列216(在数据库表中)。该数据库内核212与文件系统208进行交互。MaxDB内核212在数据库表214中存储该变化并管理TREX 206的队列表(在队列216中)。这些队列表\n216包含信息(其数据已经被改变或插入)。TREX 206被通知这些变化，并能够在队列表\n216的帮助下更新其自己的数据。这发生在同一数据库事务中。因此，TREX 206和MaxDB \n204共享数据的一致视图。\n[0066] 作为回报，TREX 206直接处理数据库查询和分析报告(注意查询222)。CODPS 206包括内核232(在此具体实施中，也称为TREX内核)、主索引234以及Δ索引236。TREX \n206将其数据安排在主索引234中。尽管表被不同地存储，主索引234将相同的数据保存为MaxDB 204中的数据库表214。在RDBMS 204中，表是以行方式(row-wise)存储的。在TREX 206，它们是以列方式(column-wise)存储的。该数据结构的优点将在下一部分论述。\n由于主索引234对读取访问是高度优化的，所以TREX 206保持Δ索引236以允许在更新其数据集的同时的快速数据检索。在Δ索引236中收集从队列表216所取的所有更新和插入。当对查询进行响应时，访问在Δ索引236和主索引234中的数据以提供与MaxDB 204的数据库表214相比较的整个数据集的一致视图。可以不像主索引234那样对Δ索引236进行用于读取访问的压缩和优化。因此，Δ索引236不应超过由实施系统的硬件限制确定的大小限制。在达到诸如特定大小或在预设时间间隔中的标准时，TREX内核232(或其监控组件)将Δ索引236和主索引234合并。将主索引234和Δ索引236合并既不阻塞TREX \n206内的数据的读取访问也不阻塞写入访问。列取向的数据处理系统206可在一个或多个可联网在一起的计算机系统上实施。\n[0067] 在本发明的一个实施例中，将数据冗余地存储在数据库表214和TREX的数据结构234中，只为了确保ACID特性。在可选实施例中，该冗余被消除。然后OLTP读取和写入访问以及OLAP报告将使用TREX 206的数据集。作为OLTP写入访问的先决条件，对TREX \n206进行修改以便充分支持ACID特性。分析了TREX 206能够支持哪些ACID特性，以及TREX 206如何可以完全支持他们：在TREX中通过使用与分布式数据库系统中的两阶段认可(two-phase-commit)协议相似的所谓的多索引调用来实施原子性。如果破坏了任何规则，那么通过监控约束、异常终止、以及退回重来(roll back)事务来支持一致性。日志文件确保持久性。隔离性是当前唯一不直接在TREX 206中实施的特性。TREX 206只提供称为读取认可(read committed)的隔离层次，这意味着在数据集中可能发生丢失的更新或者影像(phantom)。在本发明的一个实施例中，这可通过应用锁(application lock)将事务串行化来解决。在另一个实施例中，体系结构可建立在另一种现有的列取向主存储器存储系统上，诸如MonetDB、C-Store，或Google's Bigtable。\n[0068] 此外，标准化的数据库访问接口(例如SQL)的实施可包括在本发明的实施例中。\nTREX 206的原型SQL接口作为概念的验证(proof of concept)来实施。TREX 206本身提TM\n供ABAP 语言、C++语言和Python语言的编程接口。包括聚集函数(比如SUM、MIN、MAX、AVG、COUNT)的简单查询、列的分组和分类、基本条件处理是可能的。\n[0069] 然而，在另外的实施例中，由于主存储器是易失的，除主存储器数据集之外的至少一个持久性存储器208可用于备份。在系统崩溃后，主存储器的数据结构将从那里重新建立。如上所述，与传统的RDBMS 204中的数据存储相比，TREX 206中的数据是不同地存储的。以下讨论允许快速访问事务型数据的报告而无需事先聚集的数据结构。\n[0070] 数据结构和压缩技术\n[0071] 公司在日常运作过程中产生大量数据。在本节中以增进性能的两个不同领域为目标。首先，采用特定数据结构来实现性能。当前的DW体系结构的星型和雪花型模式提供对根据维度分组的关键性能数字的快速访问。通过避免当在第三范式(normal form)中使用关系数据模型用于分析时的大而复杂的连接来对其进行性能优化。然而，由于维度是在运行时间之前限定的，所以星型模式对于不可预知的报告行为是相对不灵活的。此外，需求的改变通常也导致模式的改变、或者整个模式的重新设计[W.H.Inmon。在数据仓库中星型体系结构何时是可以的?(When Are Star Schemas Okay in aData Warehouse？)商业观点：商业智能网络(B-Eye：BusinessIntelligence Network)-商业智能及远景的全球视野(The GlobalVision for BI and Beyond)http://www.b-eye-network.com/view/5626，\n2007年7月]。\n[0072] 其次，将数据完全保持在主存储器中是另一种实现足够查询性能的方式。虽然主存储器空间在尺寸上增长，但与磁盘空间相比仍然非常昂贵，而且尺寸受到限制。因此，为了适合主存储器中的这样的数据量，可利用具有最大压缩率和对插入或检索性能具有最小负面影响的压缩算法。\n[0073] 列取向\n[0074] 由于只有一个数据存储器用在所提出的体系结构中，可使用能够提供适当的用于事务情况的读取和写入访问性能以及用于分析情况的检索性能的数据结构。在这种情况下，在分析情况下使用的部分地非规范化的模式是不可行的，因为它们在事务情况下执行得不好。不是快速检索访问的非规范化，而是本发明的一个实施例的方法沿相反的方向前进，并采取比关系数据模型更进一步的规范化步骤。为了避免复杂的连接，不对数据库表进行非规范化，从而实现预先计算的连接，但是将表分解为列层次。在20多年前引入了“转动表(turning the tables)”的概念。1985年，Copeland和Khoshafian引入完全分解的存储模式(DSM)[G.P.Copeland和S.Khoshafian。分解存储模型(A Decomposition Storage Model)。在S.B.Navathe，编辑，1985年关于数据管理的ACM SIGMOD国际会议会刊(Proceedings of the 1985ACM SIGMOD InternationalConference on Management of Data)，得克萨斯州，奥斯汀，5月28-31日，1985，第268-279页。ACM出版社(ACM Press)，\n1985]。每列是由其自身存储的(见图3)，逻辑表结构由代理标识符的引入来保存的。\n[0075] 图3示出了基于行取向与列取向的数据存储的实例。行取向存储可以视为具有一系列数据的单一表。列取向存储可视为在每个表中具有复制的代理标识符sID的多个表(每列一个)。\n[0076] 代理标识符sID的存储导致额外的存储消耗，例如，这可以通过将列中的属性位置信息用作标识符来克服。甚至存在避免属性值(例如，空值)的冗余存储的更精细的方法，或在只有少量不同值存在的列的情况下。以列而不是行来存储数据的构思已在多个项目中实施，例如，MonetDB[P.Boncz.Monet：用于查询密集型应用的下一代DBMS内核(A Next-Generation DBMS Kernel for QueryIntensive Applications)。博士论文，阿姆斯特丹大学，阿姆斯特丹，荷兰，2002年5月]，C-Store[M.Stonebraker等人。C-存储：列取向的DBMS(C-Store：A Column-oriented DBMS)。在VLDB′05：第31届极大型数据库国际会议会刊(Proceedings of the 31stInternational Conference on Vert Large Data Bases)，第553-564页。VLDB基金会(VLDB Endowment)，2005]，或谷歌的BigTable[F.Chang，J.Dean，S.Ghemawat，W.C.Hsieh，D.A.Wallach，M.Burrows，T.Chandra，A.Fikes，以及R.E.Gruber.Bigtable：用于结构化数据的分布式存储系统(B igtable：A Distributed Storage Systemfor Structured Data)。在USENIX′06：操作系统设计和实现的USENIXth\n研讨会第七届会议会刊(Proceedings of ther 7 conferenceon USENIX Symposium on Opereating Systems Design andImplementation)，第15-15页，加州伯克利，美国，2006，USENIX协会(USENIX Association)]等。\n[0077] 列取向存储使用一种观察(observation)(即，并非通常在报告中查询表的所有列或者并非需要表的所有列来创建结果)。与数据库中使用的关系模型(其中访问两个表中的所有列(即使那些对结果不必要))相比，列取向的方法产生了更轻量(lightweight)的解决方案。只需访问为了创建结果直接需要的列。\n[0078] 在列取向数据结构中，与传统的分析型或事务型方案相比，组成相同信息的连接的数量较高，但连接本身具有较低的复杂度并且需要访问较少的数据。当在多台机器上分配数据时，访问值的单个列和计算连接可以大规模地并行化。存在为多台机器分配数据的两种基本方法，如图4所示。\n[0079] 图4示出了水平分段存储(fragmentation)和垂直分段存储的实例。水平分段存储将表分成行组(set of rows)并将它们分配在不同的机器上以执行并行计算。例如已经介绍了解决处理具有大量行的表的问题，比如DW系统中的事实表[A.Y.Noaman和K.Barker。用于分布式数据仓库中的事实关系的水平分段存储算法(AHorizontal Fragmentation Algorithm for the Fact Relation in aDistributed Data Warehouse)。\n在CIKM’99：第八届信息和知识管理国际会议会刊(Proceedings of the Eighth International Conference onInformation and Knowledge Management)，第154-161页，纽约，NY，美国，1999。ACM出版社(ACM Press)]。列取向有利于垂直分段存储，其中，表的列分布在多台机器上。TREX 206同时使用这两种方法[T.Legler、W.Lehner和A.Ross。\n使用SAP NetWeaver BI加速器的数据挖掘(Data Mining with the SAP NetWeaver BIAccelerator)。在VLDB’06：第32届极大型数据库国际会议会刊(Proceedings of the nd\n32 International Conference on Very Large DataBases)，第1059至1068页。VLDB基金会，2006]。除了并行计算的优点，通过分段存储，可以在存储器中保存整个数据集而无需使用高端硬件技术。\n[0080] 调整多个列\n[0081] 压缩是使更多数据适应有限的存储器空间的解决方案。写入时压缩数据，读取时解压数据，然而，给CPU增加了更多负担。可根据本发明的实施例平衡在使用压缩时处理时间的增加与没有压缩时增加的存储器空间使用量之间的折衷。然而，可以观察到CPU速度和存储器访问速度的增长率之间的差距在扩大[N.R.Mahapatra和B.Venkatrao。处理器内存瓶颈：问题与解决方案(TheProcessor-Memory Bottleneck：Problems and Solutions)。\nCrossroads，5(3)：2，1999]。虽然CPU的速度以每年60％的比率增长，但是存储器(DRAM)的访问时间每年增加不到10％。在增加信息密度从而降低内存访问量的同时，通过将某些处理能力引向压缩和解压缩，这种增长的差异补偿了数据压缩的使用。\n[0082] 数据压缩技术采用关于最优结果的数据域的数据和数据内的冗余。在这种情况下，列取向存储有助于优化压缩。一列内的属性具有相同的数据类型或结构类型，因此彼此之间具有强相似性。Abadi等[见D.Abadi、S.Madden和M.Ferreira，列取向数据库系统的集成压缩和执行(Integrating Compression and Execution inColumn-Oriented Database Systems)，在SIGMOD′06：2006年数据管理ACM SIGMOD国际会议会刊(Proceedings of the 2006ACMSIGMOD international conference on Management of data)，第671-682页(纽约，NY，美国，ACM出版社，2006年)]表征并评价了了一组利用列取向存储的工作地相当好的压缩技术，例如游程(run-length)编码(RLE)或位向量编码。\n在RLE中重复的值被压缩为一个(值，游程)对。例如序列“aaaa”被压缩为“a[4]”。这种方法特别适用于具有属性值小变化(variance)的分类的列。对于后者如果不进行分类，那么位向量编码很合适。存在许多不同位向量编码的变体。从本质上讲，在列中频繁出现的属性值与位串相关联，其中，位引用列内的位置，并且只设置在其位置存在属性值的那些位。然后对没有属性值的列进行存储，并且该列可以结合位向量进行重建。已用于行取向的存储方法也仍然可用于列取向存储。一个实例是字典编码(dictionary encoding)，其中，用较小的符号代替经常出现的图案(pattern)。\n[0083] 目前，TREX 206使用整数和字典编码以及位向量编码。属性的每一个现有值存储在字典表中并映射为整数值。在列中只存储整数值。作为第一个优点，在列中多次存在的属性值引用字典表中的同一行。从而消除了属性值的冗余存储，并且只出现引用相同属性值的整数的冗余。第二个优点是用于编码的整数与实际的属性值相比消耗更少的存储空间。\n[0084] 由于压缩的列的原因，增加了与使用的存储器空间相关的信息密度。因此，更多相关信息可以被加载到缓存(Cache)中用于同时处理。与行存储(其中甚至与查询无关的列也加载到缓存中而没有被使用的)相比，需要较少的从存储器到缓存的加载动作。\n[0085] 其他的实施例\n[0086] 在传统的DW项目中，一项重要的任务是限定如何从各个源抽取数据、然后在DW中集成数据的处理。ETL处理包括诸如访问不同的源数据库、在源数据中发现和解决不一致性、在不同的数据格式或语言之间进行转换、以及将产生的数据加载到DW中的活动。本发明的一个实施例旨在将ETL活动移动到查询运行时间。当这样做时，将ETL处理中的转换步骤映射到使用主存储器技术可实时地高效计算的操作中可能是最具挑战性的。提出的案例研究只包括一种类型的转换活动：聚集。为了能够在OLTP系统之上直接提供所有不同种类的报告，必须考虑其他类型的转换活动。转换活动可以具有原子性或组合性质(composed nature)。来自控制领域的实例将示出包含从给定年份的一月到十二月的账户的期初余额(openingbalance)和终结余额(closing balance)的列表：对于每月m，聚集必须只对带有1月1日和m月最后一天之间的日期的那些行式项目完成。结果是然后m的终结余额和m+1的期初余额。在这个实例中，求和运算符(即，聚集)将是原子性转换。组合的转换用于为创建所有期初和终结余额的处理建立模型。对于每一个复杂的报告，这种类似工作流的模型可以用来描述转换。Simitsis、Vassiliadis、和Sellis将ETL处理看作工作流以寻找优化[A.Simitsis、P.Vassiliadis和T.Sellis。ETL工作流的状态空间的优化(State-SpaceOptimization of ETL Workflows)。知识和数据工程的IEEE事务(IEEE Transactions on Knowledge and Data Engineering)，17(10)：1404-1419，2005]。然而，他们的研究旨在优化传统的、类似批量作业的ETL处理。用于运行中ETL处理的工作流模型尚未进行研究，因此是本发明的进一步实施例的一个机会。相应的任务包括它们需要的复杂转换以及复杂报告情况的识别。然后可找到对这些转换的适当的抽象，从而可以对这些转换进行概括以使用这些转换建立ETL工作流。然后，可以找到用于已识别的转换的高效实施。\n[0087] 根据上述实施例，使用SQL访问主存储器数据库206(TREX)。由于SQL是基于集合的数据检索语言，所以它不适合分层的结构化数据(由于其存储在OLAP系统中)的检索。\n出于这个目的，通常使用由适应OLAP环境的大多数数据库支持的MDX。考虑到组合的转换活动可用于描述OLTP数据和报告之间的转换，进一步实施例使用组合的转换构造来扩展如MDX或XQuery的语言。\n[0088] 根据上述实施例，实施例使用SAP TREX作为存储OLTP数据的主存储器数据库\n206。然而，存在具有诸如列取向的类似特性的其他数据库产品。根据进一步的实施例，可使用诸如MonetDB和Vertica的这些其他数据库产品。\n[0089] 与这些附加实施例有关，注意SQL生成器640和列取向的SQL模块642(见图6)。\n[0090] 图5示出了根据本发明的实施例的数据库系统500。数据库系统500包括会计凭证502、分类帐账户504、和快速搜索基础结构506。会计凭证502和分类账账户504是由主存储器数据库106(见图1)管理的数据存储108中的数据文件的具体实例。快速搜索基础结构506对应于数据库系统200(见图2)的多个方面，这将从以下的描述和随后的图中变得更加明显。\n[0091] 会计凭证502包括根对象和会计行式项目。用户可以与会计凭证502进行交互以增加新的行式项目。然后行式项目根据分类帐账目504的根对象填充分类账账目504。\n[0092] 快速搜索基础结构506与会计凭证502进行交互以将行式项目填充到列取向的数据处理系统(诸如TREX 206，见图2)，如下进一步详细描述。\n[0093] 根据本发明的进一步的实施例，省略了总数对象512、TBT对象514和总数对象\n516(及其相关联的连接)。例如，当快速搜索基础结构506正在处理查询时，可以将它们可省略。\n[0094] 图6示出了根据本发明的实施例的数据库系统600。数据库系统600包括应用程序套件602(在执行那些来自SAP的具体应用程序套件的实施例中也称为当前的AP/A1S或BuisinessByDesign)、两个列取向的系统604(也称为变量1)和606(也称为变量2)。没有必要在一个特定的实施例中包括系统604和系统606二者，一个就足够了。\n[0095] 在应用程序套件602与两个选项和604和606之间的分析引擎610是公用的。分析引擎610与虚拟提供者612a(602的组件)、612b(604的组件)和612c(606的组件)进行交互。虚拟提供者612a与商务智能(BI)数据源614进行交互。BI数据源614与总数和余额工具616进行交互。总数和余额工具616与商务对象(BO)持久存储618进行交互。\nBO持久存储618包括总数620和行式项目622。快速搜索基础结构(FSI)624如FSI复制行式项目630那样将行式项目622复制到选项604和606中。注意，数据库系统600的多个方面对应于数据库系统200的那些方面(见图2和相关描述)。\n[0096] 列取向的系统604包括索引632(在将TREX用作列取向系统604的具体实施的实施例中也称为TREX索引)。FSI复制的行式项目630填充索引632。虚拟提供者612b与索引632进行交互。\n[0097] 列取向系统606与列取向系统604相似，但增加了：SQL生成器640、列取向的SQL模块642(在将TREX用作列取向系统606的具体实施的实施例中也称为TREX SQL)。SQL生成器640是虚拟提供者612c的组件。对于附加实施例，SQL生成器640如以上讨论的那样操作。\n[0098] 列取向的SQL模块642包括分析器(parser)组件和模型组件。列取向的SQL模块642与虚拟提供者612c和索引632进行交互。对于附加实施例，列取向的SQL模块642如以上讨论的那样操作。\n[0099] 图7示出了根据本发明的实施例的数据库系统700。数据库系统700与数据库系统200(见图2)相似。省略了(为简洁起见)重复的细节，而具有如下区别。应用程序套件702(在实施来自SAP的那些具体应用程序套件的实施例中也称为AP/A1S或BuisinessByDesign)对应于OLTP(和/或OLAP)系统202。列取向数据处理系统706(也称为TREX组件，作为CODPS 706的具体实施)经由插入和查询与应用程序套件702进行交互。内核732(在该具体实施中，也被称为TREX内核)与文件系统734进行交互。\n[0100] 图8示出了根据本发明的实施例的数据库系统800。数据库系统800与数据库系统200(见图2)相似。省略了(为简洁起见)重复的细节，而具有如下区别。应用程序套件802(在实施来自SAP的那些具体应用程序套件的实施例中也称为AP/A1S或BuisinessByDesign)对应于OLTP(和/或OLAP)系统202。数据库(DB)空间808对应于文件系统208(见图2)。与数据库系统700(见图7)相比，注意，与图7中的文件系统734相比，数据库系统800省略了文件系统(示出但划掉)及与其相关联的连接。\n[0101] 图9是根据本发明的实施例的数据处理900的流程图。该方法900旨在处理用于事务和报告的数据库信息。该方法900可由诸如数据库系统200的本发明的实施例来执行(见图2)。\n[0102] 在步骤902中，数据库信息以行格式存储。数据库信息可存储在例如数据库表\n214(见图2)中。诸如关系数据库管理系统204(见图2)的关系数据库管理系统组件可管理存储操作。\n[0103] 在步骤904中，以列格式存储数据库信息。列取向数据处理组件的内核(诸如内核232和TREX组件206，见图2)可使用主索引和Δ索引(诸如主索引234和Δ索引236，见图2)来管理这种存储操作。\n[0104] 在步骤906中，响应于数据库更新请求，以如下方式执行各种更新、锁定和解锁程序。更新以行格式存储的数据库信息。诸如关系数据库管理系统204(见图2)的关系数据库管理系统组件可管理更新操作。锁定以所述行格式存储的数据库信息。诸如关系数据库管理系统204(见图2)的关系数据库管理系统组件可管理锁定并可向列取向数据处理组件(诸如内核232和TREX组件206，见图2)通知数据库更新请求。当锁定位于适当位置时，更新以所述列格式存储的数据库信息。这可通过关系数据库管理系统组件通知列取向数据处理组件(例如)锁定是激活的或更新请求起作用来完成。在以列格式存储的数据库信息更新之后，对以行格式存储的数据库信息进行解锁。列取向数据处理组件可执行更新，然后可向关系数据库管理系统组件通知已执行更新。\n[0105] 在步骤908中，响应于查询请求，基于以所述列格式存储的数据库信息生成查询响应。列取向数据处理组件可接收查询请求并可生成查询响应。\n[0106] 性能评价\n[0107] 为了验证根据本发明的报告体系结构，现有的SAP DW产品作为原型实施的性能的基准。\n[0108] 为了建立在其中现有的DW产品和原型可以比较的设置，重点放在DW必须访问OLTP数据的使用案例中。虽然在该项目的过程中已对财务会计领域的几种情况进行了研究，但以下只报告一个案例研究。\n[0109] 案例研究包含表示资产负债表报告的小子集的两个使用案例。管理人员不仅在会计期结束时使用资产负债表报告，而且还进行(如果当前周期将在进行查询的那天结束，资产负债表会看起来像)“假设模拟分析(what-if simulations)”。第一个使用案例是选择一个时期内公司的所有账户总数(借方和贷方)，在资产负债表的创建中这是主要步骤之一。第二个使用案例是为一个具体账户和时期选择借方和贷方总数。经常检查特定帐户的总数以得到支出、收入、和公司的特殊资产的特定类型的概况。\n[0110] DW系统必须从企业资源规划(ERP)系统(例如SAP BusinessByDesign)收集账户总数。ERP系统基于行式项目创建预聚集总数，其使用专用数据库表管理预聚集总数。存储这些总数的原因是它们具有财务会计背景中的特定含义，并因此经常被查询。预聚合的总数类似于经典OLAP设置，因为DW系统中的数据通常是预聚集的。在选择的资产负债表的情况下，总数需要位于非常高层次的聚集上。然而，由ERP系统存储的总数在更高密度(fine-grained)的聚集层次。为了制作资产负债表，因此在从数据库读取数据之后必须执行额外的聚集步骤。\n[0111] 然而，我们这里呈现的性能数字没有考虑额外的聚集时间：虽然也已执行了考虑端到端的性能测试(由所有涉及的组件消耗的时间和网络时间)，但是这里的重点是在数据访问层。因而，当从各表检索总数时到使用以上提出的基于主存储器的方法在运行中执行行式项目的聚集的时间，测量ERP系统中的数据库的响应时间。对于第一个使用案例(检索所有的总数)，ERP数据库(MaxDB 204)需要对总数表进行全表扫描，如同主存储器数据库(TREX 206)对行式项目层次所做的那样。第二个使用案例(检索几个具体总数)产生了MaxDB中的缓存命中(Cache-hit)，而TREX仍然需要对包含行式项目的表的“数量”列执行完全扫描。\n[0112] 用于测量的测试数据是从酿酒行业的中等企业获取的。获取了一个财政年度的会计数据(约3600万会计凭证行式项目)，分析了相应表中的值的统计分布，并且根据统计分布生成了不同的测试数据集。数据集的特征在于，所使用的ERP系统为数据集创建和管理的会计凭证的数量、会计凭证行式项目的总数以及预聚集总数的数量。不同的数据集在表\n1中示出。\n[0113] \n 规模 会计凭证 行式项目 总数\n XS 30,000 100,000 10,159\n S 150,000 500,000 49,002\n M 300,000 1,000,000 100,952\n L 1,500,000 5,000,000 442,019\n XL 3,000,000 10,000,000 474,331\n[0114] 表1：不同的测试数据集\n[0115] 在同一台机器上测量了MaxDB和TREX的性能。在表2中示出了测试平台的硬件配置。\n[0116] \n 组件 描述\n 操作系统 Gentoo Linux 2.6.21-gentoo\n CPU 4x 双核AMD Opteron\n @2.8GHz 1MB L2 Cache\n 主存储器 32GB@667MHz\n 硬盘驱动器 2x300GB\n (每秒读取89MB)\n MaxDB版本 7.6.00.37用于Linux x86_64\n TREX版本 7.10.04.00(编译：2007-06-19)\n[0117] 表2：测试平台硬件\n[0118] 表3示出了以秒为单位的测量结果。所有结果平均在20个查询以上。在测量开始前，在数据库上运行40个查询，以确保测量考虑到数据库缓存。\n[0119] \n[0120] 表3：测量结果(以秒为单位)\n[0121] 两个使用案例的TREX的平均响应时间是相似的。这是由于TREX必须为两个使用案例都进行全表扫描的事实。在第一个使用案例(检索所有账户的总数)，MaxDB不得不对包含预聚集的总数的表执行全表扫描。TREX的平均响应时间仍然略优于MaxDB的平均响应时间。值得注意的是，对于大多数数据集规模(sizes)，MaxDB的总数表中行的数量与TREX中行式项目的数量的比率大约为1∶10。相反，在第二个使用案例(检索具体账户的总数)中，TREX比MaxDB慢些。然而，运行中的计算允许ERP系统的更简单的体系结构，意味着没有需要定期更新的总数，从而它们与会计凭证行式项目是一致的。具体总数的略为缓慢的查询性能换取了更多的灵活性，因为与ERP系统中的后查询(post-query)聚集相反，它使得在资产负债表所要求的聚集层次上能够直接计算总数。\n[0122] 实施\n[0123] 图10是实施本发明的实施例的计算机系统和网络1400的实例的框图。计算机系统1410包括用于传递信息的总线1405或其他通信机构、以及与总线1405耦合的用于处理信息的处理器1401。计算机系统1410还包括耦合至总线1405的用于存储信息和将由处理器1401执行的指令(包括用于执行上述技术的信息和指令)的存储器1402。该存储器还可用于存储在将由处理器1401执行的指令的执行过程中的临时变量或其他中间信息。这种存储器可能的实施可以是(但不仅限于)随机存取存储器(RAM)、只读存储器(ROM)、或两者兼而有之。还设置存储设备1403用于存储信息和指令。存储设备的常见形式包括，例如，硬盘驱动器、磁盘、光盘、CD-ROM、DVD、闪存、USB存储卡，或计算机可对其进行读取的任何其他介质。例如，存储设备1403可包括源代码、二进制代码、或用于执行上述技术或实施上述结构的软件文件。\n[0124] 计算机系统1410可经由总线1405耦合到向计算机用户显示信息的诸如阴极射线管(CRT)或液晶显示器(LCD)的显示器1412。诸如键盘和/或鼠标的输入设备1411耦合至总线1405，用于将来自用户的信息和命令选择传递至处理器1401。这些组件的组合允许用户与系统进行通信。在某些系统中，总线1405可以分为多条专用总线。\n[0125] 计算机系统1410还包括与总线1405耦合的网络接口1404。网络接口1404可提供计算机系统1410和本地网络1420之间的双向数据通信。例如，网络接口1404可以是通过电话线提供数据通信连接的数字用户线路(DSL)或调制解调器。网络接口的另一个实例是提供到可兼容的LAN的数据通信连接的局域网(LAN)卡。无线链路也是另一个实例。在任何这种实施中，网络接口1404发送并接收携带表示各种类型的信息的数字数据流的电信号、电磁信号、或光信号。\n[0126] 计算机系统1410可通过网络接口1404向内联网(Intranet)或互联网\n(Internet)1430发送和接收信息(包括消息或其他接口动作)。在互联网的实例中，软件组件或服务可穿过网络驻留在多个不同的计算机系统1410或服务器1431、1432、1433、1434以及1435上。服务器1431可通过互联网1430、本地网络1420以及网络接口1404将动作或消息从一个组件传送到计算机系统1410的组件上。\n[0127] 结论\n[0128] 本发明的实施例提出了直接使用OLTP系统作为数据源的用于报告的体系结构，因此，\n[0129] 不需要大量的ETL加载以将数据复制到DW系统，\n[0130] 不需要管理位于各种不同层次的OLTP数据聚集，\n[0131] 不限于为OLAP数据结构(即，立方体)存在的情况提供报告，\n[0132] 不需要多于一个的OLTP和OLAP的单个持久存储。\n[0133] 诸如列取向存储范例的主存储器技术可用于实现这种体系结构。已使用基于SAP Business ByDesign的、中型市场商务软件解决方案的原型实施验证了该体系结构。介绍了来自财务会计的案例研究以示出所提出的报告体系结构的一个可能应用。使用了真实的客户财务数据以生成不同规模的测试数据集。将来自SAP BusinessByDesign的所呈现的报告使用案例的数据的直接抽取作为原型实施的基准。结果显示可以在2.1秒的响应时间内产生具有所有账户总数的报告，其中，每个总数是从包含1千万行的表聚集的。这些结果表明(至少在财务会计领域)不再需要类立方体结构中的聚集的存储。\n[0134] 以上的描述示出了本发明的各种实施例和本发明的多个方面如何可以实施的实例。不应该认为以上实例和实施例是唯一的实施例，给出上述实例和实施例是用于示出由所附权利要求限定的本发明的灵活性和优点。基于以上的披露和所附的权利要求，其他布置、实施例、实施、以及和等同物对本领域的技术人员来说将是显而易见的，并可在不背离由权利要求所限定的本发明的精神和范围的情况下采用。