Neo4j图数据库：数据建模的基础知识

原文地址：传送门   原作者：Bryo Merkl Sasaki，主编，Neo4j | 2018年7月24日

在我生命中的大约6个月时间里，我是一名数据库开发人员。

首先，我学到的第一件事是数据建模。我们的团队使用的是关系数据库(RDBMS)，特别是MySQL(我们后来改用Postgres)。与当时的许多后端开发人员一样，我们并没有刻意选择使用RDBMS，它只是默认的(现在不再是这样了)。

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

这并不是说RDBMS模型总是坏的(它不是)，也不是说它总是糟糕的(它不是)。但是当它被用作所有项目和应用程序的通用数据模型时，就会有很多不匹配的地方。

好消息是:关系模型不必是您的默认值。

其他数据模型也存在，并且它们非常棒。今天，我们将更仔细地研究其中一个——图形数据模型——并带领您体验比我最初拥有的更好的首次数据建模体验。

在这个面向初学者的图形数据库博客系列中，我将带您了解图形技术的基础知识，假设您对这个领域的背景知识很少(或者没有)。在过去的几周里，我们讨论了为什么图形技术是未来的发展方向，以及为什么连接数据很重要。

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

什么是数据建模?

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

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

数据建模通常仅为高级数据库管理员(dba)或主要开发人员保留，有时作为一种深奥的艺术呈现出来，普通人无法理解。您可能会对数据建模专家敬而远之。

虽然有些数据建模场景实际上最好留给专家处理，但默认情况下并不一定很难。事实上，数据建模既是技术问题，也是业务问题。所以如果你连一行代码都不懂，那你就走运了。

任何人都可以进行基本的数据建模，随着图形数据库技术的出现，将数据匹配到一致的模型比以往任何时候都更容易。

数据建模过程的简要概述

数据建模是一个抽象过程。您从您的业务和用户需求(即，你想让你的应用程序做什么)。然后，在建模过程中，将这些需求映射到用于存储和组织数据的结构中。听起来很简单,对吧?

对于传统的数据库管理系统，建模远非易事。

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

另一方面，为图形技术建模数据非常简单。想象一下你的白板结构是什么样的。可能是由箭头和直线连接起来的圆圈和方框的集合，对吧?

问题是:你画的模型已经是一个图形了。创建一个图形数据库只需运行几行代码。

关系与图数据建模:匹配

让我们来看一个例子。

在这个数据中心管理领域(如下图所示)，几个数据中心使用虚拟机和负载平衡器等基础设施支持一些应用程序。

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

 

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

现在，开始我们的匹配。

关系数据模型

如果我们使用关系数据库，业务负责人、主题专家和系统架构师将召集并创建一个类似于上面的图像的数据模型，该模型显示该领域的实体、它们之间的关系以及适用于该领域的任何规则。这将需要大量的反复思考，以及大量的假设——如果试图为每一个可能的异常或违反规则的情况(例如，model-breaking)实例。

这将是一个很长的会议。

在此基础上，高级DBA将从这个初始白板草图创建一个逻辑模型，然后将其映射到您可以在下面看到的表和关系中。

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

在上面的图表中，我们不得不向系统添加很多复杂性，以使其适合关系模型。首先，无论您在哪里看到注释FK(技术术语:外键)，都是另一个增加复杂性的地方。如果你不是一个经验丰富的系统管理员，当你听到“复杂性”这个词时，我会告诉你你应该怎么想:狗屎更容易碎。

最重要的是，新的表已经悄悄进入了图中，比如AppDatabase和UserApp。这些新表称为联接表。(按照行业惯例，“JOIN”是用大写字母写的，但是把JOIN表想象成对着您大喊大叫也是一个很好的视觉辅助。他们大喊大叫是因为他们很难共事。)

我不想带来坏消息，但是JOIN表会显著降低查询的速度(想象一下，您的24×7关键任务企业应用程序将运行多少查询)。是的,很多)。不幸的是，它们在关系数据模型中也是不可避免的。

图数据模型

现在让我们看看如何使用图形数据建模方法构建相同的应用程序。在开始时，我们的工作是相同的——决策者聚集在一起，生成数据模型的基本白板草图(如下图所示，以供参考)。但这次会议有一个关键的不同之处:他们早早出门，享受几个小时额外的水上摩托车特技表演(就像任何人都会做的那样)。

为什么?因为使用图形数据模型，他们不必为可能影响数据库的每个扩展、异常或火灾危险做计划。今天的会议只是一个起点，如果以后有什么事情发生，这个模型是可以适应的。没有汗水。

我们的数据中心管理域的示例模型。标题

 

从他们的水上摩托车会议刷新，我们的数据建模返回到下一步的进程。在最初的白板过程之后，一切看起来都不一样了。他们没有将最初的白板模型更改为表和连接，而是根据业务和用户需求丰富了白板模型。

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

充实之后，添加标签、属性和关系后，新充实的数据模型如下:

通过添加标签、属性和关系，我们丰富了图形数据模型。

正如您所看到的，丰富的数据模型与最初的白板草图并没有太大的不同，只是它更有帮助。实际上，这个数据模型现在已经准备好加载到图形数据库中(比如Neo4j!)，因为使用图形技术，您在白板上绘制的内容就是存储在数据库中的内容。

底线:在您和已完成的数据模型之间唯一的障碍是一个EXPO标记和一个空白白板。

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

很容易忽略关系数据库和图数据库之间数据建模的主要差异。毕竟，数据建模只是在应用程序开发开始时必须完成一次的活动，对吗?错了。

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

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

一旦我们将白板模型插入到Postgres中，更改就变得困难得多。模式迁移实际上不是任何人最喜欢的数据库活动(可能他只是跳过了注释部分)。一旦数据库运行并投入生产，我对任何提议的更改的回答都是:fuggedaboutit。

当然，西装没有忘记这一点。他们仍然需要改变，因为用户的需求是不断变化的。业务需求也在不断变化。这是因为，生活提醒:改变正在发生。

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

结论:你可以相信的改变

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

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

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

如果您正在创建一个具有良好理解的、最少更改的数据模型的应用程序，请坚持使用可靠的关系数据库。说真的，只要坚持已经奏效的方法。

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

如果这描述了您的下一个项目，那么您需要一个敏捷的数据模型。您需要一个随开发而发展的数据模型(不分解或落后)。您需要一个图形数据模型。

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