数仓理论建模

数仓理论建模

数据仓库

数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合

数仓的使用

1. 结构复杂

   业务数据库通常是根据业务操作的需要进行设计的，遵循3NF范式，尽可能减少数据冗余。这就造成表与表之间关系错综复杂。在分析业务状况时，储存业务数据的表，与储存想要分析的角度表，很可能不会直接关联，而是需要通过多层关联来达到，这为分析增加了很大的复杂度。
   举例：想要从门店的地域分布来分析用户还款情况。基本的还款数据在订单细节表里，各种杂项信息在订单表里，门店信息在门店表里，地域信息在地域表里，这就意味着我们需要把这四张表关联起来，才能按门店地域来分析用户的还款情况。
   此外，随着NoSQL数据库的进一步发展，有许多数据储存在诸如MongoDB等NoSQL数据库中，另外一些通用信息，如节假日等，通常也不会在数据库中有记录，而是以文本文件的形式储存。多种多样的数据储存方式，也给取数带来了困难，没法简单地用一条SQL完成数据查询。如果能把这些数据都整合到一个数据库里，比如构造一张节假日表。这样就能很方便地完成数据查询，从而提高分析效率。

2. 数据脏乱

   因为业务数据库会接受大量用户的输入，如果业务系统没有做好足够的数据校验，就会产生一些错误数据，比如不合法的身份证号，或者不应存在的Null值，空字符串等。

3. 理解困难

   业务数据库中存在大量语义不明的操作代码，比如各种状态的代码，地理位置的代码等等，在不同业务中的同一名词可能还有不同的叫法。

   这些情况都是为了方便业务操作和开发而出现的，但却给我们分析数据造成了很大负担。各种操作代码必须要查阅文档，如果操作代码较多，还需要了解储存它的表。来自不同业务数据源的同义异名的数据更是需要翻阅多份文档。

4. 缺少历史

   出于节约空间的考虑，业务数据库通常不会记录状态流变历史，这就使得某些基于流变历史的分析无法进行。比如想要分析从用户申请到最终放款整个过程中，各个环节的速度和转化率，没有流变历史就很难完成。

5. 大规模查询缓慢

   当业务数据量较大时，查询就会变得缓慢。尤其需要同时关联好几张大表，比如还款表关联订单表再关联用户表，这个体量就非常巨大，查询速度非常慢。美好的青春都浪费在了等待查询结果上，真是令人叹息。

   主题

   面向主题

   主题（Subject）

   将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念
   每一个主题基本对应一个宏观的分析领域
   例如“销售分析”就是一个分析领域，那么这个数据仓库应用的主题就是“销售分析”

   提取主题

   采购子系统ÿ