什么是数据模型
数据模型是抽象描述现实世界的一种方法，是通过抽象的实体及实体之间的联系来表示现实世界中事务的相互关系的一种映射。
数据仓库模型是数据模型中针对特定的数据仓库应用系统的特定模型。由下图四部分内容组成：
l 业务建模，主要解决业务层面的分解和程序化。
l 领域建模，主要对业务模型进行抽象处理，生成领域概念模型。
l 逻辑建模，主要将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
l 物理建模，主要解决逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。
2 数据仓库数据模型架构
数据仓库模型由五部分组成
系统记录域：数据仓库业务数据存储区，模型保证了数据的一致性。（继续使用Oracle？）
内部管理域：也就是元数据模型的存储管理。（工具待定）
汇总域：系统记录域的汇总数据，数据模型保证的主题分析的性能，满足部分报表查询。
分析域：用于各个业务部分的具体的主题分析。也就是数据集市。
反馈域：针对前端反馈的数据，根据业务需求而定。
3 数据模型的作用
l 进行全面的业务梳理，改进业务流程。
l 建立全方位的数据视角，打通信息孤岛，去除数据差异。
l 解决业务的变动，提高数据仓库灵活性。
l 帮助数据仓库系统本身的建设。
4 如何创建数据仓库模型
4.1 数据仓库建模四个阶段
4.1.1 业务建模
l 划分整个企业的业务，一般按部门划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
l 深入了解各业务部门工作流程的方法。
l 提出修改和改进业务部门工作流程的方法。
l 数据建模的范围界定，确定数据仓库项目的目标和阶段划分。
4.1.2 领域概念建模
l 抽取关键业务概念，并抽象化。
l 将业务概念分组，按业务主线聚合类似的分组概念。
l 细化分组概述，理清分组概念内的精力流程并抽象化。
l 理清分组概念之间的关联，形成完整的领域概念模型。
4.1.3 逻辑建模
业务概念实体化、事实实体化、说明实体化，并考虑其属性内容。
4.1.4 物理建模
l 针对特定物理平台做出相应的技术调整
l 针对模型的性能考虑，结合特定平台做出相应调整
l 生成执行脚本，并完善。
4.2 数据仓库建模的方法
数据仓库建模方法种类较多，常见的三种是范式建模、维度建模、实体建模，每种方法本质上都是从不同的角度解决业务中的问题。
4.2.1 范式建模
Inmon所提倡的范式建模就是关系数据库用的三范式建模方法，数据仓库模型的建设方法和业务系统的数据模型类似。有一些区别就是：
1) 数据仓库的域模型应该包含业务数据模型到域模型之间的关系，以及各主题域定义，数据仓库的域模型概念比业务系统的主题域模型范围更广。
2) 在数据仓库的逻辑模型需要从业务系统的逻辑模型中抽象实体、实体的属性、实体的子类、实体关系等。
l 优点：从关系型数据库角度出发，结合了业务系统的数据模型，方便实现数据仓库的建模。
l 缺点：某些时候限制了整个数据仓库的灵活性、性能等。特别在底层数据向数据集市汇总时需要进行在量的数据处理工作。
4.2.2 维度建模
Kimball主张维度建模法，就是按维度表、事实表来构建数据仓库、数据集市。维度建模有星形、雪花型两种常见类型。
l 优点：维度模型可极大提升数据仓库的处理能力；紧紧围绕业务模型，直观的反映业务问题。
l 缺点：构建模型之前需要进行大量的数据预处理，当业务变化后需要重新定义维度时，需要重新进行维度数据的预处理；很难提供一个完整地描述真实业务实体之间复杂关系的抽象方法。
l 辩解：对于这些缺点，都是片面的，因为数据仓库总线架构和维度处理方法能很好解决以上问题。
以下对维度建模深入介绍一下：
4.2.2.1 维度建模的四个步骤
1) 选择业务过程（比如：促销活动、评选活动、产品交易等）
2) 声明粒度（确定数据单位的综合程度）
3) 识别维度（粒度已经确定了一个基本的维度集合，根据需要再添加其他相关的维度）
4) 识别事实（选择适合业务过程的指标）
4.2.2.2 企业数据仓库总线
数据仓库建模的争议点：从建立一个集中式的、规划好的架构角度为整个企业建立数据仓库，还是为每个具体的部门建立小型的独立解决方案。当然这两种都不是很有效。前者需要在设计之前将所有数据、所有业务完全掌握清楚，并对数据清洗等了解清楚，这个很难办到，后者由于是单独的创建集市，导致各集市互不兼容，无法形成企业级的全局的数据仓库。
如何解决这一难题，首先需要迅速简洁地定义整个企业数仓系统的数据架构，收集业务需求生成企业数据仓库总线矩阵，矩阵每行对应一个业务过程，每列都是一个业务维度。逐个收集业务过程，并使用一致性维度确保系统的综合集成。这样每个业务过程的实现都对整个架构进行了增量扩展，迭代地建立成一个集成的数据仓库。基于一致性维度的架构将一组业务过程紧密的联系到一起形成了企业数据仓库。企业数据仓库的总线其实就是共享的一致性维度。
另外：一致性维度需要得到高层的支持，因为要做到统一其实是牵扯很多业务系统的事情，有很多是非技术问题。
4.2.2.3 深入讨论维度
重点进行全面深入的对维度建模上的各个关键点进行阐述。
4.2.2.3.1 日期维
在数据仓库中占有特殊的地位，几乎每个事实都是一个观测序列，没有时间，讨论一切将没有意义。但日期在各系统中的格式有差异，长短也许不一致，使用代理键可以解决这个问题。但在使用时间戳时，不需要使用代理键。
4.2.2.3.2 退化维
诸如订单号、发票编号、提货单编号等都是事实表的成员，属于主键值，但其没有单独的维度表，所以称之为退化维。它在分析中可用于分组。
4.2.2.3.3 缓慢变化维
有些维度的属性是会发生变化的，比如姓名、地名等会变，这样会对产生的事实结果造成影响，可以用以下方法解决：
l 覆盖维度属性
直接覆盖的方式将会丢掉历史信息，所以适用于修正错误，也可在旧值对业务来说没有意义时使用。（很少用）
l 添加一行新维
在维度变化时插入一个有新代理主键的行来反映新的属性值，并且需要生效日期、失效日期、当前状态来辅助查询。比如某人身份证号不变，但名字发生变化，就需要将旧名字设置为失效，并加上有效区间。（主要解决方法）
l 添加一个新的维度属性
向维度表中添加新列，原属性值放入先前的属性列中，新属性值覆盖现有列。（使用较少）
4.2.2.3.4 杂项维
在确定了明显的业务维度之后，还会有许多杂乱的标记和文本属性无法归纳进去，将事实表用到的这些属性组合成一个维度表并设置代理键，也就是将事实表中这些非维度属性抽取到新的维度表中，这些属性组成了杂项维。
4.2.2.3.5 雪花型
当对维度表进行范式建模时，会产生多层的引用，这样就将星形变成雪花型了，雪花型（冗余低）因为引用层级较多，看起来眼花缭乱不易理解，还造成查询速度大大降低，特殊需要是可以创建，但层级一定不要太深。
4.2.2.3.6 使用桥接表的多值维
以上分析的全是事实表与维度表1对N的关系，在有些情况下，每个事实度量都可以和多个维度值相关，这样就产生了多对多的关系，那么事实表的一个维度值怎么变成多个值？这就需要加人桥接表，这个表将这个维度的所有值进行组合，每种组成生成桥接表的新行，然后在事实表中使用这个桥接表的代理键即可。
4.2.2.4 三种事实表
所有度量事件都可以转化成事务、周期快照、累积快照。事实表共享了一致性维度，由于粒度不同，产生三种类型的事实表。
4.2.2.4.1 事务事实表
大多事实表都是面向事务的，粒度是每行对应一个事务，或者一行对应事务中的一个条目上。可以查询所有细节数据，就是容易会非常大。可汇总到集市去。
4.2.2.4.2 周期快照事实表
是按定义好的时间间隔保存业务过程信息，也就时间粒度变大，维度也随之会变少，但查询会快很多。
4.2.2.4.3 累积快照事实表
用于描述业务过程中某个不确定时间跨度里的活动（比如一次购物流程，从下单到给差评）。与上两种最大的不同是它的事实行是需要更新的，也会失去一些维度细节。一般情况前两种就足够用了。
4.2.2.5 有关维度的误区
将关注点集中到部门报表和分析结果上，而没有集中到度量过程上。四步曲的第一步就是确定业务过程。如：建立维度模型是为了提交一份具体的业务报表，维度模型是部门解决方案，需要重建星形模型或独立事实表才能合并新数据源。
l 在事实表中放置用于约束与分组操作的文字型属性（应在维度表里）
l 在维度表中为节省空间而不使用详细的描述属性（划不来，现在机器很强悍）
l 将系统与体系层次分解成多个维度。（比如把地区分成多个维不合适，不能省、市、县、村各来一个维度，应该是层级的而非独立）
l 忽视跟踪维度变化的需要（在变化维一节有说明）
l 使用原数据表主键做为维度表主键（应用代理键）
l 忽视事实表粒度的定义与使用（意思是辈分不能乱）
4.2.2.6 设计维度模型
识别数据源-》了解候选数据源-》数据探查和数据源的选定-》确立一致性维度-》确定事实-》出设计文档。
4.2.3 实体建模
利用面向对象的思想，将整个业务划分为一个个的实体，每个实体之间的关系以及针对这些关系 的说明就是建模要做的事。将业务过程分成实体、事件、说明。
l 实体：指领域模型中待定的概念主体，指发生业务关系的对象。
l 事件：指概念主体之间完成一次业务流程的过程，指特定业务过程。
l 说明：对实体和事件的说明，
实体建模法能轻松的实现业务模型的划分，但它只是一种客观世界的抽象，所以只能用于业务建模和领域建模阶段。
