หน่วยที่ 2

การออกแบบฐานข้อมูลและตาราง

    คำศัพท์ที่ใช้กับโมเดลเชิงสัมพันธ์

        ก่อนที่จะศึกษาเรื่องการออกแบบฐานข้อมูลและตาราง ควรต้องรู้จักกับความหมายของคำศัพท์ที่มีการบัญญัติขึ้นใช้กับโมเดลแบบนี้ เพื่อเป็นพื้นฐานในการออกแบบฐานข้อมูลต่อไป

    อี-อาร์โมเดล 

        อี-อาร์โมเดลเป็นแบบจำลองข้อมูล ซึ่งแสดงถึงโครงสร้างของฐานข้อมูลที่เป็นอิสระจากซอฟต์แวร์ที่จะใช้ในการ พัฒนาฐานข้อมูล รวมทั้งรายละเอียดและความสัมพ้นธ์ระหว่างข้อมูลในระบบในลักษณะที่เป็นภาพรวม ทำให้เป็นประโยชน์อย่างมากต่อการรวบรวมและวิเคราะห์รายละเอียด ตลอดจนความสัมพันธ์ของข้อมูลต่างๆ โดยอี-อาร์โมเดลมีการใช้สัญลักษณ์ต่างๆที่เรียกว่า Entity Relationship Diagram หรือ อี-อาร์ไดอะแกรม แทนรูปแบบของข้อมูลเชิงตรรกะขององค์กร จึงทำให้บุคคลากรที่เกี่ยวช้องกับระบบฐานข้อมูลสามารถเข้าใจลักษณะของข้อมูล และความสัมพันธ์ระหว่างข้อมูลได้ง่ายและถูกต้องตรงกัน ระบบที่ได้รับการออกแบบจึงมีความถูกต้องและสอดคล้องกับวัตถุประสงค์ของ องค์กร

    อี-อาร์โมเดล ประกอบด้วย 3 ส่วน คือ เอนทิตี้,Attribute,ความสัมพันธ์

    1.เอนทิตี้

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

        - บุคคล     ได้แก่ พนักงาน ผู้ป่วย และ นักศึกษา เป็นต้น

        - สถานที่    ได้แก่ เขต จังหวัด และ ภาค เป็นต้น

        - วัตถุ        ได้แก่ รถยนต์ อาคาร และ เครื่องจักร เป็นต้น

        - เหตุการณ์ ได้แก่ การลงทะเบียนเรียน ความชำนาญ เป็นต้น

      ในอี-อาร์ไดอะแกรม ใช้สัญลักษณ์รูสี่เหลี่ยมผืนผ้า แทนหนึ่งเอนทิตี้โดยมีชื่อเอนทิตี้นั้นกำกับอยู่ภายใน

เอนทิตี้สามารถจำแนกได้ 2 ประเภท คือ เอนทิตี้ปกติ(Regular Entity) และ เอนทิตี้อ่อนแอ (Weak Entity)

        1.1 เอนทิตี้ปกติ

            เอนทิตี้ปกติ หมายถึง เอนทิตี้ที่สนใจและต้องการจับเก็บข้อมูลที่เกี่ยวข้องไว้ในระบบฐานข้อมูล การคงอยู่ของเอนทิตี้ไม่เกี่ยวข้องกับเอนทิตี้อื่น โดยเอนทิตี้นี้สามารถมีคุณสมบัติ Identity ได้ในตัวเอง ในอี-อาร์ไดอะแกรมสัญลักษณ์ที่ใช้แทนเอนทิตี้ปกติเป็นเช่นเดียวกับเอนทิตี้ ดังนั้น เมื่อมีกล่าวถึงเอนทิตี้ใดๆโดยไม่มีการระบุรายละเอียดอื่นจึงหมายถึงเอนทิ ตี้ปกตินั่นเอง

        1.2 เอนทิตี้อ่อนแอ

            เอนทิตี้อ่อนแอ หมายถึง เอนทิตี้ที่มีการคงอยู่เกี่ยวข้องกับเอนทิตี้อื่นในระบบฐานข้อมูล ดดยเอนทิตี้อื่นที่มีความสัมพันธ์กับเอนทิตี้นี้เรียกว่า Parent Entity หรืออาจกล่าวได้ว่าเอนทิตี้อ่อนแอจะไม่มีความหมายหรือไม่สามารถปรากฏในฐาน ข้อมูลได้ หากปราศจาก Parent Entity ที่มีความสัมพันธ์เกี่ยวข้องกันซึ่งสมาชิกของเอนทิตี้อ่อนแอจะสามารถมี คุณสมบัติ Identity ได้ก็ต่อเมื่ออาศัย Attribute ใด Attribute หนึ่งของเอนทิตี้ปกติมาประกอบกับ Attribute ของเอนทิตี้นั้นๆ ในอี-อาร์ไดอะแกรมใช้สัญลักษณ์รูปสี่เหลี่ยมผืนผ้าสองรูปซ้อนกันแทนหนึ่งเอน ทิตี้อ่อนแอ โดยชื่อของเอนทิตี้อ่อนแอนั้นๆกำกับอยู่ภายใน

 2. Attribute

        Attribute หมายถึง ข้อมูลที่แสดงคุณสมบัติหรือคุณลักษณะของเอนทิตี้หรือความสัมพันธ์ใน อี-อาร์ไดอะแกรมใช้สัญลักษณ์วงรี ที่มีชื่อของ Attribute นั้นกำกับอยู่ภายในแทนหนึ่ง Attribute และเชื่อมต่อกับเอนทิตี้ที่มี Attribute นั้นด้วยเส้นตรง

 

