OracleBIBlog Search

Friday, October 31, 2008

Data Modeling

One of the most important aspects of a BI project is the underlying data warehouse model. This may seem like a no-brainer, right?


In practice, I don't believe the data model is always given the proper time or expertise necessary for a successful implementation. Often, seemingly small flaws or shortcuts in the design of data warehouses or marts can cause much larger problems down the road in terms of functionality, performance, and flexibility. It's imperative that any organization faced with the task of designing their own data warehouse has a project team that understands the importance of a well-planned dimensional model. Changes can always be made, but often at an exponentially higher cost when issues are uncovered late in the game.

Anyone involved with a BI project at any level without a sound understanding of data warehouse modeling techniques should consider doing some research on the topic. One book in particular which I highly recommend is The Data Warehouse Toolkit, 2nd Ed. by Ralph Kimball and Margy Ross. If you're unfamiliar with Ralph Kimball, he's considered a pioneer in the field of data warehousing.


Another highly regarded data warehouse guru is BIll Inmon, who has also written several books on the subject. Most experts in the field strongly side with either Kimball or Inmon. There have been many arguments around whose philosophy on the subject is superior, but of course I'd hate to go picking a fight in my first post by endorsing one over the other here. Maybe we'll hit the topic of their fundamental differences next time. In actuality, their methodologies are very similar and have become more so over time. Anyone interested in learning more about warehouse design should pick up a book on the subject by either or both of them.

An understanding of their techniques and a well designed warehouse won't guarantee a successful implementation, but it's a great step in the right direction. Obviously, we'll never be able to foresee every issue to arise or every request thrown at us, but a strong warehouse design will allow us to deal with both much more easily.

Thursday, October 30, 2008

Basic Branding - Dashboard Header... Continued

In my last Blog… I outlined the steps necessary to update your header image and dashboard links. Here we will update the product link color, welcome bar background color, dashboard name color, the welcome text color.


Whenever you’re making additional color changes to the header, or anywhere else in the software, keep your company color palette in mind. Pull colors from the company logo or an already header image whenever possible. So without further ado… we begin:

1. Identify a desired color and HEX color code for the welcome bar. The welcome bar is the area directly under the dashboard header image and sits behind the page tabs. This color should complement the existing header image.

2. The welcome bar has two color settings… so first open the file “PortalContent.css” and find the entry “TabTable”. Replace the existing “background-color“ HEX code with the one you identified in step 1.

3. Now open the file “PortalBanner.css” and find the entry “PortalBottomTable”. Replace the existing background-color HEX code just like step 2.

4. To change the dashboard name text color, open the file “PortalBanner.css” and find the entry “PortalName”. Replace the HEX code for “color” with one of your choice.

5. Within the file “PortalBanner.css”, do the same thing for the entry “WelcomeTextCell” to change the color of the welcome message.

6. To update the product links, find the following entries within the file “PortalBanner.css”:

a. .DashBarProductCell A,
.DashBarProductCell A:visited,
.DashBarProductCell A:link

b. .DashBarActiveProductCell A,
.DashBarActiveProductCell A:visited,
.DashBarActiveProductCell A:link

c. .DashBarActionCell A,
.DashBarActionCell A:visited,
.DashBarActionCell A:link

d. .DashBarProductCell A:hover,
.DashBarActiveProductCell A:hover,
.DashBarActionCell A:hover,
.DashBarAlertCell A:hover

e. DashBarSep

7. For each of these entries, with the exception of “DashBarSep”, you will need to add an attribute named “color” between the “{…}”. It should look like the following with “XXXXXX” being your desired HEX color code.
color: #XXXXXX;

…for entries with the color attribute already existing, simply replace the HEX code.

8. Refresh your browser to see the changes… make adjustments if needed.


You are now one step further to achieving a completely customized OBIEE. A completely branded style would include customized colors and images for:

  • each page tab
  • welcome text
  • product links
  • section colors
  • table and pivot table colors
  • chart colors
  • ...and the list goes on and on.


If you really feel ambitious… you can do the same to the 'Answers' and 'Delivers' areas of the software. Realistically, it isn’t feasible for a do-it-yourself-er to spend the time to identify each individual setting and redesign every detail. It would probably take months… or even years just to find everything.

Some consulting firms who implement OBIEE will do a certain level of branding, if requested. BI Consulting Group advertises a service specific to branding called IDENTITY. They have even developed a tool that pinpoints and links to each of the 20+ CSS files where the bulk of these changes are made.

Check back for future updates where I’ll cover steps on customizing other areas of OBIEE.

Tuesday, October 21, 2008

Basic Branding - Dashboard Header

There’s a lot of talk… and confusion... surrounding the topic of branding OBIEE. There obviously isn’t much in regards to documentation as Oracle doesn’t make it a priority to show companies how to erase the Oracle name from their own product. But since I don’t really care about any of that… I’ll share some of what I know.

