Hi All,
I got a question from one of our customers. I would like to share that question with you all.
Which is the best one for BO? Star Schema Or 3rd Normalization form? Why?
All the answers are welcome.
Thanks
Ravi.
______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
Listserv Archives (BOB member since 2002-06-25)
Performance.
I would suggest reading the book:
“The Data Warehouse Toolkit” by Ralph Kimball. He will give you all the arguments that you need.
You never want to run reports of any size on a transactional platform: that is the purpose of relational modeling and that is also the purpose of datawarehousing. This has nothing to do with Business Objects, every reporting tool would require the same thing.
Simon
Listserv Archives (BOB member since 2002-06-25)
Performance, complexity and flexibility.
A reporting/analysis tool like BusObj is about providing an open architecture, user-friendly interface into the user’s data. If you build an interface (such as a universe) over a transactional database, you’ll find yourself writing some pretty tricky SQL, and doing some denormalisation of data at the report end. This takes away the flexibility and user-friendly part of the conversation from the user. I’ve actually had to do this a couple of times, and whilst BusObj can handle it (hey, it can handle anything), it isn’t exactly a preferred option.
Recommend a denormalised database for any reporting tool, regardless of the schema chosen.
Ang.
Listserv Archives (BOB member since 2002-06-25)
Ravi,
PERFORMANCE : You want to limit the number of level of join involved in a query.
The best schema in term of performance is obviously the Pure Star Schema (only one level of dimension around the fact table) regardless the query tool you are using.
It is better from a database level as it guaranty you to have only one level of join around your fact table.
But if you leave Dream World then the Snow Flake Schema (one level of dimension then an additional level of dimension on top of the dimension) is the second best alternative in term of performance. Then you will choose a De-normalised Transactional Database Schema with some duplicate informations so that you won’t need to join the whole set of tables before to build your report. You will choose the degree of de-normalisation that suits to you.
And a standard Fully Normalised Transactional Database Schema last as there may be a huge number of tables that you will need to join before to be able to consolidate to the level you want in your report and end up with a tricky SQL as Angela said.
ANYWAY There isn’t A perfect solution.
It doesn’t exist !!
The nice thing with BusinessObjects is that it gives you the flexibility to choose which model you want to deal with.
Pascal BRENNER - Sydney - Australia
Listserv Archives (BOB member since 2002-06-25)