原文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.pngOBT 方法比上述其他方法简单一些图像灵感 –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 – 一个大表OBTTech Zero – 什么是“一个大表”探讨何时使用何时不使用以及我的个人经验Christianlauer – 如何在数据分析项目中使用 BEAM 方法Lawrence Corr Jim Stagnitto – 敏捷数据仓库设计从白板到星型模式协同维度建模Optimal BI – BEAM*敏捷数据仓库的需求收集应用数据建模在那里有大量的信息如果你真的想构建一个数据模型还有很多需要理解的东西。总体来说理解各种数据建模方法对于在多种场景下有效地管理和利用数据至关重要。了解这些方法请参阅乔·里斯的文章。每种方法都有其独特的优势和劣势使它们适合不同的商业需求和技术环境。例如Kimball 的星型模式非常适合简单的 BI 任务而 Inmon 的规范化方法则非常适合企业范围内的全面数据集成和一致性。由于数据需求可能有很大的差异拥有灵活性使得组织能够定制他们的数据库方法。但为了有效地做到这一点你需要理解每种方法的细微差别以及它如何与你的组织设定的业务和数据需求相一致无论是现在还是未来。不幸的是大多数组织在没有结构化建模方法的情况下进行构建。我强烈建议不要这样做因为数据模型对于维护数据完整性、优化存储和提升整体数据质量至关重要这最终推动更好的商业决策和结果。如果没有经过深思熟虑的数据模型组织将不断面临短期数据工程问题并且将业务需求与数据需求相连接将极其困难。我将更多地撰写关于数据建模以及你如何实际处理它的内容包括不同的考虑因素、它对数据角色的影响以及你在数据建模领域中找到的关键术语。几个月后你将看到那篇文章感谢阅读如果你认为这篇文章相关请在下面评论并分享。你也可以随意关注我在Substack每周一篇文章或LinkedIn非常活跃上的账号。除非另有说明所有图片均为作者所有