“写入”的基数是多少？关系类型？
writes 关系类型的基数是多少？
a) 一对多
b) 多对多
c) 一对一
d) 没有其他选项
这个问题让我很困惑。这就是问题中给出的所有上下文。
我觉得可以是一对多，比如1个人可以写多封信。但也可以是多对多，比如，一个人写了很多本书。而且一本书也是很多人写的。也可以是一对一的。
那么，既然每个作者不必写多于一本书，那么是否就没有其他选择呢？或者应该是所有选项？ 我认为 d) 是正确答案吗？
What is the cardinality of the writes relationship type?
a) One-to-many
b) Many-to-many
c) One-to-one
d) None of the other options
This question confuses me a lot. This is all the context that is given in the question.
I think it can be One-to-many, for example, 1 person can write more than one letter. But it can be Many-to-many, for example, A person writes many books. And one book is also written by many people. It can also be One-to-one.
So would it be none of the other options since it is not necessary that every author has written more than one book? Or should it be all of the options?
Am I correct in thinking d) is the correct answer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能会对集合论中的基数指的是集合的一个实例中的元素数量这一事实感到困惑，正如您在示例中指出的那样，有不同的可能情况。
实体关系建模中的术语基数是指实体集两侧可能的边界。 （这就是为什么 UML 术语避免使用“基数”术语并使用多重性）。
因此，在您的 E/R 模型中，关系的类型取决于双方可能的最大“基数”。考虑到：
因此答案是b。如果您的模型或数据库关系可以表示多对多，则它包括所有其他可能性。如果您选择其他选项，则只能处理可能情况的子集，因为您无法处理多对多。
You may be confused by the fact that the cardinality in the set theory refers to the number of elements in one instance of the set, and as you pointed out in your examples, there are different possible cases.
The term cardinality in Entity-Relationship modeling refers to the possible boundaries of the entity sets on each side. (This is why the UML terminology avoids the “cardinality” term and uses multiplicity).
So in your E/R model, the kind of relationship depends on the maximal “cardinality” that is possible on both sides. Considering:
The answer would therefore be b. If your model lr your database relation can represent many-to-many, it includes all the other possibilities. If you’d chose another option, you could only deal with a subset of the possible cases because you’d not be able to deal with many to many.