Normalization

ပြီးခဲ့တဲ့ အခန်းဆက်ဖြင့် Normalization သည် Relational Data Modelling အား ရေးသားရာတွင် လိုအပ်ကြောင်း ဖေါ်ပြခဲ့သည်။ ဒီ တစ်ခေါက်မှာတော့ Normalization ကို မည်သို့အသုံးပြုမည် ဆိုသည့်ဘက်မှ ရေးသားသွားပါ ဦးမည်။

ဆိုကြပါစို့၊ ပရိုဂရမ်မာ အသစ်တစ်ယောက်ရှိပါတယ်။ တစ်နေ့ သူ့အရာရှိက သူ့ကို အပလီကေးရှင်း အသစ်တစ်ခု ရေးဖို့ အတွက် 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 ဖွဲ့စည်းမှု့ရရှိအောင် ရေးသားနိုင်မှာဖြင်ပါတယ်။

လေးစားစွာဖြင့်

မင်းလွင်

Normalization of Relation

Relational Database အား ဒီဇိုင်းရေးသားရန်မှာ Relational DBMS မှ ပံ့ပိုးပေးထားသော Data Modeling Function အား အသုံးပြု၍ ရေးသားနိုင်ပါသည်။ Data Modeling တွင် Relational DBMS တွင်မှီခိုမှု့ မရှိသော Logical Modeling နှင့် DBMS အပေါ်မှီခို နေသော Physical Modeling ဟူ၍ရှိပါသည်။ ဤအခန်းတွင် DBMS အပေါ်မှီခိုမှု့မရှိသော Logical Modeling အကြောင်းကို ရေးသားသွား ပါမည်။

Normalization of Relation

Relational Schema တစ်ခုသည် တစ်ခုထက်မကသော Attributes များဖြင့် ဖွဲ့စည်းထားပါသည်။ အတွေ့ အကြုံနဲပါးသော Database ဒီဇိုင်းရေးသားသူ တစ်ဦးက Attributes Group များကို အသုံးပြု၍ Relation Schema အားဖွဲ့စည်း တည်ဆောက်ရာတွင်၊ ရေးသားထားသော Relation Schema သည် အသင့်တော်ဆုံ အနေအထား ဟုတ်မဟုတ်ဆိုသည်ကို ဆုံးဖြတ်ရန် ခက်ခဲပေလိမ့်မည်။ အခြားသော ရေးသားသူတစ်ဦး ဆိုပါက နောက်တစ်မျိုးရေးချင် ရေးပေလိမ့်မည်။

အဆိုပါပြဿနာမျိုးအတွက် Relational Model အားဖေါ်ထုတ်ခဲ့သော E.F Codd မှ Normalization Theory ကို ပြဌာန်းထားခဲ့ပါသည်။ ဤ Normalization အားအသုံးပြုခြင်းအားဖြင့် Relational Schema အားဒီဇိုင်းရေးသားရာတွင် အသင့်တော်ဆုံး Standard တစ်ခုအား ရှာဖွေတွေ့ရှိနိုင်မည် ဖြစ်ပါသည်။ ဤ Normalization Theory သည် Relational Data Model တွင်သာမဟုတ်၊ Conceptual Level Data Modeling နှင့် အခြားသော Data Model Design များတွင်လဲ အသုံးပြုနိုင်ပါသည်။

ဤသို့ဆိုပါက အသင့်တော်ဆုံး အနေအထား Relational Schema ဆိုသည်မှာ အဘယ်နည်း။ အဖြေမှာ Relation  ၏ တန်ဖိုးများအား ပြုပြင်မှု့ပြုလုပ်သည့် အခါမျိုးတွင် Tuple ၏တန်ဖိုးများအကြား မှားယွင်းမှု့များ မဖြစ်သော၊ လက်ရှိအချက်အလက်များ ပြောင်းလဲမှု့ကြောင့် Relation Schema များအား ပြုပြင်ရန်လိုအပ်လာသော အခါ အကျိုးသက်ရောက်မှု့နည်းသော၊ တည်ငြိမ်မှု့မြင့်မားသည့် Schema များကို ဆိုလိုပါသည်။

အသင့်တော်ဆုံးအနေအထား မဟုတ်သည့် Schema များတွင် မည်ကဲ့သို့ပြဿနာများ ဖြစ်ပွါးနိုင်သည် ဆိုသည်ကို အောက်ပါ မေးခွန်းများကို ဖြေဆိုရင်း အဖြေရှာကြည့်ပါမည်။

Employee
ID	Name	Entry	Branch	Location	Phone
1001	Aung Aung	2011-10-01	Yankin	Yangon	01-203-309
1002	Mg Mg	2012-02-01	Yankin	Yangon	01-203-309
1003	Thidar	2011-10-01	Bahan	Yangon	01-512-388
1004	Nilar	2013-06-01	Yankin	Yangon	01-203-309
1005	Mya Mya	2013-10-01	Amarapura	Mandalay	02-546-679

မေးခွန်း ၁

ရန်ကင်းဆိုင်ခွဲအား လမ်းမတော်သို့ပြောင်းရွှေ့သွားပါသဖြင့် အောင်အောင်၏ ဆိုင်ခွဲအား လမ်းမတော်ဟု ပြောင်းလိုပါက မည်သို့ဖြစ်မည်နည်း။

အထက်ပါနမူနာတွင် ရန်ကင်းဆိုင်ခွဲ၌ အောင်အောင်တစ်ယောက်တည်းရှိသည်မဟုတ်။ မောင်မောင်နှင်နီလာတို့လဲရှိကြ၏။ ထို့ကြောင့် အောင်အောင်၏ ဆိုင်ခွဲကိုသာ ပြုပြင်ပါက အချက်အလက်တို့သည် မှန်ကန်တော့မည်မဟုတ်။ မောင်မောင်နှင့် နီလာတို့၏ ဆိုင်ခွဲနှင့်ပတ်သက်သော အချက်အလက်တို့ကိုလဲပြုပြင်ရန် လိုအပ်ပါသည်။



မေးခွန်း ၂

မသီတာ အလုပ်ကနှတ်ထွက်သွားပါသဖြင့် ထိုအချက်အလက်များအား ဖျက်ထုတ်ပစ်ပါက မည်သို့ဖြစ်မည်နည်း။

မသီတာ အလုပ်လုပ်နေသော ဗဟန်းဆိုင်ခွဲမှာ Tuple တစ်ခုထဲတွင်ရှိသောကြောင့်၊ မသီတာ၏ Record အားဖျက်ပစ်ပါက ဗဟန်းဆိုင်ခွဲ၏ အချက်အလက်များလဲ ပျောက်ပျက်သွားနိုင်ပါသည်။



မေးခွန်း ၃

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

Primary Key သည် Employee ID ဖြစ်သောကြောင့် ဝန်ထမ်းမရှိသေးသော ဆိုင်ခွဲများအား ဖြည့်စွက်၍ရနိုင်မည် မဟုတ်ပါ။

တည်ဆောက်ထားသော Relational Schema သည် အသင့်တော်ဆုံ အနေအထားမဟုတ်သောကြောင့် ဤကဲ့သို့ပြဿနာမျာ ဖြစ်ပွားနေရခြင်းဖြစ်ပါသည်။ အမှန်ဆိုပါက အထက်ပါနမူနာတွင် Employee နှင့် Branch တို့၏ အချက်အလက်များသည်၊ schema တစ်ခုထဲတွင် ရေားနှေားနေပါသည်။ ထိုကြောင့် အချက်အလက် တစ်ခုခု ကိုပြုပြင်လိုက်သည်နှင့် အခြားသော အချက်အလက်များ အပေါ် အကျိုးသက်ရောက်မှု့များ ဖြစ်ပေါ်နေရခြင်းဖြစ်ပါသည်။

အထက်ပါ Schema အား အောက်ပါအတိုင်းပြုပြင်လိုက်ပါက အထက်ပါပြဿနာများကို ဖြေရှင်းပြီး ဖြစ်ပါလိမ့်မည်။

Branch
Branch	Location	Phone Number
Yankin	Yangon	01-203-309
Bahan	Yangon	01-512-388
Amarapura	Mandalay	02-546-679

Employee
ID	Name	Entry	Branch
1001	Aung Aung	2011-10-01	Yankin
1002	Mg Mg	2012-02-01	Yankin
1003	Thidar	2011-10-01	Bahan
1004	Nilar	2013-06-01	Yankin
1005	Mya Mya	2013-10-01	Amarapura

ဤအခန်းဖြင့် အသင့်အတော်ဆုံ အနေအထား မရှိသော Relational Schema များ တွင်ဖြစ်တတ်သော ပြဿနာများကို လေ့လာခဲ့ပါသည်။ ဤကဲ့သို့ပြဿနာများအား Normalization နည်းလမ်းများကို အသုံးပြု၍ဖြေရှင်းနိုင်ပါသည်။ နောက်အခန်းဆက်ဖြင့် Normalization Method များအကြောင်းကို ဖေါ်ပြပါဦးမည်။

လေးစားစွာဖြင့် 

မင်းလွင်

Constraint for Data Integrity

Relational Data Model ၏ Function များအတွင်းတွင် မှန်ကန်မှု့ရှိစေရန်ထားရှိနိုင်သော Constraint များသည် လွန်စွာအရေးပါသော အချက်တစ်ခုပင်ဖြစ်၏။ Data Structure အတွင်း Data များအား ပြုပြင်ပြောင်းလည်းမှု့များ ပြုလုပ်သည့်အခါတွင် Database အတွင်း Data များ မှန်ကန်စွာထားရှိနိုင်ရန် အဆိုပါ Constraint များအတိုင်း စီစစ်ပေးပါသည်။ ဤအခန်းတွင် Relational Database ၏ Data များအား မှန်ကန်မှု့ရှိစေရန် ထားရှိသော Constraint များအကြောင်းအား ဖော်ပြသွားပါမည်။

Domain Constraint

Relational Model ၏ Domain Constraint သည်၊ Attribute ၏တန်ဖိုးများသည် အဆိုပါ Domain အတွင်း Atomic Value ဖြစ်ရပါမည်။ ဆိုလိုသည်မှာ Atomic Value များသည် လက်ရှိတန်ဖိုးထက်ပို၍ အသေးစိတ်ခွဲခြား၍ မရနိုင်သောတန်ဖိုးများဖြစ်ရမည်ဟု ဆိုလိုခြင်း ဖြစ်ပါသည်။

Key Constraint

Relational Model ၏ Relation များသည် တူညီသော Tuple များဖြစ်၍ မရပါ။ ၎င်းတို့အား တစ်ခုချင်း ခွဲခြား၍သိရှိနိုင်ရန် လိုအပ်ပါသည်။ ထိုအတွက် Relation တစ်ခုအတွင်းရှိ Attribute တစ်ခု၏ တန်ဖိုး၊ ဒါမှမဟုတ် Attribute များ၏တန်ဖိုးဖြင့် Tuple တစ်ခုချင်းအား ခွဲခြားသတ်မှတ်နိုင်ရန်လိုအပ်ပါသည်။ ဤကဲ့သို့သော Attribute ဒါမှမဟုတ် Attribute အစုအဝေးအား Super Key ဟုခေါ်ဆိုပါသည်။

Relation များတင် အဆိုပါ Relation မှ ပိုင်ဆိုင်သင့်သော Attribute များအား စုစည်း၍ Super Key တစ်ခုအနေနှင့် ကြည့်မြင်နိုင်ပါသည်။ သို့ရာတွင် ဤကဲ့သို့သော Super Key အတွင်းရှိ Attribute များအတွင်းတွင် Tuple အား ခွဲခြားသတ်မှတ်ရာတွင် မလိုအပ်သော Attribute များလည်း ပါဝင်နိုင်ပါသည်။ Tuple အား ခွဲခြားသတ်မှတ်ရန်လိုအပ်သော အနည်းဆုံး Attribute အစုအဝေးအား Key ဟု ခေါ်ဆိုနိုင်ပါသည်။

ဥပမာအားဖြင့် အောက်ပါ Relation အား ကြည့်ပါ။ အမည်မှာ Branch ဖြစ်ပါသည်။

Branch Name, Township, Phone Number အစုအဝေးသည် Tuple တစ်ခုအား ခွဲခြားသတ်မှတ်နိုင်သောကြောင့် ၎င်းသည် Super Key ဖြစ်ပါသည်။ သို့ရာတွင် Tuple တစ်ခုအား ခွဲခြားသိရှိနိုင်ရန်မှာ Branch Name တစ်ခုတည်းနှင့်လည်း သိရှိနိုင်မည် ဖြစ်ပါသည်။ ဤနမှုနာတွင် Branch Name သည် Key ဖြစ်ပါသည်။



Candidate Key


အထက်ဖော်ပြပါအတိုင်း၊ Relation တစ်ခုတွင် ကီးတစ်ခုထက်မက ပိုင်ဆိုင်နိူင်ပါသည်။ အဆိုပါကီးမျိုးအား Candidate Key ဟုလည်းခေါ်ဆိုပါသည်။ အထက်ပါနမူနာတွင် Branch Name, Township, Phone Number တို့သည် Candidate Key အဖြစ်စဥ်းစားနိုင်မည်ဖြစ်သည်။ သို့ရာတွင် မြို့နယ်တစ်ခုအတွင်း ဆိုင်ခွဲတစ်ခုထက်မကရှိမည် ဆိုပါက Township အား Candidate Key အဖြစ် အသုံးပြုနိုင်မည်မဟုတ်ပေ။ အလားတူပင် ဆိုင်တစ်ဆိုင်တွင် ဖုန်းနံပါတ် တစ်ခုထက်မက ရှိမည် ဆိုပါက Phone Number ကိုလည်း အသုံးပြုနိုင်မည် မဟုတ်ပေ။

Employee Relational Schema တွင် Employee ID သည် Relation တစ်ခုလုံးတွင် တစ်ခုတည်းသာ ရှိ့မည်ဖြစ်သေားကြောင့် Candidate Key အဖြစ်အသုံးပြုနိုင်မည် ဖြစ်သည်။ အခြားသေားကီးများအား Candidate Key အဖြစ် အသုံးပြု၍သင့်တော်မည်မဟုတ်ပေ။



Primary Key


Candidate Key များအတွင်းမှ Relational Schema အတွက် အသင့်တော်ဆုံး ကီးတစ်ခုအား Primary Key အဖြစ် သတ်မှတ်အသုံပြုနိုင်ပါသည်။ မည်သည့်ကီးအား Primary Key အဖြစ် အသုံးပြုမည်ဆိုသည်မှာ Database ဒီဇိုင်းရေးသား ရာတွင် စဥ်းစားစရာ ပြဿနာ တစ်ခုဖြစ်ပါသည်။ အထက်ပါနမူနာတွင် Branch Name အား Branch ၏ Primary Key အဖြစ်၎င်း Employee ID အား Employee ၏ Primary Key အဖြစ်၎င်း သတ်မှတ်ထားပါသည်။

Primary Key အဖြစ် အသုံးပြုမည် ဆိုပါက Relation တစ်ခုလုံး အတွင်းရှိ တန်ဖိုးတစ်ခုတည်းကိုသာ အသုံးပြုရမည် ဖြစ်သည်။ တဖန် Primary Key Column အတွင်း တန်ဖိုးမပါပဲ Null အား သတ်မှတ်၍ရမည်မဟုတ်ပါ။



Foreign Key


Relational Schema တစ်ခု၏ Primary Key အား အခြားသေား Attribute များမှ Reference လုပ်နေခြင်း၊ ဒါမှမဟုတ် အခြားသေား Relation ၏ Attribute များမှ Reference လုပ်နေခြင်းတို့ရှိနေ တတ်ပါသည်။ ဤကဲ့သို့  Relation တစ်ခုအတွင်းမှ အခြားသေား Relation တစ်ခု၏ Primary Key အား Reference လုပ်နေသော Key အား Foreign Key ဟု ခေါ်ပါသည်။

