El levantamiento de Varsovia a través de la prensa

Using dynamically calculated data values changes the order in which Essbase calculates the values and can have implications for the way you administer a database. See these topics:

• Calculation Order for Dynamic Calculation

• Calculation Order for Dynamically Calculating Two-Pass Members

• Calculation Order for Asymmetric Data Calculation Order for Dynamic Calculation

When Essbase dynamically calculates data values, it calculates the data in an order that is different from the batch database calculation order.

During batch calculations, Essbase calculates the database in the following order:

1. Dimension tagged as accounts

2. Dimension tagged as time

3. Other dense dimensions (in the order they appear in the database outline) 4. Other sparse dimensions (in the order they appear in the database outline) 5. Two-pass calculations

See Defining Calculation Order.

For dynamically calculated values, on retrieval, Essbase calculates the values by calculating the database in the following order:

1. Sparse dimensions

• If the dimension tagged as time is sparse and the database outline uses time series data, Essbase bases the sparse calculation on the time dimension.

• Otherwise, Essbase bases the calculation on the dimension that it normally uses for a batch calculation.

2. Dense dimensions

α.Dimension tagged as accounts, if dense β.Dimension tagged as time, if dense χ.Time series calculations

δ.Remaining dense dimensions ε.Two-pass calculations

φ.^Attributes

If your data retrieval uses attribute members, the last step in the calculation order is the summation of the attributes. However, the use of attribute members in your query causes Essbase to disregard the value of the Time Balance member in the dynamic calculations.

During retrievals that do not use attributes, the value of the Time Balance member is applied to the calculations. The difference in calculation procedure between the use and non-use of attribute members generates different results for any upper level time members that are dynamically calculated.

During retrievals that do not use attributes, these dynamically calculated members are calculated in the last step and, therefore, apply the time balance functionality properly.

However, during retrievals that do use attributes, the summation of the attribute is the last step applied. The difference in calculation order produces two different, predictable results for upper level time members that are dynamically calculated.

Calculation Order for Dynamically Calculating Two-Pass Members Consider the following information to ensure that Essbase produces the required

calculation result when it dynamically calculates data values for members that are tagged as two-pass (see Using Two-Pass Calculation).

If more than one Dynamic Calc or Dynamic Calc and Store dense dimension member is tagged as two-pass, Essbase performs the dynamic calculation in the first pass, and then calculates the two-pass members in the following order:

1. Two-pass members in the accounts dimension, if any exist 2. Two-pass members in the time dimension, if any exist

3. Two-pass members in the remaining dense dimensions in the order in which the dimensions appear in the outline

For example, in the Sample Basic database, assume the following:

• Margin% in the dense Measures dimension (the dimension tagged as accounts) is tagged as both Dynamic Calc and two-pass.

• Variance in the dense Scenario dimension is tagged as both Dynamic Calc and two-pass.

Essbase calculates the accounts dimension member first. So, Essbase calculates Margin%

(from the Measures dimension) and then calculates Variance (from the Scenario dimension).

If Scenario is a sparse dimension, Essbase calculates Variance first, following the regular calculation order for dynamic calculations. Essbase then calculates Margin%. See

Calculation Order for Dynamic Calculation.

This calculation order does not produce the required result because Essbase needs to calculate Margin % -> Variance using the formula on Margin %, and not the formula on Variance. You can avoid this problem by making Scenario a dense dimension. This problem does not occur if the Measures dimension (the accounts dimension) is sparse, because Essbase still calculates Margin% first.

Calculation Order for Asymmetric Data

Because the calculation order used for dynamic calculations differs from the calculation order used for batch database calculations, in some database outlines you may get different calculation results if you tag certain members as Dynamic Calc or Dynamic Calc and Store. These differences happen when Essbase dynamically calculates asymmetric data.

Symmetric data calculations produce the same results no matter which dimension is calculated. Using the following data set:

Table 26. Example of a Symmetric Calculation Time -> Accounts Jan Feb Mar Qtr1

Sales 100 200 300 600

COGS 50 100 150 300

Profit (Sales – COGS) 50 100 150 300

The calculation for Qtr1-> Profit produces the same result whether you calculate along the dimension tagged as time or the dimension tagged as accounts. Calculating along the time dimension, add the values for Jan, Feb, and Mar:

50+100+150=300

Calculating along the accounts dimension, subtract Qtr1 -> COGS from Qtr1 -> Sales:

600–300=300

Asymmetric data calculations calculate differently along different dimensions. Using the following data set:

Table 27. Example of an Asymmetric Calculation

Market -> Accounts New York Florida Connecticut East

UnitsSold 10 20 20 50

Price 5 5 5 15

Sales (Price * UnitsSold) 50 100 100 250

The calculation for East -> Sales produces the correct result when you calculate along the Market dimension, but produces an incorrect result when you calculate along the

accounts dimension. Calculating along the Market dimension, adding the values for New York, Florida, and Connecticut produces the correct results:

50+100+100=250

Calculating along the accounts dimension, multiplying the value East -> Price by the value East -> UnitsSold produces incorrect results:

15*50=750

In the following outline, East is a sparse dimension, and Accounts is a dense dimension:

If East and Sales are tagged as Dynamic Calc, Essbase calculates a different result than it does if East and Sales are not tagged as Dynamic Calc.

If East and Sales are not Dynamic Calc members, Essbase produces the correct result by calculating the:

1. Dense Accounts dimension—calculating the values for UnitsSold, Price, and Sales for New York, Florida, and Connecticut

2. Sparse East dimension—aggregating the calculated values for UnitsSold, Price, and Sales for New York, Florida, and Connecticut to obtain the Sales values for East

If East and Sales are Dynamic Calc members, Essbase produces an incorrect result by calculating the:

1. Sparse East dimension—aggregating the values for UnitsSold, Price, and Sales for New York, Florida, and Connecticut to obtain the values for East

2. Values for East -> Sales—taking the aggregated values in the East data blocks and performing a formula calculation with these values to obtain the value for Sales

To avoid this problem and ensure that you obtain the required results, do not tag the Sales member as Dynamic Calc or Dynamic Calc and Store.