《商业智能：方法与应用》课件第3章 数据仓库.pptx

1、3.1 数据仓库相关概念3.2 数据仓库设计3.3 ETL的过程设计目 录O N T E N T S数据仓库的定义及特点数据集市、元数据管理和数据质量管理数据仓库的体系结构逻辑模型设计概念模型设计物理模型设计数据抽取设计数据清洗设计数据加载设计3.1 数据仓库相关概念数据仓库的定义及特点数据集市、元数据管理和数据质量管理数据仓库的体系结构3.1.1 数据仓库的定义及特点两大类 数据处理系统即联机事务处理，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改，是数据库中最基础的操作。缺点：只是针对企业日常的事务进行处理，而并不具备对存储数据进行分析的功能，更无法向用户提供决策支持

2、。因此，另一类数据处理系统分析型处理则针对操作型处理系统的短板应运而生。分析型a.操作型处理：应 运 而 生操作型3.1.1 数据仓库的定义及特点两大类 数据处理系统主要功能是综合某些主题的历史数据进行多维度、全面的分析，用以支持管理决策。优点：包含操作型处理的基础功能，并能够针对主题性的数据进行分析，通过将历史数据进行整合体现数据的完整性；同时在数据的抽取过程中能够保证数据的准确性，十分契合企业以及用户对数据分析的需要。操作型分析型b.分析型处理：应 运 而 生3.1.1 数据仓库的定义及特点操作型处理分析型处理性 能需对用户的查询、修改等指令进行及时反应，在企业日常事务较多时，需进行频繁的

3、数据处理，并在短时间内展示处理结果，要求其系统性能较高。不涉及日常频繁的事务处理，因此在系统性能上并不需要即时反馈的高性能处理。集 成 性仅限于日常事务的数据操作，其数据源也只限于企业日常的数据，通常不需要跨部门、跨系统的数据集成。将各类数据进行整合以达到数据的全面分析，相应的数据抽取、清洗、加载过程技术保证了分析型处理系统具备较好的数据集成性，能够将长期的、不同的数据进行集成分析。数 据 冗 余需频繁响应用户的操作，所以在数据存储中数据保持着很高的实时性，即用户频繁的查询、修改使得数据更新频繁，因此要求数据符合关系型数据库范式要求，并且数据冗余要少。需将长期的历史数据进行存储以供查询、分析、

4、决策，但历史数据几乎不会修改，因此可以具有一定的数据冗余以提高查询效率。3.1.1 数据仓库的定义及特点分析型系统操作型系统适合使用数据仓库技术来实现在从数据的集成到用户决策的制定过程中涉及的功能较多，因此数据综合性较高，传统的数据库技术并不完全满足这种技术要求。适合使用数据库技术来实现针对企业日常事务进行一些重复、频繁的操作，通常设计目标是大量的数据维护和较为简单的查询统计功能。数据库数据仓库作为数据库的一个分支，数据仓库在一定程度上相比于数据库针对数据信息的分析处理以及决策有更好的适用性，从数据库到数据仓库的细化，也是对数据获取并正确合理分析的必然要求。主要区别3.1.1 数据仓库的定义及

5、特点定义数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，并应用于支持管理决策。本质特点作用通过对数据分析面向主题：指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。“集成”：指数据仓库中的数据是来源于不同结构的数据源，从不同的数据源中进行数据的抽取，经过一系列加工后最终加载到数据仓库中。数据“历史”：指某个数据进入数据仓库以后，一般情况下将被长期存储，在较长的时间段内不进行改动数据的操作，即数据仓库内的信息并不仅仅反映企业当前的状态，而且记录了从过去某一时点到当前各个阶段的信息，能够随时反映历史数据信息。3.1.1 数据仓库的定义及特

6、点效率高数据仓库对数据分析的粒度非常细化，因此对分析效率的要求也随之增加。由于企业的数据量往往是庞大的，用户希望得到及时的分析结果，如果数据仓库效率不达标，分析结果出现延迟，这对于企业来说影响是非常大的，所以数据仓库要求效率一定要足够高。数据准确可靠数据仓库在抽取数据时，由于数据源存在异构、数据正确性、完整性等问题，数据的准确与否会直接影响到决策的质量。因此，在进入数据仓库前需要经过一系列的数据加工，即数据抽取、清洗、载入。扩展性高数据仓库体系结构一般设计得较为复杂，这是因为企业数据的存储、获取以及分析是一个长期持续存在的需求，数据仓库应该保持相应的稳定运行以及在该时间段内能够实现功能拓展的目