Attribute สามารถจำแนกได้เป็น 6 ประเภท คือ Simple Attribute ,Composite Attribute ,Key Attribute ,single Attribute, Multi-Valued Attribute และ Derived Attribute

        2.1 Simple Attribute

        Simple Attribute หมายถึง Attribute ที่ไม่สามารถแบ่งแยกย่อยลงไปได้อีก เช่น Attribute รหัสลูกค้า เพศ เป็นต้น ทั้งนี้ ในอี-อาร์ไดอะแกรม สัญลักษณ์ที่ใช้แทน Simple Attribute เป็นเช่นเดียวกับ Attribute

        2.2 Composite Attribute

        Composite Attribute หมายถึง Attribute ที่มีลักษณะตรงข้ามกับ Simple Attribute คือ สามารถแบ่งแยกย่อยลงไปได้อีก เช่น Attribute ชื่อ นามสกุล ในอี-อาร์ไดอะแกรมใช้สัญลักษณ์รูปวงรีที่มีชื่อของ Property นั้นกำกับอยู่ภายในแทนหนึ่ง Composite Attribute และเชื่อมต่อกับ Simple Attribute ที่จำแนกออกไปด้วยเส้นตรง

 2.3 Key Attribute

        Key Attribute หมายถึง Attribute หรือ กลุ่มของ Attribute ที่มีค่าของข้อมูลในแต่ละสมาชิกของเอนทิตี้ไม่ซ้ำกัน ทำให้สามารถระบุความแตกต่างของแต่ละสมาชิกในเอนทิตี้ได้ เช่น เอนทิตี้ลูกค้าประกอบด้วย Attribute รหัสลูกค้า ชื่อ-สกุล และที่อยู่ โดย Property ที่สามารถบอกความแตกต่างของลูกค้าแต่ละคนได้ คือ รหัสลูกค้า ดังนั้น Attribute รหัสลูกค้าจึงเป็น Key Attribute ของเอนทิตี้นักศึกษา เป็นต้น

        ในอี-อาร์ไดอะแกรม ใช้สัญลักษณ์รูปวงรีซึ่งภายในกำกับด้วยชื่อของ Attribute ที่มีการขีดเส้นใต้แทน Key Attribute และเชื่อมต่อกับเอนทิตี้ที่มี Attribute นั้นด้วยเส้นตรง

 

 2.4 Single -Valued Attribute

        Single-Valued Attribute หมายถึง Attribute ที่มีค่าของข้อมูลในแต่ละสมาชิกของเอนทิตี้ได้เพียงค่าเดียว เช่น ลูกค้าหนึ่งคนมีเพศเดียว Attribute เพศจึงเป็น Single -Valued Attribute หรือ วันเกิดของลูกค้า Attribute วันเกิดจึงเป็น Single -Valued Attribute เป็นต้น

        ทั้งนี้ ในอี-อาร์ไดอะแกรมสัญลักษณ์ที่ใช้จะเป็นเช่นเดียวกับ Attribute

        2.5 Multi-Valued Attribute

        Multi-Valued Attribute หมายถึง Attribute ที่มีลักษณะตรงข้ามกับ Single -Valued Attribute โดยที่ Attribute ที่สามารถมีค่าของข้อมูลในแต่ละสมาชิกของเอนทิตี้ได้หลายค่า เช่น บ้านหลังหนึ่งอาจมีโทรศัพท์หลายเลขหมาย Attribute เบอร์โทรศัพท์จึงเป็น Multi-Valued Attribute ในอี-อาร์ไดอะแกรมสัญลักณ์รูปวงรี 2 รูป 2 รูปซ้อนกัน ภายในกำกับด้วยชื่อของ Attribute

        2.6 Derived Attribute

        Derived Attribute หมายถึง Attribute ที่มีค่าของข้อมูลในแต่ละสมาชิกของเอนทิตี้ได้มาจากการนำค่าของข้อมูลใน Attribute อื่นที่มีอย
ในแต่ละสมาชิกของเอนทิตี้มาทำการคำนวณ ซึ่งโดยทั่วไปไม่จำเป็นต้องจัดเก็บ Attribute ประเภทนี้ไว้ในระบบฐานข้อมูล เนื่องจาก Attribute ประเภทนี้มีการเปลี่ยนแปลงค่าของข้อมูลในแต่ละสมาชิกในเอนทิตี้ เช่น Attribute อายุปัจจุบันสามารถคำนวณได้จาก Attribute วัน เดือน ปีเกิด เป็นต้น ในอี-อาร์ไดอะแกรมใช้สัญลักษณ์รูปวงรีที่เป็นเส้นประ

 3. ความสัมพันธ์

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

        ในอี-อาร์ไดอะแกรม ใช้สัญลักษณ์รูปสี่เหลี่ยมข้าวหลามตัด มีชื่อของความสัมพันธ์นั้นกำกับอยู่ภายในแทนหนึ่งความสัมพันธ์ และเชื่อมต่อกับเอนทิตี้ที่เกี่ยวข้องความสัมพันธ์นั้นด้วยเส้นตรง

           เอนทิตี้ที่เกี่ยวข้องกับความสัมพันธ์ เรียกว่า Participant ของความสัมพันธ์ และจำนวนของ Participant ในความสัมพันธ์เรียกว่า ดีกรี ของความสัมพันธ์ ทั้งนี้เอนทิตี้ซึ่งเป็น Participant ของความสัมพันธ์อาจมีส่วนร่วมในความสัมพันธ์ที่สามารถจำแนกได้ 2 ลักษณะ คือ แบบ Total Participant และแบบ Partial Participant

        แบบ Total Participant เป็นความสัมพันธ์ที่ทุกสมาชิกในเอนทิตี้หนึ่งจะมีข้อมูลใน Attribute หนึ่งที่มีความสัมพันธ์กับข้อมูลในอีกหนึ่งเอนทิตี้ เช่น นักศึกษาทุกคนต้องสังกัดคณะใดคณะหนึ่งเท่านั้น ดังนั้น แต่ละสมาชิกในเอนทิตี้นักศึกษาจะมีความสัมพันธ์กับเอนทิตี้คณะเป็นต้น

        ในอี-อาร์ไดอะแกรม การระบุความสัมพันธ์แบบ Total Participant ใช้สัญลักษณ์เส้นคู่เพื่อเชื่อมต่อระหว่างความสัมพันธ์กับเอนทิตี้ที่ทุกสาม ชิกมีความสัมพันธ์กับอีกเอนทิตี้หนึ่ง

 

 

แบบ Partial Participation เป็นความสัมพันธ์ที่บางสมาชิกในเอนทิตี้หนึ่งเท่านั้นจะมีข้อมูลใน Attribute หนึ่งที่มีความสัมพันธ์กับข้อมูลในอีกหนึ่งเอนทิตี้ เช่น มีนักศึกษาเพียงบางคนเท่านั้นที่เป็นผู้แทนนักศึกษาใหม่แต่ละคณะ ดังนั้น จะมีเพียงบางสมาชิกในเอนทิตี้นักศึกษาเท่านั้นที่มีความสัมพันธ์กับเอนทิตี้ คณะ เป็นต้น

        ในอี-อาร์ไดอะแกรม การระบุความสัมพันธ์แบบ Partial Participation ใช้สัญลักษณ์เช่นเดียวกับการแสดงความสัมพันธ์ระหว่างเอนทิตี้ใดๆที่เกี่ยว ข้อ

