书本图的关系模式
Relational schema for a book graph
我制作了下图来展示书籍和与之相关的人：
有两个节点：
- 人
- 书本
和三个关系（及其属性，图中未显示）：
- 已读（日期，num_stars）
- 写（日期）
- 已审核（日期，num_stars，text_review）
如果要在关系数据库中对其进行建模，架构会是什么样子？我的想法是打破每一个关系和节点，比如：
NodePerson
- 人物ID
- 姓名
NodeBook
- 图书编号
- 标题
EdgeRead
- FromPersonID
- ToBookID
- 日期
- num_stars
EdgeWrote
- FromPersonID
- ToBookID
- 日期
EdgeReviewed
- FromPersonID
- ToBookID
- 日期
- num_stars
- text_review
或者，所有节点都应该是一个 table 吗？如果我们要添加 Movies 作为另一个节点，我们将如何显示 Review 边缘可能来自 Person->Book 或 Person->Movie。似乎更通用的方法可能是：
节点：
- ID
- 类型
- // 来自特定边的 FK table
边缘：
- 发件人ID
- ToID
- 类型
- // 来自特定边的 FK table
使用后一种方法有什么缺点吗？
1 上下文
注意 relational-database 标签。
首先我们需要了解这个问题存在的整个背景，包括各种可用的方法；每个人的能力；和限制（如果有的话）。之后，很容易理解解决方案。在关系范式中只有一个正确解决方案。
1.1 Pre-Relational
在 Codd 产生他的关系模型（1970 年）之前的 20 年里，DBMS 一直非常出色。此外，供应商花了 10 多年的时间才生产出真正的 RDBMS (1981)。在那个年代，电脑和软件都很贵，而且是专有的。
- 初始访问是通过密钥进行的（在分层 DBMS 中改进了 ISAM；在网络 DBMS 中散列）
- 关系是作为指针实现的
这导致了维护问题，export/import 需要一个程序
- 在层次结构 DBMS 中它是一个真正的树（有向无环图）
- 在网络 DBMS 中具有更大的灵活性，可以实现树或网络。
虽然键是合乎逻辑的，但指针当然是物理的。系统因此受到限制。
出于对科学（逻辑；理智）的热爱，没有实现循环引用（循环图）。换句话说，只实现了真实的层次结构（有向无环图；树），因为它们存在于现实世界中或在 man-made 世界中是合乎逻辑的。
1.2 关系模型
第一个以逻辑为基础或建立的逻辑，具有数学定义，这使它获得了被称为 模型 的许可。它改变了 DBMS 世界。与这个问题相关的主要区别是：
- 由于数学定义
- 因此它是 100% 逻辑的（即它是从物理 SQL 实现中删除的一个抽象级别）
- 没有什么不能定义的
既然世界已经疯了，我必须添加限定词：自然宇宙中的任何事物和任何 man-made 合乎逻辑的事物都可以定义。任何不符合逻辑的东西都是精神错乱
- 关系被实现为键
这消除了维护难题，并且提供了毫不费力的 import/export
1.3 Anti-Relational
EF Codd 博士是一名工程师，他与科学家一起为 IBM 工作。同样，其他 DBMS 供应商也有科学家和工程师。
学术界不喜欢 Codd 和 IDEF1X 的工作，因为他们完全脱离了行业和 DBMS 供应商。他们使用和撰写只有学者炮制的东西。从那时到现在：
他们否认 SQL 合规平台的现实，并培养一种“SQL”，它不合规，甚至不是一种语言；
他们压制 IDEF1X，转而培养 ERD，它对建模没有希望，不能处理关系键（复合）并且不能用于任何类型的建模
他们不同意科德和我这样的从业者，因为我们不是学者，我们是现实主义者
他们压制逻辑关系模型，并推广 1960 年代 (pre-DBMS) 的物理记录归档系统，该系统被错误地标榜为“关系”。这些以 RecordIDs 为特征（物理记录，而不是逻辑行）。
- 请注意，此类 RFS 是原始的，非常有限。它们被放置在一个 SQL 容器中，以便于访问 (DML) 和方便（备份等）。这种限制被错误地归因于 SQL，但实际上它们是由于原始 RFS。
RecordIDs 不提供行唯一性，这是 RM 所要求的，以防止重复数据。 （它们确实提供了 RecordID 唯一性，这是无关紧要的，更糟糕的是，你可能认为你已经防止了数据重复，但实际上你没有- 此外，
RecordIDs 始终是一个额外的 non-data 字段，并且比关系等效项多一个额外的索引。
- 并且由于 RM.
中的访问路径独立规则失败，他们强制执行更多 JOINs
讨论参考：
，仅限第 1 节和第 2 节。
因此他们提出不合理的要求，由于对RM的无知，例如“RM不能做这个或那个”，这对于他们的“RM”来说是正确的，但对于 Codd 的 RM.
来说是完全错误的
1.4 SQL 对比“SQL”
同样Codd定义了单一数据sub-language，各大厂商（不包括Oracle）都实现了它。那是真正的 SQL，它是一个 ANSI->ISO/IEC Stan硬。有一篇著名的论文 Codd 的十二条规则 遵守他的数据 sub-language，主要供应商遵守，免费软件甚至不接近。
免费软件和 Oracle 不符合 SQL 标准，他们使用术语 SQL 是不合理的。在 Postgres 和 Oracle 中的实现甚至不是一种语言。
所以，又是因为不知道RM和SQL；他们与行业隔绝；以及他们对私人“RM”和“SQL”的固定，他们做出不真实的声明，例如“SQL 不能做这个或那个”，这对他们的“SQL ”，以及他们的“RM”，但对于真正的 RM 和 SQL.
歇斯底里地错误
这导致世界上 95% 的数据库被标记为“关系型”，但它们根本不是关系型的，它们提供 none 关系型的特性和优势型号。当然，它并不像预期的那样工作。因此，有一种从关系型（实际上是“关系型”）转移到各种 non-Relational “数据库”的趋势。
最新出现的是“图形数据库”，它根本不是数据库（没有完整性，没有标准），但它们确实提供了“关系”或“SQL”的特性或功能” 按理说不能提供。同时，实际上，在 Codd 的 关系模型 和真正的 SQL 中，没有什么是无法定义的，数据层次结构（DAG；图形；树）毫不费力并且 straight-forward 来设计和实现。
值得注意的是，IBM 专门委托 Codd 解决的一个问题是他们 HDBMS 中的一个特定问题，涉及著名的 物料清单 问题，他确实出色地解决了这个问题。即RM完全支持各种dat层级，普通[正版]SQL即可导航
1.5 开发者作为建模者
三个问题是典型的。
首先，理解上面的上下文，这样你就会明白你被anti-Relational 不能处理各种逻辑数据结构（例如图）的废话轰炸为“关系”，并且关系和SQL 很好地处理所有这些结构。
- 因此，我将以关系术语为您的问题提供相当简单的解决方案，并且通过正版 SQL 易于使用。您需要明白，认为图数据库可以做 RM 做不到的任何事情，或者它在任何方面都更优越的想法是错误的。
第二个问题是普遍的开发人员心态，他们专注于他们的 GUI；皮肤，以及他们对数据的需求。 （我知道我需要什么，以及 GUI 的样子）这很容易，因为学者们建议他们根据 Excel 电子表格（可怕的 RecordIDs).而不是数据是什么，确切地说。
- 这削弱了建模练习。真正的数据建模（关系或非关系）是一门科学，必须对数据建模，而且只对数据建模，而不考虑使用（用例）。
- 虽然每个版本的使用都会发生变化，并且在添加计划外使用时会发生巨大变化
- 而数据的结构没有改变（如果建模正确，反映了从中提取数据的真实世界）。
第三，可能是最重要的一点是，用于分析和建模的科学和方法 数据 与分析的科学和方法非常不同；设计；和建模 过程 。不幸的是，如今的开发人员着迷于 OO/ORM，因为完全错误的观念认为宇宙中的一切都可以通过对象的镜头来感知和理解。
- 他们把“数据库”当作存储的奴隶，唯一的目的就是为他们神奇的对象提供持久性，更不用说重构和增删改查了。
- “数据库”在逻辑上是在应用程序中的，它只能通过应用程序访问，并且具有永久性等巨大好处；开放获取；等 Open Architecture 丢失；未知。
2 解决方案 • 关系模型
2.1 问题
既然我们有了上面的上下文和解释，我们就可以考虑您提供的图表了。请注意，这是一张图片，而不是任何类型的模型，它专注于描述一些示例数据以及该示例数据之间的一些可能关系。还有一个 good-looking 图。
- 但它只是完整详细的输出（用例），以图形形式呈现。它不是图（DAG；树）。如果由于视觉原因，人们认为它包含循环引用（数据实际上不包含），那么人们可能会被原谅。同样，过多地关注用例，以牺牲 o理解数据并对其建模（并对其进行关系建模，而不是作为 1960 年代的记录归档系统）。
If this were to be modeled in a relational database, what might the schema look like?
因此我会要求你释放所有关于 re:
的概念
- 物理
RecordIDs（提防 anti-Relational 想法被错误地当作“关系”），
- use case mindset（你需要什么，相对于你需要什么数据是独立的），
- 图表和图表“数据库”，包括该术语，尤其是一些数据样本的优秀图表（数据的图形报告）
- 您可能拥有的任何 OO/ORM 心态
这样您就可以有效地理解普通的关系术语和概念。除非另有说明，以上内容的任何附件都将 dumb-down 数据模型和数据库。
这是纯粹的关系。它可以在任何正版 SQL 平台（不包括免费软件平台和 Oracle）中实施，并且毫不费力地工作。任何和所有报告都将通过单个 SELECT 提供。顺序按照你的问题。
If this were to be modeled in a relational database, what might the schema look like? My thought was breaking out every relationship and node out, something like:
是的。忽略小错误，这就是规范化的样子。
我们可以删除 graph-centric 名称，因为数据库旨在反映现实，而不是许多可能的用途之一是从中生成图表这一事实。它可用于提供数据的任何报告，而不仅仅是图表。
2.2 关系数据模型 • 初始
关系数据建模的第一次迭代，在 IDEF1X 中给出。
Or, should all nodes be a single table?
没有。那将是一个平面文件，完全 un-Normalised。一个难以实施的怪物；维持;和 SELECT 来自。它没有声明性参照完整性，因此不符合数据库的条件，更不用说关系数据库了。
If we were to add Movies as another node, how would we show that an Review edge may go from a Person->Book OR a Person->Movie.
忘掉“边缘”，它只是众多可能显示类型中的一种，关注支持任何类型的数据和关系 显示。
其中的每一个 (Person; Book; Movie) 都是一个独立的、离散的事实（“节点”），并且每个箭头都是一个独立的、离散的关系，具有清晰的 VerbPhrase。
您已经添加了 Movie 实体，这需要大量的额外建模。用于定义 Book 或 Movie 的 Item 的普通 pre-Relational（60 年代和 70 年代）和关系（80 年代）方法是子类型簇。
- 解释：参考Subtype文档
- 讨论：参考：
，以及
It seems maybe a more generic way to do it might be: ...
您的属性不完整。添加相关属性后，您将得到两个 un-Normalised 文件，其中包含可为空的字段。数据库的对立面，通常是维护和使用的噩梦。
从物种转移到属并不是一个 black-or-white 决定，认为它“总是好的”是一个严重的错误。 关系模型，特别是正确的子类型，实现了属（Basetype）和种（Subtype），因此可以无限使用。
Are there any disadvantages of using this later approach instead?
是的。违背科学或涵盖某个主题的标准总是有可怕的缺点。列举几个：
- 声明性引用完整性 (
FOREIGN KEY) 是不可能的，因此数据没有完整性
- 非常复杂SQL，对于用于维护数据的事务，以及用于提取和显示数据的报告
- 由于“数据库”在逻辑上无法访问，“数据库”用户将变身杀手
- 保证完全替换“数据库”和应用程序代码。
2.3 关系数据模型 • 已进步
试试这个，这是我们建模练习中的第二次迭代。我已经实现了以下规则（随意更改或添加更多，我将更新数据模型）：
- 子类型簇是 Non-Exclusive，这意味着
Item 是 Book 或 Movie，或两者都是
- 一个
%Reviewer必须先是一个Reader/Viewer
( BookTitle, Sequence ) TINYINT 通过备用键变得唯一，即。对于给定的 BookTitle，两个 Authors 无法拥有相同的 Sequence
- 或者，可以添加
CONSTRAINT 以确保增量 Sequence，在这种情况下可以删除 AK
- PDF
中的数据模型
我制作了下图来展示书籍和与之相关的人：
有两个节点：
- 人
- 书本
和三个关系（及其属性，图中未显示）：
- 已读（日期，num_stars）
- 写（日期）
- 已审核（日期，num_stars，text_review）
如果要在关系数据库中对其进行建模，架构会是什么样子？我的想法是打破每一个关系和节点，比如：
NodePerson
- 人物ID
- 姓名
NodeBook
- 图书编号
- 标题
EdgeRead
- FromPersonID
- ToBookID
- 日期
- num_stars
EdgeWrote
- FromPersonID
- ToBookID
- 日期
EdgeReviewed
- FromPersonID
- ToBookID
- 日期
- num_stars
- text_review
或者，所有节点都应该是一个 table 吗？如果我们要添加 Movies 作为另一个节点，我们将如何显示 Review 边缘可能来自 Person->Book 或 Person->Movie。似乎更通用的方法可能是：
节点：
- ID
- 类型
- // 来自特定边的 FK table
边缘：
- 发件人ID
- ToID
- 类型
- // 来自特定边的 FK table
使用后一种方法有什么缺点吗？
1 上下文
注意 relational-database 标签。
首先我们需要了解这个问题存在的整个背景，包括各种可用的方法；每个人的能力；和限制（如果有的话）。之后，很容易理解解决方案。在关系范式中只有一个正确解决方案。
1.1 Pre-Relational
在 Codd 产生他的关系模型（1970 年）之前的 20 年里，DBMS 一直非常出色。此外，供应商花了 10 多年的时间才生产出真正的 RDBMS (1981)。在那个年代，电脑和软件都很贵，而且是专有的。
- 初始访问是通过密钥进行的（在分层 DBMS 中改进了 ISAM；在网络 DBMS 中散列）
- 关系是作为指针实现的
这导致了维护问题，export/import 需要一个程序 - 在层次结构 DBMS 中它是一个真正的树（有向无环图）
- 在网络 DBMS 中具有更大的灵活性，可以实现树或网络。
虽然键是合乎逻辑的，但指针当然是物理的。系统因此受到限制。
出于对科学（逻辑；理智）的热爱，没有实现循环引用（循环图）。换句话说，只实现了真实的层次结构（有向无环图；树），因为它们存在于现实世界中或在 man-made 世界中是合乎逻辑的。
1.2 关系模型
第一个以逻辑为基础或建立的逻辑，具有数学定义，这使它获得了被称为 模型 的许可。它改变了 DBMS 世界。与这个问题相关的主要区别是：
- 由于数学定义
- 因此它是 100% 逻辑的（即它是从物理 SQL 实现中删除的一个抽象级别）
- 没有什么不能定义的
既然世界已经疯了，我必须添加限定词：自然宇宙中的任何事物和任何 man-made 合乎逻辑的事物都可以定义。任何不符合逻辑的东西都是精神错乱
- 关系被实现为键
这消除了维护难题，并且提供了毫不费力的 import/export
1.3 Anti-Relational
EF Codd 博士是一名工程师，他与科学家一起为 IBM 工作。同样，其他 DBMS 供应商也有科学家和工程师。
学术界不喜欢 Codd 和 IDEF1X 的工作，因为他们完全脱离了行业和 DBMS 供应商。他们使用和撰写只有学者炮制的东西。从那时到现在：
他们否认 SQL 合规平台的现实，并培养一种“SQL”，它不合规，甚至不是一种语言；
他们压制 IDEF1X，转而培养 ERD，它对建模没有希望，不能处理关系键（复合）并且不能用于任何类型的建模
他们不同意科德和我这样的从业者，因为我们不是学者，我们是现实主义者
他们压制逻辑关系模型，并推广 1960 年代 (pre-DBMS) 的物理记录归档系统，该系统被错误地标榜为“关系”。这些以
RecordIDs为特征（物理记录，而不是逻辑行）。- 请注意，此类 RFS 是原始的，非常有限。它们被放置在一个 SQL 容器中，以便于访问 (DML) 和方便（备份等）。这种限制被错误地归因于 SQL，但实际上它们是由于原始 RFS。
RecordIDs不提供行唯一性，这是 RM 所要求的，以防止重复数据。 （它们确实提供了RecordID唯一性，这是无关紧要的，更糟糕的是，你可能认为你已经防止了数据重复，但实际上你没有- 此外，
RecordIDs始终是一个额外的 non-data 字段，并且比关系等效项多一个额外的索引。 - 并且由于 RM. 中的访问路径独立规则失败，他们强制执行更多
JOINs讨论参考：
因此他们提出不合理的要求，由于对RM的无知，例如“RM不能做这个或那个”，这对于他们的“RM”来说是正确的，但对于 Codd 的 RM.
来说是完全错误的1.4 SQL 对比“SQL”
同样Codd定义了单一数据sub-language，各大厂商（不包括Oracle）都实现了它。那是真正的 SQL，它是一个 ANSI->ISO/IEC Stan硬。有一篇著名的论文 Codd 的十二条规则 遵守他的数据 sub-language，主要供应商遵守，免费软件甚至不接近。
免费软件和 Oracle 不符合 SQL 标准，他们使用术语 SQL 是不合理的。在 Postgres 和 Oracle 中的实现甚至不是一种语言。
所以，又是因为不知道RM和SQL；他们与行业隔绝；以及他们对私人“RM”和“SQL”的固定，他们做出不真实的声明，例如“SQL 不能做这个或那个”，这对他们的“SQL ”，以及他们的“RM”，但对于真正的 RM 和 SQL.
歇斯底里地错误这导致世界上 95% 的数据库被标记为“关系型”，但它们根本不是关系型的，它们提供 none 关系型的特性和优势型号。当然，它并不像预期的那样工作。因此，有一种从关系型（实际上是“关系型”）转移到各种 non-Relational “数据库”的趋势。
最新出现的是“图形数据库”，它根本不是数据库（没有完整性，没有标准），但它们确实提供了“关系”或“SQL”的特性或功能” 按理说不能提供。同时，实际上，在 Codd 的 关系模型 和真正的 SQL 中，没有什么是无法定义的，数据层次结构（DAG；图形；树）毫不费力并且 straight-forward 来设计和实现。
值得注意的是，IBM 专门委托 Codd 解决的一个问题是他们 HDBMS 中的一个特定问题，涉及著名的 物料清单 问题，他确实出色地解决了这个问题。即RM完全支持各种dat层级，普通[正版]SQL即可导航
1.5 开发者作为建模者
三个问题是典型的。
首先，理解上面的上下文，这样你就会明白你被anti-Relational 不能处理各种逻辑数据结构（例如图）的废话轰炸为“关系”，并且关系和SQL 很好地处理所有这些结构。
- 因此，我将以关系术语为您的问题提供相当简单的解决方案，并且通过正版 SQL 易于使用。您需要明白，认为图数据库可以做 RM 做不到的任何事情，或者它在任何方面都更优越的想法是错误的。
第二个问题是普遍的开发人员心态，他们专注于他们的 GUI；皮肤，以及他们对数据的需求。 （我知道我需要什么，以及 GUI 的样子）这很容易，因为学者们建议他们根据 Excel 电子表格（可怕的 RecordIDs).而不是数据是什么，确切地说。
- 这削弱了建模练习。真正的数据建模（关系或非关系）是一门科学，必须对数据建模，而且只对数据建模，而不考虑使用（用例）。
- 虽然每个版本的使用都会发生变化，并且在添加计划外使用时会发生巨大变化
- 而数据的结构没有改变（如果建模正确，反映了从中提取数据的真实世界）。
第三，可能是最重要的一点是，用于分析和建模的科学和方法 数据 与分析的科学和方法非常不同；设计；和建模 过程 。不幸的是，如今的开发人员着迷于 OO/ORM，因为完全错误的观念认为宇宙中的一切都可以通过对象的镜头来感知和理解。
- 他们把“数据库”当作存储的奴隶，唯一的目的就是为他们神奇的对象提供持久性，更不用说重构和增删改查了。
- “数据库”在逻辑上是在应用程序中的，它只能通过应用程序访问，并且具有永久性等巨大好处；开放获取；等 Open Architecture 丢失；未知。
2 解决方案 • 关系模型
2.1 问题
既然我们有了上面的上下文和解释，我们就可以考虑您提供的图表了。请注意，这是一张图片，而不是任何类型的模型，它专注于描述一些示例数据以及该示例数据之间的一些可能关系。还有一个 good-looking 图。
- 但它只是完整详细的输出（用例），以图形形式呈现。它不是图（DAG；树）。如果由于视觉原因，人们认为它包含循环引用（数据实际上不包含），那么人们可能会被原谅。同样，过多地关注用例，以牺牲 o理解数据并对其建模（并对其进行关系建模，而不是作为 1960 年代的记录归档系统）。
If this were to be modeled in a relational database, what might the schema look like?
因此我会要求你释放所有关于 re:
的概念- 物理
RecordIDs（提防 anti-Relational 想法被错误地当作“关系”）， - use case mindset（你需要什么，相对于你需要什么数据是独立的），
- 图表和图表“数据库”，包括该术语，尤其是一些数据样本的优秀图表（数据的图形报告）
- 您可能拥有的任何 OO/ORM 心态 这样您就可以有效地理解普通的关系术语和概念。除非另有说明，以上内容的任何附件都将 dumb-down 数据模型和数据库。
这是纯粹的关系。它可以在任何正版 SQL 平台（不包括免费软件平台和 Oracle）中实施，并且毫不费力地工作。任何和所有报告都将通过单个 SELECT 提供。顺序按照你的问题。
If this were to be modeled in a relational database, what might the schema look like? My thought was breaking out every relationship and node out, something like:
是的。忽略小错误，这就是规范化的样子。
我们可以删除 graph-centric 名称，因为数据库旨在反映现实，而不是许多可能的用途之一是从中生成图表这一事实。它可用于提供数据的任何报告，而不仅仅是图表。
2.2 关系数据模型 • 初始
关系数据建模的第一次迭代，在 IDEF1X 中给出。
Or, should all nodes be a single table?
没有。那将是一个平面文件，完全 un-Normalised。一个难以实施的怪物；维持;和 SELECT 来自。它没有声明性参照完整性，因此不符合数据库的条件，更不用说关系数据库了。
If we were to add Movies as another node, how would we show that an Review edge may go from a Person->Book OR a Person->Movie.
忘掉“边缘”，它只是众多可能显示类型中的一种，关注支持任何类型的数据和关系 显示。
其中的每一个 (Person; Book; Movie) 都是一个独立的、离散的事实（“节点”），并且每个箭头都是一个独立的、离散的关系，具有清晰的 VerbPhrase。
您已经添加了 Movie 实体，这需要大量的额外建模。用于定义 Book 或 Movie 的 Item 的普通 pre-Relational（60 年代和 70 年代）和关系（80 年代）方法是子类型簇。
- 解释：参考Subtype文档
- 讨论：参考：
It seems maybe a more generic way to do it might be: ...
您的属性不完整。添加相关属性后，您将得到两个 un-Normalised 文件，其中包含可为空的字段。数据库的对立面，通常是维护和使用的噩梦。
从物种转移到属并不是一个 black-or-white 决定，认为它“总是好的”是一个严重的错误。 关系模型，特别是正确的子类型，实现了属（Basetype）和种（Subtype），因此可以无限使用。
Are there any disadvantages of using this later approach instead?
是的。违背科学或涵盖某个主题的标准总是有可怕的缺点。列举几个：
- 声明性引用完整性 (
FOREIGN KEY) 是不可能的，因此数据没有完整性 - 非常复杂SQL，对于用于维护数据的事务，以及用于提取和显示数据的报告
- 由于“数据库”在逻辑上无法访问，“数据库”用户将变身杀手
- 保证完全替换“数据库”和应用程序代码。
2.3 关系数据模型 • 已进步
试试这个，这是我们建模练习中的第二次迭代。我已经实现了以下规则（随意更改或添加更多，我将更新数据模型）：
- 子类型簇是 Non-Exclusive，这意味着
Item是Book或Movie，或两者都是 - 一个
%Reviewer必须先是一个Reader/Viewer ( BookTitle, Sequence ) TINYINT通过备用键变得唯一，即。对于给定的BookTitle，两个Authors无法拥有相同的Sequence- 或者，可以添加
CONSTRAINT以确保增量Sequence，在这种情况下可以删除AK
- 或者，可以添加