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) ၏ သင်ခန်းစာများမှ ပြန်လည် ကောက်နှုတ်တင်ပြပါသည်။

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

မင်းလွင်