ER繼承建模

供應場可以有運輸文件。如果存在，它可以是兩種類型之一：內部或外部。這兩份文件都有一些共同的數據，但有不同的專業領域。ER繼承建模

不過，我覺得像這樣一個OO上下的時尚造型如此： alt text http://www.arsmaior.com/tmp/mod1.png

在文件表，這兩個文檔_ * _ id爲null之一，另一個是與相應的表的外鍵。

即相對於其他模式，其中常見的數據是冗餘的： alt text http://www.arsmaior.com/tmp/mod2.png

我試圖發現正反兩種方法的缺點&。

如何在兩種情況下選擇知道所有內部文檔？我們有一種互斥的外鍵，JOIN並不是很微不足道。

第一種方法是完全垃圾嗎？

來源

2010-08-10 vulkanino

古典ER建模不包括外鍵，你的問題的要點圍繞外鍵如何工作。我認爲你真正在做的是關係建模，即使你正在使用ER圖。

在關係建模方面，有第三種方法來建模繼承。那就是爲專用表使用與廣義表相同的ID。然後，doc_internal表的ID字段既是doc_internal表的主鍵，也是引用supply_farm表的外鍵。 doc_external表同上。

supply_farm表中的ID字段既是supply_farm表的主鍵，也是引用doc_internal或doc_external表的外鍵，具體取決於。這些加入神奇地將正確的數據組合在一起。

需要一些編程來設置它，但它非常值得。

欲瞭解更多詳情，我建議你谷歌「泛化專業化關係建模」。網上有關於此主題的一些優秀文章。

來源

2010-08-10 10:00:14

「我認爲，你真正做的是關係建模，即使您正在使用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

這兩種方法都是正確的，它們的使用將完全取決於用例，要存儲的數據的種類和數量，以及您最想要查詢的查詢類型。當繼承層次結構複雜時，您也可以考慮將這兩種策略結合起來。

其中第一種方法將是首選的用例我認爲當您要搜索所有文檔時，例如，基於描述或任何公共字段。

This文檔（雖然特定於hibernate）可以提供有關不同繼承建模策略的更多信息。

來源

2010-08-10 09:14:12 Gopi

如果我正確地理解了這一點，那麼供給場對應於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.

來源

2010-08-10 13:52:15

問題是我想避免任何類型的標誌和數據冗餘。 – vulkanino 2010-08-10 15:42:50

除非您有大量不同的內部和外部文檔數據結構，否則數據冗餘可能會很小。你有什麼反對旗幟？ – 2010-08-10 15:57:33

ER繼承建模

回答

相關問題