当前位置：首页 > news >正文

数据建模的遗忘指导角色

news 2026/5/16 3:54:48

原文：towardsdatascience.com/the-forgotten-guiding-role-of-data-modelling-a76f69364284

想象一下在没有蓝图的情况下建造摩天大楼，随着大楼的成形，以临时的方式确定如何铺设混凝土、对齐支撑梁和布线。

嗯，这正是今天数据组织中所发生的事情…

数据建模，数据生态系统的基本蓝图，在采用最新技术和快速取得成果的匆忙中被忽视。我们看到的是一系列可预测的问题，这些问题通过短期工程修复来解决。

什么是数据建模？

根据Joe Reis（目前正在撰写关于这个主题的书籍）的说法，数据模型是：

一种结构化的表示，组织和标准化数据以启用和指导人类和机器行为，提供决策信息，并促进行动

数据建模几十年来一直是数据管理的基石，对于公司结构化和理解其数据至关重要。然而，近年来，这种做法变得不那么受欢迎，被新的数据工具和技术所掩盖。这种转变反映了数据行业中的短期视角，其中往往将即时结果置于基础原则之上。

核心问题是数据建模需要深入理解业务、其流程和其需求。这不仅仅是关于物理数据结构化、绘制实体关系图（ERDs）或技术团队的一次性练习；它关于（正如Sonny Rivera完美地表达的那样）：“在业务团队和数据团队之间建立共同理解”。

当正确实施时，数据模型提供了对组织的全面视图。它揭示了数据或业务利益相关者可能错过的见解和关系。它还允许数据团队构建更好的管道、产品/资产和解决方案，这些解决方案更加稳定、可靠、适应性强，最重要的是，对业务相关。

概念性、逻辑性和物理数据模型

我不是一个技术人士，所以数据建模最初对我来说是一个令人畏惧的主题。鉴于其从数据库设计的历史演变，普遍认为数据建模是一个高度技术性的领域，涉及链接数据类型和实体。

但是，相信这种刻板印象就像在成功交付数据项目时自毁长城。
*相反，数据建模实际上是商业模式和物理数据之间的联系。

它代表了将业务流程转换为数据资产和实体之间关系的行为。数据倡导者总是谈论数据是如何体现业务运作的，并且可以揭示支撑企业建立的关键绩效指标（KPIs）的有限细节。好吧，数据建模帮助我们进入这些细节，同时不失对整体业务的关注（这是做得太过频繁的事情）。

这分为三个阶段：（1）概念建模，（2）逻辑建模，和（3）物理建模。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/96043ac1ec205b1e9b7340faddc2e666.png

数据建模过程分为三个步骤，但所有步骤都必须从商业模式或关键业务流程中流下来。

第一阶段是开发一个基于最高优先级业务流程的概念数据模型。与业务利益相关者合作，目标是描绘出组织在其最常见或最有价值的业务流程中如何创造、交付和捕捉价值。然后，在该流程中绘制数据点。通过将数据资产和流程叠加在业务逻辑之上，你创建了一个高级表示，说明组织数据如何运作以驱动收入或增加销售额。你知道人们经常提到不将数据与业务价值联系起来，这就是你如何将其模型化的方式！！！在概念模型中，你应该识别关键数据实体和领域（例如，财务、营销、客户等），并映射它们之间的高级关系。整个概念模型应该让业务利益相关者易于理解，因为它充当业务流程和数据开发之间的桥梁。

第二阶段是一个逻辑数据模型，它开始在所选业务流程的上下文中定义数据表和实体之间的关系。比概念模型深入一个层次，逻辑模型进一步定义了数据类型、每个实体的属性以及关系的本质。例如，识别候选键以识别数据实体和连接不同实体的主键。虽然你开始接触到技术细节，但逻辑模型仍然独立于任何技术实现（因此技术中立)。相反，这一步的重点是创建一个清晰的结构（通过ERD或UML)，以说明数据是如何相互关联和组织的。在这个阶段，业务利益相关者可能仍然能够理解业务流程，并可以提供反馈以验证这些关系。设计还优化了数据的效率、一致性和标准化，以避免数据被错误地表示或重复，这在构建没有这种辅助的管道工程时非常常见。

最后一步是定义物理数据模型，其中设计被转换为实施的技术规范。物理模型将逻辑数据结构映射到物理存储设备上，描述了构建数据库所需的所有物理细节。这需要通过一个逐步细化具体细节的过程（例如，数据库表、列类型、关系、索引、分区方案、数据约束等）来优化性能和存储。在这个阶段，实施变得具有技术特定性，不同的方法会根据技术栈而有所不同。无论技术栈如何，工具如[SqlDBM 或 Erwin 数据模型器]可以将物理模型图转换为 SQL 代码以节省时间](https://thedataplatform.substack.com/p/how-to-build-a-data-platform-data-07e)。设置完成后，物理数据模型为组织内数据的存储、结构和访问设定了蓝图，这对于组织理解至关重要，并且当不可避免地添加新的数据源或业务规则发生变化时，它还允许进一步的扩展性。这需要积极管理（通常由数据库分析师/管理员负责），目标是物理模型的最佳配置（与概念模型和逻辑模型协调一致）提供更高的数据效率和可用性。

这三个数据模型层共同工作，为优化组织的数据提供必要的概要和详细层次。

*这样做是一种投资，但它为工程师、分析师和其他数据专业人士提供了一个结构，以节省他们长期的时间和精力。

我从未遇到过不希望提高数据质量、增强数据信任度以及提高数据与业务流程相关性的组织，数据建模是实现这一目标的基础。

数据建模的不同方法

如果不提及和定义大多数团队在物理建模数据时采取的不同方法，我就无法写出关于数据建模的文章。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/78094434f2ed02af420d2e0ada58c27e.png

我试图将这五种方法包含在一个图形中，并为每个方法提供简短的介绍。更多细节见下文！

值得注意的是，有些人只会订阅一种数据建模方法。这有点短视，因为它们各自都有其优点，如果做得恰当，可以灵活应用。正如Joe Reis 在他最近的文章中讨论的那样，混合模型艺术应该成为任何专业人士的标准方法，因为我们将在数据建模方面看到更多的融合和模糊。这样做需要定制和战略思考，但可以在推动不同结果时带来显著的好处。

Kimball– 这是最受欢迎的建模方法之一。Kimball 使用星型模式设计进行数据仓库，其中中心事实表连接到多个维度表。这种方法易于理解和/或实施，对于简单的查询效率高，并且与 BI 工具配合良好。然而，由于反规范化，它可能需要更多的存储空间，并且对于更复杂的关系可能不够灵活[（详细信息请见 https://www.astera.com/knowledge-center/star-schema/）]，这使得更新和维护变得更加具有挑战性。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/c91f4fcec581a0e31fd6adde0f9789d9.png

你可以在任何地方找到的经典 Kimball 星型模式示例

Inmon– 这种自上而下的方法侧重于创建一个集中式、规范化的数据仓库，作为企业内权威数据源（即单一事实来源）。数据模型将数据保持为第三范式以减少数据冗余和重复。为了增加对不断变化的业务需求的灵活性，在数据仓库之上为特定部门构建数据集市（它仍然作为单一事实来源）并按主题区域组织数据。这种方法的缺点是它复杂、耗时且资源密集。以这种方式构建需要更多的 ETL 管道、前期设计投资、更高的维护成本以及强大的工程团队，这使得它更适合具有复杂数据需求的大型组织。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/b6447e716e060c50f0c3074acd8d31a0.png

在 Inmon 方法中，你可以看到帮助提供数据管理灵活性和相关性的数据集市（图片灵感 –www.keboola.com/blog/kimball-vs-inmon)

数据仓库– 一种更近期的结合了 Inmon 和 Kimball 方法的方法。数据仓库通过模块化设计优先考虑可扩展性和灵活性。中心辐射架构将数据分为中心（核心业务概念）、链接（关系）和卫星（核心业务概念上的上下文数据），并允许在不破坏现有结构的情况下进行更改。通过卫星跟踪元数据提高了数据的透明度和可追溯性，允许更容易地进行审计和治理以维护数据质量。另一方面，由于结构复杂，数据仓库可能更难以理解和管理，这使得其设置和维护更加困难。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/0b948ad681328f828a9b299d6e3c59b4.png

数据仓库模式稍微复杂一些，但如果设置得当则非常灵活（图像灵感 –www.databricks.com/glossary/data-vault)

