sign in sign up
<<
Home , Essbase, Oracle Database

Understand Oracle From Relational Perspective

Session ID: 10402

Prepared by:

Qingchen Chen Senior Hyperion Technical Engineer National Renewable Energy Lab Presenter

• Oracle-Certified Professional (OCP) for Oracle 8i and 9i DBA – 15 years working with Oracle and various BI tools. • Oracle Essbase 11 Certified Implementation Specialist – 7 years working with Hyperion Planning and Essbase. • Presenter at RMOUG Training Days Conference 2010 and 2015. Presenter at Collaborate 15. • Senior Hyperion Technical Engineer at NREL.

2 Agenda

• Oracle Essbase History • Basic Essbase Concepts • Essbase cube converted from relational tables • Essbase vs RDMS • Conclusion

3 Essbase

• "Spread Sheet dataBASE", with the "E" being added to make it easier to spell/pronounce. • Created by Arbor software, bought by Hyperion in 1998. • Oracle acquired Hyperion in 2007. Part of Oracle Enterprise Performance Management (EPM) and Business Intelligence (BI) suite.

4 Essbase

• Used to be a simply architecture and used by end users in finance. • Evolved over the years to integrate with different products, such as shared services (security), Active Directory, workspace, Financial Reports, etc. • Now it requires IT maintenance for security, backup and recovery, auditing, etc. • IT vs Finance: Enterprise software vs standalone. • Challenges facing traditional Oracle SQL developers, including understanding Multi dimensionality and no SQL Plus like client.

5 Multi-Dimensional and Essbase • Essbase is the first commercially available multi-dimensional database and the backend database of Planning • Can have more than three dimensions even though commonly referred to as a cube • Think more like a series of sliding scales that resolve to an amount in the measures (account) dimension Basic Essbase Concepts

• Dimension and Multidimensional database:

Leonard: At least I didn't have to invent 26 dimensions just to make the math come out. Sheldon: I didn't have to invent them. They're there. Leonard: In what universe? Sheldon: In all of them. That's the point.

7 Basic Essbase Concepts

Multidimensional Relational Used to show your data in many Shows data in two dimensions dimensions Handles large amounts of numeric Can show any type of data in data (not good for textual data) format Reflects how the business views Model is driven by what data is the data available Stores data in blocks in Essbase Stores data in rows and/or columns

8 Basic Essbase Concepts

• Outlines: – Define the structure of a multidimensional database, including all dimensions, members, aliases, consolidations and mathematical relationships. The structure defined in the outline determines how data is stored in the database. • Hierarchy: – More than a simple group by.

9 Dimension Terminology

• A dimension is based on a tree structure with the following members: – Parent: a member that has a branch below it – Child: a member that has a parent above it – Sibling: child members of the same immediate parent, at the same generation – Descendant: all the members in branches below a parent – Ancestor: all the members in branches above a member

10 Basic Essbase Concepts

• Point of Views (POV): – POV is the combination of members of all of your dimensions. Each unique combination is a cell intersection. Data only exist in cell intersection. • Relationship among dimensions: – Relational tables emphasis on links between tables, Essbase emphasis on hierarchical relationships. – Thinks of Cartesian joins among all dimensions/tables.

11 Basic Essbase Concepts

• Aggregation (Agg) – Data is aggregated from level 0 members to higher level members along the hierarchy • Calculations and Aggregations are based on: – The outline relationships – Formulas and attributes set in the outline – Calculation scripts that are run separately from the outline.

12 Essbase Jargons

• Cube: an Essbase database • POV: Point of View • Agg: Aggregation • EAS: Essbase Administration Services Console • Calc: Calculation Scripts

13 Scott Tiger Schema Tables

14 Essbase outline

Essbase Admin Services Console (EAS)

15 Essbase Outline Dimensions

16 Design Considerations:

– Measure dimension: the main data points we are interested. Sometime it is called Account dimension which includes whole chart of account members. – Company dimension: related to employee, department information. Assume one employee only belongs to one department. Otherwise it can be separated into two dimensions. – Location branch: Alternate hierarchy. All user to data from another perspective. Assume one department only has one location. Otherwise location can be its own dimension. – Period dimension: Month/Period/Year information. Give user timely information. – Job, Manager, Hire date: Attribute dimensions.

17 Design Consideration

– Company dimension: employee name or departmental name as an Alias, similar concept as in SQL. However alias need to be unique for the whole outline. One member can have many alias. – 3 attributes provide additional information about employees. Can be used in retrieval as a filter. Similar to where clause. Or can be used in calculation.

18 Meta Data Load to Essbase

• Manually add members to the outline • Load Rule Dimension Build • Other Tools: ODI, DRM, Essbase Studio, EIS, FDMEE.

19 Load Data to Essbase

• Load Rule (flat file, relational tables) • Smartview data submission • Other Oracle tools: ODI, FDMEE, etc

