类型0 属性值不可能变 原样保留 费话
类型1 重写 最容易实现 覆盖原值 同样的BI应用在变化前与变化后会产生不同的结果。以前的预聚合数据要重新计算。类型1不能反应历史。
慎用。比如一个人改名了，覆盖原值说得通。如果一个人换城市了，那么他在以前的城市做的事情当然不能归到现在的城市。
应该想清楚，新值能否直接取代原值。比如一个人的性别从未知到男，当然就可以直接取代。
类型2 增加新行，代理键要与原来不同？？其实这一点可以不必。 类似与拉链表，通过三个字段来标识（开始日期，截止日期，当前行指示器）
如果代理键变了与以前的历史完全隔离开了。
类型3 增加新属性 不常用 比如增加一上“以前部门”
类型4 增加微型维度 比如用户的几个属性变化很快，那么把它们那出去单独建一张表，可以对这些属性做去重，数量会少很多（108页）；而且此维度是作为一个维度在事实表中去引用。用户表并不引用它。 搞这么复杂有必要么？
类型5 微型维度与类型1支架表 在微型维度做为用户维度的支架，做类型1重写缓慢变化。
类型6 先做类型3，增加“历史部门”，对于“当前部门”做类型1，对于“历史部门”做类型2
日期与时间应该是两个维度；
类型1 重写 最容易实现 覆盖原值 同样的BI应用在变化前与变化后会产生不同的结果。以前的预聚合数据要重新计算。类型1不能反应历史。
慎用。比如一个人改名了，覆盖原值说得通。如果一个人换城市了，那么他在以前的城市做的事情当然不能归到现在的城市。
应该想清楚，新值能否直接取代原值。比如一个人的性别从未知到男，当然就可以直接取代。
类型2 增加新行，代理键要与原来不同？？其实这一点可以不必。 类似与拉链表，通过三个字段来标识（开始日期，截止日期，当前行指示器）
如果代理键变了与以前的历史完全隔离开了。
类型3 增加新属性 不常用 比如增加一上“以前部门”
类型4 增加微型维度 比如用户的几个属性变化很快，那么把它们那出去单独建一张表，可以对这些属性做去重，数量会少很多（108页）；而且此维度是作为一个维度在事实表中去引用。用户表并不引用它。 搞这么复杂有必要么？
类型5 微型维度与类型1支架表 在微型维度做为用户维度的支架，做类型1重写缓慢变化。
类型6 先做类型3，增加“历史部门”，对于“当前部门”做类型1，对于“历史部门”做类型2
日期与时间应该是两个维度；
420
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
