一. 需求综合

  ETL 系统结构的建立始于处理一个最棘手的问题：需求综合 。需求综合的含义是收集并理解所有己知的将会影响 ETL 系统的需求 、现实和约束等 。需求的列表可能会很长 ，但在开始 ETL 系统开发前应该都已经收集到了表中 。

  ETL 需求是必须面对的主要约束且必须要与系统适应 。在此需求框架下，可以指定相关决策 、做出判断和开展创新工作，但是需求描述了 ETL 系统必须发布的核心元素 。

  在开始 ETL 设计和开发工作前 ，应当提供针对以下所有10个需求的应答 。我们为每个需求提供了检查列表示例，方便您开始工作 。这一练习的要点是确保您对每个需求都进行了考虑，因为缺乏其中的任何一个 ，项目都有可能会被打断 。

1.1 业务需求

  从 ETL 设计者的角度来看 ，业务需求是 DW/BI 系统用户的信息需求。我们使用受限 的术语 “ 业务需求” 意味着商业用户用于制定明智的商业决策所 需要的信息内容 。因为商 业需求直接驱动对数据源的选择以及选择的数据源 在 ETL 系统中转换的结果 ，ETL 小组必 须理解并仔细验证商业需求 。

注意：
  在项目将要支持的业务需求定义期间 ，必须维护一个揭示关键性能指标(KPI)的列表， 以及业务用户需要研究某个 KPI “为什么” 发生 变化时 ，所需要的 下钻和跨钻目标。

1.2 合规性

  改变法律条文和报表需求要求多数组织严格地对待其报表并证明这些报表的数字是准确的、完整的且未被篡改的 。当然，受到严格管理的业务的 DW/BI 系统，例如电讯 ，会花费数年时间编辑报表需求 。但是金融报表的整体氛围对每个人来说会越来越严格 。

注意：
  在与法律部门或首席合规官（ CCO）（如果有的话）和 BI 发布小组咨询讨论时 、应该列 出所有的数据以及最终报表主题要遵守的法律限制 。列出这些数据输入和数据转换步骤 ， 需要维护 “监管链” ，显示并证明最终报表走来自发布的数据源的原始数据 。列出的数据，必须提供您所控制的副本的安全性证明，无论是在线的还是离线的 。列出您所归档的数据副本 ，列出这些归桔的预期使用周期。完成这些工作会带来好运 。这就是值得您去做的原因。

1.3 数据质量

  三种强有力的力量融合将数据质量问题推到高管们最关注问题的列表顶部 。首先 ，长期文化趋势认为 “ 我只有看到数据 ，才能更好地管理业务”，这一思想持续增长 ：今天的知识工作者直觉地相信数据是他们工作的关键需求 。其次，多数组织理解其数据源是分布的 ， 通常处于不同的地点，集成不同数据源是非常有必要的 。第二，不断增长的对合规性的需求意味着不仔细处理数据将不可忽略或原谅。

注意：
  您需要将那些已经知道的不中意的数据元素记录下来 ，描述是否与源系统达成共识以使在获取数据之前进行更正 。列举数据分析期间发现的那些需要在 ETL过程中持续监控和标记的数据元素 。

1.4 安全性

  过去几年 ，安全意识在 IT 行业中一直在不断增长，但是对大多数 DW/BI 小组来说， 安全通常处于事后考虑的位置且被视为负担而不受欢迎 。数据仓库的基本节律与安全心理并不相符 ，数据仓库寻求为决策制定者发布范围广泛的数据 ，安全利益认为数据应该被限制发送给那些需要知道的人。此外，安全必须扩展到物理备份 。如果介质可以方便地从备份库移出，则当在线密码被泄露时，安全性将受到威胁 。
  在需求综合期间 ，DW/BI 小组应该寻求高管层的明确指示，指明 DW/BI 系统的哪些方面应该运用额外的安全措施 。如果这些问题从未被检验过 ，则可能会被扔回给小组 。这也是为什么需要一个有经验的安全管理员参与到设计小组的原因 。合规性需求可能与安全需求存在交叉，在需求综合期间将这两个主题合并到一起是比较明智的选择 。

注意：
  应当将合规性列表扩展，使其 包含熟知的安全和隐私需求 。

1.5 数据集成

  对 IT来说 ，数据集成是 一个大课题 。因为其最终目标是将所有系统无缝地连接到 一起来开展工作。对数据集成来说 ，“ 企业全景视图” 是一个大家耳熟能详的名称 。在多数案例中，严格的数据集成必须能够在数据到达数据仓库后端前 ，将组织中主要的事务系统集成。 但是全面的数据集成往往很难实现 ，除非企业具有全面的、集中式的主数据管理（Master Data Management, MDM）系统 ，但即使这样，也仍然可能会有一些重要 的操作型系统并未 进入到主MDM中。

  数据集成通常具有数据仓库中一致性维度和事实的形式 。一致性维度意味着跨不同据序建在公共维度属性 ，只有这样才能使用这些属性构建横向钻取报表。一致性事实意味若对公共业务度量达成一致，公共业务度量包括跨不同数据库的关键性能指标（KPI） ，只有这样 ，才能使用这些数据边过计算差异和比率来开展数学比较工作。

注意：
  应当利用业务过程的总线矩阵建立一致性维度 （总线矩阵的列）的优先列表 。对每个总线矩阵的行进行标注 ，指明参与到集成过程中的业务过程是否有明确的执行需求 ，以及是否由ETL 小组负责这些业务过程。

1.6 数据延迟

  数据延迟描述通过 DW/BI 系统发布给业务用户的源系统数据的速度。显然 ，数据延迟需求对 ETL 架构具有较大的影响。高效的处理算法 、并行化以及强大的硬件系统可以加快 传统的面向批处理的数据流 。但是在有些情况下，如果数据延迟需求非常紧迫 ，ETL 系统 的架构就必须从批处理方式转换为微批处理 方式或面向流处理的方式。这一转换不是一种 渐进的转变 ，而是一种重大的风格转变 ，数据发布流水线的所有步骤儿乎都需要 重新实现。

注意：
  您应当列举所有合法的和审核过的针对以日为基础 、或者以天为 基础 多次发生、以秒为基础 、或者即时提供的数据的业务需求 。标注每个需求，明确业务团体是否了解与他们 的特定选择相关的数据质量的权衡。

