The fifth chapter of session Success with Oracle BI? Typical Error Scenarios and their Solution covers criteria for fast OBIEE project success and outlines our OBIEE repository assessment approach. Please follow our OBIEE project series presenting our process for solving typical OBIEE project issues:
1. OBIEE Project Success - Introduction
2. OBIEE Projects - Suspect Requests
3. OBIEE Projects - Typical Error Scenarios
4. OBIEE Projects - Turn-Around Approach
5. OBIEE Projects - Criteria for Fast Success and Assessment
6. OBIEE Projects - Solution Process
Till now we just described preliminary work. Starting point was to understand client needs and giving a preview of what we will deliver by creating a prototype at low cost. Next goal is to deliver a technically executable Oracle BI system on the existing client data warehouse. Effort is estimated within previous turn-around approach phase. Again, don't focus business requirements at present to avoid failure. Focus is to create a running OBIEE solution observing standard IT success criteria: correctness, stability, performance, fault tolerance and ability for cost-saving modification.
Those criteria having specific characteristics in OBIEE build the basis for Oracle BI repository analysis and further development. A good starting point is a really bad OBIEE repository example:
It really makes no sense to go into detail when seeing such a OBIEE repository implementation. It's not faked and we saw such implementations several times. No criterion mentioned above is met. As OBIEE expert you just need to open it and your validation is finished. The following OBIEE basic criteria are not or only partially observed.
OBIEE Physical Layer
OBIEE physical layer represents data warehouse physical, multidimensional data model. Data model is created by using Aliases. Aliases must be used to apply join definitions, build instances, avoid circle joins and fast replacement of tables. We already saw duplication of database tables instead of using aliases.
Of course data types like DOUBLE or DATETIME should be set to INT and DATE if applicable from a business perspective due to usability reasons. A proper OBIEE physical layer design allows project initialization and start without data warehouse tables.
OBIEE Business Model and Mapping Layer (Logical Layer)
OBIEE logical layer isn't just a copy of physical layer although a lot of developers seem to think it is. You should create a logical, multidimensional model consisting of logical tables perhaps combining several physical sources (which represent one logical entity), figures within facts and dimensional hierarchies (one per dimension). Only a full dimensional hierarchy model enables correct level setting, aggregation, time series, drill and multi star queries.
Define and implement logical separation of dimensions and facts. We know that OBIEE is able to handle attribute fields in logical facts tables (but this functionality shouldn't be used, because several restrictions in design and implementation flexibility come along with it). Coming from a logical perspective a fact table has no attributes and no keys. Logical facts tables hold data to be aggregated. That's it, nothing to be discussed about it! Of course, physical fact tables provide attributes and figure columns.
OBIEE Presentation Layer
Few configuration is normally done in OBIEE presentation layer. But don't forget to set implicit fact column, because there is no direct binding between subject areas and logical tables (the reason why OBIEE is able to perform cross subject area navigation). Dimension and fact ordering should follow optimized usability aspects.
Subject area granularity should follow business usage. Don't create subject areas providing a lot of presentation tables which aren't used together. Utilize multilingualism only if really needed. Field names are set in OBIEE logical layer.
Based on these criteria we start to build a new OBIEE repository (see next and last chapter of OBIEE project series). General topics like security model beyond standard model which isn't sufficient for enterprise usage (access to OBIEE components, subject areas and data), cache management and coding standards aren't yet covered. But they need to after first rollout is done.
Just to let you and what we already saw sometimes: OBIEE server cache isn't purged when server is restarted :-)
Any questions? We provide Oracle BI expert support & coaching regarding all relevant OBIEE topics like architecture, security, configuration, reporting and mobile.