1、什么是数据建模？
数据就像水，如果您不将其放在有用的容器中，可能就没用了。该容器的形状、大小和功能取决于您的预期用途，但通常来说，一个容器是必需的。
数据也是如此。在创建新的应用程序或数据解决方案时，您需要提供该数据的结构，这种结构化过程称为数据建模。
数据建模通常仅保留给高级数据库管理员（DBA）或主要开发人员使用，有时需要深厚的业务和数据建模经验及技巧。
虽然有些数据建模方案确实最好由专家来决定，但多数情况下不会特别困难。实际上，数据建模与技术问题一样，是一个商业问题。
任何人都可以进行基本的数据建模，并且随着图数据库技术的出现，将数据匹配到一致的模型比以往任何时候都更加容易。
2、数据建模的基本过程
数据建模是一个抽象过程。您从业务和用户需求（即您希望应用程序要做的事情）开始，然后在建模过程中，将这些需求映射到用于存储和组织数据的结构中。听起来很简单，对吧？
使用传统的数据库管理系统，建模远非简单。
在将您的初步构想白板化之后，关系数据库需要您创建一个逻辑模型，然后将其强制转换为表格形式的物理模型。到您拥有一个正常工作的数据库时，它看起来就不像您的原始白板草图了（这使得很难分辨它是否满足用户需求）。
另一方面，使用图技术进行数据建模再简单不过了。想象一下您的白板结构是什么样的。可能是由箭头和直线连接的圆和框的集合，对吗？
建模关键：您绘制的模型已经是一个图，由此创建图数据库只需要运行几行代码即可。
3、关系与图数据建模：匹配
让我们来看一个例子。
在下面的数据中心管理域（如下图所示）中，多个数据中心使用虚拟机和负载平衡器等基础架构来支持一些应用程序。
我们想要创建一个管理该数据中心基础架构并与之通信的应用程序，因此我们需要创建一个包含所有相关元素的数据模型。
现在，为我们的比赛。
3.1 关系数据模型
如果我们正在使用关系数据库，则业务负责人、专家和系统架构师将召集并创建一个类似于上图的数据模型，该数据模型显示了该域的实体、相互间关系以及适用于该域的任何规则。如果想尝试为每个可能的异常或违反规则（即破坏模型）的实例进行规划，将需要反复讨论。
这将是一个漫长的会议。
高级DBA会由此初始白板草图创建逻辑模型，然后再将其映射到您可以在下面看到的表和关系中。
在上图中，我们不得不向系统中增加复杂度以使其适合关系模型。首先，到处都可以看到注释FK（技术术语：外键）是增加复杂性的一个方面。
重要的是，新表已增加到图中，例如AppDatabase和UserApp。这些新表称为JOIN表。JOIN表显着降低了查询速度（想象通过您的24×7，关键任务企业应用程序将运行多少查询。是的，很多。），不幸的是，它们在关系数据模型中也是必不可少的。
3.2 图数据模型
现在让我们看一下如何使用图数据建模方法构建相同的应用程序。一开始，我们的工作是相同的 — 决策者召集起来，制作数据模型的基本白板草图（下图再次用作参考）。但是这次会议有一个关键的区别：他们早点出门，享受几个小时的水上摩托技巧（就像任何人一样）。
为什么？因为有了图数据模型，他们不必为可能影响数据库的所有可能的扩展、异常或火灾隐患进行计划。今天的会议只是一个起点，如果以后有什么事情出现，该模型将具有适应性和可扩展性。
在进行水上摩托训练后，我们的数据建模人员将返回到该过程的下一步。经过最初的白板过程，一切看起来都不同。他们没有将初始的白板模型更改为表格和JOIN，而是根据业务和用户需求丰富了白板模型。
没错：数据模型会变得更好，而不是更糟。
扩充后，添加标签、属性和关系后，新扩充的数据模型如下所示：
如您所见，丰富的数据模型与初始白板草图没有太大区别，只是您知道它更有用。实际上，现在已经可以将此数据模型加载到图数据库中（例如Neo4j），因为使用图技术，您在白板上绘制的内容就是您存储在数据库中的内容。
您和已完成的数据模型之间唯一的关系就是EXPO标记和空白的白板。
4、为什么数据建模不是一次性的操作？
消除关系数据库和图数据库之间数据建模的主要区别很容易。毕竟，数据建模只是您在应用程序开发之初就必须完成的一项活动-对吗？错误。
让我们回到故事的起点：关系数据库的数据建模对于文科专业的毕业生来说是粗略的，但是后来变得更糟了。
当我们仍处于白板和集思广益阶段时，很容易对我们的数据模型进行更改。当然，找出哪些关系必须是一对一的关系以及哪些关系必须是一对多的关系并不总是那么容易，但是执行这些更改很容易。在白板阶段之后，没有那么多。
一旦我们将白板模型插入并修改为Postgres，更改就困难得多了。从本质上来说，模式迁移并不是任何人喜欢的数据库操作（可能那个人只是跳到了注释部分）。数据库上线并投入生产后，我对所有建议的更改的回答：fugged about it。
当然，他们仍然需要更改，因为用户需求在不断变化，业务需求也不断变化。这是因为，生活无时无刻不在变化着。
为什么有人会认为数据模型不会发生变化？使用接受变更为事实并为变更做好准备的数据模型，而不是为不可避免的事做准备并做好准备，这岂不是更好吗？
5、结论：您可以相信的改变
系统在不断变化，在当今的发展世界中，它们经常在变化。实际上，即使在开发中期，您的应用程序或解决方案也可能会发生巨大变化。在应用程序的生命周期中，您的数据模型会不断变化和发展，以满足不断变化的业务和用户需求。
具有模式和复杂建模过程的关系数据库并不适合快速更改。您需要的是一个不会牺牲性能的数据模型，它在保持数据完整性的同时支持不断发展的数据。
既然您了解了数据建模的基础知识，那么选择就很清楚了。
如果您要创建一个具有易于理解的、变化最小的数据模型的应用程序，请坚持使用久经考验的关系数据库，只要坚持已经可行的方法。
但是也许您的道路将您引向了其他地方。也许您正在创建新的东西，也许您正在开拓未知领域，也许您无法为所有正确答案的数据库做计划，因为您甚至都不知道用户要问的问题。
如果这描述了您的下一个项目，那么您需要一个敏捷的数据模型，您需要一个与开发一起发展的数据模型（不分解或滞后），您需要一个图数据模型。
未来是不确定的，选择一个符合实际情况的数据模型。