数仓建模方法
前言
1、建模进阶之路
朴素维度建模->面向源系统维度建模->面向业务流程维度建模、第三范式建模、DataVault建模->企业建模->......
EDW（企业级数仓）建模主要是面向业务流程维度建模、第三范式建模、DataVault建模三种
2、为什么建模
数据建模就是数据组织和存储方法。提升使用数据的效率，降低数据存储、计算、理解成本，统一数据口径。
kimball inmon 独立集市
3、为什么分层
提升数据访问效率，拆解复杂过程，降低源系统变更对模型的影响
常见分层：ods贴源层，dwd明细层，dws汇总层，ads应用层
一、三范式建模
1.1 概念
由inmon提出，主要解决关系型数据库的数据存储。用实体关系模型描述企业业务，在范式上符合3NF。
一个符合第三范式的关系必须具有以下三个条件 :
每个属性值唯一，不具有多义性 ;
每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
1.2 典型代表
3NF建模是面向主题的抽象，典型的代表是teradata发布的金融业的FS-LDM（Financial Services Logcial Data Model）
各主题域的基本内容如下：
-
当事人 （ Party ） ：银行所服务的任意对象和感兴趣进行分析的各种对象。如个人或公司客户、潜在客户、代理机构、雇员、分行、部门等。一个PARTY可以同时是这当中许多种角色。
-
产品 （ Product ） ：为拓展市场占有率，满足客户更广泛需求而制定的可营销的交易品种的集合，产品是金融机构向用户销售的或提供给客户所使用的服务。
-
协议 （ Agreement ） ：金融机构与当事人之间针对某种特定产品或服务而签立的契约关系。它可以是多样化的，如帐户、客户和银行签订的合同等。当金融机构与客户之间针对某种产品或服务的条款和条件达成协议时，一个协议（AGREEMENT）就会被开立，因此协议是客户和银行往来的重要载体。
-
事件 （ Event ） ：银行与客户或潜在客户之间的联系或交易活动，它记录了详细的行为和交易数据，包括存取款、收费、计息、咨询投诉、查询、市场调查、网上交易等。既可以与资金相关，也可以与资金无关；既可以有客户参与，也可以没有客户参与；既可以与帐户相关，也可以与帐户无关；可以由客户发起，也可以由银行发起。通过事件可以帮助了解哪些客户使用哪些渠道做哪种交易事件，交易金额多少、什么时间、在什么地点、与金融机构的哪位员工或部门打交道。
-
资产 （ Asset ） ：可能采集到的客户的资产（负债）信息，也包括银行向外租赁的资产信息。这些信息的来源很多情况下是在客户申请贷款时所提供的各种担保品信息、抵质押品信息等。
-
财务 （ Finance ） ：包括银行的总帐信息，是描述科目组织、控制、内部核算等银行核心科目帐务以及预算管理有关的内容。该主题抽象地描述了银行内部帐务的组织模式，能够适应不同的科目组织体系。
-
内部组织 （ Internal Org ） ：金融机构或保险公司的内部的业务单元。它可能是银行内部的组织机构（如分行、支行、网点、部门等），也可能是任何一个法人机构当事人的内部组织，严格意义上这些也是一种特殊的PARTY。
-
地域 （ Location ） ：是希望观察和分析的任何区域，既包括传统类型的地址信息（如国家、地区、城市、区县、街道等），又包括如电话信息、邮箱、黄页等电子地址信息。
-
营销 （ Campaign ） ：一些有组织的活动，其目的可以是为了把某些产品推向市场，也有可能是为了树立银行在市场上的形象；完整的营销活动应该包括营销策略、营销行为以及营销活动的反馈信息；收集营销活动的信息可以帮助银行发现最有效的营销方式，了解不同类型客户对营销活动的反馈。
-
渠道（ Channel ） ：当各种事件发生时，当事双方（主要是指客户和银行）进行交互和接触的手段及方法，通过它客户与银行进行接触、购买产品、使用服务并交流信息。
一个实例
交易流水中，最常见的存款业务，可以抽象为如下8个主题。每个主题常见的属性如下图示例。
二、维度建模
2.1 概念
维度建模（dimensional modeling）是数据仓库建设中的一种数据建模方法，将数据结构化的逻辑设计方法，由Kimball 最先提出这一概念。按照事实表，维表来构建数据仓库，数据集市。
维度建模下的一些常用名词：
业务过程：业务过程是组织完成的操作性活动，例如下单、支付、退款都是业务过程。业务过程是一个不可拆分的行为事件。
粒度：粒度是确定某一事实表的行表示的是什么，例如订单粒度、订单加商品粒度。粒度可以通过两种方式表示，一种是具体的业务含义，一种是维度属性组合所表示的细节程度。
维度：用以描述在业务过程中所涉及的谁、什么、哪里、何时、如何、为什么等背景，是观察数据的特定角度。
维度属性：维度属性隶属于一个维度，如地理维度里的省份名称。
事实：表示对业务过程的度量，通常是数字类型的，可以计算和聚合，例如下单量。与原子指标概念相同
维度建模主要有星型模型、雪花模型。
优点：
2、星型连接模式的可预测框架能够忍受不可预知的用户行为变化。
3、具有非常好的可扩展性，以便容纳不可预知的新数据源和新的设计决策。可以很方便在不改变模型粒度情况下，增加新的分析维度和事实，不需要重载数据，也不需要为了适应新的改变而重新编码。较好的扩展性意味着以前的所有应用都可以继续运行，并不会产生不同的结果。
缺点:
1、由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。
2、另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
2.2 总线架构和总线矩阵
维度建模的数据仓库中，有一个概念叫Bus Architecture，中文一般翻译为“总线架构”。总线架构是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是一致性维度（Conformed Dimension）和一致性事实（Conformed Fact）。
一致性维度就好比企业范围内的一组总线，不同数据集市的事实的就好比插在这组总线上的元件。这也是称之为总线架构的原因。
实际设计过程中，我们通常把总线架构列表成矩阵的形式，其中列为一致性维度，行为不同的业务处理过程，即事实，在交叉点上打上标记表示该业务处理过程与该维度相关。这个矩阵也称为总线矩阵（Bus Matrix）。
总线矩阵提供一种分解企业DW/BI规划任务的合理方式，行是业务过程，列是公共维度（一致性维度），图表中的X表示的是哪些列与哪些行有关系，也表示这一个业务过程需要有哪些公共维度。
如下图：
2.3 维度建模步骤
1、选择业务过程
业务过程是组织完成的操作型活动。业务过程事件建立或获取性能度量，并转换为事实表中的事实。多数事实表关注某一业务过程的结果。过程的选择是非常重要的，因为过程定义了特定的设计目标以及对粒度，维度，事实的定义。每个业务过程对应企业数据仓库总线矩阵的一行。
2、声明粒度
声明粒度是维度设计的重要步骤。在选择维度或事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在所有维度设计中强制实行一致性是保证BI应用性能和易用性的关键。在从给定的业务过程中获取数据时，原子粒度时最低级别的粒度。最好从原子级别粒度开始设计，因为原子粒度能够承受无法预期的用户查询。针对不同的事实表粒度，要建立不同的物理表，在同一事实表中不要混用多种不同的粒度。
3、确认维度
维度围绕某一业务过程事件所涉及的谁、什么、何处、何时、为什么、如何等背景。维度表包含BI应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度，就能够将所有可能存在的维度区分开。当与给定的事实表关联时，任何情况都能保证维度表唯一值。
4、确认用于度量的事实
事实设计来自业务过程事件的度量，基本上都是以数量值表示。一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系，因此事实表对应一个物理可观察的事件。在事实表内，所有事实只允许与生命的粒度保持一致。
5、确认所需的冗余维度
额外的为减少下游使用时需要多次关联的场景所增加的冗余维度。
