上一篇文章中，大概讲到了数据仓库的起源和发展历程，简要介绍了Inmon提出的自上而下的、面向主题的、集成架构。
数据仓库的作用（价值）要发挥出来，抛开数据可信度、生产效率等问题，更重要的一点是（区别于操作性数据库），不仅仅要体现当前、近期的业务发展数据情况，更重要的是还有历史长期的业务发展情况，为管理人员、决策制定人员对公司业务的全面掌控提供基础，也赋能业务部门和生产。因此数据仓库需要存储的内容是比较庞大的，很多开销会花费在存储上，因为不会将所有数据存储全部存储在一起。存储是个问题，那我们如何解决？
引入一个粒度的概念：粒度（granularity）是指数据仓库的数据单位中保存数据的细化或综合程度的级别，细化程度越高，粒度就越小。
粒度最小的数据，展现了一个行为可以被捕捉到的最详细的信息，全面的信息包括了大量的信息，但是大量低粒度数据中也有很多不需要字段，况且每次通过小粒度做查询较为耗费数据库性能；粒度较大的数据，可能是一些业务指标发展情况，节省了大量存储空间，但是有时想做一些全面的分析时，可能又无法支撑（细节的消失）。（举个例子:一通电话，最详细的信息可能有300个字段，但是实际关注的可能只有10个维度下的一些业务发展量）
为解决这样的问题，引入双重粒度的概念。根据业务发展和潜在发展情况，从低粒度数据做一些数据汇总，做一个中粒度的数据模型，将原来300个字段的数据表缩减成60个，存储在数据仓库中，再从中粒度表汇聚成高粒度表。同时，为解决低粒度数据（潜在的查询使用问题，将其移动到成本较低的存储介质（可能处理速度比较慢）中，如磁带，把这些数据记为档案层数据。再对中粒度数据定期清除。
还有一个问题，数据库的规范化与反规范化。引入一个3NF（第三范式）的概念：3NF，即第三范式是要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
举个例子：假设我们有个操作员的表，存储操作员ID、操作员姓名、部门ID、部门名称，这个表的部门名称字段就是不规范的，因为他是冗余的。3NF要求需要将这张表拆开，A表存储操作员ID、操作员姓名、部门ID，B表存储部门ID、部门名称。在使用时通过关联获取相关信息。这个例子比较简单，而且操作员表不是存有大量数据的事实表，看起来可能对存储的影响不大，实际情况中不然。
数据库一般都要参照3NF规范，尽量减少冗余，这种规范的模型叫雪花模型，事实表与维表的关联，维表也会与维表继续关联以获取更多信息，但是使用时不方便。另一种非规范化的模型叫星型模型，直接从事实表辐射出去，不会出现维表关联维表的情况发生，会存在一些数据冗余。我的看法是在偏底层数据表设计时，尽量使用雪花模型，在偏向具体应用时（尤其是高频使用），数据量可能也会较底层表有所减少，为更方便支撑如数据集市、前端应用，应尽量采取反规范化，甚至可以做成超级冗余的宽表。
沉默是金 话唠是银
长按识别二维码关注
或搜索ID "im-wudi" 添加关注
网友评论