Patent Publication Number: US-8527865-B2

Title: Spreadsheet formula translation of server calculation rules

Description:
BACKGROUND 
     A performance management server is a platform that can support business models and business conventions. On top of the platform complex multidimensional business calculations can be defined. Performance management server implementations typically use a classical client/server approach, where calculations are defined, saved, and maintained on the server. 
     Data in the performance management server backend store is usually manipulated using spreadsheet applications. To obtain the latest correct changes of the impending changes from the spreadsheet client, those changes are submitted to performance management server. The performance management server then performs the operations, and subsequently, the spreadsheet application fetches the calculated data from the performance management server which is then displayed in the spreadsheet application as pure data. 
     A drawback of this approach is that if the user changes one of the input cells on the sheet and the input has an impact on a calculated value on the same sheet, the new calculated value needs to be re-calculated on the backend server and re-fetched back to the sheet requiring a poorly performing three-step round-trip operation (write back the new input, calculate the new value, and then re-fetch the new value). This procedure makes the user experience less user friendly and further places a burden on server, thereby reducing server availability and scalability. 
     SUMMARY 
     The following presents a simplified summary in order to provide a basic understanding of some novel embodiments described herein. This summary is not an extensive overview, and it is not intended to identify key/critical elements or to delineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later. 
     The disclosed architecture translates performance management server calculations into spreadsheet application formulas so that the impact of changes can be reflected immediately. Moreover, this technique does not require updating and querying of the performance management server. An algorithm is provided that allows translation of the backend formula (e.g., MDX—multidimensional expressions) directly into the spreadsheet application such that the impact on calculated values by an input change can be reflected instantaneously in the sheet. The algorithm considers dependency determination, formula translation, and data retrieval queries. 
     To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of the various ways in which the principles disclosed herein can be practiced, all aspects and equivalents of which are intended to be within the scope of the claimed subject matter. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a computer-implemented system for handling data. 
         FIG. 2  illustrates a more detailed exemplary system for handling data via formulae translation of server calculation rules. 
         FIG. 3  illustrates a general representation for formulae translation of calculation rules of a server-side data cube to sheets of client-side spreadsheet applications. 
         FIG. 4  illustrates a computer-implemented method of handling data. 
         FIG. 5  illustrates a method of determining which cells on the sheet will have a formula. 
         FIG. 6  illustrates a method of determining full dependency. 
         FIG. 7  illustrates a method of formula translation and the processing of data retrieval queries. 
         FIG. 8  illustrates a method of runtime processing. 
         FIG. 9  illustrates a block diagram of a computing system operable to execute formula translation in accordance with the disclosed architecture. 
         FIG. 10  illustrates a schematic block diagram of an exemplary computing environment for formula translation. 
     
    
    
     DETAILED DESCRIPTION 
     The disclosed architecture includes one or more algorithms for translating server calculations into client application formulas. The architecture determines dependencies, performs formulae translation, and processes data retrieval queries using the translated formulae. 
     This technique immediately addresses problems such as scalability and local cube issues. Scalability issues can be encumbered with frequent server trips and multiple sessions of “what if” queries. Consequently, the server can be severely burdened when the number of users is large. Offline solutions can rely on a local cube. The local cube deployment has many issues such as external bugs, large downloaded data, incomplete formulas, etc. Translating formula (e.g., MDX—multidimensional expressions) directly to the client application (e.g., spreadsheet documents) can eliminate most of the needs associated with a local cube. 
     Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the novel embodiments can be practiced without these specific details. In other instances, well known structures and devices are shown in block diagram form in order to facilitate a description thereof. The intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the claimed subject matter. 
       FIG. 1  illustrates a computer-implemented system  100  for handling data. The system  100  includes a translation component  102  of a server  104  for translating server calculation rules  106  into formulae  108  compatible with a client application  110 . The system  100  can also include an insertion component  112  at the server  104  for inserting the formulae  108  into the client application  110  in association with application objects  114 , the formulae  108  processed for client-side calculations. 
     The server  104  can be a performance management server, the client application  110  can be a spreadsheet application, and the formulae  108  are associated with the objects  114 , which are cells of the spreadsheet application. The formulae facilitate calculation of dynamic data changes in the client application. 
       FIG. 2  illustrates a more detailed exemplary system  200  for handling data via formulae translation of server calculation rules. The system  200  includes the server  104  and associated components ( 102  and  112 ), but further includes a dependency component  202  and object component  204 . The dependency component  202  finds dependent objects (e.g., cells) in the client application. This is accomplished in part by the dependency component  202  generating a dependency graph of objects/members dependent on input objects/members (e.g., objects  114 ) of the client application  110 . The object component  204  computes which of the application objects  114  is mapped to a formula translated from the calculation rules  106 . 
     In a more specific implementation, the translation component  102  translates the server calculation rules  106  into formulae compatible with a client application, which is a spreadsheet application. In this environment, the dependency component  202  finds dependent cells in the spreadsheet application based on a dependency graph of cells dependent on input cells. The object component  204  computes which of the application cells is mapped to a formula. The insertion component  112  inserts the formulae into the spreadsheet application in association with application cells for client-side calculations. The dependency component  202  reduces the spreadsheet to pure data cells a query for which can be performed as a batch query, and the input cells that map to data cube cells of the server  104 . The dependency component  202  analyzes dependencies of MDX formulae of the server  104  and finds dimension level dependencies by transitive closure. The object component  204  groups the input cells of the spreadsheet into a set of disjoint regions, finds a combined set of dependent target cells based on the regions, and finds target cells of the spreadsheet based on the combined set. Other functionality and operations will now be described in greater detail. 
       FIG. 3  illustrates a general representation  300  for formulae translation of calculation rules of a server-side data cube  302  to sheets of client-side spreadsheet applications  304 . Rather than implementing a spreadsheet calculation engine on the server-side, the formulae are translated server-side and uploaded to the client-side. The translated formulae can be applied to cells of sheets in a first spreadsheet application  306  and/or a second spreadsheet application  308 . Thus, the computing load is moved from the server-side to the client-side. Calculations can be much faster in the client than on the server, since round-trip queries to the server for data are reduced. 
     The disclosed translation architecture allows the backend server formulae translated directly onto the client application so impact to any calculated values by an input change can be reflected instantaneously on the application document (e.g., sheet). The architecture a solution to the handling of data required for the calculation but that is not yet present on the sheet. The brute-force approach of including all data required for a calculation on the sheet is impractical because of the potentially huge volume of data. For example, 2007=2006*110% for every account, entity, product, etc. This simple expression represents a huge number of cell dependencies. Additionally, aggregations by the cube  302  are to be reflected on the sheet, making the formula translation problem more complicated. 
     Difficulties of MDX-to-sheet translation can include the following. Straightforward cell-to-cell translation does not work because this translation cannot handle calculations that require data not on the sheet. For example, consider Revenue=price 1 *volume 1 +price 2 *volume 2 . Price 1  and volume 1  are not on the sheet. Another difficulty is handling inter-dependencies between different calculations. For example, Revenue=price 1 *volume 1 +price 2 *volume 2 , where volume 1 =volume 3 *110%. Volume 3  is on the sheet but the rest of the cells are not on the sheet. Yet another difficulty involves the handling of aggregations. For example, consider that the Total (revenue for all entities)=(account.revenue, entity.all). The sheet contains only the account dimension and a single entity. 
     Solutions to these difficulties include understanding what objects (cells) are to be variables and what objects (cells) are constants. In other words, when fixing a set of input cells, find the cells that are dependent on this set. Even if the dependencies are known, this information is to be utilized to transform the formulas to a reduced form. 
     The following description is in the context of formulae translation for spreadsheet applications. However, it is to be understood that the formulae translation architecture is suitable for applications that associate formulae to document objects to calculate values for the objects. 
     A goal of dependency analysis is to find what other cells on the sheet are dependent of the input, given a set of input cells. As previously stated, the brute-force cell level dependency analysis is impractical because the huge number of cells involved. The dependency analysis reduces cell level dependencies into dimension member dependencies. 
     Single step dependency can be analyzed according to two methods: forward and backward. With respect to forward dependency analysis, given a cell C find all cells that can affect C. With respect to backward dependency analysis, given a cell C find all cells that can be affected by C. Affected cells are called target cells, and cells that can affect other cells are called source cells. Forward dependency analysis is intuitive in that the relationship between target cell and source cell given in MDX is in the desired format. For example, This=time.currentMember.lag(−1)+sum(entity.currentMember.children). However, it is less efficient to perform forward analysis when the dependencies are restricted to the sheet. Backward dependency analysis is less intuitive from the MDX point of view; however, backward dependency analysis is more efficient due to starting with a much smaller set of input cells. The backward dependency analysis approach is employed. 
     The disclosed approach keeps cell level data dependency explicitly so the dynamic calculation of data change is fast compared to prior approaches (e.g., perform blank re-calculation on demand). By extending formulae translation to the server side realtime collaborative planning, budgeting and forecasting can be provided. The architecture also solves how to handle data required for the calculation but that is not yet present on the sheet. 
     Continuing with the dependency analysis, a cell of a sheet of a spreadsheet application is called an input cell if the cell is intended to be used for user input; otherwise, non-input cells are called display cells. This description pertains to cells that map to cells in the server cube. A cell c 1  is called dependent on another cell c 2  if changing the value of c 2  affects the value of c 1  via formulas or aggregations defined in the cube. 
     Accordingly, the architecture finds a way to determine what display calls are dependent on the input cells. For each display cell that is dependent on any of the input cells, the display cell is calculated by a spreadsheet formula (derived from the backend MDX formulas and aggregations). The remaining cells can be treated as pure data as far as this particular sheet is concerned (though the backend cube may still have formulas defined on these cells). This reduction drastically reduces the number of data brought to the client side for calculation purposes. This is because as long as a calculation is not dependent on the input cells, the calculation can be reduced to a single constant. Other types of reductions are described hereinbelow as well. 
     If a cell c 1 =(d 11 , d 12 , d 13  . . . ) is dependent on c 2 =(d 21 , d 22 , d 23  . . . ) for some dimension members d 12 , d 13 , d 22 , d 23  then it is said that dimension member d 11  is dependent on dimension member d 21 . The same definition can be used to define dimension member dependency on other dimensions. In general, a set of dimension member dependencies does not imply a cell level dependency, and a cell level dependency does not imply a set of dimension member dependencies; however, since generally, MDX calculations do not allow cross-dimensional correlation (with a possible exception of generate( ) or ToString( ) type of constructs, which are very rare), MDX calculations for cell level dependency and a set of dimension member dependencies are equivalent, and one can derive one from the other. 
     This observation allows the reduction of the cell level dependence issue to a set of dimension member level dependency issues. Because of this reduction, the terms “cell” and “member” (similarly, “cell set” and “member set”) are used interchangeably herein the context of dependency analysis. 
     Cell and dimension dependency via a single step. A cell c 1  is dependent on a cell c 2  via a single step (and similarly a dimension member m 1  is dependent on another dimension member m 2  via a single step) if c 1  is calculated directly from c 2  by at least one MDX formula in the cube, or c 1  is an aggregation involving c 2 . 
     To analyze dependencies for MDX formulas, the common form of such formulas is examined. MDX calculations can be expressed as, 
                                            Current tuple = f(v(tuple 1), v(tuple 2),..., ng1(tuple set 1),            ng2(tuple set 2),..., h1(member 1), h2(member 2),...,            I1(member set 1), I2(member set 2),... )                        