7、标，避免因重建数据仓库而带来的影响。数据仓库的特点010203数据集市数据质量管理元数据指数据源经过相应的处理后进入到数据仓库，按照特定的要求形成的具有主题性的数据集合。也叫做解释数据、数据字典，即是用来描述数据的数据。从数据的获取、存储、维护、应用等阶段对可能产生的数据质量问题进行识别、度量、监控以及预警等一系列管理措施，并通过改善和提高企业的管理水平使数据质量更加科学有效。3.1.2 数据集市、元数据管理和数据质量管理3.1.2 数据集市、元数据管理和数据质量管理特点数据集市规模小、主题性高、响应速度快，在数据质量、数据分析等内容中更具有专业性。作用能够存储用户需要的数据，并且能够针对用户

8、的操作快速响应。可以解决由于不同的数据需要而访问数据仓库所造成的效率低、访问量大等问题。3.1.2 数据集市、元数据管理和数据质量管理种类元数据a.技术元数据：存储数据仓库系统技术的数据。b.业务元数据：对业务数据进行解释的数据。作用能展现数据仓库中数据之间内在信息和相互关系，并进行详细的解释说明，使用户能清楚的了解数据间的关系。可以避免在数据仓库构建初期由于过多的数据集市而带来的问题。3.1.2 数据集市、元数据管理和数据质量管理步骤数据质量管理数据分析、数据评估、数据清洗、数据监控以及错误预警等。评估的衡量维度通常数据质量评估和管理评估通过以下几个维度来衡量：完整性、规范性、一致性、准确性

9、、唯一性、关联性。3.1.3 数据仓库的体系结构数据源作为数据仓库开展一系列数据处理活动的必要条件，数据源是整个数据仓库系统最基本、最重要的部分。对于数据分析、决策支持功能来说，数据源可以分为内部数据和外部信息。数据的存储与管理源数据进入到数据仓库后，按照面向主题的特性在数据仓库中进行多维存储，形成面向决策分析需求的数据立方体。数据管理则是指对数据安全、备份以及恢复的维护工作。联机分析处理服务器能够针对特定的主题对数据进行访问、处理以及多层次、多维度的分析，并将结果展现在应用前端。当前联机分析处理方式具体分为：关系型联机分析处理、多维联机分析处理以及混合型联机分析处理。前端工具前端工具主要是将

10、分析结果展现给用户以及用户指令的输入，其中包括报表展示工具、用户查询工具以及分析工具等。体系结构12343.2 数据仓库设计概念模型设计逻辑模型设计物理模型设计3.2 数据仓库设计数据仓库设计数据装载接口设计数据仓库模型设计概念模型设计逻辑模型设计物理模型设计数据模型：即数据仓库结构中数据存储、组织方式，所以数据模型的设计是数据仓库设计中最为重要的部分。3.2.1 概念模型设计定义概念模型是用于为一定的目标设计系统、收集信息而服务的概念性工具。即在进行系统设计时，先将现实数据抽象为概念模型，再使用相关的计算机语言对其进行具体描述。设计过程 ：（1）确定数据仓库模型（2）选择粒度（3）确定主题3

11、.2.1 概念模型设计（1）数据仓库模型 数据分析系统不适合使用传统的实体-关系模型，而应该采用多维模型。星型模型和雪花模型是数据仓库常用的多维模型。星型模型雪花模型是一种使用关系数据库实现多维分析空间的模型，但星型模型是非正规的结构，多维数据集的每个维度都直接与事实表连接，不存在渐变维度，所以数据有一定的冗余。是星型模型的规范化，也是对星型模型的扩展。它将星型模型的维度进一步层次化，将已有的维度扩展为多层维度。一大优点在于能很好地支持对维度的处理。3.2.1 概念模型设计（2）选择粒度 数据仓库粒度的级别和数据细化程度成反比，例如，以“日”为粒度的数据细化程度比以“月”为粒度的数据高。在粒度