1.7 归档与世系

  即使没有存储数据的法律要求 ，每个数据仓库也都需要有以往数据的各种副本，要么与新数据比较以便建立发生变化的记录 ，要么重新处理 。我们建议在每个ETL 流水线的主要活动发生后暂存数据（将其写入磁盘）：在数据被获取 、清洗和一致化及发布后 。
  那么什么时候将暂存转入归档 ，也就是数据被无限期地保存到某种形式的持久性介质 中呢？我们的回答是比较保守的 。所有暂存数据应该被归档 ，除非有专门的定义明确认为特定的数据集合未来将不再需要 。从持久性介质上读取数据与过后通过 ETL 系统重新处理 数据比较 ，前者要容易得多 。当然，利用过去的处理算法重新处理数据是不可能的，因为时间发生了变化 ，原始的获取不能够被重建 。
  当处于实际情况时 ，每个暂存／归档数据集合都应该包含描述来源和建 立数据的处理步 骤的元数据 。此外，按照某些合规性需求的要求 ，对该世系的跟踪是明确需要的，应该成 为每个归档环境的一部分内容。

注意：
  应当记录数据源和归档的中间数据步骤以及保留政策、合规性、安全和隐私方面的约束。

1.8 Bl 发布接口

  ETL 过程的最后一步将切换到 BI 应用。我们认为这种切换应当处于强有力且具有纪律性的位置上。我们认为与建模小组密切合作的 ETL小组，必须负责使数据的内容和结构 能够使 BI应用简单而快速 。这一态度超过了那种母性式的模糊的说明 。我们相信以模糊的方式将数据推到 BI 应用是不负责任的表现，将会增加应用的复杂性，减缓查询或报表的构建，不必要地增加了商业用户使用数据的复杂性 。最基本和严重的错误是支持成熟的、规 范化的物理模型并脱离实际工作 。这也是为什么需要花这么长的时间讨论构 建包含最终切 换的维度模型的原因。

  ETL小组和数据建模人员需要与 BI 应用开发人员密切合作 ，确定数据切换的具体需求 。 如果物理数据以正确的格式表示的话，则每种 BI 工具都有某些需要避免的敏感性 ，都包含某些可以利用的特征 。同样，在为 OLAP 多维数据库准备数据时 ，也需要考虑这些因素 。

注意：
  应当列出所有将会直接被BI工具利用的事实和维度表。可以直接从维度模型定义着手 。列出BI工具需要的所有OLAP多维数据库和特定的数据库结构。列出所有您已经打算建立并用于支持BI性能的已知的索引和聚集。

1.9 可用的技能

  某些ETL系统设计决策必须基于建立和管理系统的可用源的情况制定 。如果这些编程技能不是内部的或有合理的需要的话，就不应该基于关键的 C＋＋处理模块来构建系统 。同样，如果您已经掌握了这些技能井找到如何管理类似项目 ，那么您可能会认为围绕主要提 供商的 ETL工具来建立 ETL 系统更可靠。
  考虑一个关键的决策问题，是否需要通过手工编码构建 ETL 系统或者使用供应商的 ETL 包。先将技术问题和许可证书的成本放在一边 ，不要因为未能考虑决策的长期影响而 走上雇员和经理都发现不熟悉的方向 。

注意：
  应该清查您所在部门的操作系统 、ETL 工具、脚本语言 、编程语言 、SQL、DBMS 以 及 OLAP 技能 ，这样可以理解如何暴露出您缺乏这些技能 。列 出需要支持当 前系统以及未 来可能有的 系统的那些技能．

1.10 传统的许可证书

  最后，在许多情况下 ，多数设计决策的制定隐约地受到管理层坚持认为应当使用现有许可证书的影响 。多数情况下，这一需求是可以考虑采用的，因为环境的有利条件对每个人来说都是非常明确的 。但也存在 一些情况 ，使用现有许可证书来开发 ETL 系统是一个错误的决定。如果出现这种情况，而且您感觉必须要做出正确的决定时，您可能需要以您的工作打赌 。如果您必须着手处理高管层的意见 ，挑战使用现存许可证书的原则，则需要为做出的决定进行充分的准备 ，要么接受最终 的决定，要么准备离开 。

注意：
您应当列出现有操作系统 、ETL 工具 、脚本语言 、编程语言 、 SQL、DBMS 和 OLAP的许可证书 ，无论它们是独家使用投权还是仅仅被建议使用的情况．

二. ETL的34个子系统

  在充分理解了现存的需求、现状和相关约束后，就可以准备学习形成每个ETL系统架构的34个关键子系统 。本章将不分重点地描述34个子系统。下一章将描述在特定环境中实现这些子系统的实际步骤 。虽然我们采用了行业术语一 ETL一一味描述这些步骤 ，过程实际上包含4个主要的组成部分：

• 获取：从源系统中收集原始数据并通常在所有明显的数据重构发生之前将收集的数据写到ETL环境的磁盘上 。子系统 1 子系统3 用于支持获取过程 。

• 清洗及转换 ：将获取的源数据通过 ETL 系统的一系列处理步骤 ，改进从源系统获 得数据的质量 。将来自两个或多个数据源的数据融合，用于建立和执行一致性维度和一致性度量 。子系统 4 子系统 8 描述了支持清洗和转换工作所需要的结构 。

• 发布：物理构建并加载数据到展现服务器的目标维度模型中。子系统 9 子系统
21 提供了将数据发布到展现服务器的功能 。

• 管理 ：以一致的方法管理与ETL 环境相关的系统和过程。子系统 22 子系统 34
描述了用于支持 ETL 系统持续管理所需要的各种部件。

三. 获取：将数据插入到数据仓库中

  毫无疑问，最初的ETL子系统结构将解决理解数据源 、获取数据 、将获取的数据转换到ETL系统能够操作且独立于操作型系统的数据仓库环境等问题。尽管即将讲述的子系统关注转换 、加载以及 ETL 环境的系统管理 ，但最初讨论的子系统将主要用于与源系统的接 口并获得需要的数据 。

