数据建模：技术、类型和实际应用详解

主页 » Python » 数据建模：技术、类型和实际应用详解

数据建模是那种悄然决定你的数据项目是成功还是失败的学科之一。每个分析仪表板、交易系统或商业智能解决方案背后，都有一个数据模型，它描述了存在哪些数据、数据如何连接以及日常使用方式。当这个模型清晰且设计良好时，开发就会变得更容易，报告会更可靠，而且每个人都能用相同的语言谈论业务。

数据模型本质上是一种描述业务信息的正式、可视化的方法。：存在哪些实体（客户、产品、仓库、发票……），哪些属性定义了它们（名称、地址、容量、价格……），以及它们之间如何相互关联。多年来，在新的数据库技术、治理需求以及现代分析用例（例如商业智能 (BI) 和数据仓库）的推动下，不同的建模技术和模型类型不断发展。

什么是数据模型？

数据模型是对系统内部信息结构方式的抽象蓝图。它定义了数据元素、管理这些元素的规则以及将它们联系起来的关系，这一切远在数据库或应用程序中实际实现任何功能之前就已经完成。你可以把它想象成工程师在浇筑混凝土之前遵循的建筑设计图。

实际上，数据模型展示了数据的存储、连接、访问和更新方式。 在数据库管理系统中，它使用符号、方框、线条和文本，为业务利益相关者、分析师、架构师和开发人员提供了一个组织所关注信息的共同视图，以便每个人都能对其进行推理并及早发现问题。

数据模型的主要目标之一是明确系统中使用和存储的数据类型。这包括定义键、约束、基数和命名约定，这些都将指导后续的技术实现。

数据模型并非凭空创建，而是由业务需求驱动的。在建模开始之前，需要从业务利益相关者和最终用户那里收集规则和需求。然后，这些规则会被转化为数据结构，用于指导新系统的设计或现有系统的演进。从这个意义上讲，数据模型与路线图非常相似：它本身并不执行任何操作，但它会告诉你如何从 A 点到达 B 点。

良好的数据建模依赖于标准化的模式和形式化的技术。这种标准化提供了一种一致且可预测的方式来定义和管理跨团队、部门乃至外部合作伙伴的数据资源。理想情况下，这些模型会成为动态文档，随着组织的变化而演进，从而支持流程改进并指导 IT 架构决策。

什么是数据建模？

数据建模是将数据存储位置以及数据在系统中的流动方式进行映射和可视化的过程。您需要确定应用程序、集成或 BI 平台将存储信息的所有位置，然后设计这些数据集如何连接和交互。

在任何IT项目中，数据建模都是一个至关重要的设计阶段。虽然解决方案仍在设计阶段，但团队会确定哪些业务问题必须解决，需要哪些数据来解决这些问题，以及用户和其他系统将如何使用这些数据。然后，他们会将这些理解转化为图表，描述不同数据组之间的关系以及它们在各个组件之间的流动方式。

数据建模的结果通常是一个或多个图表（或模型），这些图表（或模型）展示了每个数据组与其他数据组之间的关系。这些可以是面向业务受众的概念图，可以是最详细地展示结构和关系的逻辑模型，也可以是直接与数据库表和列关联的物理模型。每一层抽象都比前一层更加精细，更接近实际实现。

数据建模可以采用多种抽象级别，从非常高层次的概念到完全详细的模式。建模生命周期通常始于理解利益相关者的需求，将业务规则转换为数据结构，然后将这些结构细化为具体的数据库设计。在此过程中，数据缺失、不一致或数据元素缺失等问题会逐渐显现，并可在演变为生产问题之前得到修复。

由于需求不断变化，数据模型应该被视为动态的产物。每当新增功能、出现集成、法规变更或产生新的分析需求时，这些模型都会被重新审视。共享模型甚至可以与供应商和合作伙伴交换，以统一组织内部对数据的理解和交换方式。

主要数据建模技术和模型类型

