簡體   English   中英

關於UML類模型中的1對1關聯

[英]Regarding 1 to 1 associations in UML class models

在 UML 建模中,我們經常遇到類模型,它表示給定類之間的 1 x 1 或 1 x 1..* 或 1..* x 1 或 1..* x 1..* 關聯。

舉個例子:玩家 1..11 x 1 團隊。

這會不會帶來一個實際問題,即無法確定什么是第一:球隊還是球員? 在這個例子中,一支球隊至少需要一名球員才能存在,而一名球員需要球隊才能存在。 我誤解了什么嗎?

嘗試實現它,您將無法實例化 Team,因為您至少需要一名 Player,如果您嘗試實例化 Player,則 Team 將丟失。

1 x 1 的關聯如何可能?

感謝您的時間!

當模型作為 1..11 關系( Team - Player )時,沒有“先行者”。 需要有 11 個Player ,這些可以連接到一個Team 只有當所有的連接都建立起來時,你才有一個合規的模型。 您可以指出玩家通過添加組合來組成團隊。 但通常從編程方面來看,這不會增加太多語義。 無論如何,您都需要擁有實例才能創建連接。 因此Team可能有一個由 11 個Player的數組,並且為了工作,它們中的任何一個都不能為Null

1..1 關系(插頭/插座)也是如此。 只有當它們連接起來時,你才有一個合規的模型。 從建模的角度來看,如果您需要為兩個類之一提供背包,通常會使用 1..1。 然后你用單獨的信息綁定另一個。 然后可以將其與僅對這些內容而不對載體本身感興趣的其他類一起使用。

你是對的。 您必須以某種方式滿足所有約束。 要么立即創建所有內容,要么放松您的約束。 例如,一個團隊仍然可以作為一個沒有任何玩家的團隊存在,但是一個團隊必須存在才能有一個玩家加入。

您的問題“1 x 1 關聯如何可能?” 強制相互反向引用的問題,或者用 DBMS 術語來說,是循環外鍵,這可能確實會在數據管理應用程序或其底層數據庫 (DB) 中創建對象/行創建或更新問題。

有兩種處理方法:1) 至少在一個方向上放寬強制引用約束,2) 允許不需要滿足約束的中間應用程序/數據庫狀態。

1) 雖然我們知道實際上一支球隊總是包含多個球員,但出於實際原因,我們可能會選擇不實施此約束,這樣我們就可以更輕松地創建球隊數據對象(或 DB 行),而無需立即分配球員對象/rows 到它。

2)在我們的應用程序中,我們可以允許一個中間狀態,即一個團隊已經創建,沒有分配任何球員,相應地,在底層數據庫中,我們可以指示事務管理器僅在整個事務完成時檢查外鍵約束(首先創建一個空隊,然后創建11名球員,這樣他們每個人都被分配到一個團隊,這個團隊被分配給他們作為他們的團隊)完成。 這可以通過 SQL 子句DEFERRABLE INITIALLY DEFERRED來實現,請參閱“Deferrable SQL Constraints in Depth”一文的循環外鍵部分。

這要看是什么型號。 UML 模型可能是現實世界的模型,例如,人手與人的手臂具有 1:1 的關系。 這種 1:1 關聯模擬了生物學事實(忽略殘疾)。

UML 模型也可能是應用程序功能的模型。 如果應用程序強制每支球隊有 11 名球員並且每個球員都有一支球隊(例如,他們都是通過填寫帶有“保存”按鈕的表單同時創建的),那么 1:11 關聯正確地模擬了應用程序。

UML 模型也可能是某種編程語言中的類或數據庫中的表的技術模型。 在這種情況下,只有當您的編程語言或數據庫系統允許同時或至少在同一個事務中創建實例時,才可能進行 1:1 關聯。

旁注:在對團隊和球員建模時,您可能會考慮團隊和人員之間的關聯,在團隊方面具有多重性 0..* 和角色名稱“玩家”。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM