Relational Database Fundamentals (Relational database ရဲ့ အခြေခံများ)

A3.1.1: Explain the features, benefits and limitations of a relational database.
မြန်မာလို: relational database (table တွေ ချိတ်ဆက်ထားတဲ့ database) ရဲ့ ထူးခြားချက်၊ အကျိုးကျေးဇူးနဲ့ ကန့်သတ်ချက်တွေကို ရှင်းပြနိုင်ရပါမယ်။

အဓိက အယူအဆများ

Database ဆိုတာ ဘာလဲ

Database (ဒေတာ သိမ်းဆည်းတဲ့ စနစ်) ဆိုတာ ဆက်စပ်နေတဲ့ ဒေတာတွေကို ဖွဲ့စည်းပုံ တကျ စုပြီး ရေရှည် သိမ်းထားတဲ့ အစုအဝေး တစ်ခုပါ။ User တွေ၊ application တွေ အများကြီးက အဲဒီ ဒေတာကို query (database ထဲက ဒေတာကို ရှာ၊ ပြင်ဖို့ ပေးတဲ့ အမိန့်) လုပ်နိုင်၊ update လုပ်နိုင်၊ မျှသုံးနိုင်ပါတယ်။ Database ကို စီမံပေးတဲ့ software (table တွေ ဖန်တီးတာ၊ စည်းမျဉ်းတွေကို လိုက်နာစေတာ၊ query တွေ run တာ၊ တစ်ချိန်တည်း သုံးနေတဲ့ user တွေကို ကိုင်တွယ်တာ) ကို Database Management System (DBMS) လို့ ခေါ်ပါတယ်။ ဥပမာ MySQL၊ PostgreSQL၊ Oracle Database နဲ့ Microsoft SQL Server တို့ ဖြစ်ပါတယ်။

Relational database (table တွေ ချိတ်ဆက်ထားတဲ့ database) က အသုံးအများဆုံး အမျိုးအစားပါ။ ဒေတာကို row (အလျားလိုက် အတန်း) နဲ့ column (ဒေါင်လိုက် ကော်လံ) တွေပါတဲ့ table (database ထဲက ဇယား) တွေအဖြစ် စီစဉ်ထားပြီး table တွေ အချင်းချင်း ဘယ်လို ချိတ်ဆက်နေလဲ ဆိုတာကို key (row တွေကို ခွဲခြားဖို့ ဒါမှမဟုတ် table တွေကို ချိတ်ဖို့ သုံးတဲ့ column) တွေနဲ့ ဖော်ပြပါတယ်။ Relational model ကို Edgar Codd က 1970 ခုနှစ်က သုတေသန စာတမ်း တစ်စောင်မှာ စတင် မိတ်ဆက်ခဲ့ပြီး အဲဒီကတည်းက လုပ်ငန်း စနစ်တွေမှာ အဓိက နေရာ ယူထားပါတယ်။

အဓိက ဝေါဟာရများ

Term အဓိပ္ပာယ် နေ့စဉ်ဘဝက တူညီတဲ့ အရာ
Table အရာ အမျိုးအစား တစ်မျိုးအကြောင်း ဒေတာကို သိမ်းတဲ့၊ row နဲ့ column ပါတဲ့ နှစ်ဘက်မြင် ဇယားကွက် Spreadsheet (ဇယားကွက် စာရင်း software) ထဲက sheet တစ်ခု
Record (ဒါမှမဟုတ် row) Table ထဲက ထည့်သွင်းချက် တစ်ခု၊ ဆိုလိုတာက အဲဒီ အရာ အမျိုးအစားထဲက သီးခြား တစ်ခု Spreadsheet ရဲ့ row တစ်ကြောင်း
Field (ဒါမှမဟုတ် column၊ attribute) Record တိုင်းမှာ ပါတဲ့ အချက်အလက် တစ်ခု Column ခေါင်းစဉ် တစ်ခု
Entity Table က ကိုယ်စားပြုတဲ့ လက်တွေ့ ကမ္ဘာက အရာ (Member, Class, Booking) Sheet tab ပေါ်က နာမည်
Instance Entity တစ်ခုရဲ့ တစ်ခုချင်း ဖြစ်ရပ် (member 1002, Marlon Tan) Row တစ်ကြောင်းက ကိုယ်စားပြုတဲ့ “တကယ့်” လူ ဒါမှမဟုတ် အရာ
Schema Database ရဲ့ ဖွဲ့စည်းပုံ: ဘယ် table တွေ ရှိလဲ၊ table တစ်ခုစီမှာ ဘယ် field တွေ ပါလဲ၊ အဲဒီ field တွေက ဘယ် type တွေလဲ၊ table တွေ ဘယ်လို ချိတ်ဆက်နေလဲ Blueprint (တည်ဆောက်ဖို့ ပုံစံ ပုံကြမ်း)၊ ဒေတာ မဟုတ်ပါ

ဒါတွေက ရေးဖြေတဲ့ အဖြေတွေမှာ သုံးရမယ့် တိကျတဲ့ term တွေပါ။ State (ဖော်ပြပါ) ဒါမှမဟုတ် Define (အဓိပ္ပာယ်ကို တိတိကျကျ ဖော်ပြပါ) လို့ မေးတဲ့ မေးခွန်းတွေမှာ ဒီ term တွေရဲ့ အဓိပ္ပာယ်ကို သိထားတာ အရေးအကြီးဆုံးပါ။

“Field”၊ “column” နဲ့ “attribute” သုံးခုလုံးက အဓိပ္ပာယ် အတူတူပါ၊ “record” နဲ့ “row” ကလည်း အတူတူပါပဲ။ ဘယ်ဟာ သုံးသုံး မှန်ပါတယ်၊ ဒါပေမယ့် တစ်စုကို ရွေးပြီး အဖြေ တစ်ခုအတွင်းမှာ တစ်ပြေးညီ သုံးပါ။ “Relation” ဆိုတာ relational model မှာ table ကို ခေါ်တဲ့ တရားဝင် နာမည်ပါ။ ဒါပေမယ့် အဖြေတွေမှာ မသုံးပါနဲ့၊ ဘာလို့လဲဆိုတော့ “relationship” (table တွေကြား ဆက်နွယ်မှု) နဲ့ ရောထွေးလွယ်လို့ပါ။ Relationship ဆိုတာ 1:M (one-to-many) ဒါမှမဟုတ် M:M (many-to-many) လိုမျိုး ဆက်နွယ်မှုတွေဖြစ်ပြီး table နဲ့ မတူတဲ့ အယူအဆ တစ်ခုပါ။

Relational model ရဲ့ အဓိက ထူးခြားချက် ငါးခု

Database တစ်ခုကို “relational” ဖြစ်စေတာက ဒီ ထူးခြားချက် ငါးခု ပေါင်းထားတာပါ:

  1. Tables: ဒေတာကို နာမည်ပေးထားပြီး column အစု ပုံသေ ရှိတဲ့ table တွေထဲမှာ သိမ်းပါတယ်။ Table တစ်ခုထဲက row တစ်ကြောင်းစီက အဲဒီ table ကိုယ်စားပြုတဲ့ entity ရဲ့ instance တစ်ခုကို ကိုယ်စားပြုပါတယ်။
  2. Primary keys (row တစ်ခုချင်းကို ခွဲခြားပေးတဲ့ key): table တိုင်းမှာ row တစ်ကြောင်းချင်းကို မထပ်အောင် ခွဲခြားသိစေတဲ့ တန်ဖိုး ရှိတဲ့ column တစ်ခု (ဒါမှမဟုတ် column အနည်းငယ် အစု) ရှိပါတယ်။ Row နှစ်ကြောင်းမှာ primary key တန်ဖိုး တူလို့ မရပါဘူး၊ primary key တန်ဖိုးက null (တန်ဖိုး ဘာမှ မထည့်ထားခြင်း) လည်း ဖြစ်လို့ မရပါဘူး။
  3. Foreign keys (တခြား table ရဲ့ primary key ကို ညွှန်းတဲ့ column): table တစ်ခုထဲက column တစ်ခုပါ၊ တခြား table တစ်ခုထဲက row တစ်ကြောင်းရဲ့ primary key တန်ဖိုးကို သိမ်းထားပါတယ်။ Relational model က table တွေကြား ချိတ်ဆက်မှုကို ဒီနည်းနဲ့ ဖော်ပြပါတယ်။
  4. Composite keys (column အများ ပေါင်းထားတဲ့ primary key): column တစ်ခုတည်းက ကိုယ့်ဘာသာ မထပ်တဲ့ တန်ဖိုး မဖြစ်တဲ့အခါ column နှစ်ခု ဒါမှမဟုတ် ပိုများတာကို ပေါင်းပြီး ဖွဲ့ထားတဲ့ primary key ပါ။ Data Types and Keys (Data type နဲ့ key များ) မှာ အသေးစိတ် လေ့လာပါမယ်။
  5. Relationships: foreign key တွေက လက်တွေ့ အကောင်အထည် ဖော်ပေးတဲ့ table တွေကြား သဘောတရားအရ ဆက်စပ်မှုတွေပါ။ Relationship ပုံစံ သုံးမျိုး ရှိပါတယ်: one-to-one (တစ်ဖက်က record တစ်ခုက တစ်ဖက်က record တစ်ခုနဲ့ပဲ ဆက်နွယ်တာ၊ ဥပမာ စာသင်ခန်း တစ်ခန်းမှာ whiteboard တစ်ခု)၊ one-to-many (တစ်ဖက်က record တစ်ခုက တစ်ဖက်က record အများနဲ့ ဆက်နွယ်တာ၊ ဥပမာ ဆရာ တစ်ယောက်မှာ ကျောင်းသား အများ) နဲ့ many-to-many (တစ်ဖက်က record အများက တစ်ဖက်က record အများနဲ့ ဆက်နွယ်တာ၊ ဥပမာ ကျောင်းသားတွေက ဘာသာရပ် အတန်း အများကြီး တက်ပြီး အတန်း တစ်ခုစီမှာ ကျောင်းသား အများကြီး ရှိတာ)။