3.1 子系统 1：数据分析

  数据分析是对数据的技术分析，包括对数据内容 、一致性和结构的描述 。从某种意义来看 ，无论何时执行 SELECT DISTINCT 查询数据库字段 ，都是在进行数据分析 。存在大量的特定工具用于执行强大的数据分析工作 。投资采用某种工具而不是自己构建是有意义的，因为利用工具可以使用简单的用户接口探索大多数数据关系 。使用工具而不是自己手工编程开发 ，会大大提高数据分析阶段的效率 。

  数据分析扮演两种不同的角色 ：战略与战术 。一旦确定了候选数据源 ，就应该开展轻量级的分析评估工作 ，确定其作为数据仓库包含物的适用性并尽早提供用或是不用的决定 。 理想情况下，这种战略性的分析应该在业务需求分析阶段确定了候选数据源后立即开展 。 尽早确定数据源的可用性资格问题是必须开展的负责任的一个步骤 ，能够让您赢得其他小组成员的尊敬 ，即使做出的决定是放弃使用某个数据源 。较晚发现数据源无法支持任务将使DW/BI工作偏离其应有的轨道（将会成为您职业生涯的致命错误），特别是如果这一发现发生在项目己经启动数月后 。

  将数据源包含在项目中这一基本战略决策制定完成后 ，将开展较长时间的数据分析工作，尽可能将大多数问题挤出去 。通常，这一任务始于数据建模过程，井延伸到ETL系统设计过程 。有时，ETL小组可能希望将某一尚未进行内容评估的源包含进来。这些系统可能支持生产过程的需求，然而面临ETL的挑战，因为不是生产过程中心的宇段对分析目的来说可能是不可靠和不完整的。出现在该子系统中 的问题将导致详细的规格说明 ，这些规格说明要么返回 到数据来源地要求改进 ，要么成为 4 子系统 8 所描述的数据质量过程的 输入。

  分析步骤能够指导 ETL 小组 ，多少数据清洗机制用于提醒并保护他们 ，在由于需要处理脏数据而导致的意想不到的系统构建迁移中不会丢失主要的项目里程碑。预先开展数据分析工作！使用数据分析结果设置业务资助人有关现实的开发计划 、对源数据的限制 、投资更好的源数据获取实践的期望 。

3.2 子系统 2：变化数据获取系统

  在数据仓库进行最初的历史数据加载时 ，获取源数据内容的变化并不重要，因为您将会按照某一时间点 ，将该时间点之前的所有数据都加载进来 。然而 ，由于大多数数据仓库的表都非常庞大 ，以至于无法在每个 ETL 周期都能够将这些表加载一次。因此必须具备能够将上一次更新后发生变化的源数据加载进来的能力。将最新的数据源分离出来被称为变化数据获取（Change Data Capture CDC) 。隐藏在 CDC 背后的思想比较简单：仅仅传输那些 上次加载后发生变化的数据 。但是建立一个好的 CDC 系统并不像昕上去那么容易 。变化数据获取子系统的主要目标包括 ：
• 分离变化数据以允许可选择加载过程而不是完全更新加载。
• 获取源数据所有的变化（删除 、更新和插入 ），包括由非标准接口所产生的变化。
• 用变化原因标记变化了的数据 ，以区分对错误更正和真正的更新 。
• 利用其他的元数据支持合规性跟踪 。
• 尽早执行CDC步骤 ，最好是在大量数据传输到数据仓库前完成 。

  获取数据变化不是一件小事 。您必须仔细评估针对每个数据源的获取策略 。确定适当的策略以区分变化的数据要采用一些侦察性的工作。前面讨论的数据分析任务有助于做出这样的决定 。获取源数据变化可以采取几种方式 ，每种方式都适合不同的环境，下面具体介绍它们。

1. 审计列
     某些情况下 ，源系统包含审计列 ，这些列存储着一条记录被插入或修改的日期和时间。 这些列一般是在数据库记录被插入或更新时 ，激活触发器而自动产生的 。有时，出于性能方面的考虑 ，这些列由源系统的应用而不是通过触发器产生的 。当这些不是由触发器而是由其他任何方式建立的字段被加载时 ，一定要注意它们的完整性，分析并测试每 一列以确保它们是表示变化的可靠来源 。如果发现存在空值 ，则一定要找到其他用于检测变化的方法。最常见的阻碍 ETL 系统使用审计列的情况是 ，当这些字段由源系统应用建立时 ，DBA 小组允许在后端用脚本对数据进行更新 。如果这种情况在您的环境中存在 ，则会面临在增量加载期间丢失变化数据的风险。最后 ，您需要理解当一个记录被从源中删除时会发生何种反应 ，因为查询和审计列可能无法获得删除事件。

2. 定时获取
     在采用定时获取方法时，通常会选择所有那些建立 期或修改日期字段等于 SYSDATE-1（意思是昨天的记录）的行。听起来很完美 ，真是这样吗 ？错误 。纯粹按照时间 加载记录是那些没有经验的 ETL 开发者常犯的错误。这一过程非常不靠谱 。基于时间选择加载数据的方式 ，当中间过程出现错误需要重启会多次加载行 。这意味着无论加载过程由于何种原因失败，都需要人工干预并对数据进行清洗 。同时，如果晚间加载过程失败并推迟了一天， 那就意味着丢失的数据将无法再进入数据仓库中 。

3. 全差异比较
     全差异比较将保存所有昨天数据的快照 ，并与之进行比较 。将其与今天的数据逐个比较，找到那些发生了变化的数据 。这一技术的好处是它非常严密 ：可保证找到所有的变化 。 明显的缺点在于，多数情况下 ，采用这一技术对资源的消耗巨大 。如果需要使用全差异比较，则尽力利用源机器 ，这样不需要将整张表或数据库保存在 ETL环境中 。当然，这样做会招致源支持方的意见 。同样，可以研究使用循环元余校验（ Cyclic Redundancy Checksum , CRC)算法快速检测出某个复杂的记录是否发生了改变而不需要对每个字段进行检验 。

4. 数据库日志抓取
     有效的日志抓取利用时间计划点（通常是午夜时间）的数据库重做日志快照并在那些 ETL 加载用到的受影响的表的事务中搜寻 。检测包括轮询重做日志 ，实时获取事务 。抓取日志事务可能是所有技术中最杂乱的技术 。事务日志经常会被装满并阻碍过程中新事务的 加入 。当这种情况发生在生产事务环境时 ，负责任的DBA 可能会立即清空日志 ，以便能够 让业务操作继续开展 ，但是一旦日志被清空，日志中包含的所有事务都会丢失。如果您耗 尽精力使用所有技术 ，并最终发现日志抓取是您发现新的或变化的记录的最后手段 ，一定 要告诉 DBA ，请他为满足您的特 殊要求建立一个专门的日志 。

5. 消息队列监控
     在一个基于消息的事务系统中，监视所有针对感兴趣表的事务的队列 。流的内容与日志探索差不多 。这一过程的好处之一是开销相对较低 ，因为消息队列己经存在 。然而，消息队列没有回放功能 。如果与消息队列的连接消失 ，将会丢失数据 。

