Re: In an RDBMS, what does "Data" mean?

"Laconic2" <laconic2_at_comcast.net> wrote in message news:_P2dnRnUErzLz1LdRVn-hg_at_comcast.com...
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:canb6q$rab$1_at_news.netins.net...
>
>
> > Is the star join a relational concept? I heard someone suggest that
> > fact-dimension tables with star schema is bad design, but I forget the
> > rationale for that and they seem to be very effective.
>
> As near as I can make out, a "star join" is yet another join algorithm,
> that is added to the ones previously implemented.
>
> Earlier join algorithms include the "loop join" and the "merge join". I
> could describe these in more detail, but you may already know them. They
> all acheive the same result: a join. They differ in performance, and
> different ones are better in different cases. A smart optimizer picks the
> best algorithm given the available information.

Yes, I do have plenty of star join experience (with SQL-DBMS's and with OLAP "cubes" in various tools)

> A star schema is not a relational concept as such. A star schema is a
> projection of the multidimensional model onto databases like Oracle, DB2,
> etc. that I still refer to as "relational DBMSes", except in this forum,
> where I will be scolded by the keepers of the faith if I do.

I've switched from RDBMS to SQL-DBMS for that reason. I think TRDBMS is the same as RDBMS.

> In order to implement a successful star schema, you have to unlearn most
of
> what you learned in normalization catechism.
> I would have said that would be fun for you, except that you don't
unlearn
> 1NF.

Yes, interesting, eh? It makes you think that 1NF is decidedly a different animal. But since I've done stars(-ish) in Pick as well, I can say with certainty that 1NF is not required.

> Is it bad design? It depends. For certain types of uses, it is far more
> useful than a fully normalized relational design.
> Especially reporting, warehousing, and OLAP. Like almost everything in
> life, sometimes it's a good idea, sometimes it's a bad idea.

There are OLTP (online transaction processing) designs that can double handily for OLAP (online analytical processing). I'd tell you what they are, but I'm trying to trim back my use of the P word. There are good reasons to rehost data into some other format, but if all of the data you need are in a single OLTP system and you don't need a frozen point in time, then it is such a shame that so many people feel a need to pull their data out of their SQL-DBMS's and/or reshape it just so they can get information back out (reporting), don't you think?

>
> But I wouldn't recommend that you run off and learn star schema
immediately,
> although it might be useful if you could incorporate that into some of the
> SQL you teach in college. What I would recommend, for what it's worth,
is
> that you learn a little MDDB and OLAP, if you haven't already. Then, I
> think you would find it quite easy to back your way into star schema.

Sorry to mislead you, I'm well-versed in the ways of the stars -- more so than I am with other relational joins in SQL-DBMS's.

>
> It's just a blend of MDDB concepts with the relational and SQL concepts
you
> already know.

Maybe the relational complaint is about implementing fact-dimension strategies in MOLAP or other non-RDBMS products. I thought I had heard someone state that designing star schemas was both unnecessary and outside of relational modeling. I'll check Date's book later to see what he says.

cheers! --dawn Received on Tue Jun 15 2004 - 22:09:37 CEST