1上下文

注意relational-database标记。
首先，我们需要了解这个问题存在的整个背景，其中包括各种可用的方法;各自的能力;以及限制（如果有的话）。之后，就很容易理解解决方案了。而且在关系范式中只有一个 * 正确 * 的解决方案。

1.1关系前

在Codd于1970年提出他的 Relational Model（关系模型）之前的20年里，已经有了非常好的DBMS。此外，供应商花了10多年的时间才生产出真正的RDBMS（1981）。在那个时代，计算机和软件都很昂贵，而且都是专有的。

• 初始访问是通过Key（层次DBMS中改进的ISAM;在网络DBMS中散列）
• 关系被实现为指针

这导致了维护方面的麻烦，并且导出/导入需要一个程序

• 在层次DBMS中，它是真正的树（有向无环图）
• 在网络数据库管理系统中，人们有更大的灵活性，可以实现树或网络。

虽然钥匙是逻辑的，但指针当然是物理的。系统正是因为这一点而受到限制。
对于科学的爱（逻辑;换句话说，只有真正的层次结构（有向无环图; Trees），正如它们存在于真实的世界中或合乎逻辑地存在于人造世界中一样，被实现了。

1.2关系模型

第一个基于或建立在逻辑学基础上的模型，有了数学定义，这就给了它被称为Model的许可。它改变了DBMS世界。与这个问题相关的主要区别是：

• 由于数学定义
• 因此，它是100%逻辑的（即，它是从物理SQL实现中移除的一个抽象级别）
• 没有什么是不能定义的
• 既然这个世界已经疯了，我就得加上这个限定词：自然界中任何合乎逻辑的东西和任何人造的东西都是可以定义的。任何不合逻辑的东西都是疯狂的。
• 关系作为键实现

这消除了维护方面的麻烦，并提供了毫不费力的导入/导出
1.3反关系
E F Codd博士是一名工程师，他和科学家沿着为IBM工作。同样，其他DBMS供应商也有科学家和工程师。
学术界不喜欢Codd和IDEF1X的工作，因为他们完全与行业和DBMS供应商隔离，他们使用和写的东西都是学术界炮制的，从那时到现在：

• 它们否认了SQL兼容平台的现实，并培养了一种不兼容的甚至不是语言的“SQL”;
• 它们抑制了IDEF 1X，反而促进了ERD，这对于建模是毫无希望的，并且不能处理关系键（组合），也不能用于任何类型的建模
• 他们不同意Codd和像我这样的实践者，因为我们不是学者，我们是现实主义者
• 它们抑制了逻辑 * 关系模型 *，并促进了20世纪60年代（前DBMS）的物理记录归档系统，错误地将其称为“关系型”。它们的特征是RecordIDs（物理记录，而不是逻辑行）。
• 请注意，这样的RFS是原始的，非常有限。它们被放置在一个SQL容器中，以便于访问（DML）和方便（备份;这样的限制被错误地归因于SQL，但它们实际上是由于原始RFS。
• RecordIDs不提供行唯一性，这是 RM 中为防止重复数据而要求的。（它们确实提供了RecordID唯一性，但这是完全不相关的，更糟糕的是，您可能认为您已经防止了数据重复，而实际上并没有
• 此外，RecordIDs始终是一个附加的非数据字段，并且比关系等价物多一个附加索引。
• 由于 RM 中的访问路径独立性规则失败，它们会强制执行更多的JOINs。
• 有关讨论，请参阅：

Creating a Relational table with 2 different auto_increment，仅适用于§1和§ 2。
因此，由于对 RM 的无知，他们提出了不合理的主张，如“RM 不能做这个或那个”，这对他们的“RM”是正确的，但对Codd的 RM 是完全错误的。

1.4 SQL与“SQL”的对比

同样，Codd定义了一种数据子语言，主要供应商（不包括Oracle）都实现了它。这就是真正的SQL，它被制定为ANSI-〉ISO/IEC标准。有一篇著名的论文Codd的十二条规则符合他的数据子语言，主要供应商都遵守，而免费软件甚至都不接近。
免费软件和Oracle不符合SQL，它们对术语SQL的使用是不合理的。Postgres和Oracle中的实现甚至不是一种语言。
因此，再次由于不知道 RM 和SQL;他们与工业界的隔绝;以及他们对他们私有的“RM”和“SQL”的执着，他们做出诸如“SQL不能做这个或那个”之类的不真实的声明，这对于他们的“SQL”和他们的“RM”来说是真实的，但是对于真实的 RM 和SQL来说是歇斯底里地错误的。

这导致了世界上95%的数据库被贴上了“关系”的标签，但它们根本不是关系型的，它们没有提供 * 关系模型 * 的任何特性和好处。当然，它并没有像预期的那样工作。因此，出现了一种从关系型（实际上是“关系型”）到各种非关系型“数据库”的运动。
最新出现的是“图形数据库”，它根本不是数据库（没有完整性，没有标准），但是它们确实提供了“关系”或“SQL”所不能提供的特性或功能。图形;树）的设计和实现是毫不费力和直接的。
值得注意的是，IBM特别要求Codd解决的一个问题是他们HDBMS中的一个特定问题，即著名的物料清单问题，他确实出色地解决了这个问题。也就是说，RM 完全支持各种类型的数据层次结构，可以使用普通的[真正的] SQL来导航它们。

1.5开发人员作为建模者

有三个问题是典型的。
首先，理解上面的上下文，这样你就会意识到你已经被反关系的废话轰炸了，这些废话不能把各种逻辑数据结构（如图）作为“关系”来处理，而关系和SQL很好地处理了所有这些结构。

