Hybrid data provider

Systems and techniques for the hybrid provision of data are described. In one aspect, a system includes a first collection of information stored in accordance with a reporting data model, a second collection of information setting forth a collection of one or more additive delta records, and an analytic engine to perform queries on the first collection of information and the second collection of information to yield an aggregated result set that is based on the contents of both the first collection of information and the second collection of information. The additive delta records each include a numeric value that characterizes the magnitude of a change to a numeric measure in the first collection and identification information that identifies the numeric measure in the first collection. The identified numeric measure is no longer current.

BACKGROUND

This disclosure relates to a hybrid provider of data.

The storage of information by a machine can be tailored for operational efficiency and effectiveness in different contexts. Such tailoring is often achieved by using different data models in the different contexts. A data model is the logical and physical structure of a data store, and can include the physical storage parameters needed to implement a design.

Contexts for which data models can be tailored include data analysis, data modification, and/or size minimization. For example, transactional data models are generally tailored to facilitate modification of the stored data. In this regard, transactional data models generally ensure that modifications can be made quickly by using relatively small data storage structures that can be modified independently of other transactional data structures. A relatively small data storage structure is one that is comparable in size to the largest common change transaction. A change transaction is a transaction in which the stored data content is added, deleted, or otherwise changed. A transactional data model can thus include individual data objects that are comparable in size to common changes to content. For example, a transactional data model can include data objects that correspond to individual sales orders in a business, individual customers, and/or individual products.

As another example, reporting data models are generally tailored to facilitate analysis and/or reporting of stored data. In this regard, reporting data models generally ensure that large amounts of stored data can be accessed quickly and easily by using relatively large data storage structures. Also, reporting data models can be structured so that portions of the data model only include numeric data. Any exhaustive or near-exhaustive searching can thus be performed rapidly on this numeric data. A reporting data model can be several hundred or more times the size of common change transactions. For example, a reporting data model can be a relational database such as a common warehouse metamodel (CWM) star schema that includes objects which store data regarding several thousand, million, or billion sales orders, customers, and/or products.

SUMMARY

Systems and techniques for the hybrid provision of data are described. In one aspect, a system includes a first collection of information stored in accordance with a reporting data model, a second collection of information setting forth a collection of one or more additive delta records, and an analytic engine to perform queries on the first collection of information and the second collection of information to yield an aggregated result set that is based on the contents of both the first collection of information and the second collection of information. The additive delta records each include a numeric value that characterizes the magnitude of a change to a numeric measure in the first collection and identification information that identifies the numeric measure in the first collection. The identified numeric measure is no longer current.

This and other aspects can include one or more of the following features. The reporting model can include a set of relational tables, such as a common warehouse metamodel. The system can include a data flow path to upload the second collection of information into the first collection of information. The first collection of information can include previously uploaded additive delta records. All of the additive delta records can be pending and not yet uploaded into the first collection of information.

The system can also include an indexed data store that is accessible to the analytic engine for the generation of aggregated result sets that include information from the indexed data store, as well as a data flow path from the first collection of information to the indexed data store. The system can also include a third collection of information stored in accordance with a transactional data model, and a data flow path to convey transactional changes made to the third collection of information to the second collection of information. The data flow path can include an activation queue to receive the transactional changes made to the third collection of information and convey information describing the transactional changes to the second collection of information. The data flow path can also include an active record store that stores complete information received from the third collection of information.

In another aspect, an article includes one or more tangibly-embodied machine-readable media storing instructions. The instructions are operable to cause one or more machines to perform operations. The operations include querying a first collection of information stored in accordance with a reporting data model, querying a second collection of information setting forth a collection of one or more additive delta records, and generating an aggregated result set that reflects both the contents of the first collection of information and the second collection of information. The additive delta records each include a numeric value that can be added to a measure in the first collection of information and identification information that identifies the measure in the first collection of information.

This and other aspects can include one or more of the following features. The first collection of information can include a set of relational tables. The second collection of information can include a data table that associates the numeric value and the identification information of each additive delta in a row. The aggregated result set can be provided by summing a first numeric value of a first additive delta with a first measure in the first collection of information, where the identification information of the first additive delta is identical to information associated with the first measure in the first collection of information.

The operations can also include searching an indexed data store. The aggregated result set can reflect contents of the first collection of information, contents of the second collection of information, and contents of the indexed data store. The second collection of information can be uploaded into the first collection of information.

