Database System - work 9 Normal Form 1NF , 2NF , 3NF

*a prime attribute of R if it is a member of some candidate key of R

1/4/2561 update

First Normal Form - 1NF

- ใน 1 Attribute ห้าม มี หลายค่า ห้ามเป็น set ห้ามเป็น tuple

ตัวอย่างปัญหา 1

ไม่ใช่ 1 NF เพราะ มี SET ของค่าใน Dlocations row 1

 งั้นก็แยกมันออกมาสิ ? แต่หากทำแบบนั้นก็จะเกิดการซ้ำซ้อนของข้อมูลใน Attribute อื่นที่ไม่ใช่ Dlocation ดังภาพ [ row 1 - 3 ]

หรือ จะแยก Dlocation เป็น Dlocation 1 2 3 ?  แต่ก็เท่ากับว่าเราจะไปทำการ Fix ให้มัน ต้องมีไม่เกิน 3 ที่  เท่านั้นนะสิ ? แล้ว ตัวที่ มีมากกว่า 3 ที่หรือน้อยกว่าจะจัดการยัง ไง ?

ตัวอย่างปัญหา 2

Pnumber และ Hour มากกว่า 1 ค่า

ทำการแยกออกมาเป็น2 Table แทน  โดย Ssn ของEMP_PROJ2 คาดว่าน่าจะ เป็น FK ชี้ไป EMP_PROJ1 และ ใน EMP_PROJ1 นั้นจะไม่มีการที่ ใน attribute ใดๆมีค่ามากกว่า 1 อีกแล้ว จึงตรงตามเงื่อนไข และใน EMP_PROJ2 นั้น ก็ เช่นกัน เนื่องจากใช้ { Ssn , Pnumber } เป็น PK  จึงจะไม่มีการที่ ใน attribute ใดๆมีค่ามากกว่า 1 อีกแล้ว  เพราะใน ผู้ถูกจ้าง และ เบอร์ นี้ ถูกโทรนั้นจะถูกบันทึกใน row เดียวกัน  หากเปลี่ยนเบอร์ ก็จะเป็นอีก row นึงไป

Second Normal Form - 2NF

 - Based on concept of full functional dependency

full functional dependency - >

X → Y จะ  full functional dependency  ก็ต่อเมื่อ หากมีการนำ Attribute ใน X ใดๆออกไป จะไม่เป็น dependency   หรือ  X → Y อีกต่อไป ( X → Y หมายถึง  Y ขึ้นอยู่กับ X หรือ หาก รู้ X จะได้ค่า Y ที่แน่นอนออกมา หรือมีเพียงชุดคำตอบเดียวเท่านั้น )

เช่น

{Ssn, Pnumber} → Hours

ใน ผู้ใช้งาน 1 คนใน เบอร์ หนึ่งๆ นั้นจะมีชั่วโมงการใช้งานได้ค่าเดียว

Neither 
Ssn → Hours
nor
Pnumber → Hours
holds

หากแยกออกมา เป็นดังข้างบน จะไม่ใช่ dependency อีกต่อไป เพราะ ใน Ssn 1 คนอาจมีได้หลายเบอร์ จึงไม่สามารถ ระบุ ชั่วโมงที่แน่นอนได้ และ เบอร์ ใดๆ อาจจะถูกใช้โดยหลายคนได้ จึงไม่สามารถ ระบุ ชั่วโมงการใช้งานหรือถูกโทรได้อย่างแน่นอนเช่นกัน

ดังนั้น เมื่อแยกไม่ได้  {Ssn, Pnumber} → Hours
จึงเป็น  {Ssn, Pnumber} → Hours

---------------------------------------

A relation schema R is in 2NF if  every non-prime attribute A in R
is fully functionally dependent on the  primary key of R

หาก ทุกๆ ตัวที่ไม่ใช่ prime attribute ในความสัมพันธ์ใดๆ เป็น fully funtionally dependent กับ primary key ก็จะเป็น 2 NF

{Ssn, Pnumber} → Hours

ในที่นี้ Hours ไม่เป็น prime attribute  และ มีความสัมพันธ์แบบ  fully funtionally dependent  จึงเป็น 2NF

------------------------------------------


ตัวอย่างปัญหา 1

เริ่มจากการไล่เช็คไปเรื่อยๆ { Ssn , Pnumber } --> ?  โดย ? หมายถึง Hours, Ename, Pname , Plocation ไล่ไปจนครบ

ไม่ใช่ 2NF !! เพราะ ใน FD 2 นั้นจะเห็นได้ว่าใช้ แค่ Ssn --> Ename ได้ ไม่จำเป็นต้องเป็น { Ssn, Pnumber } --> Ename อีกต่อไปแล้ว จึงหมายความว่ามันไม่ใช่
fully functionally dependent เมื่อไม่ใช่ fully functionally dependent ก็ไม่เป็น 2NF อีกต่อไป รวมถึง FD3 ด้วยเหตุผลในทำนองเดียวกัน