随着时间的推移，出现了不同的数据建模技术，每种技术都针对特定的技术和用例进行了优化。从早期的层次数据库到 BI 中使用的现代维度和关联方法，每种风格在灵活性、性能和易理解性方面都有其独特的优势和权衡。

下面您将深入了解最重要的几种数据模型类型。书中以汽车经销店、仓库和 BI 星型模式等具体例子进行说明，并用通俗易懂的语言进行解释，以便技术和非技术读者都能理解。

层级数据建模

层级数据模型以树状结构组织信息。其结构以一个根节点为顶层，根节点下有多层子节点。每个父节点可以有多个子节点，但每个子节点只有一个父节点，从而形成严格的一对多关系模式。

在这种方法中，人际关系沿着一条从父母到子女的单一路径展开。这里不存在记录拥有多个父记录的概念。指针（或链接）连接父记录和子记录，您可以通过遍历这些指针来访问或更新数据。由于每条记录在树状结构中都位于一个固定的位置，因此很容易推断其传承关系。

以汽车经销店为例一个顶级节点可以代表“展厅”。每个展厅节点都会有“车辆”和“销售人员”的子节点，因为一个展厅可以容纳多辆汽车并雇用多名销售人员。导航始终从展厅开始，向下遍历以查看属于该展厅的车辆和销售人员。

当你的现实世界结构本身呈树状时，层级模型就非常适用。例如网站站点地图、组织结构图、食谱分解图或电子商务网站上的产品类别。例如，“鞋子”可能是父类别，其子节点包括“女鞋”和“男鞋”，以及更细分的子类别，例如“运动鞋”、“高跟鞋”或“靴子”。

这种风格具有一些明显的特征和局限性。关系严格遵循一对多模式，从根节点到任何给定的子节点都只有一条路径，删除父节点通常会自动删除其所有子节点。这种级联删除虽然方便，但如果不注意层级结构的语义，也可能存在风险。

网络数据建模

网络数据模型扩展了层级式方法，允许记录拥有多个父记录。最终得到的不是纯粹的树状结构，而是一个类似图的互连记录网络，例如 托管图形数据库这使得表示复杂的现实世界情况变得更加容易。

在网络模型中，可能存在更多种类的关系模式。您不仅可以处理一对多关系，还可以处理一对一和多对多关系。节点可以通过多条路径连接，这意味着在浏览结构时，可能有多种方法可以访问同一条记录。

想象一下，有一位学生既是计算机科学系的学生，又拥有图书馆的借阅权限。在网络模型中，“学生”记录可以有两个父记录：一个是“计算机科学与工程系”，另一个是“图书馆”。这在严格的层级树中是不可能的，因为在层级树中，一个子记录只能有一个父记录。

网络模型中的底层操作通常使用循环链表来实现。程序会跟踪列表中的“当前位置”，并根据定义的关联关系遍历关联的记录。这使得遍历快速而灵活，因为您可以沿着多条可能的路径访问同一条数据。

由于连接性更强，网络模型能够展现更细致入微、更贴近现实世界的关系。但它们也变得更加复杂，难以理解和管理。设计和维护所有链接可能极具挑战性，尤其对于大型模式和不断演变的业务规则而言更是如此。

实体关系（ER）数据建模

实体关系模型是一种使用ER图来描述数据需求的高级可视化方法。它是概念和逻辑数据建模中最广泛使用的技术之一，尤其适用于需要清晰了解情况而又不希望被技术细节所干扰的业务利益相关者。

在ER图中，核心组成部分是实体、属性和关系。实体代表企业关心的现实世界事物（例如“学生”、“教师”、“课程”或“部门”）。属性捕获这些实体的特性（例如教师 ID、薪水、年龄），关系则显示实体之间的连接方式（例如，“教师在部门工作”）。

