实体框架建模 - 如何建模这个简单的数据结构？

Question

这是一个相对简单的数据结构，但我有一个很难搞清楚的最佳EF策略来建模。这显然不是每个层次的表。所以我尝试了Table Per Type，它不喜欢客户与人或客户与人之间的关系。在阅读了关于每个具体类型的表之后，它也没有遵循该模型。 S如何模拟这个ERD？

＃

更新

＃

其背后的商业用例是我们处理与几家公司。其中一些公司已经购买了其他公司。母公司（Acme）长期以来一直是客户。儿童公司（泽塔）一直是一个长期的客户。当Acme收购Zeta时，他们让一个负责处理公司之间关系的人（Adam）。亚当现在有两个不同的电子邮件地址需要通知事件。 adam@acme.com获取客户通知。 adam@zeta.com获取客户通知。这就是我将它建模的原因。亚当有点强迫症，喜欢将他的通知分成单独的邮箱。作为程序员，我不喜欢亚当。 ：D

系统中还有其他几种分类比客户和客户。我们也有供应商，技术人员和分销商。我最终建模非常类似于下面的建议，但将电子邮件表分成类型特定的表（CustomerEmail和ClientEmail）。不完美，但为了“完成”，它可以工作。

Answer 1

一个人既可以是客户，也可以是客户。

然后Client和Customer不能从Person继承。你必须用组合来对它进行建模。 不是：A Person是Client或Customer。 而不是：A Person具有属性为Client和/或Customer。

随着EF这将是两个一比一的关系：

public class Person 
{ 
    public int PersonId { get; set; } 
    public Client Client { get; set; } 
    public Customer Customer { get; set; } 
} 

Client和Customer可以有Person参考闯民宅回Person。 （他们并不需要有这样的参考，但它是有道理的，以使通过该导航属性访问名字和姓氏。）

public class Client/Customer 
{ 
    public int PersonId { get; set; } 
    public Person Person { get; set; } 
} 

我认为一个人并不需要始终都一个Client和一个Customer属性，但有时只有一个（或甚至零？）。在这种情况下Person是在这两个关系的本金和Client/Customer的家属：他们必须有的Person参考，但Person只有可选引用Client和Customer。用流利的API，这将被模拟像这样：

modelBuilder.Entity<Person>() 
    .HasOptional(p => p.Client) 
    .WithRequired(c => c.Person); 

modelBuilder.Entity<Person>() 
    .HasOptional(p => p.Customer) 
    .WithRequired(c => c.Person); 

Person和Note之间的关系是两个普通的一个一对多的关系。 Person可以有两个导航集...

public ICollection<Note> NotesAsNotator { get; set; } 
public ICollection<Note> NotesAsNotatee { get; set; } 

...和Note可以有两个引用Person与两个外键的属性在一起（他们不需要在模型中，但往往有助于暴露）：

public int NotatorIDFK { get; set; } 
public Person Notator { get; set; } 

public int NotateeIDFK { get; set; } 
public Person Notatee { get; set; } 

而且关系与流利的API定义如下：

modelBuilder.Entity<Person>() 
    .HasMany(p => p.NotesAsNotator) 
    .WithRequired(n => n.Notator) 
    .HasForeignKey(n => n.NotatorIDFK) 
    .WillCascadeOnDelete(false); 

modelBuilder.Entity<Person>() 
    .HasMany(p => p.NotesAsNotatee) 
    .WithRequired(n => n.Notatee) 
    .HasForeignKey(n => n.NotateeIDFK) 
    .WillCascadeOnDelete(false); 

级联删除亩（至少为两种关系中的一种），否则Person可以通过多个级联删除路径删除Notes，这是由于两种关系至少在SQL Server中是被禁止的。

Location和Client之间和Location和Customer之间的关系又是每一个（总共四个），在Location 4个系列，并Client和Customer到Location两个引用两个一到多的关系。它们与上述关系类似。

Client和Email和Customer和Email之间的关系是一个问题，因为他们是一对之一，但显然与外键PersonIDFK（具有唯一键约束？）这不是由EF支持。正如Gert Arnold在评论中所问：为什么Person和Email之间没有关系？这两种关系是否表示一个人可以拥有另一个电子邮件地址作为客户而不是客户？我不明白模型的这一部分。