แล้วจะแก้ยังไง ?

ทำการแยก ส่วนที่ไม่ใช่   fully functionally dependent  ออกไปเป็น table ใหม่ แยกกัน ซะ แล้วทั้งหมดก็จะเป็น 2NF !

ตัวอย่างปัญหา 2

เนื่องจากใน Text book ไม่แสดงตัวอย่างให้เห็นมากกว่า1 ปัญหา ดังนั้นจึงไปหา จากข้องนอก Text book มาเสริม
http://www.gitta.info/LogicModelin/en/html/DataConsiten_Norm2NF.html

จากภาพ ความสัมพันธ์ในตอนแรกนั้น 

IDSt, IDProf --> Grade ---(3)

IDProf --> ProfessorName ---(1)

IDSt --> StudentName  ---(2)

จะเห็นได้ว่า (1)(2) นั้น จะมี มีตัว สำหรับอ้างไปยัง ผลลัพธ์แค่ตัวเดียวในขณะที่ Grade นั้นจำเป็นต้องใช้ 2 ตัว เลย จึงกล่าวได้ว่า  IDSt, IDProf ยังไม่เป็น

fully functionally dependent 

จึงยังไม่ใช่ 2NF ดังนั้น จึงแยกเป็นหลาย ตารางได้ตามภาพ โดยแยก ตาม dependent (1)(2)(3) ออกมาได้ 3 ตารางดังภาพ

Third Normal Form - 3NF

- Based on concept of transitive dependency  a relation schema R is in 3NF if it satisfies  2NF and   no non-prime attribute of R is transitively

dependent on the primary key

เงื่อนไขคือ เป็น 2NF และ  ไม่มี  non-prime attribute ที่เป็น  transitively

dependent กับ primary key หรือ ก็คือ มี ค่าที่ไม่ใช่ PK ที่ สามารถ กำหนด ค่าของ Attribute อื่นได้ หรือช่วยในการระบุได้

ตัวอย่างปัญหา 1

จากภาพ จะเห็นได้ว่า ในตารางนี้ PK หลัก ก็คือ Ssn ซึ่งมี ความสัมพัน dependent 
ที่ { Ssn } ---> ? โดยให้ ? เป็น Attribute อื่นได้ทุกตัว เช่น Ename,Dnumber, Dname เป็นต้น ซึ่งแน่นอนว่า ในเมื่อมี PK ตัวเดียว ย่อม ต้องเป็น 2NF แน่ๆ ดังนั้นเงื่อนไข แรก ผ่าน ต่อมา คือเงื่อนไขที่ว่า ต้องไม่มี ? ใดๆ ที่สามารถ กำหนด ? ตัวอื่นๆได้ แต่ในที่นี้ นั้น ปรากฏ ว่า Dnumber นั้นมีความสามารถ ที่กำหนดค่าของ Dname , Dmgr_ssn ได้ ( เนื่องจาก Dnumber จะหมายถึง Department ใดๆที่มี ชื่อเพียงชื่อเดียวและ มี department_ssn เพียงหนึ่งเดียวเท่านั้น ได้ )

จึงทำให้ไม่เข้าเงื่อนไข 3NF โดยปริยาย

แก้โดย

แยกมันออกมาจากกันซะ ก็เป็นอันจบ โดยยังเหลือ Dnumber ที่สามารถกำหนดค่า
ดังนี้ได้เอาไว้
 Ssn --> Dnumber
และในอีก ตารางนึงก็ มี ตัวที่ใช้ชี้ได้ กับ ตัวที่ถูกชี้ได้ เอาไว้ด้วยกันซะ
Dnumber --->  Dname หรือ Dmgr_ssn

ตัวอย่างปัญหา 2

เงื่อนไขแรกคือ 2NF?
มี PK ตัวเดียว = 2NF เงื่อนไขแรก ผ่าน เงื่อนไข ต่อไป transitive dependency ?
ในภาพ FD แรกที FD3 , FD 4  พบปัญหา ?
County_name สามารถกำหนดค่าของ Tax_Rate ได้ เพราะ ในเมืองเดียวกันย่อมมีภาษีเท่ากัน

แยกออกมาก่อน

 เมื่อแยกออกไปแล้ว ก็มาดู FD4 ก็พบว่า ในพื้นที่หนึ่งๆ ย่อมมีราคาเดียว เช่นกัน ดังนั้น Area สามารถกำหนด Price ได้โดยไม่ต้องพึ่ง Property_id

และที่นี้ ก็เท่ากับว่า เงื่อนไข ทุกอย่างครบถ้วนแล้ว เพราะไม่สามารถ แยก  Attribute ใดๆ ออกไปได้แล้ว หรือไม่มี Attribute ตัวใดที่สามารถอ้างอิงไปยัง non-prime key ได้แล้ว

ก็เป็นอันเสร็จ


----------

ref - fundamentals of database systems 6th edition elmasri navathe
http://iips.icci.edu.iq/images/exam/databases-ramaz.pdf