Re: Normalization by Composing, not just Decomposing

"Alan" <alan_at_erols.com> wrote in message news:c5gr5c$1dbtj$1_at_ID-114862.news.uni-berlin.de...
>
> In line, again --->>>
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c5f1cm$qo5$1_at_news.netins.net...
> > "Alan" <alan_at_erols.com> wrote in message
> > news:c5euf6$v5g3$1_at_ID-114862.news.uni-berlin.de...
> > > See in line... --->
> > >
> > >
> > > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > > news:c5esfv$hi$1_at_news.netins.net...
> > > > "Alan" <alan_at_erols.com> wrote in message
> > > > news:c5erh9$qt9b$1_at_ID-114862.news.uni-berlin.de...
<snip>
> ----->>> If you have ever created a cube, you would know that creating a
> star schema is not modeling a cube. A star schema is a logical
> representation of the arrangement of the data in a certain way in
entities.
> A cube is but one (albeit most? common) possible physical implementation
of
> the star schema. We may actualy agree in general- we could be getting hung
> up on sematics.

I've created many cubes before, with varying products for implementation but I'm far from an expert in this field and likey using incorrect terminology. I consider cubes an implementation of a star schema, for example, to the extent that I don't have a distrinction between start schema modeling and cube modeling except for user-defined fields (whether stored or virtual) being added in for the cube (measures that are summed, averaged, etc).

But please continue to correct me until I have the terminology correct. I think of doing the data modeling as dimensional modeling or star schema modeling but "designing" (rather than modeling) for the implementation of a cube. So I just used the term "cube modeling" for what gets done with data modeling prior to cube design. Otherwise what would be the distinction between dimension modeling and cube modeling -- couldn't those terms be used interchangably?

>
> >
> > >
> > > >
> > > > > Data is not _modeled_ as "OLAP cubes". Cubes are an
implementation,
> > > > > modelling is analysis and maybe design.
> > > >
> > > > Cubes could be an implementation, but they could also be used to
model
> > the
> > > > data. There is not always a need to take the data, put it into a
> > > relational
> > > > data model and reform it for OLAP -- one could go from requirements
to
> > > OLAP
> > > > data model, right? --dawn
> > >
> > >
> > > ---> Yes and no. How would you model an eight (or more) dimension
cube?
> >
> > With a fact table with an 8-part key pointing to eight dimension tables
> (or
> > something like that).
>
> ----->>> No, that is a star schema, not a cube. If you've ever created a
> pivot table (minus the data to make it a model only) in Excel, you have an
> idea of what a cube model begins to look like. Cognos Powerplay
Transformer
> is a cube modeler and constructor. Google it- I haven't but there is
> probably a white paper with examples.

I haven't seen Cognos Powerplay Transformer, but I'm guessing it is more for cube design, specification and implementation than for the data modeling that might preceed those steps.

Isn't a star schema a data model for cube design and then cube implementation? I have created a pivot table, so I have an idea what cube DESIGN is. I've also created cubes for Data Beacon and other OLAP tools. The "cube modeling" (even if technically called dimension modeling) is by way of star schema, right? The "cube design" extends that model to identify additional attributes based on measures and such.

I'm probably just muddying the waters, but I purposely called it "cube modeling" since it was modeling for the future implementation in a cube, where relational model is for future implementation in a relational structure, for example. I'm open for correction in the concepts as well as the terminology. Thanks. --dawn Received on Tue Apr 13 2004 - 19:37:17 CEST