偶爾我會遇到以下所有條件對兩個高度相似但不完全相同的實體或對象都爲真的情況。這使我很難決定如何對它們進行建模,無論是在數據庫端還是在對象建模方面。我會試着詳細說明這個問題和我的問題,因爲我發現它是一個非常難以定義的建模問題。我正在嘗試使用這些實體進行數據和對象建模,因此我將稍微鬆散地使用這兩個學科的術語。重疊對象/數據實體類型的最佳實踐
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)如何處理這些重疊的實體?我認爲就面向對象而言,它們應該有單獨的對象,因爲它們的方法往往是不同的。從另一個繼承一個將是尷尬的。更難的問題是在數據庫端使用單獨的表是否合理。將它們組合起來可能需要一系列複雜的視圖,當它們不共有的屬性/列保留爲空時,會浪費存儲空間。儘管如此,將它們存儲在單獨的表格中也可能是浪費的,如果通用屬性可以存儲在單個列中的話。
這是一個棘手的問題,甚至承認,更不用說處理。我在數據/對象建模方面的經驗並不多,因此真正瞭解他們所做工作的人的意見會很有幫助。謝謝:)
重疊的另一個例子是數據建模與軟件工程。我更願意使用面向對象的系統建模和領域建模的關係模型,保持學科正交。 – reaanb