Oracle Usable Apps | Applications User Experience Simplicity, mobility, extensibility
   
 
Customer Role: How User Experience Research Is Conducted
 
Answer Objects
   
   
 
 
Queries Design
Print this Page
 
Basic Principles Return to Top

Formatting of new reports and views must be in harmony with the existing reports and dashboard content.

Keep these principles in mind:

Maintain optimum number of columns required in report definition; remove all extra columns that do not have an identified purpose in the report.

Continue all aggregations at the report level, and not in views, unless specifically required.

Continue all column formatting at the report level, and not in views, unless specifically required.

Here is a dashboard description example:

Column Properties Return to Top

Set column properties for every column in the request:

  • Style Font Size: 9
  • Style Font Style: Regular
  • Style Font Color: White
  • Column Format Column Heading Size: 9
  • Column Format Column Heading Style: Bold
  • Column Format Column Heading Background Color: #E7E7F7
  • Data Format, Override Default Data Format option: Select to preserve the report formatting even when there is a global setting change for that data type

Never save data formats as system-wide defaults for your specific metric or as system-wide defaults for this data type. Always save data formats at the report column level.

 

 
Filters Return to Top
Presaved Filters

Do not use presaved filters in Oracle Business Intelligence Application (OBIA) content.

Hard-Coded Values

Do not include hard-coded values (dates, attributes, values) in report filters, unless the nature of the report requires them.

"Is Prompted" Filters:

  • "Is prompted" filters must be explicit (no via presaved filters) and kept to the minimum required for each report to operate
  • Consider the need for an is-prompted operator filter on each report in the light of the dashboard prompts on which this report depends and on the navigation paths that this report may be part of
Query Validation Return to Top

Extra Columns

Remove or do not include columns in your queries if they are not explicitly required to get the correct results.

Physical SQL Statements:

IMPORTANT: Always validate physical SQL statements generated by each request and validate that the structure of the SQL statements exactly match the functional value.

  • Check for fact and dimensions tables that are being hit
  • Check for filters that are being applied
  • Check for how many distinct SQLs are being generated

To view physical SQL statements:

  • Select Setting, Administration, Manage Sessions
  • In the list of log sessions, find the report that you just ran (use the information column and the time run to recognize your report)
  • Click View Log URL for this query
  • In the log, find the middle section where you can see "Sending query to database named..."

There may be many of these queries. Consider all the available physical SQLs and proceed to the checks previously listed.

Troubleshoot as follows:

  • If you receive the message "No Log Found," your user or session variable log level must be set to at least level 2. Contact your system administrator to have this set
  • If there is no physical SQL, but instead "Cache hit...," the cache is turned on and OBI EE did not need to query the database to return your results

Either purge or disable cache (see administrator) or rerun your report with some filtered value that is likely not stored in cache already.

Query Naming Return to Top

Do not include any special characters in the saved name of your query. In particular, do not use the ampersand (&), semicolon, @, %, $, *, commas, plus, or minus signs.

 
Oracle.com  |  About Oracle  |  Careers  |  Contact Us  |  Legal Notices  |  Terms of Use  |  Your Privacy Rights