维度表的层次
- 维度表进行一定的降维，一般情况加有一定的冗余是可以接受的。
- 维度表应该设计成多层次的，方便下钻
维度表中的数字列
- 一些数字类型 应该 依据具体的业务来判断其是否归入维度属性的分类。 比如一些商品的标准价格，可以用于计算以及过滤，分组等功能，这个和事实表中的商品标准价格在意义上是不同的： 事实表中的标准价格表示销售事物的价格，而维度属性则标记为当前情况的标准价格。
维度表中的空行，空值
- 对于营销方面的维度表来说：例如优惠券等，因为事实表中可能会存在未参加促销的商品，所以应当在优惠券维度表补充一行代表不含促销的条件，避免事实表中出现空的促销key维度。
- 在事实表中不同的技术可能对空值的处理不同，所以也可以减少不必要的转换。
维度表中的日期
-
对于一些维度表中的日期：比如商店维度表中代表开店日期和改装日期如果业务又需求也应该记录下来，可以作为非标准的日期来提供一定的维度（利用view的技术）。 -
日期维度是一种特殊的维度， 因为他几乎出现在所有的维度模型中。并且在事实表中，日期维度是大多数情况下也是首先需要考虑分区的一个条件。与多数其他维度不同，可以提前建立日期维度表，可以在表中表示，历史或未来不同日期，对与其他与业务相关的，说日期维度表是一个很小的表。 -
日期维度表应该尽可能做得详细 虽然我们可以用SQL的方式来实现日期的计算，例如： 计算某个日期是哪一周的哪一天，这个日期属于哪一周， 是否是节假日。 但是这样子务必带来了计算上的转换的效率问题。并且有可能需要多次与其他日期相关的维度表去join。在大数据场景下，join就意味着shuffle。 -
不同的数据库上的日期函数上的实现方式也有很大的不同，带来了很多不必要的问题 -
对于一些 日期维度的文本属性的标识，比如是否为节假日，尽量不要使用编码的形式去代表他应该去转换为更有意义的，能够自我解西的一个标识。 eg： Y/N 、 1 / 0 这样带来的问题就是：
这样是不明确的，下面的方案会更好，将节假日标识 直接使用 节假日、非节假日来表示。
以上与其通过计算或者关联，拿到这一些额外信息，不如直接将日期维度表打宽，尽可能记录的详细。
新的维度属性
如果维度表中出现了新的维度属性，可以将这些属性做为新的列增加到维度，所有现存的应用是不受这些属性的影响的
但是业务如果需要对历史数据进行跟踪的变化，这其实就是一种缓慢的变化的维度了，可以使用拉链表解决。
新的维度
如果后续业务中出现新的维度，可在新的事实表上增加新的维度。
在事实表上增加新的外键列，并将从新的维度逐渐填写到该外键列上。
– by 俩只猴
|