ความสัมพันธ์มีหลายประการขึ้นอยู่กับปัจจัย ที่ใช้ในการจำแนกประเภทของความสัมพันธ์ ซึ่งมี 2 ปัจจัย คือ ความสัมพันธ์ระหว่างเอนทิตี้ และจำนวนเอนทิตี้ที่เกี่ยวข้อง

        3.1 ความสัมพันธ์ระหว่างเอนทิตี้

            การจำแนกประเภทของความสัมพันธ์ตามความสัมพันธ์ระหว่างเอนทิตี้ เป็นการพิจารณาถึงสัดส่วนความสัมพันธ์ระหว่างสมาชิกในเอนทิตี้ที่เป็น Participant ของความสัมพันธ์ซึ่งอาจเรียกอีกอย่างว่า Cardinality Ratio

            วิธีนี้สามารถจำแนกความสัมพันธ์ได้เป็น 3 ประเภท คือ ความสัมพันธ์แบบหนึ่งต่อหนึ่ง (One to One Relationship) ความสัมพันธ์แบบหนึ่งต่อกลุ่ม (One to Many Relationship) ความสัมพันธ์แบบกลุ่มต่อกลุ่ม (Many to Many Relationship)

            ความสัมพันธ์แบบหนึ่งต่อหนึ่ง หมายถึง ความสัมพันธ์ที่แต่ละสมาชิกในเอนทิตี้หนึ่งความสัมพันธ์กับสมาชิกในอีกหนึ่ง เอนทิตี้เพียงสมาชิกเดียว หรือกล่าวได้ว่าความสัมพันธ์ดังกล่าวเป็นแบบหนึ่งต่อหนึ่ง เช่น สมมติว่าบริษัทขายรถยนต์แห่งหนึ่งได้กำหนดว่า ลูกค้าแต่ละคนจะมีสิทธิ์ซื้อรถยนต์ได้เพียงหนึ่งคันเท่านั้น และรถยนต์คันหนึ่งๆก็จะขายให้กับลูกค้าได้เพียงคนเดียว

            ในอี-อาร์ไดอะแกรม ใช้สัญลักษณ์ 1:1 กำกับเหนือเส้นที่เชื่อมต่อระหว่างความสัมพันธ์และเอนทิตี้ที่เกี่ยวข้องกับ ความสัมพันธ์นั้น

 

 

            ความสัมพันธ์แบบหนึ่งต่อกลุ่ม หมายถึง ความสัมพันธ์ที่แต่ละสมาชิกในเอนทิตี้หนึ่งมีความสัมพันธ์กับสมาชิกในอีก หนึ่งเอนทิตี้มากว่าหนึ่งสมาชิก หรือกล่าวได้ว่า ความสัมพันธ์ดังกล่าวเป็นแบบหนึ่งต่อกลุ่ม เช่น อาจารย์ที่ปรึกษาจะมีนักศึกษาได้หลายคน แต่นักศึกษาแต่ละคนจะมีอาจารย์ที่ปรึกษาเพียงคนเดียว

            ในอี-อาร์โมเดลไดอะแกรม ใช้สัญลักษณ์ 1:N กำกับเหนือเส้นที่เชื่อมต่อระหว่างความสัมพันธ์และเอนทิตี้ที่เกี่ยวข้องกับ ความสัมพันธ์นั้น

ความสัมพันธ์แบบกลุ่มต่อกลุ่ม  หมายถึง   ความสัมพันธ์ที่สมาชิกมากกว่าหนึ่งสมาชิกในเอนทิตี้หนึ่งมีความสัมพันธ์กับ สมาชิกในหนึ่งเอนทิตี้มากกว่าหนึ่งสมาชิกหรือกล่าวได้ว่าความสัมพันธ์ดัง กล่าวเป็นแบบกลุ่มต่อกลุ่ม เช่น เอนทิตี้นักศึกษาและเอนทิตี้วิชามีความสัมพันธ์กันแบบกลุ่มต่อกลุ่ม กล่าวคือ นักศึกษาแต่ละคนสามารถลงทะเบียนได้หลายวิชาและวิชา แต่ะละวิชาสามารถมีนักศึกษาลงทะเบียนเรียนได้หลายวิชา และแต่ละวิชาสามารถมีนักศึกษาลงทะเบียนเรียนได้หลายคน

            ในอี – อาร์ไดอะแกรมใช้สัญลักษณ์ N:M กำกับเหนือเส้นที่เชื่อมต่อระหว่างความสัมพันธ์และเอนทิตี้ที่เกี่ยวข้องกับ ความสัมพันธ์นั้น

 

 

 

การแปลงโมเดล E-R เป็นรูปแบบโมเดลเชิงสัมพันธ์

            การออกแบบฐานข้อมูลในรูปแบบ E-R นั้น ต้องทำการแปลงโมเดลนี้ให้อยู่ในรูปแบบของโมเดลอื่นที่สอดคล้องกับระบบจัดการ ฐานข้อมูลที่เลือกใช้ เพื่อให้สามารถใช้ฐานข้อมูลนั่นต่อไปได้

            ขั้นตอนในการแปลงเอนทิตี้และความสัมพันธ์ไปเป็นตาราง

การแปลงเอนทิตี้ปกติ

 

 จาก รูป ให้นำ composite Attribute มาเป็น Attribute List ในตาราง E สำหรับ Multivalued Attribute ให้แปลงแยกต่างหากในภายหลัง  โดยสามารถแปลงเป็ฯ

            E(P1,A1,A21,A22)

         2. การแปลงเอนทิตี้แบบอ่อนแอ

 

จาก รูป ให้นำ Primary Key ของตาราง S(P1) มาเป็น foreign sey ของตาราง W โดยที่Foreign Key นั้นเป็น Primary Key ร่วมกับ P2 จะสามารถแปลงได้เป็น

      S(P1)

      W(P1,P2,A)

แปลงความสัมพันธ์ระหว่างเอนทิตี้

ดัง ที่ได้เสนอลักษณะความสัมพันธ์ของเอนทิตี้ จะมีอยู่ด้วยกัน 3 แบบ ได้แก่ แบบหนึ่งต่อหนึ่ง หนึ่งกลุ่มต่อกลุ่ม  กลุ่มต่อกลุ่ม ซึ่งความสัมพันธ์แต่ละแบบนี้จะมีลักษณะการแปลงให้อยู่ในรูปของรีเลชั่นที่ แตกต่างกัน ดังรายละเอียดต่อไปนี้

การแทนความสัมพันธ์แบบหนึ่งต่อหนึ่ง

 

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

รูปแบบที่ 1 E1(P1)

            E2(P2,A,P1)  โดยที่มี P1 เป็น Foreing Key ไปยีง Relation E1

รูปแบบที่ 2 E1(P1,P2)

            E2(P2,A) โดยที่มี P2 เป็น Foreign Key ไปยัง Relation E2 
