cq9电子游戏app：数据建模的方法及模型

　　由于在变化快速的商业世界里，业务形态多种多样，为了能够更有针对性的进行数据建模，经过长时间的摸索，业界逐步形成了数据建模的四部曲：

　　简单讲，就是明确具体业务，抽象实体和关系，结合具体的建模方法，确定所有关键成分和属性，最后建数据表进行数据的存储和计算。

　　目前数据建模的方法论有两大阵营，一个是基于关系型数据库理论设计出来的，比如基于3NF的范式建模。虽然目前也有不少非关系型数据库以及不少半结构化和非结构化数据。但将半结构化/非结构化数据转化为结构化数据，然后再利用关系型数据库处理仍然是一种通用的主流数据处理方案。

　　另一个是基于数据仓库之父Bill Inmon提出的维度建模理论，是从全企业的高度利用实体关系来对企业业务进行描述。

　　数据几乎总是用于两种目的：操作型记录的保存和分析型决策的制定。简单来说，操作型系统保存数据，分析型系统使用数据。前者一般仅反映数据的最新状态，按单条记录事务性来处理；其优化的核心是更快地处理事务。后者往往是反映数据一段时间的状态变化，按大批量方式处理数据；其核心是高性能、多维度处理数据。

　　针对这两种不同的数据用途，如何组织数据，更好地满足数据使用需求。这里就涉及到数据建模问题。即设计一种数据组织方式（模型），来满足不同场景。在OLTP场景中，常用的是使用实体关系模型（ER）来存储，从而在事务处理中解决数据的冗余和一致性问题。

　　在OLAP场景中，有多种建模方式有：ER模型、星型模型和多维模型。下面分别说明下：

　　1、ER模型OLAP中的ER模型，与OLTP中的有所区别。其本质差异是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。

　　2、星型模型星型模型，是维度模型在关系型数据库上的一种实现。该模型表示每个业务过程包含事实表，事实表存储事件的数值化度量，围绕事实表的多个维度表，维度表包含事件发生时实际存在的文本环境。

　　这种类似于星状的结构通常称为星型连接。其重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。在星型模型基础上，在复杂场景下还可以进一步衍生出雪花模型。

　　3、多维模型多维模型，是维度模型的另一种实现。当数据被加载到OLAP多维数据库时，对这些数据的存储的索引，采用了为维度数据涉及的格式和技术。性能聚集或预计算汇总表通常由多维数据库引擎建立并管理。由于采用预计算、索引策略和其他优化方法，多维数据库可实现高性能查询。

　　维度建模，是数据仓库大师Ralph Kimball提出的，是数据仓库工程领域最流行的数仓建模经典。

　　维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。它是面向分析的，为了提高查询性能可以增加数据冗余，反规范化的设计技术。

　　事实表产生于业务过程，存储了业务活动或事件提炼出来的性能度量。从最低的粒度级别来看地型模型，事实表行对应一个度量事件。

　　事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表。

　　事务事实表，用于承载事务数据，通常粒度比较低，它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表，例如产品交易事务事实、ATM交易事务事实。

　　周期快照事实表，按照一定的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充。用来记录有规律的、固定时间间隔的业务累计数据，通常粒度比较高，例如账户月平均余额事实表。

　　累积快照事实表，用来记录具有时间跨度的业务处理过程的整个过程的信息，每个生命周期一行，通常这类事实表比较少见。

　　注意：这里需要值得注意的是，在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。

　　维度表，一致性维度，业务过程的发生或分析角度，我们主要关注下退化维度和缓慢变化维。

　　在维度类型中，有一种重要的维度称作为退化维度，亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。

　　维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD）。

　　在为维度成员增加新行时，需为其分配新的主代理键。并且，至少需要在维度行再增加三列：有效日期、截止日期、行标识。这个地方可联想拉链表设计。

　　可根据实际业务场景，混合或选择使用以上三种方式，以快速方便而又准确的分析历史变化情况。

　　用于确定某一事实表中的行表示什么，是业务最小活动单元或不同维度组合，即业务细节程度。

　　维度建模步骤：选择业务过程-声明粒度-确定维度-确定事实。旨在重点解决数据粒度、维度设计和事实表设计问题。

　　声明粒度，为业务最小活动单元或不同维度组合。以共同粒度从多个组织业务过程合并度量的事实表称为合并事实表，需要注意的是，来自多个业务过程的事实合并到合并事实表时，它们必须具有同样等级的粒度。

　　由于在维度建模过程中，涉及到很多概念。下面通过一个场景来，来一一说明。例如：常见的电商下单环节，每个用户提交一笔订单（仅限一个物品），就对应于一条订单记录。

　　在开始维度建模工作之前，需要理解业务需求，以及作为底层源数据的实际情况。通过与业务方沟通交流、查看现有报表等来发现需求，用于理解他们的基于关键性能指标、竞争性商业问题、决策制定过程、支持分析需求的目标。同时，数据实际情况可通过与数据库系统专家交流，了解访问数据可行性等。

　　业务过程是组织完成的操作型活动。业务过程时间建立或获取性能度量，并转换为事实表中的事实。多数事实表关注某一业务过程的结果。过程的选择非常重要的，因为过程定义了特定的设计目标以及对粒度、维度、事实的定义。

　　声明粒度是维度设计的重要步骤。粒度用于确定某一事实表中的行表示什么。在选择维度或事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在从给定的业务过程获取数据时，原子粒度是最低级别的粒度。强烈建议从关注原子级别粒度数据开始设计，因为原子粒度数据能够承受无法预期的用户查询。

　　维度提供围绕某一业务过程事件所涉及的谁、什么、何处、何时、为什么、如何等背景。维度表包含分析应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度，就能够将所有可能存在的维度区分开来。

　　事实，涉及来自业务过程事件的度量，基本上都是以数据值表示。一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系，因此事实表对应一个物理可观察的事件。在事实表内，所有事实只允许与声明的粒度保持一致。

　　选择一种维度模型的落地方式。既可以选择星型模型，部署在关系数据库上，通过事实表及通过主外键关联的维度表；也可以选择多维模型，落地于多维数据库中。

　　数据仓库建模方法论可分为：维度建模、范式建模、Data Vault模型、Anchor模型。1、维度模型企业中最流行、也是最经典的数仓建模经典，数据仓库大师Ralph Kimball的经典著作《数据仓库工具箱 维度建模权威指南 第三版》一本书进行了论述。从事数据仓库/ETL/BI的同学，强烈建议买一本至少读一遍。按数据组织类型划分可分为星型模型、雪花模型、星座模型。（1）星型模型星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。

　　（2）雪花模型雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面也较差，所以一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。

　　（3）星座模型星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。数仓模型建设后期，大部分维度建模都是星座模型。

　　2、范式模型即实体关系（ER）模型，数据仓库之父Immon提出的，从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF。此建模方法，对建模人员的能力要求非常高。

　　3、Data Vault模型DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性） 三部分组成 ，是Dan Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。