3.3 子系统 3：获取系统

  显然，从源系统中获取数据是ETL结构的基础部件 。如果所有的源数据都在一个系统中，且可以使用ETL工具随意获取 ，那您真是太幸运了 。多数情况下 ，每个源都位于不同的系统中，处于不同的环境并采用不同的数据库管理系统 。

  ETL 系统可能会被要求从范围广泛的系统中获取涉及多种不同类型和固有难题的数据 。组织需要从常会遇到像 COBOL 复制手册 、EBCDIC 到 ASCII 转换 、压缩十进制 、重新定义、OCCURS 字段以及多个可变记录类型等 问题的主机环境中获取数据 。另外一些组 织可能需要从关系 DBMS 、平面文件 、XML 源、Web 日志或复杂的 ERP 系统中获取 。每种获取都具有一定的难度 。有些源 ，特别是那些比较古老的遗留系统 ，可能需要使用不同 的过程语言 ，而不是 ETL 工具或小组的经验可以支持的 。在此情况下 ，请求所有者将他们的源系统转换为平面文件格式 。
注意：
  尽管使用自描述的XML格式数据有很多好处，但您仍然无法忍受大量的 、频繁的数据转换 。XML格式文件的有效部分还不到整个文件的10%。本建议的例外可能是 XML 有 效负载是复杂的深度层次 XML 结构 ，例如 ，工业标准数据交换 。在此情况下 ，DW/BI小组需要决定是否 “分解” XML 为 大量的目 标表或者坚持在数据仓库中使用 XML 结构。最 近关 系数据库管理 系统(RDBMS）提供商提供了 通过 XPath 支持 XML ，使后一种选择可操 作性更强 。

  从源系统中获取数据通常可以采用两种方法：以文件方式或者以流方式 。如果源处于古老的主机系统中，最容易的办法是采用文件方式 ，并将这些文件移动到ETL 服务器上 。
注意：
  如果源数据是无结构 、 半结构甚至是包含多种结构的 “ 大数据” ，那么与其将这些数 据以无法解释的 “blob” 类型加载到RDBMS 中，不如建立更有效的 MapReduce/Hadoop 获取步骤 ，作为 ETL 从源数据中获取事实的获取器，直接发布可加载的 RDBMS 数据。

  如果要在数据库中使用 ETL 工具且源数据在数据库（不限于 RDBMS）中 ，您可以将获取按照流来设置，其中数据流出源系统，通过转换引擎 ，以单一过程进入过渡数据库 。相比之下，文件获取方法包括三四个不同的步骤 ：获取文件 、将文件移动到 ETL 服务器 ，转换文件内容以及加载转换后的数据 到过渡服务器 。
注意：
  尽管流获取更有吸引力，但文件获取方式还是存在一些有利条件 。可以方便地在不同点重新开始。只要保存了获取的文件 ，就可以重新运行为口载，而 不会对源系统产生任何影响。将数据通过网络传输时，可以方便地加密和压缩数据 。最后，验证所有数据在移动过程中保持了正确性可以通过比较传输前后的文件行计数获得。一般来说，我们建议采用数据传输实用程序，如FTP，来传输获取的文件 。

  如果要通过公共网络或在距离比较长的情况下传输大量数据 ，对数据进行压缩后再传输是非常重要的 。在此情况下，通讯链路通常会成为瓶颈 。如果传输数据花费大量的时间， 则压缩可以减少 30% 50%或更多的传输时间 ，效果如何要看原始数据文件的属性。
  如果数据要通过公共网络传输或者在某些情况下 ，即使在内部传输，也需要对数据进行加密。处于这样的环境 ，最好考虑使用加密链路 ，这样就不用考虑l哪些需要加密 ，哪些 不需要加密 。记住在加密前压缩 ，因为加密后的文件压缩效果不好 。

3.4 清洗与整合数据

  清洗与整合数据是ETL系统的关键任务 。在这些步骤中, ETL系统将增加值到数据中 。 其他一些活动 ，获取和发布数据 ，显然也是必须存在的 ，但它们仅仅是移动和加载数据。 清洗和整理子系统对数据做出了实际的改变 ，并增加了数据对组织的价值 。此外，这些子系统可以被构建来建立用于诊断系统何处出现问题的元数据 。此类诊断最终会导致业务流程再造以解决脏数据产生的根本原因并随时间不断改进数据质量。

3.4.1 提高数据质量文化与过程

  对所有出现在流程中的错误，都试图批评原始数据源的问题 。若数据录入员再仔细一点该多好哇 ！我们应该对那些将产品和客户信息录入其订单表格的受到键盘挑战的销售人员多些宽容 。也许应当通过在数据录入用户接口增加限制性约束的方式来改善数据质量问题。该方法提供了有关如何考虑改进数据质量的提示 ，因为技术方面的解决方案通常能够避免真正问题的出现 。假定客户的社会安全号码字段常常出现空白或保存的是屏幕输入的 垃圾信息。有些人对此提出了 一种聪明的解决方法 ，要求输入必须满足 999-99-9999 这样 的格式，以此方式巧妙地避免了录入类似条目全部是 9 的情况发生。会发生什么情况呢 ？ 数据录入员必须输入合法的社会安全号 ，否则无法进入下一屏幕 ，因此当他们没有客户的号码时，只好通过人工号码避免这一障碍 。

  Michael Hammer 在其革命性的书籍 Reengineering the Corporation(Collins , 2003 年版） 中，用睿智的观察直击数据质量问题的核心 。Hammer 解释道：“看起来不起眼的数据质量问题，实际上是拆散业务流程的重要标志 。” 这一思想不仅能够引起您对数据质量问题的重视，而且还指明了解决之道 。
从技术的角度解决数据质量问题难以取得成功 ，除非它们是来自组织顶层的质量文化 的一部分。著名的日本汽车制造业对质量的态度渗入到企业的每个层次中，从 CEO 到装配线工人 ，所有层次都非常关注质量 。将其引入到数据环境中 ，设想某个大型连锁药店 ，一组买方与成千上万的提供库存的供应商签订合同 。买方助理的工作是键入每个购买药物的买方的详细信息 。这些药方包含大量的属性 。但问题是助理的工作非常繁重并且要考察买方们每小时输入的条目的数量 。助理几乎意识不到谁在利用这些数据 。偶尔，助理会因为出现明显的错误而受到批评 。但更可怕的是，提供给助理的数据本身是不完整和不可靠的。 例如 ，毒性等级没有规范的标准 ，因此这一属性会随着时间或产品分类而发生明显的变化 。 药店应该如何改进其数据质 量呢？这里提供一个包含 9 个步骤的模板 ，不仅适用于药店 ， 也可用于其他需要解决数据质 量问题的企业 ：
• 定义一个针对数据质量文化的高级别的承诺 。
• 在执行层面上发起过程再造 。
• 投资用于改进数据录入环境 。
• 投资用于改进应用集成 。
• 投资用于改变工作过程 。
• 促进端到端的团队意识 。
• 促进部门间合作 。
• 大力褒奖卓越的数据质量。
• 不断度量并改进数据质量。
  针对药店 ，需要加大投入 ，改进数据录入系统 ，为买方助理提供他们需要的内容和选择 。公司经理需要让买方助理意识到他们的工作非常重要并认识到企业价值的最终目标源于数据质量。

3.4.2 子系统 4：数据清洗系统

  ETL 数据清洗过程通常希望订正脏数据 ，同时希望数据仓库能够提供对组织生产系统中的数据的准确描述。在各种冲突的目标之间实现平衡是基本的要求 。
  在描述清洗系统时，目标之一是提供清洗数据 、获取数据质量事件 ，以及度量并最终控制数据仓库中的数据质量的全面结构 。一些组织可能发现实现这种结构具有挑战性 ，但我们相信对ETL小组来说 ，努力工作尽力争取将这些能力尽可能具体化是非常重要的。如果您是一位 ETL 方面的新手并发现实现这一工作具有严峻的挑战，那么您可能想知道 “ 我应该关注的最小内涵是什么 ？” 答案就是以实现最好的数据轮廓分析为起点 。这一工作的 结果有助于理解改善潜在的脏数据和不可靠数据的风险 ，井有助于确定您的数据清洗系统 需要完成的工作的复杂程度 。
清洗子系统的目标是汇总技术用于支持数据质量 。子系统的目标包括 ：
• 尽早诊断并分类数据质量问题。
• 为获得更好的数据而对源系统及集成工作的需求 。
• 提供在 ETL 中可能遇到的数据错误的专门描述。
• 获取所有数据质量错误以及随时间变化精确度量数据质量矩阵的框架 。
• 附加到最终数据上的质量可信度度量 。

1. 质量屏幕
     ETL 结构的核心是用于诊断过滤数据流流水线的质量屏幕集合 。每个质量屏幕就是一个测试 。如果针对数据的测试成功 ，就不会有事发生，并且屏幕没有副作用 。如果测试失败 ，则一定会在错误事件模式中出现错误行 ，并做出选择 ，是终止过程 ，将错误数据发送 到挂起状态 ，还是对数据进行标记 。
     尽管所有质量屏幕在结构上是类似的 ，但将其划分为以升序形式展现 的三种类别可方便处理 。Jack Olson 在其有关数据质量的开创性著作 Data Quality: The Accuracy Dimension (Morgan Kaufmann , 2002）中 ，将数据质量屏幕划分为三种类型：列屏幕 、结构屏幕和业务 规则屏幕 。
     列屏幕测试单一列中的数据 。这些测试通常是简单 的、 比较明显的 测试 ，例如 ，测试 某列是否包含未预 期的空值 ，某个值是否超出了 规定的范围，或者某个值是否未能遵守需 要的格式 。
     结构屏幕测试数据列之间的关系 。测试两个或更多的列以验证它 们是否满足层次要 求 ，例如 ，一系列多对 一关系。结构屏幕也对两个表之 间存在 的外键／主键 的约束关系进行 测试 ，还包括对整个列块 的测试，验证它们的邮政编码是否满足合法性 。
     业务规则屏幕实现由列和结构测试无法适应 的更复杂的测试。例如 ，可能需要测试与 客户档案有关 的复杂的与时间关联的业务规则，例如 ，需要测试那些申请终身白金飞行常 客的成员 ，要求至少有 5 年乘机历史 并且飞行距离超过 200 万公里 。业务规则屏幕也包括 聚集阙值数据质量检查 ，例如 ，磁共振成像检查是否存在某个统计上不可能出现的数字 ， 来源于极少出现的有手肘扭伤的诊断 。在此情况下 ，屏幕将会在达到 此类磁共振成像检 查阙值时弹出错误 。

2. 对质量事件的晌应
     我们已经讨论了在错误发生时决定如何操作的每种质量屏幕 。可选择的方式为 ：①终止过程 ：②将错误记录发送到搁置文件中，以便后续处理 ；③仅对数据进行标注并将其放到流水线的下一个步骤中 。无论处于何种情况，第 3 种选择是目前为止最好的选择 。终止处理显然不够好 ，因为诊断问题、重启或恢复作业或者完全中止等工作都需要人工参与处理。将记录发送到搁置文件通常也不是好的解决方案 ，因为并不清楚何时或者是否这些记录将被更正并重新进入流水线中 。在这些记录被恢复到数据流中之前 ，数据库的完整性无法得到保证 ，因为丢失了记录 。我们建议在少量数据错误时不要使用搁置文件 。以标记数据为错误数据的第 3 种选择方法通常效果较好 。不好的维度数据也可以使用审计维度进 行 标记 ，或者在面对丢失或垃圾数据的情况下 ，可以在属性上标记唯一错误值。

3.4.3 子系统 5：错误事件模式

  错误事件模式是一种集中式的维度模式 ，其目的是记录ETL 流水线中所有质量屏幕出现的错误事件 。尽管我们主要关注的是数据仓库的 ETL 过程 ，但该方法也可应用于 一般的需要在遗留应用之间传输数据的数据集成应用中 。错误事件模式如下图所示:

  在该模式中 ，主表是错误事件事实表 。其粒度是每个由 ETL 系统的质量屏幕抛出的（产生的）错误。记住事实表的粒度是对每个事实存在的原因的物理描述。每个质量屏幕错误在表中用一行表示 ，表中每行对 一个观察到的错误 。
  错误事件事实表的维度包括错误的日历日期 、错误产生的批处理作业以及产生错误的屏幕。日历日期不是产生错误的分或秒时间戳，相反，日历日期按照日历的通常属性（例如， 平日或某财务周期的最后 一天）提供一种约束井汇总错误事件的方法 。错误日期／时间事实是一种完整关联的日期／时间戳，精确地定义了错误发生的时间 。这种格式可方便计算错误 事件发生 的时间间隔，因为可以通过获得两个日期 ／时间戳之间的差别获得不同事件发生的 间隔时间。

  批处理维度可被泛化为针对数据流的处理步骤 ，而不仅仅是针对批处理 。屏幕维度准确地识别是何种屏幕约束以及驻留在屏幕上的是何种代码 。它也能够定义在屏幕 抛出错误时采取了什么措施 。例如 ，停止过程 、发送记录到挂起文件或标记数据 。

  错误时间事实表还包含一个单列的主键 ，作为错误事件的键 。此代理键类似于维度表主键 ，是一种随着行增加到事实表中而顺序分配的整数 。该键列同时被增加到错误事件事 实表中 。希望这种情况未发生在您所处的环境中 。

  错误事件模式包括另外一种粒度更细的错误事件细节事实表 。该表中每行确定与错误有关的某个特定记录的个体字段 。这样某个高级别的错误事件事实表中的单一错误事件行 所激活的复杂的结构或业务规则错误将会在错误细节事实表中用多行表示 。这两个表提供错误事件键关联 ，该键是低粒度表的外键 。错误事件细节表可区分表 、记录 、字段和准确 的错误条件 。因此复杂的多字段 、多记录错误的完整描述都将保存在这些表中 。

  错误事件细节事实表也可以包含准确的日期 ／时间戳，提供对聚集阔值错误事件的完整 描述 。聚集阔值错误事件中 的错误条件涉及某个时间段内的多条记录 。您现在应当能够感 觉到每个质量屏幕具有在错误发生时将错误添 加到表中的功能了 。

3.4.6 子系统 6：审计维度装配器

  审计维度是一种特殊的维度 ，用于在后端装配 ETL 系统的每个事实表 。如下图所示的审计维度包含当建立特定事实行时的元数据环境 。您可能会说我们将元数据提升到实际数据了 。考虑如何建立审计维度行 ，设想该货运事实表将按照批处理文件每天更新一次 。假设您今天工作顺利没有产生错误标记 ，此时 ，将建立唯一 的一行审计维度 ，将被 附加到今天所加载的所有事实行 。所有的分类 、分数和版本号都将 相同。

  现在，让我们去掉工作顺利的假设 。如果某些事实行 由于折扣值出现出界错误而被激 活，则需要不止一个审计维度行用于标记这一情况。

3.4.5 子系统 7：重复数据删除（deduplication ）系统

  通常维度来自多个源 。多个面向客户的源系统建立并管理不同的客户主表，这种情况 在组织中比较常见 。客户信息可能需要从多个业务项和外部数据源中融合获得 。有时 ，数据可以通过匹配同 一键列的相同值获得 。然而 ，即使在定义的匹配发生时 ，数据的其他列 相互之间也可能存在矛盾 ，需要确定保留哪些数据 。

  遗憾的是 ，很少存在统一的列能使融合操作更方便 。有时 ，唯一可用的线索是几个列 的相似性。需要集成不同的数据集合 ，已经存在的维度表数据可能需要对不同的字段进行 评估以实现匹配 。有时 ，匹配可能基于模糊评判标准 ，例如 ，对包含少量拼写错误的名字 和地址进行近似匹配 。

  数据保留（survivorship）是合并匹配记录集合到统 一视图的过程 ，该统一视图将从匹配 记录中获得的具有最高质 量的列合并到一致性的行中 。数据保留包括建立按照来自所有可能源系统的列值而清楚定义了优先顺序的业务规则 ，用于确保每个存在的行具 有最佳的保留属性。如果维度设计来自多个系统 ，则必须维护带有反向引用的不同列 ，例如自然键 ， 用于所有参与的源系统行的构建工作 。

  考虑到重复数据删除 、匹配和数据保留等问题的困难性 ，目前有大量的数据集成和数据标准工具可用 。这些工具非常成熟且应用非常广泛。

3.4.6 子系统 8：一致性系统

  一致性处理包含所有需要调整维度中的 一些或所有列的内容以与数据仓库中其他相 同或类似的维度保持一致的步骤 。例如 ，在大型组织中 ，可能有一个获取发票和客户服务呼叫同时又都利用了客户维度的事实表 。通常发票和客户服务的数据来自不同的客户数据库。通常情况下 ，来自两个不同客户信息源的数据很少能保证具有一致性 。需要对来自这 两个不同客户源的数据进行一致性处理 ，使某些或所有描述客户的列能够共享相同的领域。

注意：
  建立一致性维度的过程要采用敏捷方法 。对两个需要一致性处理的维度 ，它们必须至少有一个具有相同名称和内容的公共属性 。您必须考虑使用单一的一致性属性 ，例如 ，客户分类 ，让其不受任何影响地添加到每个面向客户的过程中的客户维度中 。在添加每个面向客户的过程时 ，扩展可以集成的过程列表并使其能够 参与横向钻取查询过程 。还可以增 量式添加一致性属性的列哀 ，例如 ，城市 、省和国 家等。所有这些都可以分阶段采用更敏捷的方法实现。

  一致性子系统负责建立并维护。要实现这些工作，需要合并且集成从 多个源输入的数据 ，因此需要其内容行具有相同的结构、重复数据删除 、过滤掉无效数据 、标准化等特点 。一致性处理的主要过程是如前所述的重复数据删除 、匹配和数据保留处理过程 。一致性过程流对 重复数据删除和数据保留过 程的合并如下图所示:

3.5 发布：准备展现

  ETL 系统的主要任务是发布阶段切换维度和事实表 。出于这样的原因 ，发布子系统是 ETL 结构中最为重要的子系统 。尽管数据源结构和清洗以及 一致性逻辑有相当大的变化 ， 但准备维度表结构的发布处理技术更加明确且严格 。使用这些技术对建立一个成功的维度 数据仓库 ，使其具备可靠 、可扩展和可维护的性能是至关重要的 。

  大多数此类子系统关注维度表处理过程 。维度表是数据仓库的核心 。它们为事实表及 所有的度量提供环境 ，尽管维度表通常 比事实表小得多，但它们对 DW/BI 系统的成功起关 键的作用 ，因为它们为事实表提供了接入点 。发布过程始于 刚刚描述的子系统对清洗和对数据的一致性处理。对多数维度来说 ，基本加载规划相对要简单 一些：执行基本的对数据的转换并建立维度行，加载到目标展现表中 。这一过程通常包括代理键分配 、代码查找以提供适当的描述 、划分或合并列以表示适当的数据值 ，或连接底层的符合第 3 范式格式的 表结构使其成为非规范的平面型维度 。

  事实表的准备也非常重要 ，因为事实表拥有用户希望看到的针对业务的关键度 量 。事 实表可能非常大并且需要大量的加载时间 。然而 ，准备用于展现的事实表通常更为明确 。

3.5.1 子系统 9：缓慢变化维度管理器

  ETL 结构中最为重要 的元素之一是实现缓慢变化维度（Slowly Changing Dimension , SCD）逻辑的能力 。ETL 系统必须确定当己经存在于数据仓库中的属性值发生变化时的处理方法。如果确定当被修改的描述是合理的且需要更新原有信息时 ，必须应用适当的 SCD 技术。

  当数据仓库收到通知 ，维度中存在的行发生变化时 ， 可以采用 3 种基本响应 ：类型 1 重写 ；类型 2 增加新行 ：类型 3 增加新列 。在使用这 3 种 技术以及其他 SCD 技术时 ，SCD 管理器应该系统化地处理维度中的时 间差异。此外，SCD 管理器应该为类型 2 变化维护适当的 管理列。

  在表达变化数据的 SCD 处理中 ，子系统 2 中所描述的变化数据获取过程显然扮演了 一 种重要的角色 。如果变化数据 获取过程有效地发布了适当的变 化，SCD 处理就可以采取适 当的行动。

1. 类型 1：重写
     类型 1技术简单地在己有维度行中重写一个或多个属性 。将从变化数据获取系统中获 取的修改后的数据重写到维度表中的相应内容 。当需要改正数据或对先前值没有保存的业务需求时 ，类型1是比较适当的 。例如，您可能需要改正客户的地址 。在此情况下，重写是正确的选择 。注意，如果维度表包含类型 2 变化跟踪 ，应当重写该客户的所有受影响的列。类型 1 更新必须传播到前面早期已经永久存储的阶段表，并重写所有受影响的阶段表中的数据，这些阶段表如果被用于重建最终的加载表时，才会体现出重写的影响效果 。
     某些 ETL 工具包含 “UPDATE else INSERT” 功能。该功能可能给开发者带来方便， 但可能会成为性能杀手 。为了最大程度地提高性能，对已经存在的行的更新应该与对新行 的插入操作分离 。如果类型 1更新引起性能问题 ，可考虑禁用数据库日志或使用 DBMS批量加载功能。
     类型 1 更新会使所有建立在改变列上的聚集操作都失效 ，因此维度管理器（子系统 17)
     必须通知受影响的事实提供者（子系统 18）删除并重建受影响的聚集。

2. 类型 2：增加新行
     类型 2 SCD 是一种用于跟踪维度变化并将其与正确的事实行关联的标准技术 。支持类型2变化需要强大的变化数据获取系统 ，用于检测发生的变化。对类型 2 更新来说 ，复制先前维度行的版本 ，从头开始建立新行 。然后更新行中发生变 化的列并增加所需要的其他 列。这一技术是处理 需要随时间而跟踪的维度属性变 化的主要技术 。
     如果 ETL 工具不提供更新多数最近的代理键映射表这样的功能的话，类型 2 ETL 处理 需要具备该功能 。在加载事实表数据时 ，这些包含两列的小型表具有巨大 的作用。子系统 14，即代理键流水线，支持这一处理 。
     参考上图，观察在获取过程期间处理变化维度行的 查询和键分配逻辑 。在该示例中 ， 变化数据获取过程（子系统 2）使用循环元余校验（CRC) 比较方法来确定上次更新以来，源数据的哪些行发生了变化。幸运的话，您已经知道哪些维度记录发生了变 化，可以忽略 CRC 比较步骤 。在确认变化的行涉及类型 2 变化后 ，可 以按照键序列建立新 的代理键井更新代 理键映射表。
     当新的类型 2 行被建立后，至少需要一对时间戳 ，以及一个可选的描述变化的属性。时间戳对定义了从开始有效时间到结束有效时间之间的时间范围 ，这一范围指明了整 个维度属性的合法期 。建立类型 2 SCD 行更复杂的方法是增加 5 个附加的 ETL 管理列 。参考 上图，这需要类型 2 ETL 过程找到先前有效的行并对这些管理列进行适当的更新。
   • 改变日期（改变日期作为日期维度支架 表的外键）
   • 行有效日期／时间（准确 的发生变化时的日期／时间戳）
   • 行截止日期／时间（准确 的下一次变化的日期／时间戳，大多数 当前维度行的默认值 为 12/31/9999)
   • 列变化原因（可选属性）
   • 当前标志（当前／失效）