一个大表（OBT）– 这种方法将所有数据整合到一个单一、扁平、非规范化的表中。这简化了数据检索并减少了复杂连接的需求，提高了寻找正确数据的数据分析师和科学家的访问效率。它易于实施，并且对于简单的报告需求效果良好。然而，它可能导致显著的数据冗余和存储效率低下，并且在大数据集上难以扩展和性能不佳。这可能更适合没有熟练工程师或大量数据的较小组织。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/fe4289dfebacbb9e5bea0d8e007228fc.png

OBT 方法比上述其他方法简单一些（图像灵感 –www.ssp.sh/brain/one-big-table/)

BEAM（业务事件分析与建模）– 最后一种方法是 BEAM，这是理解 Kimball 物理建模需求的一种变体。因此，BEAM 专注于建模业务流程和人员以理解数据需求。这种方法通过让业务用户定义事件和创建数据用户故事，确保与业务需求保持一致。通过这种方式，BEAM 专注于敏捷数据建模，并帮助促进来自业务的清晰沟通和需求。在物理建模方面，你然后将 BEAM 需求与 Kimball 星型模式对齐，给出一个更以业务为中心的数据模型版本。总的来说，BEAM 是一种不太传统的数据建模形式，并不一定像其他人那样与数据库设计相匹配。它是一种不太熟悉的技能集，需要更陡峭的学习曲线才能掌握。

这些只是对每种数据建模方法的高层次定义。我强烈建议你进行研究，以更好地理解哪种方法适合你的用例，以及如何根据你的具体需求进行优化。以下是一些可以帮助你的资源（我也用过的）：

Astera – 星型模式的优势与劣势
Amar Joshi – 理解 Inmon、Kimball 和数据仓库数据模型之间的差异
Alex Merced – 数据仓库建模简介
Keboola – Kimball 与 Inmon 的比较
Databricks – 数据仓库
Second Brain – 一个大表（OBT）
Tech Zero – 什么是“一个大表”？探讨何时使用，何时不使用以及我的个人经验
Christianlauer – 如何在数据分析项目中使用 BEAM 方法
Lawrence Corr & Jim Stagnitto – 敏捷数据仓库设计：从白板到星型模式协同维度建模
Optimal BI – BEAM*：敏捷数据仓库的需求收集

应用数据建模

在那里有大量的信息，如果你真的想构建一个数据模型，还有很多需要理解的东西。

总体来说，理解各种数据建模方法对于在多种场景下有效地管理和利用数据至关重要。了解这些方法，请参阅乔·里斯的文章。每种方法都有其独特的优势和劣势，使它们适合不同的商业需求和技术环境。例如，Kimball 的星型模式非常适合简单的 BI 任务，而 Inmon 的规范化方法则非常适合企业范围内的全面数据集成和一致性。

由于数据需求可能有很大的差异，拥有灵活性使得组织能够定制他们的数据库方法。但为了有效地做到这一点，你需要理解每种方法的细微差别以及它如何与你的组织设定的业务和数据需求相一致（无论是现在还是未来）。

不幸的是，大多数组织在没有结构化建模方法的情况下进行构建。我强烈建议不要这样做，因为数据模型对于维护数据完整性、优化存储和提升整体数据质量至关重要，这最终推动更好的商业决策和结果。