数据建模:第一部分 — 目标和方法

导航至

本文最初发表于 The New Stack,并经许可在此转载。

在不同的技术中,实体和关系仍然是核心。然而,它们的性质和作用会根据业务目标重新解释。

数据建模是定义和表示系统中数据元素的过程,以便沟通数据点和结构之间的联系。Martin Kleppmann 在他影响深远的著作《Designing Data-Intensive Applications》中,将数据建模描述为开发任何信息系统中最关键的步骤。

了解哪些数据与业务相关以及以何种形式相关,需要职能部门和技术人员之间的沟通。此外,允许信息系统内各组件之间的数据共享对于系统的良好运行至关重要。引用 Kleppmann 的话,“数据模型不仅对软件的编写方式产生深远影响,而且对我们思考要解决的问题的方式也产生深远影响。”

那么,数据模型到底是什么呢?

数据模型是描述系统中存储的数据结构的规范。

此外,它还可以定义约束,以保证数据完整性,并标准化如何表示(规则)、存储(格式)或共享(协议)数据。在文献中,我们通常区分数据建模的三个不同层次(见金字塔图)

data model

  • 概念层定义系统包含什么。业务干系人通常创建概念模型。目的是组织、界定和定义业务概念和规则。定义在这一层最重要,例如产品。
  • 逻辑层定义数据库管理系统 (DBMS) 应如何实现。逻辑模型在技术上是有偏见的,其创建目的是开发规则和数据结构的技术地图。关系和属性变得可见,例如,产品名称和价格。
  • 物理层描述如何使用特定技术来实现信息系统。物理模型的创建目的是实现数据库。物理层探索数据结构和算法方面的权衡。

在 InfluxDB 大学的 Beginner Flux 培训期间,我们使用了相同的层次来理解时间序列数据如何映射到 Flux 数据结构和 InfluxDB 的行协议数据模型。在这里,我们将进一步深入研究 InfluxDB 和 Flux 的数据建模。因此,值得回顾的是

  • 从概念上讲,时间序列是由一个(且只有一个)度量和一组标签描述的、带时间戳的数据点的有序集合。
  • 从逻辑上讲,Flux 同时表示多个序列,并通过一组名为字段的键值对来表示不同的值。此外,标签是键值对,有助于进一步分区数据以进行处理。
  • 从物理上讲,InfluxDB 将数据存储到时间结构合并树中;还值得一提的是,标签的键和值都被索引。

数据建模方法的简史

既然我们已经 Clarified 数据模型是什么以及数据建模的目标,我们就可以讨论如何实现目标。在实践中,文献中存在几种方法。下面列出的最突出的方法在目标信息系统和工作负载方面有所不同,例如在线事务处理 (OLTP) 和 DBMS;在线分析处理 (OLAP) 和数据仓库;以及大数据和数据湖。

  • 关系建模 (RM) 侧重于为涵盖整个企业业务的模型删除冗余信息。RM 使用关系(表)来描述域实体及其关系。
  • 维度建模 (DM) 侧重于在处理大型和复杂(分析)查询时,实现完整的需求分析,同时保持高性能。DM 旨在优化数据访问;因此,它专为 OLAP 定制。星型和雪花模型是维度建模的显著成果。

值得注意的是,考虑到上述逻辑和物理抽象级别,RM 和 DM 产生了显著不同的结果。尽管如此,当在概念层操作时,它们都共享相似的概念化和工具。实际上,实体关系 (ER) 建模技术和图表是上述所有模型以及图数据库或语义存储的基础。因此,值得回顾一下 ER 的含义

  • 实体是存在且与其他对象可区分的对象。实体具有类型和描述性属性;实体集将相同类型的实体分组。名为主键的属性唯一标识集合中的每个实体。
  • 关系是多个实体之间的关联。关系的基数描述了另一个实体可以关联到的实体数量;我们考虑一对一、一对多和多对一。

data relationship

在不同的技术中,实体和关系仍然是核心。然而,它们的性质和作用会根据业务目标重新解释。例如,RM 强调识别尽可能多的实体以避免数据冗余。实际上,冗余会随着时间的推移产生维护问题,这与用户对一致性的需求相悖。

相反,DM 围绕事实构建,这些事实使用其多对多关系从其他实体借用其身份。这些实体被解释为维度,例如,提供事实上下文的描述性信息。DM 是数据仓库用户最感兴趣的,他们最关心的是分析。上述两种建模技术都可以在一定程度上表示时间。

  • 在关系建模中,时间只是一个属性。实体和关系可以更新,但概念模式不在此级别携带信息。已经提出了关系建模方法的时间扩展。然而,它们是为时间数据库量身定制的,时间数据库侧重于其实体的时间有效性(作为一种一致性形式),而不是时间序列数据库 (TSDB) 及其随时间变化的属性的历史记录。
  • 在维度建模中,时间被视为一个分析维度——它代表一个可能的切片主题,产生重要的聚合。维度模型中的维度表不考虑概念层面的变化。然而,在较低级别,可能会发生变化。已经提出了处理此类“缓慢变化维度”的不同方法,包括跟踪其历史记录,这与 TSDB 的做法类似。