Teresa,

What OLAP platform are you using?

Sure a cube can be based on one table, the fact table, out of which
you can also create your dimensions, but this is not the best way to
go.

There are advantages of having olap cubes based on star-schema; a fact
table & a number of relational tables with the primary & foreign keys
linked.

With the SQL/AS platform you get the benefits of the relational world
& the multidimensional world.
The conformed dimension tables can be used in as many star-schema as
required so you can be sure that the cubes with the same dimension,
really do have the same dimension. This wouldn't be so if you were
doing everything off of fact tables.

There's also the big issue of processing time.
Star-schema allow you to use surrogate keys & the dimension tables are
usually a lot smaller than the fact tables.
Indeed, with SQL/AS you can use snowflake schema without any impact on
query performance if you use MOLAP storage mode (which I strongly
recommend in the vast majority of cases).

So, the simple answer is NO, you don't have to have star schema, but
because of the advantages it gives you, you SHOULD. And, if your OLAP
platform doesn't penalise snowflake schema, use these where
appropriate aswell.

Regards,

John



Teresa Mandelbaum <Teresa (AT) comcast (DOT) com> wrote

Teresa Mandelbaum <Teresa (AT) comcast (DOT) com> wrote

The answer depends on the tool you're planning to use. I have seen one
giant table work with MicroStrategy and it is conceivable that this
might work with other tools. I would never recommend this kind of
schema, though. A star schema is usually the best balance, although
for certain projects a snowflake works better.