实体通常用矩形表示，属性用椭圆形表示，关系用菱形或带标签的线条表示。基数（例如一对多或多对多）表示每个实体可以连接在一起的实例数量。这种表示法允许您在仍然相对易于阅读的图表中表达复杂的规则。

数据架构师使用实体关系（ER）工具来设计和改进这些模型。在许多情况下，ER 图成为业务分析和数据库实现之间的桥梁：一旦 ER 模型达成一致，就可以系统地将其转换为关系表、键和约束。

因为 ER 模型运行在相对较高的抽象层次上它非常适合与利益相关者验证理解。您可以在研讨会上审查图表，询问是否所有必要的实体和关系都已包含，并在深入技术层面之前调整设计。

关系数据建模

关系模型是大多数传统数据库系统的基础。在这里，数据存储在由行和列组成的二维表中，表之间的关系通过键来表示，而不是像层次模型或网络模型那样通过显式指针来表示。

关系模型中的每个表通常被称为“关系”。不过在实际应用中，人们通常会直接称它们为表。行被称为元组，代表单个记录或实例；而列是属性（或字段），用于定义每个记录存储的特性。

再以汽车经销店为例你可能会有一个名为“销售人员”的表，其中包含诸如销售人员ID和姓名之类的列，以及一个单独的“车辆”表，其中包含诸如车辆ID和品牌之类的列。“销售人员”表中的每一行代表一个实际的销售人员，“车辆”表中的每一行代表一辆实际的车辆。

主键和外键在关系模型中起着至关重要的作用。主键用于唯一标识表中的每一行（例如，销售人员ID或车辆ID）。这些主键可以作为外键出现在其他表中，以表示关联关系。例如，“展厅”表可以同时包含销售人员ID和车辆ID作为外键，从而将展厅与其销售人员以及展出的车辆关联起来。

主键和外键之间的协作使得关系数据库能够表示复杂的业务关系网络。查询数据库时，您可以根据这些键连接表，这很有用。 使用 SQL 进行数据分析 并重建现实世界的关联：哪些汽车被分配到哪个展厅，哪个销售员负责特定的销售等等。

主键和外键之间的协作使得关系数据库能够表示复杂的业务关系网络。查询数据库时，您可以根据这些键连接表，以重建现实世界的关联：哪些汽车分配给了哪个展厅，哪个销售员处理了特定的销售等等。

关系模型功能强大、易于理解，并得到成熟技术的有力支持。当数据结构高度结构化且一致性至关重要时，这种方法优势显著。然而，对于结构频繁变化的复杂对象、多媒体内容或超灵活模式，它可能会遇到局限性。

面向对象数据建模

面向对象数据建模将面向对象编程的概念引入数据领域。与其仅仅从表格和行的角度思考，不如将信息建模为对象，将数据（属性）与行为（方法）捆绑在一起，从而反映出现代应用程序的编写方式。

在面向对象模型中，每个对象都代表一个现实世界的实体。例如，对于汽车经销商而言，您可能会有一个“客户”对象，它包含姓名、地址和电话号码等属性，以及用于更新这些信息或计算客户生命周期价值的方法。每个实际客户都是系统中 Customer 类的一个实例。

这种建模方式可以克服严格关系型设计的几个局限性。尤其是在处理复杂的嵌套结构或不适合放入扁平表格的多媒体数据时，对象数据库和对象关系映射器（ORM）正是利用了这种范式来减少代码和数据存储之间的“阻抗不匹配”。

面向对象模型在多媒体和高级应用场景中很常见。将图像、视频或嵌套文档作为统一对象存储，比将所有内容分散在多个关系表中要自然得多。但是，如果不小心，它们可能会给查询、报表和集成带来复杂性。

因为对象模型通常与开发人员的思维方式非常接近。它可以加快应用程序开发速度。但缺点是，纯对象数据库不如关系型数据库主流，而且将其集成到更广泛的数据生态系统（尤其是商业智能领域）中可能更具挑战性。

用于分析和商业智能的维度数据建模

