有一個簡單的問題，但我認爲我正在超越它。我需要製作一個E/R圖表：如何把它放在E/R圖中？
大量的費用是由於每個日曆年。通過銀行轉賬支付的費用必須爲 ，並提及會員編號和適用的會員年度。數據庫應該存儲付款日期 。
我忽略了日曆年，因爲我認爲它與E/R圖無關。我有一個名爲"Members"的實體，我喜歡"Fee"通過*「通過關係支付（鑽石符號）銀行轉賬」*。
現在，我的問題是：應該"member number"和"membership"是否是"fee"實體或"member"實體的一部分？或兩者？因爲我想添加一個新的關係到"fee"給它取名爲「由」，然後點擊「會員編號」和「會員制」，但我不知道這是否是好還是不好。
如何處理最後一句話？ 「數據庫應該存儲付款日期。」？我可以忽略它嗎？
從你的描述我：
Members和PaymentsMembers由member_numberPayments有屬性date，amount和membership_year顯然鑑定，我們還需要：
Payments有一個屬性amount我們該如何識別Payments？列出的屬性沒有組合是我認爲唯一確定的。 A Member可能會在相同的會員年度例如相同的會員年度在同一日期以相同的金額製作兩個相同的Payments。如果他們不小心只支付了年費的一半，那麼第二次付款就可以糾正。
讓我們介紹一個代理鍵：
Payments由payment_id確定我們還需要兩個實體之間的關係設置：
Payment與關聯一個MemberMember可以使多個Payments我們可以把這個信息到ER圖：
導出表圖，陳的原始方法實現每一個實體關係（實體鍵和屬性）和關係關係（關係密鑰（即，相關實體鍵）和關係屬性）成爲獨立的表：
然而，這是常見的做法進行非規範化表具有相同主鍵：
我建議你學習陳的論文The Entity-Relationship Model - Toward a Unified View of Data。科德的紙A Relational Model of Data for Large Shared Databanks提供了寶貴的背景。
美麗。非常感謝你！我有一個問題，但我有關係會員年和會員編號鏈接到「付費」，鑽石。那會不對？ – Siyah
「會員年度」和「會員號碼」是屬性，而不是關係。由於'Paid'和'Payment'具有相同的主鍵，所以屬性/函數依賴'payment_id - > membership_year'可以在任何表/關係中實現。至於'member_number'，它是關係的一個重要組成部分，但IRL模型可能會擴展到捕獲成員名稱，性別，生日等，因此我們需要有一個由'member_number'標識的獨立實體集。 – reaanb
我的意思是屬性，是的，對不起。感謝您的解釋。非常感謝！ – Siyah
Member_number會隨着時間變化而變化，還是會員的唯一標識符（PK）？ – etsa
它沒有提到任何有關更改的內容，所以我認爲它是主鍵。 – Siyah