where v(tuple) is the value of the tuple; ng( ) is one of the numeric aggregation functions such as SUM( ), AVG( ), COUNT( ), etc.; h( ) are numeric functions such as member.level; I( ) are numeric functions such as COUNT(member set); and, ƒ( ) is a numeric arithmetic function of its arguments, such as (a+b*c). This description considers tuple set/member set functions SUM( ), AVG( ) and COUNT( ).
 
     Each tuple, tuple set, member, and member set in the above expression is called a factor. A factor is called a 1-1 factor if it is a tuple or a member. A factor is called a 1-n factor if it is a tuple set or member set. 
     For each 1-1 factor, there is a 1-1 mapping between each dimension coordinate of the current tuple and the corresponding dimension coordinate of the factor. For an 1-n factor there is an 1-n mapping between each dimension coordinate of the current tuple and the corresponding dimension coordinates of the tuple sets or member sets. In a mapping between coordinates of the current tuple and that of a factor in a calculation, the current tuple (or its coordinates) is called the target, and the corresponding coordinate(s) of the factor are called source(s). 
     Let F be a factor. Use F(target)=source, or F(target)=sourceSet, where (target, source) is a tuple or member of a dimension and sourceSet is a tuple set or member set of the dimension, to represent the 1-1 or 1-n mapping. A factor is converted to a numeric value via cell value, numeric member function or numeric member set or tuple set function. In subsequent description the term “factor” is also used to describe either a tuple, member, tuple set, member set, or the associated converted (via functions) numeric values appearing in an MDX formula. 
     Let S 1  be a set of source cells/members in a dimension. Members S 2  are the set of dependent target cells/members. Rule R is an MDX formula. All members S 2  dependent on S 1  via a single rule R (or aggregation) can be calculated by the following algorithmic steps. First, all ancestors of S 1  map to S 2  (denoted S 1 →S 2 ). Second, for each 1-1 factor in rule R, and for each member s in S 1 , use s as a source and find the target dimension member s′ by using an inverse mapping, target=F^-1 (source). Add s′ to S 1 . Third, for each 1-n factor F in rule R and for each s in S 1 , find the set S′={s′| where s is in F(s′)}. Add S′ to S 1 . For example, This=time.currentMember.lag(1)+SUM(currentMember:currentMember.lag(−5)), S 1 ={June}, and S 2 ={Q 2 , February, March, April, May, June} 
     Note that the relationship between S′ and s is a 1-n mapping G which can be derived based on the original mapping F. The derivation of G from F can be pre-calculated on a case-by-case basis. 
     Full dimension level dependencies by transitive closure. Starting from a set of dimension members S the single step described above can be applied repeatedly to find the transitive closure of the set S′. S′ is the set of members that depends on S. When applying the single step repeatedly, if a member s′ is added to S 2  via multiple calculation formulae or aggregations, only one member is added based on a fixed precedence order. 
     As part of dependency analysis, a dependency graph (of all cells/members dependent on the input cells/members) is generated with each edge marked by either a factor of a calculation C or by aggregation edges AG. Here, it is assumed that for each dependent cell/member c, all the incoming edges (edges coming from cells/members that could affect this target) are marked by either a single aggregation or by factors of a single calculation. 
     Internal nodes of the graph are those which have at least one incoming edge (so the internal node is dependent on at least one other cell in the graph). To simplify the description, “graph nodes” refer only to internal nodes. For instance “a node is in the graph” means that the node is an internal node of the graph. 
     Following is a series of flow charts representative of exemplary methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, for example, in the form of a flow chart or flow diagram, are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation. 
       FIG. 4  illustrates a computer-implemented method of handling data. At  400 , calculation rules of a data cube are translated into formulae compatible with a client application. At  402 , the formulae are uploaded into the client application in association with application input cells. The formulae for performing the client-side calculations are based on a query for data from the data cube. 
     The method can further comprise generating a dependency graph of cells dependent on the input cells and assigning the formulae to cells associated with internal nodes of the graph, and trimming the graph using a sheet of the client application so that an internal node is only in the graph if the internal node affects a cell on the sheet, the client application is a spreadsheet application. The method further includes generating the dependency graph of internal nodes and creating hidden cells in a sheet of a client spreadsheet application. 
     The process of translating calculation rules can further comprise computing a single-step dependency by finding target cells that are affected by a source cell, and computing target dimension members of a source member using an inverse mapping between the source member and the target member. 
     The method can further comprise querying the data cube for data, processing pure data cells as a group in a single query, and analyzing a portion of the data cube based on a sum of dimension sizes. The method further comprises reducing the data from the data cube by finding display cells dependent on input cells and treating remaining cells as pure data cells. 
       FIG. 5  illustrates a method of determining which cells on the sheet will have a formula. At  500 , input cells are grouped to a set of disjoint regions (e.g., rectangular). At  502 , the dependent target member set is computed for each region and for each dimension. At  504 , the union of the all target sets is computed to create a set of combined targets of all the input cells. At  506 , the combined target set is intersected with the cells of the sheet to obtain all the target cells on the sheet. At  508 , for each target cell on the sheet, the appropriate server formula is translated to the sheet. At  510 , the remaining cells are retrieved from the server as pure data. 
       FIG. 6  illustrates a method of determining full dependency. At  600 , a set of input cells is received. At  602 , transitive closure of a single-step algorithm is performed. At  604 , a full member level dependency graph is generated and each edge is properly marked (by aggregation or by some factor of a formula). At  606 , if there are multiple paths to the same node, the ties are broken. At  608 , the graph is trimmed by the sheet so that a node is in the graph only if the node can affect a cell on the sheet. 
       FIG. 7  illustrates a method of formula translation and the processing of data retrieval queries. Two cases to consider include where all edges are labeled by factors from a single formula and the incoming edges are aggregations. 
     If an internal node has all incoming edges labeled by factors of an MDX formula R, then that node receives a translated spreadsheet formula to be installed, derived from MDX formula R. In other words, in the first instance where all edges are labeled by factors from a single formula f, the spreadsheet formula is to be translated from the server formula f. The letter c is used to denote the current cell/member. At  700 , formula translation is initiated. At  702 , the server formula f is expanded into the canonical form so that f=term 1 +term 2 +, . . . , where each term is a product of some factors. At  704 , the terms are grouped into categories for sheet cells and pure data cells based on the factors. The first category contains all terms such that at least one of the factor in the term appears in an incoming edge to the cell/member c. The second category consists of all other terms. 
     At  706 , the algorithm ensures there are cells in the sheet using existing cells and/or hidden cells. For all factors involved in the first category of terms, a cell is desired in the sheet to represent the first category. If the cell is already a cell in the original spreadsheet scope, then nothing is done; but if the cell is not already in, a hidden cell is created for this node. 
     At  708 , a formula is assigned to a cell based on the cell being a tuple/member in the dependency graph. A check is performed to determine if the factor is either a tuple/member or a tuple set/member set. If the factor is tuple/member, then the factor is either in the dependency graph or not in the graph. If the factor is in the graph, then a formula is defined on this cell (using the same algorithm). If the factor is not part of the graph then the factor can be treated as a pure data which can be retrieved directly from the cube via MDX queries. 
     If a factor is a member set or tuple set function then the factor can be considered as a pure data cell if all the incoming edges labeled by that factor originate from cells that are not part of the graph. However, the factor is considered a formula if at least one incoming edge labeled by this factor originates from a graph node. The formula is then defined for this hidden cell. Without loss of generality, the function is assumed to be SUM(variable 1 , variable 2 , . . . , variable n , data 1 , data 2 , . . . , data m ) where variables are cells in the graph and data are cells not in the graph. The formula for this hidden node is then SUM(variable 1 , variable 2 , . . . , variable n )+SUM(data 1 , data 2 , . . . , data m ). Note that the second SUM( ) can be collapsed as a single pure data value v 0 . Let v 1  be the current value of the factor and let v 2  be the current value of SUM(variable 1 , variable 2 , . . . , variables), then v 0 =v 1 −v 2 . 
     At  710 , the data cube is queried for data and the pure data cells processed as group in a single query. For a hidden pure data cell, it is either a cell in the cube directly, or a member, tuple, member set, or tuple set function. For those hidden pure data cells which are cube cells directly, all such cells can be grouped together and retrieved in one MDX query. For other values, one query is issued for each such cell. 
     Assume the terms in the first category are t 1 , t 2 , . . . , t n , the current target cell value from the server is v 1 , and the sum of the terms t 1 , t 2 , . . . t n  with the current input values is v 2 . Then the formula for the target cell is (v 1 −v 2 )+(t 1 +t 2 + . . . +t n ). 
     In the second instance where the incoming edges are all aggregations, the formula is written as f 1 +f 2 + . . . +f n +c, where f 1 , f 2 , . . . f n  represent nodes in the dependency graph and c is a constant to be calculated. Let v 1  be the current value of the target cell and v 2  be the current value of f 1 +f 2 + . . . +f n . Then c=v 1 −v 2 , and therefore, the formula is (v 1 −v 2 )+f 1 +f 2 + . . . +f n . 
     In the above discussion it is assumed that v 2  can be calculated easily. This is indeed the case by using additional hidden spreadsheet cells which calculate t 1 +t 2 + . . . t n  or f 1 +f 2 + . . . f n . 
     Examples of formula translation now include the following. In a first example:
 
