我很難爲我的表關係創建ERD。我有4個表格：電影，ticket_type，工作室和時間表。日程表是一個關係表，其中包含來自其他三個表的主鍵作爲外鍵。問題是我怎麼能在ERD中看到它？像多對多的關係，但有3桌，是否有可能這樣做？數據庫工作正常，當我嘗試創建它，所以我認爲我的概念沒有問題。提前致謝。ERD 3表1關係
編輯：忘記添加ticket_type表的價格和類型如：2D，3D或4D，我創建它是這樣的，以避免冗餘。 還有一個問題，我可以添加另一個領域的關係表？如果我沒有記錯，應該沒問題，但只是爲了確保。
如果schedule是有關係的，將它表示的實體 - 關係圖上，如下所示：
關係由相關實體的密鑰識別。甲表圖使這變得可見：
然而，如果schedule是具有關係設定爲其他3個的實體集的實體，這將ER圖上表示如下：
如果我們每一個映射實體集和關係到它自己的表，我們可以得到如下表圖：
但是，如果我們非規範化的關係表到schedule表（因爲它們都具有相同的主鍵），我們的表圖的變化：
與第一表圖進行比較。雖然這些物理模型非常相似，但它們來自完全不同的概念模型。嚴格地說，我認爲「實體表」和「關係表」對於非規範化的schedule表是不合適的。在網絡數據模型中，我們將其稱爲關聯實體（但與ER模型中的關聯實體不同）。
最後，關係可以有屬性太：
起初我還想過使用第一個圖，但是不應該使用動詞嗎？對於表格圖，我不需要在關係表中添加計劃ID？我的意思是，如果我想使用它，例如交易，那麼我需要使用它來確定我在交易中使用哪個計劃。或者只是在表格圖中對它進行建模，但我仍然需要在真實數據庫中創建它？ – Dizz
實體=名詞，關係=動詞的概念是一種過分簡單化的概念。這種差異是任意的，實體 - 關係模型中的很多複雜性來自於試圖將這些想法分開。 ER中的實體集合還是關係取決於其關鍵，而不取決於它的命名方式。關係模型簡化了事物 - 面向事實的建模基於表格代表謂詞的思想 - 帶有佔位符（用列表示）的句子形式，它可以表達比簡單動詞更復雜的關係。 – reaanb
添加schedule_id也會更改概念和邏輯模型--file_id，ticket_type_id和studio_id將成爲依賴屬性，而不是行列式的一部分。如果沒有schedule_id，可以在事務表中使用組合外鍵，然後計劃在關係中成爲關係（ER稱爲關聯實體）。或者，您可以通過添加schedule_id將日程安排轉換爲實體集，然後在3個外鍵的組合上添加唯一約束。無論您是否實施schedule_id，請確保您的模型符合您的決定。 – reaanb
什麼是你的日程安排表的PK？如果它是FK列的組合，則它是一個關係表，如果它是代理鍵，則它是一個實體表。兩種都可以有其他屬性。 – reaanb
PK是「shedule_id」，它是一個關係表。 – Dizz