(个人意见:)
1,有可对应原系统数据的标识(最好确定与业务无关的唯一主键)。
2,有数据的生成时间字段(确定增量的有效方法)。
3,尽量采用第三范式(尽量清除数据的二异性)。
4,有能够确定分区的字段。
5,原系统表间关联辅助字段应保留。
6,缓慢变化慎用。
7,流水表设计时间字段统计尽量唯一。
(个人疑问:)
1,针对需要建立缓慢变化的数据,如果原业务系统已记录,是否直接使用还是另做处理,另做处理产生二异性如何处理。
2,设计唯一主键由原系统主键拼接可能主键字段过长, 是否有其它方式。
3,模块设计包含范围。
4,权衡各系统共性,业务驱动、技术驱动。
原生产系统表结构不稳定而开始数据仓库,是最大提忌讳。
目前我们面临的问题是,多种源表结构(AA、BB,CC)等等,且版本众多, 统一表结构是一个相当困难的事情,我们只能做到统一一些核心大众化模块中的一部分核心表(如,a1、a2、a3),且这种统一势必会造成只取到各表结构的共性,而丢失其结构的个性属性。有些结构甚至无法统一,或者是要清理其各表业务涵义进行拼装组合,造成工作量大、失真处理。
建模可以说是项目进展的第一步,是否可先集中有关力量进行开发,再进行其它相关模块。
目前困惑是,我们应该是以AA为主要服务的,但过渡上线则离不开现在BB、CC版本,AA表结构未确定或不稳定,要兼容多者有些无从下手。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/134308/viewspace-700858/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/134308/viewspace-700858/