2016-01-23 64 views
0

偶爾我會遇到以下所有條件對兩個高度相似但不完全相同的實體或對象都爲真的情況。這使我很難決定如何對它們進行建模,無論是在數據庫端還是在對象建模方面。我會試着詳細說明這個問題和我的問題,因爲我發現它是一個非常難以定義的建模問題。我正在嘗試使用這些實體進行數據和對象建模,因此我將稍微鬆散地使用這兩個學科的術語。重疊對象/數據實體類型的最佳實踐

1)兩個實體共享許多相同的屬性,但有一些沒有在另一箇中找到的獨特屬性。

2)一個不是另一個的超類型或子類型。

3)重疊不是由於對象繼承。

4)對象用於不同目的在同一個域中,但通常在任何工作流中都非常接近。這經常導致那些具有中等領域知識的人混淆實體。另一方面,這種精細的分離導致相關對象的方法之間的差異比它們的屬性更大。

5)在某些情況下,可能在數據庫端創建橋表以表示實體之間的M2M關係。儘管如此,它們擁有如此多的屬性(或數據庫方面的列),因此將它們存儲在同一個表中可能有意義。

我碰到的一些案例包括: 1)「產品vs.項目混淆」 - 尤其是在產品和項目共享許多相同屬性的軟件營銷中。通常情況下,一個產品將有多個與之相關的項目,但同時也可以想象一個項目可用於多種產品。

2)軟件開發中功能和組件之間的細微差別。一個功能是以開發人員爲中心的一種手段,從客戶的角度提供一個好處,而一個組件是開發人員實現功能的一種手段。這是一個非常微妙的區別,儘管如此。有關進一步的討論,請參閱Rod Maupin的文章http://www.installationdeveloper.com/347/features-and-components-101/

3)模板與很多不同問題域中的類型。例如,當通過TypeID列識別吉他的類型時,它引用的TypeTable可能會有與色彩,字符串大小,體形等相對應的列。另一方面,模板是您要製作吉他的東西from,因此它可能與Type有不同的方法,可能鏈接到「應用模板」或「從模板生成項目」菜單命令。儘管如此,它將具有許多與Type相同的列或屬性,例如顏色,形狀,字符串大小等。這種區別在許多問題域中引發數千種不同對象類型和模板,而不僅僅是這個狹窄的示例。使事情進一步複雜化,在某些情況下,將多個模板與特定類型相關聯和/或反之亦然可能會有所幫助。

我還沒有遇到這種經常重疊實體的問題,但是當它發生時,它就成爲一個真正的瓶頸,並導致重構​​數據和對象模型的很多浪費時間。我已經閱讀了關於這兩個主題的書籍,並且對數據/對象建模網頁進行了大量關於該問題的搜索,但尚未見到它的討論。我在StackOverflow上可以找到的唯一匹配是「重疊」和「數據模型」,用於區分一個表或實體中的相似列,而不是跨表或實體。我的問題是:

1)此問題是否有正式名稱?

2)是否有貿易在建模過程的開始,以確定這種重疊的實體,而不是更遠的路線,當後知後覺,使重構問題的一個簡單的快捷方式或把戲?

3)如何處理這些重疊的實體?我認爲就面向對象而言,它們應該有單獨的對象,因爲它們的方法往往是不同的。從另一個繼承一個將是尷尬的。更難的問題是在數據庫端使用單獨的表是否合理。將它們組合起來可能需要一系列複雜的視圖,當它們不共有的屬性/列保留爲空時,會浪費存儲空間。儘管如此,將它們存儲在單獨的表格中也可能是浪費的,如果通用屬性可以存儲在單個列中的話。

這是一個棘手的問題,甚至承認,更不用說處理。我在數據/對象建模方面的經驗並不多,因此真正瞭解他們所做工作的人的意見會很有幫助。謝謝:)

+0

重疊的另一個例子是數據建模與軟件工程。我更願意使用面向對象的系統建模和領域建模的關係模型,保持學科正交。 – reaanb

回答

1

你既涉及疑問,面向對象(編程)造型方面數據庫建模方面。我們從抽象的角度出發。

你說:

1)這兩個實體有着許多相同的屬性,但在其他未找到一些獨特的。

2)一個不是另一個的超類型或子類型。

和:

3)的重疊不是由於對象繼承。

但是請注意,繼承應該不要與亞型混淆,即使很多時候他們綁在一起!例如參見維基百科的Inheritance (object-oriented programming),其中該語句由兩個引用[12]支持。換句話說,即使A不是B的子類型,而B也不是A的子類型,也可以找到A和B都從中繼承屬性的C。

所以,你能想到或沒有這個C作爲A和B的「抽象父」;但無論如何,至少從數據庫的角度來看,將其視爲共同的祖先是很方便的,因此將「通用性」中的常見屬性因式分解。然後,從面向對象編程的角度來看,你可以將A或B看作是C的子類型,或者簡單地看成是兩個不同的東西,這取決於你的對象關係映射工具的特性,以及手邊的問題等等。

當然,這種對事物進行建模的方式並不禁止A和B除了繼承C之外,還有一個或多個它們之間的關係,就像你已經完成的示例Products-Projects一樣。

所以,這裏是我的回答您的四名決賽的問題:

1)是的,它被稱爲繼承。

2)您可以檢查兩個實體是否有大量的通用屬性。 3)你可以在數據庫中用一個公用表建模它們,這可能有一些共同的屬性,如完整性約束,並且有兩個表有一個外鍵。當然,這條規則不是盲目應用的,而是可以與所有人類規則有所不同。從編程的角度來看,另一方面,你可以決定使用超類型還是不使用超類型。這取決於很多因素,應該根據具體情況來決定。

+0

感謝您的反饋,我還有2個其他問題。我沒有使用繼承的原因之一是,在我看到的例子中,兩個實體都不佔主導地位。如果我使用超類型,我可以從那裏繼承嗎?我也沒有使用超類型,因爲沒有真實世界的對象包含模板和類型,產品和項目,或功能和組件。爲虛擬超類型創建基表併爲基表使用一些通用名稱(如TemplateTypeTable,ProductProjectTable或FeatureComponentTable)是否明智?謝謝! :) – SQLServerSteve

+0

P.S.我打算提高你的答案,但必須等到我獲得足夠的代表點。 :) – SQLServerSteve

+0

1)是的,你可以從同一個超類型繼承。 2)我認爲這是合理的,特別是如果你有一些共同的屬性。有時我發現,在定義了一個共同的超類型之後,我發現它們也有一些有用的操作。附:即使你不能贊成,你也可以通過點擊標記來接受答案,但是這樣做*只有*如果你對答案滿意:) – Renzo