图书图表的关系模式 [英] Relational schema for a book graph

查看：44
本文介绍了图书图表的关系模式的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我制作了以下图表，以显示与其有关系的图书和人员：

有两个节点：

  • 人员
  • 书籍

和三个关系(具有它们的属性，未在图形中显示)：

  • READ(DATE，NUM_STARS)
  • 已写入(日期)
  • 已审阅(DATE，NUM_STARS，TEXT_REVIEW)
如果要在关系数据库中对此进行建模，模式可能是什么样子？我的想法是打破每一个关系和节点，大概是这样的：

节点人员

  • PersonId
  • 名称

NodeBook

  • BookID
  • 标题

EdgeRead

  • 来自PerromPersonID
  • ToBookID
  • 日期
  • Num_Stars

边缘写入

  • 来自PerromPersonID
  • ToBookID
  • 日期

边审阅

  • 来自PerromPersonID
  • ToBookID
  • 日期
  • Num_Stars
  • TEXT_REVIEW
或者，所有节点都应该是单个表吗？如果我们将电影添加为另一个节点，我们将如何显示评论边可能来自Person->Book或Person-&>Movie。似乎更通用的方法可能是：

节点：

  • ID
  • 类型
  • //来自特定边缘表的FK

边缘：

  • FromID
  • toid
  • 类型
  • //来自特定边缘表的FK

改用后一种方法有什么缺点吗？

推荐答案

1上下文

注意relational-database标记。

首先，我们需要了解此问题存在的整个上下文，其中包括各种可用的方法；每种方法的功能；以及限制(如果有)。然后，很容易理解解决方案。而且在关系范式中只有一个正确的解决方案。

1.1%前期关系

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

  • 初始访问按键访问(层次化DBMS改进ISAM；网络DBMS哈希)
  • 关系以指针形式实现
    这导致了维护难题，并且导出/导入需要一个程序
  • 在分层DBMS中，它是真正的树(有向无环图)
  • 在网络DBMS中更灵活，可以实现树，也可以实现网络。

虽然键是逻辑的，但指针当然是物理的。因此，系统受到了专门的限制。

出于对科学(逻辑；理智)的热爱，没有实现循环引用(循环图)。换句话说，只实现了真实的层次结构(有向无环图；树)，因为它们存在于现实世界或人造世界中的逻辑中。

1.2版本关系模型

第一个以逻辑为基础或建立的，具有数学定义的，这使它有权被称为模型。但是它改变了DBMS的世界。与这个问题相关的主要区别是：

  • 由于数学定义
    • 因此它是100%逻辑的(即它是从物理SQL实现中移除的一个抽象级别)
    • 没有什么不能定义的
      既然这个世界疯了，我就得加上限定词：任何自然宇宙中的东西，任何人造的东西，只要符合逻辑，都可以定义。"任何不符合逻辑的东西都是疯狂的
  • 关系实现为键
    这消除了维护方面的麻烦，使导入/导出变得轻而易举

1.3%反关系

E F Codd博士是一名工程师，他和科学家一起为IBM工作。同样，其他DBMS供应商也有科学家和工程师。