注意：
  在事务数据库中运行的后端脚本有可能会修改数据 ，而没有更新相应的元数据字段 ， 例如，last modified date。维度时间戳使用这些字段时可能在数据仓库中产生不一致的结果。因此要始终坚持使用系统或截止日期来获取类型2有效时间戳。

  类型 2 处理不会像类型 1 那样对历史情况做出改变，因此类型 2 变化不需要重建受影响的聚集表，只要变化是 “今天” 而不是之前发生的 。

3. 类型 3：增加新属性
     类型 3 技术用于支持属性发 生 “ 软” 变化的情况，允许用户既可以使用属性旧值也可以使用新值。例如，如果销售小组被分配了新的销售区域名称 ，则有可能既需要跟踪原区域名的情况 ，还需要跟踪新区域名的情况 。如果未预先考虑这种情况，那么使用类型 3 技 术需要 ETL 系统对维度表做出改变 ，在模式中增加新列 。当然 ，与 ETL 小组共同工作的 DBA 最有可能负责这一工作。您需要将己经存在的列值添 加到新增加的列中 ，并在原列中 存储 ETL 系统提供的新值 。
   

  与类型1处理类似，类型3变化更新将会导致所有针对更新列所做的聚集失效。维度管理器必须通知受影响的事实提供者，使他们能够删除并重新建立受影 响的聚集。

