NoSQL 数据建模

RDBMS 的数据建模多年来一直是一个定义明确的学科。逻辑到物理映射和规范化/反规范化等技术已被专业人士（包括新手用户）广泛实践。然而，随着

RDBMS 的数据建模多年来一直是一个定义明确的学科。逻辑到物理映射和规范化/反规范化等技术已被专业人士（包括新手用户）广泛实践。然而，随着最近 NoSQL 数据库的出现，数据建模的相关性面临着新的挑战。一般来说，NoSQL 从业者关注物理数据模型设计而不是传统的概念/逻辑数据模型过程，原因如下：

• 以开发人员为中心的思维方式 – 通过 NoSQL 数据库中灵活的模式（或无模式）支持，应用程序开发人员通常承担数据模型设计的责任。他们根深蒂固地认为数据库模式是应用程序逻辑的一个组成部分。
• 在大规模横向扩展分布式环境中运行的高性能查询 - 与传统的集中式纵向扩展系统（包括 RDBMS 层）相反，现代应用程序在分布式横向扩展环境中运行。为了实现横向扩展，应用程序开发人员必须首先通过集中的物理数据模型设计来解决可扩展性和性能问题，从而放弃传统的概念、逻辑和物理数据模型设计过程。
• 大数据和非结构化数据——传统的关系型数据库管理系统（RDBMS）由于其严格固定的模式和有限的横向扩展能力，长期以来因缺乏对大数据和非结构化数据的支持而受到诟病。相比之下，NoSQL 数据库从一开始就被设想为能够使用在分布式横向扩展环境中运行的灵活模式来存储大型非结构化数据。

在这篇博文中，我们探讨了 NoSQL 数据建模中其他重要的思维方式变化：通过灵活模式实现开发敏捷性与数据库可管理性；业务和数据模型设计过程； RDBMS 在 NoSQL 数据建模中的作用；影响数据建模的 NoSQL 变体； NoSQL 逻辑和物理数据建模的可视化方法。我们以 NoSQL 数据建模未来的巅峰来结束这篇文章。

开发敏捷性与数据库可管理性

当今 NoSQL 中备受推崇的一个特性是应用程序开发敏捷性。这种敏捷性部分是通过灵活的模式实现的，开发人员可以完全控制数据在 NoSQL 数据库中的存储和组织方式。开发人员可以在应用程序代码中即时创建或修改数据库对象，而无需依赖 DBA 执行。结果确实提高了应用程序开发和部署的敏捷性。

然而，灵活的模式并非没有挑战。例如，由于缺乏 DBA 的监督，动态创建的数据库对象可能会导致不可预见的数据库管理问题。此外，无监督的模式更改增加了 DBA 诊断相关问题的挑战。通常，此类故障排除需要 DBA 检查用编程语言（例如 Java）而不是 RDBMS DDL（数据定义语言）编写的应用程序代码，而这是大多数 DBA 不具备的技能。

NoSQL 业务和数据模型设计流程

在传统的软件工程实践中，良好的业务和（关系）数据模型设计是中型到大型软件项目成功的关键。当 NoSQL 开发人员承担业务/数据模型设计所有权时，出现了另一个困境：数据建模工具。例如，传统的 RDBMS 逻辑和物理数据模型由专门的专业人员使用 PowerDesigner 或 ER/Studio 等商业工具进行管理和发布。

考虑到 NoSQL 技术的新生状态，还没有适合此类任务的专业品质的数据建模工具。利益相关者检查应用程序源代码以发现数据模型信息的情况并不罕见。对于企业主或产品经理等非技术用户来说，这是一项艰巨的任务。其他方法，例如从生产数据库中采样实际数据，可能同样费力且乏味。

很明显，需要对自动化和工具进行大量投资。为了帮助缓解这一挑战，我们建议 NoSQL 项目使用下图所示的业务和数据模型设计流程（以 MongoDB 以文档为中心的模型进行说明）：

图1

• 业务需求和领域模型：在高层，人们可以继续使用与数据库无关的方法（例如领域驱动设计）来捕获和定义业务需求
• 查询模式和应用程序对象模型：在生成初步业务需求和域模型后，可以使用 UML 类或对象图迭代并行地分析顶级用户访问模式和应用程序模型。借助 RDMS，应用程序可以使用声明性查询（即使用单个 SQL 表连接）或导航方法（即遍历嵌入在应用程序逻辑中的各个表）来实现数据库访问。后一种方法通常需要对象关系映射 (ORM) 层来简化繁琐的管道工作。从本质上讲，几乎所有 NoSQL 数据库都属于后一类。 MongoDB 可以通过 JSON 文档模型、SQL 子集查询和全面的二级索引功能来支持这两种方法。
• JSON 文档模型和 MongoDB 集合/文档：这部分是进行本机物理数据建模的地方。人们必须了解特定 NoSQL 产品的优点和缺点，以便进行有效的模式设计并提供有效的高性能查询。例如，对关注者和关注者等社交网络实体进行建模与对在线博客应用程序进行建模有很大不同。因此，社交网络应用程序最好使用 Neo4j 等图形 NoSQL 数据库来实现，而在线博客应用程序可以使用 MongoDB 等其他类型的 NoSQL 来实现。