I’m going to outline a few simple steps you can use to change your OBIEE dashboard header. Keep in mind that this is just one of many steps required to achieve a completely branded environment. The following is a step by step guide designed to get you started:



1. Open the image file bg_header.jpg using an image editing software like Photoshop, or Fireworks. In 10.1.3.3, the location is within \OracleBI\web\app\res\s_oracle10\b_mozilla_4.

2. Modify the image as desired, but be sure to maintain the image size. I also recommend using a similar layout as the original image, as the dashboard links tend to get lost if the logo or background image is too busy. You can also crop screenshots from your company website to capture certain designs or themes.

3. Save or export this file with the same name (bg_header.jpg). Save a copy of the orginial file under a different name to revert back to if needed.

4. Depending on the color of you new header, you may need to change the color of the dashboard links located at the top center of the header. Using the Image editing software, identify the HEX code for your desired color. (white = FFFFFF, Black = 000000)

5. Open the file PortalBanner.css, and find the following entries:

  • PortalLink:visited
  • PortalLink:hover
  • PortalLink:link
  • PortalLink:active
  • CurrentPortal:link/visited/hover


6. Each of these 5 entries will have an attribute listed under names “color”. Each entry is displayed depending on the link status (visited, hover, current…etc.). The default color is the same for each situation, but you can play with these setting if you want. All you need to do is insert your new color code in place of the existing one.

7. Refresh your browser to see the changes… make adjustments if needed.


You have now completed the most basic tasks needed to brand your version of OBIEE. A completely branded style would include customized colors and images for:

  • each page tab
  • welcome text
  • product links
  • section colors
  • table and pivot table colors
  • chart colors
  • ...and the list goes on and on.


If you really feel ambitious… you can do the same to the 'Answers' and 'Delivers' areas of the software. Realistically, it isn’t feasible for a do-it-yourself-er to spend the time to identify each individual setting and redesign every detail. It would probably take months… or even years just to find everything.

Some consulting firms who implement OBIEE will do a certain level of branding, if requested. BI Consulting Group advertises a service specific to branding called IDENTITY. They have even developed a tool that pinpoints and links to each of the 20+ CSS files where the bulk of these changes are made.

Check back for future updates where I’ll cover steps on customizing other areas of OBIEE.

Thursday, October 16, 2008

Performance Testing

I recently picked up a book titled "Troubleshooting Oracle Performance", which covers methods for tuning SQL and the Oracle DB versions 9iR2 through 11gR1. I have only read a few chapters to this point, but it appears to contain some useful information. One interesting point it makes in these early chapters is that many IT projects (BI implementations included) fail to define specific performance requirements (or SLA's) in addition to the functional requirements. In some instances, performance does not ever become an issue after implementation, but far too often, performance is not adequately tested during the test phases, and performance issues are not encountered until the application is already in production. This point is easy to ignore (until it occurs in production and it's too late), but poor performance can have the same damaging effect as functional defects on the overall user adoption of an application, and therefore performance testing should be given equal consideration as functional testing - this point is just something to think about which bares repeating every now and then.

Wednesday, October 8, 2008

The Six Guiding Principles of Dashboard Design

Most of the best practices standards we’ve provided, once learned, can be quickly implemented on each new dashboard created. Others will take some practice, but all have been proven in production implementations, each of which have received overwhelming user acceptance. Our advice is to avoid the approach of “getting something out the door” and then going back later to apply best practices; instead, we recommend using these standards and best practices from the very start with the first release. The fact is, once you’ve learned the ideas in this document (in particular our section on “Shortcuts, Cheats and Other Tips & Tricks”), you’ll discover that you can build a powerful, flexible, and aesthetically pleasing report in the same time it takes to build a clumsy, static, low-functionality report.

There are six main Tenets of good Dashboard Design best practices and are as follows:

I. Provide insight, not reports.
When a key user drops off a stack of Excel spreadsheets in response to your request for “requirements”, take the time to understand what results they are trying to derive from that content. Understand what they search for, what they mark up with a yellow highlighter, and what they look at next after discovering an exception. With the best practices that follow, you’ll discover that you can offer multiple ways of providing insight from the same content packed into one Excel spreadsheet (which offered no insight, just data); and that you’ll be able to compact multiple Excel spreadsheets into a single, flexible report module that can fit into the upper left hand corner of a dashboard. Column selectors, view selectors, and bubble charts are not complex. If you think they are, see Tenet #3.

II. Protect your real estate and eliminate the white space.
Unlike printed reports where you can get away with saying “the answer is on page 42”, the same is not true for online dashboards where you will most likely be restricted to what you can fit into an 1024 x 768 pixel screen (or 1024 x 2304 if your dashboard is three pages long). If your users can’t derive insight in the first few seconds of looking at a dashboard, the design could use improvement. If your dashboard has large patches of white space, it will look incomplete to the users and you are wasting space. If you believe that it’s impossible to fit meaningful content into 1024 x 2304 pixels, go check out popular Internet portals like MyYahoo, Google, or MSN.

