我正在根據與MySQL workbench生成的ERD執行UML模型。但是現在我對類圖中的主鍵和外鍵表示懷疑了。uml中的主鍵/外鍵
在傳統的UML圖中,我們應該將主鍵包含爲每個類的屬性?例如,id_user
或id_list
?關於外鍵?這些被忽略作爲屬性,但反映爲協會?
謝謝
我正在根據與MySQL workbench生成的ERD執行UML模型。但是現在我對類圖中的主鍵和外鍵表示懷疑了。uml中的主鍵/外鍵
在傳統的UML圖中,我們應該將主鍵包含爲每個類的屬性?例如,id_user
或id_list
?關於外鍵?這些被忽略作爲屬性,但反映爲協會?
謝謝
首先:爲什麼你想用UML繪製它?如果你已經有了ERD,你想用ERD不給你的UML類圖來說明附加/替換屬性是什麼?
爲什麼?因爲UML是一種工具。假設該圖僅供人使用(即,您不是通過它生成代碼),那麼您應該使用UML來公開您嘗試傳遞的信息。
作爲一個通用的標準,UML並沒有說明你是如何正規化身份(PK/FK)的。 UML遵循面向對象的習慣用法,即每個對象都有隱含的標識 - 因此你不需要明確地指定它。因此,在最簡單的情況下,您可以:
如果這符合你的建模需求,那麼你就完成了。作爲第二個改進,您可以使用ocl isUnique()
約束標記PK屬性,並再次忽略FK。
另一種選擇是使用Executable UML的規則。它在類圖上直接表示PK('標識符'}和FK('參考屬性'),因此它最接近於捕獲ERD中的所有內容
總之:沒有UML強加的正確答案。這一切都取決於你想用圖來溝通一下。
心連心。
您可以使用/創建一個「數據庫配置文件」這一信息來註釋你的UML模型。如果沒有,你可以使用OCL到配置文件指定唯一性約束,而正常關聯應足以表示將在數據庫級別轉換爲外鍵的內容
您可以使用EclipseUML Omondo試用版並反轉您的數據庫。
您將獲得您需要的信息,然後您可以將其複製到免費或開源工具中。
忽略FK沒有太大意義,imo。使用關聯(具有成員關係的屬性)(如OP所要求的)更合適。 – Christian 2012-04-24 14:01:20
@Christian:是的,FK可以在關聯結束時顯示爲角色。我的觀點是沒有一套必須適用的規則。你有自由去做一些適合你的特定情況的東西。 FKs作爲角色將是一個很好的默認值。 – sfinnie 2012-04-24 14:37:30