代理键管理策略-Canon EOS 70D数码单反摄影指南

在图6.14中，单行道类别聚合模式示例展示了类别描述和部门描述在类别级别的定义，字段名称与基础表中的维表命名保持一致。UPC号码、包装尺寸和滋味等特定维度不在此级别内，并且不应出现在类别表中。缩减的维表对于聚合导航至关重要，因为系统目录描述能够提供任何聚合级别的范围。换句话说，通过查询系统目录表，我们能够获取其目录描述和部门描述。如果查询的是产品的滋味，我们将立即了解到当前聚合级别无法满足需求，需要聚合导航器在其他地方查找。缩减的维表的吸引力还在于避免了在原始维表中为所有在更高聚合级别上不支持的维度实体填写null值。因此，在类别表中不需要填写滋味和包装尺寸字段的null值，也无需在应用程序中

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

图11.12描述了一个单一处理，即小批处理流图。各个处理连续运行，并与其他处理共同完成同一工作，如邮件收发后台程序。因此设置工作处理事件和微批处理状态值，然后继续。数据清洗、一致化、匹配、存在和发布等后台处理任务可能同时发生在数据管理者的环境中。实时CTF系统中的转换过程和代理键查找后台程序也有可能存在。每个后台程序都会连续地处理查找任务。所述的任务工作是指在给定处理中以最优方式处理的阶段，已记录的任务。任务处理事件的状态在处理中被设置，并且关系数据库处理的起始点是确定的。处理后，任务处理事件的状态会更新为成功或失败。在批处理结束时，批处理控制表会被更新，以确保所有任务都已成功执行。如果发生失

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

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

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

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”。掌握每个加载器的特定实

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

在将系统迁移到生产环境的过程中，需要考虑多种因素，如指导原则、技术架构和ETL工具集的选择。通常情况下，ETL团队是开发团队的一部分，但应避免分散注意力于数据仓库的生产支持，除非ETL团队足够强大，能够独立处理生产环境支持。本章的重点在于探讨ETL生命周期的结尾阶段，以组织架构和工具环境的变化为前提，为数据仓库的成功实施提供参考。值得注意的是，大多数文献关注数据仓库团队如何维护数据仓库，实际上根据我们的经验，数据仓库团队主要由开发者和分析员组成。他们收集业务需求、分析并建立数据仓库，完成后通常交由专门的运维团队进行日常监控和维护。数据仓库架构师和模型师负责维度建模，ETL管理者负责按照维度设计