關係數據庫設計 - 關係問題

Question

我需要創建數據庫表來存儲備忘錄。在「收件人」條款中，用戶可以選擇單個員工或一組員工（不同的組已經可以在與員工有多對多關係的數據庫中使用）。我想知道什麼應該是表結構。 對於沒有羣組的簡單備忘錄，我將使用帶有EmployeeID作爲外鍵的memodetail的「MemoMasters」和「Memodetails」。我怎麼能在這個結構中嵌入組

關注

Answer 1

只要您將其作爲關係建模任務來處理，我就不會看到複雜性。假設你想要一個純粹的關係解決方案，試試這個Memo Data Model。如果您不熟悉關係數據庫建模標準，IDEF1X Notation可能會有所幫助。

1. 它使用普通的超類型 - 子類型結構。

   • 在這種情況下，它是獨佔：所述MemoAddress即任和EmployeeAddress 或一個GroupAddress。

   • 獨佔子類型需要超類別中的判別器：我使用了布爾型IsEmployee，CHAR代碼或類似的也很常見。

2. 這是純5NF;沒有更新異常;完整的陳述式參照完整性。 Ack是在正確的位置（我使用了DateTime，但布爾也很好）。

3. 但是，如果您不習慣使用投影來填充Supertype-Subtype結構，它可能看起來很難看;只是問你是否需要幫助。

4. 不要把「簡單的備忘錄與一個員工」不同，你會遇到的問題，重複碼等

5. 另外一個問題是，你可能需要Employee誰寫的EmployeeIdMemo，這是一個不同的事情，因此你需要在Memo的Employee FK。

Answer 2

在這個結構中你不能。

這是一個many to many的關係，模型如此。

EDIT（審查的情況）： 上述規定是不夠的，確定了「精確解」

在過於簡化的風險，你應該：

1）檢查，如果你能堅持新的信息到任何現有的表/實體
2）如果不是，則檢查是否添加屬性/列到任何現有的表/ entties
3）如果不是，則添加新的表

的癸永遠不會明確切斷你的想法，你應該考慮幾種情況及其後果。您還應該定期檢查模型，以便尋找機會進行標準化，因爲它會極大地影響系統的整體功能。

因此，例如，當您聲明您已經擁有多組表的許多表時，現在的主要問題是天氣重用該表或創建一個新表。

這取決於此表中的其他屬性。也許對於你的商業模式/用例來說它是有道理的，也許它沒有。

也許你需要建模一個名爲「MemoRecipients」的表，它將存儲收件人的信息（傳遞，確認等等）。那麼你應該問自己，你是否需要所有這些狀態的時間等等...

只有你可以確定什麼是適合你的問題空間的設計決策。

Answer 3

看起來好像你需要繼承heirarchy來實現你所描述的。考慮下面的圖：

在此圖中創建一個父表（我稱之爲海報）和僱員和組表是兒童。您必須爲員工表和組表創建相同的主鍵，也就是說，從組到組和海報以及員工之間有一對一的鏈接。

這樣，備忘錄的poster_id字段指向超類。您可以在海報，小組和員工之間進行連接，以確定您是否指向員工或小組。

我從圖表中刪除了員工和組之間的關係，就像您說的那樣。

請注意，這只是可能的解釋，您的解決方案可能會有所不同。