In another aspect, a system includes a collection of data objects that are modified in response to transactional changes, a collection of relational data tables that reflect less than all of the transactional changes to content of the data object collection, a data flow path to convey unreflected changes to the data object collection to the relational data table collection, wherein the data flow path includes a staging data storage area that accumulates pending changes to be made to the relational data table collection, and an analytic engine to perform queries on both the staging data storage area and the collection of relational data tables to generate an aggregated result set that reflects the contents of both the staging data storage area and the collection of relational data tables.

This and other aspects can include one or more of the following features. The pending changes can include additive delta records. The additive delta records can include a numeric value that characterizes the change to a numeric measure in the collection of relational data tables and identification information that identifies the numeric measure in the collection of relational data tables. The identified numeric measure is no longer current. The system can also include an indexed data store that is accessible to the analytic engine for the generation of aggregated result sets that include information from the indexed data store.

DETAILED DESCRIPTION

FIG. 1is a schematic representation of a system100that includes a hybrid data provider. System100includes a user or other interface105, a transactional model data store110, a reporting model delta data store115, a reporting model data store120, and a analytic engine125. Information is conveyed between interface105, data stores110,115,120, and analytic engine125along data flow paths130,135,140,145,150,155. For example, analytic engine access the contents of both reporting model delta data store115and reporting model data store120over data flow paths140,145when running queries. Such queries can yield an aggregated result set that accurately reflects the contents of both reporting model delta data store115and reporting model data store120. Reporting model delta data store115and reporting model data store120can thus together act as a hybrid data provider160.

User or other interface105is a collection of one or more input/output devices for interacting with a human user or with another data processing system. For example, interface105can be a presentation system or a data communications gateway. Data flow path130is input received over interface105that causes a change to information stored in one or more transactional data models in transactional model data store110. Such changes include the creation, deletion, and modification of all or a portion of the contents of one or more transactional model data stores. Output over interface105can present the results of data processing activities in system100. For example, data flow path155can convey the results of queries or other operations performed on hybrid data provider160for presentation on a monitor or a data communications gateway.

Transactional model data store110is a collection of information that is stored at one or more data storage devices. Transactional model data store110stores this information in one or more transactional models. Data flow path135conveys information describing changes to data stored in a transactional model data store110to reporting model delta data store115. Such changes include the creation, deletion, and modification of all or a portion of the contents of one or more transactional model data stores.

Reporting model delta data store115is a collection of information that is stored at one or more data storage devices. The stored information can characterize changes to at least some of the content of one or more transactional model data store110. For example, reporting model delta data store115can receive multiple changes over data flow path135and accumulate them by storing them before conveying them to reporting model data store120. Reporting model delta data store115can accumulate the changes in one or more different data models. For example, as discussed further below, reporting model delta data store115can accumulate the changes as additive delta records in one or more data tables. Data flow path145periodically conveys the accumulated changes to reporting model data store120. Such conveyances can be periodic in that the conveyances are generally not continuous but rather reflect a number of discrete changes to transactional model data store110. For example, several tens or even hundreds of such changes can be accumulated at reporting model delta data store115before their conveyance.

Reporting model data store120is a collection of information that is stored at one or more data storage devices. The stored information can characterize at least some of the information stored in one or more transactional data models in transactional model data store110. Reporting model data store120can store this information in one or more reporting data models.

Data flow path140allows analytic engine125to access the accumulated changes in reporting model delta data store115. Data flow path150allows analytic engine125to access the contents of reporting model data store120.

Analytic engine125is a collection of data processing activities performed in accordance with the logic of a set of machine-readable instructions. The data processing activities can include running queries on the contents of both reporting model delta data store115and reporting model data store120, which act together as hybrid data provider160. The results of such queries can be aggregated to yield an aggregated result set. A query is a request for information. A result set is a set of information that answers a query. An aggregated result set is a set of information from two or more data stores that answers a query. The set of information in an aggregated result set can be, e.g., a union of the results of independent queries on the two or more data stores. The aggregated result sets can be conveyed to interface105over data flow path155. Interface105can, in turn, render the aggregated result sets over an output device for a human or other user. This rendering of aggregated result sets drawn from hybrid data provider160(i.e., both reporting model delta data store115and reporting model data store120) allows system100to accurately portray, the contents of different data stores having different data models.

