一个宽表好还是多个维表好？

前言

本篇的主题是关于数据模型的规范化和反规范化的讨论，其实也是一种常见的维度建模的设计和业务使用便捷性的冲突。

Dimension Table概念多出现于数据仓库里面，维表与事实表想对应，比如一个 “销售统计表” 就是一个 事实表，而 “销售统计表” 里面统计数据的来源离不开 “商品价格表”，“商品价格表” 就是销售统计的一个维度表。事实数据和维度数据的识别必须依据具体的主题问题而定。“事实表” 用来存储事实的度量及指向各个维的外键值。维表用来保存该维的元数据

 讨论

问题：

在设计数据表的时候，是一个宽表好，还是多个维度表好？

回答一：

数据仓库每张表的搭建，主要依赖于这个表在整个数据仓库中的作用和相关意义。首先要清楚这个表的存在是为了解决那些问题，什么角色使用，怎么保证使用者尽可能好的体验解决问题。从以上所提到的角度去看待问题，拆解以下几点因素：

1. 拆表情况下多张数据表的查询SQL的编写难度有多大，是否会出现为了数据提取需要关联多张表，并且需要提前知道各个表之间的关联关系。如果使用这个数据的人员较多，每个人都需要先了解所需要多张表的关联关系，然后才进行数据查询，这样是不是维度沟通成本较高，查询体验下降，影响使用者的工作效率？
2. 多表关联查询的使用频次有多高，将重复高频的事情简化，是不是更好？
3. 查询体验上需要考虑多表关联之后的查询性能问题，如果一张表的内容过度，是否影响查询速度？
4. 多表关联的合理性，不同的数据维度和内容与订单表关联，是不是会存在违背常理的坑存在。比如，数据字段的对应关系是一对一，还是多对多，是否会让使用者忽略查询数据时候的过滤限制条件。
5. 数据的安全问题，每张数据表的安全范围不同，合并成同一张表是面临的是更大的权限开放。比如订单表可能仅需要让一部分人员知晓订单信息，并不想让他们知道供应商信息。

回答二：

结合我司的一些经验来说说哈，我司会将数据用于各种各样不同主题和纬度的报表,也会将数据用于数据挖掘做模型的，因此数据分成肯定是必要的，针对报表类的数据根据报表的不同反向划分出不同的纬度表,这种方式其实就是将mysql业务库的数据经过sql语句之后重新生成一张或者多张维度表,在这之中根据经验会抽取出一个经常用的字段作为公共字段放入公共层数据中,一些经常需要用到的度量值也会抽取到度量表中,那么一些非开发人员来看数据的时候只要在页面上简单写几个sql语句就可以统计出数据来,比如月销量,周销量,日销量这些。

若是机器学习模型的同学要数据的话,我们就只需要从维度表,度量表,事实表中抽取数据做成大宽表给他们了,由于模型做的比较少,对于大宽表的经验比较少,暂时只能来一个模型数据的需求,单独写sql语句去抽取。

补充

这个问题，从本质上来讲。想讨论是数据模型设计里面的规范化和反规范化的问题。

从规范化的角度来讲，数据仓库的设计者是希望越规范越好，因为这样会减少数据的冗余，而且也便于模型的扩展。从反规范化的角度来讲，数据仓库的使用者是希望使用越方便越好，他们并不太关系规范不规范冗余不冗余，只要用着方便就好。

这种情况在工作中是十分常见的，那么该怎样来解决它？下面有两个思路：

1. 两种方式都存。虽然，这样看起来会占用更多的存储空间，但不失为一种合适的解决方案，因为宽表是通过别的表拼接而成的，因此宽表的存储周期是可以短一些。
2. 只存多个维度表，通过视图来创建宽表。这种方式适合于宽表的查询次数较少的情况。比如在Hive中，宽表其实只是为了计算出来之后导入Es等系统中供其它系统查询，那么久没必要存储一份宽表，直接通过视图来封装就可以。

另外，数据仓库的设计，往往不能是以计算出几张表就结束了，我们更应该提供的是数据服务，让使用方都通过服务的方式来访问我们的数据，而不是简单地将表暴露出去。当我们以数据服务的方式提供数据的时候，不管是易用性还是安全性都更容易得到满足。