實體框架建模 - 如何建模這個簡單的數據結構？

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之間沒有關係？這兩種關係是否表示一個人可以擁有另一個電子郵件地址作爲客戶而不是客戶？我不明白模型的這一部分。