“Relational” ဆိုတဲ့ စကားလုံးက သင်္ချာရဲ့ relation သီအိုရီကနေ လာတာပါ: Codd ရဲ့ 1970 စာတမ်းမှာ table တစ်ခုစီကို သင်္ချာ relation (record တွေ စုထားတဲ့ အစု တစ်ခု) အဖြစ် ပုံဖော်ထားပါတယ်။ ထူးခြားချက် 5 မှာ ပြောခဲ့တဲ့ table တွေကြား relationship တွေကို အစွဲပြုပြီး နာမည်ပေးထားတာ မဟုတ်ပါဘူး။ ဒီ နယ်ပယ်မှာ အခြေခံ စကားလုံးက အဓိပ္ပာယ် နှစ်မျိုး ရှိနေလို့ ဒေတာ ဖွဲ့စည်းပုံအတွက် “table” ကို၊ table တွေကြား ချိတ်ဆက်မှုအတွက် “relationship” ကို သုံးတာ ပိုကောင်းပါတယ်။

Relational model ရဲ့ အကျိုးကျေးဇူးများ

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

Benefit (အကျိုးကျေးဇူး) ဆိုလိုချက်
Data consistency (အချက် တစ်ခုက နေရာတိုင်းမှာ တူညီနေခြင်း) အချက် တစ်ခုကို နေရာ တစ်ခုတည်းမှာ သိမ်းထားလို့ သူ့ဘာသာသူ မကိုက်ညီ ဖြစ်လို့ မရပါဘူး။ Customer တစ်ယောက်ရဲ့ လိပ်စာကို တစ်ကြိမ် update လုပ်လိုက်တာနဲ့ အဲဒီ လိပ်စာ ပေါ်တဲ့ နေရာတိုင်းမှာ update ဖြစ်သွားပါတယ်။
Data integrity (ဒေတာ မှန်ကန်ပြီး မပျက်စီးဘဲ ရှိနေခြင်း) Database ထဲမှာ ပါပြီးသား စည်းမျဉ်းတွေ ဖြစ်တဲ့ data type (ဒေတာ အမျိုးအစား)၊ primary key၊ foreign key နဲ့ constraint တွေက မမှန်တဲ့ ဒေတာကို မဝင်ခင်မှာပဲ ငြင်းပယ်ပါတယ်: date column တစ်ခုက “next Tuesday” (နောက် အင်္ဂါနေ့) ကို လက်မခံပါဘူး။ Constraint ဆိုတာ column ထဲ ထည့်တဲ့ ဒေတာ လိုက်နာရမယ့် စည်းမျဉ်းပါ။
Reduced data duplication (ဒေတာ ထပ်နေမှု လျော့ခြင်း) ထပ်နေတဲ့ တန်ဖိုးတွေ (ဥပမာ order တိုင်းမှာ ပါတဲ့ supplier ရဲ့ လိပ်စာ အပြည့်အစုံ) ကို သူတို့ကိုယ်ပိုင် table တွေထဲ ခွဲထုတ်ပြီး key နဲ့ ညွှန်းပါတယ်။
Reduced redundancy (မလိုအပ်ဘဲ ထပ်နေတဲ့ ဒေတာ လျော့ခြင်း) အပေါ်က အချက်နဲ့ အနီးကပ် ဆက်စပ်ပါတယ်: အချက် တစ်ခုစီက နေရာ တစ်ခုတည်းမှာပဲ ရှိပါတယ်။ အချက် တစ်ခုတည်းကို row တချို့မှာ update လုပ်ပြီး တချို့မှာ မလုပ်မိတဲ့ အခြေအနေကို ရှောင်ပေးပါတယ်။
Data retrieval (ဒေတာကို ရှာပြီး ပြန်ထုတ်ယူခြင်း) SQL (database ကို မေးခွန်းမေးဖို့နဲ့ ပြင်ဆင်ဖို့ သုံးတဲ့ စံ language) နဲ့ row သန်းပေါင်းများစွာပေါ်မှာ တိကျတဲ့ မေးခွန်းတွေ မေးပြီး millisecond (တစ်စက္ကန့်ရဲ့ တစ်ထောင်ပုံ တစ်ပုံ) ပိုင်းအတွင်း အဖြေ ရနိုင်ပါတယ်။ Spreadsheet ထဲမှာ ရှာတာထက် အများကြီး ပိုမြန်ပြီး ပိုစုံစုံလင်လင် မေးနိုင်ပါတယ်။
Concurrency control (transaction တွေ တစ်ပြိုင်နက် မှန်ကန်စွာ run အောင် ထိန်းခြင်း) User အများကြီး တစ်ချိန်တည်း ပြင်နေတာကို DBMS က ညှိပေးပါတယ်။ Lock (တခြားသူ မပြင်နိုင်အောင် ခဏ ပိတ်ထားခြင်း) တွေ သုံးပြီး တစ်ချိန်တည်း ဖြစ်တဲ့ update နှစ်ခုက တစ်ခုနဲ့ တစ်ခု မပျက်စီးစေအောင် လုပ်ပေးပါတယ်။
Reliable transaction processing (transaction တွေကို စိတ်ချရအောင် ဆောင်ရွက်ခြင်း) အကုန် အောင်မြင်ရမယ် ဒါမှမဟုတ် အကုန် မဖြစ်ရဘူး ဆိုတဲ့ operation အစုတွေ (ဥပမာ ဘဏ် ငွေလွှဲ) ကို atomic transaction (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ်တဲ့ database လုပ်ဆောင်ချက် အစု) တွေအဖြစ် run ပါတယ်။ ဒါကို HL (IB သင်တန်းရဲ့ ပိုမြင့်တဲ့ အဆင့်) အတွက် Transactions and Views (Transaction နဲ့ view များ) မှာ လေ့လာပါမယ်။
Security features (လုံခြုံရေး လုပ်ဆောင်ချက်များ) User account၊ role (အခန်းကဏ္ဍအလိုက် ပေးတဲ့ ခွင့်ပြုချက် အစု)၊ permission (ခွင့်ပြုချက်)၊ view (query ရလဒ်ကို table တစ်ခုလို ကြည့်လို့ရအောင် ပြတဲ့ virtual table) နဲ့ audit log (ဘယ်သူ ဘာလုပ်ခဲ့လဲ မှတ်ထားတဲ့ မှတ်တမ်း) တွေကို သုံးပြီး ဘယ် row တွေကို ဘယ်သူ မြင်ခွင့်၊ ပြင်ခွင့် ရှိလဲ database က ထိန်းချုပ်နိုင်ပါတယ်။
Scalability (ဒေတာ များလာတဲ့အခါမှာလည်း ကောင်းကောင်း ဆက်အလုပ်လုပ်နိုင်မှု) ကောင်းကောင်း ဒီဇိုင်းဆွဲထားတဲ့ relational database တွေက သာမန် hardware ပေါ်မှာ row သန်းပေါင်းများစွာကနေ ဘီလီယံ ချီအထိ ကိုင်တွယ်နိုင်ပါတယ်။ Index (ရှာတာ မြန်အောင် လုပ်ထားတဲ့ ညွှန်းစာရင်း)၊ partitioning (database ကို အပိုင်းတွေ ခွဲသိမ်းခြင်း) နဲ့ replication (ဒေတာ copy တွေကို နေရာ အများမှာ ထားခြင်း) လို tuning (စွမ်းဆောင်ရည် ကောင်းအောင် ညှိခြင်း) ရွေးချယ်စရာတွေနဲ့ ဒါကို ထပ်ချဲ့နိုင်ပါတယ်။
Community support (အသုံးပြုသူ အသိုင်းအဝိုင်းရဲ့ အကူအညီ) Relational model က နှစ်ငါးဆယ်လုံး လုပ်ငန်းလောကရဲ့ ပုံမှန် ရွေးချယ်မှု ဖြစ်ခဲ့ပါတယ်: အသိပညာ အရင်းအမြစ် အများကြီး၊ ရင့်ကျက်ပြီးသား tool တွေ၊ သင်တန်း အများအပြားနဲ့ ရွေးချယ်စရာ တည်ငြိမ်တဲ့ product အများကြီး ရှိပါတယ်။