အထက်ဖေါပြပါ နမူနာ အတွင်း Employee ၏ Branch Name သည် Branch ၏ Primary Key ဖြစ်သော Branch Name အား Reference လုပ်နေသောကြောင့် ၎င်း သည် Foreign Keyဖြစ်ပါသည်။

Referential Constraint

ဤကဲ့သို့ Relational Schema တစ်ခုအတွင်း ဒါမှမဟုတ် Relational Schema အချင်းချင်းရှိ Attribute တစ်ခု ဒါမှမဟုတ် အများသည် အခြားသေား Attribute တစ်ခု ဒါမှမဟုတ် အများ အား Reference လုပ်နေသော အခါမျိုးတွင် မှန်ကန်မှူ့ရှိစေရန် Referential Constraint များဖြင့် တားမြစ်ထားရပါသည်။ Referential Constraint အား Foreign Key များဖြင့်ရေးသားရပါသည်။

ဥပမာအားဖြင့် Foreign Key ဖြင့် Reference လုပ်နေသော ဒိုမိန်းသည် လတ်တွေ့ရှိမရှိ၊ အကယ်၍ အခြားသော Relational Schema မှ Reference လုပ်နေသော Tuple အား ဖျက်မိပါက မည်သို့ဖြစ်မည် အစရှိသည်တို့အား မှန်ကန်မှု့ရှိစေရန် ကန့်သတ်ချက်များ ထားရှိရမည် ဖြစ်ပါသည်။

 အထက်ပါနမူနာတွင်၊ Employee ၏ Branch Name သည် Branch ၏ Primary Key ဖြစ်သော Branch Name အား Reference လုပ်နေသော Foreign Key ဖြစ်ပါသည်။ အကယ်၍ ဝန်ထမ်းတစ်ဦး သည် တာဝန်ထမ်းဆောင်ရန် ဆိုင်ခွဲမသတ်မှတ်ရသေးပါက Branch Name ၏ တန်ဖိုးသည် Null ဖြစ်ပါမည်။ ဝန်ထမ်းမှလည် ဆိုင်ခွဲအားလည် Reference လုပ်နိုင်မည်မဟုတ်ပေ။

သို့ရာတွင် ဝန်ထမ်း၏ဆိုင်ခွဲအား သတ်မှတ်ပြီး ဆိုပါက ဆိုင်ခွဲအမည်ဖြင့် ဆိုင်ခွဲအား ရှာဖွေနိုင်ရမည် ဖြစ်သည်။ ဝန်ထမ်းတွင်ရေးသားထားသော ဆိုင်ခွဲမှာ လက်တွေ့တွင် တကယ်မရှိပါက အဓိပ္ပါယ်ရှိမည် မဟုတ်ပေ။

တဖန် Employee Relational Schema ၏ Leader ID သည် ၎င်း၏ Primary Key ဖြစ်သော Employee ID အား Reference လုပ်နေပါသည်။ ထို့ကြောင့် Employee တွင် ရေးသားထားသော Leader ID နှင့် Employee သည် လက်တွေ့တွင် တကယ်မရှိ၍မရပေ။

ဤကဲ့သို့ ဒေတာများအား မှန်ကန်မှု့ ရှိစေရန် အထက်ပါ Constraint အား အသုံးပြု၍ရေး သားရမည်ဖြစ်ပါသည်။

ဆက်ပါဦးမည်

မင်းလွင်

Data Manipulation

Data Manipulation သည် Data Modeling ၏ အဓိက အစိတ်အပိုင်းတစ်ခုဖြစ်ပြီး၊ Data များအား အသုံးပြုရာတွင် ကျင့်သုံးသည့် နည်းနာတစ်ခု ဖြစ်ပါသည်။ Data များအား မည်ကဲ့သို့ ထည့်သွင်းမည်၊ မည်ကဲ့သို့ ပြုပြင်မည်ဆိုသည့် စည်းကမ်းများအား သတ်မှတ်ရေးသား နိုင်ပါသည်။

Relational Data Model တွင် အဓိကအားဖြင့်Data များအားအသုံးပြုနည်းနှစ်မျိုးရှိပါသည်။ ၎င်းတို့မှာ Reference နှင့် Update တို့ဖြစ်ကြသည်။ Reference သည် Relation အတွင်းမှ Tuple များအား ရှာဖွေရာတွင်၎င်း၊ Relation များမှ Data များအား ပူးတွဲ၍ ရှာဖွေရာတွင်၎င်း အသုံးပြုပါသည်။ Update လုပ်သည်ဆိုရာ၌၊ Relation အတွင်းသို့ Tuple အား အသစ် ဖြည့်စွက်ရာတွင်၎င်း၊ ရှိပြီးသား Tuple တို့အား ပြုပြင်ရာတွင်၎င်း၊ Tuple များအား ဖျက်ထုတ်ရာတွင်၎င်း အသုံးပြုနိုင်ပါသည်။ Update ပြုလုပ်ရာ၌ Relation များအတွင်း Data များမှန်ကန်မှု့ရှိရန် လိုက်နာစောင့်ထိမ်းသင့်သည့် အချက်များလည်း ရှိကြပါသည်။

Relational Data Model တွင် Data Manipulation အား ပြုလုပ်ရာ၌ Relational Algebra အား အသုံးပြုပါသည်။ Relational Algebra သည် သင်္ချာဘာသာရပ်ဆိုင်ရာ ဖော်ပြမှု့တွင် အတော်လေးကို ကောင်းမွန်သော်လည်း၊ ပရိုဂရမ်မာများက တိုက်ရိုက်ရေးသားရာတွင် အစဉ်ပြေလှသည်ဟု မဆိုနိုင်ပါ။ ထို့ကြောင့် Database Management System များတွင် Data Manipulation အား ပြုလုပ်ရန်အတွက် Query Language များအား ပံ့ပိုးထားလေ့ရှိပါသည်။ Query Language အဖြစ်အသုံးများသည်မှာ SQL ဖြစ်ပါသည်။

SQL အား အသုံးပြု၍ Data Manipulation တွင်အသုံးများသည့် Select, Insert, Update နှင့် Delete လုပ်ရုံသာမက၊ Relation ၏ ဖွဲ့စည်းပုံအား သတ်မှတ်ရာတွင်လည်း အသုံးပြုနိုင်ပါသည်။ Relation များ၏ ဖွဲ့စည်းပုံအား သတ်မှတ်ဖော်ပြရာတွင် အသုံးပြုသော SQL အား Data Definition Language (DDL) ဟု ခေါ်ပြီး၊ Relation များအား Manipulate ပြုလုပ်သော SQL အား Data Manipulation Language (DML) ဟု ခေါ်ဆိုပါသည်။ နောက်ပိုင်းတွင် အသေးစိတ် ဖော်ပြသွားပါဦးမည်။

Relational Algebra

Relational Algebra သည် Relational Data Model အား Manipulate လုပ်ရာတွင် အသုံးပြုသော တွက်ချက်နည်းဖြစ်ပြီး၊ ၎င်းတွင် Set Theory အား အခြေခံသောတွက်နည်းနှင့် Relational Database အတွက် တီထွင်ထားသော တွက်ချက်နည်းတို့ဖြင့် ဖွဲ့စည်းထားပါသည်။

Set Theory မှ အခြေခံထားသော တွက်ချက်နည်းတို့မှာ Union, Difference, Intersection နှင့် Cartesian Product တို့ ဖြစ်ကြပါသည်။ တဖန် Relational Database အတွက် တီထွင်ထားသော တွက်ချက်နည်းတို့မှာ Selection, Projection, Division နှင့် Join တို့ ဖြစ်ကြသည်။ ထို့အပြင် ၎င်းတို့အား ပြုပြင်ထားသော Outer Join နှင့် Outer Union တို့လည်း ရှိကြပါသည်။

Union

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

အစုအတွင်းရှိ တန်ဖိုးများအား နှစ်ခု ဖော်ပြ၍ မရခဲ့ပါ။ ထို့ကြောင့် A နှင့် B တွင် 3, 4 သည် အသီးသီးပါဝင်သော်လည်း A ∪ B = {1,2,3,4,3,4,5,6} ဖြစ်မလာပဲ A ∪ B = {1,2,3,4,5,6} ဖြစ်ခြင်း ဖြစ်ပါသည်။ Relational Algebra တွင်လည်း အလားတူပင် ဖြစ်၏။

Relational Data Model တွင် Union အားအသုံးပြုလိုပါက Relation များ၏ ဖွဲ့စည်းပုံသည် အခြေခံအားဖြင့် တူညီရန်လိုအပ်ပါသည်။ ထိုမှသာ Union Algebra အား အသုံးပြု၍ ရနိုင်မည် ဖြစ်သည်။ ဥပမာအားဖြင့် ရန်ကင်းရုံးနှင့် လသာရုံးရှိ ဝန်ထမ်းများအား နမှုနာအနေနှင့် အသုံးပြုကြည့်ပါမည်။

အထက်ပါအတိုင်း U Ba သည် Yankin မှာကော Lathar မှာပါ Manager ဖြစ်သောကြောင့် Yankin_Lathar တွင် တစ်ခုတည်းသာပါဝင်ပါသည်။

Difference

Difference သည် Relation တစ်ခုအတွင်းမှ အခြားသော Relation တစ်ခု၏ Tuple များအား နှုတ်ထုတ်သည့် တွက်နည်း ဖြစ်ပါသည်။ အထက်ပါအတိုင်း Yankin နှင့် Lathar အား နမှုနာ အဖြစ်ပြန်လည် စဉ်းစားကြည့်ပါမည်။

Lathar တွင်ပါဝင်သော U Ba အား Yankin အတွင်းမှ နှုတ်ထုတ်သွားပါသည်။ တဖန် Lathar - Yankin အား စဉ်းစားကြည့်ပါမည်။

Yankin အတွင်းမှ Lathar တွင်ပါဝင်သော U Ba အား နှုတ်သွားပါမည်။ ဤနေရာတွင် သတိပြုရန်မှာ Yankin - Lathar သည် Lathar - Yankin နှင့် မတူညီသည့် အချက်ပင် ဖြစ်သည်။

Intersection

Relation နှစ်ခုလုံးတွင်ပါဝင်သော Tuple အား ရှာထုတ်ပေးနိုင်သော တွက်ချက်နည်း ဖြစ်ပါသည်။

အထက်ပါအတိုင်း Yankin နှင့် Lathar တွင်ပါဝင်သော U Ba အား ရှာဖွေပေးနိုင်ပါသည်။

Cartesian Product

Relation များတွင်ပါဝင်သော Tuple များ၏ တန်ဖိုးများအား ဆက်တွဲပူးပေါင်းပေးနိုင်ပါသည်။ ဥပမာအားဖြင့် Yankin နှင့် Product တို့၏ Tuple တို့အား အသုံးပြု၍ Cartesian Product တွက်နည်းဖြင့် တွက်ချက်ကြည့်ပါမည်။

Yankin တွင် Tuple ၄ခုပါ၍ Project တွင် Tuple ၃ခု ပါဝင်သောကြောင့် ရလဒ်သည် ၁၂ခု ဖြစ်နေမည် ဖြစ်ပါသည်။

Selection

Selection ဆိုသည်မှာ ရှာဖွေလိုသည့် Relation တစ်ခုမှ၊ ရှာဖွေလိုသည့် အကြောင်းအချက်နှင့် ကိုက်ညီသော Tuple များအား ရှာထုတ်၍ Relation အား ဖွဲ့စည်းပါသည်။ ရှာဖွေရန် အကြောင်းအချက်များအား ရေးသားရာတွင် Relation ၏ Attribute နှင့် တန်ဖိုးများအား၎င်း၊ Attribute အချင်းချင်းအား၎င်း နှိုင်းယှဉ်၍ ရေးသားရပါသည်။ အသုံးပြုနိုင်သော နှိုင်းယှဉ် Operator များမှာ =, <>, >, >=, <= တို့အား အသုံးပြုနိုင်သည်။ ထို့အပြင် Logical Operator များဖြစ်ကြသော AND, OR နှင့် NOT တို့အား အကြောင်းအချက်များအကြားတွင် အသုံးပြုနိုင်ပါသည်။

Projection

Relation တစ်ခုအတွင်းမှ ရှာဖွေလိုသည့် Attribute များအား ရွေးချယ်၍ အခြားသော Relation တစ်ခုအား ဖွဲ့စည်းထားခြင်းကို Projection ဟု ခေါ်ဆိုပါသည်။ မှုလ Relation များတွင် တူညီသော Tuple များမရှိသော်လည်း၊ Projection လုပ်၍ ရလာသော Relation များတွင် Tuple များ၏ တန်ဖိုးမှာ တူညီသွားနိုင်သော်လည်း၊ ထိုအခါမျိုးတွင် တူညီသော အခြား Tuple များအား ဖယ်ထုတ်၍ တစ်ခုတည်းကိုသာ ဖော်ပြပေးမည် ဖြစ်ပါသည်။

Join

Relation နှစ်ခုမှ သတ်မှတ်ချက်များနှင့် ကိုက်ညီသော Tuple များအား ရှာဖွေ၍ အခြားသော Relation တစ်ခုအား တည်ဆောက်သောနည်းအား Join ဟု ခေါ်ဆိုပါသည်။ Relation တစ်ခုအား Join လုပ်ရာတွင် Domain တစ်ခုအတွင်းမှ ဖြစ်သော Attribute များပါဝင်နေတတ်ပါသည်။ ထိုအခါမျိုးတွင် ၎င်းတို့အတွင်းမှ တစ်ခုတည်းကိုသာယူ၍ ဖွဲ့စည်းသော Relation အား Natural Join ဟု ခေါ်ဆိုပါသည်။

Outer Join

Relation များအား Join လုပ်ရာ၌ သတ်မှတ်ချက်နှင့် တူညီသော Tuple များကိုသာ ရှာဖွေ၍ Relation အား ဖွဲ့စည်းခဲ့၏။ ထို့ကြောင့် BRANCH b_name သည် Kamaryut နှင့် Bahan တို့သည် Join ရလဒ်တွင် ပါဝင်ခြင်းမရှိခဲ့ပါ။ သို့ရာတွင် ဘယ်ဘက်ရှိ Relation ရှိ Tuple များအား အားလုံးဖော်ပြ၍၊ ညာဘက် Relation ရှိ Attribute များအား NULL ဖြင့် ဖော်ပြသောနည်းအား LEFT OUTER JOIN ဟု ခေါ်ဆိုပြီး၊ ညာဘက်ရှိ Tuple များအား အားလုံးဖော်ပြ၍ ညာဘက်ရှိ Attribute များအား မပါဝင်ပါက NULL ဖြင့် ဖော်ပြသောနည်းအား RIGHT OUTER JOIN ဟု ခေါ်ဆိုပါသည်။ နှစ်ဘက်စလုံးမှ Tuple များအား ဖော်ပြ၍၊ ကိုက်ညီမှု့မရှိသော Attribute ၏ တန်ဖိုးများအား NULL ဖြင့် ဖော်ပြခြင်းအား FULL OUTER JOIN ဟု ခေါ်ဆိုပါသည်။

Outer Union

Relation များအား Union ပြုလုပ်ရန် ၎င်းတို့၏ ဖွဲ့စည်းထားသော ဖွဲ့စည်းပုံမှာတူညီဖို့လိုအပ်ပါသည်။ သို့ရာတွင် Outer Union အား အသုံးပြုပါက ဖွဲ့စည်းပုံမတူညီသော Relation များအားလည်း Union ပြုလုပ်၍ ရနိုင်ပါသည်။ ရလဒ် Tuple ၏ မပါဝင်သော Attribute ၏ တန်ဖိုးများအား NULL ဖြင့် ဖော်ပြမည် ဖြစ်ပါသည်။

ဆက်ပါဦးမည်။ လေးစားစွာဖြင့်။

မင်းလွင်

Relational Data Structure