FIG. 2is a graph200that schematically represents how “current” the data content of transactional model data store110, reporting model delta data store115, and reporting model data store120are at a time T0. Graph200includes an vertical axis205and a horizontal axis210. Vertical axis205represents what percent of the data content of a data store is current. Horizontal axis210represents the position of data stores110,115,120relative to the data flow paths135,145between them. “Current” data is data that reflects every data transaction on the data in system100that is relevant to responding to a query. The vertical position of line215denotes what percent of the data in transactional model data store110is current. The vertical position of line220denotes what percent of the data in reporting model delta data store115is current. The vertical position of line225denotes what percent of the data in reporting model data store110is current.

Time T0is a time when the data that is relevant to responding to queries is identical in data stores110,115,120. In other words, all of the data in data stores110,115,120is entirely current, as represented by the identical vertical positions of lines215,220,225at 100%. For example, time T0can be a time immediately after the creation and population of data stores110,115,120with initial values (i.e., at the “initiation” of data stores110,115,120). As another example, time T0can be a time after an extended period of latency in system100. Such an extended period of latency can provide data flow paths135,145the opportunity to propagate relevant changes to transactional model data store110carried over data flow path130onward to data stores115,120.

As a practical matter, as the size and complexity of system100increases, the likelihood of all data in data stores110,115,120ever being current decreases. In other words, time T0will generally not be reached since the changes to transactional model data store110carried over data flow path130are first accumulated at reporting model delta data store115and only periodically committed to reporting model data store120. This is not surprising in light of reporting model data store120being tailored for analysis and reporting, rather than transactions.

This scenario is reflected inFIG. 3, which is a graph300that schematically represents how current the data content of transactional model data store110, reporting model delta data store115, and reporting model data store120are at a time T1.

As can be seen, the vertical position of line215remains unchanged, denoting that all of the data in transactional model data store110is current. However, the vertical position of line220is lower, denoting that less than all of the data in reporting model delta data store115is current. Further, the vertical position of line225denotes is yet lower than the vertical position of line220, denoting that even less of the data in reporting model data store120than the data in reporting model delta data store115is current. In particular, data flow path135does not immediately convey changes from transactional model data store110to reporting model delta data store115, and data flow path145does not immediately convey changes from reporting model delta data store115to reporting model data store120. Despite the delays associated with data flow paths135,145, the majority of data in reporting model delta data store115remains current. For example, in some implementations, over 95%, or even over 99%, of the data in reporting model delta data store115remains current.

With analytic engine125providing aggregated result sets drawn from both reporting model delta data store115and reporting model data store120, the benefits of quick data access in reporting model data store120for the majority of the data can be combined while the benefit of early access to additional current data in reporting model delta data store115. In particular, even recent transactions will appear in result sets generated by analytic engine125with a minor additional cost associated with the access and retrieval of data from reporting model delta data store115.

FIG. 4is a class diagram of an example transactional data model that can be used to store data at transactional model data store110(FIG. 1), namely a business object model400. Business object model400includes a sales order package405, a business partner package410, and a material package415. Business partner package410can include a business partner object class420. Business partner object class420has a business partner identity attribute, a name attribute, a surname attribute, a country attribute, and an organization attribute.

Material package415can include a material object class425and material text object classes430. Material object class425has a material identity attribute, a material group attribute, a price attribute, and a weight attribute. Material text object class430has a text attribute. Each material object class425can have a collection of zero or more associated material text object classes430in the role of “text.”

Sales order package405can include a header object class435, a position object class440, and a position calculation object class445. Header object class435has a header identity attribute, a customer identity attribute, a salesperson identity attribute, a date attribute, and a tax attribute. Header object class435is related to a first associated business partner object class420in the role of “customer” and to a second associated business partner object class420in the role of “salesperson.” Header object class435also has a collection of zero or more associated position object classes440.

Position object class440has a position identity attribute, a material identity attribute, a quantity attribute, and a quantity unit. Position object class440is related to one or more material object classes425. Each position object class440also has an associated position calculation object class445. Position calculation object class445has a taxperpos attribute and a currency unit attribute. Taxperpos attributes deal with the tax rate at a position.

Data stored in instantiated objects within business object model400can characterize the operations of an enterprise. For example, objects within business object model400can characterize a collection of sales events. Moreover, such object can be modified easily as individual sales events are added, modified, or deleted.

