一般建维表会考虑其变化维等建模技术问题，往往在有特定需求时，会忽略在建模技术上考虑途径，而是临时想出一些办法去处理，造成数据仓库架构不稳定性，难以管理和维护。

那么何为维表动态描述，它的在什么情况下才更有用，怎么用，和临时处理办法有何优势？

动态描述，就是需要经常更新的描述，它不同于变化维，只是更新维记录的某些描述，很多时候是定期更新，但其key健在当前还继续有效，没有变化。

一般在有特殊BI需求的时候，才会有这种应用，普通BI应用，不需要动态的描述。这种特殊应用主要包括事实表里不确定维描述的统计，如日期维里，今天是2008-05-29，对于2008-04-24是今天之前四周的日期，那么2008-04-24该天的last_week_4（4周之前的标志）为"Y"，2008-04-25last_week_4的标志为"N"，但昨天该日期的该标志还是“Y”。该维描述是处理一个到多个事实表的度量需要统计从当前日期起，之前1周到4周任意某周的统计数据。

这里只是一个假定的一个需求，还有很多类似的，甚至更复杂的统计需求可以考虑此法。只有有的更加动态的需求，比如任意输入日期，就要统计该日期之前某些周、某些月、季度等统计数据，那么可以依次逻辑类推，在前端工具使用此算法，或者使用其他临时存储手段实现。

如果相比临时的处理办法，比如在事实表里直接算、汇总表里直接算、或者使用临时表，这种办法更为合理和科学，因为维表，特别是企业级维表一旦算出维的描述后，可以被广泛的反复地使用，且对整个数据仓库影响不大。如果在事实表、临时表去处理，数据仓库变化就可能较大，今天这个事实表需要这样算，明天另外一个事实表也可能需要，不同粒度的统计也可能需要，而且大的事实表每次计算需要消耗很多时间，这种度量需求一旦多起来，太多字段会使事实表过早臃肿，而临时表更不能有效地进行数据和信息的存储和管理。

维表的描述字段并非就不用在事实表上了，当在数据展现的时候，各个粒度的事实表都可以和该维表关联，轻松计算出相关的度量，在不同场合下使用。

动态描述一般多是标志性字段，而静态描述一般是固定的定义，比如2008-05-29就是星期四，就是2008年，就是5月，这种描述不可能变化。

学习

2008-05-29之前四周的日期似乎应该是2008-05-01？2008-04-24应该是2008-05-29的之前五周，不知是楼主笔误还是我没有理解好....

看不太懂...
从举的例子看，好像是对时间/日期维度属性的维护来对实现一些BI需求提供便利。

[ 本帖最后由 zjsharp 于 2008-5-30 14:23 编辑 ]

这是昨晚随笔所作，主要想描述下自己经常做的BI实践方法，没仔细算，没有推敲过，很抱歉，应该算第5周了。

QUOTE:

---

原帖由 zjsharp 于 2008-5-30 14:09 发表
看不太懂...
从举的例子看，好像是对时间/日期维度属性的维护来对实现一些BI需求提供便利。

---

可以这么说吧，如果有大量这种BI需求的时候，这种思路才显得尤为重要，如果BI应用中只有1个这样的需求，其作用也就有限，你也可以在展现层直接采用临时性方案。当临时方案累计多了，就会影响整个BI架构的可管理性和维护性。

而且此法很简单灵活，没必要一碰到少见的BI应用就采用临时办法去回避问题，因为所谓少见的BI需求，也许是未来的主流需求之一。

从我多年实践的经验来看，当BI需求困难主要在属性方面时，首先得考虑从维下手（包括维表和退化维），否则问题积累多了，不肖1年，数据仓库架构就比较凌乱。只有当BI需求出现在度量的多样性时，才会考虑直接从事实表下手。

这种设计方法本来是一个小技巧，书上都没咋描述过，不足挂齿，不过看了很多朋友在问类似的问题，于是就多给一个解决方案吧，如果你需求很少，或者不考虑DW架构问题，你也大可采用临时解决方案，就是直接从事实表下手甚至直接在前端下手。

这种方法我也用过，只是不知道你们是怎么来维护维表的？ 如果需要重跑前天的数据，你们怎么来处理？

说实话
对于偶这样的小虾皮来说
还真是有点费解的

大体的理解是
在展现层有大量的临时处理会造成数据仓库架构的不稳定及不利于稳定
而采用维表动态描述的技术来代替实现

我现在在自学DW，这些对我很有帮助，谢谢LZ！