12、选择时应优先考虑为业务处理获取最具原子性的信息，紧密的联系企业业务实际和需求。以公交业务数据为例，不同的用户对数据有着不同的需求，而数据分析系统一共可以分为三类用户（结构如图3.1）：基层业务员：负责根据需求编制日报表、月报表、年报表。分公司管理者：负责以日为单位查看运营报表，以月、年为单位查看分公司汇总报表。总公司管理者：负责以月、年为单位查看总公司、各分公司的汇总报表。3.2.1 概念模型设计 综合考虑，数据分析系统采用双重粒度存储数据，即以“日”为粒度的原子信息和以“月”为粒度的汇总信息。详细结构如图3.1所示：车辆日收入车辆日收入车辆日收入车辆日收入日汇总数据月汇总数据轻度级别中度级别

13、图3.1 数据仓库粒度级别设计图3.2.1 概念模型设计（3）确定主题 主题是一个抽象的概念，是数据仓库设计概念模型的依据。具体来说，主题从业务角度出发，定义用户需要分析的方向，它和数据仓库的技术实现无关。同样以公交公司为例。在某公交公司存在6个运营级别，分别是公交公司分公司、车队、线路、车辆、司机以及乘务员。每个运营级别之间也存在一定的隶属关系，车队隶属于分公司、线路属于车队、车辆、司机以及乘务员属于线路。运营级别关系如图3.2。3.2.1 概念模型设计司机维度线路维度车队维度日期维度分公司维度车辆运营图3.2 车辆运营主题的逻辑结构图数据仓库确定6个主题，即：分公司运营主题、车队运营主题、

14、线路运营主题、车辆运营主题、司机运营主题、乘务员运营主题。数据仓库以面向主题的方式组织数据，可以在较高层次上对分析数据进行一致性描述。同时，这样组织数据能够全面展示各个分析对象所涉及的企业各项数据间的关系。3.2.2 逻辑模型设计定义逻辑模型主要是在概念模型的基础上进行主题细化，定义实体间的关系和属性。数据仓库逻辑模型的基础是主题，应根据主题对业务的划分以及业务间的关联关系进行描述。设计过程 ：（1）确定当前需要载入的主题（2）维度设计3.2.2 逻辑模型设计（1）确定当前需要载入的主题在概念模型阶段，以公交公司为例确定了6个主题。现在要详细的设计主题域所有的属性，特别是确定能代表主题的属性组

15、。下表3.1展示分公司日运营主题、车辆日运营主题、司机日运营主题以及乘务员日运营主题（车队、线路运营主题和分公司基本一致）的详细描述。主题名主题名公共码键公共码键属性组属性组分公司运营主题分公司编号分公司固有信息：分公司名称、分公司编号等运营信息：实际运营圈次、营运车日等计划信息：计划线路数、计划普票收入等收银信息：收银收入、收银人次等油耗信息：标准能源应耗、标准能源实耗等安全信息：事故次数、事故收入等服务信息：服务检查数、整洁检查数等日期信息：年、月、日、节日等。表3.1 主题的详细描述3.2.2 逻辑模型设计主题名主题名公共码键公共码键属性组属性组车辆运营主题车辆编号车辆固有信息：车辆编号

16、等运营信息：实际运营圈次、营运车日等计划信息：计划线路数、计划普票收入等收银信息：收银收入、收银人次等油耗信息：标准能源应耗、标准能源实耗等日期信息：年、月、日、节日、天气等。司机运营主题司机编号运营信息：实际运营圈次、总行驶时间等计划信息：计划行驶千米、计划运营圈次等收银信息：收银收入、收银人次等日期信息：年、月、日、节日、天气等。乘务员运营主题编号乘务员固有信息：乘务员姓名、乘务员编号等；运营信息：实际运营圈次、总行驶时间等；计划信息：计划行驶千米、计划运营圈次等；收银信息：收银收入、收银人次等日期信息：年、月、日、节日、天气等。接表3.1 主题的详细描述3.2.2 逻辑模型设计（2）维度

