我正在創建一個數據庫作爲一個類的最終項目。這是我第一次創建數據庫，並遇到一些麻煩。ERD關係在訪問數據庫中沒有意義
現在我爲此所做的業務並沒有真正的業務規則，至少我可以從三位在那裏工作的經理中獲得任何業務規則。所以我想出了基於過他們做了什麼，我知道從工作有：
這就是我如何基於這個ERD，但實際上創建這些關係的數據庫時，它不起作用。我想弄清楚如何糾正這個ERD，以便數據庫中的關係是正確的。當我創建數據庫時，工資，現金責任和時鐘表都有員工ID作爲外鍵，而數據庫爲此目的正常工作，而不是具有三個主鍵的員工表。
這裏是將ERD
一些評論/問題的鏈接：
如果你打算把工資在一個單獨的表，那麼你不妨讓它1:many。即將EmpID放入Wages並從Employee移除WageID。這可以讓你跟蹤每個員工的多個工資，這是現實，因爲工資通常會發生變化。您可以獲得工資申請/結束日期（即Employee1234在2011年支付10k $，在2012年支付15k $）。因爲它現在與1：1的關係，你可能會在一個表中。我不是你的TimeClock結構。就像你寫的一樣，員工只能一次進入/退出。他們肯定會出現在星期二的工作。
CashAccountability中的邏輯相同。每個員工只能負責任地進行一次套現。我認爲你正在尋找一個多對多的關係，你應該研究如何實現這種數據結構。基本上，它允許將CashAccountability鏈接到多個員工，並允許員工鏈接到多個CashAccountability。
你有一種指定部門主管的方法，但是沒有辦法顯示員工是誰領導的。即與下屬的部門沒有關聯。
編輯：
我現在看到你的問題，爲什麼Employee表不具有3列主鍵。主鍵就是你想要的任何東西，但將與員工無關的事情作爲員工表中的人蔘與並不合乎邏輯，特別是不能將其作爲識別該人員的主鍵。 WageID，TimeID和CashID與員工本身無關，因此他們不應該在員工表中，當然也不在主鍵中。
工作的方式是，工資只有在最低工資增長時纔會改變，這就是爲什麼這樣。 EmpID在訪問數據庫的工資表中，我只是在ERD中遇到了麻煩。此外，即使有部門主管職銜，實際上也沒有下屬領導。這就是爲什麼沒有鏈接。 @Brad – CoolTom
'當最低工資增加時，工資不會改變[除外]。所以他們可以改變？但是，如果您希望每個員工只有一個工資，則將其放入員工表中。如果是這種情況，那麼把它放在一個單獨的表格中是毫無意義的。這是不必要的加入。 – Brad
我改變了關係。謝謝你，我正在閱讀與時鐘表之間的關係，例如一個員工每天一次計時，因此他們只在表格中有一行，但作爲員工在課程中多次計時的時間，的就業。工資和時間時鐘表現在具有EmpId作爲外鍵和零對多關係。 @Brad – CoolTom
@Brad不，它不。這隻包含數據庫設計，不包含任何代碼。這是Code Review的主題。爲了避免在多個網站上關閉的問題，請標記使用自定義標誌進行遷移（以便管理員可以拒絕或不接受）或投票結束*，因爲它與SO沒有關係，不是因爲您認爲它屬於其他地方* –
@SimonAndréForsberg對不起，我只是做了一個代碼審查的快速搜索，發現很多問題尋求審查包括ERD的數據庫設計。信息技術看起來並不重要，因爲這個概念是相同的，因此將ERD表示爲圖片而不是CREATE語句。 – Brad
@Brad在[codereview.se]，我們*評論**代碼***，因此任何沒有任何代碼的問題都不可能成爲話題。這是一個非首發。 – nhgrif