数据库设计：X:X to 1:many vs X:X to 0:many答案

【问题标题】：database design: X:X to 1:many vs X:X to 0:many数据库设计：X:X to 1:many vs X:X to 0:many
【发布时间】：2021-07-21 01:35:36
【问题描述】：

（编辑于 1/5 10:22hr。添加了一些关于我的符号的解释。并添加了一些我收到的额外信息）

我正在上一门数据库设计课程，目前我们正在 MySQL 工作台中进行 ERD 和设计数据库。考虑第一个、第二个和第三个 NF，创建模式、表、约束等。大部分我都很清楚。

但是有一个方面尚不清楚：X:X 到 1:many 关系与 X:X 到 0:many > 关系（意思是：无论到 0:many，还是到 1:many，等等）。在某些情况下很明显，在其他情况下则不是那么明显。每当我不清楚时，它大多是这样的：

示例： 一位艺术家有 1 到多幅画作。一幅画有 1 位艺术家，而且只有 1 位艺术家。

关系：

|艺术家| 1:1 -------- 1:many |绘画|

在另一个符号中相同 |艺术家| ||------------ 1

这看起来很公平，但是....然后有一个想法：我可以成为一个新艺术家，还没有画出一幅画。或者：我可能正在将一位新艺术家输入到艺术家表中，但尚未输入他的画作（这可能会导致实际问题）。

另一个例子： 一个研讨会有 1 到多个参与者。参与者进入 0 对多研讨会。

关系：

|车间| many:0 ------- 1:many |参与者|

好的。但是：一个研讨会可能有 0 名参与者（没有人想参加，可能会导致取消）。或者：我可能正在进入一个新的研讨会到一个表中，还没有添加任何参与者。

另一个例子： 活动仅在 1 个地点举行。一个位置有 1 到多个事件。

关系：|事件|多:1 -------- 1:1 |位置|

但是，也许您正在进入一个新的（未来）地点，但那里还没有活动。

长短短：在上述情况下，我很难确定最小基数。

另外，当我设计一个数据库并让 Workbench 对用于创建表的 SQL 进行正向工程时（基于我的 ERD），X 与 1/many 之间似乎没有任何区别与 X 到 0/许多变体相比。这让我想知道：做一个或另一个的实际（实际）效果或含义是什么？也许这些影响（在未来的道路上）会让选择变得更容易？

谁能用一种简单（万无一失）的方式解释这个问题？

期待理解！

加法 1/5：

我已经和老师讨论过我的问题/问题。他同意我的观点，即某些最小基数可能会导致僵局：一个表不能在另一个表中没有出现的情况下插入，反之亦然。
他向我解释说，ERD 图是一个逻辑模型，而不是一个物理模型。换句话说，ERD 的最小基数对于技术实现来说并不是必需的。

好吧，如果是这样的话，我理解他的意思。通常一个艺术家至少有一幅画。研讨会通常至少有一名参与者。一个位置通常至少有一个事件。所以在逻辑层面上，这似乎很好。

在技术/实施层面，这是另一回事。您应该能够输入艺术家、工作室或地点，而不会在另一个表中出现事件。

我现在的问题是：

这是真的吗？ ERD 是逻辑模型，而不是技术模型？
如果是这样，添加最小基数的原因是什么？好像没什么用。

【问题讨论】：

关系中的许多可以为 0。在 mysql 中，您不能通过 FK（代表关系）强制父立即具有至少 1 个子 - 这只能通过应用程序逻辑来完成。从实际的 RDBM 的角度来看，要求父母立即生孩子是一个先有鸡还是先有蛋的问题（您需要先创建父记录，以便知道您在子记录中设置的 PK）。这通常用于处理应用程序逻辑和事务。
艺术家不一定有画。这些画可能没有记录在数据库中，或者他们可能从来没有画过任何东西，只有照片或舞蹈套路。
我能想到的强制至少 1 个关系的最简单方法是建立 primary 关系。获取一个包含person、address 的数据库和一个链接这两个person_address 的表。 person 或 address 都不是指另一个，只有链接表可以这样做。因此，您有一个 0-many : 0-many 关系。但是，如果您将primary_address_id 列添加到person 表中，您可以强制在首先创建其主要地址之前不能创建一个人并且该人是使用该地址创建的，从而强制执行最小值一。这很不寻常。
见：damirsystems.com/sql-x-to-y
那么，如果我理解正确的话，没有办法强制在 FK 关系中至少出现 1 次？

标签： mysql sql database-design schema mysql-workbench

【解决方案1】：

