目录
- DW=DB+Data
- 存储空间的估算
- 实体表数据行数估算
- 业务活动表数据行数估算
- 粒度的确定
- 越细越好?
- 确定的方法
- DM的影响
- DB
- 法律
DW=DB+Data
DW相对于DB的最大一点是对于数据物理情况的讨论,对于DB而言,设计的时候遵循关系模型的设计范式,顶多在性能出现问题时打破设计范式,而对于DW而言,设计范式从一开始就是被打破的,其中原因就是数据量的大小.对于DB而言,虽然其称为Database,但是它只关注了DDL(有时也考虑DML),但是对于Data本身却缺少考虑.粒度就是一个体现出DW和DB这种差异的地方.
存储空间的估算
一般会估算下一年和五年数据量的大小,可以使用下面公式:
数据量=(单行数据量*行数+索引)*备份
实体表数据行数估算
以估算顾客表为例
- 公司的愿景
- 市场容量&市场份额
- 竞争对手的业务量
业务活动表数据行数估算
和上面类似,只是先关注单位时间的量,再相乘.
粒度的确定
越细越好?
显而易见的一点是粒度不宜过大也不宜过小,即使我们有充足的存储器来存放所有的数据,也应该部分高细粒度的数据放到较慢的存储器上,甚至离线存储.
确定的方法
如何确定粒度呢,这里就又回到了数据仓库一书的感悟与批判-决策支持系统的发展中开发模式一节提到的流程,先模糊的给DSS分析员一个,然后接受反馈并改进.在书中,给了一个振奋人心的标准,只要50%是正确的,就是成功的.
DM的影响
另一个显而易见的是DW的数据要满足DM的需要,包括粒度的情况
DB
这里有一个想法,在数据仓库一书的感悟与批判-决策支持系统的发展中DW的帮助中提到.就是数据从DB到DW后就可以清除掉DB中的数据,从而可以提升性能.我不得不说这个DW的又一个谎言,首先DW为了自己的性能考虑可能剔除掉这些数据(也可以以冷数据的形式),另一方面这些数据提供给客户来查询时也很不方便,客户已经习惯了原有业务系统的查看页面,所以对于这种情况我的建议是DW不要接手这个需求但是可以提供技术支持,业务系统完全可以把DB整个备份后删除不想要的数据来释放空间.
法律
另一个对于一些最低细粒度数据的把控(我个人觉得,一旦完成按天的汇总,数据量就不可能特别大)的指导标准就是倾听律师的建议,而不仅仅是业务人员的诉求(他们必然要求存储所有数据并提供实时访问)