本篇的主题是关于数据模型的规范化和反规范化的讨论,其实也是一种常见的维度建模的设计和业务使用便捷性的冲突。
问题:
在设计数据表的时候,是一个宽表好,还是多个维度表好?
回答一:
数据仓库每张表的搭建,主要依赖于这个表在整个数据仓库中的作用和相关意义。首先要清楚这个表的存在是为了解决那些问题,什么角色使用,怎么保证使用者尽可能好的体验解决问题。从以上所提到的角度去看待问题,拆解以下几点因素:
回答二:
结合我司的一些经验来说说哈,我司会将数据用于各种各样不同主题和纬度的报表,也会将数据用于数据挖掘做模型的,因此数据分成肯定是必要的,针对报表类的数据根据报表的不同反向划分出不同的纬度表,这种方式其实就是将mysql业务库的数据经过sql语句之后重新生成一张或者多张维度表,在这之中根据经验会抽取出一个经常用的字段作为公共字段放入公共层数据中,一些经常需要用到的度量值也会抽取到度量表中,那么一些非开发人员来看数据的时候只要在页面上简单写几个sql语句就可以统计出数据来,比如月销量,周销量,日销量这些。
若是机器学习模型的同学要数据的话,我们就只需要从维度表,度量表,事实表中抽取数据做成大宽表给他们了,由于模型做的比较少,对于大宽表的经验比较少,暂时只能来一个模型数据的需求,单独写sql语句去抽取。
这个问题,从本质上来讲。想讨论是数据模型设计里面的规范化和反规范化的问题。
从规范化的角度来讲,数据仓库的设计者是希望越规范越好,因为这样会减少数据的冗余,而且也便于模型的扩展。从反规范化的角度来讲,数据仓库的使用者是希望使用越方便越好,他们并不太关系规范不规范冗余不冗余,只要用着方便就好。
这种情况在工作中是十分常见的,那么该怎样来解决它?下面有两个思路:
另外,数据仓库的设计,往往不能是以计算出几张表就结束了,我们更应该提供的是数据服务,让使用方都通过服务的方式来访问我们的数据,而不是简单地将表暴露出去。当我们以数据服务的方式提供数据的时候,不管是易用性还是安全性都更容易得到满足。
感谢 Joker 和 Alan 的回答,感谢 Rebie 的整理,感谢木东居士的总结(自己感谢自己,^_^)。
DataTalk 系列的文章结构一般分为三部分:
一般来讲,每一篇文章都会对应到 GitHub 中的一个 Issue,比如本篇讨论内容的地址为:https://github.com/dantezhao/data-group/issues/1