အကျိုးကျေးဇူး တစ်ခုက database တကယ် ဘာလုပ်ပေးလဲ၊ အဲဒါက အဖွဲ့အစည်းအတွက် ဘယ်နေရာမှာ ကွာခြားမှု ဖြစ်စေလဲ ဆိုတာကို ပြမှ ယုံကြည်စရာ ကောင်းပါတယ်။ “ပိုလုံခြုံတယ်” ဒါမှမဟုတ် “ပိုမြန်တယ်” လို့ ရေးရင် ဖတ်သူကို သိပ်ပြီး ဘာမှ မပြောပြပါဘူး။ ဒီ ဥပမာနဲ့ နှိုင်းယှဉ်ကြည့်ပါ: “Concurrency control: လက်မှတ် ကောင်တာ တစ်ခုက ထိုင်ခုံ တစ်ခုံကို ရောင်းနေစဉ် DBMS က အဲဒီ ထိုင်ခုံကို lock လုပ်ထားလို့ လူများတဲ့ သောကြာနေ့ ညမှာ ရုပ်ရှင်ရုံရဲ့ တခြား ကောင်တာတွေက အဲဒီ ထိုင်ခုံကိုပဲ ထပ်ရောင်းလို့ မရအောင် တားပေးပါတယ်။” ယေဘုယျ ထူးခြားချက် စာရင်း ရေးမယ့်အစား မေးခွန်းထဲက အခြေအနေ လိုအပ်တဲ့ အကျိုးကျေးဇူးတွေကို ရွေးပါ။

Relational model ရဲ့ ကန့်သတ်ချက်များ

အကျိုးကျေးဇူးတွေနဲ့အတူ ဆွေးနွေးသင့်တဲ့ ကန့်သတ်ချက် ခြောက်ခု ရှိပါတယ်။ ဒါတွေက “relational model က မကောင်းဘူး” လို့ ဆိုလိုတာ မဟုတ်ပါဘူး၊ တခြား နည်းလမ်း တစ်ခုက ပိုသင့်တော်နိုင်တဲ့ အခြေအနေတွေကို ပြတာပါ။

Limitation (ကန့်သတ်ချက်) ဘာပြဿနာ ဖြစ်လဲ
Rigid schema (ပြောင်းရခက်တဲ့ ပုံသေ schema) Column အစုကို ဒီဇိုင်းဆွဲချိန်မှာ ပုံသေ သတ်မှတ်ထားပါတယ်။ Row ဘီလီယံ ချီ ရှိတဲ့ table တစ်ခုမှာ field အသစ် တစ်ခု ထည့်တာက ကုန်ကျစရိတ် များပြီး row တစ်ကြောင်းချင်းအလိုက် column တွေ မတူအောင် ထားလို့ မရပါဘူး။
Design complexity (ဒီဇိုင်းဆွဲရ ရှုပ်ထွေးမှု) Normalisation (ဒေတာ ထပ်မနေအောင် table တွေကို စီစဉ်ခြင်း) လုပ်ထားတဲ့ သန့်ရှင်းတဲ့ ဒီဇိုင်း တစ်ခု ရဖို့ ကျွမ်းကျင်မှု လိုပါတယ်: မကောင်းတဲ့ ERD (entity တွေနဲ့ ဆက်နွယ်မှုတွေကို ပြတဲ့ ပုံ) တွေနဲ့ normal form (normalisation ရဲ့ အဆင့်) တွေအထိ မရောက်တာက နောက်ပိုင်းမှာ redundancy နဲ့ update anomaly (ဒေတာ ပြင်တဲ့အခါ မကိုက်ညီမှု ဖြစ်တာ) တွေကို ဖြစ်စေပါတယ်။
Hierarchical data handling (အဆင့်ဆင့် ဖွဲ့ထားတဲ့ ဒေတာကို ကိုင်တွယ်ခြင်း) Tree ပုံစံ ဒါမှမဟုတ် graph ပုံစံ ဒေတာ (အဖွဲ့အစည်း ဖွဲ့စည်းပုံ ဇယား၊ social network တွေ၊ reply တွေပါတဲ့ comment thread တွေ) ကို ဖော်ပြရ ခက်ပြီး join (table တွေကို ချိတ်ပြီး ဒေတာ ပေါင်းယူခြင်း) တွေ သုံးပြီး ဖြတ်သွားကြည့်ရင် နှေးပါတယ်။
Object-relational impedance mismatch (OOP object တွေနဲ့ relational table တွေကြား မကိုက်ညီမှု) OOP (object တွေကို အခြေခံပြီး program ရေးနည်း) code က object (class တစ်ခုကနေ ဖန်တီးထားတဲ့ instance) တွေနဲ့ စဉ်းစားပါတယ် (List<Booking> field ပါတဲ့ Member တစ်ခု)။ Database ကတော့ join လုပ်ထားတဲ့ table အများမှာ ခွဲထားတဲ့ row တွေနဲ့ စဉ်းစားပါတယ်။ နှစ်ခုကြား ပြောင်းဖို့ ORM (object နဲ့ table ကြား အလိုအလျောက် ပြောင်းပေးတဲ့ tool) တွေ၊ mapper တွေလို glue code (အစိတ်အပိုင်း နှစ်ခုကို ချိတ်ပေးတဲ့ code) လိုပြီး class ဒီဇိုင်းမှာ ဒါမှမဟုတ် schema မှာ အလျှော့အတင်း လုပ်ရလေ့ ရှိပါတယ်။
“Big data” scalability issues (အလွန် များပြားတဲ့ ဒေတာ ဖြစ်တဲ့ “big data” မှာ scale လုပ်ရ ခက်ခြင်း) Relational database တွေက vertically (ပိုကြီးတဲ့ စက် တစ်လုံးနဲ့) scale (ချဲ့) လုပ်တာ အရမ်း ကောင်းပေမယ့် horizontally (စက် အများကြီးနဲ့) scale လုပ်တာ မကောင်းပါဘူး။ Petabyte (terabyte 1,000 စာ) နဲ့ တိုင်းတာရတဲ့ web အရွယ် workload (လုပ်ရမယ့် အလုပ်) တွေမှာ join နဲ့ transaction အာမခံချက်တွေက bottleneck (အလုပ် တစ်ခုလုံးကို နှေးစေတဲ့ ကျဉ်းမြောင်းတဲ့ နေရာ) ဖြစ်လာပါတယ်။
Unstructured data handling (ပုံသေ ဖွဲ့စည်းပုံ မရှိတဲ့ ဒေတာကို ကိုင်တွယ်ခြင်း) စာသား အလွတ် document တွေ၊ ပုံတွေ၊ video တွေနဲ့ sensor ဒေတာ စီးကြောင်းတွေက row နဲ့ column တွေထဲ သေသေသပ်သပ် မဝင်ပါဘူး။ Relational database တွေက သူတို့ကို blob (ဒေတာ အစုကြီးကို တစ်တုံးတည်း သိမ်းထားတဲ့ တန်ဖိုး) အဖြစ် သိမ်းနိုင်ပေမယ့် အထဲက အကြောင်းအရာကို ထိထိရောက်ရောက် query မလုပ်နိုင်ပါဘူး။

HL ထပ်ဆောင်း ခေါင်းစဉ် Alternative Databases (အခြား database ပုံစံများ) မှာ ဒီ ကန့်သတ်ချက်တွေကို ဖြေရှင်းဖို့ ပေါ်လာခဲ့တဲ့ NoSQL (ပုံသေ table ပုံစံ မသုံးတဲ့ database)၊ cloud၊ spatial (တည်နေရာ ဒေတာအတွက်) နဲ့ in-memory (ဒေတာကို memory ထဲမှာ ထားတဲ့) model တွေကို လေ့လာပါတယ်။