20 Data Load: Load Rule SQL interface

21 Data Load: Load Rule SQL interface

22 Data Dump from Essbase Cube

Sal Comm 7782 Jan 2450 7839 Jan 5000 7934 Jan 1300 10 Jan 8750 7369 Jan 800 7566 Jan 2975 7788 Jan 3000 7876 Jan 1100 7902 Jan 3000 20 Jan 10875 7499 Jan 1600 300 7521 Jan 1250 500 7654 Jan 1250 1400 7698 Jan 2850 7844 Jan 1500 0 7900 Jan 950 30 Jan 9400 2200 Total_Company Jan 29025 2200 New York Jan 19625 Location Jan 29025 2200

23 Data Dump from Essbase Cube POV Data 7782 Jan Sal 2450 7839 Jan Sal 5000 7934 Jan Sal 1300 10 Jan Sal 8750 7369 Jan Sal 800 7566 Jan Sal 2975 7788 Jan Sal 3000 7876 Jan Sal 1100 7902 Jan Sal 3000 20 Jan Sal 10875 7499 Jan Sal 1600 7499 Jan Comm 300 7521 Jan Sal 1250 7521 Jan Comm 500 7654 Jan Sal 1250 7698 Jan Comm 1400 7698 Jan Sal 2850 7844 Jan Sal 1500 7844 Jan Comm 0 7900 Jan Sal 950 30 Jan Sal 9400 30 Jan Comm 2200 Total_Company Jan Sal 29025 Total_Company Jan Comm 2200 New York Jan Sal 19625 Location Jan Sal 29025 Location Jan Comm 2200

24 Essbase Data Retrieval

• Smartivew: Oracle Smart View for Office (Smart View) provides a common Office interface designed specifically for Oracle's Enterprise Performance Management (EPM) and Business Intelligence (BI). Using Smart View, you can view, import, manipulate, distribute and share data in , Word and PowerPoint interfaces. It is a comprehensive tool for accessing and integrating EPM and BI content from Microsoft Office products. • Other tools: Hyperion Financial Reporting, Dataexport script, OBIEE, etc • Demo

25 Essbase Data Retrieval Hierarchy

26 Essbase Data Retrieval

Pivot

27 Essbase vs RDMS

• Metadata: – Essbase: all members in the outline – RDMS: table/ definitions • Dimension or Table: – Essbase: Dimension – RDMS: Table • Null or #Missing: – Essbase: #Missing, sometime treated as zero. – RDMS: Null

28 Essbase vs RDMS • Hierarchy – Oracle SQL (connect by, analytic function, or many table joins) – Complex query.

– Essbase (built into the outline)

29 Essbase vs RDMS • Pivot – Oracle SQL: Complex

– Essbase : easy to do in Smartview

30 Essbase benefits

• Allow user to be able to zoom in/out of a hierarchy easily. • Allow user to pivot data easily. (Remember how hard to write SQL to pivot data?) • Smartview allows user to get data directly from Excel. • No need to remember how to join tables. • Great for reporting purposes. • Empower user to create complex reports in Excel without IT help.

31 Essbase limitations

• Not very flexible. Need to maintain Metadata consistently. • Do not handle text and date well • Limited script language • Performance tuning is not easy

32 More Advanced Essbase Topics

• BSO and ASO • Dense and Sparse Dimension • Calculation Script • OBIEE

33 BSO

• Block Storage Option • Dense dimension: data occurs often or repeatedly across the intersection of all member combinations. – Time and Accounts are normally dense. – Upper level members normally are tagged Dynamic Calc. No need to aggregate. • Sparse dimension: data occurs only periodically or sparsely across combinations. – Employee, Product, Market, Entity are normally sparse – Upper level members need to be aggregated using calculation scripts. • Use calculation script to aggregate and manipulate data.

34 BSO

35 ASO

• Aggregate Storage Option • No dense/sparse dimension. • Data is automatically aggregated. • Data needs to be inputted at Level 0. • Can have big dimension without impacting performance. • Use MDX to query data.

36 Essbase Calculation Script • It is used to do data aggregations and data manipulations. • Each line ends with a semicolon. – Calc Dim (Measures); – Agg (Company); – FIX (“Jan”).. END FIX;

37 SQL skill for Essbase

• MDX:

• Load Rule SQL interface • Hyperion Planning Repository

38 OBIEE and Essbase

39 Conclusion

• Essbase is a different beast. • Understand dimensionality is the key. • RDMS developers can leverage their skill sets, especially in data integration. • OBIEE will be a place to combine those two products.

40 Resources

• http://www.network54.com/Forum/58296 • http://john-goodwin.blogspot.com/ • http://glennschwartzbergs-essbase- blog.blogspot.com/

41 Q & A

Contact

Qingchen Chen [email protected] Session ID: 10402

42