Data Model တစ်ခုဖြစ်သော Relational Model သည် ၁၉၇၀ခုနှစ် ကတည်းက E. F. Codd မှ စတင်တီထွင်ခဲ့ပါသည်။ Relational Model သည် ရိုးရှင်းသော ဖွဲ့စည်းပုံနှင့် သင်္ချာဘာသာရပ်တို့အပေါ် အခြေခံ၍ တည်ဆောက်ထားသောကြောင့် စတင်ကာစအချိန်ကတည်းက နည်းမျိုးစုံဖြင့် သုတေသန ပြုလာခဲ့ကြပါသည်။ ထိုမှတဆင့် Relational Model အား အခြေခံသော Database Management System များ အများအပြားပေါ်ပေါက်လာခဲ့ပါသည်။ ထို့အပြင် Relational Model ၏ Query Language ဖြစ်သော SQL သည် International Standard တစ်ခုလည်း ဖြစ်ပါသည်။

ရှေ့အခန်းဆက်များတွင် ဖော်ပြခဲ့သလို Data Model သည် အခြေခံအားဖြင့် Data ၏ဖွဲ့စည်းပုံ၊ Data အား အသုံးပြုပုံနှင့် Data အား စစ်မှန်စေရန် စီးမျဉ်းသတ်မှတ်ပုံတို့ဖြင့်ဖွဲ့စည်းထားသည်ဟု ဖော်ပြခဲ့၏။ ယခုတစ်ခေါက်တွင် Relational Data Model ၏ Data Structure အကြောင်းကို ဖော်ပြသွားပါဦးမည်။

Relation ဆိုသည်မှာ

Relational Data Model တွင် အသုံးပြုသော အခြေခံ Data ဖွဲ့စည်းပုံမှာ ၎င်း၏အမည်တွင်ပါဝင်သော Relation အပေါ်တွင် အဓိကထားပါသည်။ Relation ဆိုသောစကားလုံးမှာ Data Modelling ဘာသာရပ်တွင် အသုံးများပြီး၊ မရှုပ်ထွေးစေရန် ဤနေရာတွင် ဖော်ပြသော Relation သည် Relational Data Model ၏ Relation ကိုသာ ရည်ညွှန်းသည်ဆိုသည်ကို မှတ်ထားစေလိုပါသည်။

Relational Data Model တွင် Database အား Relation များ၏အစုအဝေးတစ်ခု အနေနှင့် ဖော်ပြလေ့ရှိပြီး၊ Relation ဆိုသည်မှာ Attribute များနှင့် ဖွဲ့စည်းထားပြီး၊ Relation တွင်ပါဝင်သော Attribute ၏ တန်ဖိုးအစုံအား Tuple ဟု ခေါ်ဆိုပါသည်။

အထက်ပါပုံတွင် Branch နှင့် Employee ဟု အမည်ရသော Relation နှစ်ခုရှိပါသည်။ Branch Relation သည် b_name, b_township နှင့် b_phone ဟုအမည်ရသော Attribute များဖြင့်ဖွဲ့စည်းထားပါသည်။ ၎င်းတွင်ပါဝင်သော တန်ဖိုးအစုအဝေးများသည် Tuple များဖြစ်ကြပါသည်။ ဥပမာအားဖြင့် [Mg Mg, Kanbe, 4/4/2012] သည် Employee Relation ၏ Tuple တစ်ခု ဖြစ်ပါသည်။

အထက်ဖော်ပြပါအချက်များသည် ယနေ့တိုင်အသုံးပြုခဲ့သော File ၏ File, Record, Data name အစရှိသည်တို့နှင့် ထူးခြားမည်မဟုတ်ပေ။ သို့ရာတွင် ရှေ့တွင်ဖော်ပြမည့် အချက်များသည် File တွင် မပါရှိသော အချက်အလက်များ ဖြစ်ကြပါသည်။

သင်္ချာဘာသာရပ်ဆိုင်ရာ အမြင်

Relational Data Model သည် သင်္ချာဘာသာရပ်ဆိုင်ရာ သီအိုရီအပေါ်အခြေခံထားပါသည်။ အသုံးပြုနေသော သီအိုရီမှာ Set Theory ဖြစ်ပါသည်။

အထက်ပါတွင်ပြထားသော အကြောင်းအရာများအား စဉ်းစားပါမည်။ Branch နှင့် Employee Relation တို့သည် Branch Name, Township, Phone Number, Employee နှင့် Entry Date အစရှိသည့် Domain တို့အား ပေါင်းစပ်၍ ဖြစ်တည်ပါသည်။ Domain များသည် သင်္ချာဘာသာရပ်ဆိုင်ရာ အစု (set) ဖြစ်ပါသည်။ Set ဆိုသည်မှာ တူညီသော ကန့်သတ်ချက်အား ပြည့်စုံသည့် အရာများအား စုဝေးထားသော အစုဖြစ်ပါသည်။ အစုအတွင်းပါဝင်သော အချက်အလက်များအား Element ဟု ခေါ်ဆိုပါသည်။ သို့ရာတွင် Relational Data Model တွင် အသုံးပြုသော Domain သည် ပါဝင်သော အချက်အလက်များအား ဒီထက်ပို၍ အသေးစိတ်ခွဲခြား၍မရနိုင်သော၊ အဓိပ္ပါယ်တစ်ခုအားပိုင်းဆိုင်သော အချက်အလက်များဖြင့် ဖွဲ့စည်းထားသော အစုဖြစ်ပါသည်။

အသီးသီးသော Domain တို့မှ Element များအား တစ်ခုစီထုတ်၍ စုစည်းထားသော အစုအား Direct Product ဟု ခေါ်ဆိုပါသည်။ ဥပမာအားဖြင့် Branch Name, Township, Phone Number တို့မှဖြစ်သော Direct Product ၏ Element တစ်ခုသည် "Kanbe","Yankin","01-648-232" ဖြစ်ပြီး၊ ဤကဲ့သို့ အစီအစဉ်တကျစုစည်းထားသော အစုံအား Tuple ဟု ခေါ်ပါသည်။ ဤ Direct Product တွင် Branch Name 5 ခု၊ Township 3 ခုနှင့် Phone Number 5 ခု ပါဝင်သောကြောင့်၊ Tuple သည် စုစုပေါင်း 5 × 3 × 5 = 45 ခု ရှိနိုင်ပါသည်။ သို့ရာတွင် အဆိုပါ Tuple အားလုံးသည် လက်တွေ့တွင် အမှန်တကယ်ရှိနိုင်သော Data များ မဖြစ်နိုင်ပါ။ လက်တွေ့ အမှန်ရှိနိုင်သော အစုသည် အဆိုပါ Direct Product ၏ အစိတ်အပိုင်းတစ်ခု ဖြစ်နိုင်ပြီး ၎င်းအား Subset ဟု ခေါ်ဆိုပါသည်။ ၎င်း Subset သည် Relation ဖြစ်ပါသည်။

တဖန် Relation အား ဖြစ်တည်စေသော Domain များအား ဖော်ပြရေးသားထားသည်ကို Relation Schema ဟု ခေါ်ပါသည်။ Relation Schema အား R1(A1, A2, A3 ... An) ဟု ဖော်ပြနိုင်ပါသည်။

အထက်ပါနာ့မှုနာတွင် Branch Relation သည် Branch Name, Township, Phone Number Domain တို့ဖြင့် ဖွဲ့စည်းထားပြီး၊ ၎င်း၏ Relation Schema အား Branch (b_name, b_township, b_phone) ဟု ဖော်ပြနိုင်ပါသည်။ Branch Relation ၏ b_name attribute သည် Branch Name Domain မှလာသော အချက်အလက်များ ဖြစ်ပြီး၊ b_township သည် Township မှလာပြီး၊ b_phone သည် Phone Number Domain မှ အချက်အလက်များ ဖြစ်ပါသည်။

တဖန်  Employee Relation ၏ branch attribute သည်လည်း Branch Name Domain မှ အချက် အလက်များ ဖြစ်ပါသည်။ ဤနမှုနာတွင် Branch Relation ၏ b_name နှင့် Employee Relation ၏ branch တို့သည် Branch Name Domain မှ အချက်အလက်များဖြင့် ဖွဲ့စည်းထားပါသည်။

Relation ၏ ထူးခြားချက်

Relation များတွင် ယခင်အသုံးပြုခဲ့သော File များနှင့် မတူသည့် ထူးခြားချက်များရှိကြပါသည်။ ၎င်းတို့မှာ အောက်ပါအတိုင်း ဖြစ်ကြသည်။

1. Tuple များ၏ အစီအစဉ်မစောင့်တည်မှု့
   Relation များသည် Set များဖြစ်သောကြောင့်၊ Set တစ်ခုအတွင်းရှိ Element များတွင် အစီအစဉ်အား ဖော်ပြနိုင်ခြင်းမရှိသလို Relation များ၏ Tuple များတွင်လည်း အစီအစဉ်အား ထိမ်းသိမ်းဖော်ပြနိုင်ခြင်း မရှိပါ။ ထို့ကြောင့် Relation Schema တွင်လည်း အစီအစဉ်အား ဖော်ပြနိုင်ရန် ရေးသားထားခြင်းမရှိပါ။ သို့ရာတွင် Relation များအား အသုံးချရာတွင် ၎င်း၏ Attribute တစ်ခုဒါမှမဟုတ် အတွဲလိုက် အစီအစဉ်အား ဖော်ပြနိုင်ရန် စီမံနိုင်စွမ်းရှိပါသည်။
2. Tuple များ၏ တန်ဖိုးမတူညီမှု့
   Set များတွင် တူညီသော Element များအား ထည့်သွင်း၍မရနိုင်သလို၊ Relation များတွင်လည်း တန်ဖိုးတူညီသော Tuple အား တစ်ခုထက်ပို၍ ပိုင်ဆိုင်ခွင့်မရှိပါ။ တနည်းဆိုရသော် Tuple များအား တစ်ခုနှင့်တစ်ခု ခွဲခြားနိုင်ရမည် ဖြစ်သည်။
3. Attribute များ၏ တန်ဖိုးများသည်အသေးငယ်ဆုံးအဓိပ္ပါယ်ဆောင်သော တန်ဖိုးဖြစ်ရမည်
   Relation အားဖွဲ့စည်းထားသော Attribute များ၏တန်ဖိုးသည် ဖွဲ့စည်းပုံအရ ထပ်မံခွဲစိတ်၍မရနိုင်သော အသေးငယ်ဆုံး အဓိပ္ပါယ်ဆောင်သည့် အချက်အလက်များဖြစ်ရပါမည်။

ယခုတစ်ခေါက်တွင် Relational Data Structure နှင့်ပတ်သက်၍ ဖော်ပြခဲ့၏။ နောက်ရက်များတွင် Data Manipulation နှင့် Integrity Constraint နှင့်ပတ်သက်၍ ဖော်ပြသွားပါဦးမည်။

လေးစားစွာဖြင့်။

မင်းလွင်

Metadata Management

Deta Modeling ဘာသာရပ်တွင် Data Definition Language ဖြင့် ရေးသားသတ်မှတ်ထားသော အချက်အလက်များနှင့်၊ လက်ရှိ အသုံးပြုနိုင်သော Data များအား ခွဲခြားကြည့်မြင်ပါသည်။ Data Definition Language ဖြင့်သတ်မှတ်ထားသော Data များ၏ ဖွဲ့စည်းပုံကို ဖော်ပြပေးနိုင်သော  အချက်အလက်များအား Schema ဟုခေါ်ဆိုပြီး၊ Metadata ဟုလည်း ခေါ်ဆိုလေ့ရှိပါသည်။

Metadata  သည် Data Definition ၏ အခြေခံ အယူအဆဖြစ်သော Entity Type, Attributes နှင့် Relation များအား ဖော်ပြနိုင်သော Data များဖြစ်ကြပြီး၊ Entity အဖြစ် သိမ်းဆည်းထားသော အချက်အလက်များသည် Data များ ဖြစ်ကြပါသည်။ ထို့ကြောင့် လက်တွေ့ အသုံးပြုနေသော Data များအား မကြာခဏ Update လုပ်မည်ဖြစ်သော်လည်း၊ Database Design နည်းအားဖြင့် ရေးသားထားသော Metadata များမှာမူ တစ်ခါရေးပြီးပါက Data များလောက် Update လုပ်ဖြစ်မည် မဟုတ်ပေ။

Metadata Management

DBMS များ၏ Data Definition Function အား အသုံးပြု၍ ရေးသားထားသော Metadata များအား၊ DBMS ၏ DDL Processor များဖြင့် အလုပ်လုပ်စေကာ၊ DBMS မှ Data များအား Manipulate လုပ်သည့်အခါများတွင် Reference လုပ်ကာ အသုံးပြုပါသည်။ ထို Metadata များအား သိမ်းဆည်းထားသော နေရာအား Repository ဟု ခေါ်ဆိုပါသည်။

Repository အတွင်းရှိ Metadata များအား Management ပြုလုပ်ရန် DBMS မှ ပြင်ဆင်ပေးထားသော Software များနှင့်၊ DBMS အတော်များများတွင် အသုံးပြုနိုင်သည့် အခြားသော အဖွဲ့အစည်းများမှ ရေးသားထားသော Software များအား အသုံးပြုနိုင်ပါသည်။ ဘယ်လို Software ကိုပဲ သုံးသုံး Repository များကိုတော့ Database အတွင်းတွင် တည်ဆောက်ကြသည်က များ၏။

အသုံးပြုသော Software အပေါ်မှုတည်၍ Management ပြုလုပ်နိုင်သော အချက်အလက်များ၏ ပမာဏမှာမူ ကွာခြားတတ်ပါသည်။ Reference လုပ်နိုင်သည့် ပမာဏ အပေါ်မှုတည်၍ Metadata များအား အောက်ပါအတိုင်း သတ်မှတ်ထားပါသည်။

• System Catalog
• Data Dictionary
• Information Resource Repository
• Repository

MySQL Workbench ကဲ့သို့သော DBMS မှ ထုတ်ပြန်ထားသော Software များမှာမူ System Catalog များအထိ Management လုပ်နိုင်ပြီး၊ Third Party များမှ Support လုပ်ထားသော CASE ကဲ့သို့သော Software များမှာမူ System Catalog အထိ Management လုပ်နိုင်ခြင်း မရှိကြပေ။

Metadata Management အဆင့်များ

Repository တွင်ရှိသော Metadata များနှင့် Data များအကြား ပတ်သက်မှု့ကို အဆင့်ဆင့် Management လုပ်စေသည့်နည်းကို အသုံးပြု၍ Management ပြုလုပ်ပါသည်။ Repository သည် DBMS အတွင်းတွင် Manage လုပ်ထားသော Database များ၏ Metadata များအား Management ပြုလုပ်ရန်၊  ထိုအထက်တွင် Metadata များအား ပြန်လည် အသုံးပြုပါသည်။

အပေါ်ဆုံး  အဆင့်ရှိ Metadata များမှ ကြည့်ပါက၊ ၎င်း၏ အောက်အဆင့်ရှိ Metadata များသည် ၎င်း၏ Data များ ဖြစ်ကြပြီး၊ အောက်အဆင့်ရှိ Metadata မှ ကြည့်ပါက အပေါ်အဆင့်ရှိ data များသည် ၎င်းတို့၏ Metadata များ ဖြစ်ကြပါသည်။

အထက်တွင် ဖော်ပြထားသောပုံသည် ISO/IEC 10027 ဖြစ်သော IRDS (Information Resource Dictionary System) framework အား အခြေခံထားပြီး၊ Metadata ၏ Level အဆင့်ဆင့်အား ဖော်ပြထားပါသည်။ Application Level သည် Application များတွင် အသုံးပြုသော Data များအား Manage လုပ်နေသော Level ဖြစ်ပြီး၊ IRD Level၊ IRD Definition Level နှင့် IRD Definition Schema Level တို့သည်၊ Metadata များအား Manage လုပ်နိုင်သော Level တို့ဖြစ်ကြပါသည်။

ဆက်ပါဦးမည်။ လေးစားစွာဖြင့်

မင်းလွင်

Relation