FIG. 5is a schematic representation of an example reporting data model that can be used to store data at reporting model data store120(FIG. 1), namely a star schema500. Data stored in star schema500can also characterize the operations of an enterprise, such as the same collection of sales events characterized by instantiated objects within business object model400(FIG. 4). However, since star schema500is tailored for data access and reporting, star schema500is generally only modified occasionally to reflect a collection of multiple sales events.

Star schema500is a set of relational tables. In particular, star schema500includes a fact table505, a collection of dimension tables510, and a collection of join paths515. Fact table505is a collection of measure objects that include measures (also known as “measurements,” “metrics,” “keyfigures,” and/or “facts”) organized into rows and columns. The measures in fact table505can set forth information about the collection of sales transactions and are typically numeric. For example, the measures in fact table505can include numeric data describing the amount, quantity, customer, sales person, and article sold.

Dimension tables510are collections of one or more dimension objects that organize characteristics into rows and columns. These characteristics describe aspects of the measures in fact table505. For example, a first dimension table510can include characteristics describing the material identifications and material groups of measures in fact table505that identify the articles sold. As another example, a second dimension table can include characteristics describing the business partner identifications, names, surnames, and countries of measures in fact table505that describe the customers or the sales persons involved in the transactions.

Join paths515indicate relationships between the measures in fact table505and the characteristics in dimension tables510. For example, join paths515can indicate that measures in fact table505are primary keys that can be used to identify records in dimension tables510.

FIG. 6is a schematic representation of another example reporting data model that can be used to store data at reporting model data store120(FIG. 1), namely a warehouse schema600. Warehouse schema600includes a set of relational tables. In particular, warehouse schema600includes a fact table605, a collection of dimension tables610, a collection of surrogate identification tables615, a collection of master data tables620, a collection of text tables625, and a collection of join paths635.

Fact table605is a collection of measure objects that include measures. The measures in fact table605can be keys in dimension tables610. Dimension tables610are collections of one or more dimension objects that organize characteristics that describe the measures in fact table605. The characteristics in dimension tables610can be numeric.

Surrogate identification tables615are collections of one or more dimension objects that organize mapping information. In particular, surrogate identification tables615include information for mapping characteristics in dimension tables610to objects and/or to characteristics in other tables. Surrogate identification tables615generally appear in multiple warehouse schemata.

The mapping information in individual surrogate identification tables615can relate to classes of objects with common features. For example, “time independent” surrogate identification tables615can map characteristics in dimension tables610to objects that include attributes to which time information is relatively unimportant. For example, an employee object that includes the name, gender, date of birth, and social security number of an employee can be considered an object having attributes to which time information is relatively unimportant. In particular, these attributes are unlikely to change and the time of any such a change is not typically relevant to the data processing activities. Since time information is relatively unimportant to these attributes, such time independent surrogate identification tables615need not include time information.

“Time dependent” surrogate identification tables615are another example of a class of surrogate identification table615. Time dependent surrogate identification tables615can map characteristics in dimension tables610to objects that include attributes to which time information is relevant to data processing activities. For example, an employee object that includes the position and department attributes of an employee in a company can be considered an object having attributes to which time information is potentially relevant. In particular, the chronological history of an employee's position and department assignments may be relevant to data processing activities in the company. Since time information is potentially relevant to these attributes, time independent surrogate identification tables615can include time information. In the employee object example discussed above, this time information could include time stamps that describe “valid from” and “valid to” dates for the mapped position and department attributes of the employee.

Another class of surrogate identification table615can map dimension table characteristics exclusively to characteristics in that individual surrogate identification table.FIG. 6shows an example of such a table, namely surrogate identification table615a. Since surrogate identification table615amaps dimension table characteristics exclusively to characteristics in that surrogate identification table615, there are no join paths635that originate from surrogate identification table615a.

Object tables620are collections of objects in the data processing system. The objects can be relevant to multiple processes and/or areas in an enterprise such as a business. For example, objects can describe characteristics of products, employees, customers, or other entities that are relevant to multiple portions of an enterprise. The objects in tables620can be dependent attributes of dimension record data in dimension tables610. Object tables620generally appear in multiple warehouse schemata.

Text tables625are collections of textual descriptions of characteristics. The characteristics described by text tables can be found in, e.g., surrogate identification tables615or object tables620. The textural descriptions provided by text tables625are typically natural language descriptions. For example, text tables625can provide natural language descriptions of dimension record data in different languages. Text tables625generally appear in multiple warehouse schemata.