การแทนความสัมพันธ์แบบหนึ่งต่อกลุ่ม

 การแทนความสัมพันธ์แบบหนึ่งต่อกลุ่ม

            จากรูป นำคีย์หลักของเอนทิตี้ที่อยู่ด้านความสัมพันธ์ที่เป็น1 ไปเก็บเป็นแอทริบิวต์ของเอนทิบิวต์ด้านที่มีความสัมพันธ์เป็น N สามารถแปลงได้เป็น

            E1(P1)

            E2(P2,AP1) โดยที่มี P1 เป็น Foreign Key ไปยัง Relation E1

        -การแทนความสัมพันธ์แบบกลุ่มต่อกลุ่ม

 

จาก รูป สร้าง Relation R ที่ประกอบด้วย Primary Key ของทุกเอนทิตี้ที่เกี่ยวข้องรวมกับแอททริบิวต์ในตัวมันเอง สามารถแปลงได้เป็น

                  E1(P1)

                  E2(P2)

                  R(P1,P2,A) โดยที่มี P1 เป็น Foreign Key ไปยัง Relation E1 และ P2 เป็น Foreign Key ไปยัง Relation E2

 กระบวนการนอร์มัลไลเซซั่น (The Normalization Process)

      กระบวนการนอร์มัลไลเซซั่นนี้มีความสำคัญต่อการออกแบบระบบฐานข้อมูลมาก ฐานข้อมูลที่ดีที่สามารถจัดการข้อมูลได้อย่างมีประสิทธิภาพนั้น  จะต้องถูกออกแบบโดยผ่านกระบวนการไลซ์มาก่อนเสมอ ซึ่งโดยทั่วไปแล้วกระบวนการนอร์มัลไลซ์จะมีระดับ คือ

1.      รูปแบบนอร์มัลระดับที่ 1 (First Normal Form : 1NF)

2.      รูปแบบนอร์มัลระดับที่ 2 (Second Normal Form : 2 NF)

3.      รูปแบบนอร์มัลระดับที่ 3 (Third Nomal Form : 3 NF)

4.      รูปแบบนอร์มัลของบอยส์และคอดด์ (Boyce/Codd Normal Form : BCNF)

5.      รูปแบบนอร์มัลของระดับที่ 4 (Fourth Normal Form : 4NF)

6.      รูปแบบนอร์มัลของระดับที่ 5 (Fifth Normal Form : 5F)

 1.   รูปแบบนอร์มัลระดับที่ 1 (First Normal Form : 1NF)

ขั้น ตอนนี้เป็นขั้นตอนสำหรับโครงสร้างข้อมูลของ Relation เพื่อให้ทุก Attribute ของ Relation มีคุณสมบัติ Atomicity กล่าวคือ โครงสร้างข้อมูลของ Relation ในแบบ 1NF จะต้องประกอบด้วย Attribute ที่ไม่อยู่ในรูป Repeating Group เช่น ตัวอย่างข้อมูลต่อไปนี้

Order

 

                      จากตัวอย่าง จะสังเกตเห็นว่าลูกค้า Attribute Cust_No 1 คน สามารถมีรายการสินค้าที่สั่งซื้อ Attribute Order_Content ได้มากกว่า 1 รายการ ดังนั้น จึงกล่าวได้ว่า Attribute Cust_No นี้มีความสัมพันธ์กับ Attribute Order_content ในแบบ Repaeating Group ส่งผลให้ Relation นี้มีโครงสร้างที่ไม่สอดคล้องตามคุณสมบัติของ 1NF ดังนั้น จึงต้องทำการ Normalization โดยการแปลง Attribute ที่อยู่ในรูป Repeation Group ให้มีคุณสมบัติ Atomicity พร้อมกับกำหนดให้ Attribute ดังกล่าวเป็น Relation Key ดังนั้น จากตัวอย่างข้างต้นจึงถูกแปลงให้อยู่ในรูปดังนี้

Order 1

Cust_No	Cust_Name	City	Zone_Sale	Order_Content
				Product_ID	Order_QTY
C001	สายใจ  มีเกิด	ปราจีน	004	P005	50
C001	สายใจ  มีเกิด	ปราจีน	004	P008	25
C001	สายใจ  มีเกิด	ปราจีน	004	P006	46
C002	สุทัศน์  สุขเกษม	กรุงเทพฯ	003	P002	84
C002	สุทัศน์  สุขเกษม	กรุงเทพฯ	003	P001	23
C002	สุทัศน์  สุขเกษม	กรุงเทพฯ	003	P005	54
C003	ภิญโญ  รักดี	อยุธยา	002	P006	20
C005	รจนา  ทองแท้	พะเยา	001	P003	18
C005	รจนา  ทองแท้	พะเยา	001	P002	50
C008	สายน้ำ  ต้นเจริญ	นครสวรรค์	005	P005	84

จะสังเกตเห็นว่า แต่ละค่าที่เป็น  Repeating Group ของ Attribute Product_ID และ Order_QTY จะถูกแยกออกมาเป็น Tuple ใหม่ พร้อมกับการกำหนดให้ Attribute Product_ID ทำหน้าที่เป็น Relation Key ร่วมกับ Attribute Cust_No

            แต่อย่างไรก็ตาม Relation ที่อยู่ในรูป 1NF ถึงแม้จะทำให้ทุก Attribute มีคุณสมบัติ Anomaly แต่กลับเกิดปัญหาความซ้ำซ้อนของข้อมูล(Redundancy) ขึ้นใน Attribute Cust_No,Cust_Name,City และ Zone_Sale แทน และก่อให้เกิดปัญหาทางด้าน Anomaly ตามมาดังนี้

-        Insert Anomaly

เมื่อ พิจารณาจากตัวอย่างจะสังเกตเห็นว่า การเพิ่มข้อมูลลูกค้าจะทำได้ก็ต่อเมื่อลูกค้านั้นมีรายการสั่งซื้อสินค้า แล้วเท่านั้น ซึ่งหมายความถึง Relation นี้ จะไม่สามารถจัดเก็บข้อมูลของลูกค้าที่ยังไม่มีการสั่งซื้อได้ เช่น เมื่อต้องการเพิ่มข้อมูลลูกค้ารหัส C006 โดยที่ยังไม่มีการกำหนดการสั่งสินค้าใน Attribute Product_ID จะไม่สามารถกระทำได้ เนื่องจาก Attribute Product_ID นี้ ถูกกำหนดให้เป็น Relation Key จึงไม่สอดคล้องตามกฎของ Entity Integrity Rule ในส่วนที่ว่า Attribute หรือกลุ่ม Attribute ที่เป็น Relation Key จะมีค่าเป็น Null ไม่ได้

-       Delete Anomaly

เมื่อ พิจารณาจากตัวอย่างจะสังเกตเห็นว่า การลบข้อมูลรายการสั่งซื้อ Attribute Product_ID และ Order_QTY  บาง Tuple ใน Relation นี้ จะทำให้ข้อมูลลูกค้าบางคนสูญหายไป เช่น เมื่อลบข้อมูลรายการสั่งซื้อของสินค้า รหัส P006 ของลูกค้ารหัส C003 จะทำให้ข้อมูลลูกค้ารหัส C003 ถูกลบตามไปด้วย