ကျွှန်တော်တို့ နေထိုင်ရာ လက်တွေ့ လောကကြီးတွင် ဖြစ်ပျက်မှု့ တစ်ခုနှင့် တစ်ခု အကြား၌ ပတ်သက်မှု့ဆိုသည်မှာ ရှိကြမြဲပင် ဖြစ်၏။ ဤကဲ့သို့ အချင်းခြင်း အပြန်အလှန် ပတ်သက်မှု့အား Data Model ဘာသာရပ်၌ Entity များ၏ Relationship ဟု ခေါ်ဆို၏။ Relationship သည် Entity များ၏ အပြန်အလှန်ပတ်သက်မှု့၏ သတ်မှတ်ချက်များကို ရှင်းလင်းစွာ ဖော်ပြပေးနိုင်ပါသည်။ ဤအခန်းဖြင့် Entity များအကြားတွင် အပြန်အလှန် ပတ်သက်မှု့များရှိကြရာတွင် Entity တစ်ခုအား ပြုပြင်ပြောင်းလည်းမှု့ တစ်ခု ဖြစ်ပေါ်ရာ၌ အခြားသော Entity အား မည်သို့ အကျိုးသက်ရောက်မှု့ ရောက်ရှိစေသည်ကို လေ့လာသွားမည် ဖြစ်ပါသည်။

ဥပမာအားဖြင့် အောက်ပါ Entity များအကြား၌ရှိသော ပတ်သက်မှု့ကို စဉ်းစားကြည့်ပါမည်။

• ဆိုင်ခွဲ နှင့် ဝန်ထမ်း အကြားတွင် အလုပ်လုပ်နေကြသည်ဟူသော ပတ်သက်မှု့ ရှိပါသည်။
• ထုတ်လုပ်ရေးကုမ္ပဏီနှင့် ကုန်ပစ္စည်း တို့အကြားတွင် ကုန်ထုတ်လုပ်သည် ဟူသော ပတ်သက်မှု့ရှိပါသည်။

ပတ်သက်မှု့အား ဖော်ပြရာတွင် Entity များ၏ တန်ဖိုး အရေအတွက်ကိုလည်း ဖော်ပြရန်လိုအပ်ပါသည်။ ၎င်းအား cardinality ဟု ခေါ်ဆိုပါသည်။ ဥပမာအားဖြင့် ဆိုင်ခွဲတစ်ဆိုင်တွင် ဝန်ထမ်း ၁၀ဦး အလုပ်လုပ်နေကြသည်ဟု စဉ်းစားကြည့်ကြပါ။ ဆိုင်ခွဲတစ်ဆိုင်တွင် ဝန်ထမ်း တစ်ယောက်ထက်မက အလုပ်လုပ်နေသည်ဟု ဖော်ပြနိုင်ပါသည်။ Data Modelling ဘာသာရပ်၌ အဆိုပါ ပတ်သက်မှု့အား 1:n ဟု ဖော်ပြလေ့ရှိ၏။ ဘယ်ဘက်တွင်တည်ရှိသော ဆိုင်ခွဲက 1 ဖြစ်ပြီး ညာဘက်တွင်ရှိသော ဝန်ထမ်းက n ဖြစ်သည်ဟု ဖော်ပြနေခြင်း ဖြစ်ပါသည်။

တဖန် 1 : n >= 0 ဟု ရေးသားထားပါက၊ ဘယ်ဘက်က ၁ ဖြစ်ပြီး ညာဘက်ခြမ်းရှိ Entity က ၀ သို့မဟုတ် အများဟု ဖော်ပြနေပါသည်။ 1 : n >= 1 ဟု ရေးသားထားရာတွင် ညာဘက်ခြမ်းသည် 1 သို့မဟုတ် အများဟု ဖော်ပြနေပါသည်။ ဤအခြေအနေမျိုးအား Data Model တွင် 1 : n ဟု လည်း ဖော်ပြလေ့ရှိ၏။

ဆိုင်ခွဲနှင့် ဝန်ထမ်းအား လက်တွေ့အနေအထားဖြင့် ပြန်လည်စဉ်းစားကြည့်ပါမည်။ ဘယ်ဘက်ချမ်းတွင် ဆိုင်ခွဲ ရှိပြီးညာဘက်ချမ်းတွင် ဝန်ထမ်းဆိုသော Entityတို့ ရှိကြ၏။ ၎င်းတို့ကြားတွင် အလုပ်လုပ်နေသည် ဟုဆိုသော Relationship ရှိပြီး ပတ်သက်ပုံမှာ 1:n ဖြစ်သည်။

ဆိုပါ အနေအထားမျိုးသည် ဆိုင်ခွဲအတွင်းတွင် အလုပ်သမား တစ်ဦးလည်းရှိနိုင်သည်။ တစ်ဦးထက် မကလည်း ရှိနိုင်သည် ဟု ဖော်ပြနေပါသည်။

အထက်ပါ အနေအထားမျိုးသည် ဆိုင်တစ်ဆိုင်တွင် အလုပ်သမားလည်း ရှိချင်ရှိမည်။ မရှိချင်လည်း မရှိမည် ဟု ဖော်ပြနေပါသည်။ တဖန် လက်တွေ့ဘဝတွင် အောက်ပါအနေအထားမျိုးလည်း ရှိတတ်ပါသေးသည်။

Many to Many ပတ်သက်မှု့မျိုးဖြစ်ပါသည်။ နှစ်ဘက်စလုံးသည် အများဖြစ်နိုင်သည့်အခါမျိုး ဖြစ်ပါသည်။ ဝန်ထမ်းတစ်ဦးသည် ဆိုင်တစ်ဆိုင်ထက်မက တာဝန်ယူနေတတ်ပြီး၊ ဆိုင်တစ်ဆိုင်တွင်လည်း ဝန်ထမ်းတစ်ဦးထက်မက အလုပ်လုပ်နေသည့်အခါမျိုး ဖြစ်ပါသည်။ ထိုအခါမျိုးတွင် ကြားခံ Entity တစ်ခုကို တည်ဆောက်ပြီး အသုံးပြုလေ့ရှိပါသည်။

အထက်ပါအတိုင်း ဆိုင်ခွဲနှင့် ဝန်ထမ်းတို့အား တာဝန်နှင့် အသီးသီး One to Many ပတ်သက်သည် ဟု ပြောင်းလည်းဖော်ပြလေ့ ရှိပါသည်။

Relation အမျိုးအစား

Entity တစ်ခုနှင့် တစ်ခုတို့၏ ပတ်သက်မှု့တို့ကို Relationဖြင့် ဖော်ပြရာတွင် အမျိုးအစား ၃မျိုးခွဲခြား ထားပါသည်။

1. General Relationship
2. Composed Of Relationship
3. Generalization

General Relationship



General Relationship ဆိုသည်မှာ Entity တစ်ခုနှင့် တစ်ခုအကြားတွင် အထွေအထူးအကြောင်း အရာ သတ်မှတ်ချက်များ မရှိသော ပတ်သက်မှု့ကိုဆိုလိုပါသည်။ ဥပမာအားဖြင့် အောက်ပါအတိုင်း ဖြစ်ပါသည်။

• [ဆိုင်ခွဲ] နှင့် [အလုပ်သများ] အကြားတွင် [အလုပ်လုပ်သည်] ဟူသော ပတ်သက်မှု့ရှိ၏။
• [ကုန်ထုတ်လုပ်ငန်း]နှင့် [ထုတ်ကုန်] အကြားတွင် [ထုတ်လုပ်သည်]ဟူသော ပတ်သက်မှု့ရှိ၏။

Composed of Relationship


Composed of Relationship ဆိုသည်မှာ Entity တစ်ခုသည် အခြားသော Entity ၏ တစ်စိတ်တစ်ဒေသ ဖြစ်သော အခါမျိုးတွင် ဖော်ပြလေ့ရှိသော ပတ်သက်မှု့ တစ်ခုဖြစ်ပါသည်။ ထို့ကြောင့် Composed of Relationship အား Has A - ၊ Part of - ဒါမှမဟုတ် Aggregation ဟုလည်း ခေါ်ဆိုပါသည်။ အောက်ပါ ဖွဲ့စည်းပုံမျိုးကို Composed of Relationship ဟု ခေါ်ဆိုပါသည်။

• [ကား]သည်[ကားဘီး]လေးလုံး[အင်ဂျင်]တစ်လုံး[လက်ကိုင်]တစ်ခု အစရှိသည်ဖြင့် ဖွဲ့စည်းထား၏။
• [ကား]တစ်စီးတွင်[ကားဘီး]လေးလုံး[အင်ဂျင်]တစ်လုံး[လက်ကိုင်]တစ်ခု အစရှိသည်ဖြင့် ပါဝင်ကြပါသည်။
• [ကားဘီး]သည် [ကား] ၏ အစိတ်အပိုင်းတစ်ခု ဖြစ်သည်။

Generalization


Generalization နှင့် ပတ်သက်၍ ကျွှန်တော်သည် English လိုရှင်းလင်းချက်များကို ဖက်ကြည့်၍လည်း နားလည်ပါသည်။ ဂျပန်လိုလည်း ဖတ်ကြည့်၍လည်း နားလည်ပါသည်။ သို့ရာတွင်မြန်မာလို မည်ကဲ့သို့ ရှင်းပြရမည်ကို မသိပါ။ အဓိကမှာ Abstraction ကို မည်သို့ရှင်းပြရမည် မသိပါ။ ဒါနဲ့ ကျွှန်တော် လေးစားရသော Java ဆရာကြီး ကိုကျော်လွင်ကို မေးကြည့်ပါသည်။

Abstraction ကို မြန်မာလို ပြောရမည်ဆိုလျှင် သဘောတရား ဖြစ်သည်ဟုဆိုသည်။ လူတစ်ယောက်ကို လူတစ်ယောက် မှန် သိအောင် အနည်းဆုံး ပိုင်ဆိုင်ရန်လိုအပ်သော အချက်အလက်များအား လူတစ်ယောက်၏ သဘောတရား ဖြစ်သည်။

တဖန် Generalization ဆိုသည်မှာ ရေဘုံယဖွဲ့ခြင်း ဖြစ်သည်။ Entity တစ်ခုအား ရေဘုံယ အကျဆုံး သဘောတရား အဖြစ် သတ်မှတ်ခြင်းသည် Generalization ဖြစ်ပါသည်။ Generalization လုပ်ခြင်း အားဖြင့် ပတ်သက်သော Relation အား Is a Relation ဟုလည်း ခေါ်ဆိုပါသည်။

• [ကား]သည် [ကုန်ကား] နှင့် [ပြိုင်ကား] တို့အား Generalization လုပ်ထားခြင်း ဖြစ်သည်။
• [ကုန်ကား] နှင့် [ပြိုင်ကား] တို့သည် [ကား] ဖြစ်ပါသည်။

ဒီတစ်ခေါက်ဖြင့် Entity များအကြား ပတ်သက်မှု့ကို ဖော်ပြနိုင်သော Relationများအကြောင်းကို ဖော်ပြခဲ့၏။ နောက်ရက်များတွင် Data Modeling တွင် မရှိမဖြစ်လိုအပ်သော Metadata အကြောင်းကို ဆက်လက် ဖော်ပြသွားပါဦးမည်။

လေးစားစွာဖြင့်

မင်းလွင်

Data Definations

Data Definition ၏ အခြေခံ သဘောတရား

လက်တွေ့ သဘာဝအတွင်းရှိ အချက်အလက်များအား Database အနေဖြင့် ပြန်လည် ဖော်ပြလိုသောအခါ၊ အသုံးပြုသော Data Model အပေါ်မှုတည်၍ ဦးစွာ သဘာဝအတွင်းရှိ အကြောင်းအရာများအား လူကသိမြင် နားလည်နိုင်သော အချက်အလက်များ အဖြစ် ပြောင်းလည်းပြီး၊ ၎င်းအချက်အလက်များအား ကွန်ပျူတာဖြင့် အသုံးပြုနိုင်သော Data အဖြစ် ပြောင်းလည်း ယူရန် လိုအပ်ပါသည်။ မည်ကဲ့သို့ လက်တွေ့ဘဝထဲမှ အချက်အလက်များအား ကွန်ပျူတာမှနားလည်သော အချက်အလက်များ အနေနှင့် ပြောင်းလည်းယူမည်နည်း။ ဤသင်ခန်းစာဖြင့် Data အဖြစ်ပြောင်းလည်းယူရာတွင် လိုအပ်သည့် အစိတ်အပိုင်းများနှင့် အခြေခံ သဘောတရား အကြောင်းကို လေ့လာဖော်ပြသွားပါမည်။ အသုံးပြုလိုသော Data Model အပေါ်မှုတည်၍ ဝေါဟာရနှင့် ယူဆပုံတို့မှာ အနည်းငယ်ကွဲပြားမည် ဖြစ်သော်လည်း၊ ဤနေရာတွင် အခြေခံသဘောတရားအား Entity, Attributes, Relation အစရှိသော အခြေခံ ဝေါဟာရအား အသုံးပြု၍ ရှင်းလင်းသွားပါမည်။ ဤကဲ့သို့ ဖော်ပြရာတွင်လည်း Data Independence တွင်ဖော်ပြခဲ့သော အဆင့်သုံးဆင့်၏ သဘောတရား အဆင့် ဖြင့် ဖော်ပြသွားမှာဖြစ်ပြီး အတွင်းပိုင်း အဆင့်ဖြင့် ဖော်ပြသွားမည် မဟုတ်ပေ။

အခြေခံသဘောတရားအား လေ့လာရာတွင် နမှုနာအနေနှင့်၊ လက်ရှိသဘာဝအတွင်းရှိ လုပ်ငန်းအချက်အလက် အနေအထားများအား အောက်ပါအတိုင်း ဖော်ပြထားပြီး၊ ၎င်းအနေအထားအား ကွန်ပျူတာပေါ်တွင် အသုံးပြုနိုင်သည့် Database အဖြစ် ပြောင်းလည်းသွားပုံကို ဖော်ပြသွားပါမည်။

Software Development ကုမ္ပဏီ A သည် Software ရေးသားခြင်းနှင့် ရောင်းဝယ်ခြင်း လုပ်ငန်းများအား လုပ်ကိုင်ပါသည်။ ပြည်တွင်းတွင် ရန်ကုန်ရုံးခွဲကို အစပြု၍ ရုံးခွဲပေါင်း ၁၀ခုကို အခြေပြု၍ Software အမျိုးအစား ၁၀၀ကို ရေးသား ရောင်းချနေ၏။ အထူးသဖြင့် ရန်ကုန်ရုံးချုပ်သည် DBMS ကို၎င်း၊ ပဲခူးရုံးခွဲသည် Internet Café Management System ကို အဓိကထား ရောင်းချနေပါသည်။ ရန်ကုန်ရုံးချုပ်တွင် B မံနေဂျာအား ဦးစီးစေ၍ Software Developer ၂၀ဖြင့်၎င်း၊ ပဲခူးရုံးခွဲတွင် C မံနေဂျာအား အမှူးပြု၍ Software Developer ၁၅ဦးဖြင့် လုပ်ငန်းကို လုပ်ဆောင်လျှက်ရှိ၏။


ဤကဲ့သို့သော လက်တွေ့ဘဝအတွင်းရှိ လုပ်ငန်းအနေအထားအား Data Model ၏ အခြေခံ သဘောတရားများ ဖြစ်သော Entity, Attribute နှင့် Relation များကို အသုံးပြု၍ ဆက်လက်ရှင်းလင်းသွားပါမည်။

Entity ၏ ပုံစံ (Type) နှင့် တန်ဖိုး (Value)

