哪個是識別或非識別關係中的子表？

Question

在表格之間的識別和非識別關係的情況下，MySQL的文檔將很多表格稱爲父表格和子表格。

你如何確定哪個表是父表和哪個表是子表？

Answer 1

沒有嚴格的規則來決定關係中表的作用。事實上，這就是關係模型的美麗和創新：沒有層次結構。

通常，如果從某個表到另一個表存在硬依賴關係，則子表或父父角色由表的語義決定。例如：在order,order_details關係中，很明顯order是父項，order_details是子項。

在其他情況下，還不清楚關係在關係中扮演什麼角色。例如：orders和customers的關係。如果您執行查詢以獲得屬於某個customer的所有orders，則父代可能是customers和orders是兒童。但是，您也可以執行查詢以獲取特定order的所有貨件信息（存儲在customers關係中），在這種情況下，您可能會認爲order是父項，而customers是此查詢中的子項。

正如我之前所說的，當關系模型在70年代後期發明時，它的主要優點之一就是能夠查看相關數據而不考慮它們的依賴關係。

Answer 2

一個偉大的定義提出here：

一個識別關係是當行的一個子 表的存在依賴於父表中的一行。 （...）正式地，「正確的」 這樣做的方法是使外鍵[即父母的主鍵]部分 孩子的主鍵。

Answer 3

一個子表（AKA weak entity）是一個表，它的主鍵屬性上的另一個表依賴，因而識別的子表或部分地由表中的行識別這取決於（父）。沒有父表中的對應行時，子表中的行不能存在。

爲了說明，我們來看一個我們都很熟悉的簡單且完全相關的例子：父母和子女在家庭背景下。我們可以模擬出與表這種關係像這樣：

在上面的模型中，Parents表的每一行是由SSN唯一標識。SSN是每個父母的內在和唯一屬性，因此它是一個獨立或「強壯」的實體，因爲它不依賴於另一個表來定義其身份。

兒童然而，需要父以存在（在Parents表Parent_SSN必須參照現有SSN）。

請注意Children表中的複合主鍵（Parent_SSN, Name）。這意味着孩子們唯一標識由組合Parent_SSN和Name。您無法僅根據Name字段查詢單個孩子，因爲多個父母可能有名稱相同的孩子。同樣，您不能僅基於Parent_SSN字段查詢單個子項，因爲一個父項可能有許多子項。考慮到這一點，兒童部分由其父母認定，因此確定的關係。

但SSN不能讓兒童唯一識別嗎？當然，爲什麼是。讓我們繼續前進，並調整我們的模型，包括：

在這個版本的車型，注意我們已經介紹了SSN領域Children。兒童的獨特身份現在由他們自己固有的和獨特的SSN定義。他們的身份不再取決於Parents表中的。雖然Parent_SSN領域仍引用Parents表的SSN，它在孩子的獨特的身份沒有參與，因此父母有非識別關係到他們的孩子，而現在這兩個表可以考慮「強大」的獨立實體。

順便說一句，這個版本的模型具有在第一幾個優點：

• 一位家長現在可以有兩個或兩個以上的孩子使用相同的名稱，而在以前的模型中entity integrity約束將不允許這樣做。
• 您可以允許Parent_SSN字段包含NULL來說明您有關於孩子的數據的事件，但不知道他/她的父母是誰。

在上述兩種模式中，Parents表被認爲是Children表的父表。然而，在非識別像第二種模式關係，Parents只有外鍵Parent_SSN因爲Parent_SSN引用的背景下，父表/在Parents表上SSN取決於，但不有任何部分在確定兒童的真實身份。

爲了說明爲什麼決定哪些表的父/子表，考慮下面的例子涉及循環依賴時環境是很重要的：

在這個例子中，員工和部門是唯一的標識自己自己的屬性，並不從其他表中導出其身份的任何部分。

在這裏，我們有兩個非識別關係：僱員工程（在Employee表DeptNo）一個部門，一個部門由員工（ManagerSSN在Department表）進行管理。哪一個是父表？ ...孩子桌子？

這取決於上下文 - 您正在談論哪種外鍵關係？由於DeptNo是引用/依賴在Department表中的表DeptNo上表部門DeptNo上下文中的部門表將被視爲父表。

然而，僱員表將被認爲是在ManagerSSN在Department表上下文父表，因爲ManagerSSN是引用/依賴上Employee表。