简述数据仓库的组成 带有ODS的体系结构中数据仓库的设计方法[6]
带有ODS的体系结构中数据仓库的设计方法[6]
维和度量的唯一性和公用性
千万不要在不同的主题中定义多个表示同一内容的维 尤其对于业务代码类型的维 如果一个业务代码形成了多个维表 那么在元数据维护过程中将困难重重GongWu Com Cn : : 在整个系统范围内 要不断检视维定义是否唯一 如果有可能 一个维表要尽量被多个主题引用
数据粒度一旦变粗 就要考虑多个主题的融合汇总
![简述数据仓库的组成 带有ODS的体系结构中数据仓库的设计方法[6]](http://img.zhputi.com/uploads/7df2/7df2ea84f049d3f800409cf65ccbed8b35130.jpg)
在数据仓库中 我们出于数据组织的规则 业务的要求 性能的要求 都可能对一个主题的事实数据进行汇总 形成粒度较粗的事实数据 但这时候我们往往忘记了粒度变粗的事实数据为最终的用户提供了更宏观的数据视图 这种宏观的数据视图当然需要进行跨主题的数据融合才能更加具有应用的价值
不论如何归并 需要保持数据之间的联系
在数据仓库中 不同主题的数据之间的物理约束或许不再存在 但无论这些数据如何变化 要知道必须有一些 键 在逻辑上保持着不同数据之间的联系 这样就可以保证有联系的主题数据之间可以进行汇总以支持未知的应用 否则数据仓库的数据是一潭死水 不可能灵活支持各种应用的
数据仓库设计可以自底向上地进行 也就是说从汇总ODS数据入手 逐渐过渡到应用主题上面去(也就是说 ODS里面的数据主题域与DW中的分析主题完全不是一回事) 我们仍然按部就班地逐项设计 这样并不是完全限定设计思路和步骤 但可以有效地提醒设计者有哪些事情要做
第一步 对ODS中的各个主题的事实数据进行时间上的汇总
ODS的事实数据是纯细节的交易数据 进入ODS的第一步就是要按照时间维进行汇总 以实现初步的信息沉淀 这种汇总不是只进行一次 而是要制定下来汇总的级别 比如日汇总信息保留 个月 月汇总信息保留 年 年汇总信息长期保存(当然在时间粒度变粗的同时一般都伴随着其他维粒度的变粗或者舍弃) 我们最终一定要定义到何种程度的数据可以在数据仓库中永久保存为止的地步
lishixinzhi/Article/program/SQL/201311/16266