数据仓库建模参考

https://wenku.baidu.com/view/b6bd5ccb4028915f804dc294.html 数据仓库建模案例

https://wenku.baidu.com/view/623fb724482fb4daa58d4b69.html 数据仓库建模规范1.0

http://bigdata.51cto.com/art/201611/520727.htm  数据仓库优化数据分析

https://wenku.baidu.com/view/80f35707844769eae009ed29.html?re=view  数据仓库的建模方法

http://www.docin.com/p-1292730739.html  数据仓库维度集定义

宽表的思考

宽表从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余，与之相对应的好处就是查询性能的提高与便捷。这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提高数据挖掘模型训练过程中迭代计算时的效率问题。

一 宽表的优点

1.      宽表浅意上的好处

在当前这个项目中，大量使用了宽表，字段超过一百五十个字段的宽表有五张，分别是客户机构级信息表、客户客户经理级信息表、客户经理信息表、集团客户信息表、战略客户信息表。

从上面的表名中可以猜到，这是个CRM项目，我这里能列举出来的优点也是在项目中体现出来的优点。

大量使用宽表究竟给我们带来了什么好处？

•  窥一表知全貌
•  查询速度快（此处我一直保留疑问）

窥一表知全貌：这个好处很明显，尤其是收到报表开发人员的欢迎，他们不关心数据如何存储，只关心这张报表是不是很方便，很快的能开发出来。还有一个就是数据分析人员，银行业大部分数据分析人员很讨厌做表关联，他们喜欢一条记录看到客户的全貌。

查询速度快：大多数情况确实如此，大部分SQL慢都是由于表关联造成的，所以大家都在思考不关联出结果。于是，出现了将一些常用的信息都做成了大宽表，此处让我这种范式强迫症患者很是头疼……

二 宽表的不便

从一个ETL人员角度讲，使用宽表带给我的痛苦远远大于它带给我的快乐，此处描述一下我们目前面对的系统，从系统出发解释宽表带来的问题。

项目是一个CRM系统，以仓库数据（TD）为基础，进行建模、数据加工，作为仓库的一个集市落地后，在将这部分数据，同步到查询服务器（DB2）上，每日从TD到DB2的数据量约为16G，同步数据的方式为TD导出数据生成txt，上传到FTP服务器后在通过SHELL加载到DB2。

了解了项目的背景，就可以列举出在使用宽表时有如下不便

•  脚本过长，不易维护
• 字段的增删过于复杂

因为要在两个系统中同步两张表一份数据，增删字段时一定要考虑一致性，同时要考虑历史数据如何处理。每次都需要经过如下步骤：

1.        修改TD表结构

2.        修改TD脚本

3.        修改导出数据脚本

4.        修改DB2表结构

5.        修改DB2加载数据的Shell脚本

每次变动都伴随这大量的工作，同时还需要因为这个字段加载新的历史数据或更新这个字段的内容，此处在项目后期维护中带来了很大的工作量。

三 如何优雅的使用宽表

宽表在仓库的汇总层大量使用，如客户、存款、贷款等通用的实体都被设计为宽表。这些宽表会面临我上面提到的问题吗？

显然不会，仓库的表很少因为个人需求而增减字段，同时仓库大多只负责原始数据的存储，不会涉及到太复杂的字段加工逻辑，故大多数汇总层的表都被设计为宽表。

要想优雅的使用宽表，我认为需要注意以下这一点：

字段是否会频繁增减

对于不涉及到事务的表且字段不会频繁增加，建议设计为宽表，尤其对于BI系统。

当然，这只是一个最简单粗暴的原则，真正做的时候，你要考虑对于不同的数据库产品，宽表中很多字段是否为空等。

针对不用的场景做不同的选择，这句话，听起来很虚，其实很实。