我在生命中的六个月时间里,是一名数据库开发人员。

首先,我学到的第一件事是数据建模。我们的团队使用的是关系数据库(RDBMS),特别是MySQL(我们后来切换到Postgres)。像当时的许多后端开发人员一样,我们没有故意选择使用RDBMS,这只是默认选项(不再是这种情况)。

当然,这意味着我在数据建模方面的课程将遵循关系数据模型 - 这不是破坏结局 - 但它很糟糕。

这并不是说RDBMS模型总是坏的或它总是糟透了。但是,当它被用来作为每个项目和应用程序的数据模型,嗯,这将会有很多不匹配和合理的问题。

好消息是关系模型不一定是你的默认选项。

还存在其他非常棒的数据模型。今天,我们将仔细研究一个特别的-图形数据模型-并让你体验一次比我最初拥有的更好的数据建模体验。

在这个为图数据库初学者准备的博客系列中,我将向你介绍图形技术的基础知识, 无论你在这个领域有很少经验甚至是没有都可以有所收获。在过去的几周里,我们已经阐述了为什么图技术是未来为什么有联系的数据如此重要

本周,我们将讨论图形技术的数据建模基础知识。

到底什么是数据建模?

数据就像水。如果你不把它放在一个有用的容器里,它可能一点用处也没有。容器的形状,大小和功能取决于你的预期用途,但通常容器是必需的。

数据也是如此。在创建新的应用程序或数据解决方案时,你需要为该数据提供结构。该结构化过程称为数据建模

通常数据建模仅为高级数据库管理员(DBA)或主要开发人员所涉及,数据建模有时被呈现为一种不为人所知的深奥艺术。你可能会非常崇拜数据建模专家。

虽然一些数据建模场景最好是让专业的数据专家处理,但通常情况下这并不会很难。事实上,数据建模既是技术问题,也是业务问题。

任何人都可以进行基本的数据建模,随着图形数据库技术的出现,将数据与相干模型相匹配比以往更容易。

数据建模过程简介

数据建模是一个抽象过程。你从业务和用户需求出发。然后在建模过程中,你将这些需求映射到用于存储和组织数据的结构中。听起来很简单吧?

使用传统的数据库管理系统,建模远非简单。

在构思你的初始想法之后,关系数据库要求你创建逻辑模型,然后将该结构强制转换为表格式物理模型。当您拥有一个可用的数据库时,它看起来一点也不像您最初的白板草图(很难判断它是否满足了用户的需求)。

另一方面,为图形技术建模数据并不简单。想象一下你的白板结构是什么样的。可能是由箭头和线条连接的圆圈和方框的集合,对吗?

这里的关键是:你画的那个模型已经是一个图形了。从那幅图里构建一个图形数据库仅仅就是写几行代码这么简单了。

关系建模vs图形数据建模:匹配

我们来看一个例子吧。

在这个数据中心管理域(如下图所示)中,几个数据中心使用像虚拟机或负载均衡器等架构的应用程序。

数据中心管理域初始“白板”形式的示例模型
数据中心管理域初始“白板”形式的示例模型

我们希望创建一个管理这个数据中心基础架构并与之通信的应用程序,因此我们需要创建一个包含所有相关元素的数据模型。

现在,我们开始建立这层匹配吧。

关系数据模型

如果我们使用关系数据库,业务负责人和系统架构师将归纳并创建一个类似于下面图片中的数据模型,该模型显示该领域的实体、它们之间的关系以及适用于该领域的任何规则。这将需要大量的反复思考,以及为大量可能造成异常或违反规则的情况做假设。

这将是一次漫长的过程。

从那开始,DBA童鞋将从这个初始白板草图创建一个逻辑模型,然后将其映射到你下面看到的表格和关系中去。

我们最初的“白板”数据模型的关系数据库版本。添加了几个JOIN表,这样不同的表就可以彼此通信。
我们最初的“白板”数据模型的关系数据库版本。添加了几个JOIN表,这样不同的表就可以彼此通信。

在上图中,我们不得不在系统中添加许多复杂结构使其适合关系模型。首先,无论你在哪里看到的外键都是一个增加复杂性的点。如果你不是一个经验丰富的系统管理员,当你听到“复杂性”时,我会让你知道你应该怎么想:好坑爹呀!!!

