块加载器 - Canon EOS 70D数码单反摄影指南

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

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

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

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

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

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

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

在构建事实表时，代理键管道的最终ETL步骤涉及将新数据记录的自然键转换为准确且当前的代理键。假设所有记录已加载到事实表中，需要为每个维度实体（如客户或产品）分配当前的代理键。本节将详细探讨这一过程。

图表3.2源系统追踪报告可作为数据仓库后续阶段的概述。如果列表中有20个源系统，并且阶段1包括两到三个系统，项目规划将需要大量时间。主题领域涵盖了系统数据集市的常见命名。接口名称是支持交易应用系统的源系统标识。业务名称是业务用户通常使用的系统名称。优先级用于确定未来阶段的顺序，通常在完成数据仓库总线矩阵后设置。部门/业务用法描述了主要部门（如会计、人力资源等）使用数据库的情况。业务所有者是主题领域数据负责人的联系人或小组。技术所有者通常是负责维护数据库的DBA或IT项目经理。DBMS指出了源数据库管理系统的类型，通常是关系型数据库，如ORACLE、DB2或SYBASE，也可能是非关系型数据存储，如LOTUS NOTES或VSAM。生产服务器/OS列出了运行数据库的物理服务器名称和操作系统。