（编辑时间：28/4 00:30）
我正在做一个数据库设计的课程，目前我们正在做erd的和mysql worksbench数据库的设计。想想第1、第2和第3个nf，创建模式、表、约束等等。大部分对我来说都很清楚。
但是有一个方面还不清楚：x对一/多关系与x对零/多关系。在某些情况下，这是显而易见的，在另一些情况下则不那么明显。每当我不清楚的时候，主要是这样的：
一个艺术家有一到多幅画。一幅画只有一个艺术家。
关系：艺术家11------1<绘画。
这似乎是公平的，但是……然后有一个想法：我可以成为一个新的艺术家，还没有创作出一幅画。或者：我可能正在将一位新艺术家输入一张艺术家表格，但还没有输入他的画（这可能会导致一个实际问题）。
另一个例子：一个研讨会有1到多个参与者。参与者参加0到多个研讨会。
关系：研讨会>0-----1<参与者。
可以。但是：一个研讨会可以有0个参与者（没有人愿意参与，可能会导致取消）。或者：我可能正在把一个新的研讨会放到一张table上，还没有添加任何参与者。
另一个例子：一个活动只在一个地点举行。一个地点有1到多个事件。
关系：事件>1-----11位置。
然而，也许你正在进入一个新的（未来的）地点，那里还没有发生任何事件。
long-shorty-short：在上述情况下，我很难确定最小基数。
另外，当我设计一个db和get workbench来正向工程sql来创建表（基于我的erd）时，x-to-1/many和x-to-0/many变量之间似乎没有任何区别。这让我想知道：做这件事或那件事的实际（实际）效果或暗示是什么？也许这意味着（更进一步）更容易做出选择？
有人能用一种简单（万无一失）的方式解释这件事吗？
期待理解！
2条答案
按热度按时间0mkxixxg1#
让我们继续你和艺术家的关系，我认为这是最清楚的。当我们说1到many时，我们通常指0/1到0/many，但并非所有4个排列都有效或有意义。
“没有画就没有艺术家”听起来怎么样？这就是零对零排列。这听起来没有错，但这是一个退化的情况，是没有用的我们。
1个艺术家到0个画是可以的，正如马特贝利所描述的，并且没有问题。
1艺术家对很多画都是可以的，而且是主要的用例。
0美术师对许多画作只是不正确，不应在模型中支持。一幅画必须有一位艺术家。
因为案例1和案例4不起作用，所以说0/1到0/many是不正确的。将基数描述为1到0/多更为正确，这包含了上述情况2和3。
你可能会说，‘但有些情况下，我们不认识艺术家，所以我们应该留下一个机会，让没有艺术家的画。’。这句话让我觉得你离开了erd的领域，进入了物理设计。从设计的Angular 来说，你可以很容易地说，有一个艺术家，我们只是不知道谁，所以让我们创建一个未知的艺术家记录，并连接到这些画。
您的第二个示例（workshops：：participants）看起来更像0/多对0/多。如果你经历同样的4种排列，它们看起来都是可信的，尽管0比0的情况看起来还是有点可笑。
最后一个示例是另一个1到0/多，因为没有位置的事件无法举行。当你到达物理层时，你可以谈论处理虚拟事件的最佳方法。
因此，您的示例中似乎没有一个显示真正的0到多（更准确地说是0/1到0/many）。我认为它们很稀有，如果它们真的存在的话。它必须与某种可选活动相关联，如果你真的加入了它，就有一组有限的选择。
p3rjfoxz2#
但是。。。参与者可以参加0-n研讨会。所以这需要多对多。
一般来说，“零”是“1”或“n”的退化情况；很少值得担心。
我喜欢从识别模型中的“实体”开始。您的参与者、工作坊、绘画、活动、艺术家、地点都是此类活动的极好例子。然后我寻找明显的对之间的“关系”。
我说只有3个病例。我想记住，这两个“实体”表现为两个“数据库表”：
1:1——这时我会问为什么这两个实体（数据库表）没有合并在一起。这两个表共享相同的唯一键。
1:many——由“1”的id表示为“many”表中的一列。
many:many -- 这需要两个表之间的链接表。此链接表有两个ID。
“id”表示表的唯一键。它通常是一个数字，但这不是一个要求。
对于“0”。。。
1:0或many:0 -- 你可能需要一个
LEFT JOIN提供NULLs当“0”侧的条目丢失时many:many -- 如果任何一个id都不存在（零的情况），那么该关系就没有行。
然后是定义
INDEXes有效访问。而且，也可以选择，FOREIGN KEYs为了正直。表示两个实体如何关联的索引是fks的主要候选索引。其他INDEXes应添加以优化WHEREsql查询中的子句。在所有情况下，id/fk/索引都可以是“复合”的——这意味着它是两个或更多列，用于单个id/fk/索引。