17、设计 维度是用户观察、分析数据的角度，也是连接用户和数据仓库数据的接口。维度常常是一组指标，用户可以从不同的维度指标来进行数据的组织分析。为了避免维度孤岛的问题发生，在维度设计时应采用一致性维度的方法。一致性维度主要有两种存在方式：（1）一致性维度是同一的 一致的维度具有一致的关键字、一致的属性列名称、一致的属性定义以及一致的属性值，只要其中一项不同维度表就不一致。（2）具有最佳粒度性与细节性的维度在严格数据意义上的子集 比如，当车辆事实表为与聚集维度相联系的聚集事实时，维度就处在一个通过堆积形成的粒度层次上，这时，如果一个维度是另一个维度数学上严格的子集，这种关系也满足维度的一致性。3.2.

18、2 逻辑模型设计例如，分公司月运营和分公司日运营由于粒度不同，无法在日期维度保持一致，所以分公司月运营维度应当在分公司日运营维度上建立。这样月维度就可以是日期维度的子集，在后续钻取等操作时仍可以保持一致。根据公交公司选定的主题，进而设计的维度如上表3.1属性组中所示。3.2.3 物理模型设计定义物理模型是将概念模型和逻辑模型以具体的实体形式展现的最终目标，是建立在逻辑模型的基础上对包括物理列名、数据类型、关键字定义以及是否允许为空等关系进行相应的设计。设计过程 ：（1）事实表设计（2）维度表设计3.2.3 物理模型设计（1）事实表设计 事实表是维度模型的基本表，其度量值必须使用相同的粒度。Fa

19、ct_日司机汇总表包含三类度量值：（1）可加性事实 指可做加法的事实，它是事实表最有用的事实。（2）半加性事实 指只能在某些维度相加的事实。半加性事实的表现形式也是数值，但是不能直接相加，因为直接相加不符合逻辑。（3）非加性事实 指在任何情况下都不能进行加法运算的事实，或是加完后没有任何意义的事实。文本度量值属于非加性事实。同时，不代表数量意义的数值事实也属于非加性事实。3.2.3 物理模型设计（2）维度表设计 维度表和事实表相辅相成，它提供对业务的文字描述。维度表的属性决定着用户与数据仓库交互的难易程度，丰富的维度属性提供丰富的约束条件和报表标签。维度表的属性多是文字性的，并不具有数学上的运

20、算能力，这也是维度表属性和事实表属性的主要区别。在设计维度表时，可以更多地提供有意义的属性，即维度表的列数可以适量的增加以对数据的属性详细说明，这样的设计可以提供更多维度的查询。右图展示的是Dim_日期维度表。列名数据类型允许null值日期keyint否完全日期date否星期几tinyint否当月的第几天tinyint否当年的第几天smallint否当年的第几周tinyint否当年的第几月tinyint否当年的第几季度tinyint否日历年smallint否节日var（10）是天气var（10）是表3.2 Dim_日期维度表3.2.3 物理模型设计下面以日期维度表为例，详细介绍维度表的设计过程

21、。Dim_日期维度表有11个属性，每个属性都是对维度表的描述。“日历年”表示按照公历纪元表示的年份。目前公交业务系统中最早的数据是从2002年开始的，因此，“日历年”也是从2002年开始至今，以后随着年份增加，每年都会增加新一年的数据。“当年的第几月”表示月份数，取值范围是112，“当月的第几天”表示的是每月的天数，自然月有28天、29天、30天以及31天，因而取值范围为131。在Dim_日期维度表中除了表现时间的属性外，还有两个比较特殊的属性：节日天气不仅仅是给出“节日”和“非节日”这样的内容，而是给出9种属性值，分别是8个法定节假日以及“平时”。在生成数据时，默认为“平时”。有20个属性值