Data Model တွင် သဘာဝအတွင်းရှိ လူတစ်ဦးမှ ကြည့်မြင်သိရှိနိုင်သော အကြောင်းအရာတစ်ခုအား Entity အဖြစ် ဖော်ပြလေ့ရှိ၏။ အဆိုပါ Entity သည် Database တစ်ခုတွင် အသုံးပြုရန် အခြေခံလိုအပ်ချက် တစ်ခုလည်း ဖြစ်၏။ ဤကဲ့သို့ Entity အား စဉ်းစားရာတွင် လက်တွေ့ဘဝတွင် တကယ်တည်ရှိသော အကြောင်းအရာတစ်ခုလည်း ဖြစ်ချင်ဖြစ်မည်၊ အကဲ၍ မတည်ရှိခဲ့ပါလည်း သဘောတရားအရ တည်ရှိသော အရာဖြစ်လျှင်လည်း ကိစ္စမရှိပါ။ သဘောတရားအရ အချက်အလက်များအား ကိုယ်စားပြုပြီး Entity အနေနှင့်လည်း အသုံးပြုနိုင်မည် ဖြစ်ပါသည်။
အထက်ဖော်ပြပါ နမှုနာမှ လက်တွေ့ အချက်အလက်များမှ Entity အဖြစ်အသုံးပြုနိုင်သော အချက်အလက်များအား စဉ်းစားရာတွင် အောက်ပါအတိုင်း တွေ့ရှိရမည်ဖြစ်သည်။

• ကုမ္ပဏီ A၊ ရုံးခွဲ၊ ရန်ကုန်ရုံးခွဲ၊ ပဲခူးရုံးခွဲ၊ ရုံးခွဲပေါင်း ၁၀ခု အစရှိသဖြင့်
• Software၊ DBMS၊ Internet Café Management System၊ အမျိုးအစားပေါင်း ၁၀၀
• ဝန်ထမ်း၊ B မံနေဂျာ၊ C မံနေဂျာ၊ DBMS Software Developer ၂၀ဦး၊ ပဲခူးရုံးခွဲရှိ Developer ၁၅ဦး၊ အခြား ရုံးခွဲမှ Developer များ

Data Model ဘာသာရပ်တွင် အထက်ပါ လက်ရှိ အချက်အလက်များအား Model အဖြစ် ပြောင်းလည်းရာတွင် အမျိုးအစားတူများအား စုစည်း၍ ၎င်းအား Type အဖြစ် Modeling လုပ်မည် ဖြစ်သည်။ အဆိုပါ အချက်အလက် ပုံစံ(Type)အား Entity Type ဟု ခေါ်ဆို၏။ ထို Entity Type များတွင်ပါဝင်သော အုပ်စုတူ အချက်အလက်များအား Entity Type ၏ တန်ဖိုး၊ Occurrence ဒါမှမဟုတ် Instance ဟု ခေါ်ဆို၏။ အထက်ပါ အချက်အလက်များအား Entity Type နှင့် တန်ဖိုးအဖြစ် ခွဲခြားကြည့်သောအခါ အောက်ပါအတိုင်း တွေ့ရှိရမည် ဖြစ်ပါသည်။

• Entity Type : ရုံးခွဲ၊ Software၊ ဝန်ထမ်း၊ ကုမ္ပဏီ
• Entity Type ရုံးခွဲ ၏ တန်ဖိုး (Instance) : ရန်ကုန်ရုံးခွဲ၊ ပဲခူးရုံးခွဲ၊ အခြားသော ရုံးခွဲ ၈ခု
• Entity Type ဆော့ဖ်ဝဲ ၏ တန်ဖိုး (Instance) : DBMS၊ Internet Café Management System၊ အခြားသော ဆော့ဖ်ဝဲပေါင်း ၁၀၀မျိုးတစ်ခုစီ
• Entity Type ဝန်ထမ်း ၏ တန်ဖိုး (Instance) : B မံနေဂျာ၊ C မံနေဂျာ၊ DBMS Software Developer ၂၀ဦး၊ ပဲခူးရုံးခွဲရှိ Developer ၁၅ဦး၊ အခြား ရုံးခွဲမှ Developer များတစ်ဦးချင်းစီ
• Entity Type ကုမ္ပဏီ၏ တန်ဖိုး (Instance) : ကုမ္ပဏီ A၊ အခြားသော ကုမ္ပဏီများ

ဤကဲ့သို့ Entity Type အား အသုံးပြု၍ Model အဖြစ်ပြောင်းလည်းခြင်း အားဖြင့် အသုံးပြုနေသော Database တစ်ခုအတွက် အသုံးချနိုင်သော အချက်အလက်များအား သိသာထင်ရှားစေပါသည်။ လူတို့သည် နေ့တဓူဝ အကြောင်းအရာများအား ပြောကြားနေကြရာတွင် Entity Type နှင့် သူ၏ တန်ဖိုးဖြစ်သော Instance အား အထွေအထူး ခွဲခြားခြင်းမရှိပဲ ပြောကြားနေလေ့ရှိ၏။ စကားများအကြားမှ မည်သည့်အရာသည် Type ဖြစ်ပြီး မည်သည့်အရာသည် တန်ဖိုးဖြစ်ကြောင်း စဉ်းစားစရာမလိုပဲ အလိုလို နားလည်နိုင်၏။ သို့ရာတွင် Database တစ်ခုအား  ဒီဇိုင်းရေးသားသူ တစ်ယောက်အနေဖြင့် အသုံးပြုသူများအကြားတွင် နားလည်မှု့အား ကွဲခြားမှု့ မရှိစေရန် Entity Type အား အတိအကျ သတ်မှတ်ထားပြီး အသီးသီးသော တန်ဖိုး (Instance) များအား အသုံးချနိုင်စေရန် စီမံထားသင့်ပေသည်။ ဤအချက်သည် Data Modeling ၏ အခြေခံ အချက် တစ်ခုပင် ဖြစ်၏။

Data Modeling ဘက်မှ စဉ်းစားမည် ဆိုလျှင် Instance တစ်ခုအား Modeling အဖြစ် ပြောင်းလည်းမည့် လက်တွေ့ အနေအထားတစ်ခု အတွင်းတွင် Entity Type တစ်ခုအနေဖြင့် သတ်မှတ်ထား လေ့ရှိ၏။ ဥပမာအားဖြင့် အထက်ပါ နမှုနာအတွင်းတွင် အလုပ်တာဝန်ဘက်မှ ကြည့်သော ဝန်ထမ်းနှင့် ကုမ္ပဏီ၏ ဘဏ္ဍာရေးဘက်မှ ကြည့်၍ လစာပေးရန်လိုအပ်သော ဝန်ထမ်းသည်လည်း အုပ်စုတူပင် ဖြစ်၏။ သို့ရာတွင် လက်တွေ့ဘဝမှာမှု ထိုသို့မဟုတ်။ Instance တစ်ခုအား အမျိုးမျိုးသော Entity Type များအနေနှင့် သတ်မှတ်နိုင်မည် ဖြစ်သည်။
ဥပမာအားဖြင့် မံနေဂျာ B သည် A ကုမ္ပဏီမှကြည့်ပါက ဝန်ထမ်းအမျိုးအစား ဖြစ်သော်လည်း၊ သူ၏ သားဖြစ်သူ တက်သော ကျောင်းမှကြည့်မည်ဆိုသော် ကျောင်းသားမိဘဖြစ်ပြန်၏။ တဖန်သူအသုံးပြုသော ဘဏ်မှ ကြည့်မည် ဆိုပါက Customer ဖြစ်ပြန်သည်။ ထို့ကြောင့် Database တစ်ခုအား ဒီဇိုင်းရေးသားရာတွင် မည်သည့် ရည်ရွယ်ချက်ဖြင့် ရေးသားသည်ကို တိကျစွာသတ်မှတ်ထားရန်လိုအပ်ပြီး လက်တွေ့ဘဝနှင့် မည်ကဲ့သို့ ဆက်စပ်သည်ကို ခွဲခြားသိမြင် ထားရန် လိုအပ်ပါသည်။

တဖန် Concept Level ၌ လုပ်ငန်းတာဝန်ခွဲဝေမှု့ အဆင့်မှကြည့်သော ဝန်ထမ်းနှင့် ဘဏ္ဍာရေးဘက်မှ ကြည့်မြင်သော ဝန်ထမ်းမှာ အတူတူဖြစ်သော်လည်း၊ External Level ၌မှု ကွဲပြားခြားနား ပေသည်။ ထို့ကြောင့် Concept Level ၌ External Level အသီးသီးတွင် ဘုံအဖြစ်အသုံးပြုနိုင်သော Entity ဖြစ်ကြောင်းကို သိရှိထားရန် လိုအပ်ပါသည်။

Attribute

Entity Type သည် Entity များအား အုပ်စုဖွဲ့ထားသော အမျိုးအစားဖြစ်သာဖြစ်ပြီး၊ Entity တစ်ခုလုံး၏ ထူးခြားချက်များအား ဖော်ပြနိုင်ခြင်း မရှိပေ။ အဆိုပါ ထူးခြားချက်များအား ဖော်ပြနိုင်ရန်အတွက် Attribute ကို အသုံးပြု ပါသည်။ အထက်ပါ နမှုနာရှိ Entity Type များ၏ Attribute အား စဉ်းစားရာတွင် အောက်ပါအတိုင်း ဖော်ပြ နိုင်မည် ဖြစ်သည်။

• Entity Type ဆိုင်ခွဲ၏ Attribute : ဆိုင်အမည်၊ လိပ်စာ၊ Telephone Number အစရှိသဖြင့်
• Entity Type ဆော့ဖ်ဝဲ၏ Attribute : အမည်၊ Maker ၊ ဗားရှင်း၊ စတင်ထုတ်လုပ်သည့် ရက်စွဲ၊ အစရှိသဖြင့်
• Entity Type ဝန်ထမ်း၏ Attribute : ID နံပါတ်၊ အမည်၊ ရာထူး၊ ဆိုင်ခွဲ၊ အလုပ်ဝင်နေ့စွဲ အစရှိသဖြင့်
• Entity Type ကုမ္ပဏီ၏ Attribute : အမည်၊ လိပ်စာ၊ တာဝန်ရှိသူ အစရှိသဖြင့်

Data Model အမျိုးအစား အပေါ်မှုတည်၍ Attribute အား Entity တစ်ခု၏ အရည်အသွေး၊ ပိုင်ဆိုင်မှု့ဟု မြင်သော အမြင်နှင့် Attribute ကိုယ်တိုင်က၊ Entity တစ်ခု အနေဖြင့် ကြည့်မြင်သော အမြင်တို့ ရှိကြ၏။ Object Oriented Data Modelling တွင် Attribute ကိုယ်တိုင်အား Object တစ်ခု အဖြစ် ကြည့်မြင်လေ့ရှိပါသည်။

Domain

Attribute များ၏ တန်ဖိုးအစု (Set) များအား Domain ဟု ခေါ်ဆိုပါသည်။ အောက်ပါ ပုံကိုကြည့်ပါ။ ကုန်ပစ္စည်း၏ ထုတ်လုပ်သည့်နေ့နှင့် ဝန်ထမ်း၏ အလုပ်ဝင်သည့်နေ့တို့သည် ရက်စွဲပုံစံအား အသုံးပြုနေပြီး ၎င်းသည် Domain ဖြစ်၏။ တဖန် ကုန်ပစ္စည်း၏ မှုရင်းကုမ္ပဏီနှင့် မှုရင်းကုမ္ပဏီများ၏ အမည်တို့သည်လည်း တူညီသော Domain များ ဖြစ်ကြပါသည်။ ဤကဲ့သို့ Domain များအား အသုံးပြုခြင်းအားဖြင့် Database အတွင်းရှိ Data များ၏ ပုံစံစစ်မှန်တူညီမှု့ကို ထိမ်းသိမ်းပေးနိုင်ပါသည်။

ဆက်ပါဦးမည်။ လေးစားစွာဖြင့်။

မင်းလွင်

Data Independence

Data Independence ဆိုသည်မှာ အမည်အတိုင်း အချက်အလက်များ၏ လွတ်လပ်မှု့ ပင်ဖြစ်၏။ ဆိုလိုသည်မှာ Data များသည် အသုံးပြုမည့် အပလီကေးရှင်း ပရိုဂရမ်များမှ လွတ်လပ်မှု့ရှိရမည် ဖြစ်သည်။ ဤကဲ့သို့ Data နှင့် ပရိုဂရမ်တို့သည် အသီးသီး ချုပ်နှောင်ခြင်းမရှိပဲ လွတ်လပ်စွာတည်ရှိနိုင်မှသာ Data ပဲဖြစ်ဖြစ်၊ ပရိုဂရမ်ကိုပဲဖြစ်ဖြစ် လိုအပ်ရင် လိုအပ်သလို ပြုပြင်ပြောင်း လည်းနိုင်မည်ဖြစ်သည်။

ဖိုင်များအား အသုံးပြုခြင်း၏ ပြဿနာ

Database မပေါ်ခင်အချိန်များတွင်၊ အပလီကေရှင်းများတွင် အချက်အလက်များအား အသုံးပြုရာတွင် ဖိုင်များအား အသုံးပြုလာခဲ့ကြ၏။ ဤကဲ့သို့ ဖိုင်များအား အသုံးပြုရာတွင် အပလီကေးရှင်း ပရိုဂရမ်တစ်ခုတွင် အသုံးပြုလိုသည့် ဖိုင်တစ်ခုအား ပြင်ဆင်ထားပြီး၊ အချက်အလက်များ၏ ဖွဲ့စည်းပုံအား အသုံးပြုမည့် ပရိုဂရမ်အတွင်းတွင် တိုက်ရိုက် ရေးသား ခဲ့ကြ၏။ ထို့ကြောင့် ဖိုင်၏ ဖွဲ့စည်းပုံအား ပြောင်းလည်းလိုသည့် အခါတွင် ထိုဖိုင်အား အသုံးပြုသည့် ပရိုဂရမ်အား ပြောင်းလည်းရန် လိုအပ်ခဲ့ပါသည်။

ဥပမာအားဖြင့် ဖိုင်တစ်ခုအား အသုံးပြုနေသော အပလီကေးရှင်းတစ်ခုကို စဉ်းစားကြည့်ပါမည်။ ကားစာရင်း တစ်ခုအား အောက်ပါပုံ အတိုင်း ဖိုင်အဖြစ်သိမ်းဆည်း၍ အသုံးပြုနေပါသည်။

အထက်ဖော်ပြပါအတိုင်း ကားစာရင်းအချက်အလက်များအား 54 byteလျှင် အချက်အလက် တစ်ခုအဖြစ် ဖွဲ့စည်းထားပြီး ဖိုင်တွင် သိမ်းဆည်း၍ အသုံးပြုနေပါသည်။ အဆိုပါ ကားစာရင်းတွင် အမြန်နှုန်းဆိုသည့် အချက်အလက် အသစ်တစ်ခုအား ဖြည့်စွက်လိုသောအခါ၊ အဆိုပါ ဖိုင်အား အသုံးပြုနေသော ပရိုဂရမ်များအား ထိုအချက်အလက်အား အသုံးပြုပြု မပြုပြု ပြုပြင်ပြောင်းလည်းရန် လိုအပ်လာပါသည်။ အဘယ်ကြောင့်ဆိုသော် ထိုဖိုင်၏ ဖွဲ့စည်းပုံအား ပရိုဂရမ်အတွင်းတွင် တိုက်ရိုက်ရေးသားရန် လိုအပ်ပါသဖြင့်၊ ဖိုင်အား ပြုပြင်ပြောင်းလည်းပြီး ပရိုဂရမ်အား ပြုပြင်ပြောင်းလည်းခြင်း မရှိပါက ပရိုဂရမ်သည် မှန်ကန်စွာ အလုပ်မလုပ်နိုင်သောကြောင့် ဖြစ်၏။

Database နှင့် Data Independence ၏ အတွေးအမြင်

Database များတွင် ဤကဲ့သို့သော အချက်အလက် ဖွဲ့စည်းပုံအား အပလီကေရှင်း ပရိုဂရမ်မှ သီးသန့် ခွဲခြားထားပြီး၊ Data Definition Function အား အသုံးပြု၍ ရေးသားစေပါသည်။ ဤနည်းအားဖြင့် Data ဖွဲ့စည်းပုံမှာ Application နှင့် သီးခြား Control လုပ်ခြင်း အားဖြင့် Data ၏ ဖွဲ့စည်းပုံပြောင်းလည်းခြင်း များသည် Application အား တိုက်ရိုက် သက်ရောက်ခြင်းမှ လွတ်ကင်းစေပါသည်။

