数据建模到底是什么？搞清楚它的真正意义

欢迎来到雲闪世界。 数据模型是：

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

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

核心问题是，数据建模需要对业务、业务流程和需求有深刻的理解。这不仅仅是物理数据结构、绘制实体关系图 (ERD) 或技术团队的一次性练习；它是关于（正如Sonny Rivera完美阐述的那样）：“在业务和数据团队之间建立共识”。

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

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

我不是技术人员，所以数据建模最初是一个可怕的话题。鉴于数据建模从数据库设计演变而来的历史，人们普遍认为数据建模是一个高度技术性的领域，涉及连接数据类型和实体。

但在提供成功的数据程序时，相信这种刻板印象就好比是搬起石头砸自己的脚。 相反，数据建模实际上是业务模型和物理数据之间的纽带。

它代表将业务流程转化为数据资产和实体之间的关系的行为。数据传播者总是谈论数据如何体现业务运作方式，并可以阐明支撑业务所基于的 KPI 的有限细节。好吧，数据建模有助于我们了解这些细节，而不会忽视整体业务（这是经常做的事情）。

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

添加图片注释，不超过 140 字（可选）

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

第二阶段是逻辑数据模型，该模型开始在所选业务流程的上下文中定义数据表和实体之间的关系。逻辑模型比概念模型深一个层次，进一步定义了数据类型、每个实体的属性以及关系的性质。例如，识别候选键以识别数据实体和将不同实体链接在一起的主键。虽然您开始了解这里的技术细节，但逻辑模型仍然独立于任何技术实现（因此与技术无关）。相反，此步骤的重点是为数据如何关联和组织创建一个清晰的结构（通过ERD或UML）。此时，业务利益相关者可能仍然了解业务流程，并且仍然可以提供信息来验证关系。该设计还优化了数据的效率、一致性和标准化，因此不会出现错误表示或重复的情况，在没有此帮助的情况下构建工程管道时，这种情况非常常见。

最后，最后一步是定义物理数据模型，将设计转化为实施的技术规范。物理模型将逻辑数据结构映射到物理存储设备上，描述构建数据库所需的所有物理细节。这需要是一个迭代过程，详细说明具体细节（例如，数据库表、列类型、关系、索引、分区方案、数据约束等），以优化性能和存储。在此阶段，实施变得特定于技术，并且将根据技术堆栈采取不同的方法。无论是哪种堆栈，SqlDBM 或 Erwin Data Modeler 等工具都可以将物理模型图转换为 SQL 代码以节省时间。设置后，物理数据模型为组织内数据的存储、结构化和访问方式设定了蓝图，这对于组织理解至关重要，并且当不可避免地添加新数据源或业务规则发生变化时可以实现进一步的可扩展性。这需要主动管理（通常由数据库分析师/管理员进行），以便物理模型的最佳配置（与概念和逻辑模型协调）可以提高数据效率和可用性。

这三个数据模型层协同工作，提供优化组织数据所需的高级和低级细节。

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

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

数据建模的不同方法

如果我撰写了一篇关于数据建模的文章而没有提及和定义大多数团队对物理建模数据所采取的不同方法，那我就太失礼了。

添加图片注释，不超过 140 字（可选）

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

Kimball — 最流行的建模方法之一。Kimball 使用星型模式设计数据仓库，其中一个中心事实表连接到多个维度表。此方法易于理解/实施，对于简单查询非常有效，并且与 BI 工具配合良好。另一方面，由于非规范化，它可能需要更多存储空间，并且对于更复杂的关系可能不太灵活，这使得更新和维护更具挑战性。

添加图片注释，不超过 140 字（可选）

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

添加图片注释，不超过 140 字（可选）

Data Vault — 一种较新的方法，结合了 Inmon 和 Kimball 的各方面特点。Data Vault 通过模块化设计优先考虑可扩展性和灵活性。中心辐射型架构将数据分为中心（核心业务概念）、链接（关系）和卫星（核心业务概念的上下文数据），并允许在不破坏现有结构的情况下进行更改。通过卫星跟踪元数据可提高数据的透明度和沿袭性，从而更易于审计和治理以保持数据质量。另一方面，由于 Data Vault 结构复杂，因此可能更难理解和管理，从而更难以设置和维护。

添加图片注释，不超过 140 字（可选）

一个大表 (OBT) — 这种方法将所有数据整合到一个单一的、平面的、非规范化的表中。这简化了数据检索并减少了对复杂连接的需要，从而提高了数据分析师和科学家寻找正确数据的访问能力。它易于实施，非常适合简单的报告需求。但是，它可能导致严重的数据冗余和存储效率低下，并且在大型数据集的可扩展性和性能方面存在困难。对于没有熟练工程师或大量数据的小型组织来说，这可能是一种更好的方法。

添加图片注释，不超过 140 字（可选）

BEAM（业务事件分析和建模） ——最后一种方法是 BEAM，它是理解 Kimball 物理建模需求的一种变体。因此，BEAM 专注于对业务流程和人员进行建模以了解数据需求。这种方法通过让业务用户参与定义事件和创建数据用户故事来确保与业务需求保持一致。通过这种方式，BEAM 专注于敏捷数据建模，并帮助促进来自业务的清晰沟通和需求。在物理建模方面，您可以将 BEAM 需求与 Kimball 星型模式对齐，从而提供更加以业务为中心的数据模型版本。总体而言，BEAM 是一种不太传统的数据建模形式，并不一定与其他数据库设计相匹配。这是一套不太为人熟知的技能，需要更长的学习曲线才能掌握。

这些只是每种数据建模方法的高级定义。我强烈建议您进行研究，以更好地了解哪种方法适合您的用例，以及如何根据您的特定需求进行优化。

应用数据建模

如果您确实想要构建数据模型，那么那里有很多信息，还有很多内容需要理解。

总的来说，了解各种数据建模方法对于在不同场景中有效管理和利用数据至关重要。每种方法都有独特的优点和缺点，适合不同的业务需求和技术环境。例如，Kimball 的星型模式非常适合简单的 BI 任务，而 Inmon 的规范化方法则非常适合整个企业的全面数据集成和一致性。

鉴于数据需求千差万别，灵活性使组织能够定制其数据库方法。但要有效地做到这一点，您需要了解每种方法的细微差别，以及它如何与您的组织设定的业务和数据要求保持一致（包括当前和未来）。

不幸的是，大多数组织在构建时都没有考虑采用结构化建模方法。我强烈建议不要这样做，因为数据模型对于维护数据完整性、优化存储和提高整体数据质量至关重要，而这最终会推动更好的业务决策和结果。

如果没有深思熟虑的数据模型，组织将不断与短期数据工程问题作斗争，并且将业务需求与数据需求联系起来将非常困难。

我将撰写更多关于数据建模及其实际处理方法的文章，包括不同的考虑因素、它如何影响数据角色以及您在数据建模领域遇到的关键术语。

感谢关注雲闪世界。（Aws解决方案架构师vs开发人员&GCP解决方案架构师vs开发人员）