问题标签 [relational-model]

我试图理解 Edgar Codd 在 1970 年最初定义的关系模型规则。

具体来说，我对参照完整性是否是他的关系模型的一部分感兴趣。我将尝试在以下示例中进行演示（只是为了使这个问题变得漂亮）：

顾客

发票

现在，显然如您所见，我们有一张客户（外键）为Mary的发票。这会违反他的关系模型吗？Edgar Codd 会不会看着这个说，哎呀，这到底是怎么回事？或者他会说，这完全没问题……

这是理论上的问题。

一段时间以来，我一直推迟开发我的应用程序的这一部分，纯粹是因为我想以一种循环的方式来做这件事，但是从我记得我的讲师在学校告诉我的事情中感觉这是一个坏主意。

我有一个订单系统的设计，忽略了与这个示例无关的所有内容：

• 信用卡
• 顾客
• 命令

我想要这样，

• 客户可以有信用卡（0-n）
• 客户有订单（1-n）
• 订单有一位客户(1-1)
• 订单有一张信用卡(1-1)
• 信用卡可以有一个客户（1-1）（唯一的 id，所以我们可以忽略 cc 号码的唯一性，丈夫/妻子可以共享 cc 实例等）

基本上最后一部分是问题出现的地方，有时信用卡被拒绝并且他们希望使用不同的信用卡，这需要更新他们的“当前”卡，但这只能更改用于该订单的当前卡，而不是客户可能在磁盘上的其他订单。

这有效地在三个表之间创建了一个圆形设计。

可能的解决方案：要么

创建圆形设计，提供参考：

• cc 参考订购，
• 客户参考抄送
• 客户参考订购

或者

• 客户参考抄送
• 客户参考订购
• 创建引用所有三个表 id 的新表并在订单上放置唯一的，以便在任何时候只有一个 cc 可能是该订单的最新

本质上，两者都对相同的设计进行建模，但翻译方式不同，此时我最喜欢后一种选择，因为它看起来不那么圆，更中心化。（如果这有道理的话）

我的问题是，

• 如果有的话，每个人的优点和缺点是什么？
• 循环关系/依赖的陷阱是什么？
• 这是该规则的有效例外吗？
• 有什么理由我应该选择前者而不是后者？

谢谢，让我知道您是否需要澄清/解释任何事情。

--更新/编辑--

我注意到我所说的要求中有一个错误。在尝试为 SO 简化事情时基本上丢球了。Payments 那里还有另一个表，它增加了另一个层。问题是，订单可以进行多次付款，并且可以使用不同的信用卡。（如果您真的想知道其他付款方式）。

在这里说明这一点是因为我认为根本问题仍然是相同的，而这只确实增加了另一层复杂性。

我正在阅读 CJ Date 的SQL and Relational Theory: How to Write Accurate SQL Code，他认为位置查询是不好的——例如，这个INSERT：

相反，您应该使用这样的基于属性的查询：

现在，我了解到第一个查询与关系模型不符，因为元组（行）是无序的属性集（列）。我无法理解第一个查询中的危害在哪里。谁可以给我解释一下这个？

是否有将 SQL 子查询转换为连接的通用过程或算法，反之亦然？也就是说，是否有一组印刷操作可以应用于包含子查询的语法正确的 SQL 查询语句，该子查询会导致没有子查询的功能等效语句？如果是这样，它们是什么（即，算法是什么），在什么情况下它们不适用？

超级键可以包含不属于主键的内容吗？

我正在寻找助记符来帮助我处理数据库、关系模型和事务理论。例如，我学习了“ACID”来帮助我记住事务的属性：原子性、一致性、隔离性和持久性。还有什么其他人？

在描述我的问题之前，我想先解决一些问题：

1. 我是一位经验丰富（虽然不是专家）的数据库设计师。我相信我对关系模型有很好的掌握。
2. 我对关系模型的理解不够深入，以至于我确切地知道在每种情况下该做什么。我还在学习。

假设我们每月从一家银行获得一次 Excel 电子表格，但并不总是同一家银行。该电子表格只有六列：银行名称、帐号、账户余额、客户（账户持有人）姓名、客户 SSN 和账户持有人地址。每一行都有一个不同的帐号，并且没有帐号被列在多于一行中。我们希望将此电子表格导入数据库，并在未来的任何时候说：“John Smith 2010 年 10 月 13 日的地址是什么？”

