一. 建模过程概述
开始讨论维度建模设计工作前，必须考虑正确的人选 。最值得注意的是，我们强烈主张业务代表参加建模会议 。他们的加入与合作必然会增加最终模型解决用户需求的可能性。同样，组织的业务数据 管理人员也应该参加 ，特别是当讨论涉及那些由他们来管理的数据时。
维度模型的构建是一个具有高度动态性且需要迭代产生的过程 。最初的准备过程完成后，设计工作将开始处理从总线架构获取的图形化模型 ，确定设计范围并澄清所提出的事实表及相关维度表的粒度 。
高级模型设计完成后，设计小组将开展针对维度表属性 、领域值 、来源 、关系、数据质量关注点和转换等方面的工作。确定维度后，将建模事实表 。建模过程的最后阶段是与感兴趣的伙伴，特别是业务代表们一起对模型进行评审和验证工作 。主要目标是建立满足用户需求的模型 ，检验加载到模型中的数据的可用性，为ETL小组提供最初的源到目标的映射。
维度模型通过一系列设计会议展开，每一次会议将产生更详细 、更健壮的按照业务需求反复测试过的设计结果 。当模型清楚地满足用户需求后，结束建模过程。通常需要三四周时间完成一次业务过程维度模型的设计 ，当然需要的时间会随着小组的经验 、详细业务需求的可用性 、涉及的业务代表或授权负责管理组织数据的人员 、数据源的复杂程度 、利用现存一致性维度的能力等的差异而存在较大的差异。
二. 组织工作
开始构建模型前，为使维度建模过程能够顺利开展 ，必须开展适当的准备工作。除准备好适当的资源外，还需要考虑后勤保障问题，以便能够富有成效地开展设计工作 。
2.1 确定参与人 ，特别是业务代表们
最好的维度模型往往是小组努力协同工作的结果 。没有哪个个人能够掌握有效地建立模型所需要的业务需求的所有知识以及源系统的所有特性 。尽管数据建模人员能够使建模过程更加容易并专门负责交付物，但我们相信让业务出身的主题业务专家参与其间是至关重要的：他们的见识是无价之宝 ，特别是因为他们是那些能够指出如何从源数据中得到数据并将这些数据转换为有价值的分析信息的人员 。尽管在设计活动中加入更多的人会增加过程变慢的风险，但得到丰富的、完整的设计可以证明这一额外的开销是值得的 。
让某些具备实际涉及的源系统的知识的人参与是非常有益的 。您可以将数据库管理员 (DBA）和 ETL 小组代表加入到小组中 ，这样他们既能够学习到建模工作过程中揭示的知识 ， 又能够抵制应用第 3 范式 (3NF)概念的诱惑或按照BI 应用的复杂性努力使 ETL 过程更加合理。记住目标是在 ETL 过程的复杂性与 BI 展现层的简单性和可预测性之间取得平衡 。
深入讨论建模过程前，应该花点时间考虑正在开展的DW/BI 环境问题 。如果组织正在考虑数据治理和管理计划 ，那么现在正是开展这 一计划的合适时间 。如果没有相关的管理 计划 ，则正好是开始这 一计划的良机 。企业 DW/BI 工作致力于维度建模同时也必须致力于 一致性维度策略 以确保整个企业业务过程的 一致性 。有效的数据管理程序能够帮助组织实 现一致性维度策略 。在大型企业中要实现 一致性维度是非常困难的 。问题通常主要不在技术方面 ，而是组织交流和达成共识的挑战 。
企业中不同的小组通常致力于自己专有的业务规则和定义 。数据管理人员必须与相关的小组紧密合作，开发公共的业务规则和定义 ，然后在组织中游说 ，让大家都使用公共规则和定义以获得企业的一致认可 。多年来，始终有人在批评一致性维度 “太强硬”。是的 ， 让企业中不同领域的人们同意采用公共的属性名称、定义及数值是非常困难的事情 ，但这样做的要义在于能够获得统 一的、集成的数据 。如果每个人都使用自己的标识和业务规则， 就没有办法发布一种 DW/BI 系统承诺提供的统一版本的真实集合 。最后，Kimball 方法时常被批评说它对那些希望找寻快速解决方案的人来说非常困难的原因之 一是我们阐述了实际完成工作的详细步骤。
2.2 业务需求评审
开始建模之前，小组必须熟悉业务需求 。第 1 步是仔细评审业务需求文档 。将业务需求转换为灵活的维度模型，用于支持范围广泛的分析，而不是仅仅支持特定的报表 。某些设计人员试图跳过需求评审直接进入设计，如果这样做，最后建立的模型通常是源数据驱动的而没有考虑业务团体需要的增加的价值 。让业务代表加入到建模小组中有助于避免此类数据驱动的方法 。
2.3 利用建模工具
开始建模活动前 ，准备一些工具是非常必要的。使用电子报表作为最初的文档工具是 有效的 ，因为利用它可以在反复法代过程中方便井快速地实施变更 。
在建模活动进入最后阶段后，可以方便地将工作转换到企业所使用的任何类型的建模工具中。多数建模工具都支持建立维度模型的维度设计功能 。在详细设计完成后 ，建模工具可帮助DBA 将设计的模型 置换到数据库中 ，包括建表 、索引、分区 、视图及数据库的其他物理元素 。
2.4 利用数据分析工具
在整个建模过程中 ，小组需要随着理解深入不断地开发源数据结构 、内容、关系和获取规则。需要对处于可用状态的数据进行验证 ，或者至少可以对缺陷进行管理，了解在将它们转换到维度模型时需要做些什么 。数据分析（data profiling）利用查询能力探索源数据系 统中实际存在的内容和关系 ，而不要依靠那些不完整的或过期的文档 。简单的数据分析工 作可以通过编写简单的 SQL 语句实现 ，复杂的数据分析工作可以通过专用工具来实现 。主 要的 ETL 提供商提供的产品 一般都包括数据分析功能 。
2.5 利用或建立命名规则
在建立维度模型的过程中 ，不可避免地会遇到命名规则的问题 。数据模型的标识必须 是描述性的并且与业务场景 一致 。表 和列名是 BI 应用接口的关键元素 。类似 “ 描述 (Description ）” 这样的列名在数据模型环境中可能己非常清楚了 ，但对于报表环境来说 ，这 样的命名显然达不到交流的效果 。
设计维度模型的部分过程集中于对公共定义和标识的认定 。由于不同的业务小组可能对同一个名称具有不同的理解（同名异义 ），或者不同的名称表示的 是同种含义（异名同义）， 结果使命名工作非常困难 。人们一般都不愿意放弃自己熟悉的词汇而采用新的词汇 。在命名规则上花费时间是一种看起来意义不大 ，但从长远来看意义重大的任务 。
大型组织通常设有 IT 部门，专门负责命名规则 。常用的方法是采用包含 三个部分的命 名标准 ：主词、限定词（如果适合的话） 、类词 。利用IT部门的工作成果 ，充分理解对有 已经存在的命名规则进行扩展能够支持形成更有利于商业交流的表和列名 。如果组织没有现成的命名规则，则必须在维度建 模过程中建立命名规则 。
2.6 日历和设施的协调
最后但并非不重要的是 ，需要按照参与者的日程安排来设计会 议日程 。不一定要利用整天的时间 ，可以每周利用三 四天的上午和下午召开持续时间为两三个小时的会议 ，这是 比较现实的。这一方法充分考虑到小组成员可能会有其他工作需要处理 ，这样留出会前、会间和会后的时间让他们能够处理于头的工作 。设计小组可以利用非会议时间研究源数据并确认需求，留出时间让数据建模人员在每次会议前更新设计文档 。
如前所述，建模过程通常会用三四周的时间对单一过程开展建模工作 ，例如 ，销售订单，或对紧密相关的业务过程开展建模工作，例如，处于不同的但密切相关的事实表中的健康设施和专业要求事务 。多种因素会对工作量造成影响 。最终，先前已经存在的核心维度的可用性使建模工作能够特别关注事实表的性能度量 ，这样能够显著地降低开展工作所 需要的时间。
最后，您必须保留适当的设施 。在设计工作期间 ，最好能够保留 一个专用的会议室 ， 当然在大多数组织中 ，这一想法不易实现 ，因为会议室总是不够用 。如果会议室的四壁都 有从地板到天花板的自板那就更好了 。除了会议设施外 ，小组还需要一些基本的用品 ，例 如，自粘白板纸。会议期间通 常需要电脑投影仪，设计评审绝对离不开它 。
三. 维度模型设计
在设计维度模型 期间存在 4 个关键决策 ：
• 确定业务过程
• 声明业务过程的粒度
• 确定维度
• 确定事实
第 1 步确定业务过程通常按照需求获取的结果来确定 。以此为基础 ，小组可以开展相关的设计任务。
• 定义模型范围和粒度的高级模型
• 详细设计每个表的属性和度量
• IT 和业务代表的评审和验收
• 设计文档定稿
要完成所有 的数据建模工作 ，维度建模要采取法代方式开展 。对需求和源细节要反复 考虑以进一步精炼模型 ，随着理解的不断深入 ，对模型进行必要 的修改。
3.1 统一对高层气泡图的理解
设计会议的初始任务是建立目标业务过程 的高层维度模型图。由于您是从总线矩阵开始的 ，所以第1个草图的建立相对比较直接 。尽管有经验的设计人员可能会设计出初始的 向层维度模型井展示给 小组用于评审 ，但我们仍然建议不要采用 这种方法 ，因为它没有使整个小组参与到过程中。
高层图图形化地表示了业务过程的维度和事实 表 ，如下图所示 。出于明显可见的原因，我们将其称为气泡图 。这一实体级的图形化模型确定了事实表和与之相关的维度表的粒度，清楚地展现给非技术人员。
粒度描述需要建模小组考虑满足业务需求需要什么以及物理数据源能够提供什么数据 。气泡图必须根据可用的物理数据设计 。总线矩阵 的一行可能会用多个气泡图表示 ，每个气泡阁对应具有特定粒度的特定事实表 。
大多数主要的维度在确定了粒度后可以自然地获得 。清楚的事实表粒度声明的重要影响之一是可以精确地以图示化方法表示有关的维度 。维度的选择也可能会导致您重新思考粒度声明 。如果提出的维度无法匹配事实表的粒度 ，那么要么不用该维度 ，改变事实表的粒度 ，要么考虑使用多值设计解决方案 。
关方交流时介绍项目 、项目范围以及数据内容 。
为帮助理解 ，在给定业务过程的多个高层模型图之间保持 一致性是非常有益的 。尽管每个事实表被文档化到不同的页面中，将相关的涉及多个气泡图的维度安排到 一个相似的 系列中是非常有用的 。
3.2 开发详细的维度模型
在高层气泡图设计完成后 ，就可以开始关注细节了 。小组应该定期见面，以便逐表逐列地定义详细的维度模型 。业务代表应该参加此类交互会议 ，您需要他们对属性 、过滤器 、分组、标识和度量的反馈 。
最有效的方法是先开始设计维度表 ，然后考虑设计事实表 。我们建议在开始细节设计过程时己经具备明确的维度表。日期维度一般可以作为首选开始考虑的维度表 。这样能够确保建模小组更早地获得成功 ，理解建模过程 ，并学会作为一个 小组而共同工作 。
详细建模确定每个维度内有趣且有用的属性 ，并确定每个事实表应该具有的适当的度量 。您也希望获取源 、定义以及如何获得这些属性和度量的基本业务规则 。在设计会议期间对源系统和系统化数据概要的持续分析，将有助于小组更好地理解其拥有的源数据的实际情况。
确定维度及其属性
在详细设计阶段 ，将定义关键的一致性维度 。因为 DW/BI 系统是企业的资源 ，所以这些定义必须为整个企业所接受 。数据管理人员和业务分析师是获得组织一致认可的表和属性命名、描述和定义的关键资源 。设计小组将主导该过程的展开井利用命名规则 （如果存在的话）。但是对标准业务定义和名称达成致是最终的业务任务，其列名对业务用户来说必须具有意义 。这一过程可能需要一定的时间才能完成，但这一投资可以获得巨大回报 ，其结果是用户愿意并接受维度模型 。毫无疑问 ，管理指导委员会必须参与解决一致性维度和命名问题 。
在此点上，建模小组通常还需要充分考虑维度模型中可能包含的杂项维度和微型维度 。直到小组深入开展设计工作后 ，这些更关注性能的模式才可能会有存在的必要性 。确定事实
声明粒度是对事实表度量讨论的成果，因为事实都必须与粒度保持一致 。数据分析工作确定了由源系统的度量事件建立的计数和数量。然而，事实表并不会受制于这些 基表 。 可能会存在业务需要分析的来自基表的其他度量。确定缓慢变化维度技术
根据高层模型图初步设计好维度和事实表后，应当再次考虑维度表的设计 。针对维度表的每个属性 ，需要定义在源系统数据发生变化时，对维度表会产生何种影响 。再次强调， 业务数据管理员是建立适合的规则的重要来源 。有益的方法是询问源系统专家是否能够确 定某个数据元素的变化是由于源数据变化所引起的。建立详细的表设计文档
详细建模阶段的关键交 付品是设计工作单 。在我们的网站 WWW. kimballgroup.com 上 ，从书名 The Dαtα Warehouse Lifecycle Toolkit, Second Edition 下面的 Tools and Utilities 可以获得其数字化模板 。通过与感兴趣的业务相关方以及其他分析型业务 用户、BI 应用开发人员 ，以及最重要的参与设计任务的 ETL 开发人员交流获取工作单的各 个细节 。
应该为每个维度和事实表建立不同的工作单。支持信息至少应该包含属性 ／事实名称 、描述示例值 、每个维度属性的缓慢变化维度类型标识 。此外 ，详细的事实表设计应该确认每个外键关系 、适当的退化维度 ，以及表明每个事实是可加 、半可加还是不可加的相关规则。
维度设计工作单是建立源到目标映射文档的第 1 步。物理设计小组将不断充实物理表 以及列名、数据类型和有关键的声明 。对模型出现的问题进行跟踪
在设计过程中发 现的所有问题 、定义、转换规则和数据质量挑战必须记录到问题跟踪日志中。会议期间应指派专人获取并跟踪相关问题 。如果项目经理参与设计会议，则通常由他们担负这一责任，因为他们通常精于更新有关问题并负责推进解决发现的问题 。协调人在每次会议结束前应该留出适当的时间用于评审和验证新的问题条目并为发现的问题指派负责人。在两次会议期间，设计小组通常忙于分析数据 ，澄清并达成大家认可的定义， 与源系统专家会面以解决突出的问题。
- 维护并更新总线矩阵
在详细建模过程中 ，通常对被建模的业务过程会有新的发现。常见的情况是，这些新发现可能会引入新事实表以支持业务过程，可能产生新维度，也可能需要重新划分或合并维度 。在整个设计过程中，必须始终保持对总线矩阵的更新，因为总线矩阵是关键的交流和规划工具。详细的总线矩阵通常获 取有关事实表粒度和度 量的额外信息。
3.3 模型评审与验证
一旦设计小组对模型充满信心后 ，过程将进入到评审与验证阶段，以从其他有关小组 获得针对模型的反馈意见 ，包括 ：
• IT 资源，例如 ，未参加建模工作的 DW/BI 小组成员 、源系统专家以及 DBA 等
• 未参与建模工作的分析或强力商业用户
• 范围广泛的商业用户团体
IT 平审
通常，对详细维度模型的第 1 次评审主要由 IT 组织同行参与 。评审人员通常由非常熟悉目标业务过程的人员组成，因为他们设计或管理运行 的系统。至少他们可能熟悉部分的 目标数据模型，因为您己经就与源数据相关的问题和 他们打过交道。
IT 评审是极具挑战性的 ，因为参与者通常都不太了解维度模型 。实际上 ，他们中的大 多数人可能都是精通并狂热的第 3 范式（3NF）支持者 。他们趋向采用面向过程的事务型建模 规则处理维度模型 。与其将大量时间放到争论不同建模方法 的优缺点上 ，不如在评审过程 巾积极主动地提供一些维度建模教育 。
当每个人都了解一些基本概念后，首先应该从总线矩阵开始评审 。这样做可以让参与 人对项目范围和整个的数据结构有一些理解，阐明一致性维度的作用 ，展示相关的业务活 动优先顺序 。接下来，描述如何从 总线矩阵上选择行 ，并将其直接转换到高层维度模型图中。这样做，可以让所有人看到实体级别的模型映射 ，有利于后续讨论的开展 。
多数评审会议主要通过浏览维度和事实表工作单细节开展 。在会议期 间，讨论模型时， 对每个表存在 的问题进行评审也是非常好的办法 。
会议可能会对模型进行修改 。记住要指定小组成员专门负责获取相关 的问题和建议。核心用户评审
在多数项目中 ，并不需要这样的评审 ，因为核心商业用户都 是建模小组的成员且已经对维度模型有深刻的理解 。如果核心商业用户未成为建模小组成员 ，则核心用户评审会议与IT评审会议的范围和结构类似。核心商业用户具有比普通商业用户更强的技术背 景并能 够处理模型 的细 节 。在小型组织中，经常将IT评审和核心用户评审合并到一个会议中 。-
广泛的业务用户评审
这样的会议与其说是设计评审 ，不如说是教育与培训 。您希望就相关 内容给人们以教育和启迪而不是强迫他们接受 ，同时应该描述维度模型如何能够支持业务需求 。应当从企业DW/BI数据路标的总线矩阵开始 ，评审高层模型气泡图，最后 ，评审关键维度 ，例如客户和产品维度等 。有时，在讲解气泡图时辅以如下图所示的描述维度中 的层次下钻路径 。
![]()
记得在这样的教育／评审会上要分配 一定的时间用于描述如何使用模型来回答有关业务过程的范围广泛的问题。我们通常会在需求文档中加入 一些示例 ，并简略地说明如何解 决这些示例的问题。
- 形成设计文档
在模型稳定后 ，应该对设计小组的工作文件进行编制 ，形成设计文档 。该文档通常包括：
• 项目的简短描述
• 高级数据模型图
• 详细的针对每个事实和维度表的维度设计 工作单
• 开放的问题
参考:
- 《数据仓库工具箱 维度建模权威指南》第三版