The purpose of the article is to document best practices to be used in Oracle BI. The article covers:
• Oracle BI Principles
• Repository design best practices
• Dashboards and reports design best practices
• 10g Upgrade considerations
In this very post, we are explaining main principles of Oracle BI. In the subsequent post, we will cover the other respective articles.
Oracle BI Principles
Oracle BI Server is a SQL generator !!
• To see if an OBI implementation is good, first look at the physical SQL queries executed: is it right (provide good results) ? Is it as simple as possible, is it optimized ?
• End-users do not see physical SQLs, so they do not care about it. Very often, developers do not really look at them because it is just something "automatically generated" (until they have big problems). DBAs do not really look at their structure because developers say that it cannot be modified. “This is how the product
works, we cannot change it”
The quality of physical SQL queries is the most important part of Oracle BI. Everything depend on it.
What are the three main objectives of any Oracle BI application ?
Ordered by priority:
Get Correct Results
This looks obvious but very often this objective is not achieved due to errors in RPD configurations. End-users can get wrong results for years without noticing anything. Look at physical SQL queries to identify potential issues (missing or additional filter, an additional table that should not be included…).
Get Results Fast
Often business users do not have clear expectations. They want “acceptable” performance. Most of the time
performance is not the main focus of developers when a project is started. They only pay attention to this objective at the end of the implementation, or when they are in front of a big problem.
It is useless to have a great presentation if each click takes 2 minutes. Performance must be a permanent concern from the beginning of the design of the project until the production roll-out.
Get Results Easily
Navigation, graphs, hierarchies, report format...Everybody (end-users and developers) focus on that part. That's the main cause of failure/big troubles for many projects. Developers should always keep the performance impact in mind when discussing the presentation with business users.
Performance should always be before presentation in term of priority. It is possible to accept sacrifices on
presentation during the design of the project. But when the implementation is over, it is extremely difficult to
explain to users that they have to give up the presentation because of performance issues.
Focus on performance from day 1
Thanks
• Oracle BI Principles
• Repository design best practices
• Dashboards and reports design best practices
• 10g Upgrade considerations
In this very post, we are explaining main principles of Oracle BI. In the subsequent post, we will cover the other respective articles.
Oracle BI Principles
Oracle BI Server is a SQL generator !!
• To see if an OBI implementation is good, first look at the physical SQL queries executed: is it right (provide good results) ? Is it as simple as possible, is it optimized ?
• End-users do not see physical SQLs, so they do not care about it. Very often, developers do not really look at them because it is just something "automatically generated" (until they have big problems). DBAs do not really look at their structure because developers say that it cannot be modified. “This is how the product
works, we cannot change it”
The quality of physical SQL queries is the most important part of Oracle BI. Everything depend on it.
What are the three main objectives of any Oracle BI application ?
Ordered by priority:
1. Get Correct Results.
2. Get Results Fast.
3. Get Results Easily.
Get Correct Results
This looks obvious but very often this objective is not achieved due to errors in RPD configurations. End-users can get wrong results for years without noticing anything. Look at physical SQL queries to identify potential issues (missing or additional filter, an additional table that should not be included…).
Get Results Fast
Often business users do not have clear expectations. They want “acceptable” performance. Most of the time
performance is not the main focus of developers when a project is started. They only pay attention to this objective at the end of the implementation, or when they are in front of a big problem.
It is useless to have a great presentation if each click takes 2 minutes. Performance must be a permanent concern from the beginning of the design of the project until the production roll-out.
Get Results Easily
Navigation, graphs, hierarchies, report format...Everybody (end-users and developers) focus on that part. That's the main cause of failure/big troubles for many projects. Developers should always keep the performance impact in mind when discussing the presentation with business users.
Performance should always be before presentation in term of priority. It is possible to accept sacrifices on
presentation during the design of the project. But when the implementation is over, it is extremely difficult to
explain to users that they have to give up the presentation because of performance issues.
Focus on performance from day 1
Thanks
No comments:
Post a Comment