• 因此，我将用关系术语为您的问题提供一个相当简单的解决方案，它很容易通过真正的SQL使用。您需要了解，图形数据库可以做 RM 做不到的任何事情，或者它在任何方面都更上级的概念是错误的。

第二个问题是常见的开发人员心态，他们关注他们的GUI;皮肤，以及他们对数据的需求。（* 我知道我需要什么，以及GUI看起来像什么 *）这很容易，因为学者们建议他们从Excel电子表格的Angular 来思考（可怕的RecordIDs）。而不是确切地说，数据是什么。

• 真正的数据建模（不管是不是关系型的）是一门科学，人们必须对数据建模，而且只对数据建模，而不考虑使用（用例）。
• 然而，使用情况随每个版本而变化，并且在计划外使用增加时会发生巨大变化
• 而数据的结构不会改变（如果建模正确，则反映了从中提取数据的真实的世界）。

第三，也许是最重要的，是分析和模拟数据的科学和方法与分析的科学和方法大不相同;设计;和建模过程。不幸的是，这些天的开发人员被OO/ORM迷住了，由于完全错误的概念，即宇宙中的一切都可以通过对象的透镜来感知和理解。

• 他们将“数据库”视为一个存储从属设备，其唯一目的是为他们的神奇对象提供 * 持久性 *，而不用考虑重构和CRUD。
• “数据库”在逻辑上是在app之内的，它只能通过app访问，而且好处很大，比如永久性;开放存取;等等丢失;未知。

2解决方案·关系模型

2.1问题

现在我们有了上面的背景和解释，我们可以考虑你提供的图表。注意，它是一张图片，而不是任何类型的模型，它集中在，它描绘，一些例子数据，以及一些例子数据之间可能的关系。一个好看的图表。

• 但是它仅仅是一个输出（用例）的全部细节，以图形的形式呈现出来。树）。如果由于可视化，一个人获得了它包含循环引用的概念（数据实际上没有），这可能是可以原谅的。再次，过于关注用例，以理解数据和建模为代价（并相对地建模，而不是作为1960年的记录归档系统）。

如果在关系数据库中对此进行建模，那么模式会是什么样子的呢？
因此，我要求你释放所有关于以下内容的概念：

• 物理RecordIDs（注意反关系的思想被错误地称为“关系”），
• 用例思维（您需要什么，而不是什么数据独立于您需要什么），
• 图表和图表“数据库”，包括那个术语，特别是几个数据样本的优秀图表（数据的图形报告）
• 任何OO/ORM的思维方式，这样你就可以有效地理解普通的关系术语和概念。否则，任何对上述内容的附加都将使数据模型和数据库变笨。

这是纯关系型的。它可以在任何真正的SQL平台（不包括免费软件平台和Oracle）上实现，并且可以毫不费力地工作。任何和所有的报告都将通过一个SELECT提供。顺序按照您的问题。

如果要在关系数据库中建模，模式会是什么样子？我的想法是将每个关系和节点分解出来，类似于：
是的。忽略小错误，这就是标准化的样子。
我们可以删除以图形为中心的名称，因为数据库的目的是反映现实，而不是从数据库中生成图形，它可以从数据中提供任何报告，而不仅仅是一个图形。

2.2关系数据模型·初始化

关系数据建模的第一次迭代，在IDEF 1X中给出。

• IDEF1X Introduction是必不可少的阅读。

或者，所有节点都应该是一个表吗？
不。那将是一个平面文件，完全不规范。一个怪物实现; maintain;和SELECT from。它将没有声明引用完整性，因此它不符合数据库的条件，更不用说关系数据库了。
如果我们要添加电影作为另一个节点，我们将如何显示审查边缘可以从一个人-〉图书或一个人-〉电影。

• 忘记“边缘”，它仅仅是许多可能的 * 显示类型之一，* 而关注数据和关系，它支持任何类型的 * 显示。

每一个（Person; Book; Movie）都是一个单独的、离散的事实（“节点”），每一个箭头都是一个单独的、离散的关系，带有一个清晰的动词短语。
您添加了Movie实体，它需要大量的附加建模。用于定义Item（Book或Movie）的普通关系前（60和70年代）和关系（80年代）方法是子类型群集。

• 解释：请参阅Subtype文档
• 供讨论：请参阅：

Structuring database relationships for tracking different variations of app settings，以及
How do I get around this relational database design smell?
看起来更通用的方法可能是：...
您的属性不完整。当您添加相关属性时，您将得到两个未规范化的文件，其中包含可为空的字段。这与数据库截然相反，通常是维护和使用的噩梦。
从种到属并不是一个非黑即白色的决定，认为它“总是好的”是一个严重的错误。* 关系模型 *，特别是正确的子类型，实现了属（基本类型）和种（子类型），因此提供了无限的使用。
使用后一种方法有什么缺点吗？
是的。违背科学或某个主题的标准总是有可怕的缺点。举几个例子：

• 声明引用完整性（FOREIGN KEY）是不可能的，因此数据没有完整性
• 非常复杂的SQL，既用于维护数据的事务，也用于提取和显示数据的报告
• 由于“数据库”在逻辑上不可访问，“数据库”用户将转变为刺客
• 完全替换“数据库”和应用程序代码是有保证的。

2.3关系数据模型·渐进式

试试这个，这是我们建模练习的第二次迭代。我已经实现了以下规则（可以随意更改它们或添加更多规则，我将更新数据模型）：

• 子类型群集为“非独占”，这意味着Item是Book或Movie，或者两者都是
• %Reviewer必须首先是Reader/Viewer
• 通过备用键使( BookTitle, Sequence ) TINYINT唯一，即对于给定的BookTitle，防止两个Authors具有相同的Sequence
• 或者，可以添加CONSTRAINT以确保增量Sequence，在这种情况下，可以删除AK

• PDF中的数据模型