In Our environment we have chosen to drop the whole subject matter
environment and put in a new every time we update.

The reason for doing so is that we don't have that many records 3-4 million
(but we have sevearal dimensions) and we're pulling data out of one
ERP-system with a trustworthy datamodel.

So we wouldn't have any complexity in the transport that isn't necessary.

Now .. however...i'm getting some doubts - what does it mean dimension /
processing / aggretation wise when we drop the dimension table totally with
it's surrogate keys and rebuild the structure from scratch every time.

Is this just a "time used to process cube" problem ? If so I'm not worried -
this doesn't take long ... but do I need to make a total rebuild of
dimensions every time because of the approach above...? I could very well
have a dimension member which have a surrogate key before which now has a
new surrogate key because a member has been added since the last time ?

If it's necessary to make a total processing what impact does this have on
the aggregations ? Are they dropped and created again ? Even those based on
usage based optimization ?

Lots of questions - hope somebody can enlighten me.

\Michael Vardinghus

Full processing of a dimension always drops all aggregates in all cubes that
use that dimension regardless of the type or structure of the dimension.
--
Dave Wickert [MS]
dwickert (AT) online (DOT) microsoft.com
Program Manager
BI Practices Team
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.


"Michael Vardinghus" <michaelvardinghus (AT) hotmail (DOT) com> wrote

Aha....and translated does that mean that a dimension with for instance
surrogate key 10 must not never have this changed for incremental processing
to work ?

Incrementally processing a dimension table where the surrogate keys could
have changed on some of the existing dimensions is a dangerous action, yes ?

\Michael V.


"Dave Wickert [MSFT]" <dwickert (AT) online (DOT) microsoft.com> skrev i en meddelelse
news:ub9HMWLMEHA.1388 (AT) TK2MSFTNGP09 (DOT) phx.gbl...

Changes to keys will result in a new dimension member being added -- not
your intended result. Analysis Services has no way to know that the member
is the same -- as the key has changed (which is the definition of a "key").
If you are changing keys, then you must do a full-process.
--
Dave Wickert [MS]
dwickert (AT) online (DOT) microsoft.com
Program Manager
BI Practices Team
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.


"Michael Vardinghus" <michaelvardinghus (AT) hotmail (DOT) com> wrote

Thanks Dave - thought so.

Just one more thing...

Is there anything wrong with dumping the fact table and regenerating it -
just as long as I don't change the surrogate keys of
the existing dimensions ?

I actually believe this will be the easiest approach instead of redesigning
and getting only new records from host.

If I dump the fact table every time I don't need to make a full proces...the
full process is only when changing dimension structure ?

\Michael V.


"Dave Wickert [MSFT]" <dwickert (AT) online (DOT) microsoft.com> skrev i en meddelelse
news:%238g8hyRMEHA.3012 (AT) tk2msftngp13 (DOT) phx.gbl...