1

我正在設計一個數據庫,由於我在這個主題方面沒有太多經驗,所以我面臨着一個我不知道如何去解決的問題。在數據庫設計的邏輯設計階段實現泛化?

在我的概念模型中,我有一個客戶命令和庫存系統監視的被稱爲「車輛」的對象。這種超類型有兩個子類型「汽車」和「摩托車」。用戶可以訂購一個或另一個,甚至兩個。

現在我處於邏輯設計階段,我需要知道如何讓系統允許兩種不同類型的產品。我遇到的問題是,如果我把每個對象分開的屬性放到同一個關係中,那麼我將有對某些對象沒有用處的列。例如,如果我只有一個擁有「汽車」和「摩托車」的泛型表,我稱其爲「車輛」及其所有屬性,則車輛不需要某些摩托車屬性,摩托車不會需要所有的汽車屬性。

有沒有辦法解決這個問題?

+1

[類似於數據庫設計中的繼承]的可能重複(http://stackoverflow.com/questions/554522/something類似於數據庫設計中的繼承) –

回答

3

決定將需要以共享信息的數量爲指導。我會從識別所有屬性和關於它們的規則開始。

如果大部分信息是共享的,則可能不會拆分爲多個表。另一方面,您總是可以拆分表格,然後加入視圖以方便使用。

例如,您可能只有一個只有共享信息的車輛表,然後是帶有車輛表的外鍵的汽車表和帶有車輛表的外鍵的摩托車表。確保您沒有摩托車排和摩托車排涉及同一輛車是有一定難度的,所以還有其他可能性來減輕這種情況 - 但如果大多數信息都是常見的,那麼這是不必要的,您只是在單個車輛表中有未使用的列。你甚至可以使用約束來強制執行,以確保列對於不應填寫的類型爲NULL。

+0

同意。純粹的方法是對所有共享屬性使用VEHICLE表,併爲不同的屬性使用分區屬性和MOTORCAR和MOTORCYCLE表。您還可以擁有加入超類型和子類型的視圖(MOTORCAR_VIEW和MOTORCYCLE_VIEW?),爲您提供任何類型或其他類型實例的完整圖片。您也可以將其作爲您的概念模型進行建模,但將其平鋪到物理模型中的單個表格中。使用由您的分區屬性驅動的約束將保持您的物理表清潔。 –