22、，分别是晴天、阴天以及雾天等常见天气状况。在生成数据时，默认为“晴”。3.3 ETL的过程设计数据抽取设计数据清洗设计数据加载设计3.3 ETL的过程设计ETL（即抽取、转换、加载）系统是数据仓库的基础之一。ETL系统通过从分散的源系统中抽取数据，按照规则和一致性标准清洗数据，最后以适当的形式展现数据，供用户做决策分析。一个标准的ETL流程图如图3.3所示。图3.3 标准的ETL流程3.3.1 数据抽取设计常见的源系统类型有：平面文件（包括固定长度平面文件和有分隔符的平面文件）、数据库、XML（扩展标志语音）数据源、Web日志数据源以及ERP系统数据源等。对于各种类型的数据源，数据抽取方式如下

23、：数据抽取方式全量抽取：增量抽取：原封不动的将数据从源系统抽取出来，并转化成ETL工具可识别的格式。指只抽取新增或修改的数据。该方法应用最多，其常用的模式有：触发器方式、时间戳方式、全表删除插入方式、全表对比方式以及日志表方式。3.3.1 数据抽取设计 指在源系统的表里设置增、删、改三个触发器，当源系统数据发生变化时，触发器就会自动运行，目标数据仓库的数据也会发生相应变化。触发器方式 是一种基于快照比较的变化数据捕获方式，必须首先在源表上加上时间戳字段，当源表数据变化时，时间戳也自动更新，从而抽取数据时可以通过对比时间戳来选择需要更新的数据。时间戳方式 是一种较为常见的抽取方式，具体操作为每次

24、ETL操作之前都必须先删除相关数据，再由ETL重新加载数据。全表删除插入方式 需要在业务系统中添加日志表，每当数据源表数据发生变化，日志表就会更新，因此可以通过查看日志表确定哪些数据需要抽取。日志表方式 通过为数据源表创建一个主键以及所有字段的临时表，当ETL工具要抽取数据时，都必须先对临时表和数据源表作比较，若不同于临时表和数据源表，则执行更新操作。全表对比方式3.3.2 数据清洗设计定义数据清洗是ETL系统三个步骤中最重要也是最核心的部分。通过清洗数据，可以将质量存在问题的数据加以修正，达到准确分析的要求。设计过程 ：（1）定义数据质量（2）对数据进行清洗3.3.2 数据清洗设计（1）定义

25、数据质量正确性明确性一致性完整性数据必须能正确的反映它所代表的对象。数据的描述应具有唯一的意义。数据清洗的第一步是定义数据质量。高质量的数据必须有以下4个特点：数据的值和描述必须保持不变。确定一致性后，数据仓库的每个表都必须使用不变的标识约定。完整性约束通常有两个方面，一是保证记录数是完整的没有任何丢失记录；二是对每个属性进行定义，包括属性值和约束。（2）对数据进行清洗3.3.2 数据清洗设计明确定义数据质量之后就要将源数据和数据质量要求作对比，对数据进行清洗。在实际操作中，往往会出现多种数据问题，我们将常见的数据质量问题归为四类，针对每类问题都有相应的解决方法，如下：A类B类这类问题是最常见

26、的，表现形式为数据出现错误。比如，在DFact_日司机汇总表中，总行驶千米表示当天该司机开车行驶的总里程。从逻辑上来说，总行驶千米不可能为负值。因此，当出现负值时，可以确定是数据源存在问题，最大的可能就是数据录入时出现了错误。类似于该类问题，解决方法只能回到源系统进行处理。ETL清洗这类数据时，应当明确标明这些数据属于伪造或缺失。该类问题与A类问题的内容大致相同，但主要区别在于技术实现。以公交五公司的一条线路为例，在数据清洗过程中，发现K400公交线路存在两种写法：K400和k400。正确的写法是大写的K400。使用ETL的数据流转换工具可以批量的将错误的写法修改为正确的写法，即将小写改为大写

27、，但最理想的解决方案应该是在源系统将错误改正，这样在调用该数据源时不需要再次修改数据。3.3.2 数据清洗设计C类D类该类问题一般不是因为数据本身出现错误，而是对数据的格式有不同的需求。在数据仓库物理模型设计时，将维度属性“司机编号”数据类型定义为varchar（10），这样既可以节省空间，又可以在后期数据显示时获得更好的效果，然而在源系统里“司机编号”的类型是char（10）。源系统对数据的定义并没有出错，但不满足新系统的需求。该问题最好的解决方案是保持源数据系统不变，在ETL过程中对数据类型进行修改。这类问题通常是固定的源系统错误数据或者是第三方系统的数据缺失，并且只能在ETL系统解决。D