Data Independence သည် Database ပတ်ဝင်းကျင်တိုးတက်ရေး အတွက် အတားအဆီးဖြစ်နိုင်သော အကြောင်းအရင်းများအား အသုံးပြုသူထံမှ ကင်းဝေးစေနိုင်သည်ဟုလည်း တွေးနိုင်ပါသည်။ Data Independence အား အခြေခံ၍ သဘာဝအတွင်းရှိ အချက်အလက်များအား Data Model အဖြစ် ပြောင်းလည်းရာတွင် မည်သည့် အကြောင်းအရင်းများက Database ပတ်ဝင်းကျင် တိုးတက်ရေး အတွက် အတားအဆီး ဖြစ်စေနိုင်သလဲဆိုတာကို ကြိုတင် စဉ်းစားထားရန် လိုအပ်ပါသည်။ ဥပမာအားဖြင့် သုံးဆွဲလိုသည့် အချက်အလက်များ၏ Format၊ ဖိုင်များ၏ တည်ဆောက်ပုံ၊ သိမ်းဆည်းမည့်နေရာ၊ အသုံးပြုမည့် Data Model၊ ထိုမှတဆင့် သိမ်းဆည်းထားသော အချက်အလက်များအား နည်းအမျိုးမျိုးဖြင့် အသုံးပြုကြသောအခါ ဖော်ပြပုံတူညီခြင်း ရှိမရှိ အစရှိသည့် အချက်များအား ကြိုတင် စဉ်းစားထားသင့်ပေသည်။

Data Independence ၏ အဆင့်၃ဆင့်

Data Independence အား အခြေခံ၍သဘာဝအတွင်းရှိ အချက်အလက်များအား Model အဖြစ် ပြောင်းလည်းရာတွင် External Level၊ Conceptual Level နှင့် Internal Level ဟူ၍ အဆင့်သုံးဆင့် ခွဲခြား နိုင်ပါသည်။ External Level ဆိုသည်မှာ Application အသီးသီးမှ တွေ့မြင်နိုင်သော Model ဖြစ်ပြီး၊ Conceptual Level ဆိုသည်မှာ Application အားလုံးကို ပေါင်းပြီးကြည့်မြင်နိုင်သော Model ဖြစ်၏။ Internal Level ဆိုသည်မှာ Database ၏ အတွင်းပိုင်းကို ကိုယ်စားပြုသော အဆင့်ဖြစ်ပါသည်။

External Level သည် Database တစ်ခုလုံးနှင့်စာလျှင် အပလီကေးရှင်းတစ်ခုစီမှ စဉ်းစားသော အဆင့်ဖြစ်ပါသည်။ External Level တွင် အပလီကေးရှင်းတစ်ခုမှ ကြည့်မြင်သော အချက်အလက်များကိုသာ ဖော်ပြလေ့ရှိပြီး၊ ဤ External Level အား ရေးသားထားသော Data Structure နှင့် Integrity Constraint အစုအစည်းအား External Schema ဟု ခေါ်ဆိုပါသည်။ များသောအားဖြင့် Enterprise Database တစ်ခုတွင် အသုံးပြုနေသော အပလီကေးရှင်းများအပေါ် မှုတည်၍ External Schema ပေါင်း များစွာတည်ရှိလေ့ရှိ၏။ ဤကဲ့သို့ External Schema အား အသုံးပြုခြင်းအားဖြင့် အပလီကေးရှင်းများအား ပတ်သက်ရာ အချက်အလက်များ အပြင် Database ၏ အခြားသော အစိတ်စပိုင်းများအား မမြင်နိုင်ရန် ဖုန်းကွယ်နိုင်ပါသည်။

Conceptual Level သည် Enterpriseတစ်ခုလုံးမှ ကြည့်မြင်သော Database ကိုဆိုလို၏။ ဤအဆင့်တွင် အပလီကေးရှင်း တစ်ခုစီအားထည့်စဉ်းစားခြင်းမရှိပဲ အားလုံးအားခြုံ၍ စဉ်းစားပြီး၊ ဤအဆင့်တွင် ရေးသား ထားသည်များကို Conceptual Schema ဟု ခေါ်ဆိုပါသည်။ Conceptual Schema အား အသုံးပြုခြင်းအားဖြင့် Database ၏ အတွင်းပိုင်းရှိ မံမိုရီအစိတ်အပိုင်းအား ဖုန်းကွယ်ထားနိုင်ပါသည်။

Internal Level သည် Conceptual Schema တွင်ရေးသားထားသော Data Structure နှင့် Integrity Constraint များအား လက်တွေ့ ကွန်ပျူတာမံမိုရီအပေါ်တွင် မည်သို့ ထားရှိမည် ဆိုသည့်အချက်ကို ရေးသားနိုင်ပါသည်။ ဤအဆင့်တွင် ရေးသားထားသည်များကို Internal Schema ဟု ခေါ်ဆိုပြီး၊ Database အား ကွန်ပျူတာပေါ်တွင် Performance အကောင်းဆုံးအသုံးပြုနိုင်ရန် စီမံရန်လိုအပ်သော အဆင့်ဖြစ်ပါသည်။

အထက်ပါ Schema များအတွင်း ပြောင်းလည်းပေးခြင်းအား Mapping ဟု ခေါ်ဆိုပါသည်။ ဤဖွဲ့စည်းပုံသည် ANSI/SPARC အဖွဲ့အစည်းမှ ရေးသားထားသော Three Level Architecture ဖြစ်ပါသည်။ Database အား ဒီဇိုင်းရေးဆွဲရာတွင် အခြေခံထားသင့်သော Architecture တစ်မျိုးဖြစ်ပါသည်။


မှတ်ချက်

