Canon EOS 70D

图5.9展示了员工角色的多维图表，而图5.10展示了多个日期角色的设计方法，推荐的角色维度设计方法不会对ETL团队的工作产生影响。讨论角色维度技术的目的是帮助ETL团队通过视图而不是多个物理表达到相同目的。在电信行业，每个记录几乎都有一个地址，将所有可能的地址加入到单个地址维表可能导致维表包含数百万记录。在这种情况下，建立视图对性能可能造成严重影响，因此为各个子集创建物理表可能更有效。图6.10进一步探讨了其他维度的子维杜，将事实表中对维的引用视为事实表的外键，正确的外键存储在父维表和事实表中。

图6.9四种类型的优化更改中，前三类改变带来一个共同问题：如何处理旧的历史数据，特别是在更改事实、维度或属性之前。通常，如果有现成的旧历史数据可用，处理会更为简单。然而，大多数情况下，增加事实、维度或属性的原因是它们在当前情境下变得可用。针对这些变化，我们可以采取以下策略：1、新增事实时，历史值存储为null。随着时间推移，当历史值得到更新，null值能够正确计算，从而确保计数和平均值的准确性。2、新增维度时，必须确保之前的事实记录外键指向维度表中适用的记录。3、新增维度属性时，在类型1的维度中无需修改，新实体在所有维度表记录中均可用；而在类型2的维度中，在添加新实体之前的所有记录中，需确保相关维表记录的有效性。

3.2设计集结区根据自身需求配置最终的数据仓库展示区。有时，集结区数据用于支持需要历史数据的功能；其他时候，集结区数据在每个处理流程完成后即被清除。用于长期保存历史信息的持久集结区与每次加载后删除的临时集结区形成对比。大多数集结区采用混合模式，同时包含临时和持久的集结表。集结区的设计不仅仅是为了支持下一个处理作业，还可以用于工作流恢复、审计和验证数据处理结果。此外，在设计和部署集结区时应考虑以下基本规则，确保数据仓库操作的成功：数据集结区应由ETL小组所有，不对外开放，不支持查询索引和聚合表，也不保证数据访问和一致性，这些需求应在展示区处理。未经授权不得进入集结区，以免影响数据仓库完整性。报表不应直接从集结区访问数据，集结区是ETL小组的工作站点，允许他们无需用户通知即可操作表格。

图11.12描述了一个单一处理，即小批处理流图。各个处理连续运行，并与其他处理共同完成同一工作，如邮件收发后台程序。因此设置工作处理事件和微批处理状态值，然后继续。数据清洗、一致化、匹配、存在和发布等后台处理任务可能同时发生在数据管理者的环境中。实时CTF系统中的转换过程和代理键查找后台程序也有可能存在。每个后台程序都会连续地处理查找任务。所述的任务工作是指在给定处理中以最优方式处理的阶段，已记录的任务。任务处理事件的状态在处理中被设置，并且关系数据库处理的起始点是确定的。处理后，任务处理事件的状态会更新为成功或失败。在批处理结束时，批处理控制表会被更新，以确保所有任务都已成功执行。如果发生失败或大量任务处理事件状态失败，将执行回滚处理，将数据库恢复到微批处理执行之前的状态。回滚事件并不一定回滚错误信息或控制表中的状态值。关系型数据库提供了处理控制选项以支持这种约束。微批处理ETL应用于实时数据管理者，如图11.13所示，作为系列后台处理，从数据库表中读取数据，更新控制信息，分段传输数据，并进行数据一致化。

