我制作了下面的图表,以显示与其有关系的“工作簿”和“人员”:
有两个节点:
- 人员
- 图书
和三个关系(及其属性,未在图中显示):
- 读取(日期,num_stars)
- 编写日期
- 已检阅(日期,数字_星,文字_检阅)
如果要在关系数据库中建模,模式会是什么样子?我的想法是将每个关系和节点分解出来,类似于:
节点人员
- 人员ID
- 名称名称名称
节点簿 - 图书ID
- 职务名称
边缘读取 - 发件人个人ID
- 目标书ID
- 日期
- 星星数
边缘写入 - 发件人个人ID
- 目标书ID
- 日期
边缘已审阅 - 发件人个人ID
- 目标书ID
- 日期
- 星星数
- 文本_审阅
或者,所有节点都应该是一个表吗?如果我们要添加Movies作为另一个节点,我们如何显示Review边可以从Person-〉Book或Person-〉Movie。似乎更通用的方法可能是:
节点:
- 识别码
- 型号
- //来自特定边缘表的FK
边缘: - 发件人ID
- 目的ID
- 型号
- //来自特定边缘表的FK
使用后一种方法有什么缺点吗?
1条答案
按热度按时间3htmauhk1#
1上下文
注意
relational-database
标记。首先,我们需要了解这个问题存在的整个背景,其中包括各种可用的方法;各自的能力;以及限制(如果有的话)。之后,就很容易理解解决方案了。而且在关系范式中只有一个 * 正确 * 的解决方案。
1.1关系前
在Codd于1970年提出他的 Relational Model(关系模型)之前的20年里,已经有了非常好的DBMS。此外,供应商花了10多年的时间才生产出真正的RDBMS(1981)。在那个时代,计算机和软件都很昂贵,而且都是专有的。
这导致了维护方面的麻烦,并且导出/导入需要一个程序
虽然钥匙是逻辑的,但指针当然是物理的。系统正是因为这一点而受到限制。
对于科学的爱(逻辑;换句话说,只有真正的层次结构(有向无环图; Trees),正如它们存在于真实的世界中或合乎逻辑地存在于人造世界中一样,被实现了。
1.2关系模型
第一个基于或建立在逻辑学基础上的模型,有了数学定义,这就给了它被称为Model的许可。它改变了DBMS世界。与这个问题相关的主要区别是:
这消除了维护方面的麻烦,并提供了毫不费力的导入/导出
1.3反关系
E F Codd博士是一名工程师,他和科学家沿着为IBM工作。同样,其他DBMS供应商也有科学家和工程师。
学术界不喜欢Codd和IDEF1X的工作,因为他们完全与行业和DBMS供应商隔离,他们使用和写的东西都是学术界炮制的,从那时到现在:
RecordIDs
(物理记录,而不是逻辑行)。RecordIDs
不提供行唯一性,这是 RM 中为防止重复数据而要求的。(它们确实提供了RecordID
唯一性,但这是完全不相关的,更糟糕的是,您可能认为您已经防止了数据重复,而实际上并没有RecordIDs
始终是一个附加的非数据字段,并且比关系等价物多一个附加索引。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很好地处理了所有这些结构。
第二个问题是常见的开发人员心态,他们关注他们的GUI;皮肤,以及他们对数据的需求。(* 我知道我需要什么,以及GUI看起来像什么 *)这很容易,因为学者们建议他们从Excel电子表格的Angular 来思考(可怕的
RecordIDs
)。而不是确切地说,数据是什么。第三,也许是最重要的,是分析和模拟数据的科学和方法与分析的科学和方法大不相同;设计;和建模过程。不幸的是,这些天的开发人员被OO/ORM迷住了,由于完全错误的概念,即宇宙中的一切都可以通过对象的透镜来感知和理解。
2解决方案·关系模型
2.1问题
现在我们有了上面的背景和解释,我们可以考虑你提供的图表。注意,它是一张图片,而不是任何类型的模型,它集中在,它描绘,一些例子数据,以及一些例子数据之间可能的关系。一个好看的图表。
如果在关系数据库中对此进行建模,那么模式会是什么样子的呢?
因此,我要求你释放所有关于以下内容的概念:
RecordIDs
(注意反关系的思想被错误地称为“关系”),这是纯关系型的。它可以在任何真正的SQL平台(不包括免费软件平台和Oracle)上实现,并且可以毫不费力地工作。任何和所有的报告都将通过一个
SELECT
提供。顺序按照您的问题。如果要在关系数据库中建模,模式会是什么样子?我的想法是将每个关系和节点分解出来,类似于:
是的。忽略小错误,这就是标准化的样子。
我们可以删除以图形为中心的名称,因为数据库的目的是反映现实,而不是从数据库中生成图形,它可以从数据中提供任何报告,而不仅仅是一个图形。
2.2关系数据模型·初始化
关系数据建模的第一次迭代,在IDEF 1X中给出。
或者,所有节点都应该是一个表吗?
不。那将是一个平面文件,完全不规范。一个怪物实现; maintain;和
SELECT
from。它将没有声明引用完整性,因此它不符合数据库的条件,更不用说关系数据库了。如果我们要添加电影作为另一个节点,我们将如何显示审查边缘可以从一个人-〉图书或一个人-〉电影。
每一个(
Person; Book; Movie
)都是一个单独的、离散的事实(“节点”),每一个箭头都是一个单独的、离散的关系,带有一个清晰的动词短语。您添加了Movie实体,它需要大量的附加建模。用于定义
Item
(Book
或Movie
)的普通关系前(60和70年代)和关系(80年代)方法是子类型群集。Structuring database relationships for tracking different variations of app settings,以及
How do I get around this relational database design smell?
看起来更通用的方法可能是:...
您的属性不完整。当您添加相关属性时,您将得到两个未规范化的文件,其中包含可为空的字段。这与数据库截然相反,通常是维护和使用的噩梦。
从种到属并不是一个非黑即白色的决定,认为它“总是好的”是一个严重的错误。* 关系模型 *,特别是正确的子类型,实现了属(基本类型)和种(子类型),因此提供了无限的使用。
使用后一种方法有什么缺点吗?
是的。违背科学或某个主题的标准总是有可怕的缺点。举几个例子:
FOREIGN KEY
)是不可能的,因此数据没有完整性2.3关系数据模型·渐进式
试试这个,这是我们建模练习的第二次迭代。我已经实现了以下规则(可以随意更改它们或添加更多规则,我将更新数据模型):
Item
是Book
或Movie
,或者两者都是%Reviewer
必须首先是Reader/Viewer
( BookTitle, Sequence ) TINYINT
唯一,即对于给定的BookTitle
,防止两个Authors
具有相同的Sequence
CONSTRAINT
以确保增量Sequence
,在这种情况下,可以删除AK