-       Update Anomaly

เมื่อ พิจารณาจากตัวอย่างจะสังเกตเห็นว่า การปรับปรุงข้อมูลใน Tuple ที่มีค่าของข้อมูลซ้ำกันไม่ครบถ้วยอาจจะก่อให้เกิดความขัดแย้งของข้อมูลที่ ซ้ำซ้อนกันนั้นได้ เช่น การเปลี่ยนชื่อลูกค้าจากสายน้ำ ต้นเจริญ เป็นสายน้ำ  วิถีไทย ของลูกค้ารหัส C08 ซึ่งถ้าแก้ไขไม่ครบถ้วยแล้ว จะทำให้ลูกค้ารหัส C008 มีทั้ง สายน้ำ ต้นเจริญ วิถีไทย

2.  รูปแบบนอร์มัลระดับที่ 2 (Second Normal Form : 2NF)

            ในการทำ Normalization ในขั้นตอน Second Normal Form จำเป็นที่จะต้องรู้จักถึง prime Attribute และ Nonprime Attribute เนื่องจาก Attribute ทั้ง 2 ประเภทนี้ จะมีความสำคัญต่อการทำ Normalization แบบ Second Normal Form

            Prime Attribute ได้แก่ ทุก Attribute ที่ทำหน้าที่เป็น Relation Key ของ Relation ส่วนหนึ่งส่วนใดของ Relation Key  Nonprime Attribute ได้แก่ Attribute  ที่ไม่ได้เป็นส่วนหนึ่งส่วนใดของ Relation Key

            สำหนับ Relation ที่จะมีโครงสร้างของ 1NF

1.      ต้องมีโครงสร้างเป็นไปตามโครงสร้างของ 1NF

2.      ทุก Nonprime Attribute จะต้องไม่ขึ้นกับ Relation Key ที่อยู่ในรูปของ Subset

ยก ตัวอย่างเช่น Relation Order 1 ในตัวอย่างที่ผ่านมา ซึ่งเป็น Relation ที่มีคุณสมบัติของ 1NF จะสังเกตเห็นว่า Attribute Cust_No,Product_ID เป็น Attribute ที่ทำให้ข้อมูลในแต่ละ Tuple มีค่าไม่ซ้ำกัน ดังนั้น Attribute ทั้ง 2 จึงทำหน้าที่เป็น Relation Key ซึ่งสามารถเขียนด้วย Functional Dependency ได้ดังนี้

 

และ เมื่อพิจารณาค่าของ Arrtibute Cust_No,Cust_Name,City,Zone_Sale จะสังเกตเห็นว่า Tuple ที่ประกอบขึ้นจาก Attribute เหล่านี้ จะมีข้อมูลที่ซ้ำกันเป็นชุด ๆ และมีเพียง Attribute Order_QTY เท่านั้น ที่มีการเปลี่ยนตามค่าของ Relation Key ดังนั้นจึงสามารถเขียนด้วย Funtion Dependency เพิ่มเติมได้ ดังนี้

 

            ใน d2 จะสังเกตเห็นว่า Attribute Cust_Name, City และ Zone_Sale เป็น Nonprime Attribute ของ Relation Key แต่กลับขึ้นอยู่กับค่าของ Attribute Cust_No ด้วย แสดงว่า d2 นี้ไม่เป็นไปตามคุณสมบัติข้อที่ 2 ดังนั้น Relation Order1 จึงไม่มีคุณสมบัติเป็นไปตามคุณสมบัติของ 2NF จึงต้องแตก Relation Order1 ออกเป็น 2 Relation ตาม d1 และ d2 ดังนี้

CustOrder

Cust_No	Product_ID	Order_QTY
C001	P005	50
C001	P008	25
C001	P006	46
C002	P002	84
C002	P001	23
C002	P005	54
C003	P006	20
C005	P003	18
C005	P002	50
C008	P002	84

Cust

Cust_No	Cust_Name	City	Zone_Sale
C001	สายใจ  มีเกิด	ปราจีน	004
C002	สุทัศน์  สุขเกษม	กรุงเทพฯ	003
C003	ภิญโญ  รักดี	อยุธยา	002
C005	รจนา ทองแท้	พะเยา	001
C008	สายน้ำ ต้นเจริญ	นครสวรรค์	005

 สำหรับโครงสร้างของ Relation CustOrder และ Cust นี้ จะสังเกตเห็นว่าจะสามารถแก้ปัญหา Anomaly ที่เกิดขึ้นใน  Relation Order1 ได้ดังนี้

-     Insert Anomaly

Relation   Cust      สามารถเพิ่มข้อมูลลูกค้าได้โดยไม่ต้องมีการสั่งซื้อสินค้าเกิดขึ้น

เนื่องจากข้อมูลการสั่งซื้อสินค้าจะถูกแยกจัดเก็บใน Relation Cust Order

-    Delete Anomaly

สามารถลบข้อมูลรายการสั่งซื้อสินค้ารหัส P006 ของลูกค้าใน C003 ใน   Relation

Cust Order ได้ โดยไม่ส่งผลต่อข้อมูลของลูกค้ารหัส C003 เนื่องจากข้อมูลลูกค้าถูกแยกจัดเก็บใน Relation Cust

-    Update Anomaly

เนื่องจากข้อมูลลูกค้าที่ซ้ำซ้อนจะถูกแยกมาจัดเก็บอยู่ใน Relation Cust    ดังนั้น

การเปลี่ยนแปลงรายละเอียดข้อมูลลูกค้าจึงกระทำกับ Relation Cust เพียง  Relation เดียว

 3. รูปแบบนอร์มัลระดับที่ 3 (Third Normal From : 3 NF)

สำหรับการทำ Normalization ในขั้นตอน แบบ 3 NF จะต้องมีคุณสมบัติดังนี้

1.      ต้องมีคุณสมบัติของ 2 NF

2.   ต้องไม่มี Function Dependency เกิดขึ้น ระหว่าง Nonprime Attribute ด้วยกันเองที่เรียกว่า Transitive Dependency

จาก Relation Cust ในหัวข้อที่ผ่านมา ถึงแม้ว่าจะมีโครงสร้างเป็นไปตามคุณสมบัติของ 2

