2017-05-24 27 views

回答

1

Boyce-Codd要求在主鍵之間使用3 NF(正常形式)並且不存在依賴關係(功能依賴關係-FD)的表。你首先需要評估1NF,2NF,3NF,最後是3FN Boyce-Codd。

對於1NF一些規則必須被應用

1NF:一列

1NF沒有多值值:不重複的行

還有一些其他的規則,但對於不相關這個例子。

在您的表格中沒有重複的行。每個單元格只有一個值。該表格處於第一種標準格式。不需要轉換。

2NF:部分PK和其他無PK列之間沒有關係。例如,如果一個PK有兩列,我們必須檢查PK的一列和其他列不在Pk集合中的功能依賴關係。

如果主鍵只有一列(不是這種情況),表格在2NF中。因爲主鍵有兩列(屬性),你必須檢查一列,這不是與列PK的部分是有關(函數依賴),這不是一個PK

檢查FD的局部PK Stud_id

的一部分

Stud_id - > Stud姓名?如果我知道stud_id字段,我也知道學生的名字?對於表中的值,這是正確的。對於Stud_id列的給定值,只有一個值是針對stud_name確定的

Stud_id - >課程名稱?這個功能依賴關係不是真的。如果我得到Stud_id 224不止一個不同的值與這個值相關聯:Intro CIS,Database Mgt ...

Stud_id - >教練?這種功能依賴也是錯誤的。如果我得到Stud_id 224不止一個不同的教練確定:(格林,洪,Purao)

Stud_id - > Office?這個函數依賴是錯誤的。如果我得到Stud_id 224多個不同的辦公室確定:(CBA001,CBA908,CBA700)

Stud_id - >房?這個函數依賴是錯誤的。如果我得到Stud_id 224不止一個不同的房間確定

Stud_id - >?這個函數依賴是錯誤的。對於值224是對的,但對於值stud_id 351,有兩個可能值(3,5)

主鍵列course_id需要相同的推理。

檢查局部PK COURSE_ID

COURSE_ID - >學生姓名? FALSE(沒有功能依賴關係(FD))

Course_id - > course Name? TRUE(FD)

Course_id - >教練? TRUE(FD)

Course_id - > office? TRUE(FD)

Course_id - > room? TRUE(FD)

Course_id - > credit? TRUE(FD)

對於2NF一個表中的每個FD需要

STUDENT {Stud_ID(PK),Stud_Name}

COURSE-NAME {COURSE_ID(PK),COURSE_NAME,指導員,辦公室,房間,信貸}

學生課程 {Stud_ID(PK),COURSE_ID(PK)}

在P當我們檢查FD時,每個新生成的表的K始終是 - >左側的列。

對於每個新表,我們都必須檢查它們是否在2NF(要歸檔2NF,必須先檢查1FN)。因爲所有的主鍵對於STUDENT和COURSE表都是簡單的(一列),而在STUDENT-COURSE中所有的列都是PK,所有的表都在2NF;我們只需要刪除重複的行(如果有的話)。

要歸檔Boyce-Codd,我們需要檢查3NF。該表格檢查不是PK或候選的列之間的依賴關係。

課程 {COURSE_ID(PK),課程名稱,教師,辦公室,房間,信貸}

課程表已經重複的行。我們需要先刪除它們。當這個過程完成時,表格在2NF,,因爲所有具有簡單PK(只有一列作爲PK)的表格都在2NF中。因爲它有多個不是PK的列,我們需要檢查它們之間是否有關係(FD)。

course_name;刪除重複的行後,此列是候選鍵。我們不必檢查這一欄。

教師列必須檢查,因爲這不是PK的一部分,也不是候選鍵。

教練 - >課程名稱:NO FD

教練 - >房間:NO FD

教練 - >辦公:FD

教練 - >信用:NO FD

由於instr之間存在FD uctor和office,必須創建一個新表來存儲這些值。

講師OFFICE {教練(PK),辦公}

課程 {COURSE_ID(PK),課程名稱,講師,室,信貸}

