Jedox In-Memory DB uses Data-Driven Engine (DDE) architecture. DDEs do not interpret model metadata such as dimensions or rules directly. Instead, a calculation planner translates this metadata into an executable calculation plan.
Calculation planner
The calculation planner is a component that analyzes user queries and OLAP metadata and generates a calculation plan. Typical queries include Excel PALO.DATA, PALO.DATAC, PALO.DATAV formulas, DFILTER functions, and Jedox Views. The planner also evaluates OLAP metadata such as dimensions, cubes, and rules.
The calculation plan is a hierarchical graph of objects (nodes) that are later instantiated by the DDE to process source data stored in data cubes in a uniform way. Each node has a simple specific function but can transform a large amount of data effectively. For optimal performance, it is important that the amount of data flowing between these nodes is not extremely large (effect of data sparsity).
While building the plan, the calculation planner does some optimization to reduce DDE workload. For example, it replaces a node doing the addition of two constants and replaces it with another constant or replaces aggregation of one billion constant rule-calculated cells with an aggregation of a single constant using multiplication. It also analyzes conditions of IF expressions and, in the that case a constant condition is used, the calculation planner uses only true or false expressions as an IF result.
Below is an example of a calculation plan for two rules:
['EUR'] = ['LC'] * PALO.DATA("","XRATE","LC","EUR",!'Date')['Revenue'] = ['Price'] * ['Units']
Performance factors
Processing performance of a calculation plan depends mainly on two factors.
Plan Complexity
Plan complexity refers to the number of plan nodes. It depends on:
-
The type of query (single cell, whole cube, cell row, or multidimensional slice)
-
The number of rules and consolidations involved in query evaluation
-
The level of sub-query fragmentation caused by recursion, complex IF expressions, and PALO.DATA formulas using mapping
Amount of Data Flow Between Plan Nodes
The volume of data flowing between nodes depends on:
-
Primary data loaded into cubes
-
The types of plan nodes generated, which produce secondary data
Amount of processed data – primary and secondary
Primary data are values loaded into data cubes using Integrator cube load processes or entered manually, for example during planning.
Secondary data are values produced by plan nodes during calculation. The volume of secondary data can exceed primary data by several orders of magnitude. This usually depends on structure sizes, such as the number of dimensions and their element counts.
To prevent the creation of excessively large plans, the calculation planner stops generating plans for recursive or chained rules when the current plan reaches 64 nodes.
Value types
The CPU-based DDE implementation operates with the following data types:
- Null
- Numeric
- String
- Errors
Null
Null is usually inexpensive to process. It primarily represents an empty cell. Additionally, null can result from:
-
A consolidated cell with no source data
-
Multiplication or division where one operand is null
-
The rule keyword null
-
A rule comparison that is not true, for example 1 > 2 (which evaluates to null)
Numeric
Primary numeric data originate from base cells or rule literals such as 3.14159, -1, or 0.0. Secondary numeric data are produced by mathematical operations, consolidations, or functions, for example, ['A']+['B'], LEN("Hello")
String
Primary string data originate from base cells or string literals such as Not a Value or "".
Secondary string data comes as a function of results or rule parameter values: CONCATENATE("Hello","World"), !'Year'.
String values are typically used in attribute cubes and rights cubes. String values produced by rules are not cached in Jedox In-Memory DB. This can negatively impact performance when reports using such values are refreshed repeatedly or when Integrator jobs repeatedly extract these values.
Errors
Error values usually come from rule functions when they are called with invalid parameters. Errors typically occur when using invalid element names in recursive rules of PALO.DATA functions.
Updated March 9, 2026