Multidimensional domain modeling method and system5918232Abstract A system and method for computer modeling (10) and for creating hyperstructures (51) which are to be contained in a computer memory, which obtains measurements of physical objects and activities which are related to the entity to be modeled in the computer hyperstructure (51). The measurements are transformed into computer data which corresponds to the physical objects and activities external to the computer system (10). A plurality of independent dimensions (54) are created, where each dimension (54) includes at least one element (58). A plurality of cells (56) are created, each of which is associated with the intersection of two or more elements (58), each cell (56) being capable of storing at least one value. At least one rule domain (60) is associated with at least one cell (56), the rule domain (60) including at least one rule for assigning values to the associated cells (56). A domain modeling rule set (126) is prepared (300), which determines which of the rules will provide the value associated with each of the cells (56) wherein application of the domain modeling rule set (126) to the hyperstructure (51) causes a physical transformation of the data corresponding to said physical objects which are modeled in said hyperstructure (51). Also disclosed is a method for querying computer hyperstructures (51), a Hyperstructure Query Language, and a "cell explorer", which allows direct viewing of the applied formulas that produce a specific value for a cell (56). Claims What is claimed is: Description TECHNICAL FIELD
______________________________________
Rule domain
Rule Rule type
______________________________________
1994 Revenue = warehouse.actuals.rev
data map
1995 Revenue = warehouse.forecast.rev
data map
1996 Revenue = 1995 Revenue* 1.25
formula rule
______________________________________
When DOLAP calculates a revenue cell value, it selects the rule to use based on the year value associated with each particular cell. When computing values for cells, DOLAP generally has a variety of methods by which a cell is calculated. Where formulas are composed of commutative operators, such as addition or subtraction without constants, the order of operations is unimportant. However, for formulas including operations such as multiplication and division, the order of operations is important. The DOLAP design incorporates rule prioritization to address this problem while exploiting rule generality as much as possible. To determine how to compute the value for a cell, DOLAP scans all the rules that could apply to the cell and selects one according to its rule precedence algorithms. In general, DOLAP gives preference to rules with more specific rule domains, and to rules specified by the model builder, as opposed to rules inferred by database schema. A variety of user interface tools are provided. Model Builders use the Library Explorer portion of the client application (to create new models or open existing models) and the Modeler's Workbench (to create the structure of a datacube). The Library Explorer displays the contents of the server's repository using a split window to manage its objects. A Schema Explorer allows users with administrative privileges to specify what databases are to be accessible to the models in a particular library. A SQL Audit facility allows a user to audit HQL queries that are sent from the client to the server and view the series of SQL queries that were generated by the Calculation Engine in the fulfillment of the HQL query. A UserEnteredValue List Window provides a means by which a model user can see which user entered values have been entered into the datacube and delete any which are no longer desirable. A Worksheet is a multidimensional view of a subset of the datacube. It allows custom views of the model to be created and UEVs to be entered. FIG. 6 illustrates the relationships between entities involved in a DOLAP modeling system 10. The model 50 is a named file-like package, which receive inputs from many sources. The user 72 is a named person who has access rights to the model 50, either individually or as part of a group 74. The persistent object manager 20 holds the DOLAP models 50 as well as meta-data used by the models managed by the server 12. It also holds BLOBS 76 that are arbitrary data streams stored on behalf of a third party DOLAP client application which are associated with a particular model. A group of related functions have been shown as a model structure and UEV module 78. A group of model data maps 80 contains database-mapping rules that are attached to the model 50. This includes a group of rule domains 82. An element 58, which is included in a dimension 54, can receive input from formula rules 84, which are also included in the model 50. The formula rules 84 include the rule domain section 86, which provides a description of the part of the datacube 52 (see FIG. 2) for which a formula can be used to calculate cell values. The rule domains 86 are also included in the model tables 88. Certain elements, dynamic parents, have dynamic element specifictions which are used to generate hierarchies of elements under the dynamic parents. The DES specifies database tables whose columns contain key values and names for the elements in the hierarchy. Element 58 can also obtain input from either the metric database mapping rules 92 or the qualifier database mapping rules 94, which tell DOLAP where in the databases the raw data used in the calculations is found. The metric data base rules 92 contain rules associated with a metric-type element which represents the "what" part of the name or address of a cell 56 in a datacube 52 (see FIG. 2). Generally the metric rules 92 associate a measure such as Revenue with a numeric column. The qualifier data map rules 94, for qualifier elements such as time, include information that DOLAP eventually turns into a SQL WHERE clause that identifies the database table rows containing data that applies to the element. The calculation engine 18 (see FIG. 1) uses this information, in combination with information from the other dimensions, to help determine which table to access to get data for the model 50. The datamapping for a qualifier element will have been created by the dynamic element generation process that created the hierarchy in which the qualifier element exists. A User Entered Value (UEV) 96 is a single number which is created (or modified) when a user manually types or pastes a value into a cell 56 in a model 50 (see FIG. 2). This UEV consists of an address (which corresponds to the address of the cell) and a value. These UEVs 96 supersede the values calculated from rules at the same level of specificity (unless there are other more specific rules) and are used by DOLAP to calculate the values for other cells whose values depend on them. UEVs 96 are commonly used to override numbers for what-if analysis and to enter and edit values for business drivers. The UEVs 96 are stored in a UEV set 98 which is included in the model 50. A cell address 100 specifies one element from each of the dimensions necessary to locate a cell 56 in a datacube 52 (see FIG. 2) and can be used to specify UEVs 96. Only a tiny fraction of the cells 56 in a model 50 actually represent meaningful information. Users and client applications attempting to navigate the datacube can frequently benefit from guidance as to where the useful information resides in the datacube 52 (see FIG. 2). The DOLAP Client Application lets the model builder create and maintain an infospace 102 that defines a set of dimension and default element combinations which in turn define useful portions of the DOLAP datacube. The schema 104 is a set of persistent objects stored in a repository that specifies how information is stored in databases, tables and their component columns. Schema 104 contains the physical table configuration and relationship between tables of data. The schema object 106 contains the descriptions of the columns 108, tables 110, databases 112, and servers 114 corresponding to the contents of the data warehouses 16. Columns in specified tables can be linked or joined together. The join path 116 is the preferred join out of all possible joins between any two tables in the databases of a DOLAP schema, and may be the default or user-set path. The purpose of DOLAP 10 is to retrieve data from one or more databases 16 (see FIG. 1), perform calculations as specified by the model 50, and return values for specified cells 56 (FIG. 2) to users via client applications 40 (FIG. 1). The core part of this functionality, the retrieval and caching of data and computation of cell values for the model, is handled by the calculation engine 18. The calculation engine 18 is divided into a number of cooperating subsystems and data structures, augmented by several auxiliary subsystems. FIG. 7 illustrates the components of the calculation engine 18. It communicates with the client request manager 24, from which the calculation engine 18 receives queries, and to which it returns results in response to these queries. The engine 18 also communicates with the persistent object manager 20 which contains the model 50 and the schema 104. Additionally the calculation engine 18 communicates with the database interface 26 that includes a query dispatcher 120 and an Open Data Base Connectivity (ODBC) portion 30. An incoming client request is routed to an HQL parser 122 which transforms the HQL query from its textual form into an internal representation. After the internal representation of the query is made, the calculation engine 18 looks in the query results cache 124 to see if the query (or any portion of it) can be retrieved from the cache in order to save processing time. A Domain Modeling Rule Set 126 receives input from both the model 50 and the schema 104, and provides input to the rule evaluator 128, which then communicates with the execution plan 130 and the query engine 132. The query engine 132 creates SQL queries from HQL queries and optimizes these SQL queries by combining them (whenever possible) and also optimizes the performance of the calculation engine 18 by performing as many calculations as possible with SQL statements executed by the database. The SQL is sent to the query dispatcher 120, which accesses the data in the databases through the ODBC 30. The results are sent to the result extractor 134 which communicates with the query result cache 124 and the rule evaluator 128. The results may then be sent to the client request manager 24, and subsequently to the client application. The steps involved in this process are shown in FIG. 8 as a generalized flowchart of DOLAP operations in response to a user query. The steps of the flowcharts to follow may be implemented by one or more software routines, processes, subroutines, modules, etc. It will be apparent that each flowchart is merely illustrative of the broad logical flow of the method of the present invention and that steps may be added to, or taken away from, the flowcharts without departing from the scope of the invention. Further, the order of execution of steps in the flowcharts may change according to different implementations such as interrupt-driven, polled, etc., event-handling. A multiprocessing or multitasking environment could allow steps to be executed concurrently. For ease of discussion, the implementation of each flowchart is referred to as if the flowchart were implemented in a single "routine". The method 200 starts as a Hyperstructure Query Language (HQL) query 202 which is passed to a parser 122 which converts the HQL text to a query component tree 204 which represents the component parts of the query 202. This is sent to the calculation engine 18. The model metadata 206 is the information about the structure of the model 50 (see FIG. 2) which has been previously constructed. These are provided to Domain Modeling Rule Set Preparation 208 which generates the domain modeling rule set 126, which are then supplied to the calculation engine 18, which takes the applicable rules and adds them to the query tree 204 to produce an execution tree with rules 212 for the query engine 132. This query engine 132 produces the optimized execution tree 214 by combining queries and delegating calculations to the database server, whenever possible. The optimized execution tree 214 is passed to the evaluator 128 which decides whether further data is required from a relational database. If further data is required, evaluator 128 communicates with a Relational DataBase Management System (RDBMS) 216 through an SQL generator 218. Evaluator 128 can also communicate with a math library 220, if a calculation is required, or a sorting and processing system 222, if the process requires ordering of results or sorting in some manner. In order to save processing time, values which have been previously calculated may be obtained from cache retrieval 224 which accesses a multi-dimensional cache 226. The execution tree with results 228 then proceeds and, if it is done 232, it may be sent to result packaging 234 for eventual output of the query results 236. The query 202 may include an inner query that must be processed before the query as a whole can be processed. In this case after one pass through the process, when arriving at the decision box, the result will be not done 230, and the process will continue around the loop again until completed. When following the previous process, it is important that the system be able to determine which formulas apply to a certain cell. If there are multiple formulas that apply, there must be a hierarchy of rules established so that the correct formula is used and, consequently, the correct value is assigned. This hierarchy of rules and the associated priorities involved are very important to Domain Modeling. The Domain Modeling Rule Set 126 (see FIG. 7) is a run-time data structure used by the calculation engine 18 to resolve requests. Domain Modeling Rule Set 126 is prepared from the model description and embodies DOLAP's knowledge of all rules within the complete datacube 52 defined by all the elements 58 of all the dimensions 54 in the model 50 (see FIG. 2). The structure is created by calculating the effective Rule Domain for each metric database map, UEV, and formula rule in the model, and prioritizing them so that the proper rules will be executed. Domain Modeling Rule Set Preparation is triggered by the first HQL request after the model is opened or after the model is changed, unless the only changes were UEV value changes or if user requests to see the rule for a cell. Domain Modeling Rule Set Preparation is the process of gathering all of the rules from the model, turning them into valid actions that can be used by the calculation engine, and prioritizing them so that the proper rules take precedence. In the process, Domain Modeling Rule Set Preparation must check for conflicts in the rules, i.e. situations where it is ambiguous which rule should take precedence in a case where the results of applying the two rules would yield different results. Domain Modeling Rule Set Preparation supports an Application Program Interface that can specify for a client which specific rule was/would be used to calculate the value for any cell in the model. Rules drive all computations within the DOLAP Server. They are stored in the model as UEVs, formulas and datamaps and are composed of two parts, 1) a rule domain and 2) an action. The rule domain specifies the cells whose values can be computed by the rule's action. The rule domain is rectangular, i.e., it is a sub-cube of the model datacube. The rule domain is restricted to the rule domain as specified by the user, but additionally reduced as described below. DOLAP supports three different kinds of actions: UEVs, datamaps and formulas. UEVs are the simplest rules within DOLAP. The action of UEVs is simply to supply a constant value, while the UEV's address is used as their rule domain. Formulas are attached to specific elements in the model, with the element forming an implicit part of the formula's rule domain. The formula expression itself is the action. Datamap rules map a cell value to the value from a column in a database table. Essentially, a datamap rule is a SQL SELECT statement, specifying which rows from a table have to be selected and which column from the selected rows contains the value. Additionally, there are autoformulas which are default rules which describe very generic processes, for example, "the value of a parent equals the sum of its children". These "unpromoted" autoformulas are the lowest level in priority of application unless their priority has been adjusted higher to "promote" them. The unpromoted autoformulas only apply where higher priority rules have not been imposed and can therefore be discarded from the prepared rules. A second round of rule promotions will cause additional autoformulas to be retained, where the autoformula refers to a value that will be retrieved via a metric data map. Unpromoted autoformulas for dynamic elements are created from generic autoformulas which are generated from dynamic element specifications. FIG. 9 is a flowchart which shows the general steps involved in Domain Modeling Rule Set Preparation. The smaller steps involved in each general step are shown in greater detail in FIGS. 10-17. The overall process of Domain Modeling Rule Set Preparation is referred to by the reference number 300. In referring back to FIG. 8, this process takes place in Domain Modeling Rule Set Preparation 208, and the end product is the domain modeling rule set 126, which are input to the calculation engine 18. Returning to FIG. 9, the first step in Domain Modeling Rule Set Preparation process 300 is to gather the rules 400 from the model and convert them to the uniform representation that will be used by the calculation engine 18 (FIG. 8). Next, the autoformulas are processed 500, followed by processing the metric datamaps 600. The rules are then ordered 700, certain of the rules are promoted 800, and conflicts between rules are processed 900. Then Domain Modeling Rule Set Preparation is then done 995. The user enters UEVs explicitly, so their conversion is straightforward. The elements that are specified in the address are the rule domain for UEVs. For dimensions not specified in the address, the Rule Domain is set to include all elements in those dimensions, including the Not Specified (N/S) element. Formulas are also entered by the user explicitly, and are attached to the elements. The rule domains are initially set to the rule domain specified by the user, with the rule domain in the dimension of the element containing just that element. List formula rule domains require additional processing. All the elements that have an attribute "do not aggregate" are removed from the rule domains of the list formula rules, which would otherwise be used to compute the "do not aggregate" element. The one exception is that if the element that this formula is attached to is marked with "do not aggregate", DOLAP will not remove this element from its own formula's rule domain. FIG. 10 shows the general step of gathering rules 400 in more detail. A list of rules having "Do Not Aggregate" properties is built 405. The next rule is fetched 410. If there are no more rules to fetch 415, the routine is done 490. If not, the rule is tested to see if it is a datamap 420, an autoformula 430, or an aggregation 440. Datamaps are saved in a Datamap List 425, autoformulas are added to an Autoformula List 435. If the rule is an aggregation, a subroutine to Add/Create Time Summary Properties (TSP) Rules 450 is called. The details of this subroutine are seen in FIG. 11, to be discussed below. If the rule is neither a datamap, autoformula or aggregation it is added to the Rules List 460 through another subroutine, details of which are seen in FIG. 12 below. The routine loops back to step 410 to get the next rule, and this loop is repeated until the last rule has been processed 415, at which time the routine is done 490. The time summary property requires special support during Rule Gathering. Two inputs create these time summary rules: 1) list formulas in the time dimension that have their type set to Aggregate, and 2) elements that are not in the time dimension that specify a time summary property other than "None". The first of these inputs contains a rule domain and operands, but no operator; the second defines the operator (i.e. sum, avg, min, max, first, last). The two in combination form a complete rule. The Not Specified element (N/S) will have "None" for its time summary property. For every such pair where the element with the time summary property is within the rule domain of the aggregation formula, Domain Modeling Rule Set Preparation will create the rule and will adjust its rule domain to contain all the elements with the time summary property in that element's dimension. The other dimensions will remain unchanged. FIG. 11 shows details of the Add/Create TSP Rules subroutine 450, which is called from various points in the whole program. The next TSP in the model is fetched 452. If there are no more TSPs 454, the subroutine is done 458. If not, a new rule is created for that TSP which is derived from the original formula 456 according to the procedure described in the paragraph above. Next, the subroutine is called to add it to the Rules List 460 (see FIG. 12). The program loops back to 452 to get the next TSP until all have been processed and the loop is done 458. FIG. 12 illustrates details of the Add to Rules List subroutine 460, which is called from different points in the program. The rule is tested to see if it is a list formula 462. If not, it is appended to the Rules List 474 and the subroutine is done 476. If it is a list formula, the next element in its rule domain is fetched 464. If there are no more elements 466, the rule is appended to the Rules List 474. If not, the element is checked to see if it has a "Do Not Aggregate" property 468. If it does not, the next element is fetched 464. If it does, the element is checked to see if it is in the dimension of the element to which this rule is attached 470. If yes, the next element is gotten 464, if no, the element is removed from the formula's domain 472 and the next element is gotten 464. The subroutine is looped until each element has been checked 466, and then the rule is appended to the Rules List 474 and the routine is done 476. FIG. 13 shows details of the general step of processing the autoformulas 500. The next rule in the Autoformula List is fetched 510. There is a test to see if the end of the list has been reached 520. If yes, the routine is done 540. If no, the rule is tested to see if it is in the Time dimension 530. If not, the rule is sent to the Add to Rules List subroutine 460. If the rule is in the Time Dimension, it is sent to the Add/Create TSP Rules subroutine 450. The routine loops back to get the next rule 510, until all rules are processed 520 and the routine is done 540. Datamap rules are constructed from metric datamaps, qualifier datamaps, and model table rule domains supplied by the user. The metric datamap specifies the table, and column to be used. In addition, there are qualifier datamaps that can be used to select specific rows from the table containing the metric column. FIG. 14 illustrates details of the general processing of Metric Datamaps 600. Hierarchies and levels are gathered from all dimensions 605. The next rule is fetched from the Datamap Rules List 610, and checked to see if it is the end of the list 615. If so, the routine is done 620. If not, all elements and dimensions are set as valid for the current datamap 625. The next hierarchy is fetched 630 and checked to see if it is the last 635. If it is, the rule domain specified by the user for the metric datamap's table is accessed. Any elements not specified in the table rule domain are turned off for the datamap's rule 640, and the rule is added to the Rules List by the subroutine 460. If the hierarchy is not the last, the next level is fetched from the bottom level up 645 and tested to see if it is the last level 650. If so, the program loops back to get the next hierarchy 630. If not, the level is tested to see if the datamap's metric table is joinable to the previous level 655. If not, the next level is fetched 645, and if so, then the level is tested to see if this is the first level encountered in this dimension which is joinable 660. If not, the level's elements are added to the rule's domain 670. If so, all elements from the dimension are turned off 665 before adding the level's elements to the rule domain 670. If the rule has non-sum TSP or is marked "Do not aggregate" and is the lowest level of this hierarchy, then it is considered a low-level datamap 675 and the program loops back to get the next hierarchy 630. If not, the program loops back to get the next level 645. The routine repeats until the last datarnap rule has been processed 615 and the routine is done 620. DOLAP allows a model to include more than one rule that computes the same cell in the data cube. If multiple rules can compute the same cell, DOLAP has to choose which rule to apply. The rule precedence scheme described below is based on the premise that database-mapping rules inherently have a lower priority than rules attached or specified for specific elements in the model. Another way of looking at this rule procedure scheme is that user entered model rules override the values that are stored in the database. Model rules include UEVs and user entered formulas. Model level rules are prioritized first by their specificity, with highest specificity first, and lowest specificity last. Specificity is determined by the number of dimensions specified for the domain of the UEV or formula. For UEVs, the number of dimensions specified in the UEV address is the specificity. For formulas, specificity is the number of dimensions specified in the rule domain. If this formula is attached to an element, the dimension of the element is included as a specified dimension. Within one group with similar specificity, the model rules are prioritized by their types. UEVs are first, followed by formulas. Formulas, including user entered formulas and autoformulas, are further broken down into high-priority and low-priority formulas. A lowpriority formula is defined as one that contains a single element with no operators, or a formula made up entirely of sum, +and - operators. All other formulas aformulas. Thus, the high-priority formulas. Thus, the order of precedence for model rules of equal specificity is UEVs, high-priority formulas, and low-priority formulas. Database rules include database mapping rules and promoted and unpromoted autoformulas created for parent elements in dynamically generated hierarchies, since these represent aggregations that can be performed in the database. Database mapping rules take precedence over the unpromoted autoformulas to ensure that as much aggregating of values is done in the database as possible. The promoted autoformulas are given higher priority than the database mapping rules in cases where the user has specified a model level rule that overrides a value that would otherwise be taken from the database. Putting these items just above the database mapping rules will ensure that the program does not go to the database to get values, but rather, uses the autoformulas to get to the user entered value or rule. The following outline summarizes how rules are sorted into priority groups. Model Rules Specificity--highest UEVs High-priority formulas Low-priority formulas (each level of specificity repeats the pattern) Specificity--lowest UEVs High-priority formulas Low-priority formulas Database Rules Promoted Autoformulas Datamap Rules Unpromoted Autoformulas FIG. 15 shows the details involved in the general step of ordering the rules 700. It will be understood that the method illustrated for ordering the rules is subject to considerable variation (for example, in the values assigned for primary and secondary sorting) and other methods of ordering the rules may be employed. The next rule is fetched from the Rules List 710. If there are no more rules left 720, the Rules List is sorted 770, to be discussed below. If there are more rules, the rule is tested to see if it is an autoformula 725. If so, it is assigned a primary sort value of zero 730 and sent to be assigned a secondary sort value 750, to be discussed below. If the rule is not an autoformula, it is tested to see if it is a metric datamap 735. If so, it is assigned a primary sort value of one 740 and sent to be assigned a secondary sort value 750, to be discussed below. If the rule is not a metric datamap, the rule is assigned a primary sort value 745 equal to 3 times its specificity plus zero for a low priority rule type, plus one for a high priority rule type, or plus two for a User Entered Value. The rule is then assigned a secondary sort value 750 equal to "y", where y may be chosen from the following assignment scheme:
______________________________________
Rule type Characteristic
Value(s)
______________________________________
UEV (all formulas)
1
High Priority
(all formulas)
1
Low Priority
Non-sum operators
Dimension#
Sum operators
Dimension# + #dims in model
Datamap (all formulas)
Row count
Auto formula
(all formulas)
Dimension#
______________________________________
The routine loops back to get the next rule from the Rules List 710 until all rules are processed 720. The Rules List is then sorted with descending primary values and ascending secondary values 770. The routine is then done 780. Even with the above structure, it is possible for two or more rules to end up in the same priority catagory. The following section describes how DOLAP resolves the situation for each of the lowest divisions. High-priority formulas: Multiple high-priority formulas will yield a conflict. DOLAP will report this conflict. Users must resolve these conflicts with rule domains. Low-priority formulas: This may or may not yield a conflict. The concept of commutative formula pairs is used to resolve conflicts. One definition used in a version of the present invention limits commutative formula pairs to those that sum their children, because such commutative formula pairs are mathematically guaranteed to produce equivalent results. Analysis of formula pairs resolves questions of which formula should be used and whether a conflict exists. Not all combinations of pairs need to be analyzed. The process can start with any two formulas and compare the "winner" with the next arbitrarily ordered formula, tossing away the "loser". The results of a pair comparison will yield one of: 1. A true conflict. This occurs when the formulas are not commutative. There is no need to continue the analysis. 2. A "winner" is determined. This occurs when the formulas are commutative, and the formulas are associated with different dimensions. The winner is the formula whose dimension has higher priority, with higher priority being determined by which dimension appears first in the order of dimensions. 3. A commutative conflict. This occurs when the formulas are commutative, but are associated with the same dimension. If this occurs on the last pair of rules to be compared, a conflict will result. If there are more rules remaining to be compared, the scanning will continue in the hope of finding a new "winner", that is a commutative rule with a dimension with higher priority. If none is found, the conflict condition will result. For prioritizing datamap rules, when multiple datamap rules are available, the DOLAP server will prioritize them according to the last known row count that each table is known to have. The smaller the number of rows in the table, the higher priority the rule has. If two tables have the same row count, RSP will prioritize the two arbitrarily, and that order will hold consistently for as long as that version of the prepared rules are used. For prioritizing promoted/unpromoted autoformulas, if there is more than one, the program will choose first the time dimension formula if there is one. This is to ensure that time summary properties that are not summed will be computed first, leaving a query that can be aggregated in the database. If there is no time dimension formula, the program will choose from the other dimensions by dimension priority, with the first dimension being the highest priority. No conflicts are possible, because there can be at most one formula associated with each dimension. The precedence determination scheme described above requires that the program will promote autoformula rules to be model level rules when any of their inputs derive from model level rules. This ensures that when a model level rule, like a UEV, is entered at a given level, the autoformulas that can sum that cell will take precedence over rules that retrieve data from the database. Thus, the datamap rules for intermediate levels will not be used, and the sum that will include the model rule (UEV in this case) will be used. When the autoformula is promoted, only the parts of the rule domains that are affected by the model rules will be included with the promoted autoformula. The remaining parts of rule domain will remain with the unpromoted autoformula. The procedure to promote the rules is as follows: 1. Split all the rules into two groups: model rules (UEVs and formulae) and DB rules (datamap rules and autoformula rules). The rules from the first group have higher priority than rules in the second group. 2. For each model rule that can provide a value to an operand of an autoformula rule, find a sub-domain of the autoformula rule that it computes and move this portion of the autoformula rule into the promoted autoformula rules group and repeat the process. FIG. 16 illustrates the detailed steps involved in the general step of promoting rules 800. The next rule is fetched from the Rules List 805. If there are no more rules to process, the routine branches down to step 850, to be discussed below. If it is not the last rule, it is tested to see if it is a User Entered Value 815 or a non-autoformula 820. If it is either of these, the rule is added to the Trigger List 825. If it is neither, the routine loops back to get the next rule 805. When the last rule has been processed, the routine switches to the Trigger List and fetches the next rule from the Trigger List 850. If there are no more 855, the routine is done 890. If not, the next generic autoformula in the Autoformula List is fetched 860. There is a test to see if there are no more autoformulas 865. If the next generic autoformula was not the last, the elements which could be computed directly or indirectly from the rule from the Trigger list are computed from the autoformula's dimension 870, and the routine loops back to get the next autoformula 860. If the end of the autoformula list has been reached 865, the autoformula list is started over by fetching the next autoformula 875, which is then checked for the end of the list 880. If the end of the autoformula list has not been reached, a promoted autoformula rule is created 885, where its rule domain equals the Trigger Rule's elements from the autoformula dimension plus the Trigger Rule's elements and the affected elements from all dimensions. The routine loops to get the next autoformula 875 until the end of the list is reached 880 and the routine then loops back to get the next Trigger rule 850 until the end of this list is reached 855 and the routine is done 890. It is possible and likely that in the process of building a model, the user will define rules and datamaps which result in conflicting rules. Conflicts may be handled in the following manner: 1) Domain Modeling Rule Set Preparation will create "transient" formulas, with properties available to the client as follows: the two rules that conflicted, the time summary property for each (if needed). 2) When the server dumps prepared rules in response to appropriate model changes, the transient formulas will also be invalidated. 3) Because of 2), the client application must cache all rule conflict data locally, since the data could be invalid later on. 4) An API returns conflict pairs of formulas, eliminating duplicate pairs. No rule domain info is returned; the client will presumably retrieve the original rule domains from the model using the handles provided, sometimes indirectly, (cf 5, below), where the handle to the metric table would have to be searched for in the models' table datamaps, to find the rule domain attached to the table. 5) Datamap conflict rules return a handle to the associated metric table. FIG. 17 shows the detailed steps involved in the general step of resolving conflicts 900. The next rule is fetched from the Rules List 905, and there is a test for the end of the list 910. If so, the routine is done 990. If not, the rule is tested to see if it is a User Entered Value (UEV) 915. If so, a check set consisting of all UEVs with equivalent specificity is created 920 and the routine branches to step 950, to be discussed below. If not a UEV, the rule is checked for high priority 925. If so, a check set of high priority rules with equivalent specificity is created 930, and then the routine goes to step 950, to be discussed below. If not a high priority rule, it is tested for low priority and non-commutative properties 935. If it is a low priority rule with non-commutative properties, a check set of low priority rules with equivalent specificity is created 940, and the routine goes to step 950, below. If the rule is not both low priority and non-commutative, a check set of commutative low priority rules with equivalent specificity from the same dimension is created 945. The routine then goes to step 950, referred to above, which does a pairwise comparison of all the rules in the set. For each pair with intersecting rule domains, a conflict rule with the rule domain equal to the intersection with the set is inserted ahead of the rule in the Rules List 955. The references to the conflicting rules are then saved 960. The routine then loops back to fetch the next rule 905. The routine continues until the last rule has been processed 910 and the routine is done 990. In order for the user, who may not have an extensive background in computer programming, to see how the value contained in a particular cell is calculated, DOLAP 10 is equipped with a graphic user interface called the Cell Explorer. The Cell Explorer enables the user to explore values in a model's data cube 52 easily without the distraction of non-essential values that are usually visible in a worksheet. It is also useful for correcting errors in the model 50 in later stages of development. The Cell Explorer is available from the Tools .vertline.Cell Explorer menu command whenever the Modeler's Workbench or a Worksheet is the active window. The Cell Explorer gives the user a way of exploring the calculation process of a particular cell 56 from the model's datacube 52. This is similar to having a one-cell worksheet. In addition to seeing the value for the data cell 56 and the rule that was used to calculate the cell 56, the Cell Explorer also enables the user to view the source and parent elements for selected elements that make up the data cell's 56 address. In addition, like worksheets, the user can display the SQL Audit window to view the SQL queries generated by the Cell Explorer. The user can open multiple Cell Explorers by repeatedly using the Tools .vertline. Cell Explorer menu item from the Modeler's Workbench or from a worksheet. When the user opens the Cell Explorer from the Modeler's Workbench, the data cell 56 of interest is determined by using the default element of each dimension 54 in the model 50. If the user has not assigned a default element for a dimension 54, Cell Explorer will use the first element 58 in the dimension 54. When opened from a worksheet, the Cell Explorer uses the currently selected worksheet cell. If the worksheet has no elements 58 in it (e.g. has just been created) and is the active window, the Cell Explorer command is disabled. The Cell Explorer can be closed by using the File .vertline. Close menu command or the close box in the upper right-hand corner of the window. The user can also minimize, maximize, and restore the window using the appropriate window boxes. While the Cell Explorer is minimized, it will continue to recompute the data cell 56 and sources values if the auto-recalc mode is turned on. To obtain the value of the data cell and source cells, the Cell Explorer makes a query to the DOLAP server. If the window's auto-recalc setting is on, a query will be made whenever the focus cell is changed, the model 50 changes, or a UEV 96 is changed. Otherwise, clicking the Recalc button on the toolbar will cause the query. While the query is in progress, a modal dialog will be presented allowing the user to cancel the query before it finishes, if desired. If the query is cancelled, the Cell explorer's auto-recalc setting will be changed to OFF. If appropriate model changes have been made, or if this is the first query to the model, the DOLAP server will prepare the model's rules, and a message to that effect will appear in the progress dialog. The Cell Explorer window is divided into an upper pane and a lower pane within a resizable window divided by a user-adjustable splitter bar. The top pane displays information for the data cell of interest. Stacked vertically in the middle of the pane are tiles/buttons representing the address of the focus cell. The top button contains an edit text control with the value of the focus cell (assuming its value is being computed - see below). One of these buttons will be selected. On the left hand side is a stack of buttons representing the children of the selected center-column element. Clicking on one of the center buttons causes that element's children to be displayed on the left hand side. The right hand column contains a similar stack of buttons representing the parents of the element selected in the center column, and clicking one of the center buttons updates the right hand column as well. The buttons in the left and right hand columns each contain a static text which contains the value of the cell represented by substituting that element into the cell address of the center column. A vertical scroll bar appears for the top pane if all the element buttons will not fit in the pane, so the user can scroll up/down to bring desired element buttons into view. The lower pane of the window contains three checkboxes, indicating whether or not the cell values for the child cell(s), focus cell, and parent cell(s) should be queried for and displayed, allowing a user who is just navigating to do so without waiting for the server to compute those values. This pane also displays the name and expression for the rule used to compute the data cell's value. (Note that this rule will not necessarily refer to the elements in the Sources list.) The contents of this field will be the same as if this cell is selected in a worksheet. Typing into the focus cell's value field adds a User Entered Value (UEV) 96 to the model 50 or replaces the one already defined for that cell 56. The values for the focus cell and sources cells will be formatted according to the formatting specified for the element from the Time Summary Property dimension of the model. The lower pane also contains a field containing the model builder's description of the element selected in the central column. The left column, titled "Sources", contains the list of the children elements for the selected data cell address element. Values for the cell's address by child element are also displayed. The top item of the center column displays the data cell's computed value. If the cell returns an error, "Error" will be displayed in the value. Also, the display shows the data cell's address as a list of the elements (buttons) that make up the cell address. Elements which have children are displayed with an arrow icon to the left of the element's name. Elements that are used by other elements (parent elements) are displayed with an arrow icon to the right of the element's name. The right column, titled "Uses", shows the elements whose values can be computed from the selected data cell address element. When the Cell Explorer is first opened, a data cell address is already specified. However, the user can change the data cell by modifying the elements in the data cell address portion of the window. The address of UEVs entered in the Cell Explorer is specified in the same number of dimensions as the Cell Explorer itself, with all other dimensions wildcarded. To specify a data cell, the following operations may be performed: To use a Source or Uses element: 1. Select a data cell address element by depressing the button. 2. If Source or Uses elements are available, they are displayed in their respective lists. 3. Double-click on a Source or Uses element. Cell Explorer replaces the currently selected data cell address element with the Source or Uses element. The data cell's value is then queried for and displayed and the new rule is displayed, according to the window's auto-recalc setting. To add address elements: 1. Drag an element from the Modeler's Workbench or the worksheet and drop it on the data cell address portion of the window. The user can also paste an element from the clipboard. If the dimension for the new element is already referenced in the data cell address, the new element replaces the existing element for that dimension. If the dimension is not currently referenced, the new element is added to the address. 2. The data cell's value is recomputed and the new rule is displayed, according to the window's auto-recalc setting. To delete address elements: 1. Select an element in the data cell address. 2. Press the Del key or use the Edit .vertline. Delete menu command. 3. The data cell's value is recomputed and the new rule is displayed, according to the window's auto-recalc setting. Note that since deleting an element also removes the dimension the element belongs to, the dimensionality of the data cell is reduced. Hyperstructure Query Language (HQL) is used for querying the DOLAP system for data. It is a data manipulation language only, not a data definition language. Data definition is accomplished via the DOLAP Application Programming Interface. HQL is a "technical language", like SQL. HQL queries will usually be created automatically by software, by the DOLAP Client Application Worksheet or 3rd party report generators. Like SQL, HQL may be used in a simplistic manner by naive users, in a more sophisticated manner by power users, and in its full power and complexity only by experts. A query expressed in HQL, the Hyperstructure Query Language, is sent to the DOLAP Server for an open DOLAP model. Queries fetch cell values from the datacube, fetch lists of qualifying elements (optionally with their selected attribute values), or fetch lists of unique attribute values. Model metadata is retrieved using the API, not queries. Query processing can take place in both the DOLAP Server and the database server, depending on the amount of optimization that DOLAP can achieve. Every effort is made to "push" computation into the database server, to take advantage of its computational power and to decrease bandwidth demands on the network hosting the DOLAP and database servers. Query language supports grouping operator: (). The DOLAP Client interprets quotes in HQL and custom formulas as follows: two adjacent double quotes translates to one double quote as part of an element name; a double quote not adjacent to another double quote is treated as a grouping operator. When elements in different dimensions have the same name, then the user must disambiguate them using the syntax <dimension-name>.<element-name> Numeric constants and string constants may be used in query specifications. It can support "cutoff" type element query functions: <element-list>WHERE "TOP" or "BOTTOM"<integer> Elements are disambiguated by <dimension-name>.<element-name>Query language includes structural element query function: ChildrenOf, returns elements in the order defined by the element hierarchy, except for TDE's. Query language includes structural element query function: DescendantsOf. Query language includes structural element query function: LeavesOf. Query language includes structural element query function: ParentsOf (INDENT?) Query language includes structural element query function: ParentOf. Query language includes structural element query function: RootsOf Query language includes structural element query function: AncestorsOf. Supported decimal separators are periods. Supported list separators are commas. A query for ChildenOf(dimension) will return the root elements of the dimension in the order they appear in the MWB. Element attribute comparisons are by default case sensitive, for search and sorts. Support element with (list of) attribute(s) and value(s) query. The result of a metric comparison between a cell value and a multi-dimensional tuple is true if at least one of the individual comparisons is true. Interpretation of the following items is case-insensitive: logical database name, model names, worksheet names, info space names, BLOB names, dimension names, level names, element names, attribute names, HQL keywords, custom function names, and custom formula keywords. HQL supports UPPER and LOWER functions applied to attributes in WHERE and ORDER BY clauses; this enables case-insensitive attribute sorts and comparisons. The user can query by element name for transients by using the "name" attribute Numeric sort: nulls and errors ordered first for ascending sorts and last for descending sorts, sub-sorted by internal error numbers assigned String sort: nulls will be sorted first for string comparisons for ascending sorts and last for descending sorts. HQL is used by any application (Sybase or 3rd party) via the DOLAP API. In the DOLAP Client Application, HQL may be visible in error log file entries, the IHQL Window and the SQL Audit window. The Hyperstructure Query Language, HQL, is how a request for such data is expressed. There is one "entry point" to the Query Language Grammar. This is the symbol query in the language grammar below. There are four variants of a query: cell-query (yields cells labeled with elements) element-query (yields a list of elements from a dimension) element-attribute-value-query(yields a list of elements and one or more attribute values for each) attribute-value-query (yields a list of unique attribute values). Most queries are cell-queries, since DOLAP is most often used to analyze the numbers in the multidimensional datacube described by a model. The DOLAP Client Application Worksheet generates cell-queries to retrieve the numbers it displays. Element, element-attribute-value, and attribute-value queries will typically be used by third party metadata exploration tools such as the so-called "knock-down browser". The attribute mechanism allows searching the element space (the DOLAP metadata) by relational data available in the SQL Database only. The most common use of element, element-attribute-value, and attribute-value queries is as sub-queries embedded within a cell query, generally created and issued programmatically through the DOLAP API by 3rd party client applications. Queries involving transient dynamic elements (TDEs) are specified and processed just like those involving non-TDEs, except that: 1. TDEs cannot be specified by name in ElementSelects. 2. They cannot be queried for directly using an element query. This can be accomplished by specifying a "name" attribute for the transient level of the dynamic hierarchy, associating it with the same column that specifies the name for the TDEs, and using an element-attribute-value query. 3. Results will not be cached. Grammar for HQL (Extended Backus-Naur Form) Basic Blocks Literals: integers, numbers including standard scientific notation, string constants, which are any sequence of characters in single quotes, dates, and identifiers, which can be either a regular identifier which starts with a letter, or a delimited identifier which is any sequence of characters enclosed in double quotes. Additionally, there are the following keywords:
______________________________________
ANCESTORS OF AND ASCENDING ATTRIBUTE
ATTRIBUTES
BOTTOM BY
CELL CHILDREN OF
DESCENDANTS OF
DESCENDING DISTINCT
ELEMENT NAME ERROR
FROM
INVALID REFERENCE
LEAVES OF LEVEL LOWER
MATH ERROR NOT NULL
ONLY OR ORDER ORDERED
PARENT OF PARENTS OF
ROOTS OF RULE CONFLICT RULE MISSING
SELECT
TOP
UPPER USER DEFINED ERROR
WHERE WITH
______________________________________
Keywords are case-insensitive Whitespace (any sequence of spaces, tabs, carriage returns, line feeds, and/or form feeds) is ignored except within string constants or quoted identifiers. Referencing Elements, Dimensions, Levels and Attributes A dimension is just an identifier: Dimension: Identifier An element reference is either an element name alone, or an element name together with the dimension name, in the form <dimension-name>.<element-name>. This form must be used when the same element name is used in multiple dimensions, where the parser cannot otherwise determine the dimension of an element. Element ElementName Dimension. ElementName ElementName Identifier A level reference is either a name, or a name qualified with a dimension reference: LevelRef. LevelName Dimension . LevelName LevelName Identifier An attribute name is just a name AttributeName Identifier Query Types HQL allows four different query types Query: Cell Query Element Query ElementPlusAttributesQuery AttributeQuery Cell Queries Cell Query returns the cells specified by a cells list. A single query can consist of multiple cell specifications. Each cell query specification defines a tuple domain. CellQuery SELECT TupleDomain TupleDomain Tuple (TupleList) TupleList Tuple TupleList, Tuple Note that the list of tuples is enclosed in parentheses, that is, parentheses are optional when there is one tuple, but are required when there is more than one. Tuple: A tuple is a .vertline.--separated list of element selections, enclosed in square brackets: In this version of the preferred embodiment, each element selection within a tuple must be from a different dimension than any of the others. Tuple ›DimensionSelectList! DimensionSelectList ElementsSelectList DimensionSelectList .vertline. ElementsSelectList Element Queries An element query returns a list of elements. ElementQuery SELECT ElementsSelectList ElementsSelectList ElementsSelect ElementsSelectList, ElementsSelect Elements Selection An elements selection is defined by the elements bounding list specification, an optional filtering criteria, and an optional ordering criteria. The elements must all be from the same dimension. The parser must be able to determine the dimension of the first element reference unambiguously, or an error will result. Thereafter, all element references are assumed to be from that dimension. So, in a model with both BillTo and ShipTo dimensions, in the expression ShipTo.Boston, Chicago, New York, it's assumed that Chicago and New York refer to elements in the ShipTo dimension. Should either of them not exist in that dimension, an error would result. ElementsSelect ElementBoundingList Element Where(opt) ElementOrder(opt) If no element survives the ElementWhere filtering specification, an empty list is returned. Elements Bounding List The elements bounding list specifies the set of elements from which a smaller subset is going to be filtered. It can be an element name, a function, an element selection in parentheses, or a level specification. ElementBoundingList Element ElementFunction Dimension (ElementsSelect) LEVEL LevelRef Element functions are as follows ElementFunction: ElementFuncChildren ElementFuncParentsn ElementFuncDescendants ElementFuncAncestorsn ElementFuncLeavesn ElementFuncRootsn ›ElementFuncRelevantChildren-removed for Release 1! ElementFuncChildren: ChildrenOf (LevelNumber(opt) ElementListOrDimension) ElementFuncParents: ParentsOf (LevelNumber(opt) ElementsSelectList) ElementFuncDescendants: DescendantsOf (LevelNumber(opt) ElementListOrDimension) ElementFuncAncestors: AncestorsOf (LevelNumber(opt) ElementsSelectList) ElementFuncLeaves: LeavesOf (ElementListOrDimension) ElementFuncRoots: RootsOf (ElementSelectList) ›ElementFuncRelevantChildren RelevantChildrenOf (ElementListOrDimension, Tuple) LevelNumber: integer, ElementListOrDimension is a non-terminal symbol standing for either a list of elements or a dimension. It will require semantic analysis (there can be either a list of elements or a single dimension name, and these cases cannot be distinguished syntactically, and a single element can be either dimension name or an element name): ElementListOrDimension Dimension ElementsSelectList In this version of the preferred embodiment, all the elements must belong to the same dimension. In this version of the preferred embodiment, a dimension name cannot be combined with an element list. Element Selection Criteria An element selection criteria is either a Boolean expression or a ranking function. Element Where: WHERE ElementWhereExpr WHERE ElementWhereRank Ranking function Analogous to the corresponding SQL function. ElementWhereRank TOP integer BY Tuple BOTTOM integer BY Tuple Semantics Each element from the bounding list is concatenated with Tuple to form a cell address. The array of the values obtained this way is sorted, and the elements that correspond to the <integer>top/bottom values are returned. Null and error elements are never considered for selection. Note that the number of returned elements can be more than <integer> (if there are multiple elements in a list with the same value for the examined cell), the number of returned elements may be less than <integer> (there are not enough elements in a list) and duplicate elements are carried over to the returned list In this preferred embodiment, the tuple cannot contain any element in the queried dimension. In this preferred embodiment, the tuple has to contain exactly one element in each of the dimensions specified in it. Element Selection By Expression This is a logical expression, with elementary factors of the following kinds: cell value comparisons and range attribute value comparisons element name comparisons In this preferred embodiment, it is not possible to compare a cell value with an attribute value. ElementwhereExpr ElementWhereTerm ElementWhereExpr OR ElementWhereTerm Element WhereTerm ElementWhereFactor Element WhereTerm AND Element WhereFactor Element WhereFactor NOT(Opt) ElementWhereTest Element WhereTest ElementWherePrimary (Element hereExpr) ElementWherePrimary Element Where ValueComp ATTRIBUTE ElementWhereAttributeComp Note that since an ElementWhereExpr can be embedded in another ElementWhereExpr, and since both element queries and cell queries are building blocks for a ElementWhereExpr, it is therefore possible to embed a cell query inside an element query, or an element query inside another element query. Semantics: When a tuple is being compared to a number, the cells whose values will be compared to the number are identified by concatenating the tuple with each element in the bounding list. If two tuples are being compared, the actual tuples to be compared are constructed by concatenating each tuple with each element from the bounding list. At least one of the resulting tuples must then evaluate to a single cell for each element from the bounding list. Element Where ValueComp Tuple OpCompare Number Number OpCompare Tuple Tuple OpCompare Tuple Tuple IS NOT(Opt) NULL Tuple IS NOT(Opt) ERROR Tuple IS NOT(Opt) RULEMISSING Tuple IS NOT(Opt) RULECONFLICT Tuple IS NOT(Opt) MATHERROR Tuple IS NOT(Opt) INVALIDREFERENCE Tuple IS NOT(Opt) USERDEFINEDERROR OpCompare <= > >= = <> In this version of the preferred embodiment, the tuple reference in a comparison expression cannot contain anything in the bounding list dimension. Note that if we need to choose the elements for which all the vector components satisfy the condition, this can be achieved by prepending NOT to the negated condition: SELECT ChildrenOf(All Customers) WHERE ›Sales .vertline. "1994" .vertline. ChildrenOf(All Products) !>5000 returns the list of the customers who bought more than $5000 worth of any product in 1994, whereas SELECT ChildrenOf(All Customers) WHERE NOT (›Sales .vertline."1994".vertline.ChildrenOf(All Products)!<=5000) returns the list of the customers who bought more than $5000 worth of every product. Attribute Value Comparisons ElementWhereAttributeComp AttributeRef OpCompare AttributeLiteral AttributeLiteral Op Compare AttributeRef ›AttributeRef LIKE RegularExpression--removed for R1! ›AttributeRef IN (AttributeLiteralList)--removedfor R1! AttributeRef LevelName.AttributeName UPPER (LevelName.AttributeName) LOWER (LevelName.AttributeName) UPPER and LOWER are used in WHERE and ORDER BY clauses to enable case-insensitive attribute sorts and comparisons. Otherwise sorts and comparisons are case-sensitive. AttributeLiteral Number String Date NULL Two attributes cannot be compared to each other. In this version of the preferred embodiment, only one level may be specified in a where clause. All elements that are not part of that level are rejected. Element Ordering Elements can be ordered in the following ways: by the cell values and/or attribute values by element name according to their order in the Elements Bounding List ElementOrder ORDER BY ElementOrderByNameCellOrAttribute OrderDirection(opt) ElementOrderByNameCellOrAttribute ELEMENTNAME Tuple ATTRIBUTE AttributeRef OrderDirection ASCENDING DESCENDING The elements can be ordered either in ascending or descending order. The default order is ASCENDING. If there is no sorting specification, then the order is determined by the order of the elements in the bounding list. Semantics: The specified tuple must have a single element in each specified dimension. The bounding dimension can not be specified. Element-Attribute Queries An element attribute query returns a list of elements and one or more attribute(s) for each. ElementPlusAttributeQuery SELECT ElementsSelect WITH ATTRIBUTES AttributeNameList AttrOrder(opt) AttributeNameList LevelName.AttributeName AttributeNameList, LevelName.AttributeName AttrOrder ORDER BY AttributeRejList OrderDirection(opt) AttributeRefList AttributeRef AttributeRefList, AttributeRef Elements from the element select list which do not have the specified attributes will be filtered out of the returned list (as opposed to return a NULL value for the attribute(s)). Attribute Queries An attribute query returns a list of unique attribute values. AttributeQuery SELECT DISTINCT ATTRIBUTE Attribute FROM ElementsSelect AttrOrdered(opt) Note that elements in the ElementsSelect list which do not have the specified attribute will be filtered out of the results. Attribute: LevelRef. AttributeName AttrOrdered ATTRIBUTE ORDER OrderDirection In this version of the preferred embodiment, the AttributeRef can only refer to the Attribute that is being selected. In this version of the preferred embodiment, the LevelRef in AttributeQueries must contain the dimension. Other features of the DOLAP system include an Interactive Hyperstructure Query Language facility, which enables the user to submit queries against a model and view the results without using a worksheet. It is an effective way of issuing queriesby entering the textual form of the query instead of dragging and dropping elements, as would be done building worksheets. The Distributed OLAP system 10 thus provides the kind of computer on-line analytical processing and modeling system that can utilize large relational data bases and at the same time offer large-scale modeling. System 10 requires less administrative attention to maintain, supports many interactive users and allows easy insertion of hypothetical values to produce "what-if" analysis. Control is distributed to the end-users, rather than being centrally controlled by an IT department. This end-user control has been accomplished by providing a system in which models can be easily and rapidly constructed by end users who need not be computer programmers. System 10 provides an HQL language that can be used to query these models which have been constructed in accordance with rule sets establishing the domains in which rules apply. Hierarchies of priorities are maintained among user-entered values and formulas, datamaps and autoformulas. System 10 also provides user interface tools such as the Cell Explorer, which allow users to audit the means by which the value of each cell is calculated. This allows users to understand the workings of the models more fully, and to participate in the building and querying of models in a much more informed manner. All of these components contribute to making control of data modeling truly "distributed" among the users. In addition to the above mentioned examples, various other modifications and alterations of the inventive system 10 may be made without departing from the invention. Accordingly, the above disclosure is not to be considered as limiting and the appended claims are to be interpreted as encompassing the true spirit and the entire scope of the invention. Industrial Applicability The present Distributed On-Line Analytical Processing system 10 is well suited for computer modeling of processes in any number of business applications. The ability to plan for contingencies can be crucial to the survival of a business in an increasingly complex world. As competition from foreign competitors grows, the number of variables affecting a company's performance has grown greatly. The ability to make predictions based on complex combinations of variables can have tremendous applications in many industries. It is this handling of complex variables that the present invention 10 is designed to facilitate by forming multidimensional computer models 50. The present invention 10 calculates cell values "on the fly" in response to queries, and thus does not require the massive loading and pre-calculation of the entire data cube with accompanying large storage requirements, as in MOLAP. The present invention 10 is easy to administer, can support models 50 with very large dimensions 54, and can also suppor | ||||||