2016-05-21 14 views
0

我設定了用戶,國家,州和城市之間的數據庫關係。我認爲這不是一個好的設計,可以改進,因爲是有循環引用改善用戶國家城市之間的關係設計關係數據庫模型?

這將是一個很好的方式來重新設計呢?

enter image description here


UPDATE

隨着我來到一個新設計的答案

enter image description here

+0

是否線性?用戶 - >城市 - >州 - >國家 – lusketeer

+0

@lusketeer,謝謝你的評論。我想到了這一點,但在用戶不住在州或城市的情況下,我會爲他放棄這個國家。 – agusgambina

+0

該更新與我的「如果您正在嘗試執行這兩個操作」部分中的第一個選項非常相似。這當然是一種有效的方法,但是您可能希望通過代碼強制執行某個位置,即location.country_id,locations.state_id和locations.city_id中的某一個爲非null(其他爲空)。這將通過指向例如數據庫來避免數據不一致的可能性。一個與country_id指向的國家/地區不同的國家/地區的城市。或者,您必須立即更新所有這些文件(通過從國家/地區表複製)或根本不需要。 –

回答

0

在你的數據庫設計,關係國家 - 國家 - 城市是沒有必要的。它是多餘的。所以,我的建議是刪除屬性country_id表狀態和state_id表CITIES。

UPDATE:

如果你的設計是做得很好,有很好的事業,確保您提循環引用,那麼就沒有問題,離開這樣的參考。

我假設你有一個循環引用異常,但在閱讀@reaanb後,我同意他的看法。

+0

謝謝@FernandaInesDuran的回答,但如果我在網頁中有3個選擇組合,並且當用戶選擇一個國家時,第二個組合應該只顯示那個國家的狀態,我需要這種關係。 – agusgambina

+0

好吧,在這種情況下,您需要創建只有兩個鍵的其他表:IdCountry和IdState。 (Table Master CountryState) 你覺得怎麼樣?在其他情況下,您將有循環參考。試試這個,稍後再告訴我。 –

+0

感謝您的評論,鮑勃的回答和您的評論,我更新了設計。你怎麼看新的?謝謝 – agusgambina

1

我在努力解決你想達到的目標。我可以想象2件事,但它可能是別的。

第一個是你試圖只代表地理數據(包含在國家中的國家包含的城市)。用戶指向一個城市,然後鏈接到一個國家,然後是一個國家。

第二個是你允許用戶在3個精度級別中的任何一個給出他們的地址。即他們可以說他們居住在哪個城市,或者說哪個州,甚至哪個國家。

如果你只是想做第一個,那麼你應該擺脫用戶 - >州和用戶 - >國家關係,並將用戶鏈接到城市。如果您需要知道用戶在哪個州和/或哪個國家/地區,只需從城市加入州和/或國家。

如果你想做第二個,那麼它看起來很像polymorphic association,所以我建議你閱讀鏈接的文章,看看你認爲哪些最適合你。

如果你正在努力做到這一點,那麼我認爲你有2個選擇。首先是保持架構原樣,但通過業務邏輯強制用戶的地址字段中的一個地址字段非空。這將避免用戶可能指出的可能的問題,例如,一個國家和一個處於不同狀態的城市。

其次是明確說明你有3種類型的地址(所有級別,只是國家+州,只是國家)。就表格而言,這更昂貴,但是使得它更清晰,即約束不會隱藏在業務邏輯中。

對於你有這樣的事情第二個選項:

用戶
@user_id
(刪除地址字段)

國家
@country_id
(等領域)

國家
@state_id
COUNTRY_ID(外鍵)


@city_id
STATE_ID(外鍵)

L1_Address
@ l1_address_id
COUNTRY_ID(外鍵)
address_id(外鍵)

L2_Address
@ l2_address_id
STATE_ID(外鍵)
ADDRESS_ID(外鍵)

L3_Address
@ l3_address_id
city_id(外鍵)
ADDRESS_ID(外鍵)

UserAddress
@user_Id
@address_id

+0

謝謝你的回答。這是非常好的,我面臨的問題是兩種情況,但在同一時間。對於第一種情況,用戶可能住在農場,所以他沒有城市,但他擁有州和國家。另一方面,在向用戶顯示選項之前,我需要與查詢數據庫相關的位置實體。 – agusgambina

+0

感謝您的回答,現在對我來說很清楚,選項就是您所說的。在兩者之間我更喜歡第一個(強制商業邏輯),因爲我認爲問題的根源與阻抗不匹配有關,而我更願意儘可能避免兩個世界糾纏在一起。 – agusgambina

1

您沒有任何循環引用。 (不包括名稱)你的第一個圖中的函數依賴是:

user_id -> city_id 
user_id -> state_id 
user_id -> country_id 
city_id -> state_id 
state_id -> country_id 

的問題是,這組FDS是多餘的,因爲關係組成。例如,user_id -> city_idcity_id -> state_id意味着傳遞依賴關係user_id -> state_id,您也明確記錄。因此,從user_idstate_id有兩條路徑,並且從user_idcountry_id有三條路徑。這是可以理解的,因爲你想支持不同級別的細節。

冗餘數據是數據完整性的風險,所以如果我們可以減輕這種風險,冗餘不會成爲問題。根據您的DBMS,您可能能夠執行包含空值的複合外鍵約束,即(city_id, state_id)users參考(city_id, state_id)cities並讓(state_id, country_id)users參考(state_id, country_id)states。或者,您的DBMS可能支持檢查約束。

+0

謝謝你的解釋,很清楚。 – agusgambina