维度数据建模是数据仓库和商业智能解决方案的首选方法。其主要目标是优化数据结构，以实现快速查询、聚合和报告，即使这意味着有意复制或反规范化数据。

在维度模型中，数据被组织成事实表和维度表。事实表存储定量、可衡量的事件（销售额、点击量、发货量、交易量），而维度表提供描述性上下文（时间、产品、客户、地点），使您可以从多个角度对事实进行切片和切块。

再想象一下，一家汽车经销店正在构建一个数据仓库。事实表可以存储每笔销售交易，包括数量和收入等指标，而维度表可以描述“车辆”、“展厅”和“时间”。“车辆”维度将包含车型和品牌等属性；“展厅”维度将包含州/省、城市、街道和展厅名称等层级信息。

维度模型通常会有意地在不同表中复制某些数据。这种冗余设计是经过深思熟虑的，旨在加快查询速度，并简化 BI 用户的分析操作。分析师可以基于维度属性进行筛选、聚合和透视，而无需承担高度规范化关系模式带来的性能损失。

维度模型的两种经典物理模式是星形模式和雪花模式。两者都广泛应用于商业智能项目中。它们共享相同的分析核心，但维度归一化程度不同。

商业智能中的数据模型：星形和雪花形

在商业智能领域，人们谈到“数据模型”时，通常指的是报表背后的星型或雪花型模式。这些模式定义了事实和维度之间的联系，它们对分析工具的性能、可用​​性和灵活性有着重大影响。

星型模式围绕一个中心事实表展开。 它包含以最低可用详细级别（粒度）进行分析的度量，以及链接到周围维度表的外键。所有维度都直接连接到事实表，形成星形结构。

这种设计有一个很大的优势：它简化了筛选和聚合操作。由于每个维度都直接连接到事实表，因此查询非常简单，工具也能更轻松地生成 SQL。例如，您可能有一个“销售”事实表，它直接连接到“车辆”、“客户”、“展厅”和“时间”维度，所有这些维度都像星点一样向外辐射。

一旦你确定了与你要分析的事实相关的维度，就可以开始分析了。您可以构建一个维度模型来回答实际的业务问题：按汽车品牌和地区划分的销量是多少？随着时间的推移，业绩趋势如何？在库存相似的情况下，哪些展厅的业绩优于其他展厅？

雪花模式使用相同的概念构建模块，但将维度规范化为多个相关表。与其使用包含所有地理级别的单一“位置”维度，不如将其拆分为“国家”、“地区”、“城市”等等，每个维度都存储在自己的表中，并以规范化的结构链接起来。

雪花模型比星型模型更复杂。 但它们遵循相同的分析逻辑。当维度数据量庞大、共享或需要更强的规范化以避免冗余时，就会使用它们。例如，“产品”维度可以拆分为“产品”、“品牌”和“类别”三个单独的表，每个表都经过规范化并通过键连接。

实践者通常会根据性能、存储空间、维护工作量和易用性等标准来比较星型模式和雪花模式。星型模式通常在简洁性和查询速度方面更胜一筹，而雪花模式可以在维度层次结构复杂或在多个事实表中大量重用时节省存储空间并减少维护工作。

扁平化、半结构化和关联数据模型

除了经典的层级模型、网络模型、ER模型、关系模型、对象模型和维度模型之外，还有其他模型。此外，还有其他几种风格值得了解，尤其是在现代数据平台和集成场景中。

扁平数据模型是最简单的表示方法。所有数据都存储在一个包含行和列的单一表中，除此之外没有任何显式的关系或结构。为了访问特定的信息子集，系统可能需要读取表中的大量数据，随着数据量的增长，这会导致操作缓慢且效率低下。

半结构化模型是关系方法的更灵活的演进。在半结构化数据中，数据和模式之间并不总是泾渭分明。有些实体可能缺少某些属性，而另一些实体可能包含同类实体所没有的额外字段，这完全可以接受。

