Žiga Vaupot's Blog

Recently I was working with Oracle Business Intelligence 12c on a project where Hyperion Planning was used as a data source. In previous OBI releases, the usual way to connect to Hyperion Planning was to connect to its Essbase cube. In general this worked fine, but as some of readers might know, Essbase cube usually doesn't contain certain information that is a property of Hyperion Planning application. For example, comments are very important for users of Hyperion Planning, but when you report on Hyperion Planning's Essbase cube, how would you display comments that users enter into planning form? This was theoretically possible, but required a major workaround. To be honest, I haven't done that. But with OBI 12c this is very straight forward. Comments are seen as attributes in OBI's subject area, so it can be included in reports as any other attribute. This particular customer had specific requirement to show commentaries along side with numbers. Since we were t...

In my two previous blog posts I wrote about how to add aggregated tables into you OBI data model and how to use Aggregate Persistence Wizard to manage your aggregates more efficiently . This is the last post in the series of three, in which I will focus on using an MOLAP (Essbase) cube as an aggregate for your base data model. The first step of all before you do any modelling is to import Essbase metadata into BI repository. Once you've done that you should follow standard method of setting the cube in the physical layer of the RPD. For example, define Measure dimension, flatten Measures etc. Once you've finished with these tasks, which are definitely different from the ones when you import and model relational database metadata, then Essbase cube is practically ready to be used. There isn't much changes required in logical and presentation layers. And even when you want to use Essbase "only" as an aggregated store, you would use Essbase basically in the same ...

In my previous post  Using Aggregates and Combining Data Sources in OBIEE  I explained how to add aggregates to physical layer and how to include these in business model. In general that process is quite straightforward, but what if there are many aggregates that have to be brought into your repository. Well, in that case, using Aggregate Persistent Wizard to create aggregates might be better idea. So let's explore this tool that is available in BI Administration Tool. Before running Aggregate Persistence Wizard, you might want to run Global Consistency Check and Model to check if there are any errors or inconsistencies that might affect creation of aggregates. There shouldn't be any. Once you run both tools and check for issues, you ca run Aggregate Persistence Wizard. To start the six-step process, navigate to Tools menu in BI Administration Tool and select Utilities. When Utilities pop-up window opens, select Aggregate Persistence from the list of available utiliti...

Kimball defines "aggregate fact tables as simple numeric rollups of atomic fact table data built solely to accelerate query performance. These aggregate fact tables should be available to the BI layer at the same time as the atomic fact tables so that BI tools smoothly choose the appropriate aggregate level at query time. This process, known as aggregate navigation, must be open so that every report writer, query tool, and BI application harvests the same performance benefits. A properly designed set of aggregates should behave like database indexes, which accelerate query performance but are not encountered directly by the BI applications or business users. Aggregate fact tables contain foreign keys to shrunken conformed dimensions, as well as aggregated facts created by summing measures from more atomic fact tables. Finally, aggregate OLAP cubes with summarized measures are frequently built in the same way as relational aggregates, but the OLAP cubes are meant to be accessed di...