DB實體關係表的名稱，這是一個好主意嗎？

Question

我不是數據庫設計專家，有我懷疑是新手的問題。如果在另一個論壇（或從一個簡單的參考）得到更好的回答，請讓我知道。

給定一個表「記錄」和一張桌子「藝術家」。這兩個表都有適當定義的主鍵。我們想在這些表格之間表達一種關係。也就是說，藝術家可以有很多錄音，或者沒有錄音。錄音只能有1或0位藝術家。 （我們可以在沒有已知藝術家的情況下進行一些模糊的錄製）。

我認爲解決這個問題是有一個外鍵指向在記錄表的藝術家。該字段可以爲空（錄音沒有藝術家）。此外，我們應該定義級聯刪除，例如，如果刪除一位藝術家，所有具有外部指向該藝術家的錄音現在都有一個空值的外鍵。 [我真的很想在刪除藝術家時離開實際的錄音。我們的真實表格不是「藝術家」和「錄音」，並且沒有藝術家的錄製可以存在]。

然而，這是我的同事們並不怎麼把事情窗口。沒有外鍵列在「錄音」，而是一個額外的表「RecordingArtist_Mapping」有兩列，

RecordingKey ArtistKey

如果一個藝術家（或錄音）被刪除，在這個映射表中的相應條目已移除。我不是說這是錯誤的，只是與我的預期不同。當我有一個有許多關係的人時，我確實看到過這樣的一張桌子，但是沒有我上面描述的關係。

所以，我的問題是：

1. 你聽說過描述關係的這種方式？
2. 是否有這種類型的表的名稱？
3. 這是對關係模型或將與我解釋外鍵的想法更好的好辦法？每個的優點/缺點是什麼？

我的同事們指出，與國外主要思想，你可以有很多的錄音表空的，而這違反了（或許只是在精神？）在關係數據庫理論中的五個範式之一。我在這一方面擺脫了我的聯盟:)是否違反了這些形式之一？哪一個？怎麼樣？ （簡單引用「五種正常形式」的積分:)）。

謝謝您的幫助和指導。

Dave

Answer 1

從標準化理論的角度來看，你在錄音中使用外鍵的解決方案是絕對正確的，它不違反任何顯着的標準形式（最重要的是第三範式和Boyce-Codd標準形式，他們違反了）。

此外，從實際的角度來看，一個部分在概念上更簡單和安全，因爲它通常會減少必須完成的連接數量，所以效率更高。可能認爲，利弊大於利弊。

Answer 2

是的，這是一個可行的設置，這稱爲垂直分區。

基本上，您將artist字段從recording移至另一個表，主鍵參考recording。

的好處是，你不一定要與錄音做查詢檢索的藝術家，其缺點是，如果你仍然有，如果將是一個額外的，因爲有點慢，加盟。

Answer 3

您是否聽說過這種描述關係的方式？

是的，這是一個多對多的關係。錄音可以有多個藝術家。藝術家可以有多個錄音。

這種類型的表有沒有名稱？

我叫他們junction tables。

這是建立關係的好方法，還是用我解釋的外鍵思想更好？每個的優點/缺點是什麼？

在多對多關係中需要聯結表。當你有一對多的關係時，你會在許多表中使用一個外鍵。

至於第4級和第5級數據庫的規範化，這篇來自1982年的文章解釋了不同層次。

在第四範式下，記錄類型不應包含關於實體的兩個或多個獨立的多值事實。

第五正常形式涉及其中的信息可以從更小的碎片的信息，可以用較少的冗餘保持被重建的情況。

我記得用這句話規範化的前3個級別。

我莊嚴宣誓列依賴鍵，整個鍵，不過是關鍵，所以幫我科德。

Answer 4

表面上看，它只是一個交叉表，允許兩個其他表格之間的多對多關係。

當你發現你需要其中的一個，一般是考慮「這是什麼意思表」是個好主意，而「有我囊括了所有的相關屬性」。

在這種情況下，表告訴你，藝術家貢獻以某種方式錄製，那麼你可以考慮「什麼是貢獻的性質」。

可能他們玩某種樂器，或儀器。可能他們是一名指揮。

然後你可能會考慮藝術家以外的人是否對錄音師做出了貢獻？因此，您可以考慮「藝術家」是否是一張好桌子，因爲您可能需要一張表格代表普通人，然後您可以將其中的任何一張與錄音相關聯。例如，你甚至想記錄一個非人 - 倫敦交響樂團的貢獻。

你甚至可以有以多種方式貢獻的實體 - 吉他手，主唱和製作人？您也可以考慮是否應該對捐款進行排名，以便它們按正確的順序排列（這可能是合同問題）。

這正是以書面作品捐款一般建模的方式 - 在這裏是書籍的ONIX元數據架構中使用的代碼貢獻者的名單，作爲說明性的行業例如：https://www.medra.org/stdoc/onix-codelist-17.htm