4. 类型 4：增加微型维度
     在维度中的一组属性变化非常快的情况下 ，需要将它们划分到微型维度上 ，此时将采用类型 4 技术 。这种情况有时被称为快速变化超大维度 。与类型 3 一样，这种情况要求改变模式 ，希望在设计阶段就做好 。微型维度需要有自己的唯 一主键 ，主维度的主键和微型 维度的主键都必须出现在事实表中 。
   

5. 类型 5：增加微型维度和类型 1 支架
     类型 5 技术建立在类型 4 微型维度基础之上 ，同时在主维度的微型维度上嵌入类型 1 引用。这样可允许直接通 过主维度访 问微型维度上的当前值 ，而不需要通过事实表连接 。 只要微型维度 的当前状态随时间而发生了变 化 ，ETL 小组就必须在主维度上增加类型 1 键引用且必须在所有主维度的副本上重写该键引用。
   

6 . 类型 6：在类型 2 维度中增加类型 1 属性
  类型 6 技术包含 一个嵌入属性 ，用于作为通常的类型2属性的替换值。通常该属性就是类型3的另一种实现 ，但是在此情况下，一旦属性被更新 ，该属性将被系统性 地重写。

7. 类型 7：双重类型 1 及类型 2 维度
     类型 7 技术是一种常见的类型 2 维度 ，与特定构建的事实表成对出现 ，它们均有一个与维度关联的常态化的外键 ，用于处理类型2历史过程 ，另外也包含一个持久性外键，用于替换类型 1 当前过程 ，连接到维度表的持久键标记为 PDK 。维度表还包含 当前行标识，表示该行是否用作 SCD 类型 1 场景。ETL 小组必须增加一个正常构建的包含 该常量值持久性外键的事实表 。
   