Revenue=price1*volume1+price2*volume2;
 
     Price 1  and volume 1  are not on the sheet; 
     The translated formula: Revenue=price 2 *volume 2 +c. 
     In a second example:
 
Revenue=price1*volume1+price2*volume2;
 
Volume=Volume3*110%;
 
     Volume 3  is on the sheet and the rest of the cells are not; 
     The translated formula: Revenue=price 1 *hidden_cell+c; hidden_cell=110%*volume 3 . 
     In a third example:
 
Total revenue for all entities=(account.revenue,entity.all);
 
     Sheet contains only account dimension and a single entity; 
     The translated formula: Total=(account.revenue, On_sheet_entity)+c. 
     With respect to algorithm complexity, there are several complexity measures considered. A first complexity measure considered is the computational complexity of generating the dependency graph. The complexity of the algorithm is directly related to the sum of dimension sizes (rather than size of cell space). Avoiding an algorithm that analyzes the whole cube space (which grows exponentially with dimension growth) is desired. 
     A second complexity measure considered is the formula translation and installing the formulas into the spreadsheet application. All the formula analysis and transformation is directly proportional to the formula size (the number of factors in the expression mainly). The number of formulas to be installed on the sheet depends on the complexity of the sheet. Note that a single server formula usually covers a region of display cells rather than a single cell so the formula translation does not have to be performed cell by cell, but rather formula by formula. Certain hidden cells are created to hold intermediate values and the number of such cells is bounded by the number of factors in each formula multiplied by the number of display cells on the sheet which use formulae. Both of these numbers are reasonably small. 
       FIG. 8  illustrates a method of runtime processing. A third complexity measure considered is the complexity of data retrieval (from the cube). Data is fetched from the cube at sheet loading time. Once the data is fetched from the server the rest of the calculation is self-contained and calculated on the sheet. In general, for each display region calculated by a particular server formula, the following data fetch operations are performed. At  800 , all pure data cells are fetched (this can be done with a single MDX query). At  802 , all pure data member or member set functions are fetched (the number of queries is bounded by the number of such functions in the formula which is usually a small number). At  804 , the collapsed constant data portion in a variable member set function is fetched (this is bounded by the number functions in the formula). At  806 , a single fetch is performed of the collapsed constant portion of the whole formula. 
     Note that the first and second complexity measure above are compile-time complexities, namely, that the work can be done at the sheet and rule design-time. The third complexity measure is a runtime complexity because it incurs every time a new sheet is loaded by an end user. 
     As used in this application, the terms “component” and “system” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. The word “exemplary” may be used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. 
     Referring now to  FIG. 9 , there is illustrated a block diagram of a computing system  900  operable to execute formula translation in accordance with the disclosed architecture. In order to provide additional context for various aspects thereof,  FIG. 9  and the following discussion are intended to provide a brief, general description of a suitable computing system  900  in which the various aspects can be implemented. While the description above is in the general context of computer-executable instructions that may run on one or more computers, those skilled in the art will recognize that a novel embodiment also can be implemented in combination with other program modules and/or as a combination of hardware and software. 
     Generally, program modules include routines, programs, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the inventive methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like, each of which can be operatively coupled to one or more associated devices. 
     The illustrated aspects can also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices. 
     A computer typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer and includes volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media can comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital video disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer. 
     With reference again to  FIG. 9 , the exemplary computing system  900  for implementing various aspects includes a computer  902  having a processing unit  904 , a system memory  906  and a system bus  908 . The system bus  908  provides an interface for system components including, but not limited to, the system memory  906  to the processing unit  904 . The processing unit  904  can be any of various commercially available processors. Dual microprocessors and other multi-processor architectures may also be employed as the processing unit  904 . 
     The system bus  908  can be any of several types of bus structure that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory  906  can include non-volatile memory (NON-VOL)  910  and/or volatile memory  912  (e.g., random access memory (RAM)). A basic input/output system (BIOS) can be stored in the non-volatile memory  910  (e.g., ROM, EPROM, EEPROM, etc.), which BIOS are the basic routines that help to transfer information between elements within the computer  902 , such as during start-up. The volatile memory  912  can also include a high-speed RAM such as static RAM for caching data. 
     The computer  902  further includes an internal hard disk drive (HDD)  914  (e.g., EIDE, SATA), which internal HDD  914  may also be configured for external use in a suitable chassis, a magnetic floppy disk drive (FDD)  916 , (e.g., to read from or write to a removable diskette  918 ) and an optical disk drive  920 , (e.g., reading a CD-ROM disk  922  or, to read from or write to other high capacity optical media such as a DVD). The HDD  914 , FDD  916  and optical disk drive  920  can be connected to the system bus  908  by a HDD interface  924 , an FDD interface  926  and an optical drive interface  928 , respectively. The HDD interface  924  for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. 
     The drives and associated computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For the computer  902 , the drives and media accommodate the storage of any data in a suitable digital format. Although the description of computer-readable media above refers to a HDD, a removable magnetic diskette (e.g., FDD), and a removable optical media such as a CD or DVD, it should be appreciated by those skilled in the art that other types of media which are readable by a computer, such as zip drives, magnetic cassettes, flash memory cards, cartridges, and the like, may also be used in the exemplary operating environment, and further, that any such media may contain computer-executable instructions for performing novel methods of the disclosed architecture. 
     A number of program modules can be stored in the drives and volatile memory  912 , including an operating system  930 , one or more application programs  932 , other program modules  934 , and program data  936 . Where the computer  902  is employed as a server system, the one or more application programs  932 , other program modules  934 , and program data  936  can include the translation component  102 , the server  104 , the calculation rules  106 , formulae  108 , insertion component  112 , dependency component  202 , object component  204 , and data cube  302 , for example. Where the computer  902  is a client system, the one or more application programs  932 , other program modules  934 , and program data  936  can include the client application  110 , the formulae  108 , the objects  114 , the spreadsheet applications  304  and corresponding sheets, for example. 
     All or portions of the operating system, applications, modules, and/or data can also be cached in the volatile memory  912 . It is to be appreciated that the disclosed architecture can be implemented with various commercially available operating systems or combinations of operating systems. 
     A user can enter commands and information into the computer  902  through one or more wire/wireless input devices, for example, a keyboard  938  and a pointing device, such as a mouse  940 . Other input devices (not shown) may include a microphone, an IR remote control, a joystick, a game pad, a stylus pen, touch screen, or the like. These and other input devices are often connected to the processing unit  904  through an input device interface  942  that is coupled to the system bus  908 , but can be connected by other interfaces such as a parallel port, IEEE 1394 serial port, a game port, a USB port, an IR interface, etc. 
     A monitor  944  or other type of display device is also connected to the system bus  908  via an interface, such as a video adaptor  946 . In addition to the monitor  944 , a computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc. 
     The computer  902  may operate in a networked environment using logical connections via wire and/or wireless communications to one or more remote computers, such as a remote computer(s)  948 . The remote computer(s)  948  can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer  902 , although, for purposes of brevity, only a memory/storage device  950  is illustrated. The logical connections depicted include wire/wireless connectivity to a local area network (LAN)  952  and/or larger networks, for example, a wide area network (WAN)  954 . Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communications network, for example, the Internet. 
     When used in a LAN networking environment, the computer  902  is connected to the LAN  952  through a wire and/or wireless communication network interface or adaptor  956 . The adaptor  956  can facilitate wire and/or wireless communications to the LAN  952 , which may also include a wireless access point disposed thereon for communicating with the wireless functionality of the adaptor  956 . 
     When used in a WAN networking environment, the computer  902  can include a modem  958 , or is connected to a communications server on the WAN  954 , or has other means for establishing communications over the WAN  954 , such as by way of the Internet. The modem  958 , which can be internal or external and a wire and/or wireless device, is connected to the system bus  908  via the input device interface  942 . In a networked environment, program modules depicted relative to the computer  902 , or portions thereof, can be stored in the remote memory/storage device  950 . It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used. 
     The computer  902  is operable to communicate with wire and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE 802.11 over-the-air modulation techniques) with, for example, a printer, scanner, desktop and/or portable computer, personal digital assistant (PDA), communications satellite, any piece of equipment or location associated with a wirelessly detectable tag (e.g., a kiosk, news stand, restroom), and telephone. This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.11x (a, b, g, etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wire networks (which use IEEE 802.3-related media and functions). 
     Referring now to  FIG. 10 , there is illustrated a schematic block diagram of an exemplary computing environment  1000  for formula translation. The environment  1000  includes one or more client(s)  1002 . The client(s)  1002  can be hardware and/or software (e.g., threads, processes, computing devices). The client(s)  1002  can house cookie(s) and/or associated contextual information, for example. 
     The environment  1000  also includes one or more server(s)  1004 . The server(s)  1004  can also be hardware and/or software (e.g., threads, processes, computing devices). The servers  1004  can house threads to perform transformations by employing the architecture, for example. One possible communication between a client  1002  and a server  1004  can be in the form of a data packet adapted to be transmitted between two or more computer processes. The data packet may include a cookie and/or associated contextual information, for example. The environment  1000  includes a communication framework  1006  (e.g., a global communication network such as the Internet) that can be employed to facilitate communications between the client(s)  1002  and the server(s)  1004 . 
     Communications can be facilitated via a wire (including optical fiber) and/or wireless technology. The client(s)  1002  are operatively connected to one or more client data store(s)  1008  that can be employed to store information local to the client(s)  1002  (e.g., cookie(s) and/or associated contextual information). Similarly, the server(s)  1004  are operatively connected to one or more server data store(s)  1010  that can be employed to store information local to the servers  1004 . 
     The client(s)  1002  can include the client application  110  for processing the formulae  108  and the objects  114 , the spreadsheet applications  304  and corresponding sheets, for example. The server(s)  1004  can include the translation component  102 , the server  104 , the calculation rules  106 , formulae  108 , insertion component  112 , dependency component  202 , object component  204 , and data cube  302 , for example. 
     What has been described above includes examples of the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and/or methodologies, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.