RDBMS 数据建模对 NoSQL 的影响

有趣的是，老式 RDBMS 数据建模技术对于那些刚接触 NoSQL 技术的人来说仍然发挥着有意义的作用。以以文档为中心的 MongoDB 为例，下图说明了如何将关系数据模型映射到类似的 MongoDB 以文档为中心的数据模型：

图2

NoSQL 数据模型变体

在关系世界中，逻辑数据模型可以在不同的 RDBMS 产品之间合理移植。在物理数据模型中，存储子句或非标准 SQL 扩展等设计规范可能因供应商而异。各种 SQL 标准，例如 ANSI/ISO 等行业机构定义的 SQL-92 和最新的 SQL:2008，可以帮助应用程序跨不同数据库平台进行移植。

然而，在NoSQL世界中，不同NoSQL数据库之间的物理数据模型差异很大；对于 RDBMS，没有与 SQL-92 相媲美的行业标准。因此，它有助于理解各种 NoSQL 数据库模型的关键差异：

• 键值存储 – 由具有 1-n 个有效值
的唯一键组成的集合
• 列族 – 分布式数据存储，其中列由唯一键、键值以及区分当前值和过时值的时间戳组成
• 文档数据库 – 存储和管理文档及其元数据（类型、标题、作者、创建/修改/删除日期等）的系统
• 图数据库 - 使用图论将数据表示和存储为节点（人、企业、帐户或其他实体）、节点属性和边（将节点/属性相互连接的线）的系统

下图展示了基于模型复杂性和可扩展性的比较情况：

图3

值得一提的是，对于NoSQL数据模型来说，存在从简单的键值存储到高度复杂的图数据库的自然演化路径，如下图所示：

图4

NoSQL 数据模型可视化

对于概念数据模型，可以继续使用实体关系图等图表技术来对 NoSQL 应用程序进行建模。然而，逻辑和物理 NoSQL 数据建模需要新的思维，因为每个 NoSQL 产品都采用不同的本机结构。以 MongoDB 等以文档为中心的数据模型为例，可以直观地使用以下三种可视化方法中的任何一种：

• MongoDB 集合的原生可视化表示，支持嵌套子文档（参见上面的图 2）

优点 – 它通过直观的视觉表示自然地传达复杂的文档模型。
缺点 – 如果没有专门的工具支持，可视化会导致使用不统一约定或符号的临时绘图。

• 使用 JSON Designer 对选定的示例文档进行逆向工程（参见下面的图 5）

优点 – 它可以轻松地将分层模型逆向工程为存储在 NoSQL 数据库（如 MongoDB）中的现有 JSON 文档的可视化表示。
缺点 – 截至撰写本文时，JSON Designer 仅可在 iPhone / iPad 上使用。此外，它不包括本机数据库对象，例如 MongoDB 索引。

图5

• 传统的 RDBMS 数据建模工具，如 PowerDesigner（参见下图 6）

优点 – 提供商业工具支持。
缺点 – 它需要繁琐的手动准备和图表排列来表示复杂且深层嵌套的文档结构。

图6

在以后的文章中，我们将介绍其他 NoSQL 产品的特定数据模型可视化技术，例如基于列族结构的 Cassandra。

新的 NoSQL 数据建模机会

像任何新兴技术一样，NoSQL 将随着成为主流而成熟。我们为 NoSQL 设想了以下新的数据建模机会：

• 可重用的数据模型设计模式（一些特定于产品，一些不可知），有助于减少应用程序开发工作量和成本
• 统一的NoSQL模型存储库以支持不同的NoSQL产品
• 为（数据）模型驱动的设计流程和工具提供双向、往返工程支持
• 从应用程序源代码中自动提取数据模型
• 自动化代码-模型-数据一致性验证和一致性一致性指标
• 对应用程序/数据模型变更管理进行强有力的控制，并在应用程序代码、嵌入式数据模型和 NoSQL 数据库中的实际数据之间进行主动跟踪和协调

译文地址：NoSQL数据建模，感谢原作者分享。