3.5.2 子系统 10：代理键产生器

  我们强烈建议在所有维度表中使用代理键 。要实现这一工作 ，需要一个为 ETL 系统产生代理键的健壮的机制。代理键产生器应能独立地为所有维度产生代 理键 ；它应当独立于数据库示例并能够为分布式客户提供服务 。代理键产生器的目标是产 生无语义的键 ，通常是一个整数 ，将成为维度行的主键 。

  尽管可以通过数据库触发器建立代理键 ，但使用该技术可能会产生性能瓶颈 。如果由 DBMS 来分派代理键 ，这样对 ETL 过程是最好的，不需要 ETL 直接调用数据库序列产生器 。 从提高性能的角度考虑，可让 ETL 工具建立井维护代理键。要避免级联源系统的操作型键与 日期／时间戳的诱惑。尽管该方法看起来很简单 ，但始终会存在 问题，最终无法实现可扩展性 。

3.5.3 子系统 11：层次管理器

  在维度中通常具有多个同时存在的、嵌入的层次结构。这些层次以属性的形式简单地共存于同一个维度表中 。作为维度主键的属性必须具有单一值 。层次可以是固定的也可能是参差不齐的。固定深度的层次具有一致的层次号，简单地将其建模井将不同的维度属性 添加到每个层次上就可以 。类似通信地址这样轻微参差不齐 的层次往往被建模 成固定层次。

  参差不齐程度较深的层次通常都存在于组织结构中 ，具有不平衡及不确定的深度 。数据模型和ETL解决方案若需要支持此类需求，则需要采用包含组织映射的桥接表 。

  不建议采用雪花或规范化数据结构表示层次 。然而，在 ETL 过渡区使用规范化设计可能是比较适合的，可用于辅助维护 ETL 数据流以添加或维护层次属性。ETL 系统负责强化 业务规则以确保在维度表中加入适当的层次 。

