Re: On what OLAP can and what OLAP can't

David Cressey wrote:
> It's clear from the above transcript that you and the data architect were
> talking past each other rather than holding a genuine dialogue. Looking
> back, I can see myself in years gone by being on either side of the
> discussion, at different points in my career.
For a dialogue to happen, there's a need for a common basis. While I did set up OLAP cubes, I thought it obvious that the *Architect* did not measure up the consequences of loosing data integrity at definition level. As all idiots who try compensate such loss of integrity by costly and unreliable filtering processes at applicative level. OLAP layer is not exception.

> I can, if you like, shed some light on what the data architect might have
> been trying to show you. However, I can only surmise that the architect's
> opinions and knowledge were somewhat like my own. They may have been quite
> different. What you might get out of such a discussion in here depends on
> what you are seeking.
He later acknowledged that he had to assume SOME level of correcteness on the raw data extracted from the source databases to be able to go any further. On the other side, he admitted that most data sources returned incorrect results because not normalized. In a word this is a contradictory attitude. Which basically makes OLAP layer nothing but a semi presentation layer on the perspective of the database. The concept of OLAP could be perceived as a concentrator/connector of flexible targeted querying capabilities nothing more nothing less.

> Since the DA isn't here, I can't rephrase what you were trying to
> communicate to the DA for that person. However, it's just vaguely possible
> that the DA had been through the same learning curve you have, and had
> grown to appreciate multidimensional modeling in addition to relational
> model, rather than instead of it.
Quite frankly I don't believe there's actually such thing as a multimensional model. OLAP technologies which I have to maintain on a dayly basis are nothing but a hierarchical hangover.

> If you are seeking to genuinely understand how multidimensional modeling and
> star schema design might be genuinely useful additions to your own set of
> tools and methods, the discussion could go one way. If, on the other hand,
> you are merely looking for validation of your own opinions, and want
> justification for disregarding anything novel (to you) that the data
> architect might have said, then the discussion is likely to go nowhere, as
> many prior discussions in c.d.t. have.
I perfectly know what a star schema is for having built several data warehouses using Analysis Services. Too much ado about nothing.

> Before I invest the time and effort at trying to summarize and explain the
> benefits of star schema design, I want to have some inkling about whether
> it's a waste of time.
Thanks for the intention. The point I was trying to make was not that I did not understand what OLAP is. It was sharing a discussion I supposing not to be uncommon.

> I will comment on a few things above:
>
> First, the term "data architect" makes a great deal of sense to me. The
> terms "data multidimensional architect" or "multidimensional architect"
> sound very odd to me. I would expect any good data architect to have an
> understanding of relational data modeling, data normalization, ER modeling,
> multidimensional modeling, relational database design, star schema design,
> and (why not) object modeling, in their collection of useful tools and
> methods, and to be able to apply any one of them to good advantage, when
> appropriate.
Hey that's what written on his business card...But you now designations are not that important.

> While multidimensional modeling is quite different from relational data
> modeling, it really isn't a case of "either/or" but a case of "both/and".
> Many of the religious debates in this forum are quite sterile in terms of
> comparing different tools and methods and finding different benefits and
> drawbacks to each.

> Second, I think the data architect (DA) chose an unfortunate term when he
> described a star schema as "denormalized". A better choice of words would
> have been "not necessarily normalized (beyond 1NF)". When doing
> multidimensional modeling and star schema design, it is not so much a case
> of normalizing and then denormalizing as it is of following some design
> principles that lead to a less than fully normalized design.
That's a point...

> The multidimensional model has been dismissed as mere bunk by some acclaimed
> professionals. But I can tell you from repeated direct experience that it
> has proven very useful to me in a class of situations. And certainly
> Kimball is quite a respectable authority in this field, in his own right.
> Inmon, on the other hand, bases his discussion of data warehousing
> completely on normalized data as a starting place. I've never had a chance
> to apply Inmon's ideas, so I can't compare them to Kimball's ideas.
I place myself on the perpective of complete system success or failure.  If an OLAP system gets incorrect raw data as a data source and no matter how well designed it could be, It will present incorrect results...

> I will say, however that dismissing either one of them as ignorant and
> unprofessional only shows how little the person doing the dismissing
> actually knows.
Really, somebody who ignores the consequence of not normalizing logical models for insuring integrity and hoping by some kind of miracle that would lead to support some decision support systems through ANY kind of data reorganisation is delluding him/herself...

Thanks for playing devil's advocate...;) Received on Fri Sep 08 2006 - 10:02:07 CEST