Session ID:
Prepared by:
Understand Oracle Essbase From Relational Perspective
10402
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 database 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 Oracle Hyperion 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:
7
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.
Basic Essbase Concepts
Multidimensional Relational
Used to show your data in many dimensions
Shows data in two dimensions
Handles large amounts of numeric data (not good for textual data)
Can show any type of data in table format
Reflects how the business views the data
Model is driven by what data is 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
15
Essbase Admin Services Console (EAS)
Essbase Outline
16
Dimensions
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 view 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
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
POV Data
Essbase Data Retrieval
• Smartivew: Oracle Smart View for Office (Smart View) provides a common Microsoft 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 Microsoft Excel, 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
26
Hierarchy
Essbase Data Retrieval
27
Pivot
Essbase vs RDMS
• Metadata: – Essbase: all members in the outline – RDMS: table/column 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