3.5.4 子系统 12：特定维度管理器

  特定维度管理器是一种全方位的子系统 ：一种支持组织特定维度设计特征的 ETL 结构 的占位符。一些组织的 ETL 系统需要这里将讨论的所有能力 ，另外一些可能仅需要其中的 一些设计技术 。

1. 日期／时间维度
     日期和时间维度是唯一 一种在数据仓库项目开始时就完整定义的维度 ，它们没有约定的来源 。这很好 ！通常，这些维度可能是在某个下午与报表一起构建的 。但是当处理的是跨国组织环境时 ，考虑到多个财务报表周期 或多种不同的传统日历，即使这样一个简单的维度也会带来挑战 。

2. 杂项维度
     杂项维度涉及那些当您从事实表中删除 所有关键属性后遗留下来的文本和繁杂的标 识。在 ETL 系统中可以采用两种方式建立杂 项维度 。如果维度中行的理论上的号码确定并 己知，则可以预先建立杂项维度 。其他情况下 ，可能需要在 处理事实行输入时匆忙地建立 新观察到的杂项维度行 。这一过程需要聚集杂项维度属性并将它 们与己 经存在的杂项维度行 比较，以确定该行是否己经存在 。如果不存在 ，将组建新的维度行 ， 建立代理键，在处理事实表过程中适时地将该行加载到杂项维度中 。
   

3. 微型维度
     正如在子系统9中所讨论的那样 ，微型维度是一种用于在大型维度中当类型 2 技术不可用时 ，例如 ，客户维度，跟踪维度属性变 化的技术。从 ETL 的角度来看 ，建立微型维度 与刚刚讨论过的杂项维度处理类似 。再次说明 ，存在两个选择 ：预先建立所有的合法组合或重组并及时建立新的组合 。尽管杂项维度通常是根据事实表输入建立 ，但微型维度往往 是在维度表输入时建立 。ETL 系统负责维护多列代理键查询表 以确定基本维度号码和适当 的微型维度行 ，支持子系统 14 中将要描述的代理流水线过程 。记住，非常大的 、复杂的客户维度通常需要多个微型维度 。

4. 缩减子集维度
     缩减维度是一种一致性维度，其行与／列是基维度的子集 。ETL 数据流应当根据基维 度建立一致性缩减维度 ，而不是独立于基维度 ，以确保一致性 。然而 ，缩减维度的主键必 须独立地构建 ，如果试图使用来自于 “样例” 基维度行的键 ，则当该键被弃用或废除 时将 会带来麻烦 。

5. 小型静态维度
     某些维度可能是由ETL系统在没有真实的外部来源的情况下建立的 。这些维度通常是小型的查询维度 ，在该维度中操作型代码被转换为字词 。在此情况下 ，并不存在真正的 ETL 处理。查询维度简单 地由 ETL 小组直接建立 ，其最终格式为关系表 。

6. 用户维护的维度
     通常数据仓库需要建立全新的 “主 ” 维度表。这些维度没有正式 的记录系统。它们是由业务报表和分析过程建立的自定义描述 、分组和层次 。ETL 小组建立这些维度通常是出 于受托责任 ，但是这样做往往不会成功 ，因为ETL 小组并不知道这些自定义分组的变化 情 况，因此这些维度会变得令人烦恼且低效 。最佳应用情况是由适当的业务用户部门负责维 护这些属性 。DW/BI 小组需要为维护工作提供适当的接口 。通常 ，这一工作呈现出简单应 用的形式并使用公司的标准可视化编程工 具建立 。ETL 系统应该为新行添加默认属性值 ， 然后由负责维护的用户进行更新 。如果这些行在没有 发生变化的情况下被加载到数据仓库中，则它们仍然会 以默认描述的方式出现在报表中 。

3.5.5 子系统 13：事实表建立器

  事实表拥有组织的度量 。维度模型将围绕这些数字度量构建 。事实表建立器关注ETL结构化需求以有效 地建立三种主要的事实表类型 ：事务、周期快照和累积快照 。在加载事实表时一个主要的需求是维护相关维度表之间的参照完整性 。代理键流水线 （子系统 14）就 是设计来帮助实现该需求的 。

1. 事务事实表加载器
     事务粒度表示一种以特定时刻定义的度量事件 。发票的列表项就是一种事务事件的示例 。现金收款台的扫描设备事件是另外一种示例 。在这些示例中 ，事实表的时间戳非常简单 。要么是一种简单的日历粒度外键 ，要么是一对包含日期 ／时间戳的日期粒度的外键 ，这 取决于源系统提供的是什么以及分析需求 。该事务表 的事实必须与粒度吻合并且仅应该描 述在那个时刻发生了什么。
   事务粒度事实表是三类事实表中最大且最详细的事实表 。事务事实表加载器从