除此之外,一些新表已经加入到这个图中,例如AppDatabase和UserApp。这些新表称为JOIN表。

我不想带来坏消息,但是JOIN表会显著降低查询的速度。不幸的是,它们在关系数据模型中也是不可避免的。

图数据模型

现在让我们看一下如何使用图形数据建模方法构建相同的应用程序。最初,我们的工作是相同的 - 决策者制作数据模型的基本白板草图。但是这次的结果不同:他们早早出去享受几个小时愉快时光了😁。

为什么这样呢?因为使用图数据模型,他们不必为可能影响数据库的每个扩展、异常或危险做计划。今天的讨论只是一个起点,如果以后有什么事情发生,这个模型是可以适应的。不会大动干戈, 推到重来。

数据中心管理域的一个样本模型
数据中心管理域的一个样本模型

在最初的白板过程之后,一切看起来都不同。它们不是将初始白板模型更改为表格和表格之间的关联关系,而是根据业务和用户需求丰富白板模型。

没错:数据模型变得更好,而不是更糟。

在丰富模型之后,这是添加标签,属性和关系后数据模型的样子:

经过丰加强的数据模型的样子
经过丰加强的数据模型的样子

我们丰富的图形数据模型,添加了标签,属性和关系。

正如你所看到的,丰富的数据模型与初始的白板草图没有太大的不同,但是更加有帮助了。事实上,这个数据模型现在可以加载到图形数据库(例如Neo4j)中,因为使用图形技术,你在白板上绘制的草图就是你存储在数据库中的内容。

为什么数据建模不是一次性活动(无论你使用什么数据库)

很容易忽略关系数据库和图形数据库之间数据建模的主要差异。毕竟,数据建模只是在应用程序开发开始时必须完成的一项活动 - 是这样吗?并不是。

让我们回到故事时间:RDBMS数据建模对于文科毕业生来说是很粗糙的,但后来变得更糟了。

当我们还处于白板和头脑风暴阶段时,对我们的数据模型进行更改是很容易的。当然,要弄清楚哪些关系必须是一对一的,哪些关系必须是一对多的并不总是那么容易,但是执行这些更改非常容易。在白板阶段之后,就没那么容易了。

一旦我们将我们的白板模型插入Postgres,改变模型就会变得更加困难。模式迁移实际上并不是人们最喜欢的数据库活动。一旦数据库生效并投入生产,我对任何提议的更改的答案都是:fuggedaboutit(应该是”算了吧, 别想这回事儿了的意思”-译者注)。

但是, 他们仍然需要改变,因为用户的需求在不断变化。业务需求也在不断变化。那是因为改变是经常会发生的。

为什么有人会假设他们的数据模型不会发生变化呢?使用一个接受变化并为之做好准备的数据模型而不是固守现状,为不可避免的变化做好准备难道不是更好吗?

结论:你可以相信的改变

系统在变化,在入金的的开发世界中,它们经常变化。事实上,即使在开发中期,你的应用程序或解决方案也可能发生重大变化。在应用程序的生命周期中,数据模型不断地变化和发展,以满足不断变化的业务和用户需求。

关系型数据库——具有严格的模式和复杂的建模过程——不适合快速更改。你需要的是一个不牺牲性能的数据模型,它支持在保持数据完整性的同时进行不断的改进。

既然你已经了解了数据建模的基础知识,那么选择就很清楚了。

如果你正在创建一个具有易理解的、最少更改数据模型的应用程序,请坚持使用”可靠的”关系数据库。说真的,只要坚持已见成效的方法。

但也许你的道路正把你引向另一个地方。也许你正在创造一些新的东西。也许你正在开拓未知领域。也许你无法计划一个包含所有正确答案的数据库,因为你甚至不知道用户将会问什么问题。

如果这描述了你的下一个项目,那么你需要一个敏捷的数据模型。你需要一个随开发进展而发展的数据模型。你应该会需要一个图形数据模型。

未来是不确定的(你可以相信)。选择一个符合实际情况的数据模型。

原文链接:Graph Databases for Beginners: The Basics of Data Modeling

译文连接:图数据库初学者:数据建模的基础知识

翻译:TomorJM