供應場可以有運輸文件。如果存在，它可以是兩種類型之一：內部或外部。這兩份文件都有一些共同的數據，但有不同的專業領域。ER繼承建模
不過，我覺得像這樣一個OO上下的時尚造型如此： alt text http://www.arsmaior.com/tmp/mod1.png
在文件表，這兩個文檔_ * _ id爲null之一，另一個是與相應的表的外鍵。
即相對於其他模式，其中常見的數據是冗餘的： alt text http://www.arsmaior.com/tmp/mod2.png
我試圖發現正反兩種方法的缺點&。
如何在兩種情況下選擇知道所有內部文檔？我們有一種互斥的外鍵，JOIN並不是很微不足道。
第一種方法是完全垃圾嗎？
古典ER建模不包括外鍵，你的問題的要點圍繞外鍵如何工作。我認爲你真正在做的是關係建模，即使你正在使用ER圖。
在關係建模方面，有第三種方法來建模繼承。那就是爲專用表使用與廣義表相同的ID。然後，doc_internal表的ID字段既是doc_internal表的主鍵，也是引用supply_farm表的外鍵。 doc_external表同上。
supply_farm表中的ID字段既是supply_farm表的主鍵，也是引用doc_internal或doc_external表的外鍵，具體取決於。這些加入神奇地將正確的數據組合在一起。
需要一些編程來設置它，但它非常值得。
欲瞭解更多詳情，我建議你谷歌「泛化專業化關係建模」。網上有關於此主題的一些優秀文章。
這兩種方法都是正確的，它們的使用將完全取決於用例，要存儲的數據的種類和數量，以及您最想要查詢的查詢類型。當繼承層次結構複雜時，您也可以考慮將這兩種策略結合起來。
其中第一種方法將是首選的用例我認爲當您要搜索所有文檔時，例如，基於描述或任何公共字段。
This文檔（雖然特定於hibernate）可以提供有關不同繼承建模策略的更多信息。
如果我正確地理解了這一點，那麼供給場對應於0或1個文檔，它總是內部或外部文檔（從來都不是）。
如果是這樣，那麼爲什麼不直接使用一個表，像這樣：
**SUPPLY_FARM_DOC**
ID Int (PK)
DOC_ID Int
INTERNAL_FLAG Boolean
DESCRIPTION Varchar(40)
SOME_DATA Varchar(40)
OTHER_DATA Varchar(40)
etc.
問題是我想避免任何類型的標誌和數據冗餘。 – vulkanino 2010-08-10 15:42:50
除非您有大量不同的內部和外部文檔數據結構，否則數據冗餘可能會很小。你有什麼反對旗幟？ – 2010-08-10 15:57:33
「我認爲，你真正做的是關係建模，即使您正在使用ER圖」。我一直使用ER作爲實體關係的縮寫 - 即。它*是*關係建模。你用ER代表什麼？ – 2010-08-10 13:37:35
對我來說也是一樣，ER =關係型。 – vulkanino 2010-08-10 15:41:29
Peter Chen於1976年開發的ER模型有意與1970年由Ed Codd開發的關係模型有所不同。您可以在維基百科和其他地方閱讀它。 ER模型旨在用於概念數據分析，而不是用於數據庫設計。它也打算在關係模型和稱爲分層和網絡的圖形模型之間是不可知的。許多人今天使用ER圖來表達關係模型，但這是對ER建模的偏離使用。沒有什麼大不了的，除非它可能導致像這個問題一樣的混淆。 – 2010-08-10 18:51:34