ER圖，這是允許的嗎？

Question

我必須根據關係模式創建一個ER圖。

有一個球員表和區域表。玩家可以在多個區域「生活」，每個區域都由一個或多個玩家擁有。

我已經想出了這個簡單的ER圖，但我不確定每個方法都有關係嗎？

乾杯

Answer 1

是的，這是一個非常好的實體關係圖。 （我沒有迴應是否有意義：您仍然需要解決關係和基數問題。）

使用正確的術語有助於人們準確理解您正在討論的內容以及您正在討論的級別。討論中鬆散的談話會產生更多的數量，並且浪費時間來澄清你的意思。對生產性技術努力不利。

1. 在這個早期階段，這是正常的模型實體和關係（不是屬性），這就是爲什麼它被稱爲ER圖;我們遠不及模擬數據。這些關係是相關的，這就是爲什麼你要詳細說明和評估鑽石和基數的性質。目標是澄清真實的實體，以及彼此之間的關係。多對多關係仍然是關係。 ERD純粹是邏輯的，沒有物理的。

2. 一旦您對此有信心，即您已獲得實體和關係權，您將轉到數據模型（其中包括屬性）。仍然在邏輯級別，n :: n關係保持爲關係。

   • 隨着您的進步，您可能會顯示更多詳細信息，例如每個屬性的域。這就是DataType，但是在邏輯層面，就像術語是Entity = Table和Attribute = Column，Domain = DataType一樣。
     。

3. 當你到達物理層，數據模型有表;列;數據類型。

   • 和n :: n關係表現爲聯想表。
     。
4. 這個想法是，只要你通過規定的步驟工作，在（1）處，鑽石中的內容將決定（暴露）是否需要存儲，並且鑽石因此被提升爲一個實體;否則它仍然是一個關係。

在我給出的關係模式中有一個名爲lives-in的聯結表。但是，我認爲在將關係模式[返回]映射到ER圖時，聯結表成爲關係？

• 關係項是關聯表。

• 是的。如果它是一個純粹的n :: n表（除父表的父表的PK之外只包含兩個FK），那麼在只有邏輯的ERD級別上，它是一個關係。

• 如果它有列以外的兩個FK，它是一個實體。

Answer 2

既然是你必須添加一個結表[玩家]和[區域]之間的許多一對多的關係（呼籲前。[PlayersZones]）。符號本身是正確的（陳符號），但我更喜歡Crow's Foot Notation。

Answer 3

我無法看到您的圖片（已封鎖！），因此我只會嘗試描述「正確」的設計。如果生活在一個區域中的球員並不一定意味着他們擁有它，你應該有四個表：

PLAYER (playerid, <other fields>) 
ZONE (zoneid, <other fields> 
PLAYER_ZONE(playerid, lives_in_zoneid) 
ZONE_OWNER (zoneid, owner_playerid) 

否則三個表就足夠了。