Normalization: Second Normal Form

Second Normal Form (2NF)

Relation Schema(table) တစ်ခုဟာ Second Normal Form (2NF) ဖြစ်ဖို့ဆိုရင် အောက်ပါစည်းမျဉ်းနှစ်ခုဖြင့် ကိုက်ညီရပါမယ်။

1NF ဖြစ်ပြီးသားဖြစ်ရပါမယ်။

Table မှာရှိတဲ့ non-prime attribute(field) တိုင်းဟာ primary key အပေါ်မှာ အပြည့်အဝ မှီခို (fully functional depentent) နေရပါမယ်။

ရှင်းလင်းချက်။

Prime Attribute – Candidate Key ထဲမှာ ပါဝင်တဲ့ column (field)။
Non-Prime Attribute – Candidate Key မဟုတ်တဲ့ column (field)။
Fully Functional Dependency (FD) - Attribute(field) တစ်ခုဟာ primary key တစ်ခုလုံးအပေါ် မှီခိုနေရပါမယ်။

2NF ကို နားလည်ဖို့အတွက် အရင်ဆုံး Functional Dependency ဆိုတဲ့ အရေးကြီးတဲ့ သဘောတရားတစ်ခုကို လေ့လာဖို့လိုပါတယ်။

Functional Dependency(FD)

Functional Dependency ဆိုတာက table တစ်ခုထဲမှာ column (attribute) တစ်ခုရဲ့တန်ဖိုးက တခြား column တစ်ခုရဲ့တန်ဖိုးကို ဘယ်လိုဆုံးဖြတ်ပေးတယ်ဆိုတဲ့ ဆက်နွယ်မှုကို ဖော်ပြတာဖြစ်ပါတယ်။

ရိုးရှင်းအောင်ပြောရရင် —

Column A ရဲ့တန်ဖိုးကို သိရုံဖြင့် Column B ရဲ့တန်ဖိုးကို တိတိကျကျ သိနိုင်တယ် ဆိုရင် B ဟာ A အပေါ်မှာ Functional Dependent ဖြစ်တယ်လို့ ခေါ်ပါတယ်။

သင်္ကေတ — A → B (A determines B)

A ကို determinant လို့ ခေါ်ပါတယ်။ [A က B ကို သတ်မှတ်သည်။]
B ကို dependent လို့ ခေါ်ပါတယ်။ [B သည် A အပေါ်တွင် functional dependent ဖြစ်သည်။]

ဥပမာ

Employees table ရှိတယ်ဆိုပါစို့။

EmployeeID	FirstName	LastName	Department	DepartmentManager
101	Sarah	Connor	Sales	John
102	Kyle	Reese	Engineering	Jane
103	John	Connor	Sales	John
104	Alice	Chan	Engineering	Jane

ဒီ table ထဲက Functional Dependencies (FDs) ကို ရှာကြည့်ရအောင်။

EmployeeID → FirstName, LastName, Department

EmployeeID ကို သိရုံဖြင့် ဝန်ထမ်းရဲ့နာမည် (FirstName, LastName) နှင့် ဌာန (Department) ကို တိတိကျကျ သိနိုင်ပါတယ်။ EmployeeID ကလည်း primary key ဖြစ်တဲ့အတွက် တူညီတဲ့ တခြား row မရှိနိုင်ပါဘူး။
ဥပမာ —
EmployeeID = 101 ဆိုတာနှင့်

FirstName = Sarah
LastName = Connor
Department = Sales
ဆိုတာကို သိရှိနိုင်ပါတယ်။

➡ EmployeeID ဟာ FirstName, LastName, Department တို့ရဲ့ Determinant ဖြစ်တယ်။

Department -> DepartmentManager

Department ကို သိရုံဖြင့် အဲ့ဒီဌာနရဲ့ မန်နေဂျာကို တိတိကျကျသိနိုင်ပါတယ်။
ဥပမာ —

Sales ➜ John
Engineering ➜ Jane

➡ Department က DepartmentManager ရဲ့ Determinant ဖြစ်တယ်။

တချို့ attribute တွေက reverse dependency မဖြစ်နိုင်ပါဘူး။

ဥပမာ —
FirstName → EmployeeID လို့တော့ ပြောလို့မရပါဘူး။

ဘာလို့လဲဆိုတော့ —

“John” ဆိုတဲ့ FirstName နှင့် ဝန်ထမ်း ၂ ယောက် ရှိနိုင်တဲ့အတွက် နာမည်တစ်ခုတည်းဖြင့် EmployeeID ကို တိတိကျကျ မဆုံးဖြတ်နိုင်လို့ပါပဲ။

Full vs Partial Dependency (အပြည့်အဝ မှီခိုမှု vs. တစ်စိတ်တစ်ပိုင်း မှီခိုမှု)

ဒီသဘောတရားက Composite Primary Key (column နှစ်ခု ဒါမှမဟုတ် နှစ်ခုထက်ပိုပြီးပေါင်းထားတဲ့ Primary Key) ရှိတဲ့ table တွေမှာ အလွန်အရေးကြီးပါတယ်။

Partial Dependency - Column တစ်ခုက Composite Primary Key ရဲ့ တစ်စိတ်တစ်ပိုင်း အပေါ်မှာပဲ မှီခိုနေတာ။

Full Dependency - Column တစ်ခုက Composite Primary Key တစ်ခုလုံး အပေါ်မှာ မှီခိုနေတာ။

ဥပမာ —

ကျောင်းသား (Students) နှင့် သင်တန်း (Courses)