Database နဲ့ spreadsheet နှိုင်းယှဉ်ချက်

လက်တွေ့ အဖွဲ့အစည်း တစ်ခုက spreadsheet အစား database ကို ဘာကြောင့် သုံးသင့်သလဲ။ ကွာခြားချက်တွေက အရေးကြီးပါတယ်:

စဉ်းစားရမယ့် အချက် Spreadsheet Relational database
Data type လျော့ရဲတယ်: cell (အကွက်) တစ်ကွက်မှာ ဘာမဆို ထည့်လို့ ရတယ် တင်းကျပ်တယ်: column တိုင်းမှာ ကြေညာထားတဲ့ type ရှိပြီး မမှန်တဲ့ input ကို ငြင်းပယ်တယ်
ထပ်နေတဲ့ ဒေတာ ဖြစ်လွယ်ပြီး အဖြစ်များတယ် (လိပ်စာ တစ်ခုတည်းကို row 500 မှာ ရိုက်ထည့်ထားတာ) Normalisation နဲ့ ဒီဇိုင်းကတည်းက ဖယ်ရှားထားတယ်
တစ်ပြိုင်နက် ပြင်ဆင်ခြင်း တစ်ကြိမ်မှာ လူ တစ်ယောက်ပဲ ပြင်ရတယ်၊ ဒါမှမဟုတ် ပြင်ထားတာတွေ တစ်ခုပေါ် တစ်ခု ထပ်ရေးမိနိုင်တယ် DBMS က ရေးနေသူ အများကို လုံလုံခြုံခြုံ ညှိပေးတယ်
Query လုပ်ခြင်း Filter နဲ့ sort လုပ်ရုံ၊ formula တွေ SQL အပြည့်အစုံ၊ table အများကြားက join တွေ အပါအဝင်
အရွယ်အစား လက်တွေ့ ကန့်သတ်ချက်က row ထောင်ပေါင်း ရာချီလောက် Row သန်းပေါင်း ရာချီကို အဆင်ပြေပြေ ကိုင်တွယ်နိုင်တယ်၊ ညှိထားတဲ့ database တွေက ဘီလီယံ ချီအထိ ရောက်တယ်
လုံခြုံရေး အကုန်ရ ဒါမှမဟုတ် ဘာမှမရ: file ကို ဖွင့်တဲ့သူ အကုန်မြင်ရတယ် User တစ်ယောက်ချင်း၊ row တစ်ကြောင်းချင်း၊ column တစ်ခုချင်းအလိုက် ခွင့်ပြုချက် ပေးနိုင်တယ်
Data integrity User ကိုယ်တိုင် ထိန်းရတယ် Primary key၊ foreign key၊ constraint နဲ့ transaction တွေက အလိုအလျောက် ထိန်းပေးတယ်

User တစ်ယောက်တည်းက ကိုယ်ပိုင် စာရင်း တစ်ခု ထားတာဆိုရင် spreadsheet နဲ့ လုံလောက်ပါတယ်။ မျှသုံးရတဲ့၊ user အများ သုံးတဲ့၊ table အများ ပါတဲ့ dataset (ဒေတာ အစုအဝေး) ကို အချိန်ကြာလာတဲ့အထိ မှန်ကန်အောင် ထားရမယ်ဆိုရင်တော့ trade-off (တစ်ခု ရဖို့ တစ်ခု အလျှော့ပေးရတာ) တွေက relational database ဘက်ကို အပြင်းအထန် ဦးစားပေးပါတယ်။

Object-Relational Impedance Mismatch (OOP object တွေနဲ့ relational table တွေကြား မကိုက်ညီမှု)

အောက်က နှိုင်းယှဉ်ချက်က object တွေနဲ့ database table တွေကြား ပြောင်းဖို့ (mapping) ဘာကြောင့် code အပို လိုလဲ ပြပါတယ်။

Object-oriented program တွေနဲ့ relational database တွေကို တစ်ခုနဲ့ တစ်ခု မဆိုင်ဘဲ သီးခြားစီ ဒီဇိုင်းဆွဲခဲ့ကြလို့ ဒေတာကို အခြေခံကျကျ မတူတဲ့ နည်းတွေနဲ့ ဖော်ပြပါတယ်:

OOP ဘက် Relational ဘက်
Object တွေမှာ identity (ကိုယ်ပိုင်ဖြစ်မှု) ရှိတယ် (object တစ်ခုက အမြဲ အဲဒီ object တစ်ခုတည်းပဲ) Row တွေကို primary key ရဲ့ တန်ဖိုး နဲ့ ခွဲခြားတယ်
Object တွေက တခြား object တွေကို reference (object ရှိရာ memory နေရာကို ညွှန်းတဲ့ တန်ဖိုး) တွေနဲ့ တိုက်ရိုက် ကိုင်ထားတယ် Table တွေက join တွေနဲ့ ရှာဖွေ ချိတ်ဆက်ရမယ့် foreign key တွေကို ကိုင်ထားတယ်
Class (object တွေ ဖန်တီးဖို့ ပုံစံခွက်) တွေက inheritance hierarchy (class တွေ အဆင့်ဆင့် အမွေဆက်ခံထားတဲ့ ဖွဲ့စည်းပုံ) တွေကို ဖွဲ့တယ် Table တွေက flat (အဆင့်ဆင့် မဖွဲ့ဘဲ ပြားပြား) ဖြစ်တယ်: “table B extends table A” (table B က table A ကို ဆက်ခံတယ်) ဆိုတဲ့ သဘောတရား ပါမလာဘူး
Object တွေမှာ collection (ဒေတာအစု) တွေကို field အဖြစ် ထည့်ထားလို့ ရတယ် Collection တွေကို foreign key တွေနဲ့ ချိတ်ထားတဲ့ သီးခြား table တွေအဖြစ် ပုံဖော်ရတယ်
Object တွေက ဒေတာနဲ့အတူ behaviour (လုပ်ဆောင်ပုံ၊ method တွေ) ကိုပါ encapsulate (ဒေတာနဲ့ method ကို တစ်စုတည်း ထုပ်ပိုး) လုပ်ထားတယ် Table တွေမှာ ဒေတာပဲ ရှိတယ်၊ behaviour က application ထဲမှာ ဒါမှမဟုတ် stored procedure (database ထဲမှာ သိမ်းထားတဲ့ SQL program) တွေထဲမှာ ရှိတယ်
Method call တွေက object graph (အချင်းချင်း ညွှန်းထားတဲ့ object အစု) တွေကို သဘာဝကျကျ လိုက်သွားတယ် အဲဒီ လိုက်သွားပုံ တစ်ခုတည်းက နှေးနိုင်တဲ့ JOIN တွေ ဆက်တိုက် ဖြစ်လာတယ်

