US20020038297A1 - Allocation measures and metric calculation - Google Patents

Allocation measures and metric calculation Download PDF

Info

Publication number
US20020038297A1
US20020038297A1 US09/844,706 US84470601A US2002038297A1 US 20020038297 A1 US20020038297 A1 US 20020038297A1 US 84470601 A US84470601 A US 84470601A US 2002038297 A1 US2002038297 A1 US 2002038297A1
Authority
US
United States
Prior art keywords
measure
star
level
levels
dimension
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US09/844,706
Other versions
US7080090B2 (en
Inventor
Arun Shah
Robert Novy
Robert Ertl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle International Corp
Original Assignee
Brio Software Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from PCT/US2001/012501 external-priority patent/WO2001080095A2/en
Priority to US09/844,706 priority Critical patent/US7080090B2/en
Application filed by Brio Software Inc filed Critical Brio Software Inc
Assigned to BRIO TECHNOLOGY, INC. reassignment BRIO TECHNOLOGY, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ERTL, ROBERT A., NOVY, ROBERT F., SHAH, ARUN
Publication of US20020038297A1 publication Critical patent/US20020038297A1/en
Assigned to HYPERION SOLUTIONS CORPORATION reassignment HYPERION SOLUTIONS CORPORATION MERGER (SEE DOCUMENT FOR DETAILS). Assignors: BRIO SOFTWARE, INC.
Assigned to BRIO SOFTWARE, INC. reassignment BRIO SOFTWARE, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: BRIO TECHNOLOGY, INC.
Publication of US7080090B2 publication Critical patent/US7080090B2/en
Application granted granted Critical
Assigned to ORACLE INTERNATIONAL CORPORATION reassignment ORACLE INTERNATIONAL CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BEA SYSTEMS, INC.
Assigned to ORACLE INTERNATIONAL CORPORATION reassignment ORACLE INTERNATIONAL CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HYPERION SOLUTIONS CORPORATION
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24553Query execution of query operations
    • G06F16/24554Unary operations; Data partitioning operations
    • G06F16/24557Efficient disk access during query execution
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/283Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/953Organization of data
    • Y10S707/957Multidimensional
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99942Manipulating data structure, e.g. compression, compaction, compilation
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99943Generating database or data structure, e.g. via user interface

Definitions

  • a business's data is stored on a database or on databases. These databases are operated with associated database servers, which manage the storage and retrieval of records from the databases.
  • Analytical servers have additionally been provided to format database queries or information requests sent from a client user interface to the database server for handling. The analytical servers can be used to improve the efficiency of the database accesses and to provide metrics of interest to the user from the retrieved records from the database.
  • the embodiments disclosed below provide an analytical server which efficiently accesses a Relational Database Management System (“RDBMS”) comprising a database and a database server.
  • the database in this approach includes fact and dimension tables which may be, for example, configured in a star schema having a central base_fact table with surrounding dimension tables to form the star structure. Aggregate_fact tables may also be provided which aggregate measures from the base_fact table at a higher hierarchical level than such measures are maintained in the base fact table.
  • Metadata is further stored in the database, where the metadata describes the organization of the various tables in the database, and specifically the metadata in the embodiments described below includes information about the hierarchical levels of various dimensions of the above-mentioned tables and star schema.
  • the analytical server described herein receives the metadata from the database and analyzes that metadata, including the hierarchical information, in order to provide relatively efficient access to the tables of the database in response to a query from a user.
  • Such efficient access preferably supports calculation of complex metrics which might otherwise be difficult or impossible.
  • Supported levels of stars are defined and analyzed in a sophisticated and efficient manner which facilitates the calculation of chameleon and allocated metrics.
  • a user can easily limit the data to a particular set of value(s) for a particular hierarchy level, known as slicing.
  • the user can also view the metrics by moving up or down through a hierarchy, known as drilling.
  • fact level security and dimensional security are supported, as well as efficient collection and analysis of aggregate_fact table usage statistics.
  • FIG. 1 is a block diagram describing an exemplary computer architecture
  • FIG. 2 is a block diagram of a metadata structure for a hierarchy
  • FIG. 3A is a block diagram describing a star schema
  • FIG. 3B is a block diagram of a metadata structure for a star
  • FIG. 4 is a block diagram of a metadata structure for a measure indicator
  • FIG. 5 is a block diagram of a metadata structure for a metric indicator
  • FIG. 6 is a flow diagram describing calculation of a metric
  • FIG. 7 is a flow diagram describing carpooling
  • FIG. 8 is a flow diagram describing a rollup of a metric
  • FIG. 9 is a flow diagram of the calculation of an allocation metric
  • FIG. 10 is a block diagram describing an exemplary graphical user interface
  • FIG. 11 is a block diagram describing an exemplary hardware environment wherein the present invention can be practiced.
  • the computer architecture 100 comprises a relational database management system (RDBMS) 105 , a database or data warehouse 110 , an interface 140 , and an analytical server 120 .
  • RDBMS relational database management system
  • the computer architecture 100 comprises a relational database management system (RDBMS) 105 , a database or data warehouse 110 , an interface 140 , and an analytical server 120 .
  • RDBMS relational database management system
  • the computer architecture 100 comprises a relational database management system (RDBMS) 105 , a database or data warehouse 110 , an interface 140 , and an analytical server 120 .
  • RDBMS relational database management system
  • the database 110 is accessible by the analytical server engine 120 .
  • the analytical server engine 120 accepts requests for metric calculations from clients 135 , uses the metadata structures 145 to identify the necessary fact components and the best star schema for accessing them, generates and executes structured queries in a database query language, such as Structured Query Language (SQL), performs outer joins to conform query results, calculates the desired metrics, and returns them to the clients in a structured form such as multidimensional cubes.
  • SQL Structured Query Language
  • the clients access the analytical server via an application programming interface (API) 140 , through which metrics can be requested, possibly constrained on dimensional values.
  • API application programming interface
  • the query and metric calculation results are transmitted through the interface as objects.
  • the client need not have knowledge of how the metric is calculated.
  • the database 110 includes a collection of base_fact tables 125 a and dimension tables 125 b organized in multiple star schemas 125 . Exemplary star schemas are described in Ralph Kimball, THE DATA WAREHOUSE TOOLKIT (John Wiley & Sons 1996 ), which is hereby incorporated by reference for all purposes. Additionally, the database includes aggregate fact tables 130 . The aggregate_fact tables 130 contain values summarized from the base_fact tables 125 a to certain specified levels of one or more dimensions. An aggregate fact table 130 is more efficient and preferable to access than a base_fact table 125 a , provided the level of detail of a given aggregate_fact table 130 is still sufficient for a given query. Additionally, a set of metadata structures 145 describe the contents of, and relationships between, the various fact and dimension tables 125 a , 125 b .
  • the metadata structures 145 provides information for the analytical server 120 to determine how to access the database 110 for the values required to construct requested metrics and defines more abstract constructs, such as particular metrics which can be computed from one or more facts in the database 110 .
  • the metadata structures 145 include structures for hierarchies, stars, measure indicators, and metric indicators.
  • a hierarchy 205 defines levels 210 with a minimum of two levels.
  • the top level encompasses all elements, while successive levels further subdivide the elements into one or more non-overlapping groups.
  • Each level 210 is associated with a level name 210 a , level number 210 b , and column name 210 c .
  • the level names describe the grouping of the elements. In the exemplary case described in FIG. 2, the level names include “all,” “year,” “quarter,” “month,” “week,” and “day.”
  • the level number 210 b starts with 0 for the top level 210 and increases sequentially for each deeper level.
  • the column name 210 c is used to find the attribute values for the level in any table in the database which supports the hierarchy. For example, the column name 210 c for the “quarter” level 210 b may be used to find the attributes specifying the quarters of a particular database year.
  • a dimension table 125 b For a dimension table 125 b to be associated with a hierarchy 205 , the dimension table 125 b must contain the column names 210 c specified for the hierarchy 205 for the levels 1 . . . n. Multiple dimension tables 125 b may be associated with the same hierarchy 205 and support it to different levels. For example, a dimension table 125 b for Time might contain columns only for Year, Quarter, and Month, and therefore provided a supported level of “3,” while a more complete dimension table might contain columns for all levels down to “day,” and therefore offer a supported level of “5.”
  • FIG. 3A illustrates a star schema dimensional model
  • FIG. 3B provides a block diagram of an exemplary metadata structure for a single star within the database.
  • a star 300 has a single fact table 125 a having a number of records along multiple dimensions, which dimensions in turn point to corresponding dimension tables 125 b .
  • the fact table may be either a base level or aggregate level fact table.
  • the fact table 125 a may be a “Sales” fact table, which may in turn have facts in six defined dimensions: Products, Customers; Sales Geography; Manufacturing Location; Sales Reps; and Time. These dimensions will in turn refer to the dimension tables 125 b , which may be conceptually viewed as surrounding the fact table 125 a .
  • Exemplary hierarchical levels maintained within the dimension tables 125 b are also shown in FIG. 3A.
  • the star 300 comprising the fact table 125 a and the surrounding dimension tables 125 b can be used to apply selection constraints and specify aggregate groupings when retrieving the fact values.
  • a number of different stars can be identified in a database.
  • a star metadata structure 305 such as shown in FIG. 3B can be used to describe the various stars in a database.
  • Each star metadata structure 305 identifies an fact table 130 in the database from which values designated as facts may be obtained.
  • the star 300 For each supported hierarchy 205 (see FIG. 2), the star 300 identifies a specific dimension table 125 b to be used for performing hierarchical selection and grouping, and provides to the querying language (such as SQL), a constraint used to join the dimension table 125 b to the fact table 125 a.
  • the querying language such as SQL
  • the supported levels of the specific fact table 130 in the database are represented in a star metadata structure 305 by an array 310 of dimension indicators in which each dimension indicator 315 of the array 310 represents the supported hierarchical levels defined in a predetermined order. Additionally, an initialization process might ensure that the supported levels 210 are valid in all stars 300 , thereby eliminating the need for checking the column names during the star selection process.
  • a supported level 210 value is tracked for each dimension, specific to the star 300 and usually depending on the level 210 of data aggregation in the associated fact table.
  • the time dimension has been summarized to the “day” level, so the supported level 210 for Time in this particular star 300 will be “5,” while some other star containing only month-level fact values would support Time to level 3. If no dimension table 125 b has been assigned for some hierarchy 205 , then hierarchy 205 is not supported by the star 305 and the supported level is recorded as “0.”
  • the star metadata structure 305 may also include a flag 313 indicating the availability of the star 300 . Where the star is properly maintained or refreshed by some other mechanism, the flag 313 can be set to indicate whether the data in the star is available. The foregoing flag 313 can be examined during star selection.
  • the stars 300 are collected into groups called stargroups.
  • Aggregate_fact tables 130 are built for frequently accessed data, in a manner that reduces table size, join complexity, a query time. For example, sales figures might be accumulated at the “day” level in one aggregate_fact table 130 , and summarized more highly to the “month” level in some other aggregate_fact table 130 .
  • the stargroup used for accessing sales figures might contain two stars 300 , possibly using exactly the same dimension tables 125 b but each pointing to different aggregate_fact tables 130 .
  • the star 300 using the monthly aggregate fact table 130 would be assigned a higher aggregate rank, or in other words would contain measures at a higher hierarchical level, and would be preferred when values were not required at a finer grain than month.
  • FIG. 4 there is a block diagram of another metadata structure 145 , specifically a measure indicator 405 .
  • the measure indicator 405 identifies and describes a measure, which is a value that can be obtained directly from the database 110 .
  • the measure indicator 405 includes an identifier 410 , which identifies the facts within the database 110 that are being referred to. Also included in the measure indicator is a flag 411 which indicates whether or not the measure is additive.
  • the measure indicator 405 also contains a query language snippet 412 . To support aggregate navigation, the snippet 412 is defined using a syntax which allows substitution of specific fact table 125 a names and dimension table 125 b names. For example, a non-SQL character is used to delimit a substitutable form which is to be replaced by the name of the fact table in the associated star, prior to executing a query.
  • a measure may contain a plurality of snippets 412 , each associated with an indicator 415 indicating a particular stargroup. Verification that the columns specified in the snippets 412 actually appear in the fact tables 130 defined by each star 300 in the associated stargroup can be done during an initialization process, thereby limiting column name lookups.
  • Chameleon metrics represent a general concept, the exact definition or calculation of which is dependent on the dimension or level.
  • a cost metric when viewed by the product dimension, may measure production or part cost. However, when viewed by dimensions other than product, the cost includes the total product cost across all parts, freight, taxes! and other top-level costs.
  • Chameleon metrics are constructed by taking advantage of the provision for multiple snippet 412 /stargroup pairs in the underlying measure definitions. Using the Geography vs. Product forecast example, a measure is defined which uses two different stargroups. The snippet 412 associated with the first stargroup can cause the measure to be calculated in accordance with a first definition while the snippet 412 associated with the second definition cause the measure to be calculated in accordance with a second definition.
  • Fact-based redundancy can also be provided, for example, by providing additional security hierarchy fields 418 , 419 within the measure indicator 405 .
  • additional security hierarchy fields 418 , 419 within the measure indicator 405 .
  • the security hierarchy is defined in the measure indicator both at the broad level in field 418 and at the specific snippet level 419 . The definition at these different levels allows the facts to be accessed according to the measure's use within the star structure 300 or fact table 130 being accessed rather than just having a broad prohibition of accessing certain types of data by certain users or clients.
  • the metric indicator 505 includes a metric name 510 identifying a particular metric.
  • the metric name 510 is used in requesting results from the analytical server 120 .
  • the metric indicator 505 also includes identifiers 515 identifying measures and the operations to be performed thereon, to calculate the value of the metric.
  • the measures are obtained from the database 110 from any number of database queries, the metrics are calculated at the analytical server 120 after obtaining each measure.
  • A. Aggregate Navigation Referring now to FIG. 6, there is illustrated a flow diagram describing the calculation of a metric at an analytical server 120 .
  • the analytical server 120 receives a request to calculate a particular metric.
  • the analytical server 120 determines the specific measures required for calculating the metric from the metric indicator 515 (step 610 ). For each measure (step 615 ), the analytical server 120 selects the aggregate stargroup (step 620 ).
  • the analytical server 120 selects a particular measure and associated stargroup. Within the aggregate stargroup, the analytical server 120 selects (step 625 ) the star 300 associated with the most highly aggregated fact table 130 and determines whether the star supports each constrained dimension at the level required. The foregoing is measured by comparing (step 630 ) the requested level for each dimension in the metric request with the array 310 of dimension indicators 315 describing the supported levels 210 of the dimensions. Wherein the array 310 indicates that the requested level for each dimension is supported at the same or higher level, the star 300 is selected (step 630 ).
  • the fact table 130 associated with the star 300 is rejected (step 635 ), and a determination is made whether any remaining stars 300 are present in the stargroup. Wherein a remaining star 300 exists in the stargroup, the star 300 associated with the next most highly aggregated table 130 is selected (step 650 ) and steps 630 - 650 are repeated. Wherein there are no remaining stars 300 , data may not be obtained for the particular measure (step 655 ). Steps 622 - 655 are repeated for each measure required for the requested metric(s).
  • the analytical server 120 After selecting the star 300 , the analytical server 120 generates and conducts the queries for each measure on the selected tables 130 (step 660 ). The queries are generated by substituting the fact 125 a and dimension table 125 b names where indicated in the snippets 412 associated with the selected star 300 . After generating the queries, the analytical server 120 calculates the measures (step 665 ), calculates the metrics (step 670 ), and forwards the result to the client (step 675 ), thereby completing calculation of the metric.
  • the foregoing approach also permits maintenance of statistics which indicate the usage levels of each star 300 .
  • statistics can monitor events such as when a star 300 is considered for selection and rejected, a star 300 is selected for use, and when a star 300 is actually used in a query.
  • the required and supported hierarchical levels can also be recorded, thereby permitting examination of usage levels. From the foregoing information, it can be determined in a given circumstance that an additional level of detail should be added to the aggregate_fact table 130 because a majority of requests required the additional hierarchical level. Additionally, a determination can be made that the aggregate_fact table 130 can be consolidated without major effect on overall performance because a majority of requests require one less level of detail.
  • Certain queries can be conducted using a common fact table 130 .
  • certain fact tables 130 can include multiple aggregated facts. Wherein multiple queries request different measures, but with identical constraints, the aggregated facts can be combined into a single structured query, such as a SELECT statement in SQL. Alternatively, where in multiple queries, all but one constraint are identical, and the different constraint is constrained at the same level, the queries can also be combined.
  • the analytical server 120 can advantageously preprocess the requisite queries, possibly allowing a number of queries to be combined into a single query, resulting in relational database 110 access efficiencies.
  • FIG. 7 there is illustrated a flow diagram describing the operation of the analytical server 120 conducting queries, wherein the queries may be combined due to there being a number of queries seeking metrics along the same dimension broken down, preferably, to the same hierarchical level.
  • the combining of the queries reduces database load and in many cases improves database response time.
  • the analytical server 120 determines the fact table 130 from which to calculate each measure.
  • the analytical server determines which of a plurality of queries can be combined when accessing the database 110 .
  • the same base fact table 125 a is common between the queries to be combined, and there will be commonality to at least some of the dimension tables 125 b between the queries as well.
  • the queries can be combined for a single star or among a number of stars 300 , so long as there is the requisite commonality among the fact and dimension tables 125 a - b .
  • step 707 involves a determination of the hierarchical levels involved in the plurality of queries, and it is possible that even if a requested metric or metrics requires the same measures but at differing hierarchical levels, it may be possible to consolidate these into a single query of the database 110 and then extract the desired information needed for the different metric requests. For example, if some metric is broken down over the last six months and also for the corresponding six months in the previous year, the underlying measure for both requests can be obtained in a single query, simply by placing all desired month numbers in the “IN (1, m, n)” constraint, and selectively processing the results.
  • the analytical server 120 carpools combinable queries to reduce the number of queries actually made of the database 110 through the RDBMS 105 .
  • the analytical server 120 After carpooling the queries, the analytical server 120 generates the structured query commands for each of the database queries (step 715 ) and forwards (step 720 ) the structured database query commands to the RDBMS 105 .
  • the analytical server 120 can readily determine which measures are non-additive. By making this determination, the analytical server can allow the rollup to be handled transparently without making the non-additive attributes visible to the requester. This is accomplished by extending the metric result to contain an additional multidimensional array of totals.
  • the additional multidimensional array of totals may include or be based upon measures at different hierarchical levels than were necessary for the original (non-rollup) calculation. Alternatively, the original three-dimensional cube might simply reserve one extra element in the first dimension to contain the totals. Maintaining metadata 145 describing the hierarchical levels of the fact tables 130 allows for an efficient implementation of the transparent non-additive metric calculations described above.
  • FIG. 8 there is illustrated a flow diagram describing a rollup of a metric.
  • the metric is broken down into its component measures.
  • the component measures are separated into two groups or are conceptually treated as two groups, according to the additive/non-additive flags 411 , 416 (see FIG. 4). To the extent the rollup can be done for the additive measures without additional difficulty, this summing is done at step 815 .
  • the analytical server 120 Since the analytical server 120 knows which measures are additive and non-additive, the analytical server is able to adapt its inquiries and displays to minimize the possibility of displaying invalid results.
  • the analytical server 120 issues queries at the detail level only (business unit), and performs simple sums to calculate the totals. The individual measures are summed, and then the metric level calculations are performed using these sums.
  • the analytical server 120 When a measure is non-additive, the analytical server 120 instead generates and issues two separate queries, the extra query being for the total level (omitting the SELECT item and GROUP BY for Business Unit). In this way, complex metrics composed of any combination of additive and non-additive measures can be calculated correctly and efficiently, without requiring any knowledge or action on the part of the requester.
  • the additive/non-additive fields 411 , 416 are provided within the measure metadata structure to assist the analytical server 120 in determining whether certain measures or additive or not along certain dimensions.
  • the analytical server 120 may attempt to obtain the measures and calculate the metric at the total level only (even in the case where the measures are all additive). This can be done, for example, when the intention is to compare two metrics, such as sales vs. forecast, as when sales can be broken down by industry, customer, etc. but forecast is only available by product. In this case, forecast could still be compared to total sales across all industries or customers.
  • the server further extends the result object to provide indicators distinguishing such indicators as “all zero results”, “no data found”, “detail level not supported”, and so forth.
  • a metric which measures the average numbers of days that inventory will last is calculated by dividing the current inventory by the sales per day. Wherein one star measures sales and another star measures inventory, calculation of the inventory days on hand requires calculation of measures from both the sales star and the inventory star.
  • the analytical server 120 accesses the measures separately from each star 300 , and then performs the equivalent of an outer join on the results.
  • the different sets of results along the hierarchical level supplied in the request and retrieved by the queries are carefully “lined up”, thereby allowing the server 120 to encapsulate this knowledge and processing, and make sophisticated metrics available to the requestor.
  • Certain measures or metrics are “invariant” by dimension. For example, to calculate the metric sales per sales rep, a measure must exist for the denominator which gives the number of sales reps. Furthermore, it may be useful to look at the sales per rep metric broken down by product business unit, family, or item. If the number of sales reps is maintained in a sales forecast star, it can be accessed only by sales geography and time. However, since all reps sell all products, the measure reporting number of reps does not change whether looking at the business unit, family, or item level, the number of sales reps is invariant along the product dimension. Therefore, the sales forecast star is degenerate along the product dimension.
  • the analytical server is equipped with knowledge of measures which are invariant with respect to certain dimensions. Providing this knowledge to the analytical server allows a single value to be obtained as the invariant measure in the metric calculation, regardless of the level of the dimension to which the measure is invariant.
  • An allocation metric is a metric containing a measure that is not defined at the lowest dimension level, but which is useful and desirable to allocate a value for the metric at the lowest dimension using another measure which is definable at the lowest dimension.
  • Sales Forecast numbers may be available by Geography, Sales Rep, and Time, but not by Product Business Unit. However, suppose that Sales for the previous year are available by Product Business Unit and that it is a reasonable assumption that the breakdown of Sales by Product Business Unit will be similar to the breakdown of Sales Forecast by Product Business Unit. In such a case, the Sales Forecast by Product Business Unit can be calculated by the foregoing expression:
  • Allocated Forecast for Product (A) Total ⁇ ⁇ Forecast * Sales ⁇ ⁇ for ⁇ ⁇ Product ⁇ ⁇ ( A ) ⁇ ⁇ Last ⁇ ⁇ Year Total ⁇ ⁇ Sales ⁇ ⁇ Last ⁇ ⁇ Year
  • the measure “Forecast Sales” is the base measure while “Sales Last Year” is known as the control measure. Additionally, it should be noted that while Sales for Product(A) is at the same level as the request, i.e., at the Product Business Units level, the measures of Total Forecast and Total Sales Last Year are obtained at different levels, or “allocated levels”.
  • FIG. 9 there is illustrated a flow diagram describing calculation of an allocated metric.
  • the calculation of an allocated metric will be described using an exemplary case wherein a request is made for Forecasted Sales by Quarter, and Business Unit, across All Geographies.
  • the supported levels of the stars 300 are described in the following dimension order: Time, Product, and Geography.
  • the Time dimension is ordered from All, Year, Quarter, Month, Week, and Date.
  • the Product dimension is ordered from All and Business Unit.
  • the Geography is ordered from All, Continent, Country, State, and City.
  • the required levels for the request are determined.
  • the required levels are “ 210 .”
  • the star metadata structure 305 shown in FIG. 3 could be used to store, in a defined fashion in the array 310 of integers, the available hierarchical levels within a given star. If a star exists having the required levels, the metric is calculated (step 915 ) directly and the process is terminated. Wherein a star does not exist, the best data available for the base measure (Sales Forecast), which is simply the lowest ranked star in the stargroup, is selected (step 920 ).
  • the lowest ranked star is ranked as “ 303 ” which fails on the Product dimension.
  • the allocation levels are determined by taking the minimums of the required levels for the request and the levels of the star selected during step 920 .
  • the allocation levels are “ 200 ” in the exemplary case.
  • step 930 an attempt is made to find a star which supports the allocation levels in the base measure, e.g., the sales forecast in the present exemplary case.
  • step 935 an attempt is made to find a star in the control measure (the Sales Last Year) which support the required levels for the request (“ 210 ”).
  • the allocated measure is calculated (step 940 ), thereby completing calculation of the metric.
  • a star is not found in either steps 930 or 935 , the allocated measure cannot be calculated and calculation of the metric is terminated.
  • Data security is provided on both a dimension level and a fact level.
  • Each authorized user of the database can be associated with a particular security level which restricts the levels of each hierarchy which the user is permitted access. For example, regional sales managers can be permitted to only view sales at the regional level and not be authorized access to sales data at the national or worldwide level. Additionally, the users can be restricted access to a particular value of a hierarchical level. For example, a regional sales manager might be permitted to only view sales data from their region.
  • the dimension level security is provided by defining security groups which specify that all metric requests have to be performed as if the required level of a certain hierarchy is at least some predetermined level. The request is rejected outright if any of the requested levels are lower than the security levels.
  • the security definitions can also contain rules which force certain constraints. The force constraints are dynamically substituted to a given request.
  • An additional two level hierarchy is defined, wherein level zero is indicative that the data should not be visible, while level one is indicative that the data should be made visible.
  • the supported level for the added hierarchy is set at zero for each restricted metric and one for each unrestricted metric. Users who are restricted are placed in a security group that only permits access to level one of the hierarchy. Therefore, when a restricted user makes a query for the restricted metric, the security definition imposes a dimensional constraint of one for the additional hierarchy. During aggregate navigation, each of the stars will be rejected because the stars only support a level zero aggregation. For users who are permitted to access the restricted metric, the zero level dimensional constraint is imposed, however each of the stars support the zero level aggregation.
  • the analytical server 120 generates queries which are requested from the clients 135 .
  • the results of the query are forwarded to the clients via the API 140 .
  • Requests are also forwarded from the clients 135 to the analytical server 120 via the API 140 .
  • Communication of the requests from the clients 135 and the results from the analytical server 120 is facilitated by generation of a graphical user interface.
  • the graphical user interface is displayed at the client 135 and facilitates transmission of requests for queries and displays the results of the queries.
  • the GUI 1115 includes a hierarchical listing of each of the dimensions 1225 .
  • the user can click on a particular dimension 1225 and view metrics calculated for the constraint, as well as the lower levels of the dimension hierarchy. For each dimension, the user can either select a lower level or select a constraint to constrain the dimension.
  • the graphical user interface includes a set of metric buttons, wherein each metric button is associated with a predefined metric.
  • the user can have the metric calculated for the records with the selected constraints.
  • the user can click a query button and have constraints and selected metric forwarded to the analytical server 120 .
  • the analytical server 120 generates a structured query, transmits the structured query to the database server 105 , receives the results of the query.
  • the analytical server 120 calculates the selected metric, and prepares an object encapsulating the calculated metric for display in the GUI 1115 .
  • the retrieved data is displayed in the form of a results page 1305 .
  • the results page includes rows 1307 and columns 1308 of graphs 1310 . Each single graph 1310 can plot any number of metrics, such as profits and costs against the vertical axis.
  • Each row 1307 of graphs 1310 can represent metrics pertaining to each of the different values which comprise a level of a dimension 1220 , known as a slice. For example, each row could represent the metrics pertaining to a different country in the location dimension. Each column can represent a different quarter.
  • the GUI 1115 also includes a navigation bar for changing the dimension with an indicator button 1315 for each dimension.
  • the user can change the dimension displayed, known as slicing, by clicking on the appropriate indicator button 1315 .
  • the user can view the profits and costs from product to product by simply clicking on the product dimension indicator button 1315 .
  • the user can also traverse the levels of a dimension. For example, the user may wish to review graphs of metrics involving the various provinces of Canada. By clicking on the graph 1310 in the row representing the Canada, the user can then review graphs for the provinces of Canada. Alternatively, the user may wish to review graphs from a higher level in the location dimension, e.g., continent. To review the graphs 1310 on a higher level of the same dimension, the user clicks on the location dimension indicator button 1315 .
  • FIG. 11 a representative hardware environment for practicing the present invention is depicted and illustrates a typical hardware configuration of a computer system in accordance with the subject invention, having at least one central processing unit (CPU) 1860 .
  • CPU 1860 is interconnected via system bus 1812 to random access memory (RAM) 1864 , read only memory (ROM) 1866 , and input/output (I/O) adapter 1868 for connecting peripheral devices such as disc units 1870 and tape drives 1890 to bus 1862 , user interface adapter 1872 for connecting keyboard 1874 , mouse 1876 having button 1867 , speaker 1878 , microphone 1882 , and/or other user interfaced devices such as a touch screen device (not shown) to bus 1862 , communication adapter 1884 for connecting the analytical server to a data processing network 1892 , and display adapter 1886 for connecting bus 1862 to display device 1888 .
  • RAM random access memory
  • ROM read only memory
  • I/O input/output
  • FIG. 11 a representative hardware environment for practicing the present invention
  • the invention can be implemented as sets of instructions resident in the random access memory 1864 of one or more computer systems configured generally as described in FIG. 11.
  • the set of instructions may be stored in another computer readable memory, for example in a hard disk drive, or in a removable memory such as an optical disk for eventual use in a CD-ROM drive or a floppy disk for eventual use in a floppy disk drive.
  • the set of instructions can be stored in the memory of another computer and transmitted over a local area network or a wide area network, such as the Internet, when desired by the user.
  • a local area network such as the Internet

Abstract

Disclosed is a system, method, and apparatus for calculating metrics by using hierarchical level metadata to describe the various structures within the database. The hierarchical level metadata permit calculation of complex metrics by an analytical server which would otherwise be difficult or impossible. As a result of the way that the analytical server calculates the metrics, slicing and drilling are supported. Additionally, dimension and fact level security are also supported.

Description

    RELATED APPLICATIONS
  • This application depends and claims priority from U.S. Provisional Patent Application No. 60/199,975 (filed Apr. 27, 2000), and Patent Application No. ______, filed Apr. 17, 2001, entitled “Analytical Server Including Metrics Engine”, Attorney Docket No. 68110328.2, which are hereby incorporated by reference herein.[0001]
  • TECHNICAL FIELD
  • The embodiments disclosed and claimed herein are related to computer systems, and more particularly, databases. [0002]
  • TECHNICAL BACKGROUND
  • Today's businesses have sophisticated data analysis requirements. The metrics or analyses of a business's data can be difficult to obtain. To calculate a meaningful metric, business analysts often use spreadsheets to manually analyze data. Manual analysis, of course, is a tedious and time-consuming process. [0003]
  • Most applications fail to deliver useful metrics that provide unique insights into an organization's performance. Useful metrics highlight significant performance measures of the business. Typically, business analysts must execute multiple queries and other time-consuming manual interventions to produce these metrics. Then, despite the time-consuming effort, analysts must start the process anew to obtain follow-up information such as an explanation of a particular anomaly in a metric. [0004]
  • Typically, a business's data is stored on a database or on databases. These databases are operated with associated database servers, which manage the storage and retrieval of records from the databases. Analytical servers have additionally been provided to format database queries or information requests sent from a client user interface to the database server for handling. The analytical servers can be used to improve the efficiency of the database accesses and to provide metrics of interest to the user from the retrieved records from the database. [0005]
  • SUMMARY
  • The embodiments disclosed below provide an analytical server which efficiently accesses a Relational Database Management System (“RDBMS”) comprising a database and a database server. The database in this approach includes fact and dimension tables which may be, for example, configured in a star schema having a central base_fact table with surrounding dimension tables to form the star structure. Aggregate_fact tables may also be provided which aggregate measures from the base_fact table at a higher hierarchical level than such measures are maintained in the base fact table. Metadata is further stored in the database, where the metadata describes the organization of the various tables in the database, and specifically the metadata in the embodiments described below includes information about the hierarchical levels of various dimensions of the above-mentioned tables and star schema. [0006]
  • With further reference to the metadata stored in the database in the below-described embodiments, the analytical server described herein receives the metadata from the database and analyzes that metadata, including the hierarchical information, in order to provide relatively efficient access to the tables of the database in response to a query from a user. Such efficient access preferably supports calculation of complex metrics which might otherwise be difficult or impossible. Supported levels of stars are defined and analyzed in a sophisticated and efficient manner which facilitates the calculation of chameleon and allocated metrics. [0007]
  • The foregoing provides a number of additional advantages. A user can easily limit the data to a particular set of value(s) for a particular hierarchy level, known as slicing. The user can also view the metrics by moving up or down through a hierarchy, known as drilling. Additionally, fact level security and dimensional security are supported, as well as efficient collection and analysis of aggregate_fact table usage statistics. [0008]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram describing an exemplary computer architecture; [0009]
  • FIG. 2 is a block diagram of a metadata structure for a hierarchy; [0010]
  • FIG. 3A is a block diagram describing a star schema; [0011]
  • FIG. 3B is a block diagram of a metadata structure for a star; [0012]
  • FIG. 4 is a block diagram of a metadata structure for a measure indicator; [0013]
  • FIG. 5 is a block diagram of a metadata structure for a metric indicator; [0014]
  • FIG. 6 is a flow diagram describing calculation of a metric; [0015]
  • FIG. 7 is a flow diagram describing carpooling; [0016]
  • FIG. 8 is a flow diagram describing a rollup of a metric; [0017]
  • FIG. 9 is a flow diagram of the calculation of an allocation metric; [0018]
  • FIG. 10 is a block diagram describing an exemplary graphical user interface; and [0019]
  • FIG. 11 is a block diagram describing an exemplary hardware environment wherein the present invention can be practiced.[0020]
  • DETAILED DESCRIPTION
  • Referring now to FIG. 1, there is illustrated a block diagram describing an [0021] exemplary computer architecture 100, configurable in accordance with an embodiment of the present invention. The computer architecture 100 comprises a relational database management system (RDBMS) 105, a database or data warehouse 110, an interface 140, and an analytical server 120.
  • The [0022] database 110 is accessible by the analytical server engine 120. The analytical server engine 120 accepts requests for metric calculations from clients 135, uses the metadata structures 145 to identify the necessary fact components and the best star schema for accessing them, generates and executes structured queries in a database query language, such as Structured Query Language (SQL), performs outer joins to conform query results, calculates the desired metrics, and returns them to the clients in a structured form such as multidimensional cubes.
  • The clients access the analytical server via an application programming interface (API) [0023] 140, through which metrics can be requested, possibly constrained on dimensional values. The query and metric calculation results are transmitted through the interface as objects. The client need not have knowledge of how the metric is calculated.
  • The [0024] database 110 includes a collection of base_fact tables 125 a and dimension tables 125 b organized in multiple star schemas 125. Exemplary star schemas are described in Ralph Kimball, THE DATA WAREHOUSE TOOLKIT (John Wiley & Sons 1996), which is hereby incorporated by reference for all purposes. Additionally, the database includes aggregate fact tables 130. The aggregate_fact tables 130 contain values summarized from the base_fact tables 125 a to certain specified levels of one or more dimensions. An aggregate fact table 130 is more efficient and preferable to access than a base_fact table 125 a, provided the level of detail of a given aggregate_fact table 130 is still sufficient for a given query. Additionally, a set of metadata structures 145 describe the contents of, and relationships between, the various fact and dimension tables 125 a,125 b.
  • The [0025] metadata structures 145 provides information for the analytical server 120 to determine how to access the database 110 for the values required to construct requested metrics and defines more abstract constructs, such as particular metrics which can be computed from one or more facts in the database 110. As will be described below, the metadata structures 145 include structures for hierarchies, stars, measure indicators, and metric indicators.
  • I. Metadata Structures [0026]
  • A. Hierarchies [0027]
  • Referring now to FIG. 2, there is illustrated a block diagram of a [0028] metadata 145 structure known as a hierarchy 205. A hierarchy 205 defines levels 210 with a minimum of two levels. The top level encompasses all elements, while successive levels further subdivide the elements into one or more non-overlapping groups.
  • Each [0029] level 210 is associated with a level name 210 a, level number 210 b, and column name 210 c. The level names describe the grouping of the elements. In the exemplary case described in FIG. 2, the level names include “all,” “year,” “quarter,” “month,” “week,” and “day.” The level number 210 b starts with 0 for the top level 210 and increases sequentially for each deeper level. The column name 210 c is used to find the attribute values for the level in any table in the database which supports the hierarchy. For example, the column name 210 c for the “quarter” level 210 b may be used to find the attributes specifying the quarters of a particular database year.
  • For a dimension table [0030] 125 b to be associated with a hierarchy 205, the dimension table 125 b must contain the column names 210 c specified for the hierarchy 205 for the levels 1 . . . n. Multiple dimension tables 125 b may be associated with the same hierarchy 205 and support it to different levels. For example, a dimension table 125 b for Time might contain columns only for Year, Quarter, and Month, and therefore provided a supported level of “3,” while a more complete dimension table might contain columns for all levels down to “day,” and therefore offer a supported level of “5.”
  • B. Stars [0031]
  • FIG. 3A illustrates a star schema dimensional model, and FIG. 3B provides a block diagram of an exemplary metadata structure for a single star within the database. [0032]
  • As shown in FIG. 3A, a [0033] star 300 has a single fact table 125 a having a number of records along multiple dimensions, which dimensions in turn point to corresponding dimension tables 125 b. The fact table may be either a base level or aggregate level fact table. As shown in FIG. 3A, the fact table 125 a, for example, may be a “Sales” fact table, which may in turn have facts in six defined dimensions: Products, Customers; Sales Geography; Manufacturing Location; Sales Reps; and Time. These dimensions will in turn refer to the dimension tables 125 b, which may be conceptually viewed as surrounding the fact table 125 a. Exemplary hierarchical levels maintained within the dimension tables 125 b are also shown in FIG. 3A.
  • The [0034] star 300 comprising the fact table 125 a and the surrounding dimension tables 125 b can be used to apply selection constraints and specify aggregate groupings when retrieving the fact values. A number of different stars can be identified in a database.
  • A [0035] star metadata structure 305 such as shown in FIG. 3B can be used to describe the various stars in a database. Each star metadata structure 305 identifies an fact table 130 in the database from which values designated as facts may be obtained. For each supported hierarchy 205 (see FIG. 2), the star 300 identifies a specific dimension table 125 b to be used for performing hierarchical selection and grouping, and provides to the querying language (such as SQL), a constraint used to join the dimension table 125 b to the fact table 125 a.
  • The supported levels of the specific fact table [0036] 130 in the database are represented in a star metadata structure 305 by an array 310 of dimension indicators in which each dimension indicator 315 of the array 310 represents the supported hierarchical levels defined in a predetermined order. Additionally, an initialization process might ensure that the supported levels 210 are valid in all stars 300, thereby eliminating the need for checking the column names during the star selection process.
  • Still referring to FIG. 3B, within each [0037] star metadata structure 305, a supported level 210 value is tracked for each dimension, specific to the star 300 and usually depending on the level 210 of data aggregation in the associated fact table. For example, in FIG. 3A, the time dimension has been summarized to the “day” level, so the supported level 210 for Time in this particular star 300 will be “5,” while some other star containing only month-level fact values would support Time to level 3. If no dimension table 125 b has been assigned for some hierarchy 205, then hierarchy 205 is not supported by the star 305 and the supported level is recorded as “0.”
  • The [0038] star metadata structure 305 may also include a flag 313 indicating the availability of the star 300. Where the star is properly maintained or refreshed by some other mechanism, the flag 313 can be set to indicate whether the data in the star is available. The foregoing flag 313 can be examined during star selection.
  • The [0039] stars 300 are collected into groups called stargroups. Aggregate_fact tables 130 are built for frequently accessed data, in a manner that reduces table size, join complexity, a query time. For example, sales figures might be accumulated at the “day” level in one aggregate_fact table 130, and summarized more highly to the “month” level in some other aggregate_fact table 130. The stargroup used for accessing sales figures might contain two stars 300, possibly using exactly the same dimension tables 125 b but each pointing to different aggregate_fact tables 130. The star 300 using the monthly aggregate fact table 130 would be assigned a higher aggregate rank, or in other words would contain measures at a higher hierarchical level, and would be preferred when values were not required at a finer grain than month.
  • C. Measure Indicator [0040]
  • Referring now to FIG. 4, there is a block diagram of another [0041] metadata structure 145, specifically a measure indicator 405. The measure indicator 405 identifies and describes a measure, which is a value that can be obtained directly from the database 110.
  • The [0042] measure indicator 405 includes an identifier 410, which identifies the facts within the database 110 that are being referred to. Also included in the measure indicator is a flag 411 which indicates whether or not the measure is additive. The measure indicator 405 also contains a query language snippet 412. To support aggregate navigation, the snippet 412 is defined using a syntax which allows substitution of specific fact table 125 a names and dimension table 125 b names. For example, a non-SQL character is used to delimit a substitutable form which is to be replaced by the name of the fact table in the associated star, prior to executing a query.
  • Additionally, different stargroups may require that the [0043] snippet 412 be written differently. Accordingly, a measure may contain a plurality of snippets 412, each associated with an indicator 415 indicating a particular stargroup. Verification that the columns specified in the snippets 412 actually appear in the fact tables 130 defined by each star 300 in the associated stargroup can be done during an initialization process, thereby limiting column name lookups.
  • Use of [0044] multiple snippets 412 for different stargroups are advantageous for calculation of chameleon metrics. Chameleon metrics represent a general concept, the exact definition or calculation of which is dependent on the dimension or level. For example, a cost metric when viewed by the product dimension, may measure production or part cost. However, when viewed by dimensions other than product, the cost includes the total product cost across all parts, freight, taxes! and other top-level costs.
  • Chameleon metrics are constructed by taking advantage of the provision for [0045] multiple snippet 412/stargroup pairs in the underlying measure definitions. Using the Geography vs. Product forecast example, a measure is defined which uses two different stargroups. The snippet 412 associated with the first stargroup can cause the measure to be calculated in accordance with a first definition while the snippet 412 associated with the second definition cause the measure to be calculated in accordance with a second definition.
  • Fact-based redundancy can also be provided, for example, by providing additional security hierarchy fields [0046] 418, 419 within the measure indicator 405. By defining for particular measures a security hierarchy, it is possible to grant access to particular users or clients according to levels of fact-based data by defining security hierarchy levels on a measure-by-measure basis. For ultimate flexibility, the security hierarchy is defined in the measure indicator both at the broad level in field 418 and at the specific snippet level 419. The definition at these different levels allows the facts to be accessed according to the measure's use within the star structure 300 or fact table 130 being accessed rather than just having a broad prohibition of accessing certain types of data by certain users or clients.
  • D. Metric Indicators [0047]
  • Referring now to FIG. 5, there is illustrated a block diagram describing a [0048] metric indicator 505. The metric indicator 505 includes a metric name 510 identifying a particular metric. The metric name 510 is used in requesting results from the analytical server 120. The metric indicator 505 also includes identifiers 515 identifying measures and the operations to be performed thereon, to calculate the value of the metric. Although the measures are obtained from the database 110 from any number of database queries, the metrics are calculated at the analytical server 120 after obtaining each measure.
  • II. Metric Calculation [0049]
  • A. Aggregate Navigation Referring now to FIG. 6, there is illustrated a flow diagram describing the calculation of a metric at an [0050] analytical server 120. At step 605, the analytical server 120 receives a request to calculate a particular metric. After receiving the request to calculate the particular metric, the analytical server 120 determines the specific measures required for calculating the metric from the metric indicator 515 (step 610). For each measure (step 615), the analytical server 120 selects the aggregate stargroup (step 620).
  • At [0051] step 622, the analytical server 120 selects a particular measure and associated stargroup. Within the aggregate stargroup, the analytical server 120 selects (step 625) the star 300 associated with the most highly aggregated fact table 130 and determines whether the star supports each constrained dimension at the level required. The foregoing is measured by comparing (step 630) the requested level for each dimension in the metric request with the array 310 of dimension indicators 315 describing the supported levels 210 of the dimensions. Wherein the array 310 indicates that the requested level for each dimension is supported at the same or higher level, the star 300 is selected (step 630).
  • Wherein one or more requested levels of dimensions are not supported, or supported at a lower level, the fact table [0052] 130 associated with the star 300 is rejected (step 635), and a determination is made whether any remaining stars 300 are present in the stargroup. Wherein a remaining star 300 exists in the stargroup, the star 300 associated with the next most highly aggregated table 130 is selected (step 650) and steps 630-650 are repeated. Wherein there are no remaining stars 300, data may not be obtained for the particular measure (step 655). Steps 622-655 are repeated for each measure required for the requested metric(s).
  • After selecting the [0053] star 300, the analytical server 120 generates and conducts the queries for each measure on the selected tables 130 (step 660). The queries are generated by substituting the fact 125 a and dimension table 125 b names where indicated in the snippets 412 associated with the selected star 300. After generating the queries, the analytical server 120 calculates the measures (step 665), calculates the metrics (step 670), and forwards the result to the client (step 675), thereby completing calculation of the metric.
  • The foregoing approach also permits maintenance of statistics which indicate the usage levels of each [0054] star 300. For example, statistics can monitor events such as when a star 300 is considered for selection and rejected, a star 300 is selected for use, and when a star 300 is actually used in a query. The required and supported hierarchical levels can also be recorded, thereby permitting examination of usage levels. From the foregoing information, it can be determined in a given circumstance that an additional level of detail should be added to the aggregate_fact table 130 because a majority of requests required the additional hierarchical level. Additionally, a determination can be made that the aggregate_fact table 130 can be consolidated without major effect on overall performance because a majority of requests require one less level of detail.
  • B. Combining Queries [0055]
  • Certain queries can be conducted using a common fact table [0056] 130. For example, certain fact tables 130 can include multiple aggregated facts. Wherein multiple queries request different measures, but with identical constraints, the aggregated facts can be combined into a single structured query, such as a SELECT statement in SQL. Alternatively, where in multiple queries, all but one constraint are identical, and the different constraint is constrained at the same level, the queries can also be combined.
  • The [0057] analytical server 120 can advantageously preprocess the requisite queries, possibly allowing a number of queries to be combined into a single query, resulting in relational database 110 access efficiencies.
  • Referring now to FIG. 7, there is illustrated a flow diagram describing the operation of the [0058] analytical server 120 conducting queries, wherein the queries may be combined due to there being a number of queries seeking metrics along the same dimension broken down, preferably, to the same hierarchical level. The combining of the queries reduces database load and in many cases improves database response time.
  • At [0059] step 705, the analytical server 120 determines the fact table 130 from which to calculate each measure. At step 707, the analytical server determines which of a plurality of queries can be combined when accessing the database 110. In order to combine queries, the same base fact table 125 a is common between the queries to be combined, and there will be commonality to at least some of the dimension tables 125 b between the queries as well. The queries can be combined for a single star or among a number of stars 300, so long as there is the requisite commonality among the fact and dimension tables 125 a-b. The determination of step 707 involves a determination of the hierarchical levels involved in the plurality of queries, and it is possible that even if a requested metric or metrics requires the same measures but at differing hierarchical levels, it may be possible to consolidate these into a single query of the database 110 and then extract the desired information needed for the different metric requests. For example, if some metric is broken down over the last six months and also for the corresponding six months in the previous year, the underlying measure for both requests can be obtained in a single query, simply by placing all desired month numbers in the “IN (1, m, n)” constraint, and selectively processing the results.
  • At [0060] step 710, the analytical server 120 carpools combinable queries to reduce the number of queries actually made of the database 110 through the RDBMS 105. After carpooling the queries, the analytical server 120 generates the structured query commands for each of the database queries (step 715) and forwards (step 720) the structured database query commands to the RDBMS 105.
  • C. Non-additive Metric Calculation [0061]
  • It is noted that it is often desirable to display metrics broken down across dimensional levels, and simultaneously display a roll-up or total. Provided all the measures that have been broken down across dimensional levels are additive, the requester of the metric can simply total the returned results. However, this is incorrect wherein certain measure components of the metrics are non-additive. Correct totals can only be obtained if the requester has knowledge of which measures are non-additive and asks for the non-additive measures separately. [0062]
  • By using the additive/[0063] non-additive fields 411,416 described with respect to FIG. 4, it is possible for the analytical server 120 to readily determine which measures are non-additive. By making this determination, the analytical server can allow the rollup to be handled transparently without making the non-additive attributes visible to the requester. This is accomplished by extending the metric result to contain an additional multidimensional array of totals. The additional multidimensional array of totals may include or be based upon measures at different hierarchical levels than were necessary for the original (non-rollup) calculation. Alternatively, the original three-dimensional cube might simply reserve one extra element in the first dimension to contain the totals. Maintaining metadata 145 describing the hierarchical levels of the fact tables 130 allows for an efficient implementation of the transparent non-additive metric calculations described above.
  • Referring now to FIG. 8, there is illustrated a flow diagram describing a rollup of a metric. At [0064] step 805, the metric is broken down into its component measures. At step 810, the component measures are separated into two groups or are conceptually treated as two groups, according to the additive/non-additive flags 411,416 (see FIG. 4). To the extent the rollup can be done for the additive measures without additional difficulty, this summing is done at step 815.
  • At [0065] step 820, a separate totals query is generated for each non-additive measure. The query is launched using the stars as described above, and it is noted that the totals query typically requires a shallower hierarchical level on at least one dimension. Accordingly, the totals query may actually be obtained using a more highly aggregated table. Finally, at step 825, the metric is calculated and the process is terminated. In the foregoing manner, complex metrics composed of any combination of additive and non-additive measures can be calculated correctly and efficiently, without requiring any knowledge or action on the part of the requester.
  • Since the [0066] analytical server 120 knows which measures are additive and non-additive, the analytical server is able to adapt its inquiries and displays to minimize the possibility of displaying invalid results.
  • In the simple case where it turns out all component measures are additive, the [0067] analytical server 120 issues queries at the detail level only (business unit), and performs simple sums to calculate the totals. The individual measures are summed, and then the metric level calculations are performed using these sums.
  • When a measure is non-additive, the [0068] analytical server 120 instead generates and issues two separate queries, the extra query being for the total level (omitting the SELECT item and GROUP BY for Business Unit). In this way, complex metrics composed of any combination of additive and non-additive measures can be calculated correctly and efficiently, without requiring any knowledge or action on the part of the requester. The additive/non-additive fields 411, 416 (see FIG. 4) are provided within the measure metadata structure to assist the analytical server 120 in determining whether certain measures or additive or not along certain dimensions.
  • As an additional benefit, there may be cases where no star is available at a certain hierarchical level, in which case the [0069] analytical server 120 may attempt to obtain the measures and calculate the metric at the total level only (even in the case where the measures are all additive). This can be done, for example, when the intention is to compare two metrics, such as sales vs. forecast, as when sales can be broken down by industry, customer, etc. but forecast is only available by product. In this case, forecast could still be compared to total sales across all industries or customers. To best support this capability, the server further extends the result object to provide indicators distinguishing such indicators as “all zero results”, “no data found”, “detail level not supported”, and so forth.
  • D. Cross Star Joins [0070]
  • Many metrics must be calculated using measures obtained from different stars. For example, a metric which measures the average numbers of days that inventory will last (inventory days on hand) is calculated by dividing the current inventory by the sales per day. Wherein one star measures sales and another star measures inventory, calculation of the inventory days on hand requires calculation of measures from both the sales star and the inventory star. [0071]
  • The [0072] analytical server 120 accesses the measures separately from each star 300, and then performs the equivalent of an outer join on the results. The different sets of results along the hierarchical level supplied in the request and retrieved by the queries are carefully “lined up”, thereby allowing the server 120 to encapsulate this knowledge and processing, and make sophisticated metrics available to the requestor.
  • E. Invariant Metrics [0073]
  • Certain measures or metrics are “invariant” by dimension. For example, to calculate the metric sales per sales rep, a measure must exist for the denominator which gives the number of sales reps. Furthermore, it may be useful to look at the sales per rep metric broken down by product business unit, family, or item. If the number of sales reps is maintained in a sales forecast star, it can be accessed only by sales geography and time. However, since all reps sell all products, the measure reporting number of reps does not change whether looking at the business unit, family, or item level, the number of sales reps is invariant along the product dimension. Therefore, the sales forecast star is degenerate along the product dimension. The analytical server is equipped with knowledge of measures which are invariant with respect to certain dimensions. Providing this knowledge to the analytical server allows a single value to be obtained as the invariant measure in the metric calculation, regardless of the level of the dimension to which the measure is invariant. [0074]
  • F. Allocation Metrics [0075]
  • An allocation metric is a metric containing a measure that is not defined at the lowest dimension level, but which is useful and desirable to allocate a value for the metric at the lowest dimension using another measure which is definable at the lowest dimension. For example, Sales Forecast numbers may be available by Geography, Sales Rep, and Time, but not by Product Business Unit. However, suppose that Sales for the previous year are available by Product Business Unit and that it is a reasonable assumption that the breakdown of Sales by Product Business Unit will be similar to the breakdown of Sales Forecast by Product Business Unit. In such a case, the Sales Forecast by Product Business Unit can be calculated by the foregoing expression: [0076]
  • Allocated Forecast for Product (A)= [0077] Total Forecast * Sales for Product ( A ) Last Year Total Sales Last Year
    Figure US20020038297A1-20020328-M00001
  • In the following case, the measure “Forecast Sales” is the base measure while “Sales Last Year” is known as the control measure. Additionally, it should be noted that while Sales for Product(A) is at the same level as the request, i.e., at the Product Business Units level, the measures of Total Forecast and Total Sales Last Year are obtained at different levels, or “allocated levels”. [0078]
  • Referring now to FIG. 9, there is illustrated a flow diagram describing calculation of an allocated metric. The calculation of an allocated metric will be described using an exemplary case wherein a request is made for Forecasted Sales by Quarter, and Business Unit, across All Geographies. The supported levels of the [0079] stars 300 are described in the following dimension order: Time, Product, and Geography. The Time dimension is ordered from All, Year, Quarter, Month, Week, and Date. The Product dimension is ordered from All and Business Unit. The Geography is ordered from All, Continent, Country, State, and City.
  • At [0080] step 905, the required levels for the request are determined. In the exemplary case, the required levels are “210.” At step 910, a determination is made whether a star exists with the required levels. As an example, the star metadata structure 305 shown in FIG. 3 could be used to store, in a defined fashion in the array 310 of integers, the available hierarchical levels within a given star. If a star exists having the required levels, the metric is calculated (step 915) directly and the process is terminated. Wherein a star does not exist, the best data available for the base measure (Sales Forecast), which is simply the lowest ranked star in the stargroup, is selected (step 920).
  • In the exemplary case, the lowest ranked star is ranked as “[0081] 303” which fails on the Product dimension. At step 925, the allocation levels are determined by taking the minimums of the required levels for the request and the levels of the star selected during step 920. The allocation levels are “200” in the exemplary case.
  • During [0082] step 930, an attempt is made to find a star which supports the allocation levels in the base measure, e.g., the sales forecast in the present exemplary case. During step 935, an attempt is made to find a star in the control measure (the Sales Last Year) which support the required levels for the request (“210”). Wherein a star for the base measure is found in step 930 and a star for the control measure is found in step 935, the allocated measure is calculated (step 940), thereby completing calculation of the metric. Wherein a star is not found in either steps 930 or 935, the allocated measure cannot be calculated and calculation of the metric is terminated.
  • III. Security [0083]
  • A. Dimension Level Security [0084]
  • Data security is provided on both a dimension level and a fact level. Each authorized user of the database can be associated with a particular security level which restricts the levels of each hierarchy which the user is permitted access. For example, regional sales managers can be permitted to only view sales at the regional level and not be authorized access to sales data at the national or worldwide level. Additionally, the users can be restricted access to a particular value of a hierarchical level. For example, a regional sales manager might be permitted to only view sales data from their region. [0085]
  • The dimension level security is provided by defining security groups which specify that all metric requests have to be performed as if the required level of a certain hierarchy is at least some predetermined level. The request is rejected outright if any of the requested levels are lower than the security levels. The security definitions can also contain rules which force certain constraints. The force constraints are dynamically substituted to a given request. [0086]
  • B. Fact Level Security [0087]
  • It may also be desirable to prevent users from viewing specific metrics. An additional two level hierarchy is defined, wherein level zero is indicative that the data should not be visible, while level one is indicative that the data should be made visible. The supported level for the added hierarchy is set at zero for each restricted metric and one for each unrestricted metric. Users who are restricted are placed in a security group that only permits access to level one of the hierarchy. Therefore, when a restricted user makes a query for the restricted metric, the security definition imposes a dimensional constraint of one for the additional hierarchy. During aggregate navigation, each of the stars will be rejected because the stars only support a level zero aggregation. For users who are permitted to access the restricted metric, the zero level dimensional constraint is imposed, however each of the stars support the zero level aggregation. [0088]
  • IV. Graphical User Interface [0089]
  • As noted above, the [0090] analytical server 120 generates queries which are requested from the clients 135. The results of the query are forwarded to the clients via the API 140. Requests are also forwarded from the clients 135 to the analytical server 120 via the API 140. Communication of the requests from the clients 135 and the results from the analytical server 120 is facilitated by generation of a graphical user interface. The graphical user interface is displayed at the client 135 and facilitates transmission of requests for queries and displays the results of the queries.
  • Referring now to FIG. 10, there is illustrated a block diagram of the GUI [0091] 1115. The GUI 1115 includes a hierarchical listing of each of the dimensions 1225. The user can click on a particular dimension 1225 and view metrics calculated for the constraint, as well as the lower levels of the dimension hierarchy. For each dimension, the user can either select a lower level or select a constraint to constrain the dimension. Additionally, the graphical user interface includes a set of metric buttons, wherein each metric button is associated with a predefined metric.
  • By constraining the dimension and selecting a metric, the user can have the metric calculated for the records with the selected constraints. The user can click a query button and have constraints and selected metric forwarded to the [0092] analytical server 120. The analytical server 120 generates a structured query, transmits the structured query to the database server 105, receives the results of the query. Upon receiving the results of the query, the analytical server 120 calculates the selected metric, and prepares an object encapsulating the calculated metric for display in the GUI 1115. The retrieved data is displayed in the form of a results page 1305. The results page includes rows 1307 and columns 1308 of graphs 1310. Each single graph 1310 can plot any number of metrics, such as profits and costs against the vertical axis. Each row 1307 of graphs 1310 can represent metrics pertaining to each of the different values which comprise a level of a dimension 1220, known as a slice. For example, each row could represent the metrics pertaining to a different country in the location dimension. Each column can represent a different quarter.
  • The GUI [0093] 1115 also includes a navigation bar for changing the dimension with an indicator button 1315 for each dimension. The user can change the dimension displayed, known as slicing, by clicking on the appropriate indicator button 1315. For example, the user can view the profits and costs from product to product by simply clicking on the product dimension indicator button 1315.
  • Additionally, the user can also traverse the levels of a dimension. For example, the user may wish to review graphs of metrics involving the various provinces of Canada. By clicking on the graph [0094] 1310 in the row representing the Canada, the user can then review graphs for the provinces of Canada. Alternatively, the user may wish to review graphs from a higher level in the location dimension, e.g., continent. To review the graphs 1310 on a higher level of the same dimension, the user clicks on the location dimension indicator button 1315.
  • Referring now to FIG. 11, a representative hardware environment for practicing the present invention is depicted and illustrates a typical hardware configuration of a computer system in accordance with the subject invention, having at least one central processing unit (CPU) [0095] 1860. CPU 1860 is interconnected via system bus 1812 to random access memory (RAM) 1864, read only memory (ROM) 1866, and input/output (I/O) adapter 1868 for connecting peripheral devices such as disc units 1870 and tape drives 1890 to bus 1862, user interface adapter 1872 for connecting keyboard 1874, mouse 1876 having button 1867, speaker 1878, microphone 1882, and/or other user interfaced devices such as a touch screen device (not shown) to bus 1862, communication adapter 1884 for connecting the analytical server to a data processing network 1892, and display adapter 1886 for connecting bus 1862 to display device 1888.
  • In one embodiment, the invention can be implemented as sets of instructions resident in the random access memory [0096] 1864 of one or more computer systems configured generally as described in FIG. 11. Until required by the computer system, the set of instructions may be stored in another computer readable memory, for example in a hard disk drive, or in a removable memory such as an optical disk for eventual use in a CD-ROM drive or a floppy disk for eventual use in a floppy disk drive. Further, the set of instructions can be stored in the memory of another computer and transmitted over a local area network or a wide area network, such as the Internet, when desired by the user. One skilled in the art would appreciate that the physical storage of the sets of instructions physically changes the medium upon which it is stored electrically, magnetically, or chemically so that the medium carries computer readable information.
  • Although preferred embodiments of the present inventions have illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the inventions are not limited to the embodiments disclosed, but are capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims and equivalents thereof. [0097]

Claims (10)

1. A method for calculating a measure, said method comprising:
receiving a request to calculated a measure, said measure associated with one or more requested levels;
determining at least one allocated level for the measure;
selecting a first star from a first stargroup associated with the measure, wherein the first star supports the at least one allocation level for the measure; and
selecting a second star from a second stargroup associated with a control measure, wherein the second star supports the one or more requested levels.
2. The method of claim 1, wherein determining at least one allocated level further comprises:
comparing the requested levels to a lowest level star in the first stargroup; and
selecting for each requested level, a minimum of the requested level and a corresponding one of one or more dimension levels associated with the star.
3. The method of claim 1, further comprising:
calculating the measure for the allocated levels; and
calculating the control measure for the requested levels.
4. The method of claim 1, wherein determining the allocated levels further comprises:
determining the allocated levels wherein no star exists which supports the measure at the requested levels.
5. The method of claim 1, wherein the control measure is a predetermined measure associated with the measure.
6. A computer readable medium for storing a plurality of instructions for calculating a measure, said plurality of instructions comprising:
receiving a request to calculated a measure, said measure associated with one or more requested levels;
determining at least one allocated level for the measure;
selecting a first star from a first stargroup associated with the measure, wherein the first star supports the at least one allocation level for the measure; and
selecting a second star from a second stargroup associated with a control measure, wherein the second star supports the one or more requested levels.
7. The computer readable medium of claim 6, wherein the plurality of instructions comprising determining at least one allocated level further comprises:
comparing the requested levels to a lowest level star in the first stargroup; and
selecting for each requested level, a minimum of the requested level and a corresponding one of one or more dimension levels associated with the star.
8. The computer readable medium of claim 6, wherein the plurality of instructions further comprises:
calculating the measure for the allocated levels; and
calculating the control measure for the requested levels.
9. The computer readable medium of claim 6, wherein the plurality of instructions comprising determining the allocated levels further comprises:
determining the allocated levels wherein no star exists which supports the measure at the requested levels.
10. The computer readable medium of claim 6, wherein the control measure is a predetermined measure associated with the measure.
US09/844,706 2000-04-27 2001-04-27 Allocation measures and metric calculations in star schema multi-dimensional data warehouse Expired - Lifetime US7080090B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US09/844,706 US7080090B2 (en) 2000-04-27 2001-04-27 Allocation measures and metric calculations in star schema multi-dimensional data warehouse

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US19997500P 2000-04-27 2000-04-27
USPCT/US01/12501 2001-04-17
PCT/US2001/012501 WO2001080095A2 (en) 2000-04-17 2001-04-17 Analytical server including metrics engine
US09/837,114 US6662174B2 (en) 2000-04-17 2001-04-17 Analytical server including metrics engine
US09/844,706 US7080090B2 (en) 2000-04-27 2001-04-27 Allocation measures and metric calculations in star schema multi-dimensional data warehouse

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/837,114 Continuation-In-Part US6662174B2 (en) 2000-04-17 2001-04-17 Analytical server including metrics engine

Publications (2)

Publication Number Publication Date
US20020038297A1 true US20020038297A1 (en) 2002-03-28
US7080090B2 US7080090B2 (en) 2006-07-18

Family

ID=46277554

Family Applications (1)

Application Number Title Priority Date Filing Date
US09/844,706 Expired - Lifetime US7080090B2 (en) 2000-04-27 2001-04-27 Allocation measures and metric calculations in star schema multi-dimensional data warehouse

Country Status (1)

Country Link
US (1) US7080090B2 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040122936A1 (en) * 2002-12-20 2004-06-24 Ge Mortgage Holdings, Llc Methods and apparatus for collecting, managing and presenting enterprise performance information
US20050055329A1 (en) * 2000-02-28 2005-03-10 Reuven Bakalash Database management system having data aggregation module integrated therein
US20050091237A1 (en) * 1999-08-04 2005-04-28 Reuven Bakalash Relational database management system having integrated non-relational multi-dimensional data store of aggregated data elements
US20050182703A1 (en) * 2004-02-12 2005-08-18 D'hers Thierry System and method for semi-additive aggregation
US20110099167A1 (en) * 2004-05-26 2011-04-28 Nicholas Galbreath Graph Server Querying for Managing Social Network Information Flow
US8041670B2 (en) 1999-08-04 2011-10-18 Yanicklo Technology Limited Liability Company Data aggregation module supporting dynamic query responsive aggregation during the servicing of database query requests provided by one or more client machines
US20110276464A1 (en) * 2005-06-29 2011-11-10 Itg Software Solutions, Inc. System and method for generating real-time indicators in a trading list or portfolio
US20170116305A1 (en) * 2015-10-23 2017-04-27 Numerify, Inc. Input Gathering System and Method for Refining, Refining or Validating Star Schema for a Source Database

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7257596B1 (en) 2000-11-09 2007-08-14 Integrated Marketing Technology Subscription membership marketing application for the internet
US7720842B2 (en) * 2001-07-16 2010-05-18 Informatica Corporation Value-chained queries in analytic applications
US9158818B2 (en) * 2007-04-05 2015-10-13 Oracle International Corporation Facilitating identification of star schemas in database environments
US9495429B2 (en) * 2010-07-09 2016-11-15 Daniel Paul Miranker Automatic synthesis and presentation of OLAP cubes from semantically enriched data sources
US9396283B2 (en) 2010-10-22 2016-07-19 Daniel Paul Miranker System for accessing a relational database using semantic queries
US8271537B2 (en) * 2010-11-15 2012-09-18 Sas Institute Inc. Grid computing system alongside a distributed database architecture
US9507825B2 (en) 2012-09-28 2016-11-29 Oracle International Corporation Techniques for partition pruning based on aggregated zone map information
US8996544B2 (en) 2012-09-28 2015-03-31 Oracle International Corporation Pruning disk blocks of a clustered table in a relational database management system
US9430550B2 (en) 2012-09-28 2016-08-30 Oracle International Corporation Clustering a table in a relational database management system
US8904551B2 (en) 2012-11-07 2014-12-02 International Business Machines Corporation Control of access to files
US10642837B2 (en) 2013-03-15 2020-05-05 Oracle International Corporation Relocating derived cache during data rebalance to maintain application performance
US10360239B2 (en) * 2015-10-23 2019-07-23 Numerify, Inc. Automated definition of data warehouse star schemas
US10452677B2 (en) 2016-06-19 2019-10-22 Data.World, Inc. Dataset analysis and dataset attribute inferencing to form collaborative datasets
US11036716B2 (en) 2016-06-19 2021-06-15 Data World, Inc. Layered data generation and data remediation to facilitate formation of interrelated data in a system of networked collaborative datasets
US10699027B2 (en) 2016-06-19 2020-06-30 Data.World, Inc. Loading collaborative datasets into data stores for queries via distributed computer networks
US10438013B2 (en) 2016-06-19 2019-10-08 Data.World, Inc. Platform management of integrated access of public and privately-accessible datasets utilizing federated query generation and query schema rewriting optimization
US11755602B2 (en) 2016-06-19 2023-09-12 Data.World, Inc. Correlating parallelized data from disparate data sources to aggregate graph data portions to predictively identify entity data
US10853376B2 (en) 2016-06-19 2020-12-01 Data.World, Inc. Collaborative dataset consolidation via distributed computer networks
US11086896B2 (en) 2016-06-19 2021-08-10 Data.World, Inc. Dynamic composite data dictionary to facilitate data operations via computerized tools configured to access collaborative datasets in a networked computing platform
US10346429B2 (en) 2016-06-19 2019-07-09 Data.World, Inc. Management of collaborative datasets via distributed computer networks
US11036697B2 (en) 2016-06-19 2021-06-15 Data.World, Inc. Transmuting data associations among data arrangements to facilitate data operations in a system of networked collaborative datasets
US10324925B2 (en) 2016-06-19 2019-06-18 Data.World, Inc. Query generation for collaborative datasets
US11068847B2 (en) 2016-06-19 2021-07-20 Data.World, Inc. Computerized tools to facilitate data project development via data access layering logic in a networked computing platform including collaborative datasets
US11042548B2 (en) 2016-06-19 2021-06-22 Data World, Inc. Aggregation of ancillary data associated with source data in a system of networked collaborative datasets
US11334625B2 (en) 2016-06-19 2022-05-17 Data.World, Inc. Loading collaborative datasets into data stores for queries via distributed computer networks
US10353911B2 (en) 2016-06-19 2019-07-16 Data.World, Inc. Computerized tools to discover, form, and analyze dataset interrelations among a system of networked collaborative datasets
US11468049B2 (en) 2016-06-19 2022-10-11 Data.World, Inc. Data ingestion to generate layered dataset interrelations to form a system of networked collaborative datasets
US11023104B2 (en) 2016-06-19 2021-06-01 data.world,Inc. Interactive interfaces as computerized tools to present summarization data of dataset attributes for collaborative datasets
US10984008B2 (en) 2016-06-19 2021-04-20 Data.World, Inc. Collaborative dataset consolidation via distributed computer networks
US11068475B2 (en) 2016-06-19 2021-07-20 Data.World, Inc. Computerized tools to develop and manage data-driven projects collaboratively via a networked computing platform and collaborative datasets
US10747774B2 (en) 2016-06-19 2020-08-18 Data.World, Inc. Interactive interfaces to present data arrangement overviews and summarized dataset attributes for collaborative datasets
US10515085B2 (en) 2016-06-19 2019-12-24 Data.World, Inc. Consolidator platform to implement collaborative datasets via distributed computer networks
US11042556B2 (en) 2016-06-19 2021-06-22 Data.World, Inc. Localized link formation to perform implicitly federated queries using extended computerized query language syntax
US11042537B2 (en) 2016-06-19 2021-06-22 Data.World, Inc. Link-formative auxiliary queries applied at data ingestion to facilitate data operations in a system of networked collaborative datasets
US11016931B2 (en) 2016-06-19 2021-05-25 Data.World, Inc. Data ingestion to generate layered dataset interrelations to form a system of networked collaborative datasets
US11675808B2 (en) 2016-06-19 2023-06-13 Data.World, Inc. Dataset analysis and dataset attribute inferencing to form collaborative datasets
US10691710B2 (en) 2016-06-19 2020-06-23 Data.World, Inc. Interactive interfaces as computerized tools to present summarization data of dataset attributes for collaborative datasets
US10645548B2 (en) 2016-06-19 2020-05-05 Data.World, Inc. Computerized tool implementation of layered data files to discover, form, or analyze dataset interrelations of networked collaborative datasets
US11042560B2 (en) 2016-06-19 2021-06-22 data. world, Inc. Extended computerized query language syntax for analyzing multiple tabular data arrangements in data-driven collaborative projects
US10452975B2 (en) 2016-06-19 2019-10-22 Data.World, Inc. Platform management of integrated access of public and privately-accessible datasets utilizing federated query generation and query schema rewriting optimization
US10824637B2 (en) 2017-03-09 2020-11-03 Data.World, Inc. Matching subsets of tabular data arrangements to subsets of graphical data arrangements at ingestion into data driven collaborative datasets
US11238109B2 (en) 2017-03-09 2022-02-01 Data.World, Inc. Computerized tools configured to determine subsets of graph data arrangements for linking relevant data to enrich datasets associated with a data-driven collaborative dataset platform
US11068453B2 (en) 2017-03-09 2021-07-20 data.world, Inc Determining a degree of similarity of a subset of tabular data arrangements to subsets of graph data arrangements at ingestion into a data-driven collaborative dataset platform
US11086876B2 (en) 2017-09-29 2021-08-10 Oracle International Corporation Storing derived summaries on persistent memory of a storage device
US11243960B2 (en) 2018-03-20 2022-02-08 Data.World, Inc. Content addressable caching and federation in linked data projects in a data-driven collaborative dataset platform using disparate database architectures
US10922308B2 (en) 2018-03-20 2021-02-16 Data.World, Inc. Predictive determination of constraint data for application with linked data in graph-based datasets associated with a data-driven collaborative dataset platform
US11537990B2 (en) 2018-05-22 2022-12-27 Data.World, Inc. Computerized tools to collaboratively generate queries to access in-situ predictive data models in a networked computing platform
USD920353S1 (en) 2018-05-22 2021-05-25 Data.World, Inc. Display screen or portion thereof with graphical user interface
USD940169S1 (en) 2018-05-22 2022-01-04 Data.World, Inc. Display screen or portion thereof with a graphical user interface
USD940732S1 (en) 2018-05-22 2022-01-11 Data.World, Inc. Display screen or portion thereof with a graphical user interface
US11327991B2 (en) 2018-05-22 2022-05-10 Data.World, Inc. Auxiliary query commands to deploy predictive data models for queries in a networked computing platform
US11442988B2 (en) 2018-06-07 2022-09-13 Data.World, Inc. Method and system for editing and maintaining a graph schema

Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5355474A (en) * 1991-09-27 1994-10-11 Thuraisngham Bhavani M System for multilevel secure database management using a knowledge base with release-based and other security constraints for query, response and update modification
US5475826A (en) * 1993-11-19 1995-12-12 Fischer; Addison M. Method for protecting a volatile file using a single hash
US5848408A (en) * 1997-02-28 1998-12-08 Oracle Corporation Method for executing star queries
US5899992A (en) * 1997-02-14 1999-05-04 International Business Machines Corporation Scalable set oriented classifier
US5926818A (en) * 1997-06-30 1999-07-20 International Business Machines Corporation Relational database implementation of a multi-dimensional database
US5943671A (en) * 1994-09-29 1999-08-24 International Business Machines Corporation Compensation for security procedures in different database management systems
US5944825A (en) * 1997-05-30 1999-08-31 Oracle Corporation Security and password mechanisms in a database system
US5991754A (en) * 1998-12-28 1999-11-23 Oracle Corporation Rewriting a query in terms of a summary based on aggregate computability and canonical format, and when a dimension table is on the child side of an outer join
US6038550A (en) * 1998-03-31 2000-03-14 Rosenwald; Jeffrey A. Method and apparatus for managing interest on a developing series of financial transactions in several memories
US6163774A (en) * 1999-05-24 2000-12-19 Platinum Technology Ip, Inc. Method and apparatus for simplified and flexible selection of aggregate and cross product levels for a data warehouse
US6189004B1 (en) * 1998-05-06 2001-02-13 E. Piphany, Inc. Method and apparatus for creating a datamart and for creating a query structure for the datamart
US6212515B1 (en) * 1998-11-03 2001-04-03 Platinum Technology, Inc. Method and apparatus for populating sparse matrix entries from corresponding data
US6327574B1 (en) * 1998-07-07 2001-12-04 Encirq Corporation Hierarchical models of consumer attributes for targeting content in a privacy-preserving manner
US20020029207A1 (en) * 2000-02-28 2002-03-07 Hyperroll, Inc. Data aggregation server for managing a multi-dimensional database and database management system having data aggregation server integrated therein
US6374263B1 (en) * 1999-07-19 2002-04-16 International Business Machines Corp. System for maintaining precomputed views
US6385201B1 (en) * 1997-04-30 2002-05-07 Nec Corporation Topology aggregation using parameter obtained by internodal negotiation
US20020078018A1 (en) * 1999-05-24 2002-06-20 Tse Eva Man-Yan Method and apparatus for populating multiple data marts in a single aggregation process
US6434557B1 (en) * 1999-12-30 2002-08-13 Decode Genetics Ehf. Online syntheses programming technique
US6438537B1 (en) * 1999-06-22 2002-08-20 Microsoft Corporation Usage based aggregation optimization
US6438538B1 (en) * 1999-10-07 2002-08-20 International Business Machines Corporation Data replication in data warehousing scenarios
US6446059B1 (en) * 1999-06-22 2002-09-03 Microsoft Corporation Record for a multidimensional database with flexible paths
US6446063B1 (en) * 1999-06-25 2002-09-03 International Business Machines Corporation Method, system, and program for performing a join operation on a multi column table and satellite tables
US6477525B1 (en) * 1998-12-28 2002-11-05 Oracle Corporation Rewriting a query in terms of a summary based on one-to-one and one-to-many losslessness of joins
US6484179B1 (en) * 1999-10-25 2002-11-19 Oracle Corporation Storing multidimensional data in a relational database management system
US6487546B1 (en) * 1998-08-27 2002-11-26 Oracle Corporation Apparatus and method for aggregate indexes
US6505205B1 (en) * 1999-05-29 2003-01-07 Oracle Corporation Relational database system for storing nodes of a hierarchical index of multi-dimensional data in a first module and metadata regarding the index in a second module
US6662174B2 (en) * 2000-04-17 2003-12-09 Brio Software, Inc. Analytical server including metrics engine
US6718312B1 (en) * 1999-10-12 2004-04-06 Market Design Group, Inc. Method and system for combinatorial auctions with bid composition restrictions
US6778709B1 (en) * 1999-03-12 2004-08-17 Hewlett-Packard Development Company, L.P. Embedded block coding with optimized truncation

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3952518B2 (en) 1996-03-29 2007-08-01 株式会社日立製作所 Multidimensional data processing method
US6032144A (en) 1996-05-29 2000-02-29 Lucent Technologies Inc. Optimization of queries using relational algebraic theta-semijoin operator
US5884299A (en) 1997-02-06 1999-03-16 Ncr Corporation Optimization of SQL queries involving aggregate expressions using a plurality of local and global aggregation operations
US6205469B1 (en) 1997-05-27 2001-03-20 Yahoo! Inc. Method for client-server communications through a minimal interface
US5983227A (en) 1997-06-12 1999-11-09 Yahoo, Inc. Dynamic page generator
US5905985A (en) 1997-06-30 1999-05-18 International Business Machines Corporation Relational database modifications based on multi-dimensional database modifications
US6574661B1 (en) 1997-09-26 2003-06-03 Mci Communications Corporation Integrated proxy interface for web based telecommunication toll-free network management using a network manager for downloading a call routing tree to client
US5991756A (en) 1997-11-03 1999-11-23 Yahoo, Inc. Information retrieval from hierarchical compound documents
US6078926A (en) 1997-12-18 2000-06-20 Persistence Software, Inc. Method and apparatus for performing multi-class object fetch in a database management system
US6199063B1 (en) 1998-03-27 2001-03-06 Red Brick Systems, Inc. System and method for rewriting relational database queries
JP2002510088A (en) * 1998-03-27 2002-04-02 インフォミックス ソフトウェア, インコーポレイテッド Processing precomputed views
WO1999057658A1 (en) 1998-05-01 1999-11-11 Information Advantage System and method for updating a multi-dimensional database
US6161103A (en) * 1998-05-06 2000-12-12 Epiphany, Inc. Method and apparatus for creating aggregates for use in a datamart
US6212524B1 (en) * 1998-05-06 2001-04-03 E.Piphany, Inc. Method and apparatus for creating and populating a datamart
AU1097800A (en) 1998-09-30 2000-04-17 I2 Technologies, Inc. Multi-dimensional data management system
AU6169399A (en) 1998-10-02 2000-04-26 Ncr Corporation Techniques for deploying analytic models in parallel
US6385604B1 (en) 1999-08-04 2002-05-07 Hyperroll, Israel Limited Relational database management system having integrated non-relational multi-dimensional data store of aggregated data elements
US6542895B1 (en) 1999-08-30 2003-04-01 International Business Machines Corporation Multi-dimensional restructure performance when adding or removing dimensions and dimensions members
US6556983B1 (en) 2000-01-12 2003-04-29 Microsoft Corporation Methods and apparatus for finding semantic information, such as usage logs, similar to a query using a pattern lattice data space

Patent Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5355474A (en) * 1991-09-27 1994-10-11 Thuraisngham Bhavani M System for multilevel secure database management using a knowledge base with release-based and other security constraints for query, response and update modification
US5475826A (en) * 1993-11-19 1995-12-12 Fischer; Addison M. Method for protecting a volatile file using a single hash
US5943671A (en) * 1994-09-29 1999-08-24 International Business Machines Corporation Compensation for security procedures in different database management systems
US5899992A (en) * 1997-02-14 1999-05-04 International Business Machines Corporation Scalable set oriented classifier
US5848408A (en) * 1997-02-28 1998-12-08 Oracle Corporation Method for executing star queries
US6385201B1 (en) * 1997-04-30 2002-05-07 Nec Corporation Topology aggregation using parameter obtained by internodal negotiation
US5944825A (en) * 1997-05-30 1999-08-31 Oracle Corporation Security and password mechanisms in a database system
US5926818A (en) * 1997-06-30 1999-07-20 International Business Machines Corporation Relational database implementation of a multi-dimensional database
US6038550A (en) * 1998-03-31 2000-03-14 Rosenwald; Jeffrey A. Method and apparatus for managing interest on a developing series of financial transactions in several memories
US6189004B1 (en) * 1998-05-06 2001-02-13 E. Piphany, Inc. Method and apparatus for creating a datamart and for creating a query structure for the datamart
US6327574B1 (en) * 1998-07-07 2001-12-04 Encirq Corporation Hierarchical models of consumer attributes for targeting content in a privacy-preserving manner
US6487546B1 (en) * 1998-08-27 2002-11-26 Oracle Corporation Apparatus and method for aggregate indexes
US6212515B1 (en) * 1998-11-03 2001-04-03 Platinum Technology, Inc. Method and apparatus for populating sparse matrix entries from corresponding data
US5991754A (en) * 1998-12-28 1999-11-23 Oracle Corporation Rewriting a query in terms of a summary based on aggregate computability and canonical format, and when a dimension table is on the child side of an outer join
US6477525B1 (en) * 1998-12-28 2002-11-05 Oracle Corporation Rewriting a query in terms of a summary based on one-to-one and one-to-many losslessness of joins
US6778709B1 (en) * 1999-03-12 2004-08-17 Hewlett-Packard Development Company, L.P. Embedded block coding with optimized truncation
US6163774A (en) * 1999-05-24 2000-12-19 Platinum Technology Ip, Inc. Method and apparatus for simplified and flexible selection of aggregate and cross product levels for a data warehouse
US20020078018A1 (en) * 1999-05-24 2002-06-20 Tse Eva Man-Yan Method and apparatus for populating multiple data marts in a single aggregation process
US6505205B1 (en) * 1999-05-29 2003-01-07 Oracle Corporation Relational database system for storing nodes of a hierarchical index of multi-dimensional data in a first module and metadata regarding the index in a second module
US6438537B1 (en) * 1999-06-22 2002-08-20 Microsoft Corporation Usage based aggregation optimization
US6446059B1 (en) * 1999-06-22 2002-09-03 Microsoft Corporation Record for a multidimensional database with flexible paths
US6446063B1 (en) * 1999-06-25 2002-09-03 International Business Machines Corporation Method, system, and program for performing a join operation on a multi column table and satellite tables
US6374263B1 (en) * 1999-07-19 2002-04-16 International Business Machines Corp. System for maintaining precomputed views
US6438538B1 (en) * 1999-10-07 2002-08-20 International Business Machines Corporation Data replication in data warehousing scenarios
US6718312B1 (en) * 1999-10-12 2004-04-06 Market Design Group, Inc. Method and system for combinatorial auctions with bid composition restrictions
US6484179B1 (en) * 1999-10-25 2002-11-19 Oracle Corporation Storing multidimensional data in a relational database management system
US6434557B1 (en) * 1999-12-30 2002-08-13 Decode Genetics Ehf. Online syntheses programming technique
US20020029207A1 (en) * 2000-02-28 2002-03-07 Hyperroll, Inc. Data aggregation server for managing a multi-dimensional database and database management system having data aggregation server integrated therein
US6662174B2 (en) * 2000-04-17 2003-12-09 Brio Software, Inc. Analytical server including metrics engine

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090271384A1 (en) * 1999-08-04 2009-10-29 Hyperroll Israel, Ltd. Relational database management system having integrated non-relational multi-dimensional data store of aggregated data elements
US8799209B2 (en) 1999-08-04 2014-08-05 Yanicklo Technology Limited Liability Company Data aggregation module supporting dynamic query responsive aggregation during the servicing of database query requests provided by one or more client machines
US8788453B2 (en) 1999-08-04 2014-07-22 Yanicklo Technology Limited Liability Company Data aggregation module supporting dynamic query responsive aggregation during the servicing of database query requests provided by one or more client machines
US20050091237A1 (en) * 1999-08-04 2005-04-28 Reuven Bakalash Relational database management system having integrated non-relational multi-dimensional data store of aggregated data elements
US8463736B2 (en) 1999-08-04 2013-06-11 Yanicklo Technology Limited Liability Company Relational database management system having integrated non-relational multi-dimensional data store of aggregated data elements
US8041670B2 (en) 1999-08-04 2011-10-18 Yanicklo Technology Limited Liability Company Data aggregation module supporting dynamic query responsive aggregation during the servicing of database query requests provided by one or more client machines
US20090276410A1 (en) * 2000-02-28 2009-11-05 Hyperroll Israel, Ltd. Relational database management system (RDBMS) employing multi-dimensional database (MDDB) for servicing query statements through one or more client machines
US20090271379A1 (en) * 2000-02-28 2009-10-29 Hyperroll Israel, Ltd. Relational database management system (RDBMS) employing a relational datastore and a multi-dimensional database (MDDB) for serving query statements from client machines
US8473450B2 (en) 2000-02-28 2013-06-25 Yanicklo Technology Limited Liability Company Relational database management system (RDBMS) employing multi-dimensional database (MDDB) for servicing query statements through one or more client machines
US20100042645A1 (en) * 2000-02-28 2010-02-18 Hyperroll Israel, Ltd. System with a data aggregation module generating aggregated data for responding to OLAP analysis queries in a user transparent manner
US20100063958A1 (en) * 2000-02-28 2010-03-11 Hyperroll Israel, Ltd. Database management system (DBMS) employing a relational datastore and a multi-dimensional database (MDDB) for servicing query statements in a manner transparent to client machine
US20100100558A1 (en) * 2000-02-28 2010-04-22 Hyperroll, Inc. Method of servicing query statements from a client machine using a database management system (DBMS) employing a relational datastore and a multi-dimensional database (MDDB)
US8452804B2 (en) 2000-02-28 2013-05-28 Yanicklo Technology Limited Liability Company Database management system (DBMS) employing a relational datastore and a multi-dimensional database (MDDB) for servicing query statements in a manner transparent to client machine
US20050060325A1 (en) * 2000-02-28 2005-03-17 Reuven Bakalash Method of and apparatus for data aggregation utilizing a multidimensional database and multi-stage data aggregation operations
US7315849B2 (en) 2000-02-28 2008-01-01 Hyperroll Israel, Ltd. Enterprise-wide data-warehouse with integrated data aggregation engine
US20050055329A1 (en) * 2000-02-28 2005-03-10 Reuven Bakalash Database management system having data aggregation module integrated therein
US8170984B2 (en) 2000-02-28 2012-05-01 Yanicklo Technology Limited Liability Company System with a data aggregation module generating aggregated data for responding to OLAP analysis queries in a user transparent manner
US8195602B2 (en) 2000-02-28 2012-06-05 Yanicklo Technology Limited Liability Company Relational database management system (RDBMS) employing a relational datastore and a multi-dimensional database (MDDB) for serving query statements from client machines
US8321373B2 (en) 2000-02-28 2012-11-27 Yanicklo Technology Limited Liability Method of servicing query statements from a client machine using a database management system (DBMS) employing a relational datastore and a multi-dimensional database (MDDB)
US20040122936A1 (en) * 2002-12-20 2004-06-24 Ge Mortgage Holdings, Llc Methods and apparatus for collecting, managing and presenting enterprise performance information
US7756739B2 (en) * 2004-02-12 2010-07-13 Microsoft Corporation System and method for aggregating a measure over a non-additive account dimension
US20050182703A1 (en) * 2004-02-12 2005-08-18 D'hers Thierry System and method for semi-additive aggregation
US20110099167A1 (en) * 2004-05-26 2011-04-28 Nicholas Galbreath Graph Server Querying for Managing Social Network Information Flow
US8572221B2 (en) 2004-05-26 2013-10-29 Facebook, Inc. System and method for managing an online social network
US9241027B2 (en) 2004-05-26 2016-01-19 Facebook, Inc. System and method for managing an online social network
US9703879B2 (en) 2004-05-26 2017-07-11 Facebook, Inc. Graph server querying for managing social network information flow
US9990430B2 (en) 2004-05-26 2018-06-05 Facebook, Inc. Graph server querying for managing social network information flow
US10628502B2 (en) 2004-05-26 2020-04-21 Facebook, Inc. Graph server querying for managing social network information flow
US20110276464A1 (en) * 2005-06-29 2011-11-10 Itg Software Solutions, Inc. System and method for generating real-time indicators in a trading list or portfolio
US20150012412A1 (en) * 2005-06-29 2015-01-08 Itg Software Solutions, Inc. System and method for generating real-time indicators in a trading list or portfolio
US20170116305A1 (en) * 2015-10-23 2017-04-27 Numerify, Inc. Input Gathering System and Method for Refining, Refining or Validating Star Schema for a Source Database
US10599678B2 (en) * 2015-10-23 2020-03-24 Numerify, Inc. Input gathering system and method for defining, refining or validating star schema for a source database

Also Published As

Publication number Publication date
US7080090B2 (en) 2006-07-18

Similar Documents

Publication Publication Date Title
US7080090B2 (en) Allocation measures and metric calculations in star schema multi-dimensional data warehouse
US6941311B2 (en) Aggregate navigation system
US6748394B2 (en) Graphical user interface for relational database
US7167859B2 (en) Database security
US7890546B2 (en) Analytical server including metrics engine
US10459940B2 (en) Systems and methods for interest-driven data visualization systems utilized in interest-driven business intelligence systems
US11720598B2 (en) Data analysis engine
US7072897B2 (en) Non-additive measures and metric calculation
CN103177061B (en) Unique value estimation in partition table
US7158968B2 (en) Database query system and method
US7324991B1 (en) Sampling in a multidimensional database
US10824614B2 (en) Custom query parameters in a database system
US20110055246A1 (en) Navigation and visualization of relational database
US11720636B2 (en) Methods and user interfaces for visually analyzing data visualizations with row-level calculations
US20140258312A1 (en) Insight determination and explanation in multi-dimensional data sets
US20150081353A1 (en) Systems and Methods for Interest-Driven Business Intelligence Systems Including Segment Data
US6732115B2 (en) Chameleon measure and metric calculation
US6799175B2 (en) System and method of determining and searching for patterns in a large database
US7308457B1 (en) Method and apparatus for providing customized filters to restrict datasets retrieved from a database
US7636709B1 (en) Methods and systems for locating related reports
US10866958B2 (en) Data management system and related data recommendation method
US20160379148A1 (en) System and Methods for Interest-Driven Business Intelligence Systems with Enhanced Data Pipelines
Ankerst et al. DataJewel: integrating visualization with temporal data mining
Işık Fuzzy spatial data cube construction and its use in association rule mining
Köylü A case study in weather pattern searching using a spatial data warehouse model

Legal Events

Date Code Title Description
AS Assignment

Owner name: BRIO TECHNOLOGY, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHAH, ARUN;NOVY, ROBERT F.;ERTL, ROBERT A.;REEL/FRAME:012106/0035;SIGNING DATES FROM 20010706 TO 20010720

AS Assignment

Owner name: HYPERION SOLUTIONS CORPORATION, CALIFORNIA

Free format text: MERGER;ASSIGNOR:BRIO SOFTWARE, INC.;REEL/FRAME:014743/0063

Effective date: 20031016

Owner name: BRIO SOFTWARE, INC., CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:BRIO TECHNOLOGY, INC.;REEL/FRAME:014743/0059

Effective date: 20010919

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BEA SYSTEMS, INC.;REEL/FRAME:025747/0775

Effective date: 20110202

AS Assignment

Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HYPERION SOLUTIONS CORPORATION;REEL/FRAME:025986/0490

Effective date: 20110202

FPAY Fee payment

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553)

Year of fee payment: 12