Abstract:
A system may include a database of physical data tables including stored data, and an abstraction layer associated with the stored data. The abstraction layer may include a measure object associated with a measure, a plurality of dimension objects associated with respective dimensions, a first analysis group object linked to the measure object, to a first one or more of the plurality of dimension objects, and to a first portion of the stored data associating the measure with respective dimensions of the first one or more of the plurality of dimension objects, and a second analysis group object linked to the measure object, to a second one or more of the plurality of dimension objects, and to a second portion of the stored data associating the measure with respective dimensions of the first one or more of the plurality of dimension objects and of the second one or more of the plurality of dimension objects.

Description:
BACKGROUND 
       [0001]    Business data is typically stored within physical tables of a database. The database may comprise a relational database such as SAP MaxDB, Oracle, Microsoft SQL Server, IBM DB2, Teradata and the like. Alternatively, the database could be a multi-dimensional database, an eXtendable Markup Language document, or any other structured data storage system. The physical tables may be distributed among several relational, dimensional, and/or other data sources. 
         [0002]    The structures of and relationships between the physical database tables are complex. A typical end user is therefore unable to locate or extract desired information from the physical database tables. Business Intelligence (BI) tools (e.g., BusinessObjects Information Designer®) may therefore be used to build an abstraction layer that shields end users from the complexity of the physical tables. More specifically, the abstraction layer allows the end users to query a database using intuitive terms rather than references to specific physical entities of the database. 
         [0003]    Commonly-assigned and co-pending U.S. patent application Ser. No. 12/463,702 describes such an abstraction layer, referred to therein as a semantic layer. Briefly, the “business objects” of an abstraction layer represent business entities, such as customers, products, stores, time, sales figures, etc., represented in the data of a data source. Business objects may be classified as dimension objects (i.e., to represent dimensions along which one may want to perform an analysis or report), detail objects (e.g., to represent additional information on dimensions), and measure objects (e.g., to represent indicators, most often numeric, whose value can be determined for a given combination of dimension values). In one example, a Sales measure object may be used to determine the total sales for January (i.e., a value of the Month dimension object) in France (i.e., a value of the Country dimension object). 
         [0004]    Within a business, the same data (e.g., revenue) may be tracked by different departments at different levels of granularity. For example, at the corporate level, revenue may be recorded for each line of business, while each line of business may record revenue at the product level. Due to data entry errors, incomplete data, etc., the total revenue recorded by a particular line of business (i.e., the aggregation of revenues associated with each product of the line of business) may not equal the revenue recorded for that line of business at the corporate level. 
         [0005]      FIG. 1  displays portions of physical database tables  110 ,  120  and  130  which illustrate the foregoing scenario. Tables  110 ,  120  and  130  may be contained in a data warehouse associated with a particular business. According to the present example, table  110  may be considered sales data compiled at the corporate level. Each row of table  110  associates a month and a company with sales figures for that company during that month. 
         [0006]    Table  120  includes sales data compiled at the activity level. Each row of table  120  associates a month, a company and an activity with sales figures for that month, company and activity. Lastly, it may be assumed that table  130  includes sales data compiled by a particular company at the product level. The data of tables  110 ,  120  and  130  may appear partially redundant, however, since these tables are fed independently, several inconsistencies are exposed therein. 
         [0007]    For example, table  110  shows total sales of 10000 for the company “Acco” in January 2008 (i.e., 01/08). In contrast, table  120  shows total sales of 9490 (i.e., 5000+4490) for the same company and period. Moreover, table  120  shows sales of 5000 during January 2008 for Acco and the activity “metal”, while table  130  shows sales of 5020 (i.e., 2000+2000+1020) for the same period, company and activity. 
         [0008]      FIG. 2  illustrates database table  200  including the data of tables  110 ,  120  and  130 . Database table  200  therefore shows sales data compiled at different levels of granularity. Database table  200  will be used to demonstrate that, if sales data is stored at different levels of granularity, the desired value of a Sales measure usually cannot be determined by aggregating the stored sales data at its most granular level. 
         [0009]    More specifically, a case is considered in which a Sales measure of an abstraction layer is bound to column  202  of  FIG. 2 , and dimensions Month, Company, Activity and Product are bound to columns  204 ,  206 ,  208  and  209 , respectively. The query {Dim: 1/08, Dim: Acco, Meas: Sales} will provide the result 24,510, which is the sum of column  202  for each row of table  200  which includes the month 1/08 and the company Acco. This result is virtually meaningless from a business standpoint. 
         [0010]    Conventional systems attempt to address the foregoing by creating a different measure for each level of granularity of a single measure (e.g., Sales).  FIG. 3  illustrates data model  300  of a conventional Online Analytic Processing (OLAP) system including such different measures. 
         [0011]    Data model  300  includes CorporateSales measure  310 , SalesbyActivity measure  320 , and SalesbyActivityandProduct measure  330 . Each measure is independent from the others and individually declares the dimensions that govern it. CorporateSales measure  310  is governed only by Month dimension  340  and Company dimension  350 , SalesbyActivity measure  320  is governed only by Month dimension  340 , Company dimension  350  and Activity dimension  360 , and SalesbyActivityandProduct measure  330  is governed only by Month dimension  340 , Company dimension  350 , Activity dimension  360  and Product dimension  370 . 
         [0012]    With reference to  FIG. 1 , CorporateSales measure  310  may be bound to column  112  of table  110 , SalesbyActivity measure  320  may be bound to column  122  of table  120  and SalesbyActivityandProduct measure  330  may be bound to column  132  of table  130 . The sales data collected at each level of granularity may therefore be accessed independently via the three measures CorporateSales, SalesbyActivity, and SalesbyActivityandProduct. 
         [0013]    The measures of data model  300  are considered orthogonal to one another. In other words, data model  300  does not provide a data consumer with any indication of relationships between the measures which may actually exist in the underlying physical tables. Consequently, data model  300  does not provide any mechanism for semantically drilling down or drilling up among the multiple analysis levels represented by the measures. The multiple analysis levels may introduce data discrepancies due to simplification or errors. The existence and nature of the differences between the analysis levels would assist a data consumer in evaluating the reliability of data which is retrieved through each analysis level. 
         [0014]    What is needed is an efficient system to represent a same measure which is tracked at different levels of detail and to facilitate navigation between the levels. Such a system may reduce a need to maintain multiple unrelated representations of a same measure, and may provide more meaningful evaluation of stored data and of the discrepancies reflected therein. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0015]      FIG. 1  illustrates portions of physical database tables. 
           [0016]      FIG. 2  illustrates a portion of a physical database table. 
           [0017]      FIG. 3  is a representation of a prior art OLAP data model. 
           [0018]      FIG. 4  is a UML instance diagram according to some embodiments. 
           [0019]      FIG. 5  is a UML class diagram according to some embodiments. 
           [0020]      FIG. 6  is a block diagram of a system to generate an abstraction layer according to some embodiments. 
           [0021]      FIG. 7  is a UML instance diagram according to some embodiments. 
           [0022]      FIG. 8  is a block diagram of a system to consume data based on an abstraction layer according to some embodiments. 
           [0023]      FIG. 9  is an outward view of a user interface presenting data retrieved based on an abstraction layer according to some embodiments. 
           [0024]      FIG. 10  is an outward view of a user interface presenting data retrieved based on an abstraction layer according to some embodiments. 
           [0025]      FIG. 11  is an outward view of a user interface presenting data retrieved based on an abstraction layer according to some embodiments. 
           [0026]      FIG. 12  is an outward view of a user interface presenting data retrieved based on a prior art OLAP data model. 
       
    
    
     DETAILED DESCRIPTION 
       [0027]    The following description is provided to enable any person in the art to make and use the described embodiments and sets forth the best mode contemplated for carrying out some embodiments. Various modifications, however, will remain readily apparent to those in the art. 
         [0028]      FIG. 4  illustrates UML class diagram  400  of an abstraction layer based on the  FIG. 2  data according to some embodiments. Diagram  400  includes Sales measure object  410  associated with a measure (i.e., sales) represented within stored data of a data source. Also included are Month dimension object  420 , Company dimension object  430 , Activity dimension object  440 , and Product dimension object  450 , each of which is associated with a respective dimension (i.e., month, company, activity, product) represented in the stored data. 
         [0029]    Diagram  400  further includes Corporate Analysis analysis group object  460 , Breakdown by Activity analysis group object  470 , and Breakdown by Product analysis group object  480 . Each analysis group object is linked to Sales measure object  410  and to a unique set of governing dimension objects. Diagram  400  therefore provides different levels of analysis for a single semantic measure rather than different semantic measures for each level of analysis as shown in  FIG. 3 . 
         [0030]    Specifically, Corporate Analysis analysis group object  460  is linked to Month dimension object  420  and Company dimension object  430 , while Breakdown by Activity analysis group object  470  is linked to Month dimension object  420 , Company dimension object  430  and Activity dimension object  440 . Lastly, Breakdown by Product analysis group object  480  is linked to Month dimension object  420 , Company dimension object  430 , Activity dimension object  440  and Product dimension object  450 . 
         [0031]    Since each analysis group object represents a different level of analysis, each analysis group object is associated with a different binding to the stored data of the associated data source. Taking  FIG. 1  as an example, Corporate Analysis analysis group object  460  may be linked to table  110 , which associates the measure (sales) with the dimensions of the dimension objects to which Corporate Analysis analysis group object  460  is linked (i.e., month and company). Breakdown by Activity analysis group object  470  may be linked to table  120 , which associates the measure (sales) with the dimensions of the dimension objects to which Breakdown by Activity analysis group object  470  is linked (i.e., month, company and activity). Continuing with the example, Breakdown by Product analysis group object  480  may be linked to table  130 , which associates the measure (sales) with the month, company, activity and product dimensions. 
         [0032]    Similar bindings may be used in the case of table  200  of  FIG. 2 . Specifically, Corporate Analysis analysis group object  460  may be linked to those rows of table  200  in which only the values of Activity and Product are &lt;null&gt;, Corporate Analysis analysis group object  460  may be linked to those rows of table  200  in which only the value of Product is &lt;null&gt;, and Breakdown by Product analysis group object  480  may be linked to those rows of table  200  in which no column value is &lt;null&gt;. Other binding schemes may be employed to link analysis group objects to stored data of a corresponding analysis level. 
         [0033]      FIG. 5  is a UML class diagram according to some embodiments. Diagram  500  illustrates objects of which the  FIG. 4  objects are instances. 
         [0034]    As illustrated, and as described in aforementioned U.S. patent application Ser. No. 12/463,702, an instance of Measure object  510  knows the instances of Dimension object  520  which govern its values. A Dimension object is said to govern a Measure object if, within a query including the Measure object, the selection of some members of that Dimension object affects the measure value returned by the query. 
         [0035]    Instances of Analysis Group object  530  aggregate instances of Measure object  510 . Instances of Analysis Group object  530  therefore define the Dimension objects which govern instances of Measure object  510 . An instance of Measure object  510  (e.g., Sales measure object  410 ) may belong to several instances of Analysis Group object  530  (e.g., Corporate Analysis analysis group object  460 , Breakdown by Activity analysis group object  470 , and Breakdown by Product analysis group object  480 ), and an instance of Analysis Group object  530  (e.g., Corporate Analysis analysis group object  460 ) may be linked to one or more other instances of Analysis Group object  530  (e.g., Breakdown by Activity analysis group object  470 ) which add one or more other governing Dimension objects (e.g., Activity dimension object  440 ). 
         [0036]    System  600  of  FIG. 6  comprises an architecture to define an abstraction layer according to some embodiments. Each element of  FIG. 6  may be implemented by any suitable combination of hardware and/or software. 
         [0037]    As illustrated, information designer  610  may create abstraction layer metadata  620  based on relational data source(s)  630  and OLAP data source(s)  635 . Abstraction layer metadata  620  defines objects of an abstraction layer to represent data of data source(s)  630  and  635 . The abstraction layer may comprise an abstraction layer as described herein including one or more analysis group objects. 
         [0038]    Information designer  610  may comprise a standalone, Web-based or other application executing on any computing device or devices that are or become known. Data source(s)  630  and  635  may comprise any query-responsive data source or sources that are or become known, including but not limited to a structured-query language (SQL) relational database management system. Dashed lines are used in  FIG. 6  to indicate that a connection between relational data source(s)  630  and  635  and information designer  610  need not exist before, during, or after generation of abstraction layer metadata  620 . Such a connection, if established, may comprise any suitable database connection (e.g., Java Database Connector, QT/Connection Server). 
         [0039]      FIG. 7  illustrates UML instance diagram  700  of an abstraction layer according to some embodiments. The abstraction layer includes analysis group objects which are linked to more than one measure object. Accordingly, these analysis group objects may be used to represent multiple analysis levels for each of the linked measure objects. 
         [0040]    Objects  710  through  780  are linked as described above with respect to similarly-numbered objects of UML instance diagram  400 . However, Corporate Analysis analysis group object  760  and Breakdown by Activity analysis group object  770  are also linked to Cost measure object  790 . Accordingly, Corporate Analysis analysis group object  760  is linked to a portion of stored data which associates the cost measure with the month and company dimensions, and Breakdown by Activity analysis group object  770  is linked to a portion of stored data which associates the cost measure with the month, company and activity dimensions. 
         [0041]      FIG. 7  also includes Headcount measure object  795  that is not linked to any analysis group object. Instead, Headcount measure object  795  is linked to Month dimension object  720  and Company dimension object  730 . This arrangement may indicate that the headcount measure is presented at only one level of analysis (i.e., with respect to month and company dimensions) in the stored data associated with diagram  700 . 
         [0042]    As shown, Cost measure object  790  is not linked to Breakdown by Product analysis group object  780 . Accordingly, unlike Sales measure object  710 , Cost measure object  790  is not represented in the stored data at the level of analysis associated with Breakdown by Product analysis group object  780  (i.e., with respect to month, company, Activity and Product dimensions). 
         [0043]    As described above, some embodiments facilitate the modeling of measure values acquired at different levels of analysis, or dimensional depths. Such modeling may be consumed so as to improve the navigation and understanding of such values. 
         [0044]      FIG. 8  illustrates runtime architecture  800  according to some embodiments. Generally, consumers  810  through  814  comprise software applications for object-based viewing of stored business data and/or creating object-based reports including stored business data. Examples of consumers  810  through  814  include BusinessObjects Web Intelligence, Crystal Reports, and BusinessObjects Explorer. Any number of reporting clients of one or more types may be supported according to some embodiments. 
         [0045]    Central management system  820  includes abstraction layer metadata  822  corresponding to data stored among one or more of relational data sources  830 / 832  and OLAP data source  834 . Embodiments are not limited to the number and types of data sources shown in  FIG. 8 . Abstraction layer metadata  822  describes objects mapped to logical entities of relational data sources  830 / 832  and OLAP data source  834 . 
         [0046]    Information engine  840  presents data of data sources  830  through  834  to consumers  810  through  814 . The presentation may be provided by a viewing/navigation component such as BusinessObjects Explorer or via a reporting engine. In some embodiments, information engine  840  may communicate with consumers  810  through  814  to allow a user to generate a query based on abstraction layer metadata  820 . Information engine  840  may operate to query appropriate ones of data sources  830  through  834  based on the generated query and metadata  820 , and may present results to consumers  810  through  814 . 
         [0047]    For purposes of consumption, an analysis group object can be exposed as a dimension (e.g., to limit the concepts which must be understood by a user), or as an analysis group object per se.  FIGS. 9 through 11  include outward views of user interfaces to present data via an abstraction layer according to some embodiments. The abstraction layer underlying  FIGS. 9 through 11  may be similar to that represented by diagram  700  of  FIG. 7 . 
         [0048]    Within these views, analysis group objects are presented as an additional dimension (i.e., “Analysis”). User interface  900  of  FIG. 9  initially shows data associated with Corporate Analysis analysis group object  760 . Moreover, the views may expose analysis paths between the analysis group objects to facilitate navigation there through. 
         [0049]    User interface  900 , for example, includes tooltips  905  through  915 . Tooltips  905  through  915  may assist a user in selecting a relevant breakdown for the set of measures being analyzed. 
         [0050]    In particular, the link of tooltip  905  allows drilling to Cost and Sales data associated with Breakdown by Activity analysis group object  770 , while the links of tooltip  910  provide drilling to Sales data associated with Breakdown by Activity analysis group object  770  and Breakdown by Product analysis group object  780 . Since Cost measure object  790  is not linked to Breakdown by Product analysis group object  780 , tooltip  915  only offers a link to Cost data associated with Breakdown by Activity analysis group object  770 . 
         [0051]    User interface  1000  of  FIG. 10  may be presented if the user selects the link of tooltip  905 . Analysis column  1010  now reads “By Activity” and the dimension object governed by Breakdown by Activity analysis group object  770  (i.e., Activity) is added in new column  1020 . In some embodiments, measures not governed by the newly-displayed dimension, such as Headcount in the present example, may be displayed in a different manner than the other measures as shown. 
         [0052]      FIG. 11  shows user interface  1100  for comparing data associated with different analysis levels according to some embodiments. For example, Sales data  1110  captured at the Corporate Analysis level (e.g., by the “Corporate” department) can be compared with Sales data  1120 , which is the sum of Sales data recorded for each Activity at the Breakdown by Activity level. Such a presentation apprises the report consumer of the consistency of the different data sources. 
         [0053]      FIG. 12  illustrates user interface  1200 , which is a view of the data underlying view  1100 , but as provided by a conventional OLAP system. As shown, interface  1200  does not provide semantic guidance into possible navigation paths through the data. Moreover, data comparison requires reading each individual cell and locating measures to be compared. 
         [0054]    Some embodiments facilitate the creation and management of novel calculations. For example, a single formula (e.g., Revenue=Sales−Cost) may be created to calculate a new measure from existing measures. Advantageously, the single formula would be valid for all levels of analysis with respect to underlying data reflecting different analysis levels. A conventional system would, in contrast, require one formula for each measure (e.g., Corporate Revenue=Corporate Sales−Corporate Cost, By Activity Sales=By Activity Sales−By Activity Cost, . . . ). 
         [0055]    Some embodiments also support usage of formulae to calculate the difference between different analysis levels (e.g, Corporate/By Product analyses delta=Corporate−By product). Such a formula could be presented as part of an analysis “dimension” as described above to be used by all measures linked to these two analysis groups objects. Again, conventional systems would require as many formulas as there are measures. 
         [0056]    Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.