Hierarchy tables630are special purpose collections of information derived from a master hierarchy. A hierarchy is a representation of the organization of common values of a characteristic in a tree structure. Hierarchy tables630can be created from a master hierarchy by selecting common values of a characteristic that stand in a particular parent-child relationship in the tree structure. Hierarchy tables630can thus be limited to a single column that describes the common values of a characteristic that stand in the particular parent-child relationship. The special purposes for which hierarchy tables630can be created include searching for measures that are relevant to characteristics that stand in the particular parent-child relationship.

Join paths635indicate relationships between the measures in fact table605, the characteristics in dimension tables610, the mapping information in surrogate identification tables615, the objects in object tables620, the text in text tables625, and the hierarchical information in hierarchy tables630.

FIG. 7is a schematic representation of an example reporting model delta data store115(FIG. 1). Reporting model delta data store115includes an activation queue store705, an active record store710, and a change log store715that can communicate with each other over data flow paths720,725,730to receive and transmit data along data flow paths135,140,145and allow reporting model delta data store115to be integrated into hybrid data provider160.

In particular, activation queue store705is an ordered collection of activation information that is stored at one or more data storage devices. Activation information characterizes changes made to one or more transactional models in transactional data model store110. Activation information can be received from transactional data model store110over data flow path135. The activation information in activation queue store705is ordered as a queue that represents the order in which the changes to the one or more transactional models were made. Activation queue store705can be, e.g., a linked list, a data table, or other data storage structure that can accommodate a variable rate of changes to one or more transactional models but yet maintain ordering.

Active record store710is a collection of information that is stored at one or more data storage devices. Active record store710can be a “complete” record of the contents of transaction model data store110in that active record store710contains all the information that has been dequeued from activation queue705regarding the contents of one or more transaction models in transaction model data store110. Thus, information that has yet to be conveyed over data flow path135is not contained in active record store710(see, e.g., line220,FIG. 3). The information stored in active record store710is generally not stored in a reporting model but rather can be stored, e.g., in a single database table.

Change log store715is a collection of information that sets forth pending changes to one or more reporting models in reporting model data store120. The changes are pending in that they have not yet been committed to reporting model data store120but rather are accumulating in changed log715. The pending changes can be stored in a format that is tailored to facilitate the transfer of information to reporting model data store120and to facilitate the aggregation of result sets from hybrid data provider160. For example, the pending changes can be stored in a format that can be written directly into reporting model data store120, such as a 1:1 transformation to convey the contents of change log store715to reporting model data store120. Further, in some implementations, the editing of this transformation by a user can be foreclosed.

The pending changes can be stored in data assemblies that associate additive deltas with identifiers of the records in reporting model data store115that are to be changed (hereinafter “additive delta records”). An additive delta is a numeric value that, when added to a numeric measure in a reporting model, changes that measure to make it more current. However, an additive delta need not overwrite the old measure to make the reporting model more current. Rather, an additive delta, along with other information specifying the record that is to be changed, can be committed to a reporting model and stored in the reporting model alongside the prior measure.

FIGS. 8,9,10A,10B illustrate example additive delta records and their correspondence to the contents of a reporting or other data model stores. In particular,FIG. 8is a table800that schematically represents a portion of the prior contents of a reporting model or other data store. For example, table800can be part of reporting model data store120(FIG. 1) or table800can be part of active record store710.

Table800includes a collection of columns805,810,815,820,825,830that associate their contents into a series of records835,840,845,850. Column805includes a collection of document numbers. The document numbers can each identify, e.g., a relevant sales order. For example, the document numbers of records835,840both identifier the same sales order “100001.” Column810includes a collection of document item identifiers. The document item identifiers can identify, e.g., an item purchased in the identified sales orders. Column820includes a collection of order quantity identifiers. The order quantity measures can characterize, e.g., the quantity of items purchased in the identified sales orders. Column825includes a collection of unit of measure identifiers. The unit of measure identifiers can identify, e.g., the units of measure of the quantities of items purchased in the identified sales orders. Additional columns815,830can include additional information regarding the identified sales orders.

In setting forth part of the prior contents of a reporting or other data model store, records835,840,845,850can, for example, set forth the same values that they set forth when table800was initialized. As another example, records835,840,845,850can set forth the same values at they set forth when table800was last updated.

FIG. 9is a table900that schematically represents a portion of the subsequent contents of a reporting model or other data store. For example, table900can be part of reporting model data store120(FIG. 1) after an update. Table900can also be part of active record store710after an update or part of activation queue store705.

Table900includes a collection of columns905,910,915,920,925,930that associate their contents into a series of records935,940,945. Column905includes a collection of document numbers. Column910includes a collection of document item identifiers. Column920includes a collection of order quantity measures. Column925includes a collection of unit of measure identifiers. Additional columns915,930can include additional information regarding the identified sales orders.

In setting forth part of the subsequent contents of a reporting or other data model store, records935,940,945can set forth more current values in a data processing system. For example, records935,940,945can set forth more current values that were propagated into table900during an update. In particular, record935indicates that the quantity of items “10” ordered in sales order document number “100001” decreased by 10%, i.e., to 180 pieces, from the prior value of 200 pieces set forth in record835of table800(FIG. 8). Record935indicates that the quantity of items “20” ordered in sales order document number “100001” increased by 10%, i.e., to 165 pieces, from the prior value of 150 pieces set forth in record840of table800(FIG. 8).

FIG. 10Ais a table1000that schematically represents example additive delta records. The additive delta records can be uploaded into a reporting model or other data store to change reporting from the reporting model or other data store without an update and can reside in the reporting model or other data store until an update. For example, table1000can be part of change log715before uploading or part of reporting model data store120after uploading.

Table1000includes a collection of columns1005,1010,1015,1020,1025,1030that associate their contents into a series of records1035,1040,1045. Column1005includes a collection of document numbers. Column1010includes a collection of document item identifiers. Column1025includes a collection of unit of measure identifiers. Additional columns1015,1030can include additional information regarding the identified sales orders.

Column1020includes a collection of additive deltas of order quantity measures. In particular, the additive deltas of column1020are numeric values that describe the magnitude of a change to a prior numeric order quantity measure. In particular, the additive delta set forth in row1035indicates that the prior value of 200 pieces of item “10” in sales order document number “100001” set forth in record835of table800(FIG. 8) has been decreased by 20 pieces to accurately reflect a more current value. The additive delta set forth in row1040indicates that the prior value of 150 pieces of item “20” in sales order document number “100001” set forth in record840of table800(FIG. 8) has been increased by 15 pieces to accurately reflect a more current value. Please note that negative additive deltas (e.g., an additive delta of “−20”) can be used to reduce the numeric value of a measure.

FIG. 10Bis table1050that schematically represents other examples of additive delta records. Table1050can be part of change log715before uploading or part of reporting model data store120after uploading.

Table1050includes columns1005,1010,1015,1020,1025,1030that associate their contents into a series of records1055,1060,1065,1070. In table1050, multiple records are used to describe additive deltas of a single order quantity measure. For example, row1055indicates that the prior value of 200 pieces of item “10” in sales order document number “100001” set forth in record835of table800(FIG. 8) has been decreased by 200 pieces and row1060indicates that the value of item “10” in sales order document number “100001” has been increased by 180 pieces. Together, rows1055,1060describe additive deltas to accurately reflect a more current value of the single order quantity measure. As another example, row1065indicates that the prior value of 150 pieces of item “20” in sales order document number “100001” set forth in record840of table800(FIG. 8) has been decreased by 150 pieces and row1070indicates that the value of item “20” in sales order document number “100001” has been increased by 165 pieces. Together, rows1065,1070describe additive deltas to accurately reflect a more current value of the single order quantity measure.

Returning toFIG. 7, in operation, data flow paths720,725,730in reporting model delta data store115can convey data to allow reporting model delta data store115to be integrated into hybrid data provider160.

In particular, at some time To after initiation, data flow path135conveys information describing changes to data storage in one or more transactional data models in transactional model data store110. The information conveyed along data flow path135is received and enqueued at activation queue705. As the received information is dequeued, data flow paths720,725,730can be used to convey that information to change log715and active records710. As information is dequeued, it is expunged from activation queue705.

The conveyance of information along data flow paths720,725,730can depend upon the nature of the changes that are to be made. For example, information describing an insert that is to create a new record in both change log715and active records710can be conveyed directly from activation queue705to change log715along data flow path720and from activation queue705to active records710along data flow path725.

As another example, information describing an deletion that is to remove an existing record in active records710can be conveyed to from activation queue705to active records710along data flow path725. The existing record that is to be removed can be selected from active records710. The key figures in the selected record can then be inverted and the inverted record can be conveyed from active records710to change log715along data flow path730.

