Aggregates, source control and Monitoring

I have been fortunate enough to have some time to do some housekeeping on the OBIEE systems.

Monitoring.

I think it's fair to say that we had very little monitoring in place, and we knew things were bad when users phoned to say that their pages were 'slow'. Now to get a user to phone you takes some doing, usually they'll live with it, so things must get pretty bad before they do. Luckily this is only n our exploratory areas, otherwise people would be questioning just what it is we do.

Source Control

No-one like interrupting their work to perform a manual step, like source control. it is one of those things that somehow gets missed the one time you really need it. I've been looking at ways to automate this, behind the scenes, totally hands off using SVN (Subversion)

Aggregates 

Need I say more. Level heirarchies and aggregates go hand in hand. If you can provide the least number of rows back to satisfy your answers report, it will run a lot faster that running an aggregate operation over raw data.

Expect a couple of posts over the coming days detailing just what I've been doing.

Explaining OBIEE to Your Boss!

To explain all the details behind OBIEE would take a long time, probably bore a non-technical person half-way to death, yet still not provide them with any details they can conceptually grasp.

There is tons of documentation - the problem is wading through it all, and all your boss wants is-

"OBIEE in a Nutshell".

The OBIEE server exposes to an end user their business focussed measures and dimensions that can be used to assemble analyses of interest.

Assuming that your boss wants to find out how many cars were sold last month and whether they were new or used would assembling a theoretical query of:

"Calendar.Month", "Car.Condition", "Sales.UnitsSold"

with a filter of last month on "Calendar.Month"

The OBIEE server will now organise how the raw data sources are to be queried. It generates one, or more, queries against the data source(s). retreives the results, applies some post processing, and presents back to the user a result set that can be used to generate not only tables, but graphs, pivot tables and maps.

The OBIEE server has modelled physical raw data, applied calculations and transformations, all interwoven with a consistent security model, ensuring data access is seamless and controlled.

In discoverer or reports and to some extent in publisher you design a query. In OBIEE we no longer hand-craft individual queries, rather we model relationships and the ineractions between heirarchical behaviours. This allows for any possible random query entered by a user in the presentation layer to be transformed from a logical to a physical query, transparent to the user, and the results returned and displayed in the manner requested.