講師OFFICE表只有一個PK列,另一列不是PK。它採用Boyce-Codd形式。

對於新表COURSE,我們必須檢查沒有PK列之間沒有FD。

室溫 - >信用:DF

COURSE {COURSE_ID(PK),課程名稱,講師室}

ROOM {室(PK),信用}

學生課程:它只有PK欄。它在3FN。 (只刪除重複行以存檔1NF)

學生:只有一列不是PK(Stud_Name)。它在3FN,因爲只有一列。。 (僅刪除重複的行存檔1NF)

這個過程之後,我們已經與他們列如下表:

學生 {Stud_ID(PK),Stud_Name}:簡單的PK,只有一個屬性不PK => 3FN博伊斯-科德

ROOM {室(PK),信用}

講師OFFICE {指導員(PK),辦公}

STUDENT-COURSE {Stud_ID(PK),COURSE_ID(PK)}

COURSE {COURSE_ID(PK),課程名稱(CC),教練,室}(CC =候選鍵)

指導員 - >房間:否FD 教室 - >教員:FD

必須爲房間教師列的相關性生成一個新表。我們在桌子房間的房間專欄。我們必須在此表中添加新的專欄指導員。

ROOM {室(PK),信用卡,指導員}

COURSE {COURSE_ID(PK),課程名稱(CC),室溫}

當前表:

STUDENT {Stud_ID(PK),Stud_Name}:簡單的PK,只有一個屬性不是PK => 3FN Boyce-Codd

ROOM {室(PK),信用卡,講師}:簡單PK和信用NOT DF與講師和指導員NOT DF與信用=> 3NF博伊斯-科德

講師OFFICE {指導員(PK),辦公室}:簡單PK,只有一個屬性不PK => 3FN博伊斯-科德

COURSE {COURSE_ID(PK),課程名稱(CC),室溫}:一列PK,一個CC,和一列,也不PK and nor CC => 3FN Boyce-Codd

STUDENT-COURSE {Stud_ID(PK),Course_ID(PK)}

要實現3NF Boyce-Codd,我們必須檢查PK列之間沒有功能依賴關係。僅與複合PK表必須檢查:在我們的例子:

STUDENT-COURSE {Stud_ID(PK),COURSE_ID(PK)}

Stud_ID - > COURSE_ID:NO FD

Couse_ID - > Stud_ID:NO FD

此表位於3NF Boyce-Codd。

如果沒有失誤與FD的最後一組表是:

學生 {Stud_ID(PK),Stud_Name}

ROOM {房(PK),信貸,教練}

INSTRUCTOR-OFFICE {指導員(PK),辦公室}

課程 {COURSE_ID(PK),課程名稱(CC),室溫}

STUDENT-COURSE {Stud_ID(PK),COURSE_ID(PK)}

與博伊斯-科德過程的想法是刪除數據冗餘表。目前的冗餘只適用於關係公寓。 4FN和5FN也被定義,但通常不適用。

在每個新表中保留值以檢查FD是一個好主意:更多的工作,但更可靠。

我希望這有助於理解過程!

Miquel

+0

標準的BCNF算法不需要任何事先的NF。 (標準3NF/EKNF算法也不是。)歸一化通常不涉及通過較低的NF。事實上,這可以從最終結果中消除更好的高NF設計。 – philipxy

+0

PS「1NF」用於表示很多事情,通常模糊不清。請參閱[this](https://stackoverflow.com/a/40640962/3404097)和[this](https://stackoverflow.com/a/43321127/3404097)。 – philipxy

+0

你的語言不清楚和錯誤。 (無論如何,這個問題太廣泛了。)例如,「Boyce-Codd需要3 NF(正常形式)表,並且主鍵之間沒有依賴關係(功能依賴關係-FD)」。例如「部分PK與其他無PK列之間沒有關係」。請用足夠的單詞說出你的意思,並找出實際的定義,而不是僅僅使用一些相關詞彙來表達模糊的東西。一門課程的PS學分不取決於教授的房間。如果您被告知專門爲此設計了FD,您只能從一個例子中推斷FD。 – philipxy