Hi,

I would like to know how dimensions work. Specifically I have data with
Manufacturer and Brand information.

Does it make sense to create 3 dimensions, One with each and then one with
combined.
I have a few different ways to view the data. Does it makes sense to create
a dimension for each posibility or does this make the cube too big?

Yossi

Make one dimension in Analysis Services but snowflake them in the
starschema. Manufacturer will be on the one side and product on the many
side. The product table will be the one that join with the fact table.

If you have one manufacturer and one separate product dimension you create
combinations(in the cube) for all manufacturers and products, even if they
do not exist in the real world.

The businesscase for separate dimensions can be if many manufacturers supply
the same product.

HTH
Thomas Ivarsson

"Yossi" <my (AT) eject (DOT) co.za> wrote

There are both pro and cons with using starschema and/or snowflake. If you
have a snowflake that is OK from the point of Analysis Services. It works
with both structures. If you look at the foodmart demo database you can see
that the product dimension is in a snowflake structure.

I do not understand your second question.

HTH
Thomas Ivarsson


"Yossi Neimann" <yossicms (AT) hotmail (DOT) com> wrote

I think if you use Office Web Component (OWC) for User Interface, it's
possible that you only have 1 dimension for this.
Just make 1 dimension with hierarchy like Manu -> Brand -> Products
When the user want to see Manu they can ommit the Brand level, so it will be
Manu -> Products
When the user want to see Brand they can ommit the Manu level, so it will be
Brand -> Products
But if the User Interface that you use doesn't support it, than the other
way is you make 1 dimension with multiple hierarchy (3 hierarchy in this
case).

I think you should have 2 single-leveled dimensions. 1 for Manu, and 1 for
Brand. When a cube is processed, ALL possible combinations are stored in the
cube's partition (if aggregation is high enough). The drill path Manu->Brand
and Brand->Manu are included!


"Yossi Neimann" <yossicms (AT) hotmail (DOT) com> wrote

As far as snowflaking or using a star schema is concerned, Analysis
Services will work with both. However, if you don't need to query the
relational data, outside of processing the cubes of course, I'd recommend
that you choose a snowflake. The primary reason I'd go with a snowflaked
schema is so that you can create cubes with different levels of granularity.
For example, suppose you have some fact data at the monthly level and some
fact data at the day level. If you snowflake the time dimension in this
case you can build a virtual cube that will allow you to combine the mothly
and day level cubes together. You may not need the ability to add different
levels of fact granularity into your solution at the moment, but it's good
to have an architecure that will support it if the need arises in the
future.

Sean


--
Sean Boon
SQL Server BI Product Unit

**This posting is provided AS IS, with no warranties, and confers no
rights.**
"Yossi" <my (AT) eject (DOT) co.za> wrote

Yossi,
0) I agree with Sean on star vs. snowflake designs
1) on your issue:
a single Dimension with Manu as the top level and Brand as the next
level(call this Product). In Analysis Services define a single named set of
just the Brand Level (call this BrandView). This gives you two effective
dimensions when users access the view:
Product Which Gives them ALL, Manu and Manu -> Brand and
BrandView which gives them ALL, Brand.

"Yossi Neimann" <yossicms (AT) hotmail (DOT) com> wrote