ဆရာဆာတို (http://www.tiu.ac.jp/n_department/professor/commercial/0010_sato.html) ၏ သင်ခန်းစာများမှ ပြန်လည် ကောက်နှုတ်တင်ပြပါသည်။

လေးစားစွာဖြင့်

မင်းလွင်

Data Model

Database အကြောင်းအား နားလည်နိုင်ရန်အတွက် Data Model အကြောင်းအား သဘောပေါက်ရန် လိုအပ်ပါသည်။ ဤနေရာတွင် သုံးနှုန်းသည့် စကားလုံး Mode သည် အရာတစ်ခုအား ဖော်ပြရာတွင်အသုံးပြုသည့် ကိုယ်စားပြု ပုံစံတူတစ်ခု ဖြစ်ပါသည်။ Data Model ဆိုသည်မှာလည်း လက်ရှိသဘာဝတွင် ရှိသော အချက်အလက်များအား ကိုယ်စားပြု ဖော်ပြနိုင်သော Data ပုံစံတူများဟု ဆိုနိုင်မည် ဖြစ်သည်။

Data Model ဆိုသည်မှာ

Data Model ဆိုသည်မှာ၊ လက်တွေ့သဘာဝအတွင်းတွင်ရှိသော အချက်အလက်များအား၊ Database အတွင်း ထည့်သွင်း သိမ်းဆည်း ရာတွင် အသုံးပြုသော နည်းလမ်း၊ ဒါမှမဟုတ် သိမ်းဆည်းထားသော ရလဒ်ကို ဆိုလိုပါသည်။

Data Model အကြောင်းအားစဉ်းစားရာတွင် လူတို့သည် သဘာဝ အတွင်းရှိ အကြောင်းအရာများအား တစ်ယောက်မှ တစ်ယောက်ဆီသို့ အကြောင်းကြားပုံကို ကရုစိုက်ကြည့်သင့်ပါသည်။ လူတို့သည် လောကအတွင်းရှိ မြင်ရကြားရသည့် အရာများအား တစ်ဦးမှတစ်ဦးဆီသို့ ဆက်သွယ်နိုင်စေရန်အတွက် အပြန်အလှန်နားလည်နိုင်သော နည်းလမ်းအား အသုံးပြု၍ ဆက်သွယ်ကြ၏။ ထိုနည်းလမ်းများအား မော်ဒယ်ဟု ခေါ်၏။ လူတစ်ဦးနှင့် တစ်ဦးအကြား ဆက်သွယ်ရာတွင် အသုံးများသော မော်ဒယ်များမှာ ရုပ်ပုံ၊ စကားလုံး၊ ဂီတ၊ ဓါတ်ပုံ၊ ရုတ်ရှင် အစရှိသည်တို့ ဖြစ်ကြ၏။ စကားလုံးများတွင်လည်း မြန်မာစာ၊ အင်္ဂလိပ်စာ၊ ဂျပန်စာ အစရှိသဖြင့် လူမျိုးအပေါ်မှုတည်၍ အမျိုးမျိုး ကွဲပြားကြ၏။

ဤနည်းအားဖြင့် လူတို့သည် တစ်ဦးနှင့်တစ်ဦးဆက်သွယ်ရာတွင် လက်ရှိ အရာများအား ကိုယ်စားပြုဖော်ပြနိုင်သော မော်ဒယ်များအား အသုံးပြုသကဲ့သို့၊ Data Model သည်လည်း လက်တွေ့ အကြောင်းအရာများအား ကွန်ပျူတာတွင် အသုံးပြုနိုင်ရန်အတွက် ကိုစားပြုဖော်ပြပေးနိုင်သော မော်ဒယ်တစ်ခုပင် ဖြစ်၏။ ဤသို့ဆိုလျှင် Database ဆိုသည်မှာ ရည်ရွယ်ချက်အမျိုးမျိုးအတွက် အသုံးပြုနိုင်ရန်ရည်ရွယ်ပြီး၊ အပြန်အလှန် ပတ်သက်ပုံကို ဖော်ပြပေးနိုင်သော လိုရင်းအချက်အလက် အစုအဝေး ဆိုပါက၊ ထိုအချက်အလက်များအား ဖော်ပြရာတွင်၎င်း၊ ရှာဖွေရာတွင်၎င်း၊ ပြောင်းလည်းရာတွင်၎င်း အသုံးပြုသောနည်းလမ်းအား Data Model ဟု ခေါ်ဆိုမည် ဖြစ်သည်။

လူ့လောကတွင်လည်း ဘာသာစကား  အမျိုးမျိုးရှိသကဲ့သို့ပင် Data Model တွင်လည်း အမျိုးမျိုးရှိပါသည်။ သဘာဝအတွင်းတွင်ရှိသော အကြောင်းအရာများအား ကိုယ်စားပြုရာတွင်၊ အချက်အလက်များအား ကြည့်မြင်ပုံ၊ တွေးခေါ်စဉ်းစားပုံတို့၏ ကွာခြားချက်အပေါ်မှုတည်၍ Data Model အမျိုးအစားများမှာလည်း ကွာခြားတတ်ပါသည်။

Data Model အမျိုးအစားများ

၁၉၆၀ခု ဆယ်စုနှစ် နောက်ပိုင်းမှ စ၍ ၁၉၇၀ခု ဆယ်စုနှစ် အစပိုင်းလောက်အထိ အသုံးများခဲ့သော Data Model များမှာ အချက်အလက် ဆက်သွယ်ပုံများအား အဆင့်ဆင့် ဖော်ပြပေးနိုင်သော Hierarchical Database Modelနှင့် အချက်အလက်များအား အဆင့်လိုက်သာမဟုတ် ကွန်ယက်အနေဖြင့် ဖော်ပြနိုင်သော Network Model တို့ ဖြစ်ကြ၏။ ၎င်းမော်ဒယ်များအား အသုံးပြုသော Database Management System များလည်း စီးပွားဖြစ် အနေနဲ့ အများအပြား ထွက်ပေါ်ခဲ့ပါသည်။

ဆားဗစ်လုပ်ငန်းများတွင် အသုံးပြုသော Booking System၊ ပို့ဆောင်ဆက်သွယ်ရေး လုပ်ငန်းများ၏ Ordering System နှင့် Inventory Control System၊ ကုန်ထုတ်လုပ်ငန်းများ၏ Production Control System နှင့် ဘဏ်လုပ်ငန်းများ၏ ဘဏ်စာရင်း Control System များတွင် အသုံးပြုခဲ့ကြ၏။ အထက်ပါ Data Model များသည် ၁၉၈၀ခု အရောက်တွင် Online System များတွင် အသုံးပြုသော ကြီးမားသည့် Database များတွင် အသုံးပြုလာခဲ့ပြီး ယနေ့တိုင်အသုံးပြုနေဆဲပင် ဖြစ်သည်။

တဖက်တွင် ၁၉၇၀ခုနှစ်ပိုင်းလောက်မှ စ၍ အချက်အလက်များအား ဇယားအဖြစ်ဖော်ပြနိုင်သော Relational Data Model ကို စတင် ပေါ်ပေါက်လာခဲ့ပြီး၊ ၁၉၈၀ခုနောက်ပိုင်းတွင် Relational Data Model ကို အသုံးပြုသော DBMS များသည် Decision Management System များတွင် အသုံးများလာပြီး၊ Online အား အခြေခံသော Enterprise System များတွင် အသုံးများသော Data Model တစ်ခု ဖြစ်လာပါသည်။ အသုံးပြုရာတွင် ပုံစံအမျိုးမျိုးဖြင့် အသုံးပြုနိုင်ပါသဖြင့် ယနေ့ခေတ်တွင် အသုံးအများဆုံးသော Data Model တစ်ခု အဖြစ်ရပ်တည် နေပါသည်။ တဖန် ၁၉၉၀ခုနှစ် ပိုင်းတွင် အချက်အလက်များနှင့် လုပ်ဆောင်ချက်များအားပူးတွဲ၍ Object Oriented သဘောတရားများသည်၊ အချက်အလက်များနှင့် Software များအား ပြန်လည်အသုံးပြု နိုင်မှု့တို့ကြောင့် လူအများ အာရုံစိုက်လာသော နည်းပညာ တစ်မျိုးဖြစ်လာပါသည်။ လက်ရှိတွင် Object Oriented သဘောတရားများအား ထည့်သွင်းထားသော Data Model မှာ Object-Relational Data Model ဖြစ်ပြီး၊ ၎င်းအား အသုံးပြုထားသော DBMS များမှာလည်း Public အနေနဲ့ရော Commercial အနေနဲ့ပါ ထုတ်ပြန်လာခဲ့ပါသည်။

Data Model ၏ အခြေခံအစိတ်အပိုင်း ၃ခု

အထက်ဖော်ပြပါ Data Model များတွင်သဘာဝ အကြောင်းအရာများအားမော်ဒယ်အနေဖြင့် ကိုယ်စားပြုရာတွင် အခြေခံအနေဖြင့် အောက်ပါ အချက် ၃မျိုးကို အဓိကထားခဲ့ပါသည်။

1. Data Structure
2. Data Manipulation
3. Integrity Constraint

Data Structure အစိတ်အပိုင်းသည် လက်ရှိ အကြောင်းအရာများအား Data အဖြစ်ဖော်ပြရာတွင် မည်ကဲ့သို့ရှိသည်၊ မည်ကဲ့သို့ ပတ်သက်သည် အစရှိသည့် အချက်များအား သတ်မှတ်ပေးနိုင်ပါသည်။ တဖန် Data Manipulation အစိတ်အပိုင်းသည် Data များအားရှာဖွေရာတွင် (Search) ၎င်း၊ ပြုပြင်ရာတွင် (Update) ၎င်း၊ စီးမျဉ်းများအား ချမှတ်ပေးပါသည်။ နောက်ဆုံး Integrity Constraint သည် Data Structure တွင် အခြေခံ၍ စုစည်းထားသော အချက်အလက်များအား Data Manipulation ဖြင့် အသုံးပြုရာတွင် Data များအား အမြဲတမ်း မှန်ကန်မှု့ရှိစေရန် ကန့်သတ်ချက်များအား သတ်မှတ်ပေးပါသည်။ ဥပမာအားဖြင့် အချက်အလက်တစ်ခုအား အသစ် ဖြည့်စွက်ရာတွင် လက်ရှိရှိပြီးသော အချက်အလက်ဖြစ်ပါက ဖြည့်စွက်မည်သို့မဟုတ် မဖြည့်စွက်ပါ အစရှိသည်ကို ဆုံးဖြတ်ရသော သတ်မှတ်ချက်ဖြစ်ပါသည်။ တဖန် အချက်အလက်တစ်ခုအား ပြုပြင်ပြောင်းလည်းမည် ဆိုပါက အဆိုပါအချက်အလက်အား ကိုးကား (Reference) နေသော အချက်အလက်များရှိပါက မည်သို့ပြုလုပ်မည် အစရှိသည့် သတ်မှတ်ချက်များလည်း ပါဝင်ပါသည်။

Database Language

Data Model အား သက်မှတ်ရေးသားသော အစိတ်အပိုင်းအား Database Language ဟု ခေါ်ဆိုပါသည်။ ပုံမှန်အားဖြင့် Data Structure နှင့် Integrity Constraint အား ရေးသားသော ဘာသာရပ်အား Data Definition Language (DDL) ဟု ခေါ်ဆိုပြီး၊ Data များအား အသုံးချရာတွင် အသုံးပြုသော ဘာသာရပ်အား Data Manipulation Language (DML) ဟု ခေါ်ဆိုပါသည်။

တဖန် DDL အား အသုံးပြု၍ ရေးသားထားသော Data Structure နှင့် Integrity Constraint အစုအစည်းအား Schema ဟု ခေါ်ဆိုပါသည်။ တနည်း ဆိုရသော် Schema သည် သတ်မှတ်ချက်များအား စုစည်းထားသော အစုအဝေးတစ်ခုပင် ဖြစ်၏။

Data Modeling Facility နှင့် Application Data Model

အထက်တွင် Data Model သည် လက်ရှိဘဝတွင် ရှိသော အရာများအား ကိုယ်စားပြုနိုင်သော နည်းလမ်းများနှင့် ကိုယ်စားပြုထားသော ရလဒ်များဖြစ်သည်ဟု ဖော်ပြခဲ့ပါသည်။ တနည်းဆိုရသော နည်းလမ်းဖြစ်သော Data Model နှင့် ရလဒ်အဖြစ်တည်ရှိသော Data Model ဟူ၍ ရှိကြပါသည်။ အဆိုပါ အကြောင်းအရာနှစ်ခုအား မည်သို့ကွဲခြားသနည်းဟု ဆိုသော် နည်းလမ်းအဖြစ်ရှိသော Data Model အား Data Model Facility ဟု ခေါ်ဆိုပြီး၊ ရလဒ်အဖြစ်ရှိသော Data Model အား Application Data Model ဟု ခေါ်ဆိုပါသည်။

Hierarchical Database Model ၊ Network Data Model နှင့် Relational Data Model အစရှိသည်များသည် Data Modeling Facility ဖြစ်ပြီး၊ ၎င်းတို့အား အသုံးပြု၍ ရေးသားထားသော Booking System, Ordering System နှင့် Decision Management System အစရှိသည်တို့သည် Application Data Model တို့ ဖြစ်ကြပါသည်။


မှတ်ချက်

ဆရာဆာတို (http://www.tiu.ac.jp/n_department/professor/commercial/0010_sato.html)၏ သင်ခန်းစာများမှ ပြန်လည် ကောက်နှုတ်တင်ပြပါသည်။

ဆက်ပါဦးမည်

မင်းလွင်

DataBase Management System

Database အား ထိမ်းသိမ်းနိုင်ရန်အတွက် အသုံးပြုသော ဆော့ဖ်ဝဲအား Database Management System (DBMS) ဟု ခေါ်ဆိုပါသည်။ DBMS သည် Database အတွင်းရှိ အချက်အလက်များအား ထာဝရ အသုံးပြုနိုင်ရန် အတွက် Hard Disk များကဲ့သို့ Storage Device များတွင် Database အား ဖွဲ့စည်း သိမ်းဆည်းထားပြီး၊ အသုံးပြုမည့် Enterprise အပလီကေးရှင်း၏ ပရိုဂရမ်များမှ တဆင့် တောင်းဆိုချက်များအား လုပ်ဆောင်ပေးနိုင်သော အပလီကေးရှင်းမျိုးဖြစ်ပါသည်။ DBMS ၏ ဖန်ရှင်များသည် Database ရှိ သတ်မှတ်ချက်များနှင့် Data Model အပေါ်တွင် မှုတည်၍ ပြောင်းလည်း ပါသည်။

ဤကဲ့သို့သော DBMS များသည် Operating System များနှင့် Application များအကြားတွင် တည်ရှိသောကြောင့် Middleware ဟုလည်း ခေါ်ဆိုလေ့ရှိ၏။ DBMS ဟု ခေါ်ဆိုခြင်းမှာလည်း Database အား ထိမ်းသိမ်းရန် အတွက် လုပ်ဆောင်ချက်များအား စုစည်းထားသော အပလီကေးရှင်း ဖြစ်ခြင်းကြောင့် DBMS ဟု ခေါ်ဆိုခြင်း ဖြစ်ပါသည်။

DBMS တစ်ခုတွင် အခြေခံအားဖြင့် အောက်ပါ လုပ်ဆောင်ချက်များကို ပံ့ပိုးပေးလေ့ရှိပါသည်။

1. Data Storage Management
2. Data Access Management
3. Query Processing
4. Transaction Management
5. End User Interface

အတော်များများ DBMS များတွင် ၁ မှ ၄ အထိ ဖန်ရှင်များအား ပံ့ပိုးထားကြပြီး၊ User Interface ကိုတော့ အခြားသော ဆော့ဖ်ဝဲကို အသုံးပြုပြီး ပံ့ပိုးထားသည်က များပါသည်။

Data Storage Management

ဤဖန်ရှင်များသည် Hard Disk များကဲ့သို့ Storage Device များတွင် Database များအား ဖွဲ့စည်း တည်ဆောက်ရာတွင် အသုံးပြုသော ဖန်ရှင်မျိုးကို ဆိုလိုပါသည်။ DBMS များသည် များသောအားဖြင့် OS များမှ ပံ့ပိုးပေးသော File နှင့် File System အား အသုံးပြု၍ Database များအား လက်တွေ့ ဖွဲ့စည်း တည်ဆောက် ပါသည်။ Database အား အသုံးပြုသူနှင့် ပရိုဂရမ်များသည် လက်တွေ့ Database အား မည်ကဲ့သို့ ဖွဲ့စည်း တည်ဆောက်ထားသည်ကို မသိရှိနိုင်ပေ။ တကယ်တမ်းမှာလည်း အသုံးပြုသူအနေဖြင့် Database အား File System အပေါ်တွင် မည်သို့တည်ဆောက်ထားသည်ကို သိရှိရန်မလိုပေ။ သိရှိရန် လိုအပ်သည်မှာ Logically အချက်အလက်များအား မည်သို့ဖွဲ့စည်းထားသည် ဆိုသည့်အချက်သာလျှင် ဖြစ်၏။

သို့ရာတွင် အချို့သော DBMS များတွင်မှု၊ Data Storage ၏ အကျိုးသက်ရောက်မှု့ရှိစေရန်နှင့် Data Access Performance အား ထိရောက်မှု့ရှိစေရန် Database ၏ လက်တွေ့ဖွဲ့စည်းပုံနှင့် တည်ဆောက်ပုံတို့ကို စီမံခန့်ခွဲရန် လိုအပ် လေ့ရှိပါသည်။ အထူးသဖြင့် Data ပေါင်းမြောက်များစွာကို အသုံးပြုသော၊ အသုံးပြုသူ အများအပြားနှင့် Transaction အလွန်များသော Online System များတွင် အသုံးပြုလေ့ရှိသော Database များသည် Performance နှင့် Data ပမာဏကို အကျိုးရှိစွာ သိမ်းဆည်းနိုင်စေရန် စီမံမှု့များကို လိုအပ်လေ့ရှိပါသည်။

Performance Tuning နှင့်ပတ်သက်လာလျှင် Index များကို ပြုလုပ်၍ ဒေတာများအား ရှာဖွေနှုန်းကို တိုးမြင့်စေရန် ပြုလုပ်နည်းများလည်း ရှိပါသည်။ ရှာဖွေရာတွင် အသုံးများသော ကော်လန်များအား Index အဖြစ် သတ်မှတ်ထားခြင်း အားဖြင့် ရှာဖွေရ လွယ်ကူစေသည့်နည်း ဖြစ်ပါသည်။ သို့ရာတွင် မလိုအပ်ပဲ Index များကို သတ်မှတ်မိပါက Insert လုပ်ခြင်း၊ Delete လုပ်ခြင်း Update လုပ်ခြင်းများအား ကြံ့ကြာစေ တတ်သောကြောင့် သတိထား၍ အသုံးပြုသင့်ပါသည်။ Performance Tuning နှင့်ပတ်သက်၍ နောက်အခန်းများတွင် ဖော်ပြသွားပါဦးမည်။

Data Access Management

Data Access Management တွင် Input Output များအား စီမံခန့်ခွဲပေးနိုင်သော Buffer Management နှင့်၊ တပြေးညီ လုပ်ဆောင်ချက်များကို စီမံခန့်ခွဲမှု့ ပေးနိုင်သော Concurrency Process Management အစရှိသည့် အပိုင်းများကို ပံ့ပိုးပေးနေပါသည်။

Buffer Management သည် Hard Disk ပေါ်ရှိ Database ရှိ အချက်အလက်များအား အကျိုး သက်ရောက်စွာ Input Output များကို ပြုလုပ်နိုင်စေရန် Main Memory အပေါ်တွင် Buffer များအား ပြင်ဆင်ထားပြီး၊ Cashing လုပ်ခြင်းအားဖြင့် တတ်နိုင်သလောက် ဆက်သွယ်မှု့ အကြိမ်ကို နည်းပါးစေရန် စီမံခန့်ခွဲပေးနိုင်ပါသည်။

တဖန် Concurrency Process Management သည်၊ တပြိုင်နက်တည်း Transaction အများကို လုပ်ဆောင်ရာတွင် အစီအစဉ်တကျ လုပ်ဆောင်နိုင်စေရန် စီမံခန့်ခွဲမှု့ပေးနိုင်ပြီး၊ အချက်အလက်များ၏ တိကျသေချာစေမှု့ကို ထိမ်းသိမ်းစောင့်ရှောက် ပေးနိုင်ပါသည်။

Query Processing

အကယ်၍ SQL ကဲ့သို့သော Query ဘာသာရပ်အား အသုံးပြု၍ Database အတွင်းရှိ အချက်အလက်များအား ရှာဖွေရာတွင် DBMS သည် မေးမြန်းလာသည့် စာကြောင်းအား ဖတ်ယူကာ၊ အချိန်အတိုဆုံးနှင့် အထိရောက်ဆုံး Execution Plan အဖြစ်ပြန်လည် ပြုပြင်ရေးသားကာ Database အား ဆက်သွယ် စေပါသည်။ ဤကဲ့သို့ ပြင်ပမှ ရယူလာသော Query Expression အား အထိရောက်ဆုံး Expression အဖြစ်ပြန်လည်ပြုပြင်ကာ အချက်အလက်များအား ရှာဖွေပေးခြင်းအား Query Processing ဟု ခေါ်ဆိုပါသည်။

DBMS အတော်များများတွင် Explain လုပ်ဆောင်ချက်ကို ပြင်ဆင်ထားပြီး၊ ၎င်းအား အသုံးပြုခြင်းအားဖြင့် အသုံးပြုထားသော Query Expression တစ်ခု၏ DBMS မှ လက်တွေ အသုံးပြုသွားသော Execution Plan အား ရရှိစေနိုင်ပါသည်။ DB ၏ Performance Tuning များတွင် Explain ကွန်မန်းအား အသုံးပြု၍ လက်တွေ့ Database အား မည်ကဲ့သို့ ရှာဖွေစေသည်ကို စမ်းစစ်နိုင်ပါသည်။ အကဲ၍ Key နှင့် ပြင်ဆင်ထားသော Index များအား အသုံးပြုခြင်းမရှိပါက Index များအား ပြုပြင်ခြင်း အစရှိသဖြင့် Performance အား တိုးတက်စေရန် လုပ်ဆောင်လေ့ရှိပါသည်။ နောက်အခန်းများတွင် Performance Tuning နှင့် ပတ်သက်၍ ဖော်ပြသွားပါဦးမည်။

Transaction Management

Transaction ဆိုသည်မှာ လုပ်ငန်းတစ်ခုအား လုပ်ဆောင်စဉ် ဖြစ်ပွားလေ့ရှိသော လုပ်ဆောင်ချက်များအား လုပ်ငန်း တစ်ခုချင်းစီ စုစည်း၍ သတ်မှတ်လေ့ရှိသော ပမာဏဖြစ်ပါသည်။ ဥပမာအားဖြင့်၊ ဘဏ်လုပ်ငန်းများတွင် ငွေထုတ်ခြင်း၊ ငွေသွင်းခြင်း၊ ငွေလွှဲခြင်း အစရှိသည့် လုပ်ငန်းတစ်ခုချင်းစီအား Transaction ဟု သတ်မှတ်လေ့ရှိပါသည်။

ငွေထုတ်ခြင်းကို လုပ်ဆောင်ရာတွင်၊ အကြမ်းဖျင်းအားဖြင့် Bank Account ရှိမရှိကို စစ်ဆေးမည်၊ လက်ကျန်ငွေ ပမာဏအား စစ်ဆေးမည်၊ ထုတ်ယူလိုသည့် ငွေပမာဏကို ထုတ်ပေးနိုင်စွမ်းရှိမရှိကို စမ်းစစ်ကာ၊ ထုတ်ငွေစာရင်းအား အသစ်ရေးသားခြင်း၊ လက်ကျန်စာရင်းအား ပြုပြင်ရေးသားခြင်း၊ ငွေထုတ်ပေးခြင်း၊ ထုတ်ငွေစာရင်းအား ပြုပြင်ခြင်း အစရှိသည့် လုပ်ဆောင်ချက်များအား လုပ်ဆောင်ရန်လိုအပ်ပါသည်။

လုပ်ငန်းတစ်ခုအတွင်းရှိ၊ တနည်း Transaction တစ်ခု အတွင်းရှိ လုပ်ဆောင်ချက်များ အားလုံး ပြီးဆုံးမှသာ ထို Transaction သည် ပြီးဆုံးသည်ဟု သက်မှတ်နိုင်မည် ဖြစ်သည်။ ဤကဲ့သို့ Transaction သည် အောင်မြင်စွာ ပြီးဆုံးသလား၊ မပြီးဆုံးသလား ဆိုသည်ကို ကြည့်၍ Database အတွင်းရှိ အချက်အလက်များ၏ တိကျသေးချာမှု့၊ မှန်ကန်မှု့ကို ထိမ်းသိမ်းစောင့်ရှောက်ခြင်းအား Transaction Management ဟု ခေါ်ဆိုပါသည်။

End User Interface

Database အတွင်းရှိ အချက်အလက်များအား အသုံးပြုသူများမှ အလွယ်တကူ ဆက်သွယ် အသုံးပြုနိုင်စေရန် ရည်ရွယ်၍ ပံ့ပိုးပေးထားသော အပလီကေးရှင်းများ ဖြစ်ကြ၏။ အသုံးပြုသူ၏ Query ၏ ရလဒ်အား ဇယားအဖြစ်သော်၎င်း၊ Report အနေဖြင့်သော်၎င်း လွယ်ကူစွာ ဖော်ပြပေးနိုင်ရန် အထောက်အကူပြုစေသော အပလီကေးရှင်းများ ဖြစ်ကြပါသည်။

MySQL ၏ MySQL Workbench၊ Query Browser နှင့် Oracle Client များသည် အထက်ပါ အမျိုးအစား အပလီကေးရှင်းများ ဖြစ်ကြပါသည်။

DBMS များတွင် အထက်ပါ ဖန်ရှင်များအပြင်၊ အသုံးပြုရလွယ်ကူစေရန် Backup လုပ်သည့် ဖန်ရှင်များ၊ Performance ကို တိုးတက်စေရန် ဖွဲ့စည်းပုံကို ပြန်လည်ပြုပြင်နိုင်သော Analyze နှင့် Optimize အစရှိသည့် ဖန်ရှင်များ အပြင် အခြားသော အသုံးဝင်သော ဖန်ရှင်များကိုလည်း ပံ့ပိုးပေးလေ့ရှိပါသည်။

ဤကဲ့သို့ DBMS အား အသုံးပြု၍ ဖွဲ့စည်းထားသော Information System မျိုးအား Database System ဟု ခေါ်ဆိုလေ့ရှိပါသည်။ တနည်းဆိုရသော် Database System တစ်ခုသည်၊ Database ၊ DBMS နှင့် အသုံးပြုသော အပလီကေးရှင်းတို့ဖြင့် ဖွဲ့စည်းထားသည်ဟု ဆိုနိုင်မည် ဖြစ်ပါသည်။

ကျွှန်တော်တို့သည် ပြီးခဲ့သော Database ဆိုသည်မှာ၊ Data နှင့် Information နှင့် ယခုတစ်ခေါက် Database Management System တို့ဖြင့် Database ဆိုသည်မှာအဘယ်နည်း၊ ဘာကြောင့် Database ကို အသုံးပြုရ သနည်း၊ ဘယ်အရာသည် Data ဖြစ်၍ Information ဖြစ်သနည်း၊ Data နှင့် Information တို့သည် မည်ကဲ့သို့ ပတ်သက်သနည်းနှင့် Database များအား မည်ကဲ့သို့ စီမံခန့်ခွဲကာ အသုံးပြုနေသနည်း အစရှိသည့် Database နှင့် ပတ်သက်သော အခြေခံ အကြောင်းအရာများကို လေ့လာခဲ့ပါသည်။ ဆက်လက်၍ နောက်အခန်းများတွင် Data Model နှင့် ပတ်သက်သော အကြောင်းအရာများကို လေ့လာသွားပါဦးမည်။

လေးစားစွာဖြင့်။

မင်းလွင် 

Information and Data

ကျွှန်တော်တို့သည် နေတဓူဝ သတင်း၊ အကြောင်းအရာ၊ အချက်အလက် အစရှိသည့် စကားလုံးများကို အသုံးပြုနေကြပါသည်။ သတင်းသွားယူရအောင်၊ အချက်အလက်တွေကို စုစောင်းရန်လိုသည်။ အကြောင်းအရာကို ရှာဖွေနိုင်သည် အစရှိသဖြင့် နေရာအမျိုးမျိုးတွင် အထက်ပါစကားလုံးများကို အသုံးပြုဘူးမည် ဖြစ်သည်။

အထက်ပါစကားလုံးများသည် တူညီပါသလားဟု မေးလာလျှင် မတူညီပါဟု အတော်များများ ဖြေဆိုကြမည်  ဖြစ်ပါသည်။ ဘယ်လိုမတူညီတာလဲဆိုသည်ကို စဉ်းစားဘူးပါသလားဟု ဆက်မေးလာပါက မစဉ်းစားဘူးပါ ဟု အဖြေကများမည် ထင်ပါသည်။ ကျွှန်တော်တို့ ဒီတစ်ခေါက် အိုင်တီနည်းပညာဘက်ပိုင်း အမြင်မှနေ၍ အကြောင်းအရာနှင့် အချက်အလက်တို့ အကြောင်းကို စဉ်းစားကြည့်ပါမည်။

ဘာကြောင့် ဒီစကားလုံးများ၏ ကွာခြားချက်ကို စဉ်းစားရန်လိုသနည်း ဟု မေးစရာရှိပါမည်။ ကျွှန်တော်တို့ နေ့တဓူဝ စကားပြောရာတွင် သိပ်ပြီးခွဲခြားရန် မလိုအပ်သော်လည်း၊ Database ကို လေ့လာမည် အသုံးပြုပြီး အပလီကေးရှင်းများအား တည်ဆောက်တော့မည် ဆိုပါက အကြောင်းအရာနှင့် အချက်အလက်တို့၏ ကွာခြားချက်ကို ရှင်းလင်းစွာသိမြင်ထားရန် လိုအပ်သောကြောင့် ဖြစ်ပါသည်။ 

ကျွှန်တော်တို့ ဤနေရာတွင် ခေါ်ဆိုသွားမည့် အချက်အလက်ဆိုသည်မှာ အိုင်တီဝေါဟာရ Data ကို ရည်ညွှန်းပါသည်။ တဖန် အကြောင်းအရာဆိုသည်မှာလည်း Information ကို ရည်ညွှန်းပါသည်။

Data

အချက်အလက် (Data) ဆိုသည်မှာ သဘာဝ ဖြစ်ရပ်များအား စမ်းသပ်၊ တိုင်းတာ၊ တွက်ချက်၍ ရရှိလာသော လက်ရှိဖြစ်ရပ်များ ဖြစ်ပြီး၊ စကားလုံး၊ ကိန်းဂဏန်း၊ ပုံသဏ္ဍန်၊ အသံ အစရှိသည့် မီဒီယာ ပုံစံများဖြင့် ဖော်ပြပေးနိုင်ပါသည်။ ဥပမာအားဖြင့် လူတစ်ယောက်၏ အချက်အလက်ဆိုပါက အမည်နှင့် လိပ်စာများသည် စာလုံးများဖြင့်ဖော်ပြနိုင်ပြီး၊ အသက်၊ ခန္ဓာကိုယ် အလေးချိန် အစရှိသည့် အချက်အလက်များသည် ကိန်းဂဏာန်းများ ဖြင့် ဖော်ပြလေ့ရှိပါသည်။ တဖန် မှတ်ပုံတင် ဓာတ်ပုံသည် ပုံသဏ္ဍန်ဖြင့် ဖော်ပြပေးသော အချက်အလက်များ ဖြစ်ကြပါသည်။

ဤကဲ့သို့သော အချက်အလက်များအား မည်သည့်အပလီကေးရှင်းများမှာ မဆို အသုံးပြုနိုင်ပါသည်။ ဥပမာအားဖြင့် Amazon မှာ ဈေးဝယ်သည့်အခါတွင်၎င်း၊ သန်းခေါင်စာရင်းတိုင်သည့်အခါတွင်၎င်း၊ ဗီဒီယိုငှားရန် မန်ဘာကဒ်လုပ်သည့်အခါတွင်၎င်း အထက်ပါအချက်အလက်များအား အသုံးပြုနိုင်မည် ဖြစ်ပါသည်။

Information

ဤနေရာတွင် ဆိုလိုသည့်အကြောင်းအရာဆိုသည်မှာ Information ကို ရည်ညွှန်းပါသည်။ Information ဆိုသည်မှာ လက်ခံရရှိသူက လိုအပ်နေသော အရာတစ်ခုဖြစ်ပြီး၊ လက်ခံရရှိသူအတွက် အကျိုး ဖြစ်ထွန်းစေနိုင်သော အချက်အလက်မျိုးကို ဆိုလိုပါသည်။ ဥပမာအားဖြင့် အခြေအနေအပေါ် မှုတည်၍ ဆုံးဖြတ်ချက်ကို ချမှတ်ရန် လိုအပ်သောအခါ၊ အချက်အလက်များအား သုံးသပ်ပြီး ရရှိလာသော ရလဒ်က ဆုံးဖြတ်သူ၏ အဆုံးအဖြတ်အား အကျိုးသက်ရောက်စေနိုင်သော အချက်အလက်များအား Information ဟု ခေါ်ဆိုပါသည်။ တနည်းဆိုရသော် အသုံးပြုသူအတွက် အကျိုးမရှိနိုင်သော အချက်အလက်များအား Information ဟု မသတ်မှတ်နိုင်ပါ။

Data နှင့် Information တို့၏ ကွာခြားချက်ကို သိရှိစေနိုင်ရန်၊ နမှုနာတစ်ခုကို စဉ်းစားကြည့်ပါမည်။ ဥပမာအားဖြင့် စတိုးဆိုင်တစ်ခု၏ အရောင်းစာရင်းအား သုံးသပ်နိုင်ရန် POS (Point Of Sale) စစ္စတမ်တစ်ခု ရှိသည် ဆိုကြပါစို့။ ကုန်ပစ္စည်းတစ်ခုရောင်းတိုင်း အရောင်းစာရေးက ဘားကုဒ်အား ဖတ်ပြီးတစ်ခုခြင်း မည်သည့်အချိန်က၊ ဘယ်လောက်ဖြင့်၊ ဘယ်နှစ်ခု ဝယ်ယူသွားသည်ဟု စာရင်းသွင်းပါမည်။ ထိုအချက်အလက်များအား Database တွင် သိမ်းဆည်းထားပါမည်။

စတိုးဆိုင်၏ အဝယ်တာဝန်ခံသည် ထိုအချက်အလက်များအား စာရင်းချုပ်ခြင်းအားဖြင့်၊ ဘယ်ကာလတွင် ဘယ်ပစ္စည်းသည် ရောင်းကောင်းပါသဖြင့် ဘယ်လောက်ဝယ်ထားသင့်သည်၊ ဒီပစ္စည်းအား ဝယ်ယူသူသည် အခြား ဒီပစ္စည်းအားလည်း တွဲဝယ်လေ့ရှိသောကြောင့်၊ တွဲဘက်ပစ္စည်းများကိုလည်း ကြိုတင် ပြင်ဆင်ထားသင့်သည် အစရှိသည့် ဆုံးဖြတ်ချက်များအား ချမှတ်နိုင်မည် ဖြစ်ပါသည်။

ဤကဲ့သို့ စုစောင်းထားသော အချက်အလက်များအား အသိဉာဏ် (Knowledge) အား အသုံးချကာ အသုံးပြုသူအတွက် အကျိုးရှိသော Information များအား ဖြစ်ပွားစေနိုင်ခြင်း ပင်ဖြစ်၏။ အဆိုပါ နမှုနာအား ကြည့်ခြင်းအားဖြင့် အချက်အလက်များအား စုစောင်းကာ ရရှိလာနိုင်သော Information နှင့် ထိုအချက်အလက်များအား စုစည်း၍ တွက်ချက်ယူခြင်း အားဖြင့် ရရှိလာနိုင်သော Information ဟူ၍ နှစ်မျိုး နှစ်စားရှိနိုင်ကြောင်း သိရှိနိုင်မည် ဖြစ်ပါသည်။

Data Base နှင့် Info Base

Database များ၏ ရည်ရွယ်ချက် အပေါ်မှုတည်၍ တည်ဆောက်ပုံမှ အစအသုံးပြုပုံတို့သည် လွန်စွာ ကွာခြား၏။ နားလည်လွယ်ကူစေရန် Data များအား အခြေခံ၍ အသုံးပြုလိုသော Database များအား ဤနေရာတွင် Data Base ဟု ၎င်း၊ Information များအား အဓိကထား အသုံးပြုလိုသော Database များအား ဤနေရာတွင် Info Base ဟု၎င်း အသုံးပြုသွားပါမည်။

Data ကို အခြေခံသော Data Base များသည် ရည်ရွယ်ချက်အမျိုးမျိုးတွင် အချက်အလက်များအား တူညီစွာ အသုံးပြုနိုင်ရန် ရည်ရွယ်၍ Database Management System (DBMS) များအား အသုံးပြုကာ၊ အချက်အလက်များအား ပတ်သက်ကြောင်းအား သတ်မှတ်ပြီး သိမ်းဆည်း ထားလေ့ရှိပါသည်။ အသုံးပြုသူတို့သည် မည်သည့်အချက်အလက်သည် Database အတွင်းတွင် မည်ကဲ့သို့ တည်ရှိသည်ကို ကြိုတင်သိရှိနိုင်ပြီး၊ မည်ကဲ့သို့ရှာဖွေပါက မည်သည့် အချက်အလက်များကို ရရှိနိုင်သည် ဆိုသည်ကို သိရှိနိုင်ပါသည်။

ဥပမာအားဖြင့် ဘဏ်လုပ်ငန်းများ၏ Online System များတွင်၊ ATM တစ်ခုမှ ငွေထုတ်သည့် ပရိုဂရမ်တစ်ခုကို စဉ်းစားကြည့်ပါမည်။ ဘဏ်စာရင်းပိုင်ရှင် တစ်ယောက်မှ ငွေထုတ်ယူသောအခါ ATM ၏ ငွေ အသွင်းအထုတ် ပရိုဂရမ်သည် Bank Account စာရင်းတွင် ထုတ်ယူလိုသည့် Account အား ရှာဖွေပါမည်။ တွေ့ရှိပါက လက်ကျန်စာရင်းတွင် ထုတ်ယူလိုသည့် ပမာဏအား ဆက်လက်ရှာဖွေပြီး၊ ထုတ်ယူလိုသည့် ပမာဏအတွင်း ဖြစ်ပါက၊ ထုတ်ပေးပြီး၊ လက်ကျန်စာရင်းအား ပြုပြင်သိမ်းဆည်းမည် ဖြစ်သည်။ ဤနေရာတွင် ငွေအသွင်းအထုတ် ပရိုဂရမ်သည် အချက်အလက်များအား အသုံးပြုသူဖြစ်ပြီး၊ Account နှင့် လက်ကျန်စာရင်းသည် မည်သို့ပတ်သက်ပြီး၊ Account တစ်ခု၏ လက်ကျန်စာရင်းအား မည်သို့ရှာဖွေရမည် ဆိုသည်ကို တိတိကျကျ သိရှိနေရန် လိုအပ်ပါသည်။

အခြားတစ်ဘက် Information ကို အခြေခံသော Info Baseများတွင်အချက်အလက် ရှာဖွေရာတွင် ဤသို့မဟုတ်။ ရှာဖွေလိုသော အချက်အလက်သည် Database ရှိနေ မရှိနေ ကြိုတင် သိရှိထားရန် မလိုအပ်ပါ။ ဥပမာအားဖြင့် Amazon Book Store တွင် လိုချင်သော စာအုပ်တစ်အုပ်ကို ရှာဖွေရာတွင် Keyword တစ်ခုဖြင့် စာအုပ်ခေါင်းစဉ်များအား ရှာဖွေပါမည်။ ထို့အပြင် ခေါင်းစဉ်တစ်ခုတည်းဖြင့် ရှာဖွေလိုသော Information အား ဖော်ပြနိုင်ခြင်း မရှိပါသဖြင့် ထိုစာအုပ်၏ စာသားအတွင်းရှိ Keyword များအား index အနေဖြင့် ဖွဲ့စည်းထားပြီး၊ index များအထိ ရှာဖွေ စေပါသည်။ ခေါင်းစဉ်များ၊ keyword index များတွင် ရှာဖွေ၍ ရရှိလာသော အချက်အလက်များအား ဖော်ပြပေးပါသည်။ တဖန် ရရှိလာသော ရလဒ်များသည် ရှာဖွေလိုသည့် အကြောင်းအရာ ဖြစ်ချင်မှ ဖြစ်နိုင်ပေလိမ့်မည်။ အကြောင်းများ ခေါင်းစဉ်နှင့် keyword များအား ဖွဲ့စည်းရာတွင် ကွာဟမှု့များ ဖြစ်ပေါ်စေနိုင်သောကြောင့် ဖြစ်ပါသည်။ ဤနေရာတွင် သတိပြုရန် အချက်မှာ Info Base တွင် ရှာဖွေ၍ ရရှိလာသော အချက်အလက်များသည် မိမိက လိုချင်နေသော အချက်အလက် ဟုတ်မဟုတ် ဆုံးဖြတ်ရန် လိုအပ်ခြင်း ဖြစ်ပါသည်။


မှတ်ချက်။

ဆရာ Sata Hideto ၏ သင်ခန်းစာ မှတ်စုများမှပြန်လည် ဖော်ပြခြင်း ဖြစ်ပါသည်။
http://www.tiu.ac.jp/english2/departments/faculty/commercials/sato.html

ဆက်ပါဦးမည်။ လေးစားစွာဖြင့်။
မင်းလွင်