2014-05-18 56 views
2

嗨我有一個關於我面臨的一些循環關係的問題與我的數據庫設計。我讀了幾個類似的問題,但解決不了我的問題,所以這裏是我的類圖: enter image description here我如何避免我的班級圖中的循環關係

和這裏的邏輯:

  • 一個文件屬於DocumentType (發票,訂單,..)
  • a documentField(date,address,nameClient,...)屬於一個documentType(每個documentType都有它自己的字段
  • 的fieldValue方法是,將被保存在數據庫中的documentfield的值它屬於兩個文件和documentField,the value should be saved according to the fieldType (date , char , long , double...)

然而,從數據庫建築師的角度來看,這個圓形關係是不正確,因爲它可以導致完整性問題:

如果您有任何想法如何處理這個,請歡迎評論。

非常感謝您的幫助。

+0

你能否提供一些具體的例子,爲「誠信問題」?據我所知,如果你沒有在'Document'上施加'1 .. *'基數限制,你可能會過上更簡單的生活。爲什麼不允許沒有實例(尚未)的文檔類型? –

+0

由什麼基數我可以代替1 .. *在這種情況下的基數? – manu

+0

1 .. *是一個錯誤,它是0 .. *不是1 .. *文檔類型和文檔 – manu

回答

1

從關聯這裏的情況比你的其他類似的問題更簡單。很顯然,底部兩個類別描述了抽象文檔結構,而前兩個類別描述了具體文檔

抽象元素不應該依賴於具體的元素,所以只需創建兩個垂直關聯,並指向抽象類。這將整齊地打破循環依賴。

此外,我將進一步完善模型:

  • 文件和fieldValue方法之間的關係應該是一個conposition
  • 爲了讓你的模型實例更靈活(例如 - 爲什麼不允許沒有DocumentField的文檔呢?很顯然你遲早會添加一些字段,但你也許可以先創建一個空文件並保存它)

UPDATE:

enter image description here

+0

你是說我應該將FieldValue與DocumentField和Document與DocumentType關聯?單向關聯並保持DocumentField和DocumentType之間的關聯? – manu

+0

請參閱更新。我會考慮將類DocumentField重命名爲FieldType,它會使情況和定義(類型)和實例之間的分離更加清晰。 – Aleks

+0

我已經有一個類FieldType包含字段的類型,例如:字段日期有一個fieldType:Date,字段地址有一個FieldType字符串等 – manu

0

我實際上看不到你的建模目標。在我看來,您正在將元元素(DocumentType和DocumentField)與元元素(Document和FieldValue)的建模元素實例進行混合。

什麼是Document - > DocumentType關係的語義?這是一個「isA」關係嗎?如果是這樣,爲什麼不使用擴展/泛化(繼承)或接口實現(實現)?

爲什麼你需要反向關係DocumentType - > Document?如果你能避免它,你將不會有循環關係。

[更新] 爲什麼不重命名AbstractDocument中的DocumentType並將其設置爲抽象類。 然後替換從文件關聯的擴展名(總結)到DocumentType 最後創建1個.. *從是AbstractDocument協會本身

[UPDATE2] 同時認爲,根據你的解釋從文檔到DocumentType該協會有不同的sematnics,因此是不同的(另一個協會)從文檔類型到文檔

+0

之間的文檔有一個類型,我們可以處理髮票,訂單等...,我需要一個反比關係因爲文件類型可以有很多文件:例如:類型發票有很多發票作爲文件保存在數據庫中 – manu

+0

看到我的更新請問 – Sindico

+0

問題是隻有文件類型和文件?我想也許FieldValue是問題 – manu