我在將我的資料庫表和外鍵轉換為帶有類和關聯的類圖時遇到了困難。
我的問題是：
"在一個組合關系中，子類是否應該總是有一個ID欄位？".
在我的CD中，有2個合成器類。PurchaseItem和PurchaseFinisher，它們復合了Purchase類。PurchaseItem已經從它的表中獲得了一個ID欄位，但是，PurchaseFinisher沒有，因為它是由id_purchase和id_payment_method外鍵過濾的。
預先感謝。
這是我的DB圖：
我看不到Purchase或Product之間的冗余，如你所說。能否請你根據我的DB圖來告訴我？我的表是很好的模型（希望如此）。我的錯誤是在類的定義上。
uj5u.com熱心網友回復：
在類圖中，沒有一個類需要id屬性：每個類實體（又稱物件）都有自己的身份，無論是否有明確的id屬性。
在資料庫中，您當然需要一個明確的 id 屬性，以便在資料庫中的其他物件中唯一地識別該物件并將其找回來。順便說一下，你可以用尾部的{id}來注釋這種屬性。UML并沒有為它定義任何語意，但是一般來說，它的表達能力足以幫助資料庫設計者。
在組合的情況下，主要的問題是一個被組合的物件是否可以很容易地通過其他的方式被識別。有幾種相關的ORM資料庫技術，例如：
- 你可以使用擁有物件的id和另一個屬性，如果這足以識別該元素。這兩個屬性將在資料庫中構成一個復合主鍵。
- 你可以使用一個唯一的id來識別物件（代理主鍵），并使用擁有物件的id作為外鍵。
對于PurchaseItem，您擁有所需的一切，盡管該圖沒有告訴您將使用兩種方法中的哪一種（例如，id是全域唯一的，還是在購買中唯一的？
但是對于PurchaseFinisher來說，不清楚您是否可以唯一地識別一個發生。如果一種支付方式在每次購買時只能使用一次，那就沒問題，因為它可能被用來識別物件。
如果會允許用相同的支付方式以相同的貨幣支付兩次相同的金額（整體價格的一半），你會有無法區分的重復。因此，從資料庫的角度來看，將需要某種識別符號。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/313132.html
標籤：