ဆိုကြပါစို့၊ ပရိုဂရမ်မာ အသစ်တစ်ယောက်ရှိပါတယ်။ တစ်နေ့ သူ့အရာရှိက သူ့ကို အပလီကေးရှင်း အသစ်တစ်ခု ရေးဖို့ အတွက် Database Design ချခိုင်းလိုက်တယ်။ သူလည်း ကြိုးစားပြီး Data Flow Diagram (DFD) တွေ Entity Relationship Diagram (ERD) တွေရေးမယ်ပေါ့ဗျာ။
သူရေးထားတဲ့ Data Model ဟာ မှန်မမှန် သူဘယ်လို လုပ်သိမလဲ ဆိုတာ စဥ်းစားစရာ ဖြစ်တယ်။
အဲ့ဒီနေရာမှာ အသုံးဝင်တာကတော့ Normalisation Theory ပဲဖြစ်တယ်။ Normalisation ဟာ Database Design ရေးသားရာတွင် သင့်တော်သော Relationship များ ဟုတ်မဟုတ်ကို ခွဲခြားနိုင်တဲ့ အခြေခံ အချက်အလက်များကို သတ်မှတ်ပေးထားပါတယ်၊
Normalization ကို စတင်ရေးသားခဲ့သူမှာ E.F.Codd ဆိုသူဖြစ်ပြီး First Normal Form, Second Normal Form နှင့် Third Normal Form ဟူ၍ စတင်သတ်မှတ်ခဲ့ပါသည်။ နောက်ပိုင်းတွင် Boyce-Codd Normal Form ဆိုပြီး Third Normal Form ကို ပြုပြင်ကာ ဖေါ်ထုတ်ခဲ့ပါသေးသည်။ ထို့နောက် ဆက်လက်ပြီး Forth Normal Form, Fith Normal Form, Sixth Normal Form နှင့် Domain/Key Normal Form ဟု ဆိုကာ ဆက်လက် ထွက်ပေါ်လာခဲ့ ပါသေးသည်။
ဒီနေရာမှာတော့ အခြေခံဖြစ်တဲ့ Third Normal Form အထိကို ဖေါ်ပြသွားပါမည်။
First Normal Form
First Normal Form မှာတော့ Relational Model မှာရှိတဲ့ Domain တွေဟာ Atomic Value ရဲ့ အစု ဖြစ်ရမယ် လို့သတ်မှတ်ထားပါတယ်။
ဒီနေရာမှာ Atomic Value ဆိုတာဘာလဲ့ ဆိုတာကို နားလည်ဖို့လိုအပ်ပါလိမ့်မယ်။ ဒီနေရာမှာ သုံတဲ့ Atomic Value ဆိုတာဟာ လက်ရှိအနေအထားထက် ပိုပြီး သေးငယ်အောင် ခွဲစိတ်လို့မရတော့သော တန်ဖိုးတစ်ခု ဆောင်သော အချက် အလက်ကို ဆိုလိုပါတယ်။ ရှင်းလိုက်မှ ပိုရှုပ်သွားမယ်ထင်တယ်။
ဒီလိုပါ။ ဥပမာအားဖြင့် Employee တစ်ယောက်ရဲ့ Birth Date ဆိုတဲ့ Domain တစ်ခုကို ကြည့်ရအောင်။ ’1980/10/20’ အဲ့ဒီ Domain မှာ ‘1980’ , ’10’, ’20’ အစရှိသဖြင့် နှစ် လ ရက် တို့ဖြင့် ဖွဲ့စည်းထားပါသည်။ အဆိုပါ Birth Date အား ရက်၊ လ၊ နှစ် အထိ အသေးစိတ်ခွဲခြားနိုင်မည် ဖြစ်သော်လည်း မွေးနေ့၏ အဓိပ္ပါယ်အား ဆောင်နိုင်တော့မည် မဟုတ်။ ထို့ကြောင့် ၎င်းတို့မှာ Atomic Value ဟုတ်တော့မည် မဟုတ်ပေ။
Domain Value အား Atomic Value ဖြင့်သတ်မှတ်ထားရန် လိုအပ်သည် ဆိုသည်မှာ Relation တစ်ခု၏ Attribute Value သည်လဲ Atomic Value ဖြစ်ရန်လိုအပ်သည်ဟု ဆိုလိုခြင်းဖြစ်ပါသည်။
အောက်ပါ Table နမူနာများသည် Atomic Value မဟုတ်ဟု ဆိုနိုင်ပါသည်။
| Branch | |||
| Branch Name | Place | Phone | Sections |
|---|---|---|---|
| Bahan | Bahan Township | 01-xxxxx-xxxx | Accounting |
| Marketing | |||
| Field Engineering | |||
| Hlal Dan | Kamayut Township | 01-xxxxx-xxxx | Accounting |
| Marketing | |||
အထက်ပါနမူနာထဲတွင် Sections Attribute ၏တန်ဖိုးသည် Atomic Value မဟုတ်ပေ။ ၎င်းတို့အား ထို့ထက်သေးငယ်အောင် ခွဲစိတ်နိုင်ပါသေးသည်။ အထက်ပါ Relation အား First Normalization Form အဖြစ် ပြောင်လဲကြည့်မည် ဆိုပါက အောက်ပါ အတိုင်းရရှိမည် ဖြစ်ပါသည်။
| Branch | |||
| Branch Name | Place | Phone | Sections |
|---|---|---|---|
| Bahan | Bahan Township | 01-xxxxx-xxxx | Accounting |
| Bahan | Bahan Township | 01-xxxxx-xxxx | Marketing |
| Bahan | Bahan Township | 01-xxxxx-xxxx | Field Engineering |
| Hlal Dan | Kamayut Township | 01-xxxxx-xxxx | Accounting |
| Hlal Dan | Kamayut Township | 01-xxxxx-xxxx | Marketing |
တဖန် အောက်ပါ နမူနာအားကြည့်ပါ။ အဆိုပါ Relation သည်လည်း Normalization ပုံမကျသော ပုံစံဖြစ်ပါသည်။
| Employee | |||||
| Name | Branch | Section | Entrance Date | ||
|---|---|---|---|---|---|
| Year | Month | Day | |||
| Mg Mg | Hlal Dan | Accounting | 2012 | 4 | 1 |
| Kaung Htet Aung | Hlal Dan | Marketing | 2012 | 4 | 1 |
| Thidar Swe | Bahan | Development | 2012 | 4 | 1 |
အထက်ပါ Relation တွင် ပါဝင်သော Year, Month နှင့် Day Attribute တို့သည် Entrance Date အား အသေးငယ်ဆုံးဖြစ်အောင် ခွဲစိတ်ထားသည်မှာ မှန်သော်လည်း Entrance Date အနေနှင့် အဓိပ္ပါယ်ဆောင်နိုင်စွမ်းမရှိပေ။ ထို့ကြောင့် ၎င်းတို့မှာ Atomic Value မဟုတ်တော့ပေ။ အဆိုပါ Relation အား First Normalization Form ဖြစ်အောင်ပြောင်းလဲ ထားသည်မှာ အောက်ပါ အတိုင်းဖြစ်ပါသည်။
| Employee | |||||
| Name | Branch | Section | Entrance Date | ||
|---|---|---|---|---|---|
| Mg Mg | Hlal Dan | Accounting | 2012-04-01 | ||
| Kaung Htet Aung | Hlal Dan | Marketing | 2012-04-01 | ||
| Thidar Swe | Bahan | Development | 2012-04-01 | ||
အထက်ပါ Relation များသည် First Normalization Form အဖြစ်ပြောင်းလဲပြီး ဖြစ်သော်လည်း အောက်ပါ ပြဿနာများမှာ ကျန်ရှိနေဆဲ ဖြစ်ပါသည်။
- အကြောင်းတစ်ခုခုကြောင့် Bahan Branch ၏ Place တန်ဖိုးအား ပြောင်းလဲ လိုပါက Bahan ပါဝင်သော Record သုံးခုလုံးအား ပြောင်းလဲပေးရန် လိုအပ်နေပါသည်
- Bahan Branch ၏ Accounting Section အား အခြားသော Section တစ်ခုနှင့် ပူးပေါင်းစေပြီး Section အသစ်တစ်ခု အား ဖွဲ့စည်းလိုသည့် အခါမည်သို့ဖြစ်မည်နည်း။ Section အသစ်တစ်ခု မသတ်မှတ်ရသေးမှီ၊ Bahan ၏ Accounting အား Delete လုပ်မိပါက ၎င်း Record ၏တန်ဖိုးမှာ ပျောက်ပျက်သွားမည်ဖြစ်သည်။ တဖန် Section Name အား null ဖြင့် update လုပ်မည်ဆိုရင်လဲ Primary Key Constraint နှင့် မကိုက်ညီပဲ Error ဖြစ်မည်ဖြစ်သည်
- တဖန် Branch အသစ်တစ်ခု ကို ဖြည့်စွက်လိုပြီး ၎င်း တွင် Section များ မသတ်မှတ်ရသေးပါက ဖြည့်စွက်၍ရမည် မဟုတ်ပေ
Second Normalization Form
Branch Relation တွင် အထက်ဖေါ်ပြပါ ပြဿနာများ ဖြစ်ပွားရခြင်း အကြောင်းမှာ Branch Relation အတွင်းတွင် Branch နှင့်သက်ဆိုင်သော အချက်အလက်များသာမက Section နှင့်ဆိုင်သော အချက်အလက်များလဲ ရောနှောပါဝင်နေသောကြောင့် ဖြစ်ပါသည်။
| Branch | ||||
| Branch Name | Sections | Place | Phone | Section Manager |
|---|---|---|---|---|
| Bahan | Accounting | Bahan Township | 01-xxxxx-xxxx | Pa Pa Aung |
| Bahan | Marketing | Bahan Township | 01-xxxxx-xxxx | Hnin Pwint |
| Bahan | Field Engineering | Bahan Township | 01-xxxxx-xxxx | Than Htike |
| Hlal Dan | Accounting | Kamayut Township | 01-xxxxx-xxxx | Aung Myoe Oo |
| Hlal Dan | Marketing | Kamayut Township | 01-xxxxx-xxxx | Myo Min |
အထက်ပါ နမူနာတွင် Branch Name နှင့် Sections တို့သည် Primary Key များဖြစ်ကြသည်။ Primary Key ၏တန်ဖိုးကို သိရှိပါက Row တစ်ခုလုံး၏ တန်ဖိုးကို သိရှိနိုင်မည်ဖြစ်ပါသည်။ ၎င်းအား Functional Dependency ဟုခေါ်ဆိုပါသည်။ {Branch Name, Sections } တို့အား သိရှိပါက သက်ဆိုင်သော {Place, Phone, Section Manager} တို့ကို သိရှိနိုင်မည် ဖြစ်သည်။
သို့ရာတွင် Place နှင့် Phone တို့အားသိရှိနိုင်ရန် Section အထိ မလိုအပ်ပဲ Branch Name တစ်ခုထဲနှင့်သိရှိနိုင်ပါသည်။
ဆိုနိုင်သည်မှာ {Place, Phone} တို့သည် {Branch Name, Sections} တို့တွင် Fully Dependent မဟုတ်ပဲ Branch Name တွင်သာ Partially Dependent ဖြစ်နေပြီး၊ Section Manager သည်သာ {Branch Name, Sections} ကို မှီခိုနေပါသည်။
အထက်ပါ Relation အား အောက်ဖေါ်ပြပါ အတိုင်ခွဲခြားနိုင်မည်ဖြစ်သည်။
| Branch | |||
| Branch Name | Place | Phone | |
|---|---|---|---|
| Bahan | Bahan Township | 01-xxxxx-xxxx | |
| Hlal Dan | Kamayut Township | 01-xxxxx-xxxx | |
| Branch | |||
| Branch Name | Sections | Section Manager | |
|---|---|---|---|
| Bahan | Accounting | Pa Pa Aung | |
| Bahan | Marketing | Hnin Pwint | |
| Bahan | Field Engineering | Than Htike | |
| Hlal Dan | Accounting | Aung Myoe Oo | |
| Hlal Dan | Marketing | Myo Min | |
ဤကဲ့သို့ Relation တစ်ခု အတွင်းရှိ Primary Key အား Fully Dependent မဖြစ်နေသော Candidate Key မဟုတ်သော အစုအား ဖယ်ထုတ်ကာ သီခြား Relation တစ်ခုအဖြစ် အားလုံးသော Candidate Key မဟုတ်သော Attribute များသည် Primary Key တစ်ခုထဲတွင် မှီခိုမှု့ရှိအောင် ဆောင်ရွက်ထားသော ပုံစံအား Second Normalization Form ဟု ခေါ်ဆိုပါသည်။
Third Normal Form
Second Normal Form ဖြစ်အောင်ရေးသားထားခြင်းဖြင့် Relation တစ်ခု အတွင်းမှာရှိတဲ့ Primary Key မဟုတ်တဲ့ Attribute များအားလုံးကို Primary Key တစ်ခုတည်းကိုသာ မှီခိုမှု့ရှိအောင် ဆောင်ရွက်နိုင်ခဲ့ပြီဖြစ်သည်။ သို့ရာတွင် အောက်ပါ အနေအထားအား ဆက်လက်ကြည့်ပါမည်။
| STUDENT | ||||||
| STUDENT_ID | STUDENT_NAME | DOB | POSTAL_CODE | STREET | TOWNSHIP | DIVISION |
|---|---|---|---|---|---|---|
| 001 | Aung Aung | 1990-10-01 | 201-0042 | No.110 Thit Sar Street | Yankin | Yangon |
| 002 | Nilar | 1995-08-10 | 201-0042 | No. 60 Thit Sar Street | Yankin | Yangon |
| 003 | Mya Mya | 1990-06-01 | 201-0048 | No.110 Padonmar Street | Alon | Yangon |
| 001 | Aung Aung | 1990-10-01 | 201-0048 | No.67 Padonmar Street | Alon | Yangon |
အထက်ပါနမူနာတွင် Primary Key မဟုတ်သော {STUDENT_NAME, DOB, POSTAL_CODE, STREET, TOWNSHIP, DIVISION } တို့သည် Primary Key ဖြစ်သော STUDENT_ID တွင် မှီခိုနေသည်မှာ မှန်ပါသည်။ သို့ရာတွင် {TOWNSHIP, DIVISION } တို့သည် STUDENT_ID တွင်သာမဟုတ်ပဲ အခြားသော Primary Key မဟုတ်သော POSTAL_CODE တွင်မှီခိုနေပြန်သည်။
ထို့ကြောင့် လိပ်စာတန်ဖိုးတူသော Record များကိုလည်း အကြိမ်ကြိမ်ရေးသားနေရသည်ကို တွေ့ရပါသည်။
Third Normalization Form ဖြစ်အောင်ရေးသားခြင်းသည် Primary Key မဟုတ်သော Attribute များအားလုံးသည် Primary Key များကိုသာ မှီခိုမှုရှိအောင်ရေးသားခြင်းဖြစ်ပါသည်။
အထက်ပါနမူနာအား Third Normalization Form ဖြစ်အောင်ရေးသားမည်ဆိုပါက အောက်ပါအတိုင်း ရေးသားရမည်ဖြစ်သည်။
| POSTAL_ADDRESS | ||
| POSTAL_CODE | TOWNSHIP | DIVISION |
|---|---|---|
| 201-0042 | Yankin | Yangon |
| 201-0048 | Alon | Yangon |
| STUDENT | |||||
| STUDENT_ID | STUDENT_NAME | DOB | STREET | POSTAL_CODE | |
|---|---|---|---|---|---|
| 001 | Aung Aung | 1990-10-01 | No.110 Thit Sar Street | 201-0042 | |
| 002 | Nilar | 1995-08-10 | No. 60 Thit Sar Street | 201-0042 | |
| 003 | Mya Mya | 1990-06-01 | No.110 Padonmar Street | 201-0048 | |
| 001 | Aung Aung | 1990-10-01 | No.67 Padonmar Street | 201-0048 | |
အထက်ပါအတိုင်း Third Normalization Form ဖြစ်အောင်ရေးသားခြင်းအားဖြင့် Duplication ဖြစ်သော ဒေတာများအား လျှော့ချနိုင်ပါသည်။ ထို့အပြင် ဒေတာများ၏ မှန်ကန်မှု့ကိုလည်း မြင့်မားအောင် ဆောင်ရွက်နိုင်ပါသည်။
ဤကဲ့သို့မိမိရေးသားထားသော Data Model များအား Normalization Form ဖြစ်အောင်ရေးသားခြင်းအားဖြင့် မှန်ကန်သော Data ဖွဲ့စည်းမှု့ရရှိအောင် ရေးသားနိုင်မှာဖြင်ပါတယ်။
လေးစားစွာဖြင့်
မင်းလွင်
No comments:
Post a Comment