許多一對多的關係ERD

房地產公司有幾個建築，由一個或多個經理管理的每個建築物，管理者可以訪問的一個或多個建築物。所以，管理者與建築物之間存在着多對多的關係。它必須是一個表，如權限擺脫多對多的關係。

請幫我弄明白，數據庫的最佳設計是什麼？

我想出了兩個候選人圖，哪一個更好？如果他們都不好，我應該改變什麼？

http://i.stack.imgur.com/Z0l6h.png
http://i.stack.imgur.com/Dg5Sv.png

真誠

2014-06-09 koryakinp

也許是因爲我不是一個「紳士」，但我很難理解你想** ** Permissions **表做什麼。您的ERD似乎對您在數據庫中管理的多對多關係知之甚少。你想要**經理**擁有許多**建築物** _through_ **權限**？你的第二個ERD顯示了什麼？那些應該是FK的，而不是PK的 – eriese

@eriese我很抱歉。據維基稱，「大多數數據庫管理系統只支持一對多關係」。這就是爲什麼我試圖擺脫建築和經理之間的多對多的原因。是的，我想要管理哪些管理員通過權限表管理哪些建築物。 Permisions表中的BuildingID和ManagerID是一個組合PK。 – koryakinp

你有沒有想要使用什麼語言/框架和數據庫來構建它？我習慣於使用Postgresql的Ruby on Rails，它使用activerecord進行真正簡單的關係管理並處理許多事情。 – eriese

的second picture似乎最接近

我建議走動一點的盒子，以顯示層次結構。把公司放在首位，然後在下一排，左邊的經理，右邊的建築和這兩者之間的權限。

來源

2014-06-09 18:08:12 IanH

ER圖用於兩個不同的目的。一個目的是說明主題實體，以及它們之間的關係，正如主題專家所理解的那樣。這被稱爲數據的概念模型。

另一個目的是說明一個建議的數據庫設計，其中的關係不僅被表達，而且還以某種方式實現。如果設計是關係型的（通常是這樣），那麼通過創建一箇中間表來表達多對多的關係。這被稱爲數據的物理模型（在某些文獻中稱爲邏輯模型）。這是你在第二個圖表中完成的。

通過消除名爲「permissions」的框，並在連接管理者和建築物的線的兩端放置一個烏鴉腳，可以清理您的第一個圖。

現在回到你的問題：哪一個是「更好」？這取決於。有時，概念圖更適合與最終利益相關者討論主題：非技術管理人員始終處理數據，可能被稱爲「主題專家」。

在討論數據架構師和程序員之間的建議設計時，物理圖通常會更好。它不僅解釋了數據如何在概念上起作用，還解釋瞭如何構建數據庫。這種細節被概念模型掩蓋了。

因此，您最終可能會得到兩個圖表，並根據您的受衆使用適當的圖表。

來源

2014-06-14 11:34:06

許多一對多的關係ERD

回答

相關問題