ကျောင်းသားတွေ ဘယ်ဘာသာရပ်တွေ တက်ရောက်နေလဲဆိုတာကို မှတ်တမ်းတင်ထားတဲ့ table တစ်ခုကို စဉ်းစားကြည့်ပါ။

Enrollments Table (in 1NF)

StudentID	CourseID	StudentName	CourseGrade	CourseProfessor
S101	CS101	Ann	A	Prof. Smith
S101	ENGL201	Ann	B	Prof. David
S102	CS101	Ben	A	Prof. Smith
S103	MATH301	Chris	B	Prof. White

ဒီ Table မှာ ကျွန်တော်တို့ရဲ့ primary key က (StudentID, CourseID) ဖြစ်ပါတယ်။ အခု ကျန်တဲ့ Columns တွေရဲ့ Dependencies တွေကို ကြည့်ရအောင်။

StudentName: ကျောင်းသားရဲ့ နာမည်က Composite primary key (StudentID နှင့် CourseID) နှစ်ခုစလုံးအပေါ် မှီခိုနေသလား။
- မဟုတ်ပါ။
- ကျောင်းသားနာမည်ကိုသိဖို့ StudentID တစ်ခုတည်းဖြင့် လုံလောက်ပါတယ်။ CourseIDမလိုပါဘူး။ ဒါကြောင့် ဒါဟာ Partial Dependency ဖြစ်ပါတယ်။
- StudentName က composite key ရဲ့ တစ်စိတ်တစ်ပိုင်း (StudentID) အပေါ်မှာပဲ မှီခိုနေပါတယ်။
CourseProfessor: ပါမောက္ခနာမည်က Composite primary key (StudentID နှင့် CourseID) နှစ်ခုစလုံးအပေါ် မှီခိုနေသလား။
- မဟုတ်ပါ။
- ပါမောက္ခနာမည်ကိုသိဖို့ CourseID တစ်ခုတည်းဖြင့် လုံလောက်ပါတယ်။ StudentID မလိုပါဘူး။
- ဒါဟာလည်း Partial Dependency (တစ်စိတ်တစ်ပိုင်း မှီခိုမှု) ဖြစ်ပါတယ်။ CourseProfessor က composite key ရဲ့ တစ်စိတ်တစ်ပိုင်း (CourseID) အပေါ်မှာပဲ မှီခိုနေပါတယ်။
CourseGrade: အမှတ်က Composite primary key (StudentID နှင့် CourseID) နှစ်ခုစလုံးအပေါ် မှီခိုနေသလား။
- ဟုတ်ပါတယ်။
- ကျောင်းသားတစ်ယောက်ရဲ့ အမှတ်ကို သိဖို့ဆိုရင် ဘယ်ကျောင်းသားလဲ (StudentID) ဆိုတာကိုရော၊ ဘယ်ဘာသာလဲ (CourseID) ဆိုတာကိုပါ နှစ်ခုလုံးသိဖို့လိုပါတယ်။ အဲ့ဒီအချက်အလက် နှစ်ခုထဲက တစ်ခုတည်းဖြင့် အမှတ်ကို မသိရှိနိုင်ပါဘူး။
- ဒါဟာ Fully Functional Dependency (အပြည့်အဝ မှီခိုမှု) ဖြစ်ပါတယ်။ CourseGrade ဟာ composite key တစ်ခုလုံးအပေါ်မှာ မှီခိုနေပါတယ်။

ဒီဥပမာကနေ Full Dependency နှင့် Partial Dependency ကြားက ကွာခြားချက်ကို ရှင်းရှင်းလင်းလင်း နားလည်ပြီလို့ မျှော်လင့်ပါတယ်။

Second Normal Form (2NF) သို့ ပြောင်းလဲခြင်း။

ဒါဆိုရင် ကျွန်တော်တို့ရဲ့ Fig. 3.2. 1NF Orders table ကို second normal form ဖြစ်အောင် လုပ်ကြည့်ကြရအောင်။

ဒီ Fig.3.2. table မှာဆိုရင် Primary key က (OrderID နှင့် BookID) ဖြစ်ပါတယ်။

Dependency တွေကို ကြည့်ရအောင်။

CustomerName, CustomerAddress, OrderDate တို့ဟာ OrderID တစ်ခုတည်းအပေါ်မှာပဲ မှီခိုပါတယ်။ (Partial Dependency)
BookTitle နှင့် Price တို့ဟာ BookID တစ်ခုတည်းအပေါ်မှာပဲ မှီခိုပါတယ်။ (Partial Dependency)
Quantity ကတော့ OrderID နှင့် BookID နှစ်ခုလုံးအပေါ်မှာ မှီခိုပါတယ်။ (Full Dependency)

2NF ဖြစ်ဖို့အတွက် ဒီ Partial Dependency တွေကို ဖယ်ရှားပြီး သက်ဆိုင်ရာ table တွေအဖြစ် ခွဲထုတ်ရပါမယ်။



Fig. 3.3.1: 2NF Orders Table	Fig. 3.3.2: 2NF Order Items Table	Fig. 3.3.3: 2NF Books Table

အခုဆိုရင် table တွေဟာ 2NF စည်းမျဉ်းနှင့် ကိုက်ညီသွားပါပြီ။ ဒါပေမဲ့ ကျွန်တော်တို့ရဲ့ Orders Table ထဲမှာ ပြဿနာတစ်ခု ကျန်နေပါသေးတယ်။ ဒါကြောင့် Third Normal Form (3NF) ကို ဆက်သွားကြပါမယ်။