1

我有两种情况我想要这样的东西。在我的模型中,我有一个Message涉及一个或两个Persons的。此外,该消息与两个 相关Addresses,即一个 fromAddress和一个 to Address

在两者的第一种情况下Persons,我想指定 1---1..2 之间的关联MessagePerson多重性,或者指定两个关联,一个与 1---1,另一个与 1---0.. 1. 但是,我不能(或不知道如何)将多重性设置为两个。我可以想象有可能将其设置为 1--* 并将约束设置为最大值 2(但是我不知道该怎么做)。
通过添加这两个关联,当我从侧面看时我感觉有点奇怪,Message因为这两个关联都有一个 1 ,这表明 aPerson应该有两个Messages与之相关。对于两个关联,我可能想要像 0..1 这样的Message东西,对它们有异或约束或其他东西,但我不知道这在 EF 中是否是好的做法,甚至可能。 我想指定它的最大值为 2 现在看起来一个人有两个不同的消息 现在看起来一个人可以有两个或没有消息

对于第二种情况,问题非常相似,只是总有一个 fromAddress和一个 to Address。设置多重性 1--* 对我来说似乎不合适。在这里,我想肯定应该有两个关联,一个 from 和一个 to 关联(恰好都去Address实体)。Message然而,这会在有两个 1 或两个 0..1 的情况下导致相同的问题。
这里的地址有两条消息 现在地址有零到两个消息

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

提前致谢。

更新1:

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

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

更新 2:

我只是想到了我认为在这种情况下可能是最好的方法。因为和之间几乎没有区别Person1Person2我觉得MessagePerson1..* 之间的关联是可以接受的。许多意味着两个的事实将是较低层处理的事情。在地址的情况下,from 和 to 是完全不同的。它们都是地址,但我觉得我无法将它们列在列表中。我可以将 from 和 to address 拆分为单独的实体,并让它们继承自Address. 然后Message与每个子类关联。这似乎有点矫枉过正,但您可以推断,在某些时候,发件人地址可能具有与收件人地址不同的要求,因此具有不同的属性。 解决方案

不过,我并不是 100% 高兴(尤其是地址部分)。这个解决方案可能好也可能不好,但我觉得它避免了核心问题。

4

2 回答 2

0

对于第一个问题(消息 - 人):

关键问题是:您是否希望 person1 不可为空?和人2?

考虑到您需要一条消息恰好有 1 个 Person1(例如:消息的创建者),您草拟的第二种选择对我来说看起来还不错,因此是不可为空的属性。Person2(例如:最后更新消息的人)可以为 null 或链接到现有人员。美好的!

您从人员类的角度看到的是,它有两个关联(和 2 个导航属性,您折叠了......)一个用于特定人(人实体的实例)是创建者的消息,一个用于这些消息这个特定的人是最后一个更新者。挺好的!不是吗?这样,您可以从消息的角度查询模型(给我所有消息以及创建它和最后更新它的每条消息的人......)或者......查询一个人并收集这个人的所有消息创建或者是最后一个更新...得到它?

但一切都归结为确定您是否允许 Person1 和 Person2 的可空性。

我没有阅读你的第二个问题,但认为它更像是一样的。也需要一些建议吗?打电话给我。

此外。如果从业务/功能的角度来看,两个人就足够了,那么备选方案 2 就是要走的路。另一方面,如果您想要完整的人员历史记录如何更新消息以及创建消息的人(这将始终是一个),您最终会得到一个导航属性 Message.Creator(完全是一个)和 Message.Updaters( 0到很多)。你看?从这个人的角度来看,他们可能是消息的创建者(0 到多)或消息的更新者(0 到多)。

于 2011-01-27T11:45:10.977 回答
0

呼……幸运的是,您看到了将消息实体反编译为更符合逻辑和可重用的实体(如人员、消息和地址)的重要性。以我的拙见,你应该有这个设计->

重新设计

因此,Person 实体诞生了。但是,这可能看起来像一个 Person 可以链接到许多消息,但事实并非如此。可以有两个不同的人具有相同的属性。无法判断这些人在现实生活中是否真的是同一个人。

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

**** 更新 *****

我应该这样建模:

我的设计

于 2011-01-27T14:40:34.687 回答