学术界不喜欢Codd的工作，IDEF1X因为他们与业界和DBMS供应商完全隔绝。他们使用和写只有学者才能炮制的东西。从那时起，一直到现在：

  • 他们否认SQL兼容平台的现实，助长"SQL&Quot；这不符合，甚至不是一种语言；

  • 它们抑制IDEF1X，反而助长ERD，ERD对于建模无望，不能处理关系键(组合)，也不能用于任何类型的建模

  • 他们不同意Codd和像我这样的实践者，因为我们不是学者，我们是现实主义者

  • 他们压制逻辑关系模型，并推广1960年代(DBMS之前)的物理记录归档系统，错误地将其营销为"关系"。但这些系统的特点是RecordIDs(物理记录，而不是逻辑行)。‘

    • 请注意，这类RFS是原始的，非常有限，只是为了便于访问(DML)和方便(备份；等等)而放在SQL容器中。*这样的限制被错误地归结为SQL，但实际上是因为原语RFS。
    • RecordIDs请不要提供RM中要求的行唯一性，以防止重复数据。)(它们确实提供了RecordID唯一性，这是非常不相关的，更糟糕的是，当您没有提供行唯一性时，您可能会认为已经阻止了数据重复
    • 此外，RecordIDs始终是一个额外的非数据字段，并且比关系等效项多一个额外的索引。
    • 并且由于未通过RM中的访问路径独立规则而强制更多JOINs。

  • 详见：
    Creating a Relational table with 2 different auto_increment，仅§1&；2。

这样他们就会因为不了解RM而做出不合理的断言，比如"TheRM不能做这个做那个"，这对他们的"RM"是正确的，但是对于Codd的RM是非常错误的。

1.4%SQL与SQL"；

同样，Codd定义了单一的数据子语言，主要供应商(不包括Oracle)都实现了它。"这就是真正的SQL，它被制定为ANSI-&>ISO/IEC标准。"有一篇著名的论文Codd‘s十二条规则是关于遵守他的数据子语言的，主要供应商都遵守，免费软件甚至都没有实现。

免费软件和Oracle不符合SQL，它们使用术语SQL是不合理的。"Postgres和Oracle中的实现甚至不是一种语言。

因此，再一次由于不了解RM和SQL；他们与世隔绝；固守自己的私有"RM"和"SQL"，所以他们的"SQL"和"RM"是真的，SQL不能做这个或那个，而真的RM和SQL是歇斯底里的假。

这导致世界上95%的数据库被贴上了"关系型"的标签，但它们根本不是关系型的，它们没有提供关系模型的任何功能和好处。"当然，它不能按预期工作。"因此，从关系型(实际上是"关系型")转向各种非关系型的"数据库"。"

挡路最新的孩子是"图形数据库"，它根本不是数据库(没有完整性，没有标准)，但提供了一个"关系"或"sql"理应无法提供的特性或功能。同时，在现实中，在codd的关系模型和正版sql中，没有什么是不能定义的，数据层次结构(DAG；图；树)设计和实现起来也是毫不费力、直截了当的。‘

值得注意的是，IBM专门委托Codd解决的一个问题是他们的HDBMS中与著名的物料清单问题有关的一个具体问题，他确实出色地解决了这个问题。即RM完全支持各种数据层次结构，并且可以使用普通的[正版]SQL来导航。

1.5名开发人员作为建模者

有三个典型问题。

首先，理解上面的上下文，这样您就会意识到您已经被不能处理各种逻辑数据结构的反关系废话轰炸了(例如，图)作为"关系"，并且关系型和SQL可以很好地处理所有这些结构。

  • 因此，我将用关系型术语为您的问题提供相当简单的解决方案，并且通过正版SQL很容易使用。"您需要了解，认为图形数据库可以做RM不能做的任何事情，或者认为它在任何方面都更优越的想法是错误的。
第二个问题是共同的开发人员心态，他们关注他们的GUI、皮肤以及他们对数据的需求。(我知道我需要什么，以及GUI是什么样子)，这很容易，因为学者们建议他们按照Excel电子表格(可怕的RecordIDs)的方式思考。而不是准确地说数据是什么。

  • 这削弱了建模工作。真正的数据建模(关系或非关系)是一门科学，人们必须对数据建模，而只对数据建模，而不考虑使用情况(用例)。
  • 虽然每个版本的使用率都会发生变化，并且在计划外使用时会有很大变化，但它增加了
  • 而数据结构不会更改(如果建模正确，则反映了从中提取数据的真实世界)。

第三，可能也是最重要的一点是，分析和建模数据的科学和方法与分析、设计和建模过程的科学和方法非常不同。不幸的是，如今的开发人员被OO/ORM迷住了，因为他们完全错误地认为宇宙中的一切都可以通过对象的镜头来感知和理解。

  • 他们把"数据库"当成存储子，唯一的目的就是为他们的神奇对象提供持久化，更别提重构和CRUD了。
  • 数据库逻辑上在APP内，只能通过APP访问，Open Architecture的持久化、开放访问等大好处丢失了，未知。

2解决方案·关系模型

2.1问题

既然我们有了上面的上下文和解释，我们就可以考虑您提供的图表了。"请注意，这是一张图片，而不是任何类型的模型，它集中描述了一些示例数据，以及这些示例数据之间可能存在的一些关系。"

也是一张好看的图表。

  • 但它只是详细的输出(用例)，以图形的形式呈现。但它不是图形(DAG；Tree)。如果由于视觉原因，人们获得了它包含循环引用(数据实际上不包含)的概念，这是可以原谅的。再说一次，过于关注用例，而牺牲了对数据的理解和建模(并以关系的方式对其建模，而不是作为20世纪60年代的记录归档系统)。

如果要在关系数据库中对此建模，架构可能是什么样子？

因此，我要求您释放所有概念Re：

  • 物理RecordIDs(注意反关系思想错误地伪装成"关系")，
  • 用例思维(您需要什么，而不是数据独立于您需要什么)，
  • 图形和图形"数据库"，包括术语，特别是几个数据样本的优秀图表(数据的图形报告)
  • 您可能有的任何OO/ORM思维方式 这样您就可以亲切地理解普通的关系术语和概念。正如另行说明的那样，任何附加到上面的内容都将使数据模型变得愚蠢，从而使数据库变得迟钝。

这是纯关系型的。*它可以在任何正版SQL平台(不包括免费软件平台和Oracle)中实现，并且可以毫不费力地工作。*任何和所有报告都将通过单个SELECT提供。*请按照您的问题顺序进行操作。

如果要在关系数据库中对此进行建模，模式可能是什么样子？我的想法是打破每一个关系和节点，大概是这样的：

是的。忽略小错误，这就是正常化的样子。

我们可以删除以图形为中心的名称，因为数据库旨在反映现实，而不是许多可能的用途之一只是从它生成图形这一事实。此外，它可以用于提供来自数据的任何报告，而不仅仅是图形。

2.2使用关系数据模型·初始

IDEF1X中给出的关系数据建模的第一次迭代。

或者，所有节点都应该是单个表吗？

否。这将是一个完全非规范化的平面文件。它是一个需要实现；维护；和SELECT的庞然大物。它不会有声明引用完整性，因此它不符合数据库的资格，更不用说关系数据库了。

如果我们要将电影添加为另一个节点，我们将如何显示审阅边可能来自人员图书或人员电影。

忘掉"；edge"；，它只是众多可能的显示类型中的一种，将重点放在支持任何类型的显示的数据和关系上。

每个箭头(Person; Book; Movie)都是一个独立的离散事实("；node"；)，每个箭头都是一个独立的离散关系，具有清晰的VerbPhrase。

您添加了需要大量额外建模的Movie实体。但是用于定义Book或Movie的Item的普通Pre-Relational(60年代和70年代)和Relational(80年代)方法是子类型群集。

似乎更一般的方法可能是：.

您的属性不完整。*当您添加相关属性时，最终会得到两个未规范化的文件，其中包含可以为空的字段。与数据库截然相反，维护和使用通常是一场噩梦。*

从物种移到属不是非黑即白的决定，认为它总是好的是一个严重的错误。根据关系模型，特别是正确的子类型，同时实现了属(Basetype)和种(子类型)，因此提供了无限的使用。

改用后一种方法有什么缺点吗？

是的。*违背科学或涵盖某一主题的标准总是有可怕的缺点。我想列举几个：

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

2.3使用关系数据模型·进展

试试看，这是我们建模练习的第二次迭代。我已经实现了以下规则(请随意更改或添加更多规则，我会更新数据模型)：

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

  • PDF
    • 中的数据模型

这篇关于图书图表的关系模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