On Apr 17, 1:37*pm, "Jeje" <willg...@hotmail.com> wrote:
> you talk about a change in your factless table, this is NOT a change in the
> dimension.
> in this case you have to reprocess the factless table to make sure that the
> customers parameters are correctly associated to the customers.
>
> because you don't change the dimension himself, there is no need for a full
> process of the sales.
>
> Now... if your parameters dimension is directly attached to your sales fact
> table (or referenced to the fact table), in this scenario you have to
> reprocess your sales history. but with a many many, there is no need for a
> process.
>
> <sergei.shei...@ru.nestle.com> wrote in message
>
> news:188680f1-e710-4b23-bf09-bd33eec38ce3@a23g2000hsc.googlegroups.com...
>
>
>
> > Hello,
>
> > I have a question about use of many-to-many dimensions. There is a
> > huge fact table joined to a dimension, and that dimension has a
> > factless many-to-many table with attributes attached. Question: when
> > attribues of a dimension record which has been used in the fact table
> > in the past change, do you have to re-compile the whole cube?
>
> > As an example, let's say you have a sales fact table and customers
> > dimension. There is a factless many-to-many table called
> > customer_parameters. At one point, one parameter changes for many
> > customers who've had sales in the past (for example, they change from
> > single to married). Do you have to re-compille the whole cube every
> > time such updates take place in a dimension? Is there a way to avoid
> > and/or delay that?
>
> > Thanks!
> > S.- Hide quoted text -
>
> - Show quoted text -
Jeje is right.
I've a concern about your model - when you say that that a parameter
changes for customers who've had sales in the past, are you sure you
want to "lose" the parameters for the past sales? You can also have
both, but depending on your requirement you could choose different
models.
I suggest you to take a look at my paper here:
http://www.sqlbi.eu/manytomany.aspx
Look at the models "Transition Matrix" and "Cross-Time", you might
find some ideas for your models.
Marco Russo
http://www.sqlbi.eu http://sqlblog.com/blogs/marco_russo