ဒီ နှစ်ဘက်ကြား အပြန်အလှန် ပြောင်းရာမှာ ဖြစ်တဲ့ အခက်အခဲကို object-relational impedance mismatch လို့ ခေါ်ပါတယ်။ Object တွေနဲ့ table တွေကြား ဘာသာပြန်ပေးဖို့ သက်သက်အတွက် framework (အသင့်ရေးထားတဲ့ code အစု) တစ်ခုလုံး (Java မှာ Hibernate၊ C# မှာ Entity Framework၊ Python မှာ Django ORM) ရှိနေရတာ ဒါကြောင့်ပါ။ ဒါက developer တွေ တစ်ခါတစ်ရံ document-oriented NoSQL database (ဒေတာကို document ပုံစံနဲ့ သိမ်းတဲ့ NoSQL database) တွေကို အစားထိုး ရွေးကြတဲ့ အဓိက အကြောင်းရင်း တစ်ခုလည်း ဖြစ်ပါတယ်။

OOP model: booking တွေကို တိုက်ရိုက် ထည့်ထားတဲ့ class တစ်ခု:

classDiagram
    class Member {
        -int id
        -String name
        -List~Booking~ bookings
    }

ပုံထဲမှာ Member class မှာ id၊ name နဲ့ Booking object တွေရဲ့ list ဖြစ်တဲ့ bookings ဆိုတဲ့ attribute သုံးခု ပါပါတယ်။ ရှေ့က - လက္ခဏာက private (class အပြင်ကနေ တိုက်ရိုက် မသုံးနိုင်တဲ့) attribute လို့ ပြပါတယ်။

Relational model: အဲဒီ ဒေတာကိုပဲ table သုံးခုမှာ ခွဲထားပြီး foreign key တွေနဲ့ ချိတ်ထားတာ:

erDiagram
    MEMBER ||--o{ BOOKING : "makes"
    CLASS  ||--o{ BOOKING : "is booked in"
    MEMBER {
        int MemberID PK
        string FirstName
        string Surname
    }
    BOOKING {
        string BookingID PK
        int MemberID FK
        string ClassID FK
        date BookedOn
    }
    CLASS {
        string ClassID PK
        string Title
        datetime StartsAt
    }

ပုံထဲက “makes” က MEMBER တစ်ယောက်က BOOKING တွေကို “လုပ်တယ်”၊ “is booked in” က CLASS တစ်ခုကို BOOKING တွေထဲမှာ “booking လုပ်ထားတယ်” လို့ ဆိုလိုပါတယ်။ မျဉ်းအစွန်းက သင်္ကေတတွေက MEMBER (ဒါမှမဟုတ် CLASS) တစ်ခုမှာ BOOKING အများ (တစ်ခုမှ မရှိတာ ဒါမှမဟုတ် အများ) ရှိနိုင်တယ်လို့ ပြပါတယ်။ PK က primary key၊ FK က foreign key ပါ။

Booking object တွေရဲ့ list ကို အထဲမှာ ထည့်ထားတဲ့ Member object တစ်ခုတည်းက join လုပ်ထားတဲ့ သီးခြား table သုံးခု ဖြစ်သွားပါတယ်။ Save လုပ်တိုင်း၊ load လုပ်တိုင်း ပုံစံ နှစ်မျိုးကြား ပြောင်းပေးရပါတယ်။

အဆင့်ဆင့် ရှင်းပြထားတဲ့ ဥပမာများ

ဥပမာ 1: Schema ရဲ့ အစိတ်အပိုင်းတွေကို ခွဲခြားသိခြင်း

Harbour Run ဆိုတဲ့ ရပ်ကွက် အားကစား အသင်း သေးသေးလေး တစ်ခုက အောက်ပါ member table ကို ထားပါတယ်။

MEMBER table

MemberID FirstName Surname DateOfBirth MembershipTier
1001 Aroha Kahurangi 2008-03-14 Standard
1002 Marlon Tan 1995-07-22 Premium
1003 Sebastián Quispe 1980-11-02 Standard
1004 Priya Nair 2003-05-30 Premium

ခွဲခြမ်းစိတ်ဖြာချက်:

  • Entity: Member၊ table က member တစ်ယောက်ကို record တစ်ခုစီ သိမ်းပါတယ်။
  • Records: လေးခု ရှိပါတယ် (1001 ကနေ 1004 အထိ)။
  • Fields: ငါးခု ရှိပါတယ် (MemberID, FirstName, Surname, DateOfBirth, MembershipTier)။
  • Primary key: MemberID၊ member တစ်ယောက်ချင်းစီကို သတ်မှတ်ပေးထားတဲ့ null မဖြစ်တဲ့၊ မထပ်တဲ့ integer (ကိန်းပြည့်) ပါ။
  • Schema (primary key ကို မျဉ်းသားထားပါတယ်): MEMBER(MemberID, FirstName, Surname, DateOfBirth, MembershipTier)။

ဥပမာ 2: Foreign key ကို ရှာဖွေခြင်း

Harbour Run က fitness class (ကိုယ်ကာယ လေ့ကျင့်ခန်း အတန်း) တွေလည်း ဖွင့်ပြီး ဘယ် member က ဘယ် class ကို booking (ကြိုတင် စာရင်းသွင်းခြင်း) လုပ်ထားလဲ မှတ်ထားပါတယ်။

CLASS table

ClassID Title Coach StartsAt
C401 Sunrise 5k Lila Okafor 2026-06-01 06:30
C402 Track Sprints Lila Okafor 2026-06-02 17:30
C403 Hill Repeats Daniel Park 2026-06-03 18:00

BOOKING table

BookingID MemberID ClassID BookedOn
B9001 1001 C401 2026-05-28
B9002 1002 C401 2026-05-28
B9003 1002 C402 2026-05-29
B9004 1004 C403 2026-05-30

ခွဲခြမ်းစိတ်ဖြာချက်:

  • BOOKING table ရဲ့ MemberID column က foreign key ပါ: အထဲက တန်ဖိုး တိုင်းက MEMBER ထဲမှာ MemberID တစ်ခုအဖြစ် ရှိနေရပါမယ်။ အလားတူပဲ BOOKING ထဲက ClassID က CLASS ကို ညွှန်းတဲ့ foreign key ပါ။
  • Booking row တိုင်းထဲကို member ရဲ့ နာမည် အပြည့်အစုံ ဒါမှမဟုတ် class ရဲ့ ခေါင်းစဉ်ကို ကူးမထည့်ဘဲ “ဒီ booking က ဒီ member ရဲ့ booking ဖြစ်ပြီး ဒီ class အတွက်ပါ” ဆိုတာကို database က ဒီလို ဖော်ပြပါတယ်။
  • MEMBER နဲ့ BOOKING ကြား relationship က one-to-many ပါ (member တစ်ယောက်မှာ booking အများ ရှိနိုင်ပြီး booking တစ်ခုကို member တစ်ယောက်ပဲ ပိုင်ပါတယ်)။ CLASS နဲ့ BOOKING ကြားလည်း အတူတူပါပဲ။
  • One-to-many ချိတ်ဆက်မှု နှစ်ခု ပေါင်းလိုက်တော့ MEMBER နဲ့ CLASS ကြား many-to-many relationship ကို ဖြေရှင်းပေးပါတယ် (member တစ်ယောက်က class အများကို booking လုပ်ပြီး class တစ်ခုစီမှာ member အများ ရှိပါတယ်)။ ဒါကို ဖြစ်နိုင်အောင် လုပ်ပေးတဲ့ BOOKING table က junction table (many-to-many ဆက်နွယ်မှုကို ဖြေရှင်းပေးတဲ့ ကြားခံ table) ပါ။

ဥပမာ 3: လက်တွေ့ အခြေအနေ တစ်ခုအတွက် database နဲ့ spreadsheet နှိုင်းယှဉ်ခြင်း

ကျောင်း စာကြည့်တိုက်မှူး တစ်ယောက်က လက်ရှိမှာ စာအုပ် ငှားတာတွေကို မျှသုံးတဲ့ spreadsheet တစ်ခုတည်းမှာ မှတ်ထားပါတယ်။ Row တစ်ကြောင်းစီမှာ စာအုပ် နာမည်၊ ငှားသူ နာမည်နဲ့ form class (ကျောင်းသားရဲ့ အတန်းခွဲ)၊ ငှားတဲ့ ရက်စွဲနဲ့ ပြန်အပ်ရမယ့် ရက်စွဲ ပါပါတယ်။ စာကြည့်တိုက်မှူး နှစ်ယောက်က ကိုယ့် laptop ကိုယ်စီကနေ file ကို ပြင်ကြပါတယ်။

Relational database တစ်ခုက ဖြေရှင်းပေးနိုင်မယ့် ပြဿနာ သုံးခု:

  1. ပြင်တာတွေ အချင်းချင်း ထိခိုက်ခြင်း။ စာကြည့်တိုက်မှူး နှစ်ယောက်လုံး file ကို ဖွင့်ထားပြီး တစ်ယောက်စီက ငှားမှု တစ်ခုစီ ထည့်ရင် နောက်တစ်ကြိမ် save လုပ်တဲ့အခါ အဲဒီ ငှားမှုတွေထဲက တစ်ခု ပျောက်သွားနိုင်ပါတယ်၊ ဘာလို့လဲဆိုတော့ ဒုတိယ save က ပထမ save ပေါ်ကို ထပ်ရေးလိုက်လို့ပါ။ Relational database က ရေးမှု နှစ်ခုကို တစ်ခုပြီးမှ တစ်ခု ဆောင်ရွက်လို့ ငှားမှု နှစ်ခုလုံး ကျန်ပါတယ်။ (အကျိုးကျေးဇူး: concurrency control။)
  2. ကျောင်းသား ဒေတာ မလိုအပ်ဘဲ ထပ်နေခြင်း။ ငှားမှု row တိုင်းမှာ ငှားသူ နာမည်နဲ့ form class ကို ထပ်ခါထပ်ခါ ရေးထားပါတယ်။ နှစ်သစ် အစမှာ ကျောင်းသား တစ်ယောက် form class ပြောင်းရင် row ဒါဇင်ချီမှာ ပြင်ရပြီး တစ်ကြောင်း ကျန်ခဲ့ဖို့ လွယ်ပါတယ်။ Relational ဒီဇိုင်းမှာ STUDENT ကို သူ့ကိုယ်ပိုင် table အဖြစ် ခွဲထုတ်လို့ form class က row တစ်ကြောင်းတည်းမှာပဲ ရှိပါတယ်။ (အကျိုးကျေးဇူး: reduced data duplication၊ reduced redundancy။)
  3. မမှန်တဲ့ input ကို မကာကွယ်နိုင်ခြင်း။ စာကြည့်တိုက်မှူး တစ်ယောက်က Date Borrowed (ငှားတဲ့ ရက်စွဲ) cell ထဲကို "last Tuesday" (ပြီးခဲ့တဲ့ အင်္ဂါနေ့) လို့ မတော်တဆ ရိုက်ထည့်မိရင် spreadsheet က လက်ခံပါတယ်။ MySQL ဒါမှမဟုတ် PostgreSQL လို database စနစ် တစ်ခုထဲက DATE column ကတော့ မှန်ကန်တဲ့ ပြက္ခဒိန် ရက်စွဲ မဟုတ်တာ မှန်သမျှကို ငြင်းပယ်ပါတယ်။ (အကျိုးကျေးဇူး: data integrity။)

User တစ်ယောက်တည်း ရှိတယ်၊ dataset သေးတယ်၊ ဒေတာကို ခဏပဲ ထားဖို့ လိုတယ် ဆိုရင်တော့ spreadsheet က သင့်တော်နေဆဲပါ။ ဒီ ယူဆချက်တွေထဲက တစ်ခုထက် ပိုပြီး မမှန်တော့တာနဲ့ trade-off တွေက ပြောင်းပြန် ဖြစ်သွားပါတယ်။

Quick Check (အမြန် စစ်ဆေးမေးခွန်း)

Q1. Relational database မှာ table ထဲက row တစ်ကြောင်းကို ဘယ် term နဲ့ ခေါ်သလဲ။

Q2. တခြား table ရဲ့ primary key ကို ညွှန်းပြီး table နှစ်ခုကြား ချိတ်ဆက်မှုကို ဖန်တီးပေးတဲ့ key က ဘယ် အမျိုးအစားလဲ။

Q3. Receptionist (ဧည့်ကြို ဝန်ထမ်း) နှစ်ယောက်က fitness class တစ်ခုတည်းအတွက် booking တွေကို တစ်ချိန်တည်းမှာ မတူတဲ့ laptop တွေကနေ လက်ခံနေပါတယ်။ သူတို့ရဲ့ တစ်ပြိုင်နက် update တွေ တစ်ခုပေါ် တစ်ခု ထပ်မရေးမိအောင် relational database ရဲ့ ဘယ် ထူးခြားချက်က သေချာစေသလဲ။

Q4. Object-relational impedance mismatch ကို အကောင်းဆုံး ဖော်ပြထားတာ ဘယ်ဟာလဲ။

Q5. အပေါ်က ဥပမာ 2 မှာ MEMBER နဲ့ CLASS ကြား ဘယ်လို relationship ရှိသလဲ (BOOKING junction table ကနေတစ်ဆင့် ဖြေရှင်းထားတာပါ)။

Q6. အောက်ပါတို့ထဲက ဘယ်ဟာက relational model ရဲ့ အကျိုးကျေးဇူး မဟုတ်ဘဲ ကန့်သတ်ချက် ဖြစ်သလဲ။

Schema ကို ဖတ်ကြည့်ခြင်း

ဥပမာ 2 ထဲက Harbour Run schema (MEMBER, CLASS, BOOKING) ကို သုံးပြီး ကွက်လပ် တန်ဖိုးတွေကို ဖြည့်ပါ။ Column နာမည်တွေကို table ထဲမှာ ရေးထားတဲ့အတိုင်း English လို ရိုက်ထည့်ပါ။

Schema ဖတ်တဲ့ လေ့ကျင့်ခန်း။ ဖော်ပြထားတဲ့ table ဒါမှမဟုတ် column တစ်ခုစီအတွက် မှန်ကန်တဲ့ အဖြေကို ဖြည့်ပါ။

မေးခွန်းအဖြေ
MEMBER table ရဲ့ primary key က
BOOKING ထဲမှာ MEMBER ကို ချိတ်ထားတဲ့ foreign key က
BOOKING ထဲမှာ CLASS ကို ချိတ်ထားတဲ့ foreign key က
CLASS table ထဲက record အရေအတွက်
BOOKING table ထဲက field အရေအတွက်
MEMBER နဲ့ BOOKING ကြား relationship အမျိုးအစား (1:1၊ 1:M ဒါမှမဟုတ် M:M ပုံစံနဲ့ ရိုက်ပါ)

Fill in the Blanks (ကွက်လပ် ဖြည့်ခြင်း)

Relational model အကြောင်း အောက်ပါ စာကြောင်းတွေကို ပြည့်စုံအောင် ဖြည့်ပါ။ စာကြောင်းတွေက English လို ဖြစ်လို့ ကွက်လပ်တွေကို English term နဲ့ ရိုက်ထည့်ပါ။

CORE TERMINOLOGY
================
A  is a two-dimensional grid of rows and columns
that stores data about one type of entity.

The column (or small set of columns) that uniquely identifies each
row in a table is called the .

A column whose values must match a primary key in another table
is called a .

A relationship in which one member can book many classes AND
each class can have many members is called a 
relationship.

The DBMS feature that lets multiple users update the same data
at the same time without losing changes is called
.

စာကြောင်းတွေရဲ့ အဓိပ္ပာယ် (____ က ကွက်လပ်ပါ):
CORE TERMINOLOGY (အဓိက ဝေါဟာရများ)
____ ဆိုတာ entity အမျိုးအစား တစ်ခုအကြောင်း ဒေတာကို သိမ်းတဲ့၊ row နဲ့ column တွေပါတဲ့ နှစ်ဘက်မြင် ဇယားကွက်ပါ။
Table တစ်ခုထဲက row တစ်ကြောင်းချင်းကို မထပ်အောင် ခွဲခြားပေးတဲ့ column (ဒါမှမဟုတ် column အနည်းငယ် အစု) ကို ____ လို့ ခေါ်ပါတယ်။
တန်ဖိုးတွေက တခြား table တစ်ခုထဲက primary key နဲ့ ကိုက်ညီရမယ့် column ကို ____ လို့ ခေါ်ပါတယ်။
Member တစ်ယောက်က class အများကို booking လုပ်နိုင်ပြီး class တစ်ခုစီမှာလည်း member အများ ရှိနိုင်တဲ့ relationship ကို ____ relationship လို့ ခေါ်ပါတယ်။
User အများ ဒေတာ တစ်ခုတည်းကို တစ်ချိန်တည်း update လုပ်တဲ့အခါ ပြင်ထားတာတွေ မပျောက်အောင် လုပ်ပေးတဲ့ DBMS ရဲ့ ထူးခြားချက်ကို ____ လို့ ခေါ်ပါတယ်။

Spot the Error (အမှား ရှာခြင်း)

ကျောင်းသား တစ်ယောက်က relational database ထဲက key တွေအကြောင်း ပြန်နွှေးဖို့ မှတ်စု ရေးထားပါတယ်။ Line တစ်ကြောင်း မှားနေပါတယ်။ အမှားပါတဲ့ line ကို ရွေးပါ၊ ပြီးရင် မှန်ကန်တဲ့ ပြင်နည်းကို ရွေးပါ။

1A primary key uniquely identifies each row in its own table 2A primary key value cannot be null and cannot be duplicated 3A foreign key is a column that uniquely identifies rows within the same table 4A composite key uses two or more columns together as the primary key 5A many-to-many relationship is normally resolved using a junction table

Line တွေရဲ့ အဓိပ္ပာယ်: (1) primary key က ကိုယ့် table ထဲက row တစ်ကြောင်းချင်းကို မထပ်အောင် ခွဲခြားပေးတယ်၊ (2) primary key တန်ဖိုးက null ဖြစ်လို့ မရသလို ထပ်လို့လည်း မရဘူး၊ (3) foreign key က table တစ်ခုတည်းအတွင်းက row တွေကို မထပ်အောင် ခွဲခြားပေးတဲ့ column ပါ၊ (4) composite key က column နှစ်ခု ဒါမှမဟုတ် ပိုများတာကို ပေါင်းပြီး primary key အဖြစ် သုံးတယ်၊ (5) many-to-many relationship ကို ပုံမှန်အားဖြင့် junction table နဲ့ ဖြေရှင်းတယ်။

Line 3 အတွက် မှန်ကန်တဲ့ ပြင်နည်းကို ရွေးပါ:

Term ကို ခွဲခြားသိခြင်း

ဖော်ပြချက်ကို ဖတ်ပြီး မှန်ကန်တဲ့ term ကို English လို ရိုက်ထည့်ပါ။

Many-to-many relationship ကို one-to-many relationship နှစ်ခုအဖြစ် ခွဲပေးဖို့ အဓိက table နှစ်ခုထဲက တစ်ခုစီကို ညွှန်းတဲ့ foreign key နှစ်ခုကို ကိုင်ထားတဲ့ ကြားခံ table အသေးလေး တစ်ခုပါ။ ဥပမာ 2 ထဲက BOOKING table က ဥပမာ တစ်ခုပါ။

ဖော်ပြချက်ကို ဖတ်ပြီး မှန်ကန်တဲ့ term ကို English လို ရိုက်ထည့်ပါ။

ကြေညာထားတဲ့ data type တွေနဲ့ constraint တွေက မမှန်တဲ့ input ကို ငြင်းပယ်တာကနေ ရတဲ့ relational database ရဲ့ အကျိုးကျေးဇူးပါ၊ ဥပမာ DATE column က "next Tuesday" ဆိုတဲ့ တန်ဖိုးကို သိမ်းဖို့ ငြင်းတာ၊ ဒါမှမဟုတ် NOT NULL constraint က မဖြစ်မနေ ဖြည့်ရမယ့် field မပါတာကို လက်မခံတာ။

Practice Exercises (လေ့ကျင့်ခန်းများ)

လေ့ကျင့်ခန်း တစ်ခုစီရဲ့ ရှေ့မှာ အဆင့် ([Core] စသဖြင့်)၊ ခေါင်းစဉ် link နဲ့ [4 marks] လို mark allocation (မေးခွန်း တစ်ခုစီအတွက် ပေးတဲ့ အမှတ်) ပါပါတယ်။ အပိုင်းခွဲ တစ်ခုစီရဲ့ နောက်က [2] လို ဂဏန်းက အဲဒီ အပိုင်းရဲ့ အမှတ်ပါ။ အမှတ်တွေက IB Computer Science (နိုင်ငံတကာ ကျောင်းတွေမှာ သင်တဲ့ ကွန်ပျူတာသိပ္ပံ သင်ရိုး) စာမေးပွဲ ပုံစံအတိုင်းပါ: IB သင်တန်း မတက်တဲ့သူတွေကတော့ အဖြေကို ဘယ်လောက် အသေးစိတ် ရေးရမလဲ ပြတဲ့ လမ်းညွှန်အဖြစ် သုံးနိုင်ပါတယ်။

Core (အခြေခံ အဆင့်)

  1. [Core] Vocabulary [4 marks] Relational database ရဲ့ အခြေအနေမှာ အောက်ပါ term တစ်ခုချင်းစီကို Define လုပ်ပါ:
    • (a) record
    • (b) field
    • (c) primary key
    • (d) foreign key
  2. [Core] Benefits and limits [6 marks] ရပ်ကွက် ပရဟိတ မီးဖိုချောင် အများ ပါတဲ့ အဖွဲ့ တစ်ခုက သူ့ရဲ့ စေတနာ့ဝန်ထမ်းတွေ၊ မီးဖိုချောင်တွေနဲ့ စေတနာ့ဝန်ထမ်းတွေ စာရင်းပေးတဲ့ အလှည့်တွေကို relational database တစ်ခုမှာ သိမ်းထားပါတယ်။ ပြီးခဲ့တဲ့ လက အဖြစ်အပျက် သုံးခု ဖြစ်ခဲ့ပါတယ်။ တစ်ခုစီအတွက် relational database ရဲ့ ဘယ် ထူးခြားချက် ဒါမှမဟုတ် အကျိုးကျေးဇူးက အဲဒီ ရလဒ်ကို ဖြစ်စေခဲ့လဲ Explain (ရှင်းပြပါ) လုပ်ပါ။
    • (a) ညှိနှိုင်းရေးမှူး တစ်ယောက်က စေတနာ့ဝန်ထမ်း တစ်ယောက်ကို သောကြာနေ့ အလှည့်ကနေ စနေနေ့ အလှည့်ကို ရွှေ့နေပါတယ်။ သောကြာနေ့ အလှည့်ကို ဖယ်ပြီးနောက်၊ စနေနေ့ အလှည့်ကို မထည့်ရသေးခင်မှာ connection (ချိတ်ဆက်မှု) ပြတ်သွားပါတယ်။ နောက်ပိုင်းမှာ ဘာအပြောင်းအလဲမှ မစခဲ့သလိုပဲ အဲဒီ စေတနာ့ဝန်ထမ်းက သောကြာနေ့ အလှည့်မှာ ရှိနေဆဲပါ။ [2]
    • (b) မီးဖိုချောင် တာဝန်ခံတွေက ကိုယ့် မီးဖိုချောင်ရဲ့ အလှည့်တွေမှာ ပါတဲ့ စေတနာ့ဝန်ထမ်းတွေရဲ့ နာမည်နဲ့ ဖုန်းနံပါတ်တွေကို မြင်ရပေမယ့် သူတို့ရဲ့ နေအိမ်လိပ်စာကို မမြင်ရပါဘူး၊ နေအိမ်လိပ်စာကို ဗဟို ရုံးကပဲ မြင်ရပါတယ်။ [2]
    • (c) ဆောင်းရာသီ အလှူခံ စည်းရုံးမှု မတိုင်ခင် ရုံးက မတူတဲ့ မီးဖိုချောင် သုံးခု ဒါမှမဟုတ် ပိုများတဲ့ နေရာမှာ အလှည့် လုပ်ခဲ့ဖူးတဲ့ စေတနာ့ဝန်ထမ်း အားလုံးကို စာရင်း ထုတ်ခဲ့ပါတယ်။ စာရင်း ထုတ်တာ တစ်စက္ကန့်ထက်တောင် မကြာပါဘူး။ [2]
  3. [Core] Benefits and limits [4 marks] ပျားမွေးသူ တစ်ယောက်က သူ့ရဲ့ ပျားအုံ 12 အုံကို စစ်ဆေးတဲ့ မှတ်တမ်းတွေကို spreadsheet တစ်ခုမှာ ထားပါတယ်။ Row တစ်ကြောင်းစီမှာ စစ်ဆေးမှု တစ်ခု ပါပါတယ်: ပျားအုံ နံပါတ်၊ စစ်ဆေးတဲ့ ရက်စွဲ၊ မိဖုရား ပျားကို တွေ့ခဲ့လား ဆိုတာနဲ့ မှတ်ချက် တိုတို တစ်ခု။ File ကို သူ တစ်ယောက်တည်းပဲ သုံးပါတယ်။ သူငယ်ချင်း တစ်ယောက်က မှတ်တမ်းတွေကို relational database ကို ပြောင်းဖို့ အကြံပေးပါတယ်။
    • (a) လက်ရှိမှာ spreadsheet က သူ့အတွက် ဘာကြောင့် လုံလောက်လဲဆိုတဲ့ အကြောင်းရင်း တစ်ခုကို Outline (အကျဉ်းချုပ် ဖော်ပြပါ) လုပ်ပါ။ [2]
    • (b) မှတ်တမ်းတွေကို သုံးပုံမှာ ဘယ်လို အပြောင်းအလဲ တစ်ခု ဖြစ်လာရင် relational database က ပိုကောင်းတဲ့ ရွေးချယ်မှု ဖြစ်လာမလဲ Outline လုပ်ပါ။ [2]

Extension (တိုးချဲ့ အဆင့်)

  1. [Extension] Schemas [5 marks] ဥပမာ 2 ထဲက Harbour Run schema ကို ကြည့်ပါ။ အောက်ပါတို့ကို Identify (ဖြစ်နိုင်တဲ့ အဖြေတွေထဲက ရွေးပြီး ဖော်ပြပါ) လုပ်ပါ:
    • (a) table တစ်ခုစီရဲ့ primary key
    • (b) schema ထဲက foreign key အားလုံးနဲ့ တစ်ခုစီ ညွှန်းထားတဲ့ table
    • (c) တိုက်ရိုက် relationship တစ်ခုစီရဲ့ အမျိုးအစား (1:1, 1:M, M:M)
    • (d) junction table အဖြစ် ကိုယ်စားပြုထားတဲ့ entity
  2. [Extension] Benefits and limits [4 marks] User ဘီလီယံ ချီ ရှိပြီး free-text (စာသား အလွတ်) post တွေ၊ ပုံတွေ၊ video တွေ ပါတဲ့ feed ရှိတဲ့ ကမ္ဘာလုံးဆိုင်ရာ social media platform တစ်ခုရဲ့ developer တွေကို non-relational ဖြေရှင်းနည်း ဘက်ကို တွန်းပို့မယ့် relational model ရဲ့ ကန့်သတ်ချက် နှစ်ခု ကို Describe (ဖော်ပြရှင်းပြပါ) လုပ်ပါ။ ကန့်သတ်ချက် တစ်ခုစီက အဲဒီ workload အတွက် ဘာကြောင့် အရေးကြီးလဲ Explain လုပ်ပါ။

Challenge (စိန်ခေါ်မှု အဆင့်)

  1. [Challenge] Benefits and limits [6 marks] ကျောင်းသား တစ်ယောက်က Java နဲ့ ကျောင်း စာကြည့်တိုက် application တစ်ခု တည်ဆောက်နေပါတယ်။ သူ့မှာ List<Loan> field ပါတဲ့ Book class၊ List<Loan> field ပါတဲ့ Member class နဲ့ Book နဲ့ Member field တွေ ပါတဲ့ Loan class ရှိပါတယ်။ ဒီဒေတာကို relational database တစ်ခုမှာ persist (program ပိတ်သွားပြီးနောက်မှာလည်း ဒေတာ ဆက်ရှိနေအောင် သိမ်းထား) လုပ်ချင်ပါတယ်။ Object-relational impedance mismatch က ဒီ mapping ကို ဘာကြောင့် ခက်ခဲစေလဲ Explain လုပ်ပါ။ OOP နဲ့ relational ဘက်ကြား ကွာခြားချက် အနည်းဆုံး သုံးခုကို ကိုးကားပါ (identity နဲ့ primary key၊ reference နဲ့ join၊ collection၊ inheritance ဒါမှမဟုတ် ဒေတာနဲ့အတူ behaviour ပါခြင်း)။

  2. [Challenge] Alternative DBs (HL) [8 marks] Start-up ကုမ္ပဏီ တစ်ခုက သူ့ရဲ့ အဓိက product အတွက် relational database နဲ့ NoSQL document store (ဒေတာကို document ပုံစံနဲ့ သိမ်းတဲ့ database) ကြား ရွေးချယ်နေပါတယ်။ သူတို့ စဉ်းစားသင့်တဲ့ trade-off တွေကို Discuss (အမြင် အမျိုးမျိုးကို ချိန်ဆပြီး ဆွေးနွေးပါ) လုပ်ပါ။ Relational model ရဲ့ အကျိုးကျေးဇူး အနည်းဆုံး သုံးခုနဲ့ ကန့်သတ်ချက် အနည်းဆုံး သုံးခုကို ကိုးကားပါ။ တည်ဆောက်နေတဲ့ product အမျိုးအစားပေါ် မူတည်တဲ့၊ အကြောင်းပြချက် ခိုင်လုံတဲ့ အကြံပြုချက် တစ်ခု ထည့်ပါ။

Exam-Style (စာမေးပွဲ ပုံစံ မေးခွန်း)

  1. [Exam-Style] Keys [5 marks] မြို့ တစ်မြို့ရဲ့ ပစ္စည်းပျောက် ရုံးက တွေ့ထားတဲ့ ပစ္စည်း တစ်ခုစီကို နံပါတ်တပ်ထားတဲ့ crate (သေတ္တာ) တစ်ခုထဲမှာ ထားပါတယ်။ သူ့ database မှာ table နှစ်ခု ရှိပြီး primary key တွေကို မျဉ်းသားထားပါတယ်:

    CRATE(CrateCode, Room) နဲ့ FOUND_ITEM(ItemRef, Description, CrateCode)

    CRATE table ထဲမှာ crate သုံးခု ရှိပါတယ်: C1, C2 နဲ့ C3။ စေတနာ့ဝန်ထမ်း တစ်ယောက်က FOUND_ITEM ထဲ ထည့်ဖို့ ဒီ row တွေကို ပြင်ဆင်ထားပါတယ်:

    ItemRef Description CrateCode
    7001 Black umbrella C1
    7002 Child’s scooter C3
    7003 Blue backpack C4
    7002 Reading glasses C2
    7005 Set of house keys C1
    • (a) FOUND_ITEM ထဲက foreign key နဲ့ အဲဒါ ညွှန်းထားတဲ့ table ကို Identify လုပ်ပါ။ [1]
    • (b) DBMS က ဒီ row တွေထဲက နှစ်ကြောင်းကို ငြင်းပယ်ပါတယ်။ တစ်ကြောင်းစီကို Identify လုပ်ပြီး ဘာကြောင့် ငြင်းပယ်ခံရလဲ Explain လုပ်ပါ။ [4]

IB CS သင်တန်း တက်နေသူတွေအတွက် မှတ်ချက်: A3.1.1 အတွက် key term တွေကို အဓိပ္ပာယ် ဖွင့်ဆိုနိုင်လောက်အောင် ကောင်းကောင်း လေ့လာထားပါ၊ ပြီးတော့ အကျိုးကျေးဇူးနဲ့ ကန့်သတ်ချက် တစ်ခုစီကို database က ဘာလုပ်လဲ ဆိုတာနဲ့ မေးခွန်းထဲက အဖွဲ့အစည်းနဲ့ ချိတ်ဆက်ပြီး ရေးတာကို လေ့ကျင့်ပါ။

ဆက်စပ် ခေါင်းစဉ်များ

  • နောက်ထပ် လေ့လာမယ့် ခေါင်းစဉ်: Database Schemas (Database ဖွဲ့စည်းပုံ ဖော်ပြချက်များ): “ဘာကို model လုပ်မလဲ” ကို “ဘယ်လို သိမ်းမလဲ” နဲ့ ခွဲထားပေးတဲ့ အလွှာ သုံးခု (conceptual၊ logical၊ physical)။
  • ဆက်စပ် ခေါင်းစဉ်: Data Types and Keys (Data type နဲ့ key များ): ဒီမှာ မိတ်ဆက်ခဲ့တဲ့ primary key၊ foreign key နဲ့ composite key တွေကို အသေးစိတ် လေ့လာပါတယ်၊ concatenated key (column အများကို ဆက်ပေါင်းထားတဲ့ key) တွေကိုလည်း လေ့လာပါတယ်။
  • ဆက်စပ် ခေါင်းစဉ်: Entity-Relationship Diagrams (Entity တွေနဲ့ ဆက်နွယ်မှုတွေကို ပြတဲ့ ပုံများ): table၊ relationship၊ cardinality (ဆက်နွယ်မှု တစ်ဖက်စီရဲ့ အများဆုံး အရေအတွက်) နဲ့ modality (ဆက်နွယ်မှုမှာ မဖြစ်မနေ ပါရမလား ဆိုတာ) ကို ပုံနဲ့ ဖော်ပြတဲ့ နည်း။
  • ဆက်စပ် ခေါင်းစဉ်: Normalisation (ဒေတာ ထပ်မနေအောင် table တွေကို စီစဉ်ခြင်း): ရှုပ်ပွနေတဲ့ အစကနေ redundancy နည်းတဲ့ သန့်ရှင်းတဲ့ table အစု ရအောင် လုပ်တဲ့ လုပ်ငန်းစဉ်။
  • ရှေ့ဆက် လေ့လာရန် (HL): Alternative Databases (အခြား database ပုံစံများ): ဒီမှာ လေ့လာခဲ့တဲ့ relational ကန့်သတ်ချက်တွေကို ဖြေရှင်းပေးတဲ့ NoSQL၊ cloud၊ spatial နဲ့ in-memory model များ။
  • Programming: OOP Fundamentals (OOP ရဲ့ အခြေခံများ): object-relational impedance mismatch ရဲ့ ဘက်နှစ်ဖက်ထဲက object ဘက်။

© EduCS.me. ကွန်ပျူတာသိပ္ပံ ပညာရေးအတွက် အရင်းအမြစ်တွေ စုထားတဲ့ နေရာပါ။ EduCS is an independent educational resource. It is not affiliated with, or endorsed by, the International Baccalaureate Organization. (EduCS ဟာ သီးခြား ပညာရေး အရင်းအမြစ်တစ်ခုပါ။ International Baccalaureate Organization နဲ့ ဆက်စပ်မှု မရှိသလို သူတို့ရဲ့ ထောက်ခံချက်လည်း မရှိပါဘူး။) ဆက်သွယ်ရန်

Just the Docs နဲ့ တည်ဆောက်ထားပါတယ်။