让我们继续你的艺术家::绘画关系，我认为这是最清楚的。当我们说 1 比多时，我们通常指的是 0/1 到 0/多，但并非所有 4 种排列都有效或有意义。

“我不能有没有画的艺术家”听起来如何？这就是零到零的排列。听上去没有错，但这是一个退化的案例，对我们没有用处。
1 位艺术家比 0 幅画是可以的，正如 matbailie 所描述的，并且没有问题。
一位艺术家画多幅画是可以的，并且是主要用例。
0 艺术家对许多画作不正确，不应在模型中支持。一幅画必须有一个艺术家。

因为案例 1 和 4 不起作用，所以说 0/1 到 0/many 是不正确的。将基数描述为 1 到 0/many 更正确，这包括上面的情况 2 和 3。

你可能会说，'但在某些情况下，我们不认识艺术家，所以我们应该留下机会，让没有艺术家的画作。这句话让我觉得你正在离开 ERD 领域并进入物理设计。从设计的角度来看，您可以轻松地说有一位我们只是不知道是谁的艺术家，所以让我们创建一个 UNKNOWN ARTIST 记录并将这些画与它联系起来。

您的第二个示例（workshops::participants）看起来更像是 0/many 到 0/many。如果您运行相同的 4 个排列，它们看起来都是可信的，尽管 0 到 0 的情况似乎仍然有点可笑。

您的最后一个示例是另一个 1 比 0/多，因为无法举办没有地点的活动。当你到达物理层面时，你可以谈论处理虚拟事件的最佳方式。

因此，您的示例似乎都没有显示真正的零对多（更准确地说是 0/1 到 0/many）。我认为它们非常罕见，如果它们存在的话。它必须与某种可选活动相关联，如果您确实注册了它，就会有一组有限的选择。

【讨论】：

这是一个很好而清晰的解释。我遵循你的推理。
这是一个很好而清晰的解释。我遵循您的推理，并且感觉您实际上经常说 1 到 0/many 就是这种情况。我之所以在这里提出它，是因为在我的课程中，许多练习解决方案都显示了 1 对 1/多的关系，我觉得 1 对 0/多的关系更现实。唯一值得怀疑的是：当您设计一个 to-1/many 与 to-0/many 时，MySQL Workbench “做什么”。我不禁想知道它什么都没有改变（在引擎盖下）.....
一旦你得到一个物理实现，我不相信有任何方法可以实例化一个真正的一对一/多约束关系。想想看，你已经有了一个约束，不允许没有艺术家的绘画，现在你想禁止没有绘画的艺术家——无论我选择先添加哪个记录，我都在短暂地违反了一个约束。也许如果您有一个允许将约束检查推迟到提交的数据库，但是您必须在程序控制下添加所有内容，并且出于同样的原因删除将是fubar。我的建议：将其编码到应用程序中！

【解决方案2】：

但是...参与者可以参加 0-N 研讨会。所以这需要是多对多的。

一般来说，“零”是“1”或“N”的退化情况；很少值得担心。

我喜欢从识别模型中的“实体”开始。您的参与者、工作坊、绘画、活动、艺术家、地点就是很好的例子。然后我寻找明显配对之间的“关系”。

我说只有 3 个案例。而且我想记住，这两个“实体”表现为两个“数据库表”：

1:1 -- 此时我问为什么两个实体（数据库表）没有合并在一起。这两个表共享相同的唯一键。
1:many -- 由“1”的 id 表示为“many”表中的一列。
Many:many -- 这需要两个表之间的链接表。此链接表有两个 id。

“Id”表示表的唯一键。它通常是一个数字，但这不是必需的。

对于“0”...

1:0 或 many:0 -- 当“0”侧的条目缺失时，您可能需要LEFT JOIN 来提供NULLs
Many:many -- 如果任一 id 不存在（零情况），则该关系没有行。

然后定义INDEXes 以实现高效访问。并且，可选地，FOREIGN KEYs 以确保完整性。表示两个实体如何相关的索引是 FK 的主要候选者。应添加其他INDEXes 以优化SQL 查询中的WHERE 子句。

在所有情况下，id/FK/index 都可以是“复合的”——这意味着它是用于单个 id/FK/index 的两个或多个列。

【讨论】：

感谢您的贡献。并不是我不了解其中的关系或技术实现，而是我练习的“解决方案”经常显示（例如）1/1 到 1/many 的关系，我在想：这可以/ 应该是 1/1 到 0/many 的关系。所以它是关于 0 与 1 的最小基数。从这里的答案中，我收集到我正在做很多事情。它通常不是 0，但实际上它甚至无关紧要。我知道这更有可能通过应用程序逻辑来解决，而不是技术数据库实现。