这种灵活性在 JSON、XML 或某些 NoSQL 数据库等格式中很常见。属性可以包含一个简单的原子值，也可以包含一个完整的集合，并且其结构可能因记录而异。这在处理不断演变或异构的数据源时非常强大，但也使严格的验证和传统的关联查询变得复杂。

关联数据模型则从另一个角度出发，将数据拆分为“项”和“链接”。任何能够独立存在的事物都被视为一个项（或元素），而项之间的关系则存储为链接（或关联）。每个元素都有一个名称和一个标识符，而每个链接都有自己的标识符以及指向源、动词和目标的属性。

请思考以下句子：“世界杯将于2022年5月30日起在伦敦举行”。关联模型可能存储一个链接，内容为“世界杯——在——伦敦举行”，其中“世界杯”是来源，“在……举行”是动词，“伦敦”是目标。另一个链接则通过动词“从”将第一个链接（来源）与开始日期（目标）连接起来。

这种基于链接的视角对于知识图谱和语义关系来说非常具有表现力。与其将关系隐藏在表连接或对象引用中，不如将它们视为可以独立查询、版本控制和分析的一等数据元素。

用于业务分析的概念数据建模

概念数据建模侧重于在非常高的层面上捕捉业务概念及其关系。无需担心数据类型、索引或物理存储等技术细节。这在项目早期阶段尤其有用，因为那时您仍在验证范围和需求。

在 Pega 和类似平台的环境中，概念数据模型首先要识别业务实体及其属性。例如，在图书仓库场景中，您可以定义一个名为“仓库”的实体，其属性包括名称、城市和容量。其他实体（例如“地址”和“库存”）将链接到“仓库”实体，以表示仓库的位置及其存放的图书。

生成的图表将这些实体、它们的核心属性以及它们之间的关键关系可视化。您无需对实现业务目标所需的每一个数据点进行建模；目标是把握全局，以便利益相关者能够看到是否存在任何明显的遗漏或错误陈述。

在与业务利益相关者会面时，概念模型就成为共同的参考依据。它帮助人们直观地了解他们的流程如何映射到数据：每个步骤涉及哪些实体，完成一个案例需要哪些属性，以及部门或系统之间存在哪些依赖关系。

早期投入足够的时间进行概念数据设计，可以大大降低后期返工的风险。如果在项目进行过程中发现关键数据需求被误解或忽略，则可能需要重做流程设计、集成和用户界面的大部分内容。一个稳健的概念模型可以在变更成本较低时发现这些误解，从而降低这种风险。

当然，概念模型并非一成不变的。随着项目推进和团队经验的积累，模型可以（也应该）不断演进。这种演进是健康探索的标志，而非失败的迹象。关键在于将概念模型维护成一份动态文档，确保项目讨论始终围绕清晰的业务数据展开。

数据模型作为鲜活的战略资产

在所有这些技术和模型类型中，一个共同的主题浮现出来：数据模型不仅仅是技术产物；它们也是战略沟通工具。无论是绘制简单的 ER 图，还是维护丰富的 BI 维度模式，你都是在以数据形式编码组织如何理解自身。

构建完善的数据模型能够支持核心业务流程，指导 IT 架构，并实现可靠的分析。它们为业务团队和技术团队提供了共同的词汇，减少了歧义，并使未来的变更不那么痛苦，因为可以通过明确定义的实体和关系来追踪这些变更的影响。

从层级树和网络图到关系表、对象层级、维度星形、扁平结构、半结构化格式和关联链接每种建模风格都有其自身在特定应用场景下的优势。现代组织很少只使用一种建模风格；相反，它们会将多种方法融合到各自的系统和数据平台中。

归根结底，数据建模的价值在于它如何有效地将纷繁复杂的现实世界需求转化为连贯、易于理解的结构。如果以严谨的态度和务实的商业思维来构建数据模型，数据模型就能成为加速开发、提高数据质量并增强企业决策能力的基础资产。