1 / 33

Capitolul 3.2 Proiectarea unei baze de date Essbase Construirea Dimensiunilor

Objectives. Describe data descriptor dimensionsDesign time dimensionsDesign scenario dimensionsDescribe outline calculationsDesign accounts dimensionsCreate member aliases Describe dimension typesCreate period-to-date totalsDescribe Dynamic Calc membersEnhance accounts dimensionsBusiness V

sine
Download Presentation

Capitolul 3.2 Proiectarea unei baze de date Essbase Construirea Dimensiunilor

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. Capitolul 3.2 Proiectarea unei baze de date Essbase – Construirea Dimensiunilor

    2. Objectives Describe data descriptor dimensions Design time dimensions Design scenario dimensions Describe outline calculations Design accounts dimensions Create member aliases Describe dimension types Create period-to-date totals Describe Dynamic Calc members Enhance accounts dimensions Business View Dimensions

    3. Data Descriptor Dimensions Overview In general, data descriptor dimensions Define data in its essentials Are manually developed and maintained Incorporate variances (both value and percentage differences) Are calculation-intensive Are densely populated with data Typical data descriptor dimensions include time, accounts, and scenario dimensions.

    4. Designing Time Dimensions Decisions to make: What is the lowest-level granularity of data Depends on the type of analysis required Can be very summarized (quarters ) or very detailed (15-minute intervals) How many years to track and how to separate them Generic time designs Fiscal year crossover designs

    5. Generic Time Designs The generic time design requires at least two dimensions: A time dimension with generic time periods Discrete years represented in a scenario dimension or in a separate years dimension

    6. Fiscal Year Crossover Designs A fiscal year crossover design requires one of the following: A continuous, single time dimension with year-specific time periods A continuous, single time dimension with duplicate names Only use a fiscal year crossover time design if you need to: Forecast prices or costs for a rolling forecast (where the forecast time horizon crosses over the fiscal year end) Calculate rolling lead or lag calculations that require a single time continuum. Calculate cumulative values over time Only use a fiscal year crossover time design if you need to: Forecast prices or costs for a rolling forecast (where the forecast time horizon crosses over the fiscal year end) Calculate rolling lead or lag calculations that require a single time continuum. Calculate cumulative values over time

    7. Designing Scenario Dimensions Scenarios are the primary tool for variance analysis. They typically take one of two forms: Scenarios that track data sets Scenarios that track processes

    8. Tracking Data Sets Scenarios that track data sets Are typical in financial applications Define the foundation of the planning and control process

    9. Tracking Processes Scenarios that track processes Are typical in forecasting applications Define a single data set Track adjustments by distinct functional groups

    10. Outline Calculations The database outline facilitates calculations two different ways: Hierarchy structure Consolidation operators Shared members Member formulas

    11. Consolidation operators define how child members consolidate to parents. Valid consolidation operators: Addition (+) Subtraction (-) Multiplication (*) Division (/) Percent (%) Exclude from consolidation (~) Never consolidate (^) Consolidation Operators In addition to the structural relationships between members within dimensions, the database outline enables you to define consolidations between the members by setting their consolidation property. You set the consolidation property by assigning on of the consolidation operators: Addition (+), Subtraction (-), Multiplication (*), Division (/), Percent (%), or Ignore (~). By default, when you add a new member to the outline, the member consolidation property is set to the Addition (+) consolidation operator. The consolidation property defines how the member rolls up to its parent. For example, you may want to subtract a member from its sibling, such as subtracting COGS from Sales, to define the proper value for Margin. The Ignore (~) operator identifies the member as exempt from consolidation. For example, Actual, Budget, Variance, and Variance % are tagged as Ignore (~) so that they do not roll up into Scenario. Once your outline is created, you need to look at how the dimensions and members are ordered. Your data consolidates based on the order of dimensions and members in your outline. In addition to the structural relationships between members within dimensions, the database outline enables you to define consolidations between the members by setting their consolidation property. You set the consolidation property by assigning on of the consolidation operators: Addition (+), Subtraction (-), Multiplication (*), Division (/), Percent (%), or Ignore (~). By default, when you add a new member to the outline, the member consolidation property is set to the Addition (+) consolidation operator. The consolidation property defines how the member rolls up to its parent. For example, you may want to subtract a member from its sibling, such as subtracting COGS from Sales, to define the proper value for Margin. The Ignore (~) operator identifies the member as exempt from consolidation. For example, Actual, Budget, Variance, and Variance % are tagged as Ignore (~) so that they do not roll up into Scenario. Once your outline is created, you need to look at how the dimensions and members are ordered. Your data consolidates based on the order of dimensions and members in your outline.

    12. Shared Members Do not store data Create a pointer to a stored member Are always level 0 members Are positioned after (below) the stored member in the outline

    13. Member Formulas Member formulas define calculations in the outline. Calculation script functions return sets of members or data values. Whenever possible, use consolidation operators in the outline to define natural formulas. This is generally more intuitive to end users as they can drill down to see how a member was derived. However, you can define more complex formulas for members. Analytic Services provides a comprehensive set of operators and functions that you can use to construct formula calculations on a database. For instance, you can perform common arithmetic operations or control the flow of formula executions based on the results of conditional tests. Calculation functions include boolean to provide a conditional test, mathematical, statistical, and financial to perform specialized calculations, and so on. In the example shown in the slide, Analytic Services performs the following calculations for each month: The IF statement and @ISMBR function check that the current member on the Year dimension is Jan. This step is necessary because the Opening Inventory value for Jan is an input value. If the current month is not Jan, the @PRIOR function obtains the value for the Ending Inventory for the previous month. This value is then allocated to the Opening Inventory of the current month.Whenever possible, use consolidation operators in the outline to define natural formulas. This is generally more intuitive to end users as they can drill down to see how a member was derived. However, you can define more complex formulas for members. Analytic Services provides a comprehensive set of operators and functions that you can use to construct formula calculations on a database. For instance, you can perform common arithmetic operations or control the flow of formula executions based on the results of conditional tests. Calculation functions include boolean to provide a conditional test, mathematical, statistical, and financial to perform specialized calculations, and so on. In the example shown in the slide, Analytic Services performs the following calculations for each month: The IF statement and @ISMBR function check that the current member on the Year dimension is Jan. This step is necessary because the Opening Inventory value for Jan is an input value. If the current month is not Jan, the @PRIOR function obtains the value for the Ending Inventory for the previous month. This value is then allocated to the Opening Inventory of the current month.

    14. Designing Accounts Dimensions Design choices are based on input data and sample reports. Profit and loss accounts Balance sheet accounts Units, rates, prices, and other assumptions Analysis metrics

    15. Consolidation Order Consolidation order is defined by the order of members in the outline. Essbase calculates data in top-down order. It is important to understand how Analytic Services calculates members with different consolidation operators. When you are using just addition and subtraction operators the order of members in the outline is irrelevant. However, when you use any other operator, you need to consider the member order and its impact on the consolidation. When siblings have different operators, Analytic Services calculates data in top-down order. The following example illustrates a top-down calculation: Sample Roll-up Parent1 Member1 (+) 10 Member2 (+) 20 Member3 (-) 25 Member4 (*) 40 Member5 (%) 50 Member6 (/) 60 Member7 (~) 70 Analytic Services calculates Member1 through Member4 as follows: (((Member1 + Member2) + (-1)Member3) * Member4) = X (((10 + 20) + (-25)) * 40) = 200 If the result from Members 1-4 is X, then Member5 consolidates as follows: (X/Member5) * 100 = Y (200/50) * 100 = 400 If the result of Member5 is Y, then Member6 consolidates as follows: Y/Member6 = Z 400/60 = 66.67 Analytic Services ignores Member7 in the consolidation. It is important to understand how Analytic Services calculates members with different consolidation operators. When you are using just addition and subtraction operators the order of members in the outline is irrelevant. However, when you use any other operator, you need to consider the member order and its impact on the consolidation. When siblings have different operators, Analytic Services calculates data in top-down order. The following example illustrates a top-down calculation: Sample Roll-up Parent1Member1 (+) 10Member2 (+) 20Member3 (-) 25Member4 (*) 40Member5 (%) 50Member6 (/) 60Member7 (~) 70 Analytic Services calculates Member1 through Member4 as follows: (((Member1 + Member2) + (-1)Member3) * Member4) = X(((10 + 20) + (-25)) * 40) = 200 If the result from Members 1-4 is X, then Member5 consolidates as follows: (X/Member5) * 100 = Y(200/50) * 100 = 400 If the result of Member5 is Y, then Member6 consolidates as follows: Y/Member6 = Z400/60 = 66.67 Analytic Services ignores Member7 in the consolidation.

    16. Design Considerations

    17. Creating Accounts Hierarchies

    18. Creating Member Aliases Aliases are Used as reporting names Used for data source name mapping Updated in Member Properties Stored in alias tables Alias tables are Created in Outline Properties Limited to 10 per database Updated separately Displayed one at a time

    19. Dimension Types

    20. Creating Period-to-Date Totals Calculated members Shared member hierarchy Member formula Dynamic Time Series

    21. Creating Period-to-Date Calculated Members Provides hierarchy path expansion in reports Creates more stored members Enables loading to period-to-date totals

    22. Implementing Dynamic Time Series

    23. Dynamic Calc Members Advantages: Reduce batch database calculation time Reduce disk storage usage Reduce database restructure time Reduce time required to perform a backup Understanding Dynamic Calculation Members When you design the overall database calculation, it may be more efficient to calculate some member combinations when you retrieve their data, instead of pre-calculating the member combinations during a batch database calculation. In Analytic Services you specify dynamic calculations on a per-member basis. You can define a member in the database outline as one of two types of a dynamically calculated member: ? Dynamic Calc ? Dynamic Calc and Store Dynamic Calc When a member is set to Dynamic Calc, Analytic Services does not calculate the value for that member until a user requests it. After the user views it, Analytic Services does not store the value for that member. Dynamic Calc and Store Analytic Services calculates the data value for a member that is tagged as Dynamic Calc and Store when you retrieve the data, in the same way as for a Dynamic Calc member. For a Dynamic Calc and Store member, however, Analytic Services stores the data value that is calculated dynamically. Subsequent retrievals of that data value do not require recalculation, unless Analytic Services detects that the value needs recalculating. Understanding Dynamic Calculation Members When you design the overall database calculation, it may be more efficient to calculate some member combinations when you retrieve their data, instead of pre-calculating the member combinations during a batch database calculation. In Analytic Services you specify dynamic calculations on a per-member basis. You can define a member in the database outline as one of two types of a dynamically calculated member: ? Dynamic Calc ? Dynamic Calc and Store Dynamic Calc When a member is set to Dynamic Calc, Analytic Services does not calculate the value for that member until a user requests it. After the user views it, Analytic Services does not store the value for that member. Dynamic Calc and Store Analytic Services calculates the data value for a member that is tagged as Dynamic Calc and Store when you retrieve the data, in the same way as for a Dynamic Calc member. For a Dynamic Calc and Store member, however, Analytic Services stores the data value that is calculated dynamically. Subsequent retrievals of that data value do not require recalculation, unless Analytic Services detects that the value needs recalculating.

    24. Enhancing Accounts Dimensions Time balance accounting Expense reporting

    25. Time Balance Reporting Time balance reporting defines consolidation of members in the accounts dimension across the time dimension. Skip options determine how Essbase treats zero and missing values. Similarly to the Variance reporting expense property, time balance properties apply only to members of the Accounts dimension. Time balance lets you control the consolidation of balance sheet items for different time periods. Essbase enables you to set one of the following values for the Time balance property: None. When a member in the Accounts dimension represents a value that is irrespective of a time period, the corresponding parent in the Time dimension is calculated based on the consolidation and formulas of its children. For example, the Time balance property for the Additions member is set to the default value, None. This tells Essbase to calculate the Qtr1 member in the Time dimension as the sum of its children (Jan, Feb, and Mar). TB First. When a member in the Accounts dimension represents the value at the beginning of the time period and you want to carry this value to the parent in the Time dimension, set the Time balance property of that member to TB First. For example, the Opening Inventory member represents the inventory at the beginning of the time period. If the time period is Qtr1, then Opening Inventory represents the inventory at the beginning of Jan; that is, the Opening Inventory for Qtr1 is the same as the Opening Inventory for Jan. Similarly, Year Opening inventory is equal to Qtr1 Opening inventory. TB Last. When a member in the Accounts dimension represents the value at the end of a time period and you want to carry this value to the parent in the Time dimension, set the Time balance property of that member to TB Last. For example, the Ending inventory represents the inventory at the end of the time period. If the time period is Qtr1, then Ending Inventory represents the inventory at the end of Mar; that is the Ending Inventory for Qtr1 is the same as the Ending Inventory for Mar. Year Total Ending inventory is equal to Qtr 4 Ending inventory. TB Average. When you want that the parent value in the Time dimension to represent the average value of a time period for a member in the Accounts dimension, set the Time balance property of that member to TB Average. Setting Skip Properties If you set the time balance as TB First, TB Last, or TB Average, you must set the skip property to tell Essbase what to do when it encounters missing values or values of 0. The following table describes how each setting determines what Analytic Services does when it encounters a missing or zero value. None: Zeros and missing values are considered when parent values are calculated. This is the default setting. Missing: #MISSING values are excluded when parent values are calculated. Zeros: Zero values are excluded when parent values are calculated. Missing and Zeros: #MISSING values and zero values are excluded when parent values are calculated. Similarly to the Variance reporting expense property, time balance properties apply only to members of the Accounts dimension. Time balance lets you control the consolidation of balance sheet items for different time periods. Essbase enables you to set one of the following values for the Time balance property: None. When a member in the Accounts dimension represents a value that is irrespective of a time period, the corresponding parent in the Time dimension is calculated based on the consolidation and formulas of its children. For example, the Time balance property for the Additions member is set to the default value, None. This tells Essbase to calculate the Qtr1 member in the Time dimension as the sum of its children (Jan, Feb, and Mar). TB First. When a member in the Accounts dimension represents the value at the beginning of the time period and you want to carry this value to the parent in the Time dimension, set the Time balance property of that member to TB First. For example, the Opening Inventory member represents the inventory at the beginning of the time period. If the time period is Qtr1, then Opening Inventory represents the inventory at the beginning of Jan; that is, the Opening Inventory for Qtr1 is the same as the Opening Inventory for Jan. Similarly, Year Opening inventory is equal to Qtr1 Opening inventory. TB Last. When a member in the Accounts dimension represents the value at the end of a time period and you want to carry this value to the parent in the Time dimension, set the Time balance property of that member to TB Last. For example, the Ending inventory represents the inventory at the end of the time period. If the time period is Qtr1, then Ending Inventory represents the inventory at the end of Mar; that is the Ending Inventory for Qtr1 is the same as the Ending Inventory for Mar. Year Total Ending inventory is equal to Qtr 4 Ending inventory. TB Average. When you want that the parent value in the Time dimension to represent the average value of a time period for a member in the Accounts dimension, set the Time balance property of that member to TB Average. Setting Skip Properties If you set the time balance as TB First, TB Last, or TB Average, you must set the skip property to tell Essbase what to do when it encounters missing values or values of 0. The following table describes how each setting determines what Analytic Services does when it encounters a missing or zero value. None: Zeros and missing values are considered when parent values are calculated. This is the default setting. Missing: #MISSING values are excluded when parent values are calculated. Zeros: Zero values are excluded when parent values are calculated. Missing and Zeros: #MISSING values and zero values are excluded when parent values are calculated.

    26. Expense Reporting In applications where revenues and expenses are not loaded with credit and debit balances: Members that represent expense must have the Expense Reporting tag. Essbase provides two variance reporting functions: @VAR(mbrName1, mbrName2) @VARPER(mbrName1, mbrName2) One of the typical analytic requirements is the ability to perform variance reporting on actual versus budget data. When you are budgeting expenses for a time period, you want the actual expenses to be lower then the budget. When actual expenses are greater than budget, the variance is negative. On the other hand, when you are budgeting non-expense items, such as sales, you want the actual sales to come in a higher than the budget. When actual sales are less the budget, the variance is negative. Essbase variance reporting calculation requires that any outline member that represents an expense to the company must have the Expense Reporting tag. For example, Inventory members, Total Expense members, and the COGS member each receive the Expense Reporting tag for variance reporting. You assign the Expensive Reporting tag to a member by setting its Variance reporting expense property to true. The default value of the Variance reporting expense property is false. Note: Expense reporting can only be tagged on members within the Accounts dimension. To perform variance reporting calculation, Essbase provides two functions: @VAR and @VARPER. In the example shown in the slide, Sales is a non-expense member, and the variance reports a negative number. However, COGS is tagged as an expense member, and the variance reports a positive number. Because it is an expense reporting item, the sign is flipped on the variance calculation. The actual formulas used in the relevant outline are as follows: @VAR(Actual, Budget); @VARPER(Actual, Budget); These formulas trigger Essbase to check if a member has the Expense Reporting tag and does a sign flip if it finds the member does. When you use the subtract operator in the member formula, Essbase does not check the Expense Reporting tag for that member.One of the typical analytic requirements is the ability to perform variance reporting on actual versus budget data. When you are budgeting expenses for a time period, you want the actual expenses to be lower then the budget. When actual expenses are greater than budget, the variance is negative. On the other hand, when you are budgeting non-expense items, such as sales, you want the actual sales to come in a higher than the budget. When actual sales are less the budget, the variance is negative. Essbase variance reporting calculation requires that any outline member that represents an expense to the company must have the Expense Reporting tag. For example, Inventory members, Total Expense members, and the COGS member each receive the Expense Reporting tag for variance reporting. You assign the Expensive Reporting tag to a member by setting its Variance reporting expense property to true. The default value of the Variance reporting expense property is false. Note: Expense reporting can only be tagged on members within the Accounts dimension. To perform variance reporting calculation, Essbase provides two functions: @VAR and @VARPER. In the example shown in the slide, Sales is a non-expense member, and the variance reports a negative number. However, COGS is tagged as an expense member, and the variance reports a positive number. Because it is an expense reporting item, the sign is flipped on the variance calculation. The actual formulas used in the relevant outline are as follows: @VAR(Actual, Budget); @VARPER(Actual, Budget); These formulas trigger Essbase to check if a member has the Expense Reporting tag and does a sign flip if it finds the member does. When you use the subtract operator in the member formula, Essbase does not check the Expense Reporting tag for that member.

    27. Optimizing Data Storage Shared data: Label only members Implied shares

    28. Label Only Members Do not store data Group members to ease navigation and reporting Create a pointer to the first child

    29. Implied Shares An implied share is an automatic internal optimization created by Essbase in the following circumstances: A parent has only one child. A parent has only one child that consolidates to the parent. To prevent implied sharing, set the storage property of the parent to Never Share.

    30. Business View Dimensions Overview Business view dimensions Define a specific cut of the data Are developed and maintained through automatic processes Incorporate alternate rollups using shared members Are not calculation-intensive Are sparsely populated with data The choice of business view dimensions is substantially driven by the company’s industry and business practices.

    31. Combining Business Views Consider combining several business views in one hierarchy Consider using attribute dimensions

    32. Planning Dimensions with Label Outlines

    33. Designing Primary Hierarchies

    34. Designing Secondary Hierarchies

More Related