一 维度表和业务领域
第一部分将重点介绍维度表，它是提供上下文并支持对业务数据进行多方面分析的关键结构。深入探讨维度表的概念、它们在星型模式中的重要性以及它们与业务领域的关系。我将探讨这些元素如何协同工作以创建统一且直观的业务数据架构视图。
了解维度和业务领域
什么是维度表
星型模式中的维度表是一种基本结构，可用于对事实和度量进行分类，从而让用户从各个角度分析数据。但是，它们也可以单独使用，以提供其所涵盖领域的“单一视图”。这些表包含描述性属性，可为事实表中存储的数字数据提供背景信息。例如，在航空公司的数据仓库中，维度表可能包括“客户”、“航班”、“时间”和“地点”，每个维度表都提供了检查运营数据的不同角度。
维度表通常由一个主键和多个描述性列组成。例如，“客户”维度可能包括 CustomerID（主键）、Name、Address、FrequentFlyerStatus 和 JoinDate 等属性。这些属性允许对数据进行切片和切分，从而实现丰富的多维分析。它们还可以在适当的情况下包含指标，以便在单个表中提供您正在查看的“事物”的更整体视图。
什么是业务领域
业务领域代表着一个独特的业务活动领域，包括其独特的规则、流程和数据。它是相关业务实体和操作的逻辑分组。在航空公司的背景下，业务领域可能包括客户管理、航班运营、收益管理和机组人员调度。
每个业务领域都封装了支持其特定操作所需的相关数据和业务逻辑。这种以领域为中心的方法有助于组织和管理大规模业务操作及其相应数据结构的复杂性。
星型模式维度与业务域之间的关系
星型模式维度与业务域之间的关系对于创建有效且直观的数据仓库设计至关重要。维度通常设计为与数据仓库结构中的业务域紧密结合并表示业务域。这种结合有几个关键目的：
业务现实反映：通过将维度映射到业务领域，数据仓库结构可以反映业务的实际设计。这使得数据模型对于业务用户来说更加直观。
简化分析：当维度与熟悉的业务概念相对应时，用户可以更轻松地浏览和分析数据，即使没有底层数据结构的深入技术知识。
一致的维度：正确对齐的维度有助于创建一致的维度——可用于多个分析点的标准化维度结构。这可提高不同业务流程中报告和分析的一致性。
可扩展性和灵活性：随着业务领域的发展，相应的维度可以更新或扩展，从而使数据仓库与业务同步增长。
增强的数据治理：维度和业务领域之间的清晰关系可以更轻松地分配所有权和管理特定业务领域内的数据质量，从而支持更好的数据治理。
通过精心设计反映业务领域的维度表，公司可以创建一个数据仓库，不仅可以高效存储数据，还可以以与业务实际运作方式相呼应的方式呈现数据。这种协调对于充分发挥基于星型模式的数据仓库的潜力至关重要，有助于做出更有效的决策并实现更丰富的业务洞察。
以业务为中心的维度表构建方法
在敏捷环境中，构建维度表的过程应该是迭代的、协作的，并与业务需求保持一致。这种方法确保生成的数据仓库结构不仅在技术上合理，而且还能为公司提供真正的价值。以下是该过程的详细介绍：
1.确定关键业务领域：
与业务利益相关者合作以了解关键运营领域。
确定对决策过程至关重要的域。在我们的航空公司示例中，客户域至关重要，因此应该是最先构建的域之一。
2.确定属性：
对于每个域，列出描述该域的所有潜在属性。
考虑当前的需求和未来的潜在需求。
对于客户领域，属性可能包括：客户 ID、姓名、地址、电子邮件、电话号码、常旅客状态、加入日期、上次飞行日期、总航班次数、去年花费的美元数、首选机场等。
3. 标准化定义：
与跨职能团队合作为每个属性创建标准定义。
解决不同部门对某些术语的定义或使用方式上的差异。
例如，确保“FrequentFlyerStatus”在营销、客户服务和运营部门具有一致的定义。
4. 创建一致的维度：
开发可在多个团队中一致使用的维度，以实现不同的洞察目的。
确保维度的粒度（详细程度）适合其所有潜在用途。您应该计划从尽可能详细的级别开始。稍后汇总很容易，但一旦投入生产，就很难变得更细。
对于客户维度，粒度可能是每个客户一行，并使用渐变维度技术跟踪历史变化。
5.记录和沟通：
为每个维度创建文档，包括属性定义、数据类型和业务规则。
使用 Confluence 或其他协作平台等工具，使企业能够轻松访问这些信息。
举办培训课程或研讨会，以确保所有利益相关者了解如何使用和解释这些维度。
6.迭代细化：
使用敏捷冲刺来逐步开发和完善维度。
从最小可行产品 (MVP) 维度开始，并在后续冲刺中增加复杂性。
定期寻求业务用户的反馈并根据需要扩充维度结构。
7.数据治理集成：
为每个维度建立数据管理角色。
实施持续数据质量检查和维度属性更新的流程。
8.性能优化：
持续审查查询模式并优化常用属性的维度结构。
如果派生属性或预聚合值能够显著提高查询性能，请考虑在维度上创建派生属性或预聚合值。如果历史指标有助于为企业提供洞察，Kimball 并不反对将其存储在维度表上。
9.业务价值验证：
定期评估维度属性的使用情况和价值。虽然一开始向维度添加所有可能的内容似乎很合适，但 100 个价值不大的属性会造成空间混乱，使企业更难看到真正有助于促进理解的 15 个属性。
随着业务需求的发展，准备弃用不再提供价值的属性或添加新的属性。
维度表设计中的注意事项
构建维度表时，有几项考虑因素可以显著提高数据仓库的价值和性能。我将在下面介绍其中的一些因素：
整合其他数据源
虽然初始维度属性通常来自主要的操作系统，但集成来自其他来源的数据可以极大地丰富您的维度并提供更深入的见解。
第三方数据集成：
确定可以增强您的维度的有价值的外部数据源。
例如：客户维度的人口统计数据、产品维度的市场数据。
仔细规划集成过程，考虑数据质量、更新频率和与现有属性的映射。
跨职能协作：
与各个部门合作，找出他们可能拥有的有用数据源。
确保在整合外部数据时有法律和合规团队参与。
数据质量保证：
为集成数据实施强大的数据清理和验证流程。
设置监控以确保来自所有来源的持续数据质量。
处理缓慢变化维度 (SCD)
缓慢变化维度是一种不仅捕获业务领域属性的当前位置，还跟踪历史变化的维度。以航空业务中的客户维度为例，它不仅可以让您看到他们当前的常旅客身份，还可以查看他们在任何历史航班预订时的身份。
虽然类型 1 最容易实现，但它确实存在重大缺陷。如果企业不确定自己想要什么，我始终建议从类型 2 维度开始。最简单的原因是历史准确性。
假设您在一家水果和蔬菜公司工作，您有一种产品 — 西红柿 — 在 1 月份的产品分组为“蔬菜”。2 月份，公司向高管发送了一份报告，其中显示了按产品组划分的全年月度销售额。所有西红柿的销售额都归入蔬菜类别。3 月份，有人决定将西红柿更技术性地定义为水果，因此更新了西红柿的产品组。在类型 1 维度中，这将导致西红柿的所有历史交易现在都显示在“水果”产品组下。3 月份的报告发送给了高管团队，其中一位高管表示担心，虽然 1 月份的总数与之前的报告相同，但细节已经发生了变化。他们不再信任这些数据。
实现层次结构
层次结构在维度中相当常见。日期维度是最容易考虑的。天数累计为月数，月数累计为季度，然后是年数。这是一个定义明确的层次结构的示例。层次结构的每个级别都可以在维度表中分离成自己的属性。
更难建模的是杂乱的层次结构。一个例子可能是组织结构图。首席执行官可能有三名报告人。一名是他们的行政助理，他没有自己的报告人。另外两名可能是职能主管，其层次结构深度为 5-6 级。更糟糕的是，这些级别可能会随着时间的推移而发生变化，而不会引起太多注意。对于这些，我们可以使用递归层次结构，在每个记录上显示父级的主键。
扁平层次结构：将层次结构的多个级别作为单独的属性包含在内，以便于钻取。
递归层次结构：实现具有可变深度的组织结构或产品类别。
整个企业的一致维度
虽然这可能很有挑战性，并且可能涉及大量的业务讨论，但确保不同主题领域的维度一致，将使长期工作变得更加轻松：
在整个组织内标准化属性名称和定义。
实施强大的主数据管理 (MDM) 策略。
使用代理键来管理跨不同源系统的维度成员。
管理事件驱动源中的细节级别
事件驱动的数据源可以提供高度精细的信息，但管理这种级别的细节需要仔细考虑，特别是当你被要求在 2 型以上样式维度中跟踪历史记录时：
适当的报告间隔：
分析业务需求以确定正确的粒度级别。
对于大多数业务场景来说，每日更新就足够且易于管理。
处理高频更新：
对于频繁更新的源（例如，10 分钟内超过 50 次更新），请考虑实施暂存区。
在将更新应用到维度表之前，使用暂存区来聚合更新。
向维度添加指标
虽然维度主要包含描述性属性，但包含某些指标可以增强分析能力：
静态指标：
包括提供背景的相对稳定的指标。
示例：产品维度中的标准销售价格。
历史汇总指标：
添加预先计算的聚合以加快常见查询。
将这些限制为仅涵盖两个维度的指标：维度本身和时间。
示例：客户维度中的总生命周期价值。
添加指标的注意事项：
确保添加的指标不会频繁改变，以避免过多更新。
记录这些指标的计算方法和更新频率。
请谨慎添加过多的指标以保持维度表的简单性。
确保所使用的任何指标都符合与其可计算的事实表相同的业务规则。不要创建两个版本的事实！
通过仔细考虑维度表设计的这些方面，您可以创建一个更强大、更高效、更具洞察力的数据仓库，以更好地满足您公司的分析需求。
二 通过业务流程理解定义的事实表
本小结介绍数据工程团队如何有效地与业务利益相关者合作，通过在数据仓库中创建事实表来提供见解。根据以前领导数据团队的经验，下面探讨了确保无缝流程所需的最佳实践和方法。
了解事实表的重要性
事实表是将数据仓库表示层结合在一起的粘合剂。它们存储定量数据以供分析，通常设计为遵循定义的业务流程，这使得它们对于业务智能和报告至关重要。设计良好的事实表使企业能够以最小的努力执行复杂的查询并生成有见地的报告。因此，规划业务流程以形成这些表的过程至关重要。
事实表的类型
在了解创建事实表的过程之前，了解不同类型的事实表及其用例非常重要：
交易事实表：这是最常见的类型，以原子级别捕获每笔交易或事件。它们提供业务流程的最精细视图，例如单个销售交易。
定期快照事实表：这些表按定义的时间间隔（例如每日、每月）对业务流程进行快照。它们可用于分析流程随时间的变化状态，例如每月库存水平。
累积快照事实表：这些表用于具有标准步骤数的明确定义的流程，用于跟踪流程的生命周期。粒度处于项目级别（例如订单），列标识关键里程碑日期。在基于订单步骤的累积快照事实表示例中，您会期望此事实表中的记录数等于业务中的订单数，这应该等于相关维度表中的订单数。
无事实事实表：这些表不包含数字事实，但记录事件的发生，通常用于跟踪维度之间的多对多关系。这些表还可用于跟踪关系的持续时间，并记录生效日期和起始日期。
建立事实表的过程
让我们逐步介绍构建事实表的步骤，如下图所示：
与业务利益相关者接触
规划业务流程的第一步是与相关业务利益相关者进行交流。不要误以为您可以在源系统中看到交易表，然后可以简单地将其用作事实表。业务利益相关者对业务运营和推动组织发展的关键绩效指标 (KPI) 有着深刻的理解。他们会意识到可能应用的任何业务规则，或任何可能不会立即显现的额外细节级别。
确定关键利益相关者：确定关键利益相关者是谁。这可能包括部门主管、业务分析师和其他有影响力的人员。
进行访谈：组织访谈或研讨会，收集有关业务流程的详细信息。目标是了解工作流程、数据要求和可用的信息来源。
定义目标：明确定义项目的目标。企业想要回答的关键问题是什么？如何利用这项工作来增加收入、降低成本或改善文化？哪些 KPI 对成功至关重要？虽然不应构建事实表来迎合特定报告，但了解可以沿着业务流程跟踪的 KPI 至关重要，以便让业务改进机会变得清晰可见。
记录业务流程
初步合作完成后，下一步是详细记录业务流程。这涉及创建流程图，以直观的方式呈现组织内的活动和数据流。
流程图绘制工具：利用 Mermaid 等工具进行图表绘制。Anthropic 和 OpenAI LLM 产品均能够原生构建 Mermaid 图表，因此可以用自然语言写出（或讲解）流程图，然后自动生成。
定义流程：规划端到端流程，包括所有相关步骤、决策点和数据输入/输出。
识别数据源：记录与每个流程相关的数据源。这包括数据库、外部系统、电子表格和任何其他信息存储库。
确定适当的事实表类型
根据记录的业务流程，确定哪种类型的事实表最适合每个流程。考虑数据的性质、更新频率和业务的分析需求。对于任何给定的业务流程，拥有多个事实表是完全可以接受的，特别是当相关指标处于不同的粒度级别时。
将业务流程转化为数据模型
在详细了解业务流程后，下一步就是将这些流程转化为数据模型，作为事实表的基础。
识别实体和属性：确定每个流程中涉及的关键实体及其各自的属性。例如，在销售流程中，实体可能包括客户、订单和产品。这些实体中的每一个都需要在集成到事实表之前创建一个维度表。
定义关系：建立不同实体之间的关系。这对于了解数据如何在公司内流动以及如何在必要时汇总数据至关重要。
创建逻辑数据模型：使用实体关系图 (ERD) 创建逻辑数据模型。这些模型应描述前面步骤中确定的实体、属性和关系。同样，您可以利用 Mermaid 或类似工具来完成此过程。
设计和构建事实表
设计事实表是一个关键的步骤，涉及将逻辑数据模型转换为可以在数据仓库中实现的物理模式。
确定事实和度量：确定需要存储在事实表中的事实（定量数据）。度量通常是数值，例如销售收入、销售数量或交易计数。不要试图混淆这些指标。您不应该在同一条记录中同时包含交易金额和年初至今金额。
定义维度：确定将为事实提供背景的维度。维度是与事实相关的描述性属性，例如时间、客户、产品和位置。
开发 ELT 管道：开发 ELT 管道以从源系统提取数据，将其加载到仓库中，然后将其转换为事实表所需的格式。
数据验证：实施数据验证检查，以确保数据的准确性和完整性。这包括检查数据的完整性、一致性和正确性。
部署后流程
虽然创建事实表标志着一个重要的里程碑，但重要的是要明白，获取业务价值的真正工作才刚刚开始。数据团队的作用远远超出了最初的实施，包括持续的测量、分析和改进建议。
建立基线
发布事实表后，为其所代表的业务流程建立基线指标。
该基线将作为所有未来改进的参考点，并可以量化衡量数据驱动决策的影响。
持续监控与分析
定期分析事实表中的数据以识别趋势、异常和潜在的改进领域。
使用统计技术和数据可视化工具来更深入地了解业务流程。
确定改进机会
根据分析，确定可以优化业务流程的具体领域。
寻找数据揭示的瓶颈、低效率或未开发的潜力。
与业务利益相关者合作
向业务利益相关者提出调查结果和改进建议。
与他们密切合作，以了解数据洞察的实际意义以及如何将其转化为可行的策略。
实施并衡量变革
协助实施商定的改进措施。
使用事实表数据衡量这些变化的影响，并与已建立的基线进行比较。
迭代改进周期
将此视为一个持续、反复的过程。在实施和衡量一组改进后，开始寻找下一个机会。
根据需要不断完善和扩展事实表，以支持不断变化的业务需求和新确定的分析领域。
量化并传达价值
定期量化通过这些数据驱动的改进产生的业务价值。
向利益相关者传达这些成功，展示数据团队为组织带来的持续价值。
通过采用这种持续改进的思维方式，数据团队从单纯的技术资源转变为推动业务价值的战略合作伙伴。事实表不再只是静态的信息存储库，而是持续进行业务优化和创新的动态工具。
这种方法可以确保创建事实表的投资产生的回报远远超出其最初的实施，并通过数据驱动的决策和流程改进不断为公司增加价值。
三 多对多关系的桥接表
下面我们解决一个甚至经常让数据专业人员感到困惑的更高级的概念：桥接表。
桥接表可能不像维度表或事实表那样普遍存在，但它们在处理数据模型中的复杂关系方面起着至关重要的作用。下面，我将尝试揭开桥接表的神秘面纱，探讨何时以及为何使用它们，并提供实际示例来巩固您的理解。因此，无论您是希望提高技能的数据建模者，还是希望优化仓库设计的数据工程师，请系好安全带 — 我们将弥补您在 Kimball Star Schema 知识方面的差距！
什么是桥接表
想象一下，你在现实世界中建造一座桥。它的目的是什么？连接两个原本很难或不可能直接连接的点。这基本上就是桥接表在数据建模领域的作用——它们在直接链接不切实际或效率低下的地方建立连接。
用更专业的术语来说，桥接表是促进维度表和事实表之间多对多关系的中间表。当单个指标可以与维度表中的多个记录相关联时，它们就会发挥作用，如果没有正确处理，这种情况很快就会变得难以处理。
桥接表的必要性
你可能会想，“为什么我们不能只使用维度表或事实表来处理这些关系？”好问题！让我们分解一下：
保持星型模式的简单性：星型模式因其简单性和查询效率而受到分析师的青睐。直接的多对多关系会使此结构复杂化，从而使查询更加复杂和缓慢。
数据完整性：如果没有桥接表，您可能会倾向于在多行中复制数据，从而导致潜在的不一致和更新异常。
灵活性：桥接表允许更动态的关系，轻松适应随时间的变化，而无需对核心事实和维度表进行重大重组。
性能：虽然这看起来有悖常理，但正确实施的桥接表实际上可以通过允许更有效的连接和过滤来提高查询性能。
避免事实表膨胀：如果没有桥接表，您可能被迫创建极其精细的事实表，而这些事实表实际上比它们出现的自然级别更精细，从而导致表的大小过大并降低查询性能。
真实场景：银行交易
让我们用一个来自银行业的真实案例来具体说明这一点，希望大多数人都熟悉这个案例。假设您正在为一家银行设计一个数据仓库，该银行需要跟踪客户账户之间的交易。问题在于：一些账户有多个所有者。我们如何有效地对此进行建模？
场景：
客户：每个客户可以拥有多个银行账户。
账户：每个账户可由多个客户拥有。
交易：每笔交易都与特定账户相关联。
如果没有桥接表，您可能会想创建如下所示的模型：
不使用桥接表进行建模，但这种方法有几个问题：
它不能准确表示联名账户。您需要为每个账户所有者复制交易，从而导致数据不一致和交易数量虚高。这意味着您需要在事实中进行额外计算，将任何基础交易金额除以客户数量，然后再将其插入事实中。
如果账户所有权发生变化，则需要更新历史交易，这违反了事实表的不变性原则。
查找客户所有交易的查询变得更加复杂且效率更低。
输入桥接表解决方案：
实现桥接表
引入桥接表以增加灵活性，这个结构解决了我们的问题：
它准确地代表联名账户，而无需重复交易数据。
即使账户所有权发生变化，历史准确性仍能保持。
查询可以通过桥接表轻松连接，将客户与其交易联系起来。您可以将乘以transaction_amount以pct_ownership确保保持所有总数，或者transaction_amount直接查看每个客户的原始数据。
何时使用桥接表：决策框架
虽然桥接表功能强大，但并非总是必需的。以下是帮助您确定何时使用它们的决策过程：
让我们分解一下这个决策过程：
确定关系：首先，确定您是否在处理多对多关系。如果不是，则标准星型模式方法就足够了。
考虑事实表调整：您可以通过调整事实表的粒度来解决问题吗？例如，在我们的银行业务场景中，如果我们只关心主要账户持有人，我们可以将 CustomerID 直接包含在事实表中，并记录此业务假设。
评估维度表更改：如果事实表调整不起作用，您可以修改维度表以消除多对多关系吗？在某些情况下，您可能能够创建一个表示关系的组合维度。例如，如果最多有两个帐户持有人，您可以将帐户持有人的姓名透视到帐户维度中的两个预定义字段中。
实现桥接表：如果事实表和维度表的调整都不可行或不理想，那么就该实现桥接表了。
桥接表的最佳实践
现在您知道何时使用桥接表，让我们讨论一些最佳做法，以确保它们有效实施：
保持简单：仅在必要时使用桥接表。如果可以通过调整事实表或维度表来解决问题，而不会损害数据完整性或查询性能，那么这通常是首选方法。
考虑时间维度：桥接表中的关系通常会随时间而变化。包括开始和结束日期（或生效和到期日期）可以帮助保持历史准确性。
维护数据完整性：确保您的桥接表与相关维度表的变化保持一致。在我们的银行示例中，如果客户从帐户中删除，请确保更新 Account_Customer_Bridge 表中的 EndDate。
优化性能：桥接表可以在查询中引入额外的连接。确保已设置适当的索引，如果查询性能成为问题，则考虑实现通用连接路径。
添加相对权重：为确保指标不会超标，请在桥接表上提供相对权重，这些权重可用于乘以事实表指标。在银行示例中，一个账户上可能有两个客户。第一个拥有 60% 的所有权，第二个拥有 40%。因此，这应该显示在桥接表上。可以将事实指标乘以相对权重，以确保总值不变。pct_ownership在上面的 ERD 中使用了一列。
全面记录：桥接表会增加数据模型的复杂性。确保为其他团队成员和未来维护人员清楚地记录其目的、结构和用法。
处理空关系：在某些情况下，您可能拥有不参与多对多关系的实体。决定如何处理这些情况并记录您的方法。
考虑属性桥接：有时，您可能需要桥接一组属性，而不是整个维度。在这些情况下，请考虑创建属性桥接，它链接到维度属性的子集，而不是整个维度表。
常见陷阱及避免方法
即使考虑到最佳实践，人们在实施桥接表时也会犯一些常见错误。以下是一些需要注意的事项：
过度使用：不要对每个复杂关系都使用桥接表。有时，反规范化或其他技术可能更合适。
忽略性能：如果实施不当，桥接表可能会影响查询性能。始终测试您的查询并根据需要进行优化。
忽略更新：桥接表需要像数据仓库中的任何其他表一样进行维护。确保您已制定流程以使其保持最新状态。
误解基数：确保您真正理解您正在建模的关系。误解的关系可能导致模型效率低下或不正确。
忘记历史：如果您的桥梁代表着一种随着时间而改变的关系，请确保您适当地捕捉到了那段历史。
本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。
