下载文档原格式
数仓⼯具介绍随着数据收集⼿段不断丰富，⾏业数据⼤量积累，数据规模已增长到了传统软件⾏业⽆法承载的海量数据（百TB、PB、EB）级别。
1、种类（1）Hive是基于的⼀个⼯具，⽤来进⾏数据提取、转化、加载，这是⼀种可以存储、查询和分析存储在Hadoop中的⼤规模数据的机制。
hive数据仓库⼯具能将结构化的数据⽂件映射为⼀张数据库表，并提供查询功能，能将转变成任务来执⾏。
Hive的优点是学习成本低，可以通过类似SQL语句实现快速MapReduce统计，使MapReduce变得更加简单，⽽不必开发专门的MapReduce应⽤程序。
hive是⼗分适合数据仓库的统计分析和注册表⽂件。
（2）⼤数据计算服务（MaxCompute，原名ODPS）是⼀种快速、完全托管的EB级数据仓库解决⽅案，阿⾥云产品。
MaxCompute致⼒于批量结构化数据的存储和计算，提供海量数据仓库的解决⽅案及分析建模服务。
由于单台服务器的处理能⼒有限，海量数据的分析需要分布式的计算模型。
分布式的计算模型对数据分析⼈员要求较⾼且不易维护。
数据分析⼈员不仅需要了解业务需求，同时还需要熟悉底层分布式计算模型。
MaxCompute为您提供完善的数据导⼊⽅案以及多种经典的分布式计算模型，您可以不必关⼼分布式计算和维护细节，便可轻松完成⼤数据分析。
2、计算模型（1）SQL：传统的数据库软件操作功能。
（2）：MaxCompute MapReduce是MaxCompute提供的Java MapReduce编程模型，它可以简化开发流程，更为⾼效。
使⽤MaxCompute MapReduce，需要对分布式计算概念有基本了解，并有相对应的编程经验。
MaxCompute MapReduce为您提供Java编程接⼝。
（3）：MaxCompute提供的Graph功能是⼀套⾯向迭代的图计算处理框架。
图计算作业使⽤图进⾏建模，图由点（Vertex）和边（Edge）组成，点和边包含权值（Value）。
数据仓库工具箱学习笔记数据仓库必备要求：1、数据仓库必须使组织的信息容易存取；2、数据仓库必须一致地展示组织信息；3、数据仓库必须具有广泛的适用性和容易修改；4、数据仓库必须发挥安全堡垒作用保护信息资产；5、数据仓库必须在推进决策上发挥最基本的作用；6、数据仓库被业务群体所接受必须是被认定为成功的；数据仓库是信息技术与业务知识相结合的产物。
数据仓库管理员职责：1、在业务范围、工作职责和计算机性能等方面多为用户考虑；2；确定业务用户在数据仓库帮助下想要做出什么样的决策；3、标定那些使用数据仓库进行效能高而作用大的决策制定的最佳用户；4、寻找潜在的新用户并让他们了解数据仓库；5、选取那些从机构海量数据中挑出的最有效和最富有实际意义的数据子集在数据仓库中展示；6、适应用户对相关处理概况的感性认识，将用户接口和应用做得简单并且模板驱动；7、跨部门一致地标注数据，确保数据是准确的、可信的；8、持续不断地对数据的准确性和提交报告的内容进行监控；9、搜罗新的数据来源，持续不断地调整数据仓库以适应数据概况修改、需求支持和业务优先权的调整等方面的需要；10、抽取一部分在使用数据仓库进行业务决策方面具有良好声誉的实现，并用这些成功的例子就人员、软件和硬件配备与选购是否合理做出评判；11、按通行的方式发布数据；12、维持业务用户的信任；13、让业务用户，经理和老板都感到满意；数据仓库组成：操作型源系统，数据聚集环节，数据展示环节，数据存取工具应该避免的常见失误：1、过多地将心思放在技术和数据上，而不关注业务的要求和目标；2、未能实现或者再现数据仓库主管所具备的看起来有影响、易访问又合乎情理的管理功能梦想而耿耿于怀；3、扭住制定一个庞大的多年工程计划不放，而不是去追求一个更易于处理的可能，也是更急迫的可以进行迭代开发的方案；4、将精力全部投入到构造规范化数据结构中去，而在建造一个基于维度模型的可行的展示环节时，却已经用光了给定的投入；5、把注意力放在了后台的作业性能和容易开发上，而不是放在前台的查询性能和容易使用上；6、吧展示环节假定为可查询的数据做得过于复杂，应该；去建立一个在突出简明性的需要方面更为人们所欣赏的解决方案；7、在孤立应用的基础上建立维度模型，没有考虑采用共享的一致维度将这些模型捆绑在一起的数据体系结构；8、仅仅将总结性的数据加入到展示环节的维度中；9、吧业务、业务需求与分析内容以及基本数据与支持技术等都看成是静态的；10、忽视了数据仓库的成功直接系于用户的接受程度这样的认识；数据仓库建设流程：。
1 LSM Tree熟悉读写流程中的写流程，再了解lsm tree就会变得容易很多了。
Log-Structured Merge-Tree中文翻译是日志结构合并树。
那我们就从日志结构与合并树这两个方面来讲。
1.1 日志结构我们知道磁盘随机读写性能是比顺序读写慢至少3个数量级的，日志的特点是它是顺序追加写的，可以保证非常好的写操作性能，但是从日志文件中读一些数据将会比写操作需要更多的时间，需要倒序扫描，直接找到所需的内容。
因此日志适用的场景非常有限：1. 数据是被整体访问，像大部分数据库的WAL(write-ahead log)、HDFS2. 记录了文件明确的偏移量，比如Kafka为了为更复杂的读场景（比如按key或者range）提供高效的性能，人们发明了几种方式：二分查找: 将文件数据有序保存，使用二分查找来完成特定key的查找。
哈希：用哈希将数据分割为不同的bucketB+树：使用B+树或者ISAM 等方法，可以减少外部文件的读取外部文件：将数据保存为日志，并创建一个hash或者查找树映射相应的文件。
所有的方法都可以有效的提高了读操作的性能（最少提供了O(log(n)) )，但是，却丢失了日志文件超好的写性能。
上面这些方法，都强加了总体的结构信息在数据上，数据被按照特定的方式放置，所以可以很快的找到特定的数据，但是却对写操作不友善，让写操作性能下降。
更糟糕的是，当我们需要更新hash或者B+树的结构时，需要同时更新文件系统中特定的部分，这就是上面说的比较慢的随机读写操作。
这种随机的操作要尽量减少。
此时，LSM 被发明了，LSM 使用一种不同于上述四种的方法，保持了日志文件写性能，以及微小的读操作性能损失。
本质上就是通过把随机写的数据写到内存，然后定期flush到磁盘，对于磁盘来说，让所有的操作顺序化，而不是随机读写。
1.2 合并树LSM树原理把一棵大树拆分成N棵小树，它首先写入内存中即是小树，随着小树越来越大，会flush到磁盘中，磁盘中的树定期可以做merge操作，合并成一棵大树，以优化读性能。
提交事实表事实表装有企业的度量数据。
事实表与度量的关系非常简单。
如果存在一个度量，则它可以被模型化为事实表的行。
如果事实表的行存在，则它就是一个度量。
那么什么是度量呢？一个关于度量通用的定义是：通过工具或比例等级可以测量观察的数量值。
在维度建模时，我们有意识地围绕企业的数字度量创建我们的数据库。
事实表包含度量，维表包含关于度量的上下文。
这种关于事物的简单视图被一次又一次的证明是最终用户直观理解我们的数据仓库的方式。
这也是我们为什么通过维度模型打包和提交数据仓库内容的原因。
流程检查规划与设计：需求/现状 -> 架构 -> 实现 -> 测试/发布数据流：抽取 -> 清洗 -> 规格化 -> 提交第5章描述了如何创建数据仓库的维表。
也许从维表开始介绍会觉得很奇怪，因为度量以及事实表才是最终用户真正想要看的内容，但是维表是事实表数据的入口，事实只有通过维度解释才会变得有意义。
由于第5章详细完整地描述了维，因此本章的内容多少会变得简单一些。
事实表基本结构每一个事实表通过表的粒度来定义。
事实表的粒度是事件度量的定义。
设计者必须至始至终按照度量如何在现实世界中理解来规定事实表的粒度。
例如，图6.1中的事实表的粒度为指定的零售发票上的单个货品。
我们并不从定义这些字段的粒度开始，而是将粒度表示成为维度的外键和事实表的某些字段。
粒度定义必须按照现实的，物理的度量意义来定义，然后才考虑维度和事实表中的其他字段等其他因素。
所有的事实表包含了一组关联到维表的外键，而这些维表提供了事实表度量的上下文。
大多数的事实表还包括了一个或者多个数值型的度量字段，我们称之为事实（Fact）。
请看图6.1。
某些事实表中还包还了一个或者多个特殊的近似维度字段，他们是在第5章中介绍的退化维度(Degenerate Dimensions)。
退化维度存在于事实表，但是他们不是外键，不关联任何真正的维表。
我们在图6.1中使用符号DD来标识退化维度。
一. 课前提示1. 今日任务2. 今日目标2.1了解和熟悉部分2.2掌握部分二. 正课内容1. Sqoop简介以及使用1.1 产生背景1.2 Sqoop是什么Sqoop是一个用于Hadoop和结构化数据存储（如关系型数据库）之间进行高效传输大批量数据的工具。
它包括以下两个方面：可以使用Sqoop将数据从关系型数据库管理系统(如MySQL)导入到Hadoop系统(如HDFS、Hive、HBase)中将数据从Hadoop系统中抽取并导出到关系型数据库(如MySQL)常见数据库开源工具：1.sqoop2.datax3.kettle4.cannal1.3 底层实现原理Sqoop的核心设计思想是利用MapReduce加快数据传输速度。
也就是说Sqoop的导入和导出功能是通过基于Map Task（只有map）的MapReduce作业实现的。
所以它是一种批处理方式进行数据传输，难以实现实时的数据进行导入和导出。
官网介绍：Apache Sqoop(TM) is a tool designed for efficiently transferring bulkdata between Apache Hadoop and structured datastores such as relational databases. Sqoop结构图:1.4 特点优点：它可以将跨平台的数据进行整合。
缺点：它不是很灵活。
主要执行操作tar -zxvf /opt/soft/sqoop... -C /opt/app/sqoop... vi /etc/profilemv ./conf/sqoop-env-template.sh ./conf/sqoop-env.shvi ./conf/sqoop-env.shexportHADOOP_COMMON_HOME =/usr/local/hadoop-2.7.1/ export HADOOP_MAPRED_HOME =/usr/local/hadoop-2.7.1/export HIVE_HOME =/usr/local/hive-1.2.1/export ZOOCFGDIR =/usr/local/zookeeper-3.4.7/cp /home/mysql-connector-java-5.1.18.jar ./lib/sqoop 的重要的几个关键词==import== ： 从关系型数据库到hadoop==export== ： 从hadoop 到关系型数据库。
在数据仓库的开发过程中，需要熟悉大量的概念以及相关工具的使用，还需要了解宏观上的各种开发流程，串联起来完成最终的数据仓库项目的开发，本篇介绍一些准备工作，包括涉及到的工具介绍，以及开发过程的描述，记录学习研究的印记，并和大家讨论研究存在的相关问题。
数据仓库的开发，是完全独立于OLTP系统的，也就是独立于当前各种应用的业务系统而作的分析项目，因此要包含从数据的迁移（提取）、变换、清洗、加载等ETL操作，其中可以分为这么几个数据层。
源数据层客户的各种业务系统中的数据，如包括企业、车辆和司机信息系统、企业录入数据和及营运等数据，里面存放了大量的事务数据。
ODS数据层数据库用户ODS数据层主要管理把业务数据层的数据存储到ODS数据层，它的数据表主要就是来源于业务数据表，通过一些存储过程把业务数据表结构改变成基层的数据仓库的表结构。
DW数据层数据库用户DW主要管理把ODS数据层的数据存储到DW数据层，它的数据表主要就是来源于ODS数据表，通过一些存储过程把ODS数据表结构改变成项目主题数据仓库的表结构。
DW数据层还管理一些对存储过程的记录表，方便数据仓库的维护和管理。
ODS是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。
常常被作为数据仓库的过渡，也是数据仓库项目的可选项之一。
因此操作数据存储（ODS）是用于支持企业日常的全局应用的数据集合，ODS的数据具有面向主题、集成的、可变的和数据是当前的或是接近当前的4个基本特征。
同样也可以看出ODS是介于DB和DW 之间的一种数据存储技术，和原来面向应用的分散的DB相比，ODS中的数据组织方式和数据仓库（DW）一样也是面向主题的和集成的，所以对进入ODS 的数据也象进入数据仓库的数据一样进行集成处理。
另外ODS只是存放当前或接近当前的数据，如果需要的话还可以对ODS中的数据进行增、删和更新等操作，虽然DW中的数据也是面向主题和集成的，但这些数据一般不进行修改，所以ODS和DW的区别主要体现数据的可变性、当前性、稳定性、汇总度上。
关于数据仓库的书
在构建或理解数据仓库时，一本好的参考书籍可以为你提供深入、全面的知识。
以下是关于数据仓库的几本经典书籍，每本书都有其独特的观点和深度，有助于你深化对数据仓库的理解和实践。
1、《数据仓库工具箱：维度建模的完全指南》
这本书是数据仓库领域的经典之作，详细介绍了维度建模的基本概念、方法和最佳实践。
它提供了大量的实用案例和练习，使读者能够全面掌握数据仓库设计和构建的技能。
2、《数据仓库原理与实践》
这本书从数据仓库的基本概念讲起，深入探讨了数据仓库的架构、ETL 过程、OLAP 技术等方面的内容。
它不仅涵盖了数据仓库的基础知识，还提供了许多实用的开发工具和技巧。
3、《大数据之路：构建可扩展、可靠的数据仓库》
随着大数据技术的普及，如何构建可扩展、可靠的数据仓库成为了一个重要的问题。
这本书介绍了在大数据环境下，如何设计、构建和管理数据仓库，同时还涉及到了数据清洗、数据安全等方面的内容。
4、《数据仓库与数据挖掘教程》
这本书将数据仓库和数据挖掘两个领域的内容结合起来，系统地介绍了数据仓库和数据挖掘的基本概念、方法和技术。
它还包括了一些实用的案例和实验，可以帮助读者更好地掌握相关技能。
5、《数据仓库设计：最佳实践》
这本书详细介绍了数据仓库设计的最佳实践，包括如何设计高效的数据库结构、如何优化查询性能、如何保证数据质量等方面的内容。
它还提供了一些实用的工具和技巧，可以帮助读者在实际项目中更好地应用数据仓库技术。
这些书籍各有特色，但都是数据仓库领域的经典之作。
如果你希望深入了解数据仓库的各个方面，这些书籍都是非常值得一读的。
数据仓库工具箱_读书笔记《数据仓库工具箱—维度建模的完全指南》是数据仓库建模方面的经典著作，1996年第一版出版被认为是数据仓库方面具有里程碑意义的事件。
作者kimballl 是数据仓库方面的权威，他将多年的数据仓库建模实战经验、技巧融入本书。
他提出的许多维度建模概念被广泛应用于数据仓库的设计和开发中。
2002年本书出版了第二版。
这是一部非常好的数据仓库建模的书，前后完整的读了三遍，受益匪浅。
以下笔记将本按四个部分组织:一、数据仓库体系结构和建模过程、技巧。
二、维度表建模技术。
三、事实表建模技术。
四、行业建模经验。
一、数据仓库体系结构和建模过程、技巧关键点:数据仓库体系结构、维度建模的四个步骤、数据仓库总线结构、一致性维度。
1、对于数据仓库来说，业务需求是第一位的。
2、数据仓库的目标:(1)、随心所欲的访问数据。
直观、明显、简单、易用、切割、合并、下钻、上卷。
(2)、一致的展现数据(相对于原来从多个系统中出来的报表不一致)。
(3)、适应性、扩展性、可维护性。
(4)、为领导决策提供支持。
3、数据仓库的组成。
源数据-->数据准备区-->数据仓库(维度建模)-->数-->展现。
其中原系统到数据准备区属于ETL过程。
数据仓库据聚集区(OLAP) 和数据聚集区本书称为数据展示。
展现本书称为数据存取工具。
4、数据仓库应特别注意的几点特点:(1)、数据应该以维度的形式进行展示、存储和访问。
(2)、数据仓库中必须包含详细的原子数据。
(3)、必须采用共同的维度和事实表来建模。
5、数据仓库采用使用维度建模的好处:易理解、查询的高性能、修改的灵活性和可扩充性。
6、维度建模的扩展性。
表现在三个方面:(1)、在现有的事实表中增加维度。
(2)、在事实表中增加事实。
(3)、在维度表中增加属性。
(第一章)7、维度模型设计的四个步骤。
(1)、选取业务(主题)。
(2)、定于业务处理的粒度。
(3)、选择维度。
(4)、选择事实。
8、应优先为模型选择有原子性的信息，因为原子性的数据提供了最大限度的灵活性，可以接受任何可能形式的约束。
(第二章)9、数据仓库总线结构。
实际上是一种增量建模方式，通过一致性维度来集成数据中心。
数据总线矩阵:业务处理、公共维度。
一级数据中心:衍生于单个基本源系统的数据中心，建议从一级数据中心开始建模，因为导致失败的主要风险是ETL。
合并数据中心:合并多个位于不同源系统的一级数据中心。
(第三章)10、维度建模复查。
考虑的问题:粒度，日期维度，退化维度，维度属性采用名称而不是编码，代理关键字，维度的多少。
11、维度建模常犯的错误:(1)、舍弃一致性维度和一致性事实表。
(2)、事实表的粒度不采用原子型。
(3)、基于报表来设计维度表。
(4)、不使用代理关键字。
(5)、忽视维度的变化的需求。
(6)、将体系与体系层次分解成多个维度。
(7)、在维度表中为节省空间而限制使用详细的描述属性。
(8)、在事实表中放置用于约束与分组操作的文本属性。
(第十五章)12、数据仓库成功的五个前提:(1)、拥有精明、强干的业务用户。
用户应该对数据仓库具有独特的见解，坚信数据仓库项目具有实现的价值。
(2)、机构必须存在建立数据仓库坚实而有说服力的业务动机。
(3)、数据仓库的可用性。
(4)、业务用户与IT人员之间的沟通。
(5)、业务分析人员的分析文化，是基于图形、数据还是直觉、传闻和一时冲动。
(第十六章) 二、维度表建模技巧关键点:退化维度、代理关键字、一致性维度、渐变维度、角色模仿、杂项维度、微型维度、深度可变的层次建模方法、审计维度、多值维度解决办法、异构产品解决办法。
1、维度表倾向于将行数做得相当少，而将列数做的特别大。
数据仓库的能力直接与维度表的属性的质量和深度成正比。
、维度的属性采用文字而不是编码。
23、维度表通常是不规范的，几乎总是用空间换取简明性和可访问性。
(第一章)4、日期维度，应包含星期、周末指示符、月末指示符、节假日指示符、重大事件、财政时间等。
5、如果需要处理一天中不同时间，则增加一个时间维度。
6、一个维度包含多个体系(层次)，每个层次包含若干级别。
7、退化维度。
一方面可以通过退化维度对数据进行分组，另一方面可以使用退化维度关联到源数据上，有利于ETL更新及排错。
8、一般情况维度个数应该控制在15个以内，唯独过多影响查询性能和磁盘空间。
一些小维度可以进行组合，这取决于具体的业务。
9、代理关键字。
使用代理关键字的优点:能实现渐变维度;获得性能上的优势，节省事实表空间;可以记录没有操作源码的数据(ETL过程生成);处理关键字段的修改、删除等。
(第二章)10、一致性维度。
具有一致性的维度关键字，以致的属性名称，以致的属性定义，一致的属性值。
一致性维度对于设计可以进行集成的数据中心来说，具有绝对的决定性作用。
(第三章)11、渐变维度。
渐变维度的处理办法。
类型1:改写属性值;类型2:添加维度行;类型3:添加维度列。
第二种类型最常用。
12、快变维度的处理办法:将这些迅速变化的属性分裂成一个或者多个单独的维度。
(第四章)13、维度的角色模仿。
在同一个维度表上通过视图的形式建立多个维度。
在实际运用中，很多OLAP工具都支持在同一个维度表上建多个维度，而并不需要建立视图。
14、实体之间存在固定的，不随时间变化的，强烈相关的关系时，显然应该将它们当作单一维度进行建模。
15、杂项维度。
将标志与指标符从设计中剥离出来，将其封装成一个或者多个杂项维度。
(第五章)16、将聚集事实放入维度表的优缺点。
优点:查询时可以对聚集属性进行约束。
缺点:ETL过程变麻烦了。
17、雪花模型的使用场合:粒度悬殊，节省空间(属性众多)。
18、宽度变化的属性集的处理办法:拆分成两个维度。
Oracle数据库不存在这个问题。
19、采用类型2的方式处理维度慢性变化时，应该注意避免计数过度。
20、深化不变的体系结构(层次、级别)。
一个层次建立单独的字段。
如果某一个级别没有值，就应该用较低级别的属性覆盖该值。
21、深度可变的体系结构。
使用桥接标来解决。
父到子的每一条路径都包含一行记录，到其自身长度为0的路径包含一行。
实际上是把循环递归的过程通过表数据的形式实现。
大量olap工具以提供了对小于64000个成员的中小尺寸维度中这些体系进行导航操作得更加强劲的内置功能支持。
(第六章)22、依照十五描述内容在每行加入生效和截止日期标记，可以将类型2渐变维度设计方案修改为允许自然的对维度在时间上进行非常精细的切割。
23、审计维度。
源系统的情况;抽取软件的版本;抽取记录数;开始时间;完成时间等。
24、维度的属性数量不确定时，使用关键词支架维度。
相当于将横表设计成纵表。
使用union和intersect命令解决SQL跨行约束问题。
(第八章)25、维度类型:因果维度、多日期或时间标记维度、退化维度、角色模仿维度、状态维度、审计维度、杂项维度。
26、多值维度。
概念:一个账户拥有多个客户，一个客户也可能拥有多个账户。
解决办法:桥接表。
27、异构产品方案。
概念:每种产品类型都有大量的专用属性与度量事实不能为其他产品所用。
解决方案:核心维度，定制维度，使用相同的代理关键字。
采用支架结构。
(第九章)28、日期维度。
国别历法的处理办法，做成日期维度的支架。
29、多个时区日期的处理办法，增加维度。
(第十章)30、多值维度解决方案。
所谓多值维度是指一个事实表对应多个值的维度，比如，住院结算事实表拥有多个疾病。
通过组桥表来实现。
组桥表可以增加起止时间来满足住院渐变维度。
可以增加加权因子来实现财务报表关于疾病的分类统计。
31、稀疏事实表的解决方案。
事实维度表。
实际上是纵表和横表的设计思想。
优点:灵活、结构简单、节省空间。
缺点:生成查询、报表复杂、行间计算困难。
32、迟到维度行的处理办法。
所谓迟到维度是指某项属性到当前时间才知道其以前的值。
通过渐变维度(类型2)的方法处理，在维度表中增加记录并修改其他型的起止时间，在事实表中修改该维度的代理关键字。
(第十三章)三、事实表建模技术1、事实表中的事实分为三种类型:可加性事实，半可加性事实，非可加性事实。
2、事实表的三种粒度:事务，周期快照，累计快照。
3、事实表倾向于具有更多的行和更少的列。
4、事实表的主键应采用复合主键，引入唯一的rowid关键字作为主键字并无什么优点可言。
(第一章)5、明显属于不同粒度的事实必须放在单独的事实表中。
6、将可计算得值作为事实的原因:消除用户出错的可能性，一致的引用它。
例如，利润=销售额-成本额，将利润作为一个事实而不是通过展现工具进行计算得到。
7、非可加性的数据项尽量不要放到事实表中。
例如，毛利润率是非可加性数据，不应该保存在事实表中，应保存分子和分母，再通过前端展现工具进行计算得到。
8、非事实型事实表。
解答什么促销产品没有卖出去的问题。
建立一张非事实型事实表，促销产品(周期快照)中每个商场的每隔促销产品每天创建一行。
再关联销售事实表来解决什么产品没有卖出去这个问题。
9、事实表的粒度很关键，决定了维度模型的扩展性。
过早汇总或者聚集处理必然限制对维度的增补。
10、半可加性事实。
对特定的维度具有可加性，对其他维度不具有可加性。
11、周期快照事实表是最常见的库存设计方案。
12、一致性事实。
一致的事实定义，一致的测量单位。
(第三章)13、使用单个事实表(通过增加事务类型维度)还是多个事实表的选择:(1)、业务需求(目标是降低复杂度，用最有效的形式将数据展示给用户)。
(2)、业务处理的关联性。
(3)、源系统。
(4)、维度是否完全一致。
(第四章)14、事实表的规范化。
纵表和横表的设计方式。
优缺点。
事实设置显得比较稀疏并且不在事实之间运算的情形是有用的。
15、不同粒度事实的处理办法。
例如，订货系统中的订货分列项事实表(基于产品)与装运费(基于订单)。
两种处理方式:(1)、分配到细节层次(装运费à产品)。
(2)、建立两个事实表。
优先采用第一种方式。
16、累计快照。
采用对整个订单处理流程的分析感性趣，他们想了解产品的移动速度，累计快照很好的体现这种业务情景。
适用:具有明确起止时间的短期处理应用。
17、多个计量单位的处理办法。
将转移因子写入事实表。
18、三种事实粒度的比较:(第五章)时间段粒度加载更新日期维度事实每个事务事务活事务时间点插入不事务日期一行动周期时间段终间隔事规律间隔每段一行插入不快照止日期务累计不确定跨度，每个生命插入行为发生关键环节生命周快照一般短期期一行更新时更新多日期期性能19、至今为止事实:应该计算出来，而不是保存在事实表中。
数字型事实必须与粒度保持一致。
20、事实的变化通过增加一行冲减记录，而不是通过修改原事实数据。
21、事实的自由分段。
通过分段定义表连接到事实表上，来灵活划分和定义分段。