为简单起见，假设每个客户只有一个地址，每个客户可以有零个或多个帐户。稍等片刻，让我们假设我们只需要导入一个 Excel 工作表，这是一个愚蠢的前提，但请耐心等待。如果是这样的话，下面的设计就足够了：

我的其余问题基于您同意该架构是“正确”的前提，因此希望您对此感到满意。

现在，如果我们只进行一次导入就可以了，但我们每个银行每年将进行 12 次导入。以下是我考虑的原因：

现在每个帐户都与导入相关联，我们可以肯定地说“帐户 12345 来自 2010 年 10 月 13 日的导入 572”。customer当您查看例如表格时，它可能会变得更加模棱两可。由于表中的行数少于customer表中的行数account（因为某些客户有多个帐户），因此我们不会像帐户和导入那样在客户和导入之间建立一对一的关系。我知道没有数据丢失，也没有数据完整性的损失，但它仍然感觉像是某种牺牲。

我的问题是（这可能过于开放）：您认为这是存储数据的好方法吗？你会做不同的事吗？

编辑：有一种重要的方式来思考这些你必须注意的实体。不要认为account随着时间的推移而存在的单一帐户。将 aaccount视为某个时间点的帐户快照。因此，余额为 100 美元的account账户 12345 与余额为 150 美元的账户 12345 不同。是的，这两条记录都与现实世界中的同一个银行账户相关联，但我存储的是某个时间点的账户快照。与客户类似（但不相同）的情况。

在我 7 年的开发经验中，我见过的每个数据库中的几乎每个表都有一个自动递增的主键。为什么是这样？如果我有一个美国州表，其中每个州必须有一个唯一的名称，那么自动递增主键有什么用？为什么不直接使用州名作为主键呢？在我看来，这似乎是允许重复伪装成唯一行的借口。

这对我来说似乎很明显，但话又说回来，似乎没有其他人会得出和我一样的逻辑结论，所以我必须假设我很有可能是错的。

我们需要使用自动递增键是否有任何真实、实际的原因？

我们有三个实体，分别称为Product、ProductType和ProductCategory。

假设我们有三种ProductType：Book、Music和Video。

我们有三个不同ProductCategory的Book: Fiction, Novel, Technical。

三个不同ProductCategory的Music: Rock, Jazz, Pop。

我们有三个不同ProductCategory的Video: Fiction, Comic, Drama。

AProduct有 aProductType并且可以有许多ProductCategory's。但它ProductCategory的应该匹配它的ProductType。例如，如果ProductTypeis Book，则只能取Fiction,Novel和Technicalas ProductCategory。

是否可以在不使用应用程序代码或触发器等的情况下使用此限制（即ProductCategoryaProduct应该与其匹配ProductType）对这个模式进行建模——只使用表、外键等。

你会如何建模？

这个问题需要一些假设的背景。让我们考虑一个employee具有列name, date_of_birth, title,的表salary，使用 MySQL 作为 RDBMS。因为如果任何给定的人与另一个人有相同的名字和出生日期，根据定义，他们就是同一个人（除非有两个人名叫亚伯拉罕林肯的惊人巧合出生于 1809 年 2 月 12 日），我们将放置一个唯一键打开name，date_of_birth这意味着“不要将同一个人存储两次。” 现在考虑这些数据：

如果我现在尝试运行以下语句，它应该并且将会失败：

如果我尝试这个，它将成功：

现在我的数据将如下所示：

这不是我想要的，但我不能说我完全不同意发生的事情。如果我们用数学集合来讨论，

我的猜测是 MySQL 说，“因为我不知道有NULL出生日期的 Jim Johnson 不在此表中，所以我将添加他。”

我的问题是：即使date_of_birth并不总是知道，我如何才能防止重复？到目前为止，我想出的最好的办法是搬到date_of_birth另一张桌子上。然而，这样做的问题是，我最终可能会得到两个名字、头衔和薪水相同、出生日期不同的收银员，并且无法在没有重复的情况下存储它们。