Data Mining ในโลกความจริง ตอน Normalization จุดผลิกผัน BI(2)

อ้างอิงปฐมภูมิจาก Thomas Connolly, Carolyn Begg : Database System, 2005

---

          จากคราวที่แล้วว่าเรื่อง Nomalization Level 1 (1NF) ไป ตอนแรกผมกะจะเขียนต่อในวันถัดมาจากคราวที่แล้ว แต่ก็ยุ่ง ๆ เลยหายไปซะ 2-3 วัน เอาล่ะ! วันนี้เรามาต่อกันเลยนะครับ ผมขอตัดเรื่อง 1NF แบบพิศดารออกไปก่อน เริ่มที่ 2NF เลยแล้วกันนะครับ อืม ๆ นิดนึงนะครับ อาการไม่ปกติของ Database มันมีคำถาม 2 คำถาม ที่ต้องตั้งเมื่อมองไปที่ Databse คือ 1.ข้อมูลมีอะไรต้องเขียนซ้ำ ๆ ซาก ๆ มั้ย 2.เมื่อสั่งให้ ลบ หรือ แก้ไข อาจเกิดการชี้แถวผิดได้มั้ย ถ้า Database ที่ดูอยู่อาจเกิด 2 อย่างนี้ได้ แสดงว่ายังไม่ผ่าน Normalize ครับ

 

          Nomalization Level 2 เป็นการรักษาอาการไม่ปกติของ Entity(Table) ใน Database ขั้นที่ 2 ซึ่งมีนิยามว่า “No non-prime attribute in the table is functionally dependent on a part (proper subset) of a candidate key” แปลเป็นไทยก็คือ “เป็น 1NF และ Attribute(Field) ที่ไม่ใช่คีย์ ต้องขึ้นกับคีย์หลัก(Pimary Key)” งงใช่มั้ยล่ะครับ เราลองมาดูกันเลยดีกว่าครับว่าถ้าเราจะสร้างความรู้ แบบไม่จำจะทำไงกันดี งั้นเริ่มอย่างนี้นะครับ ดูภาพที่ 1 ก่อน

 

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

แต่ละสีก็คือ 1 กลุ่มข้อมูล แต่ละกลุ่มก็มีตัวแทนของมัน เอาเป็นว่าใช้ถ้าทำตามผมนะครับให้ทำ 2 ขั้นตอนครับคือ 1.จัดกลุ่มข้อมูล 2.หาตัวแทนของกลุ่ม เหตุผลง่าย ๆ ครับ ถ้ายังเป็นแบบรูปที่ 1 อยู่ มันเปลืองเนื้อที่ แล้วก็เปลืองเวลาด้วยครับ แถมเวลาต้องทำการ Update หรือ Delate แล้วมันก็สุ่มเสี่ยงในการ Update หรือ Delate ผิดพลาดได้ เราก็มาแยกออกเป็นกลุ่ม ๆ แล้วเอาตัวแทนของแต่ละกลุ่มออกมาเป็นตารางแทน เหมือนรูปที่ 3

ถ้าข้อมูลน้อยจะไม่ค่อยเห็นว่ามันลดใช่มั้ยครับ คือเดิมมี 35 ช่อง(Cells) แต่ พอผ่าน 2NF แล้วทั้งหมดดันกลายเป็น 39 ช่อง(Cells) นั่นเพระาตัวอย่างมันดันมีน้อยครับ ถ้าข้อมูลเยอะกว่านี้จะเห็นได้ว่ามันลดลงครับ แล้วก็ขจัดข้อผิดพลาดในการ Upfdate หรือ Delate ด้วย

ยังไม่จบ ต่อพรุ่งนี้ครับ…