Tag Archives: Obiee
OBIEE11g Aggregate At
One of the new feature of 11g is the AGGREGATE AT function. It uses the hierarchical level to pin the the aggregate. Problem is you can’t select a hierarchy level in the formula editor, so you have to some old school typing:
Example:
Only month 1 to 6 are selected.
Just like the BY statement you can do multiple levels from different Hierarchies:
Till Next Time
OBIEE11g Golden Rules: Catalog Management
First of al the original inspiration for these “Golden Rules” Series are based on the “20 GOLDEN RULES FOR REPOSITORY DESIGN” from the people at Peak Indicators. Kudos to them.
The series contains:
- RPD-Physical Layer
- RPD-Business Model Layer
- RPD-Presentation Layer
- Report Building
- Dashboard Building
- Catalog Management
The “rules” is this article are somewhat in random order
This is always a “work in progress” and please feel free to make any suggestions!
Catalog management
- use a transport folder.
Don’t allow all developers to place everything in all shared folders. Have them place it first in “transport” folder. Assign a “librarian” for the shared folder who will check everything and place it in the correct shared folder.
- Add Metadata to the folders:
This makes them better searchable.
- Add structure to the portal:
There are a number of different ways that a portal could be structure to improve efficiency to business users. For instance:
- Reports could be stored by subject area, such as 'finance', 'sales', 'supply chain'
- Reports could be stored in a 'daily', 'weekly', 'monthly' directory structure depending on how often they have been designed to be refreshed.
- Reports could be stored by perspective:
- Financial — Groups objectives, initiatives, and KPIs that relate to or support the monetary or economic health and development of your organization.
- Customer — Groups objectives, initiatives, and KPIs that pertain to or support your client base.
- Internal Process — Groups objectives, initiatives, and KPIs that categorize and support your corporate internal policies and procedures.
- Learning and Growth — Groups objectives, initiatives, and KPIs that relate to or support employee training and advancement.
- A combination of the above.
Till Next Time
OBIEE11g Golden Rules: Dashboard Building
First of al the original inspiration for these “Golden Rules” Series are based on the “20 GOLDEN RULES FOR REPOSITORY DESIGN” from the people at Peak Indicators. Kudos to them. I just added my own observations.
The series contains:
- RPD-Physical Layer
- RPD-Business Model Layer
- RPD-Presentation Layer
- Report Building
- Dashboard Building
- Catalog management
The “rules” is this article are somewhat in random order
This is really a work in progress, will be updated soon! (Bit pressed for Time 
)
Dashboard Design
- Don’t crowd the dashboard
Divide your report over several pages! Check why a user really needs 25 pages…..
- Avoid scrolling
Remember that your developers screen is often bigger then the user screen
- Check for screen size
If the user has only a 1024 * 768, then make your own resolution the same!
- Check for mobile
- Animation
- Colours
Before you start using non standard colours have a look a some colour theory: http://en.wikipedia.org/wiki/Color, not every colour combination does well…..
This is always a “work in progress” and please feel free to make any suggestions!
Till Next Time!
OBIEE11g Golden Rules: Report Building
First of al the original inspiration for these “Golden Rules” Series are based on the “20 GOLDEN RULES FOR REPOSITORY DESIGN” from the people at Peak Indicators. Kudos to them.
The series contains:
- RPD-Physical Layer
- RPD-Business Model Layer
- RPD-Presentation Layer
- Report Building
- Dashboard Building
- Catalog Management
The “rules” is this article are somewhat in random order.
- First column: TIME/CALENDAR
The first column you select for your report should always a column from your time or calendar dimension. Time is often the most consistent aggregation splitter. And most database use partitioning along a time-line.
- Dimension Order:
Try to maintain the same order of the dimension across all reports build on a single presentation layer. That way the use of aggregate tables and or query rewrite can be optimally provisioned.
- Move Complex Logic to the rpd:
If you have made a nice “fancy” formula which you probably need to use in a couple of reports, consider moving it to the rpd. That way you only have to maintain it in one place.
- Less is more 1!
If the user is only interested in the “bad” records, then only show hem/her the “bad” records. To make the user scroll trough hundreds of records looking for the ones you flagged with conditional formatting isn’t very efficient.
- Less is more 2!
If a report generates more then a hundred records, changes are big that the user is going to do “download to excel”. Check with the user if he needs the report in this form. Consider using different deliver methods (agents / Bip).
- Less is more 3!
If on opening the report the user already has to scroll or navigate to other pages try opening the report on a “higher” level.
- Avoid multidimensionality on graphs:
If the human eye and brain need to pick up more then 1 dimension on graph it’s easily fooled.
- Check graph for “lost” data
2011 Paid amount is not visible…..
- Make sure the description is always entered:
A good description must be readable for a “noob”.See: http://obiee101.blogspot.com/2011/09/obiee-mandatory-description-field.html
- Give the report a sell by date!
Go back to the user every 6 to 9 months to see if the report still is required in it’s current version.
This is always a “work in progress” and please feel free to make any suggestions!
Till Next Time
OBIEE11g Golden Rules: RPD-Presentation Layer
First of al the original inspiration for these “Golden Rules” Series are based on the “20 GOLDEN RULES FOR REPOSITORY DESIGN” from the people at Peak Indicators. Kudos to them.
The series contains:
- RPD-Physical Layer
- RPD-Business Model Layer
- RPD-Presentation Layer
- Report Building
- Dashboard Building
The “rules” is this article are somewhat in random order
This is always a “work in progress” and please feel free to make any suggestions!
Presentation Layer
- Common dimensionWhen you have multiple Subject Areas, list the common dimensions in the same order across all the Subject Areas
- Time dimension first:
Since the time/calendar dimension is often the main aggregator make it the first in your presentation layer list.
- No prefixes:
Presentation Table names within each Subject Area must not begin with “Dim – “ or “Fact –“ or “Fact Compound –“. So remove these prefixes if they are present after creating the Subject Area by dragging Logical Tables directly from the Business Model.
- Identify your facts:
The Presentation Table containing your facts should be listed right at the bottom, and the Presentation Table name should contain words like “Measures” or “Facts”
- Ensure logical relationship:
There should be absolutely no possibility whatsoever of a user selecting objects from a Subject Area that have no logical relationship. So, if there are any objects within the same Subject Area that cannot co-exist in the same report, then your Subject Area design is incorrect!
- Split over multiple subject area:
Within OBIEE11g report can be build using multiple presentation layers based on the same business layer:
Consider splitting your presentation layer in “sub” areas.
- Dimension Column Order:
Try to have the column in the same order as your hierarchy: Year > Quarter > Month > Week > Date or Business Line > Brand > Product
- Special characters:
Special HTML characters {< > / } should be avoided in the object names. Not ever browser can render them correctly.
- Metadata dictionary
Have a well maintained metadata dictionary in place:
Remember in OBIEE11G you have to redeploy the metadata dictionary after each RPD deployment
Till Next Time