28、类问题在4种数据质量问题中最少见，但往往是数据清洗的难点和重点。下面以DFact_日司机汇总表的ETL过程为例，详细阐述D类问题的产生原因和解决方案：DFact_日司机汇总表中有一类数据表示的是收银信息，包括收入和人次两个方面。3.3.2 数据清洗设计收入营运收入收银收入票务收入IC卡收入人次营运人次收银人次票务人次IC卡人次收入信息人次信息包括营运收入、收银收入、票务收入、IC卡收入。其中，IC卡收入又可以细分为成人卡收入、学生卡收入以及老年卡收入。包括营运人次、收银人次、票务人次、IC卡人次，IC卡人次可分为成人卡人次、学生卡人次以及老年卡人次，具体关系如下表：表3.3 收入、人次关系3.

29、3.2 数据清洗设计以收入信息为例分析数据来源。运 营收 入收 银收 入票 务收 入IC卡收 入是一个计算字段，相当于收银收入、票务收入以及IC卡收入总和。来源于收银数据库，是无人售票线路的现款收入。收银数据是第二天从收银数据库导入计统数据库。来源于票务数据库，是有售票员线路的售票收入，票务收入每天晚上导入计统数据库。来源于一卡通数据库，是无人售票线路的IC卡刷卡收入，IC卡收入也是次日从一卡通数据库导入计统数据库。在源系统中，对任意的某一天，只有票务收入是当天的数据，收银收入和IC卡收入都是前一天的数据，所以当天的营运收入是错误的值。3.3.2 数据清洗设计ETL系统设计了存储过程“DFac

30、t日司机日期提前一天”，它按月将一个月的部分收入数据和人次数据提前一天。例如源系统的20号数据在数据仓库中为19号的数据，而源系统每月的第一天则提前为上月的最后一天的数据。“DFact日司机日期提前一天”是写在数据仓库中的存储过程，可以使ETL工具箱里的控制流工具“传输主存储过程任务”调用该存储过程，在适当的时候执行操作。通过存储过程的修正，查询DFact_日司机汇总表中任意一天的收入数据即为当天的收入数据。为了保持数据的一致性，ETL过程必须将这部分数据重新组合。解决方案：3.3.3 数据加载设计定义加载数据到目标多维结构是ETL的最后一步。在这个步骤中，主要操作是提取并转换数据写入目标数据

31、库，最终由用户和应用程序访问。设计过程 ：（1）对维度表的加载（2）对事实表的加载3.3.3 数据加载设计（1）维度表的加载 维度表的加载常采用渐变维度法（Slowly Changing Dimensions，简称SCD）。渐变维度是指在数据仓库中随着时间的变化存储和管理当前数据以及历史数据的维。根据处理属性变化的策略不同，渐变维度分为3种类型。类型一：特点是变化覆盖现有属性。一个类型变化只更新属性，不插入新纪录，不影响主码。新传入的记录（改变或修改了数据集）取代了现有的旧记录，这样属性反映的总是最新的记录。现在以乘务员的维度作为考察对象。Dim乘务员表是乘务员运营主题的维度表，现在有乘务员编

32、号为05001627的乘务员。于是，存在于Dim乘务员表的05001627号乘务员具有如下表3.4形式：3.3.3 数据加载设计年月乘务员编号乘务员名称性别车队编号是否在册线路编号20141005001627马涛男506是260表3.4 乘务员维度值1乘务员编号是Dim乘务员表的主码，在3种类型的讨论中，主码都保持不变，即乘务员编号是不会发生变化的。假设在2014年11月1日，该乘务员从260线路调到环山2号线路上班，如果应用类型1，则用新的线路编号更新维度表的数据即可，更新后的数据如下表3.5所示：年月乘务员编号乘务员名称性别车队编号是否在册线路编号20141105001627马涛男506是

