設計循環引用
所以我需要設計數據庫招聘方案。有7個表包括:
- 申請人:對申請人的數據
- 位置:位置數據的
- 技巧:對於技術數據
- 申請人技巧:應聘者技能列表
- 崗位技能:職位所需技能列表
- 職位空缺:職位空缺列表
- 申請:申請數據列表
我被告知我的設計有循環引用。我搜索了一些設計實例,但沒有找到適合我的案例。所有表格都是必需的,不能刪除。我無法想出其他想法。
我該如何擺脫循環引用?謝謝。
設計循環引用
所以我需要設計數據庫招聘方案。有7個表包括:
我被告知我的設計有循環引用。我搜索了一些設計實例,但沒有找到適合我的案例。所有表格都是必需的,不能刪除。我無法想出其他想法。
我該如何擺脫循環引用?謝謝。
這裏沒有任何循環,您可能遇到的唯一明顯問題是不執行替代鍵,在圖中這些通常標記爲AK
- 使用UNIQUE NOT NULL
來創建它們。
這裏是三個表的候選鍵。
ApplicantSkill {APPLICANT_ID, SKILL_ID, APPLICANT_SKILL_ID}
KEY {APPLICANT_ID, SKILL_ID}
KEY {APPLICANT_SKILL_ID}
PositionSkill {POSITION_ID, SKILL_ID, POSITION_SKILL_ID}
KEY {POSITION_ID, SKILL_ID}
KEY {POSITION_SKILL_ID}
Application {APPLICANT_ID, VACANCY_ID, APPLICATION_ID}
KEY {APPLICANT_ID, VACANCY_ID}
KEY {APPLICATION_ID}
你介紹了代理鍵(額外_ID),並選擇了他們作爲主要爲這些表, 但省略其他(AK) - 非常容易出錯,易造成重複,冗餘 和矛盾。
這JOB_TITLE_ID
應該從Application
被刪除,它看起來像 有依賴{POSITION_ID} --> {JOB_TITLE_ID}
所以它可能無法同步,創造矛盾。
你好,謝謝你指出這一點!我修正了他們:) – arukasa
正如你在這裏介紹的那樣,你的設計確實有而不是有任何循環引用。
所以你沒有什麼可以解決的。 (注意:我忽略了「Jobtitle ID」這個東西,因爲相關的表並沒有出現在你的圖表中,但是看起來好像這張表並不依賴於這些)。
你擔心什麼?技能表在你的模型之上,並且它是不確定的。
1.在評論中,你說你說「Jobtitle表只涉及位置表」。應用程序也是嗎?請包括所有參考表格。 2.位置JobtitleID是否也必須出現在應用程序中?如果是這樣,你已經忽略了FK。應用程序JobtitleID是否也必須出現在Position中?如果是這樣,你已經忽略了FK。這種FK影響圓度。 – philipxy