As yet another example, information describing an update that is to change one or more key figures in an existing record in active records710can be conveyed to from activation queue705to active records710along data flow path725. The existing record that is to be changed can be selected from active records710. The key figures in the selected record can then be inverted and the inverted record can be conveyed from active records710to change log715along data flow path730. The existing record can also be updated in active records710, and the updated record conveyed from active records710to change log715along data flow path730. Thus, the conveyance of multiple records from active records710to change log715can be used to describe additive deltas of even a single measure, much like rows1055,1060(FIG. 10B).

In response to receiving information along data flow path725, active records data store710can incorporate the received information into a data structure that has been updated to more accurately reflect the current state of information in system100. One example of a portion of such an active records data store710is table900(FIG. 9). Active records data store710can thus include the complete information content of both reporting model data store120and change log715.

In response to receiving information along data flow path720, change log715can incorporate the received information into additive delta records that associate additive deltas with identifiers of the records in reporting model data store115that are no longer current. The records can be accumulated in a data structure, such as data table1000(FIG. 10). Such data structures thus characterize the reporting model delta and can be accessed by analytic engine125along data flow path140to provide an aggregated result set even before the reporting model deltas are committed to reporting model120along data flow path145. Once reporting model deltas are committed to reporting model120, they can be expunged from change log715. Change log715is thus not complete in that it does not contain all the information that has been dequeued from activation queue705regarding the contents of one or more transaction models in transaction model data store110. Rather, change log715only contains pending additive delta records that have yet to be committed to reporting model120. Thus, a level marker than denotes which changes have been committed from change log715to reporting model120is unnecessary

FIG. 11is a schematic representation of another system1100that includes a hybrid data provider. In addition to interface105, transactional model data store110, reporting model delta data store115, reporting model data store120, and analytic engine125, system1100also includes an indexed data store1105.

Indexed data store1105is a collection of information that is stored at one or more data storage devices. Indexed data store1105can store this information in one or more documents, data structures, data models, or other data storage devices (hereinafter “documents”) that are indexed to an inverted index and searchable through the index. Indexed data store1105can thus be searched, e.g., using fuzzy text searching, Boolean searching, attribute searching, linguistic searching, advanced text mining searches, and the like. For example, indexed model data store1105can be searched using the Text Retrieval and Information Extraction service (TREX) component of SAP Netweaver (SAP AG, Walldorf, Germany).

In operation, indexed data store1105can receive and incorporate more current information along a data flow path1110from reporting model data store120as shown, or indexed data store1105can receive and incorporate more current information along data flow paths from other sources, such as, e.g., directly from transactional model data store110(FIG. 1). This information, along with other information stored at indexed data store1105, can be used to respond to queries and other searches by analytic engine125jointly with reporting model delta data store115and reporting model data store120, as represented by data flow path1115. Thus, reporting model delta data store115, reporting model data store120, and indexed data store1105can act as hybrid data provider160and allow analytic engine125to aggregate result sets across all three data stores.

In one implementation, namely, when indexed data store1105receives and incorporates more current information along data flow path1110from reporting model data store120, the data content of indexed data store1105is generally less current than the data content of transactional model data store110, reporting model delta data store115, and reporting model data store120. This is represented inFIG. 12, which is a graph1200that schematically represents how current the data content of transactional model data store110, reporting model delta data store115, reporting model data store120, and indexed data store1105are at a time T1.

As can be seen, the vertical position of a line1205is lower than the vertical position of lines215,220,225, denoting that even less of the data in indexed data store1105is current than the data in reporting model data store120, the data in reporting model delta data store115, and the data in transactional model data store110. However, with analytic engine125providing aggregated result sets drawn from all of reporting model delta data store115, reporting model data store120, and indexed data store1105, the benefits of quick data access in indexed data store1105and reporting model data store120for the majority of the data can be combined with the benefit of early access to more current data in reporting model delta data store115. In particular, even recent transactions will appear in result sets generated by analytic engine125with a minor additional cost associated with the access and retrieval of data from reporting model delta data store115.

A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made. For example, process steps can be performed in different order, and steps can be omitted, and meaningful results nevertheless achieved. As another example, system elements can be arranged in different order or omitted and meaningful results nevertheless achieved. As yet another example, in some implementations, data flow paths725,730can be used to convey dequeued information to both change log715and active records710and data flow path720can be omitted. Accordingly, other implementations are within the scope of the following claims.