33、环山2号表3.5 乘务员维度值23.3.3 数据加载设计类型二：特点是增加改变的记录。当2014年11月后05001627乘务员从260线路调到环山2号线路上班，应用类型2的方法，则是添加一条新的记录，该乘务员相关数据记录如表3.6所示：年月乘务员编号乘务员名称性别车队编号是否在册线路编号20141005001627马涛男506是26020141105001627马涛男506是环山2号表3.6 乘务员维度值3 类型2的方法可以很好地跟踪维度的变化，并且能够记录所有的历史属性。但是每次变化添加新纪录的方式会加速维度表的膨胀，实践证明，当维度表已经超过100万行时，类型2是不适用的。3.3.3 数

34、据加载设计类型三：特点是添加维度列。当属性值变化时，并不是如类型2一般添加新的记录，而是通过添加新的列来捕获属性的变化。针对乘务员的例子，应用类型3得到记录表3.7：年月乘务员编号乘务员名称性别车队编号是否在册前线路编号20141105001627马涛男506是260表3.7 乘务员维度值4 类型3的优点是可以在同一条记录里展示新旧属性值，方便做分析比较。但类型3显然不适用于属性值频繁变化的情况，属性值频繁变化带来的影响非常严重，因此如果需要跟踪不可预见的变化，类型2更适用于类型3。3.3.3 数据加载设计（2）事实表的加载 事实表有3种基本类型，分别是事务事实表、周期快照事实表以及累积快照事

35、实表。累积快照事实表周期快照事实表事务事表粒度每个生命期一行每段一行每个事务一行日期维度标准关键环节的多个日期时间段终止日期事务日期代表的时间段不确定时间跨度规律性可预见时间点事实表更新需要更新数据更新数据不更新数据事实表加载插入与更新插入插入表3.8 三种事务的比较3.3.3 数据加载设计特定时间、特定空间上的某个时间点的测量。主要用于存储最低粒度的数据。因此，事务事实表通常是三种表中数据量最庞大的表。事务事实表适用于描述有确定时间段的过程，它可以涵盖一个事务生命周期的任意时间跨度。累积快照事实表通常是一个时间段的规律性重复，在每周、每月结束时为当时的业务状态拍照，每个给定的时间周期都会有一

36、张快照。周期快照事实表3.3.3 数据加载设计 当事实表第一次导入数据时，通常都会面临较为庞大的数据量，如何有效快速的载入数据是需要考虑的重要问题，因此下面给出了几种较为常见的一次性数据加载的方法。法1单独处理数据插入，使用SQL语句的方式，如update和insert语句，都可以将数据进行加载。法2批量加载，使用批量加载工具可以提高加载效率，同时也能够降低数据库负载法3并行加载，适用于加载大量的数据。先对数据进行分区，然后通过ETL过程并行加载。法4最小化物理更新，先删除需要更新的数据，然后将所有的数据批量加载法5在数据库外进行聚合，应用ETL过程将数据在进入关系型数据库准备区之前进行合并。

37、3.3.3 数据加载设计公交公司分公司事实表的加载过程是一个典型的数据加载过程。事实表的初始化是通过批量加载完成的，一次性将2002至2012年的数据加载到数据仓库。事实表的周期性加载使用的是增量加载方法，系统设置每天凌晨2点自动将前一天的事务数据加载到DFact日分公司汇总表里。同时在每月的2号凌晨执行以“月”为粒度的增量加载，即将上一个月的周期性数据加载到DFact月分公司汇总表里。图3.4是DFact日分公司汇总表的数据流任务图。事实表的初始化完成之后，系统更多的需要考虑的是如何对事实表进行周期性加载。目前，数据分析系统的数据仓库使用的是增量加载方式，并且加载的时间间隔为每日，即每天将“

38、日”粒度数据加载到数据仓库中。这样的加载方式既可以避免实时加载的频繁访问，又可以及时的将新的数据更新到数据仓库中。3.3.3 数据加载设计图3.5 DFact_日分公司汇总表的数据流任务图3.3.3 数据加载设计Extract changes from data sourcesRefresh the data warehouse based on changesData WarehouseStaging DatabaseETL process inserts or modifies data in the data warehouse based on changesETL process extracts new and modified dataUsers modify data in business applications