Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Normalization by Composing, not just Decomposing

Re: Normalization by Composing, not just Decomposing

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Tue, 13 Apr 2004 15:45:05 -0500
Message-ID: <c5hjgv$8qm$1@news.netins.net>


This terminology is just peachy -- I'll try to stick to it better. Dimensional modeling --> Star Schema design (whether or not it is for a relational database) --> Cube specification --> Cube construction.

It seems to me that the dimensional modeling is more like relational modeling than ER modeling (which is more conceptual) but that is not a major point and if I'm wrong on that small point, it pains me naught. Thanks. --dawn

"Laconic2" <laconic2_at_comcast.net> wrote in message news:_LednVPTGP1loOHdRVn-vg_at_comcast.com...
> The terminology, by Kimball, refers to dimensional modeling. I would put
> dimensional modeling on a par with ER modeling. It's abstract enough so
> that it's not particularly tuned to any implementation.
>
> A star schema is a dimensional model mapped into tables. This makes it
easy
> to imlpement in something like Oracle or DB2.
>
> A cube is a dimensional model mapped into some kind of multidimensional
> database system. Cognos powerplay is one example.
>
> You can realize a dimensional model by building a cube, just as you can
> realize an ER model by building a database.
>
> However, it may be better to do the modeling first, then the building,
> rather than the other way around, especially for large projects. But,
at
> first, we tend to do things backward. We learn how to program before we
> learn how to design programs, and we learn ho to design programs before
we
> learn how to analyze requirements. Funny the way we think, huh?
>
>
Received on Tue Apr 13 2004 - 15:45:05 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US