NF แต่จะสังเกตเห็นว่า ค่าของ Attribute City และ Zone_Sale ยังปรากฏข้อมูลที่มีค่าซ้ำกันอยู่เป็นคู่ ๆ หรือกล่าวอีกนัยหนึ่งทั้ง 2 Attribute สามารถที่จะระบุค่าระหว่างกันได้ กล่าวคือ เมื่อระบุค่าให้กับ Attribute Zone_Sale จะสามารถทราบถึงชื่อเมืองใน Attribute City ได้ ซึ่งความสัมพันธ์ในลักษณะนี้จะเรียกว่า Transitive Dependency ดังนั้น Relation นี้จึงขาดคุณสมบัติของ 3NF และยังก่อให้เกิดปัญหาความผิดพลาดทางด้าน Anomaly ดังนี้

-    Insert Anomaly

ใน Relation Cust   เมื่อต้องการพิมพ์ข้อมูลใหม่ให้กับ  Attribute  City   และ  

Zone_Sale ซึ่งมีความสัมพันธ์ในแบบ Transitive Dependency จะไม่สามารถกระทำได้ เนื่องจากข้อมูล 2 Attribute นี้ไม่ใช่ Relation key ดังนั้น จึงต้องเพิ่มข้อมูลนี้ของลูกค้ารายใหม่ให้กับ Attribute Cust_No และ Cust_Name ตามไปด้วย

-    Update Anomaly

ใน Relation Cust จะสังเกตเห็นว่า เมื่อมีการแก้ไขข้อมูลใน Attribute Zone_Sale

จาก 005 ไปเป็น 006 จะต้องทำการแก้ไขข้อมูลในทุก ๆ Tuple ที่มีค่าของ  Attribute Zone_Sale เท่ากับ 005 ให้ครบถ้วน เนื่องจากเมื่อทำการแก้ไขข้อมูลไม่ครบถ้วนจะก่อให้เกิดข้อมูลใน Relation ที่มีความขัดแย้งกันได้

-     Delete Anomaly

ใน Relation Cust จะสังเกตเห็นว่า ถ้ามีการลบข้อมูลของ Tuple ที่จัดเก็บข้อมูลใน

กลุ่ม Transitive Dependency ที่ปรากฏอยู่เพียงชุดเดียวใน Relation จะส่งผลให้ข้อมูลในกลุ่ม Transitive Relation Cust ออกมาเป็น Relation ใหม่ซึ่งจากตัวอย่างได้แก่ Attribute City และ Zone_Sale ดังนี้Dependency นั้นสูญหายไปจาก Relation ได้ เช่น เมื่อทำการลบข้อมูลใน Tuple ของลูกค้ารหัส C001 นอกจากจะทำให้ข้อมูลของลูกค้ารหัส C001 หายไปแล้วยังส่งผลให้ข้อมูลของเขตการขายที่อยุธยาหายไปด้วย

            จากปัญหา Anomaly ที่เกิดขึ้นจาก Transitive Dependency เหล่านี้ จึงต้องทำการแยก Nonprime Attribute ที่ก่อให้เกิด Transitive Dependency ของ

 Cust 2

Cust_No	Cust_Name	City
C001	สายใจ  มีเกิด	ปราจีน
C002	สุทัศน์  สุขเกษม	กรุงเทพฯ
C003	ภิญโญ  รักดี	อยุธยา
C005	รจนา ทองแท้	พะเยา
C008	สายน้ำ ต้นเจริญ	นครสวรรค์

 City Zone

City	Zone_Sale
พะเยา	001
อยุธยา	002
กรุงเทพฯ	003
ปราจีน	004
นครสวรรค์	005

 ซึ่งสามารถเขียนด้วย Functional Dependency ได้ดังนี้

 

การ แยก Nonprime Attribute ที่ก่อให้เกิด Transitive Dependency ออกมาเป็น Relation ใหม่ อาจทำให้ความสัมพันธ์ระหว่างข้อมูลสูญเสียไปได้เช่นเดียวกัน เช่น ตัวอย่างข้อมูล และ Functional Dependency ต่อไปนี้

 

Cust 2

Cust_No	Cust_Name	City
C001	สายใจ  มีเกิด	ปราจีน
C002	สุทัศน์  สุขเกษม	กรุงเทพฯ
C003	ภิญโญ  รักดี	อยุธยา
C005	รจนา ทองแท้	พะเยา
C008	สายน้ำ ต้นเจริญ	นครสวรรค์

 City Zone

Cust_No	Zone_Sale
C001	004
C002	003
C003	002
C005	001
C008	005

         จากตัวอย่างจะเห็นว่า โครงสร้างของทั้ง 2 Relation สามารถที่จะแก้ปัญหา Anomaly ได้และมีโครงสร้างในแบบ 3NF อย่างไรก็ตาม ข้อมูลใน Relation CustZone กลับไม่มีความเป็นอิสระต่อกัน กล่าวคือ เมื่อต้องการเพิ่มข้อมูลให้กับ Attribute Zone_Sale จะต้องเพิ่มข้อมูลให้กับ Attribute Cust_No ตามไปด้วย

 ข้อ สังเกต    ในการแยก Nonprime Attribute ที่ก่อให้เกิด Transitive Dependency ออกมาเป็น Relation ใหม่มีหลักการอยู่ 2 ข้อดังนี้

1.      แยก Nonprime Attribute ที่ก่อให้เกิด Transitive Dependency ออกเป็น Relation ใหม่

2.      กำหนดให้ Nonprime Attribute ที่เป็นตัวระบุค่าให้เป็น Relation key ของ Relation ใหม่

 4. รูปแบนอร์มัลของบอยส์และคอดด์ (Boyce/Codd Normal From : BNCF)

สำหรับ  Relation ที่มีโครงสร้างในแบบ BNCF จะต้องมีคุณสมบัติดังนี้

1.      ต้องมีคุณสมบัติของ 3 NF

2.      Attribute ที่เป็น Determinant จะต้องเป็น Relation key

ยกตัวอย่างเช่น Relation Custtomer4 ที่มีตัวอย่างข้อมูลดังนี้

Custtomer4

Cust_ID	Tax_ID	Cust_Name	Address
C001	8904587485	โสภา       เตีย	123  ยานนาวา   กทม.
C002	8246464141	นันทิดา   หยุ่น	4/55  พระโขนง  กทม.
C003	2546464644	ฮีแมน      เมก	3  สุขุมวิท  กทม.
C005	9685812614	วันตา       อิ่มใจ	3/7  คลองตัน  กทม.

 จาก Relation ที่กำหนด สามารถเขียน FD ได้ดังนี้

 

            เมื่อพิจารณาใน d1 และ d2 จะสังเกตเห็นว่า Attribute Cust_ID และ Tax_ID ต่างสามารถทำหน้าที่เป็น Determinant เพื่อใช้อ้างถึง Attribute Cust_Name และ Address ได้เช่นเดียวกัน และในขณะเดียวกันเมื่อพิจารณาใน d3 จะสังเกตเห็นว่า ความสัมพันธ์ของ 2 Attribute นี้ เป็นความสัมพันธ์แบบ 2 ทาง กล่าวคือ ต่างฝ่ายสามารถทำหน้าที่แทนหน้าที่แทนอีกฝ่ายหนึ่งได้ ดังนั้นในกรณีเช่นนี้จึงสามารถกำหนดให้ Attribute ใด Attribute หนึ่งใน 2 Attribute นี้ ทำหน้าที่เป็น Relation Key ได้ ซึ่งในตัวอย่าง Attribute Cust_ID ถูกกำหนดให้เป็น Relation Key อยู่แล้ว ด้วยเหตุนี้จึงกล่าวได้ว่าโครงสร้างของ Relation นี้มีคุณสมบัติเป็นไปตามคุณสมบัติ BCNF

 แต่ใน Relation Cust_Order ที่มีตัวอย่างข้อมูลต่อไปนี้

