如何在EF中模拟2的多重性

Question

我有两种情况需要这样的事情。在我的模型中，我有一个Message，其中包含一个或两个Persons。此外，该消息与两个Addresses相关联，即从Address和到Address。

在第一种情况下，使用两个Persons，我想指定Message和Person多重性1 --- 1..2之间的关联，或者指定两个关联，一个1 --- 1，另一个1 --- 0..1。但是，我不能（或不知道如何）将多重性设置为两个。我可以想象，有可能将约束设置为1 - *，约束设置为最大值2（但我不知道该怎么做）。
通过添加这两个关联，当我查看Message侧时，我觉得有点奇怪，因为两个关联都有1，表示Person应该有两个与它相关的Messages。我可能想要Message侧的0..1这样的东西，对于它们或它们的xor约束的两个关联，但我不知道这是好的做法，甚至可能在EF中。

对于第二种情况，问题非常相似，只是始终有Address且始终为Address。设置多重性1 - *对我来说似乎不对。在这里，我想象肯定会有两个关联，一个来自和一个到一个关联（碰巧都发生在Address实体上）。然而，这导致Message侧有两个1或两个0..1的相同问题。

所以我的问题是，如何在EDM中正确建模？

提前致谢。

更新1：

为了澄清这个问题，我将提供一些背景信息，说明为什么我需要这样的模型。我必须能够创建一条消息。在此消息中，我必须指明它是否涉及一个或两个人。在这些人中，我指定了名字，姓氏和一些其他非独特属性（两个人可以具有相同的名称）。我可以在Message实体（fname1，lname1，fname2，lname2）中转储所有这些属性，但这似乎是一个坏主意。因此Person实体诞生了。但是，这可能看起来像Person可以链接到许多消息，但事实并非如此。可以有两个具有相同属性的不同人员。没有办法说出这些人在现实生活中是否真的是同一个人。

在地址的情况下，类似的论点成立。两个地址的拼写可能有点不同，但如果我将它们写在一封信上并邮寄，它们都会到达同一地点（例如sesamestreet或sesamestr。）。所以我没有一个Address实体连接到多个Messages。同样，Address是一个单独的实体的唯一原因是因为我有两个具有完全相同属性的em。 从数据库设计的角度来看，这可能没有意义，从类图的角度来看，它可能会更有意义。我的印象是EF中的EDM不应该像数据库设计，而更像是域模型，所以我希望我做对了。

更新2：

我只是想到了我认为在这种情况下可能是最好的方法。因为Person1和Person2之间几乎没有区别，所以我觉得Message和Person之间的联系可以接受。许多意味着两个将是较低层处理的事实。在地址的情况下，from和to是完全不同的。它们都是地址，但我觉得我不能把它列成一个列表。我可以将from和to地址拆分为单独的实体，并让它们从Address继承。然后将Message与每个子类关联起来。它可能看起来有点矫枉过正，但你可以推断，某个地址可能在某些时候有不同的要求，而不是地址，因此不同的属性。

虽然我并不百分百（特别是地址部分）。这个解决方案可能会或可能不会，但我觉得它避免了核心问题。

Answer 1

对于第一个问题（消息 - 人）：

关键问题是：你想让person1不可为空吗？和person2？

你勾勒出的第二个选择看起来很好，我认为你需要一条消息才能拥有1个Person1（比如：消息的创建者），所以这是一个不可为空的属性。 Person2（例如：上次更新消息的人）可以为null或链接到现有人。精细！

你从人类角度看到的是它有两个关联（和2个导航属性，你折叠了......）一个用于消息，其中一个特定的人（人实体的实例）是一个人的创建者和一个对于那个特定的人是最后一个更新者的消息。挺好的！不是吗？通过这种方式，您可以从消息的角度查询模型（给我所有消息以及创建它的每条消息的人员并最后更新它...）或者......查询一个人并收集此人的所有消息创建或是...的最后一个更新程序吗？

但所有这些都归结为确定你是否允许Person1和Person2的可空性。

我没有读过你的第二个问题，但认为它更像是一样。还需要一些建议吗？请打电话给我。

此外。如果从商业/功能角度来看，只有两个人就足够了，那么替代方案2就是要走的路。另一方面，如果你想要一个完整的历史记录，那么如何更新消息以及创建它的人（这将永远只有一个）你最终得到一个导航属性Message.Creator（正好一个）和Message.Updaters（ 0到很多）。你看？从个人的角度来看，他们可能是消息的创建者（0到多个）或消息的更新者（0到多个）。

Answer 2

Phew ...幸运的是，您看到了将消息实体反编译为更多逻辑和可重用实体（如人，消息和地址）的重要性。根据我的拙见，你应该有这个设计 - ＆gt;

  

因此，Person实体诞生了。   但是，这可能看起来像一个人   可以链接到许多消息，但是   不是这种情况。可以有两个   不同的人有同样的   属性。没有办法说出来   这些人是否真的是   现实生活中的同一个人与否。

这对我来说听起来很奇怪......虽然输入可能不正确，例如两个人反映一个现实生活中的人，但有一些错字。但是仍然有人可以有更多的消息......而且当真的不是这样的情况时，你可以在你的业务代码中处理这个问题，以防止特定的人被耦合到多个消息......

****更新*****

我应该这样建模：