III. Trust your users will get it.
Most users in today’s business world are familiar with browsing the web and the typical controls used to shop, bank, research, and consume information. Controls like dropdowns, buttons, checkboxes, and text fields are all used on popular sites throughout the Internet – and on OBIEE, too! Trust your users. If you’ve followed rules #1 and #2, your users are going to get it.

IV. Merge business skills into your IT skills.
In order to create the insightful reports we discussed in Tenet #1, report designers need to know more than what the business users are asking for on a report. A highly successful BI project will have designers who know the business side well and can develop new reports and enhance existing ones without explicit instruction from the business users. In Business Intelligence, we need to move away from simply asking what the user wants the report to look like and what data they want in the database. We need to move toward understanding the business processes and determining what data and reports will bring the insight the users need. Once you’ve gotten to know the processes driving the reports, you can make suggestions to the users on what they need to be successful. Most of your users have no idea what kind of reports Oracle BI is capable of producing when utilized to its full potential. With a time spent getting to better know the business, you’ll be able to deliver powerful, insightful reports the users hadn’t considered or didn’t even know were possible.

V. Design your dashboard (and insight) in Oracle BI itself using an iterative methodology.
Dashboard design requires multiple iterations to be successful. Business users often don’t know or realize what they want until they can see something they like or something they recognize needs to be changed. It’s important that you have a plan in place during the build process that allows for several levels of refinement. This plan should include a sound strategy for capturing and documenting user input, prioritizing the changes, and determining the complexity. Careful planning of this process will ensure that all iterations run smoothly and add as much value as possible.

VI. Be prepared to review, refine, and re-do.
After you’ve rolled out your BI project, if the implementation is viewed as a success by the users, you’ll notice that BI slowly becomes more pervasive throughout your organization and is eventually no longer thought of as BI - it’s simply part of the way the business is run. But the business focus can change, processes change, needs change. A periodic review should be done to asses whether the dashboards are still meeting the needs of the business as well as when they were first deployed. Refinement may be needed to evolve the dashboards with the business, and sometimes even more dramatic re-do’s are necessary.

Tuesday, October 7, 2008

Cache Basics

Part of any OBIEE Implementation should be spent defining the proper caching strategy specific to a given project. This post is a basic look at what cache means to OBIEE.

WHAT IS CACHE?
Pronounced "cash", it is generally an easily accessible place to store frequently used information. The most recognizable use of cache relates to the manner in which a personal computer utilizes this information. As it relates to PC, there are two basic types of cache: memory caching and disk caching.

Both types follow the same principle of storing recent or frequently used information in a memory buffer. Memory cache uses a portion of static RAM memory. Disk caching uses conventional main memory. When a piece of information is required, the system (or application) first checks the cache to see if the data is there.

The main purpose of cache is to improve performance. Accessing information stored in a memory buffer can be thousands of times faster than accessing a byte on a hard disk.

OBIEE CACHE
Caching as it relates to OBIEE is a bit different, but the same general purpose applies. Rather than utilizing memory buffer to quickly access recent information, OBIEE will access a file containing a stored record set of information rather than spend processing time querying the database upon each request.

When a request, or query, is made for a set of records, OBIEE can store this as cached information in a file to be used later. When a similar request is made for this same information, OBIEE will retrieve this information from the cache rather than spending processing time negotiating with the database. This can greatly improve the performance of the application.

In the OBIEE/Siebel Analytics world, this is referred to this as ‘query cache’. By utilizing query cache, the cost of database processing only needs to be paid for the one time the query is run against the database. Subsequent identical queries will run against the cache.

Monday, October 6, 2008

"Bullet Proof" SSO

The following pieces are a subset of info presented at Oracle OpenWorld's OBI SSO Unconference by Kevin McGinley and myself. The content framework was provided by John Andrzejek of BI Consulting Group.

The full presentation can be found via http://www.biconsultinggroup.com/OOW

Many organizations have enabled SSO (Single Sign-On) with OBI EE; however, not all have taken the appropriate steps to make it "Bullet Proof", aka next to impossible to hack. Until now!

Below is a typical OBI EE login path when SSO is not enabled. This method works well in an intranet environment where personal data is not available to be queried by OBI EE.



Many organizations have taken the step to enable SSO for OBI EE so their users do not have to enter/remember yet another username/password combination. SSO is more secure than the basic OBI EE login but is still susceptable to hackers tricking OBI EE into authorization.


In order to ensure a more robust/secure method of SSO with OBI EE, the following approach should be taken so that a hacker cannot trick OBI EE into thinking the user has been authenticated. This is handle by Step 4 (see pic below) whereby the user clicks on a link in their portal to go to OBIEE and the portal writes a Record to a database table and then the BI Server checks this record to make sure the user has been authenticated.

If the user was not properly authenticated by the Portal then OBI will deny the user access to OBI EE.