Cust Order

Cust_ID	Tax_ID	Product_Name	Order_QYT
C001	8904587485	I001	90
C002	8246464141	I003	80
C003	2546464644	I004	220
C005	9685812614	I003	100

 จาก Relation ที่กำหนดสามารถเขียน FD ได้ดังนี้

 

            เมื่อพิจารณาตามคุณสมบัติข้อ 2 ของ BCNF จะพบว่า Relation นี้ มีโครงสร้างที่ไม่เป็น BCNF เนื่องจาก Attribute Product_ID ไม่ได้ทำหน้าที่เป็น Relation Key ของ Relation จึงต้องแยก Relation นี้ออกเป็น 2 Relation โดยกระทำได้ 2 วิธีดังนี้

            วิธีที่ 1  แยก Relation ออกตามความสัมพันธ์ที่กำหนดใน d1 และ d3 ซึ่งได้ Relation ดังนี้

                                    Cust1

Cust_ID	Tax_ID
C001	8904587485
C002	8246464141
C003	2546464644
C005	9685812614

            Cust_Order1

Cust_ID	Product_Name	Order_QYT
C001	I001	90
C002	I003	80
C003	I004	220
C005	I003	100

วิธีที่ 2  แยก Relation ออกตามความสัมพันธ์ที่กำหนดใน d2 และ d3 ซึ่งได้ Relation ดังนี้

        Cust1

Cust_ID	Tax_ID
C001	8904587485
C002	8246464141
C003	2546464644
C005	9685812614

 

 

 

 

Cust_Order2

Tax_ID	Product_Name	Order_QYT
8904587485	I001	90
8246464141	I003	80
2546464644	I004	220
9685812614	I003	100

           ซึ่งจะสังเกตเห็นว่าโครงสร้างข้อมูล Relation ใหม่ตามวิธีที่ 1 และ 2 ต่างมีคุณสมบัติของ BCNF แต่เมื่อพิจารณาตัวอย่างของ Relation ต่อไปนี้

 Sample

S#	C#	T#
S061	คณิตศาสตร์	อ.อรุณวรรณ
S061	ฟิสิกส์	อ.อรัญญา
S037	คณิตศาสตร์	อ.อรุณวรรณ
S037	ฟิสิกส์	อ.อรัญญา
S131	คณิตศาสตร์	อ.อาร์ม
S131	ฟิสิกส์	อ.กนกรัตน์

 ซึ่งมีการกำหนดเงื่อนไขต่าง ๆ ดังนี้

      1. นักศึกษาแต่ละคนจะต้องเลือกเรียนกับอาจารย์ท่านใดท่านหนึ่งเพียงท่านเดียวในแต่ละรายวิชา

2        อาจารย์แต่ละท่าน สามารถสอนได้เพียงวิชาเดียว

3        แต่ละวิชาสามารถเปิดสอนโดยอาจารย์หลายท่านได้

ดังนั้น  จึงสามารถเขียน FD ได้ดังนี้

 

              จากการพิจารณา FD จะเห็นได้ว่า Relation นี้ มีโครงสร้างไม่เป็นไปตามคุณสมบัติของ BCNF เนื่องจาก Attribute T# ถึงแม้ว่าจะทำหน้าที่เป็น Determinant แต่ก็ไม่ทำหน้าที่เป็น Relation Key ประกอบกับ Relation นี้ได้ก่อเกิดปัญหาทางด้าน Anomaly ดังนี้

  Insert Anomaly

ในการเพิ่มข้อมูลให้กับ Relation sample จะต้องเพิ่มข้อมูลให้กับทั้ง 3 Attribute พร้อมๆ กัน จึงจะ

สามารถ กระทำได้ เช่น เมื่อต้องการเพิ่มวิชาเรียนที่มีรหัส S128 จะไม่สามารถกระทำได้ ถ้ายังไม่ทราบชื่อของอาจารย์ผู้สอนหรือยังไม่มีนักศึกษาลงทะเบียนเรียน

   Update Anomaly

ในการเปลี่ยนแปลงข้อมูลใน Attribute ของ Tuple หนึ่ง จะต้องเปลี่ยนแปลงข้อมูลนั้นใน Tuple อื่น

ที่ มีค่าของข้อมูลเดียวกันทั้งหมด เช่น เมื่อต้องการเปลี่ยนข้อมูลผู้สอนวิชาคณิตศาสตร์ จากอาจารย์ อรุณวรรณ เป็นอาจารย์ อารมณ์ จะต้องเปลี่ยนแปลงข้อมูลในทุก Tuple ที่เป็นของวิชาคณิตศาสตร์ และมีอาจารย์ อรุณวรรณ เป็นผู้สอนทั้งหมด

 Delete Anomaly

ในการลบ Tuple ใดๆ Tuple หนึ่ง อาจส่งผลให้ค่าใน Attribute ใด Attribute หนึ่ง สูญหายไป เช่น

เมื่อทำการลบข้อมูลของ Tuple ต่อไปนี้

 

 จะทำให้ข้อมูลของอาจารย์ กนกรัตน์ ที่เป็นผู้สอนวิชาฟิสิกส์ สูญหายไปด้วย

            การแก้ไข Relation นี้ ให้มีโครงสร้างเป็นไปตามคุณสมบัติของ BCNF ทำได้โดยแยก Attribute T# ออกมาเป็น Relation ใหม่ตาม d2 ซึ่งจะทำให้ได้ Relation ใหม่ ดังนี้