在图6.14中，单行道类别聚合模式示例展示了类别描述和部门描述在类别级别的定义，字段名称与基础表中的维表命名保持一致。UPC号码、包装尺寸和滋味等特定维度不在此级别内，并且不应出现在类别表中。缩减的维表对于聚合导航至关重要，因为系统目录描述能够提供任何聚合级别的范围。换句话说，通过查询系统目录表，我们能够获取其目录描述和部门描述。如果查询的是产品的滋味，我们将立即了解到当前聚合级别无法满足需求，需要聚合导航器在其他地方查找。缩减的维表的吸引力还在于避免了在原始维表中为所有在更高聚合级别上不支持的维度实体填写null值。因此，在类别表中不需要填写滋味和包装尺寸字段的null值，也无需在应用程序中对这些null值进行处理。尽管我们专注于缩减的维表，但是在构建高级别聚合时，事实表中的度量数目也会随之变化。大多数基本的可加度量如销售额、销售数量和成本额将存在于各个聚合级别上，但是一些维度如促销和一些事实如促销成本将仅在基础级别上存在，并在聚合表中被删除。简化的设计要求#2仅创建此类聚合事实表，完全删除特定维度，而不是仅简单地缩减。例如，在零售销售事实表中，地址或店铺维度可以完全删除。

Oracle SQL*Loader需要一个控制文件来描述数据文件的编排。优化性能的两个重要参数：DIRECT={TRUE | FALSE} PARALLEL={TRUE | FALSE}。Microsoft SQL Server Bulk Copy Program（BCP）提供了BULK INSERT，比BCP更快，节省时间，无需利用Microsoft Netlib API。IBM DB2 Load Utility接受来自Oracle的控制文件和数据文件作为输入源。Sybase Bulk Copy Program（BCP）也支持DBLOAD，参数BULKCOPY=“Y”。掌握每个加载器的特定实用程序是相对简单的，它们之间的相似性使得理解更为容易。

9.1调度和支持ETL执行策略主要有两种方式：调度的重要性远超简单的作业时间安排。现实情况下，作业执行的确切时间并非关键。有效的调度需考虑ETL作业间的相关性和依赖关系，并作为管理执行策略物理实施的可靠机制。

数据库应用系统设计中，CRUD矩阵表（创建、读取、修改和删除）用于追踪数据操作过程。尽管数据修改和读取很常见，但删除操作的开发却常被忽视。这会导致两种情况：运行后台脚本删除历史数据或数据无限期留存，两种情况都不利于数据仓库管理。 每个主题域完成后，都应有相应的清除处理过程。如果数据量小，且长期数据量不影响性能，ETL开发可延后，但清除策略元数据需在初始化实施时收集发布。 数据仓库数据的存档应由DBA负责，而永久删除则由ETL团队执行。删除数据的业务规则需通过充分测试和质量保证的ETL过程来执行。

账户活动事实表 账户活动事实表提供账户在特定期间内的活动摘要。例如，在月度快照中，每个账户都有一个记录，其中包含该月的所有活动。 维护策略 周期快照事实表通过一次性加载所有记录进行维护，并在当前紧迫滚动周期内进行增量更新。这确保了在整个历史周期内始终提供最新数据。 加载特性 周期快照事实表与事务粒度表具有相似的加载特性。在数据仓库加载过程中，所有记录将在每个周期性加载中按最近时间分区进行分组。

在将系统迁移到生产环境的过程中，需要考虑多种因素，如指导原则、技术架构和ETL工具集的选择。通常情况下，ETL团队是开发团队的一部分，但应避免分散注意力于数据仓库的生产支持，除非ETL团队足够强大，能够独立处理生产环境支持。本章的重点在于探讨ETL生命周期的结尾阶段，以组织架构和工具环境的变化为前提，为数据仓库的成功实施提供参考。值得注意的是，大多数文献关注数据仓库团队如何维护数据仓库，实际上根据我们的经验，数据仓库团队主要由开发者和分析员组成。他们收集业务需求、分析并建立数据仓库，完成后通常交由专门的运维团队进行日常监控和维护。数据仓库架构师和模型师负责维度建模，ETL管理者负责按照维度设计装载数据仓库，ETL开发团队编写测试计划来验证ETL过程。随着数据仓库的成长和更多数据集市的增加，开发团队应从生产环境的日常操作中解脱出来，专注于开发和创新。因此，ETL生产支持和数据仓库的运维工作应交由专门的团队承担，确保系统稳定运行，只有在遇到长期困扰无法解决的问题时才需要开发团队介入。