More Big Tips Please

Reply from Phil as follows:


Of course Adrian, I've got loads.

How about this one:

When you do a combined request you can't change the column headings in the Edit Column Formula window as any changes you make there aren't saved. However, you can change the column name in the Column Properties \ Column Format window just fine.
(I have better tips than this but I'm just warming up).

Surely someone out there can challenge Phil to tip showdown?

Stars and Snowflakes

Part 2

Continuing on the discussion about OBIEE (Oracle BI EE) structure of the Logical Layer - please read Part 1 before this chapter.

To set the context, The discussion is around your choices in table design in the warehouse and I am only referring to the reporting in OBIEE on the datawarehouse, and your design considerations for Logical Tables, logical Table Sources and Physical Joins in the Physical Layer. Another point to note is that I am not too concerned about the theoretical difference between Snowflakes and Normalised, in the example shown in Part 1 you could call that a Snowflake or a Normalised design. Some have described Snowflakes as semi-normalised stars which is a fair decription, but the important point for the discussion is that there is at least one join between dimensions, which instantly makes it a non-star design, and is on the road to normalisation.

In part three I will look at a mixed model - Logical stars with normalised physical tables.

I do believe the actual dataWarehouse design and ETL routines should follow what you decide in your logical design considerations. Having said that though, I don't think that the whole reporting system can be developed in a linear path, you often have to loop back at each stage when more clarity is found.

And finally, Please join in the discussion by posting your comments.

Now, on with the blog...

From Part 1 some of you may be thinking that I'm advocating that Stars are not always required in the warehouse. Well, I tried to put together a fair case for the use of normalised design as best as I could. Now, lets have a look at the case for a pure star.

Continuing with the Contact example used in part 1, we can redraw the model in a logical and physical pure star.

Running the same report.

And obviously it works, but look at the SQL:

SELECT

T3489."ATTRIB_11" as c1,

sum(T3517."BLAH_VALUE") as c2

from "W_PERSON_DX" T3489,

"W_PERSON_F" T3517

where ( T3489."ROW_WID" = T3517."CONTACT_WID" )

group by T3489."ATTRIB_11"order by 1

So this time the join is direct in the physical layer, and therefore the server does not add in another table to get the answer.
Is this reduction in joins THE main reason why you design a pure star? Or are there other reasons why star = good?

So on the face of it there is no problem with either method. The star method was very efficient in the query, minimising the number of joins. But at what cost to the ETL process? Here, in this example, none because it joined to an existing key, however if you were talking about say, Account Id, then the mapping would have to look it up and add it to the target table. Of course the Star Transformation in the db will struggle with the normalised schema (or will it – answers on a postcard).

But. I cheated. Twice. Firstly, this is a very simple model, with little data in, so design is not vital.
Secondly, what if I want to do this …..

Part 2A

Let's build a hybrid. Surely we can use a star and introduce some level of normalisation and all will be well? Consider the following design.

The above 'star' has all the physical dimension tables in the single dimension logical table.

We have a logical star. With Physical table sources arranged in a physical star, except we have a few ‘spokes’ around some of the physical dimension tables (this is essentially what mosst people would call a Snowflake!). A common use here would be a ‘List of Values’.

Does it work? and is it 'better'?

There are two considerations

1. Errors is Analytics generating SQL
2. Duplication of data.

I'll explore these in part 3.

Quiet Christmas

I had a few emails, texts and calls today from people who are available for work. Good Siebel Analytics / OBIEE consultants who may be having an extended xmas holiday!

If you have a need for someone for short or long term please get in touch and I'll forward their details on.

You may have noticed me being busy on LinkedIn recently. I have managed to build a good network of OBIEE consultants, and even started a group specifically for Oracle Business Intelligence consultants. This should benefit us all when it comes to project requirements.
Go to http://www.linkedin.com/e/gis/43109/526A0219C124 and I'll add you in (I only add in OBI consultants and related workers).

I have also been busy on the Oracle OBIEE forum, reading the issues that people have. It annoys me when someone clearly hasn't read the manual or even tried to find the answer to something before posting a request.

Each day I always check out Venkats postings on his blog. He has a great job - he just gets to play with OBIEE all day and write about the new stuff.

Talking of new stuff, the new functionality in 10.1.3.3.xyz, which allows you to call Oracle functions will be a greta boost for the product. Up until now I have seriously wondered by you need a BLOB in an Analytics but now we get to put pictures from a database in you reports.

I was sceptical about the time series functions, particularly as they were causing some people problems, but I have now converted over completely and so far so good. Let me know what you think.

Have you noticed that when you use the functions editor you now get something more useful when you add the function - it actually now tells you what arguments it requires instead of <>. I tended to copy the contents of the edit box into TextPad but may start using the editor more now.

I notice there are more and more companies that are offering OBIEE and Siebel Analytics consultancy. Those of us that were using the product over 4 years ago are seeing others trying to muscle in. All I can say is How much do you really know?? There are so many stories at conference from clients that say their implementation failed due to the integrator not having the right skills. We ALL need to make sure the product is not undermined by consultants who frankly do not have a clue. If you are in a pitch to a client sell your real experience and don't let beginners run your project.

I am still building the OBIEE information website, if you would like to have a listing just let me know.

That's all for now Folks!

New Version of OBIEE

Version 10.1.3.3.3.1..3.1.1.2..3.1..3. of OBI Enterprise Edition is now released.

It's got some new stuff in.

How exciting!

How good IS good?

I've been interviewing loads of candidates recently (you may have seen my ads on Jobserve and LinkedIn) for Siebel Analytics consultants.


By the way, if you would like to connect on linkedIn (www.linkedin.com) please send an invite to adrian.ward@majendi.com; in the note say you are reading the blog.

Most of the interviewees have stated that they are pretty good at developing Analytics applications. One said that he was an expert and knew all of the components in detail.

So, to test this I ask a few simple questions (see my previous blog for some examples). Before long it becomes obvious that they have over estimated their own ability. This makes for an awkward end to the interview because it's obvious that they have been exposed. So why do they do it? Do people really believe that they know the system like the back of their hand, or is it bluff to try and get past the interview and into the job where they will learn?


Perhaps my questions are too difficult?

Try this one, and see what you think.

Q. What Types of Physical Table are there?

A. There are 4 types of Physical table

- Ordinary
- Alias
- Stored Procedure
- Select

Not really a difficult questions, is it?

But no-one could answer it.

Whilst I’m on the subject of tables, the new OBI EE has a slightly different way of creating Aliases.

You now have to include the Orignial underlying Table in the model (something I always do but found others do not). Right click on the table and select New Object.. Alias.