และสามารถเขียน FD ใหม่ได้ดังนี้

 

                   ซึ่งจะสังเกตเห็นว่า Relation ST และ  TC ที่กำหนดขึ้นใหม่ จะมีโครงสร้างเป็นไปตามคุณสมบัติของ BCNF  แต่อย่างไรก็ตาม จะพบว่าการเปลี่ยนแปลงค่าให้กับข้อมูลใน Relation ทั้งสองกลับไม่เป็นอิสระต่อกัน เช่น เมื่อต้องการเพิ่มข้อมูลอาจารย์ใหม่ใน Relation ST ดังนี้

 

 

 

                   ข้อมูลที่เพิ่มเข้าไปใหม่จะทำให้นักศึกษารหัส  S061 สามารถเรียนวิชาคณิตศาสตร์กับทั้งอาจารย์ อารมณ์ และอาจารย์อรุณวรรณ ซึ่งขัดแย้งกับข้อกำหนดของเงื่อนไขข้อที่ 1 ที่กำหนดให้นักศึกษาแต่ละคนจะต้องเลือกเรียนกับอาจารย์ท่านใดท่านหนึ่งเพียง ท่านเดียวในแต่ละรายวิชา ดังนั้น จึงอาจใช้วิธีแยก Attribute T# และ S# ออกเป็น Relation ST และ SC ตามลำดับแทน ดังนี้

 

 

            ซึ่งจะสังเกตเห็นได้ว่าสามารถแก้ไขปัญหาข้างต้นได้ อย่างไรก็ตาม จะสูญเสียความสัมพันธ์ระหว่างอาจารย์กับวิชาที่สอนไป ดังนั้น Relation ที่มีโครงสร้างในลักษณะนี้ จึงไม่สามารถทำให้อยู่ในรูปของ BCNF ได้    

 5. รูปแบบนอร์มัลระดับที่ 4 (Fourth Normal Form : 4NF)

สำหรับการทำ Normalization ในขั้นตอน แบบ 4NF จะต้องมีคุณสมบัติ ดังนี้

1.      ต้องมีคุณสมบัติของ BCNF

2.      ต้องไม่ปรากฏความสัมพันธ์ระหว่าง Attribute ในแบบ Multi – Value Dependency

เช่น ตัวอย่างข้อมูลของ Relation Employee_Skill ซึ่งใช้จัดเก็บข้อมูลเกี่ยวกับความสามารถของพนักงาน ทางด้านการใช้โปรแกรมคอมพิวเตอร์ Attribute Computer_Skill และทางด้านการใช้ภาษาต่างประเทศ Attribute Language_Skill ดังนี้

             จากตัวอย่างข้อมูล จะสังเกตเห็นว่า Relation นี้ มีคุณสมบัติเป็น BCNF แต่ยังไม่เป็น 4NF เนื่องจากปรากฏโครงสร้างข้อมูลในแบบ Multi_Value Dependency กล่าวคือ เมื่อระบุค่าของ Attribute Employee# ซึ่งทำหน้าที่ Determinant จะสามารถแสดงค่าของ Attribute Computer_Skill และ Language_Skill ที่ทำหน้าที่ Dependency ได้มากกว่า 1 ค่า เช่น เมื่อระบุค่าของ Attribute Employee# เป็น 1267 จะปรากฏค่าของ Attribute Computer_Skill ออกมา 2 ค่า คือ Word Processing และ Spreadsheets พร้อมกับ Attribute Language_Skill ออกมา 2 ค่าเช่นเดียวกัน คือ ฝรั่งเศส และสเปน

        ดังนั้น จึงต้องแบ่ง Relation นี้ออกเป็น Relation ใหม่ตามโครงสร้างข้อมูลแบบ Multi-Value Dependency ที่ปรากฏอยู่ ซึ่งได้แก่ Relation Computer_Skill และ Language_Skill ดังนี้

 

ข้อสังเกต      โครงสร้างของ Relation ในส่วนที่เดิมมีความสัมพันธ์แบบ Multi-Value Dependency

                   เมื่อนำมาทำ Normalization ในขั้นตอน 4NF Relation ใหม่ที่ได้จะมีโครงสร้างเช่นเดียว

                   กับ Relation ที่ได้จากการทำ Normalization ในขั้นตอน 1NF

6.    รูปแบบนอร์มัลระดับที่ 5 (Fifth Normal Form: 5NF)

                   สำหรับ Relation ที่มีโครงสร้างในแบบ 5NF จะต้องมีคุณสมบัติ ดังนี้

1.      ต้องมีคุณสมบัติของ 4NF

2.      ต้องมีคุณสมบัติ Join Dependency

 Join Dependency เป็นคุณสมบัติของการนำ Relation ย่อยที่เกิดจากการแตก Relation เดิมมารวมกัน (Join) แล้วได้ข้อมูลเช่นเดียวกับ Relation เช่น เมื่อนำ Relation Computer_Skill และ Language_Skill ในหัวข้อที่ผ่านมา มาทำการ Join โดยใช้ค่าของ Attribute Employee# แล้วยังได้ผลเช่นเดียวกับ Relation Employee_Skill ที่ 2 Relation นั้นแตกมา

         การทำ Normalization ในขั้นตอน 5NF นี้จะใช้คุณสมบัติ Join Dependency สำหรับตรวจสอบโครงสร้างของ Relation ที่ได้จากการแตกในขั้นตอน 4NFว่ามีโครงสร้างที่ถูกต้องหรือไม่ เช่น Relation_Plan ซึ่งใช้จัดเก็บข้อมูลประเภทโครงการ (Attribute Project) และจังหวัดที่ตั้งของโครงการ (Attribute City) ที่พนักงานแต่ละคนทำงานอยู่ ดังนี้

้

 

ซึ่งจะสังเกตเห็นว่าเมื่อนำมารวมกับ Relation Project_Join 1 จะสามารถนำมารวมกันเป็น Relation เดิมได้

 

จากผลของการ Join จะสังเกตเห็นว่า มี Tuple ที่เกินมาดังนี้

 

ซึ่ง Tuple ที่เกินมานี้จะเรียกว่า Spurious Tuple

             ดังนั้น Relation Emp_Prooject และ Emp_City นี้ จึงไม่ถือว่ามีคุณสมบัติ 5NF เนื่องจากเมื่อทำการรวม Relation ดังกล่าวแล้ว ไม่สามารถนำมารวมกันเป็น Relation เดิมได้ จึงถือว่าโครงสร้างของ Relation ใน 4 NF ไม่ถูกต้อง แต่เมื่อเพิ่ม Relation Project_City ซึ่งเป็น Relation ที่แตกย่อยมาจาก Relation Project_Plan และมีคุณสมบัติ 4NF ดังนี้

 

จึง ถือว่า Relation Emp_ciry และ Project_city นี้มีคุณสมบัติ 5NF แต่ถ้าไม่สามารถนำมารวมกันเป็น Relation เดิมได้ จะถือว่าโครงสร้างของ Relation ใน 4NF ไม่ถูกต้อง และให้ถือว่าโครงสร้างของ BCNF อยู่ใน Normal Form สูงสุดแล้ว จึงไม่จำเป็นที่จะต้องแตกย่อยต่อไปอีก