数据仓库建模概念

1. 数据仓库建模概念

 总线矩阵是一个二维表格，每一行对应一个 业务线 ，每一列对应一个 维度 ，每一个交叉点对应了业务和维度的联系
   我们在业务分析时使用雪花模型，最终存储到数据仓库中的是星型模型。
   事实表由度量值和维度值组成，度量值反应了该业务过程涉及的数字指标，维度值反应了该业务过程的维度信息。
   原子粒度，聚集事实表。
   一定要从原子粒度开始设计。
   存储外键关联维度
   退化维度（DD, Degradation dimension）
   Operational Data Store，数据运营层。从其他业务系统抽取的数据，直接存储。
   Data Warehouse，数据仓库层，内部又划分为3层。
   维度表
   服务特定的应用，复用性不强，存储在响应速度较快的存储引擎。例如报表数据。

2. 如何建立和评估数据仓库逻辑模型

逻辑模型指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看，数据仓库的数据逻辑模型也许是整个项目最重要的方面，需要领域专家的参与。从内容上看，涉及的方面有确立主题域，粒度层次的划分，确定数据分割策略，关系模式的确定。 

    逻辑模型建设方法
    逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF,即 Third Normal Form)和星型模式 (Star-Schema)
    第三范式
    关系模式满足以下特征：
    1 每个属性的值唯一,不具有多义性;
    2. 每个非主属性必须完全依赖于整个主键,而非主键的一部分;
    3. 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去
    星型模型
    星型模式是一种多维的数据关系，它由一个事实表(Fact Table)和一组维表(Dimens ion Table)组成。每个维表都有一个维作为主键，所有这些维则组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实 (Fact)，它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。
    第三范式和星型模式在数据仓库中的应用
    大多数人在设计中央数据仓库的逻辑模型时，都按照第三范式来设计;而在进行物理实施时，则由于数据库引擎的限制，不得不对逻辑模型进行不规范处理 (De-Normalize)， 以提高系统的响应速度，这当然是以增加系统的复杂度、维护工作量、磁盘使用比率 (指原始数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。
    那么，在中央数据仓库中是否可以采用星型模式来进行模型设计呢?我们知道，星型模式中有一个事实表和一组维表，我们可以把事实看成是各个维交叉点上的值。
    星型模式之所以速度快，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。因此，在星型模式设计的数据仓库中，作报表的速度虽然很快，但由于存在大量的预处理，其建模过程相对来说就比较慢。当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。由于事实表的主键由所有维表的主键组成，这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。综合这些讨论，不难得出结论，星型模式比较适合于预先定义好的问题，如需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此，星型模式在一些要求大量报表的部门数据集市中有较多的应用。
    总之，上面讨论了数据仓库模型设计中常用的两种方法。对于部门数据集市，当数据量不大、报表较固定时可以采用星型模式;对于企业级数据仓库，考虑到系统的可扩展能力、投资成本和易于管理等多种因素，最好采用第三范式。
逻辑模型指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看，数据仓库的数据逻辑模型也许是整个项目最重要的方面，需要领域专家的参与。从内容上看，涉及的方面有确立主题域，粒度层次的划分，确定数据分割策略，关系模式的确定。 

 
    逻辑模型的质量标准
    对逻辑模型的评估，就是对逻辑模型质量的考察，什么是逻辑模型的质量呢？从狭义的概念说，逻辑模型是否正确表达了业务规则，也就是准确，但是随着人们对数据仓库认识的加深，质量的含义不断延伸,现在对模型质量要求不仅仅单纯指单纯的业务规则，还包括模型满足用户分析需求的程度，它是一个包含丰富内涵、具有多维因素的综合性概念。相应地逻辑模型质量概念的认识也从狭义向广义转变，准确性已不再是衡量唯一标准。评估逻辑模型一般包括如下方面的标准
    正确性
    逻辑模型的建设方法是正确的，遵循了从上到下和从下到上相结合的方法，选择了正确的模型表示方式，对实际业务采用正确的概化抽象。
    准确性（精度）
    指逻辑模型和实际业务即“真值”之间的差异程度。误差越小，准确性就越高。这里，所谓的“真值”是可知的，尽管逻辑模型经过了抽象，概化等方法总结共性，但是模型的具体化后，与“真值”是应当符合的。可以通过范围误差、计数误差、不回答率、加工整理差错、模型假设误差等影响准确性的各个因素，测算统计估算值的变动系数、标准差、均方差、曲线配合吻合度、假设检验、偏差等，修正逻辑模型将其的误差控制在一个可接受的置信区间内。
    适用性
    指收集的信息是否有用，是否符合用户的需求。它要求逻辑模型的粒度，分割方式符合用户的分析需求。
    可解释性
    是指在公布逻辑模型时，应同时公开逻辑模型的的补充解释信息或称为“元数据”，即关于模型数据的解释说明。内容包括所使用的建设方法，建设目标，以防止模型数据二义性导致错误解释和使用。
    完备性
    目前的业务需求和所用的业务规则完全包含在逻辑模型中。模型中不存在没有包含的需求业务对象（如实体，属性，以及之间的关系）
    一致性
    模型中的各个对象命名方式统一，有明确的命名规范。而且模型中各个相关对象的粒度一致，业务逻辑模型对象的划分标准应当统一。
    扩展性
    当新的业务产生时，仅仅是增加了相关逻辑模型对象的实例内容，不影响目前的逻辑模型，模型这些分类能够随统计分析需求的不同进行相应的调整，无需改变数据库结构，具有灵活的扩展性。仅在个别情况下，需要对逻辑模型的属性或者实体本身增加，支持分步骤的实施。
    可衔接性
    逻辑模型来自拥有行业经验的概念模型，里面凝聚了许多成功的经验，而且从规划上符合行业系统的长远发展，因此逻辑模型应当从概念模型上相对平滑的过度过来。此外，物理模型应当来自与逻辑模型，逻辑模型的建设应当具有一定的可操作性，便于向物理模型的转化。
    逻辑模型中常犯的错误：
    命名规范不统一
    对于汇总数据，低粒度数据或历史数据采用已定义的命名规范。
    粒度层次不统一
    有的具体，有的过于抽象
    不准确
    业务关系表示错
    不全面：
    一些属性外键标识没有主表
    无用关联关系多：
    模型中各种对象所表示的内容，应当与用户的业务分析需求密切相关。
    与行业通用模型移动的兼容性差：
    与行业通用模型存在较大的差异，不利于系统的将来发展符合信息发展的趋势。
    总结
    商业智能和数据仓库系统的建设作为一个渐进、迭代的过程，其发展趋势是从现有的初步应用如报表分析、数据集市，向深度和广度复杂分析和数据挖掘技术应用发展，其依赖的数据存储模型，包括逻辑模型和物理模型，也是一个不断发展，不断丰富完善的过程。

3. 数据仓库数据建模的几种思路

数据仓库数据建模的几种思路主要分为一下几种
1. 星型模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：a. 维表只和事实表关联，维表之间没有关联；b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c. 以事实表为核心，维表围绕核心呈星形分布；

2. 雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用

雪花模式
3．星座模式
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

星座模型

4. 数据仓库数据建模的几种思路

数据仓库接典型的两种数据仓库建模的理论是维度建模和基于主题域的实体关系建模，这两种方式分别以Kimball和Immon两位大师为代表。维度建模以数据分析需求为驱动，倡导总线架构：一致的事实和一致的维度，这种数据模型易于用户理解和数据分析操作。基于主题域的实体关系建模以源系统数据为驱动，整合企业的所有数据，站在企业级的高度对数据进行抽象，整合，采用3NF的实体关系理论建模，这种数据建模方式以更为抽象的方式尝试建立一个相对稳定的数据模型，并能描述企业级的数据关系。在工业界往往把两种方式结合起来运用数据仓库的不同数据层次结构中。
我们上周主要是针对采用基于主题域的实体关系建模中数据整合的方式进行较为深入的讨论，讨论了以下三种思路：
以属性聚集的方式同一主题域中不同实体的属性。比如对于会员、公司、客户等等实体对象我们都有地址属性信息、名称标识属性信息等等，这种思路就是把属性内聚性高的字段整合在一起，并把不同的属性打上类型标识以树表的形式存放。它的优点是：第一，模型稳定性好，外围系统变化了字段，只需要添加不同的类型，不需要进行表结构的变更；第二，减少大量冗余记历史数据。它的缺点是：第一，丢失了很多实体的属性标识信息，我们从模型上将看不到一个会员究竟有哪些地址属性，只能通过查询类型代码才能获取这些信息；第二，它极度的膨胀数据表的记录数，因为它采用竖表的形式存放；第三，应用起来很难，效率是一个大问题，因为我们往往要使用一个实体的多个字段，就会有很多join操作和竖转横的操作。第四：属性聚集也是一件比较难操作的过程，应为这是一个抽象的过程，对建模人员的业务背景知识和抽象能力都提出了很高的要求；第五：虽然减少了冗余的记历史数据，但是记历史的操作也较为复杂。
采用面向对象建模的方式，抽象不同实体的共同属性，然后再一步步采用继承、组合等面向对象的思想具体化实体。他的优点是模型模型概念比较清晰，缺点也是模型相对不是很稳定，整合后的数据的后续应该也面临重新组合的问题。
贴源的建模方式：
采用基本保持源系统的方式进行建模，重点放在数据的标准化，一致化，和数据业务意义的梳理。这种做法和我们目前数据仓库的做法比较类似。它具有实施比较容易，快速实现，前台可以直接使用数据；缺点是整合度不高，模型不稳定。
模型终究是为数据分析应用服务的，具体采用什么方式建模需要根据实际业务特点和源系统的特点决定。阿里巴巴的源系统具有变化快，数据分析应该变化快的特点，响应速度也要快的特点，而且我们要求不同系统之间整合的需求并不是很大，往往深度的数据整合带来的是应用上的不方便。因此，我个人觉得采用贴源的方式是当前更优的方案。

5. 数据仓库数据建模的几种思路

数据仓库接典型的两种数据仓库建模的理论是维度建模和基于主题域的实体关系建模，这两种方式分别以Kimball和Immon两位大师为代表。维度建模以数据分析需求为驱动，倡导总线架构：一致的事实和一致的维度，这种数据模型易于用户理解和数据分析操作。基于主题域的实体关系建模以源系统数据为驱动，整合企业的所有数据，站在企业级的高度对数据进行抽象，整合，采用3NF的实体关系理论建模，这种数据建模方式以更为抽象的方式尝试建立一个相对稳定的数据模型，并能描述企业级的数据关系。在工业界往往把两种方式结合起来运用数据仓库的不同数据层次结构中。
我们上周主要是针对采用基于主题域的实体关系建模中数据整合的方式进行较为深入的讨论，讨论了以下三种思路：
以属性聚集的方式同一主题域中不同实体的属性。比如对于会员、公司、客户等等实体对象我们都有地址属性信息、名称标识属性信息等等，这种思路就是把属性内聚性高的字段整合在一起，并把不同的属性打上类型标识以树表的形式存放。它的优点是：第一，模型稳定性好，外围系统变化了字段，只需要添加不同的类型，不需要进行表结构的变更；第二，减少大量冗余记历史数据。它的缺点是：第一，丢失了很多实体的属性标识信息，我们从模型上将看不到一个会员究竟有哪些地址属性，只能通过查询类型代码才能获取这些信息；第二，它极度的膨胀数据表的记录数，因为它采用竖表的形式存放；第三，应用起来很难，效率是一个大问题，因为我们往往要使用一个实体的多个字段，就会有很多join操作和竖转横的操作。第四：属性聚集也是一件比较难操作的过程，应为这是一个抽象的过程，对建模人员的业务背景知识和抽象能力都提出了很高的要求；第五：虽然减少了冗余的记历史数据，但是记历史的操作也较为复杂。
采用面向对象建模的方式，抽象不同实体的共同属性，然后再一步步采用继承、组合等面向对象的思想具体化实体。他的优点是模型模型概念比较清晰，缺点也是模型相对不是很稳定，整合后的数据的后续应该也面临重新组合的问题。
贴源的建模方式：
采用基本保持源系统的方式进行建模，重点放在数据的标准化，一致化，和数据业务意义的梳理。这种做法和我们目前数据仓库的做法比较类似。它具有实施比较容易，快速实现，前台可以直接使用数据；缺点是整合度不高，模型不稳定。
模型终究是为数据分析应用服务的，具体采用什么方式建模需要根据实际业务特点和源系统的特点决定。阿里巴巴的源系统具有变化快，数据分析应该变化快的特点，响应速度也要快的特点，而且我们要求不同系统之间整合的需求并不是很大，往往深度的数据整合带来的是应用上的不方便。因此，我个人觉得采用贴源的方式是当前更优的方案。

6. 数据仓库的模型有哪些？

1. 星型模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：a. 维表只和事实表关联，维表之间没有关联；b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c. 以事实表为核心，维表围绕核心呈星形分布；

2. 雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用

雪花模式
3．星座模式
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

星座模型

7. 数据仓库有哪些模型？举例说明

1、星型模型
星型模型是一种由一点向外辐射的建模范例，中间有一单一对象沿半径向外连接到多个对象。星型模型反映了最终用户对商务查询的看法:销售事实、赔偿、付款和货物的托运都用一维或多维描述(按月、产品、地理位置)。星型模型中心的对象称为“事实表”，与之相连的对象称为“维表”。对事实表的查询就是获取指向维表的指针表，当对事实表的查询与对维表的查询结合在一起时，就可以检索大量的信息。通过联合，维表可以对查找标准细剖和聚集。
2、雪花模型
雪花模型是对星型模型的扩展，每一个点都沿半径向外连接到多个点.雪花模型对星型的维表进一步标准化，它的优点是通过最大限度的减少数据存储量以及把较小的标准化表(而不是大的非标准化表)联合在一起来改善查询性能。化及维的较低的粒度，雪花模型增加了应用程序的灵活性。
3、混合模型
混合模型是星型模型和雪花模型的一种折衷模式，其中星型模型由事实表和标准化的维表组成，雪花模型的所有维表都进行了标准化。在混合模型中，只有最大的维表才进行标准化，这些表一般包含一列列完全标准化的(重复的)数据。

8. 数据仓库的建模划分

数据仓库的数据建模大致分为四个阶段：1.业务建模，这部分建模工作，主要包含以下几个部分：  划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。  深入了解各个业务部门的内具体业务流程并将其程序化。  提出修改和改进业务部门工作流程的方法并程序化。  数据建模的范围界定，整个数据仓库项目的目标和阶段划分。  2.领域概念建模，这部分得建模工作，主要包含以下几个部分：  抽取关键业务概念，并将之抽象化。  将业务概念分组，按照业务主线聚合类似的分组概念。  细化分组概念，理清分组概念内的业务流程并抽象化。  理清分组概念之间的关联，形成完整的领域概念模型。  3.逻辑建模，这部分的建模工作，主要包含以下几个部分：  业务概念实体化，并考虑其具体的属性  事件实体化，并考虑其属性内容  说明实体化，并考虑其属性内容  4.物理建模，这部分得建模工作，主要包含以下几个部分：  针对特定物理化平台，做出相应的技术调整  针对模型的性能考虑，对特定平台作出相应的调整  针对管理的需要，结合特定的平台，做出相应的调整  生成最后的执行脚本，并完善之。