在員工，經理和部門關係中實現參照完整性

Question

我在ER中發現了一個案例，對於我而言，我無法弄清楚如何實現參照完整性。傳統的員工，經理，部門關係可以說明這個問題。

有以下限制：

1. 員工只能在一個部門工作。
2. 部門可以有很多員工。
3. 員工可以有一個經理在同一部門工作。
4. 經理可以有許多員工在同一部門工作。
5. 沒有經理的員工是經理。

該圖說明了這個概念。

正常化之前，我落得下表。

正常化後，我結束了這些表。

但是，仍然沒有什麼意外分配經理在一個部門工作，僱員在EmployeeManager表中的不同部門工作，阻止我。

一個可能的解決方案，我發現是把繫到EmployeeManager表和定義參考完整性約束，這樣{Manager, Department}在EmployeeDepartment表是指{Employee, Department}。

然而，對於這個工作不{Manager, Department}必須是一個候選鍵？有不同的設計可以解決這個問題嗎？

更新

好回答我的第一個問題，不{Manager, Department}必須是一個候選鍵？事實證明EmployeeManager表中的{Manager, Department}不必是候選密鑰或唯一密鑰。它只是一個外鍵，引用EmployeeDepartment表中的{Employee, Department}。 {Employee, Department}鑰匙的唯一性沒有明確定義，並且可能在不同的發動機之間有所不同。例如，MySQL建議外鍵僅引用唯一鍵。

此外，由於性能原因，MySQL要求對引用列進行索引。但是，系統不強制要求被引用的列是UNIQUE或被聲明爲NOT NULL。對包含NULL值的非唯一鍵或鍵的外鍵引用的處理對於UPDATE或DELETE CASCADE等操作沒有很好的定義。建議您使用僅引用UNIQUE（包括PRIMARY）和NOT NULL鍵的外鍵。

在我的情況下，它會工作，因爲員工可以在一個部門工作，僅但是如果約束的機會，讓員工在許多部門的工作將無法正常工作，因爲{Employee, Department}將不再是唯一的。

它應該適用於所有情況，包括限​​制機會是否允許員工在多個部門工作。

有沒有不同的設計可以解決這個問題？我還考慮用ManagerDepartment表替換EmployeeDepartment表，其中{Manager}作爲主鍵，然後回到之前的EmployeeManager表和(Employee, Manager)列。因此，現在要找出哪個部門的員工工作，您需要加入EmployeeManager與ManagerDepartment表。

您是否發現此設計有任何不良做法或異常？

Answer 1

假設所有這些列都被聲明爲NOT NULL。 。 。

一個可能的解決方案，我發現是把繫到 EmployeeManager表和定義參考完整性約束，所以 即{經理，部門} {指員工，部門}在 EmployeeDepartment表。

是的，在「EmployeeManager」表中添加一個「department」列。但是你需要兩個重疊的外鍵約束。 （不過，見下文。）

• （經理，部門）引用EmployeeDepartment（員工，部門）
• （員工，部門）引用EmployeeDepartment（員工，部門）

由於EmployeeDepartment。員工是唯一的，EmployeeDepartment.Employee和EmployeeDepartment.Department這兩列是也是的唯一。因此，您可以聲明「員工」作爲主鍵，並且也聲明一對列（Employee，Department）上的唯一約束。如果需求發生變化並允許員工在多個部門工作，則可以刪除單列主鍵。 I可能會同時刪除主鍵和唯一性約束，並創建一個包含這兩列的主鍵約束，但所有嚴格來說必需的都是刪除主鍵約束。

在像你這樣的系統中，通常有一個好主意是擁有一個管理員表，帶有明顯的外鍵引用。現在，如果你刪除員工威爾，你會失去史蒂夫是經理的事實。