neo4j 图书图的关系模式

wf82jlnq  于 2022-11-05  发布在  其他
关注(0)|答案(1)|浏览(157)

我制作了下面的图表,以显示与其有关系的“工作簿”和“人员”:

有两个节点:

  • 人员
  • 图书

和三个关系(及其属性,未在图中显示):

  • 读取(日期,num_stars)
  • 编写日期
  • 已检阅(日期,数字_星,文字_检阅)

如果要在关系数据库中建模,模式会是什么样子?我的想法是将每个关系和节点分解出来,类似于:

节点人员

  • 人员ID
  • 名称名称名称
    节点簿
  • 图书ID
  • 职务名称
    边缘读取
  • 发件人个人ID
  • 目标书ID
  • 日期
  • 星星数
    边缘写入
  • 发件人个人ID
  • 目标书ID
  • 日期
    边缘已审阅
  • 发件人个人ID
  • 目标书ID
  • 日期
  • 星星数
  • 文本_审阅

或者,所有节点都应该是一个表吗?如果我们要添加Movies作为另一个节点,我们如何显示Review边可以从Person-〉Book或Person-〉Movie。似乎更通用的方法可能是:

节点:

  • 识别码
  • 型号
  • //来自特定边缘表的FK
    边缘:
  • 发件人ID
  • 目的ID
  • 型号
  • //来自特定边缘表的FK

使用后一种方法有什么缺点吗?

3htmauhk

3htmauhk1#

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中给出。

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

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

每一个(Person; Book; Movie)都是一个单独的、离散的事实(“节点”),每一个箭头都是一个单独的、离散的关系,带有一个清晰的动词短语。
您添加了Movie实体,它需要大量的附加建模。用于定义ItemBookMovie)的普通关系前(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关系数据模型·渐进式

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

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

  • PDF中的数据模型

相关问题