擴展實體關係圖：子類有外鍵還是主鍵？

考慮這個例子（順便說一下，它們是不相交的）：

我猜有兩種情況：

1. 在將其轉換為關係表時，PROGRAMMER 中的行是唯一的，在 EMPLOYEE 表中不存在，並且它具有 PRIMARY KEY
2. 它們已經存在於 EMPLOYEE 表中，並且 PROGRAMMER 有一個引用它的外鍵。

哪個場景是正確的？還是兩者都錯？

這不是非此即彼的情況。您的特定係統的答案可能作為這兩個選項的組合存在。讓我解釋。

如果 Programmer、Engineer 和 Admin 表之間的唯一共同屬性是 Emp#，那麼我可能會將它們實現為單獨的表。每個都將 Emp# 作為主鍵。我根本不會實現 Employee 表，因為它沒有為執行時系統增加額外的價值。

如果這三個子類型有許多共同的列，比如 Name、HireDate、Department ..HolidayBalance、ContactNumber 等，並且只有少數子類型特定的值（正如您在圖表上註釋的那樣），您可以放置​​所有列在 Employee 中，將不適用的（例如程序員的 EType）設為 NULL。如果排除 NULL 變得乏味，則可以為每個子類型定義一個視圖。

事實可能介於這兩者之間——每個子類型中都有足夠的特定屬性來保證它自己的表，但也有足夠的常見屬性來證明 Employee 表的合理性。在這種情況下，我將 Emp# 設為 Employee 的主鍵，並且每個子類型也將具有 Emp# 的主鍵。此外，我將 Programmer.Emp# 定義為引用 Employee.Emp# 的外鍵，其他子類型也是如此。以這種方式，在每個子類型中都保持唯一性，並且子類型和超類型之間的完整性也是如此。換句話說，我會在 Employee 和每個子類型之間建立一對一的關係。

我不會在每個子類型（例如 ProgrammerId）中實現代理鍵，因為它沒有添加 Emp# 無法實現的任何內容。

請注意，很難以聲明方式確保子類型之間的互斥。這將在應用程序中或通過觸發器強制執行。

引用自：https://dba.stackexchange.com/questions/218934