cube partitions strategy

Hi,
I have a product dimension with the following hierarchy:
Category->Brand->Type->...->UPC
There are 10 category items in the hierarchy. In every update, we will add some new products under 1 or 2 categories, which will cause rebuilding the whole cube, which takes very long time.
Can I partition the cube along the category level so that only the affected partition needs to be rebuild in each update?
or what's better partition strategy here?
Thanks for your attention.
That's probably what I would do, cut the partition the along categories
so only affected category will be reprocessed, then create a virtual
cube on top so from users' point of view, there's one cube.
Or you can incrementally update your dimension but it's more complicated
because you have to be careful about the members and calculated members
to avoid double count.
Eric
yongliyang wrote:

> Hi,
> I have a product dimension with the following hierarchy:
> Category->Brand->Type->...->UPC
> There are 10 category items in the hierarchy. In every update, we will add some new products under 1 or 2 categories, which will cause rebuilding the whole cube, which takes very long time.
> Can I partition the cube along the category level so that only the affected partition needs to be rebuild in each update?
> or what's better partition strategy here?
> Thanks for your attention.
Eric Li
SQL DBA
MCDBA

cube partitions strategy

Hi,
I have a product dimension with the following hierarchy:
Category->Brand->Type->...->UPC
There are 10 category items in the hierarchy. In every update, we will add
some new products under 1 or 2 categories, which will cause rebuilding the w
hole cube, which takes very long time.
Can I partition the cube along the category level so that only the affected
partition needs to be rebuild in each update?
or what's better partition strategy here?
Thanks for your attention.That's probably what I would do, cut the partition the along categories
so only affected category will be reprocessed, then create a virtual
cube on top so from users' point of view, there's one cube.
Or you can incrementally update your dimension but it's more complicated
because you have to be careful about the members and calculated members
to avoid double count.
Eric
yongliyang wrote:

> Hi,
> I have a product dimension with the following hierarchy:
> Category->Brand->Type->...->UPC
> There are 10 category items in the hierarchy. In every update, we will ad
d some new products under 1 or 2 categories, which will cause rebuilding the
whole cube, which takes very long time.
> Can I partition the cube along the category level so that only the affecte
d partition needs to be rebuild in each update?
> or what's better partition strategy here?
> Thanks for your attention.
Eric Li
SQL DBA
MCDBA

Cube History

I am trying to build a cube to monitor the sales performance. My measure is the sale amount. My dimensions include 1) Time 2) Sale hierarchy (salesman, sales office, region), and 3) Product Line. The problem I have is that when the salesman move from one office to another, the sales occured before this movement should continue to be credited to the old office. Only sales happen after the movement should be credited to the new office.
How should I implement the cube to achieve this effectively? We have more that 40,000 sales, about 500 offices, in the company to monitor. So I don't think keeping a copy of the sales hierarchy whenever there is a change is feasible.

Any inputs will be highly appreciated!

Thanks.You will need to Consider creating another dim for salesman.

you apear to need to collect when an employee was at a particular site for a particular sale so you will have to add a location value to each ORDER and not rely on the salesman's location. it has to be tied to the sale itself so the location attribute should be derived for the order

if this is a seldom problem you may want to make your cube holap (part relational and part cube)instead of pure olap and then you can use the drill down feature for a particular sale or set of sales to find the distinction between sites.|||Thank you very much for the information. I can see how that will fix the problem. However, I am not sure how to make the drilldown work using holap as you have suggested. Could you please elaborate it a bit about your last paragraph? Thanks. Sorry, I am new in the DWH field...|||check out those topics in BOL for analysis services
i will try to reply later