Transactions and Views (transaction နဲ့ view များ)

A3.3.5: Describe different database views (virtual, materialised). A3.3.6: Describe how transactions maintain data integrity (ACID, TCL commands).
မြန်မာလို: A3.3.5: database view (database ထဲမှာ နာမည်ပေး သိမ်းထားတဲ့ query) အမျိုးအစားတွေ (virtual နဲ့ materialised) ကို describe (ဖော်ပြရှင်းပြ) လုပ်နိုင်ရပါမယ်။ A3.3.6: transaction (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ်တဲ့ database လုပ်ဆောင်ချက် အစု) တွေက data integrity (ဒေတာ မှန်ကန်ပြီး မပျက်စီးဘဲ ရှိနေခြင်း) ကို ဘယ်လို ထိန်းသိမ်းပေးလဲဆိုတာ ACID (transaction တစ်ခုရဲ့ အာမခံချက် လေးခု) နဲ့ TCL command (transaction ကို ထိန်းချုပ်တဲ့ SQL command) တွေကို သုံးပြီး describe လုပ်နိုင်ရပါမယ်။

ဒီစာမျက်နှာ တစ်ခုလုံးက HL အဆင့်မှာပဲ အကဲဖြတ် စစ်ဆေးတဲ့ အကြောင်းအရာ ဖြစ်ပါတယ်။ SL (Standard Level) နဲ့ HL (Higher Level) ဆိုတာ IB Computer Science (နိုင်ငံတကာ ကျောင်းတွေမှာ သင်တဲ့ ကွန်ပျူတာသိပ္ပံ သင်ရိုး) သင်တန်းရဲ့ အဆင့်နှစ်ဆင့်ဖြစ်ပြီး HL အပိုင်းတွေက ပိုနက်နက်ရှိုင်းရှိုင်း လေ့လာရတဲ့ အပိုင်းတွေပါ။

အပိုင်း 1: Database View များ (A3.3.5)

View ဆိုတာ ဘာလဲ

View ဆိုတာ database (ဒေတာ သိမ်းဆည်းတဲ့ စနစ်) ထဲမှာ နာမည်ပေးပြီး သိမ်းထားတဲ့ query (ဒေတာ ရှာဖွေ တောင်းဆိုမှု) တစ်ခုပါ။ User တွေက table (database ထဲက ဇယား) တစ်ခုကနေ ဒေတာ ရွေးထုတ်သလိုပဲ view ကနေလည်း ရွေးထုတ်လို့ရပါတယ်။ Query ကို တစ်ကြိမ်ပဲ သိမ်းထားပါတယ်။ User တစ်ယောက်က view ပေါ်မှာ SELECT ကို run တဲ့အခါ DBMS (database management system၊ database ကို စီမံခန့်ခွဲတဲ့ software) က view ရဲ့ query ကို view နောက်ကွယ်က table တွေပေါ်မှာ run ပါတယ်။ Materialised view (ရလဒ်ကို သိမ်းထားတဲ့ view) ဆိုရင်တော့ ကြိုသိမ်းထားပြီးသား ရလဒ်ကို ပြန်ပေးပါတယ်။

ပုံမှန် အသုံးပြုပုံ ဥပမာ:

CREATE VIEW PremiumMemberSummary AS
SELECT Member.MemberID, FirstName, Surname, COUNT(*) AS BookingCount
FROM Member
INNER JOIN Booking ON Member.MemberID = Booking.MemberID
WHERE Member.Tier = 'Premium'
GROUP BY Member.MemberID, FirstName, Surname;

View ရှိပြီဆိုရင် user တွေက နောက်ကွယ်က join (table တွေကို ချိတ်ပြီး ဒေတာ ပေါင်းယူခြင်း) အကြောင်း သိစရာ မလိုဘဲ SELECT * FROM PremiumMemberSummary WHERE BookingCount > 10; လို့ ရေးလို့ရပါတယ်။

ဒီခေါင်းစဉ်မှာ view ဆိုတာ database ထဲမှာ သိမ်းထားတဲ့ အရာ တစ်ခုပါ: user တွေ ဒေတာ ရွေးထုတ်လို့ရတဲ့ နာမည်ပေးထားတဲ့ query ပါ။ တစ်ကြိမ်တည်း run ပြီး ပြပြီးရင် ပစ်လိုက်တဲ့ query ရလဒ်က view မဟုတ်ပါဘူး။

Virtual Views (query ကိုပဲ သိမ်းထားတဲ့ view)

Virtual view က query ကိုပဲ သိမ်းထားပြီး ဒေတာကို မသိမ်းပါဘူး။ User က view ကနေ ဒေတာ ရွေးထုတ်တဲ့အခါ DBMS က query ကို table တွေပေါ်မှာ run ပြီး ရလဒ်ကို ပြန်ပေးပါတယ်။

Virtual view တွေရဲ့ ဂုဏ်သတ္တိများ:

  • ဖတ်တိုင်း နောက်ဆုံး ဒေတာကို ပြတယ်: query ကို table တွေပေါ်မှာ အကြိမ်တိုင်း run တာကြောင့် ရလဒ်က ဖတ်နေသူရဲ့ transaction မြင်ခွင့်ရှိတဲ့ နောက်ဆုံး ဒေတာကို ပြပါတယ် (Isolation အသေးစိတ် ကို ကြည့်ပါ)။
  • Storage (ဒေတာ သိုလှောင်ရာ နေရာ) အပို မလိုဘူး: query ကိုပဲ သိမ်းထားပါတယ်။
  • ဖတ်တိုင်း ပြန်တွက်ရတယ်: view က သူ့ရလဒ်ကို မသိမ်းထားတာကြောင့် view ကို ဖတ်တိုင်း query ရဲ့ အလုပ်ကို ထပ်လုပ်ရပါတယ်။
  • ဒေတာ ပြောင်းတဲ့အခါ အလုပ် အပို မရှိဘူး: table တွေမှာ ပြောင်းလဲမှု ရှိရင် အဲဒါကို view ထဲ ကူးထည့်စရာ မလိုပါဘူး။

Query က လုံလောက်အောင် မြန်တဲ့အခါ၊ ဒါမှမဟုတ် ဖတ်တဲ့ မြန်နှုန်းထက် နောက်ဆုံး ရလဒ်က ပိုအရေးကြီးတဲ့အခါ virtual view ကို သုံးပါ။

Materialised Views (ရလဒ်ကို သိမ်းထားတဲ့ view) ဒါမှမဟုတ် Snapshot Views

Materialised view (တခါတလေ snapshot view လို့လည်း ခေါ်ပါတယ်) က query ရဲ့ precomputed result (ကြိုတင် တွက်ထားတဲ့ ရလဒ်) ကို သိမ်းထားပါတယ်: ကြိုတွက်ထုတ်ထားတဲ့ ရလဒ် row (table ထဲက အလျားလိုက် အတန်း) တွေပါ။ Join တွေနဲ့ စုစုပေါင်း တန်ဖိုး (total) တွေကို လုပ်ပြီးသား ဖြစ်နေလို့ view ကို ဖတ်တဲ့အခါ query ရဲ့ အလုပ်ကို ထပ်လုပ်စရာ မလိုပါဘူး။

Materialised view တွေရဲ့ ဂုဏ်သတ္တိများ:

  • ဖတ်တာ မြန်တယ်: သိမ်းထားတဲ့ ရလဒ်ကို ဖတ်တာကြောင့် view ရဲ့ query အလုပ်ကို ထပ်မလုပ်ရပါဘူး။
  • Storage သုံးတယ်: ရလဒ် row တွေကို disk (ကွန်ပျူတာရဲ့ storage) ပေါ်မှာ သိမ်းပါတယ်။
  • Stale ဖြစ်နိုင်တယ် (ဒေတာ ဟောင်းနေနိုင်တယ်): သိမ်းထားတဲ့ ရလဒ်က table တွေကို နောက်ဆုံး refresh လုပ်ခဲ့တုန်းက အခြေအနေအတိုင်းပဲ ပြပါတယ်၊ အခု အခြေအနေကို မပြပါဘူး။
  • Refresh လုပ်ဖို့ လိုတယ် (query ကို ပြန် run ပြီး ရလဒ်အသစ်ကို သိမ်းခြင်း): အချိန်ဇယားအတိုင်း၊ တောင်းဆိုတဲ့အခါ၊ ဒါမှမဟုတ် table တွေ ပြောင်းတဲ့အခါ အလိုအလျောက် refresh လုပ်ပါတယ်။

နှေးတဲ့ query ဖြစ်ပြီး ရလဒ်ကို update လုပ်ဖို့ လိုတာထက် အများကြီး ပိုခဏခဏ ဖတ်ရတဲ့ query တွေအတွက် materialised view ကို သုံးပါ: report dashboard (အချက်အလက်တွေကို စုပြတဲ့ စာမျက်နှာ) တွေ၊ နေ့စဉ် အရောင်း အကျဉ်းချုပ်တွေ၊ တစ်နာရီ တစ်ကြိမ် update လုပ်တဲ့ leaderboard (အဆင့်ဇယား) တွေ။

Virtual နဲ့ Materialised: ဘေးချင်းယှဉ် နှိုင်းယှဉ်ချက်

ကဏ္ဍ Virtual view Materialised view
Storage Query ကိုပဲ Query နဲ့ ကြိုတွက်ထားတဲ့ ရလဒ် row တွေ
Freshness (ဒေတာ နောက်ဆုံး ဖြစ်မှု) ဖတ်တိုင်း နောက်ဆုံး ဒေတာ Refresh တစ်ခုနဲ့ တစ်ခုကြားမှာ stale ဖြစ်နိုင်တယ်
ဖတ်တဲ့ မြန်နှုန်း ဖတ်တိုင်း query ရဲ့ အလုပ်ကို ထပ်လုပ်ရတယ် ဖတ်တိုင်း သိမ်းထားတဲ့ ရလဒ်ကို သုံးတယ်
Table တွေ ပြောင်းတဲ့အခါ အလုပ် အပို မရှိဘူး View က ပြောင်းလဲမှုတွေကို မပြခင် refresh လုပ်ဖို့ လိုတယ်
Refresh လုပ်ဖို့ လိုသလား မလိုဘူး လိုတယ်: တောင်းဆိုတဲ့အခါ၊ အချိန်ဇယားအတိုင်း၊ ဒါမှမဟုတ် အလိုအလျောက်
အသင့်တော်ဆုံး မြန်တဲ့ query တွေ၊ လုံခြုံရေး၊ query တွေ ပိုရိုးရှင်းအောင် လုပ်ဖို့နဲ့ နောက်ဆုံး ဒေတာ ဖြစ်ရမယ့် ရလဒ်တွေ ခဏခဏ ဖတ်ရတဲ့ နှေးတဲ့ query တွေ၊ ရလဒ် နည်းနည်း ဟောင်းနေလည်း လက်ခံနိုင်တဲ့အခါ

View တွေကို ဘာကြောင့် သုံးသလဲ: အကျိုးကျေးဇူး ခြောက်ခု

ပထမ အကျိုးကျေးဇူး ငါးခုက view နှစ်မျိုးလုံးအတွက် မှန်ပါတယ်:

  1. Hiding data complexity (ဒေတာရဲ့ ရှုပ်ထွေးမှုကို ဖုံးထားပေးခြင်း)။ View တစ်ခုထဲမှာ table ငါးခုကို ချိတ်တဲ့ JOIN ပါနိုင်ပါတယ်။ အဲဒီ view ကို သုံးတဲ့သူတွေက table တစ်ခုလို ပုံပေါ်တာကိုပဲ မြင်ရပြီး join ကို ကိုယ်တိုင် ရေးစရာ မလိုပါဘူး။
  2. Query simplification (query ကို ရိုးရှင်းအောင် လုပ်ခြင်း)။ Query ရှည်ကြီး လိုခဲ့တဲ့ report တစ်ခုက view ကနေ SELECT တိုတို တစ်ခု ဖြစ်သွားပါတယ်။
  3. Security (လုံခြုံရေး)။ View တစ်ခုမှာ column (ဒေါင်လိုက် ကော်လံ) တချို့ ဒါမှမဟုတ် row တချို့ကိုပဲ ထည့်ထားလို့ရပါတယ်။ User တစ်ယောက်ကို view ကို ဖတ်ခွင့် ပေးပြီး view နောက်ကွယ်က table ပေါ်မှာ ဘာခွင့်မှ မပေးဘဲ ထားလို့ရပါတယ်။ ဥပမာ view တစ်ခုက ဝန်ထမ်း တစ်ယောက်ချင်းစီကို သူ့ကိုယ်ပိုင် လစာ row ကိုပဲ ပြပြီး တခြားသူတွေရဲ့ row ကို မပြဘဲ ထားနိုင်ပါတယ်။
  4. Independence (table ဖွဲ့စည်းပုံ ပြောင်းလည်း query တွေ မထိခိုက်ခြင်း)။ အောက်က table တွေ ပြောင်းသွားတဲ့အခါ (column တစ်ခုကို နာမည်ပြောင်းတာ၊ table တစ်ခုကို ခွဲလိုက်တာ) view ရဲ့ query ကို column အတူတူတွေကို ဆက်ပြန်ပေးအောင် ပြန်ရေးလို့ရပြီး view ကို သုံးတဲ့ query တွေက ဆက်အလုပ်လုပ်ပါတယ်။
  5. Data consistency (ဒေတာ တစ်ပြေးညီ ဖြစ်မှု)။ View တစ်ခုတည်းကနေ query လုပ်တဲ့သူ အားလုံးက စည်းမျဉ်း အတူတူကို သုံးကြပါတယ်။ View တစ်ခုက active member (တက်ကြွ အဖွဲ့ဝင်) ကို လွန်ခဲ့တဲ့ သုံးလအတွင်း booking လုပ်ခဲ့တဲ့သူလို့ သတ်မှတ်ထားရင် အဲဒီ view ပေါ်မှာ တည်ဆောက်ထားတဲ့ report နှစ်ခုက active member တွေကို နည်းလမ်း တူတူနဲ့ ရေတွက်ပါတယ်။
  6. Performance (စွမ်းဆောင်ရည်၊ materialised view တွေမှာပဲ)။ ရလဒ်ကို ကြိုတွက်ထားတာကြောင့် နှေးတဲ့ join တွေနဲ့ total တွေက မြန်မြန် ဖတ်လို့ရတာတွေ ဖြစ်သွားပါတယ်။

Read-Only View (ဖတ်ရုံပဲ ဖတ်လို့ရတဲ့ view) နဲ့ Updatable View (view ကနေ ဒေတာ ပြင်လို့ရတဲ့ view)

View တချို့က INSERT၊ UPDATE နဲ့ DELETE ကို လက်ခံပြီး ပြောင်းလဲမှုတွေက view နောက်ကွယ်က table တွေဆီ ရောက်သွားပါတယ်။ ပြောင်းလဲမှု တစ်ခုချင်းက ဘယ် table ရဲ့ ဘယ် row နဲ့ သက်ဆိုင်လဲဆိုတာ DBMS က သိနိုင်မှသာ ဒါကို ခွင့်ပြုပါတယ်။ များသောအားဖြင့် ဆိုလိုတာက view က table တစ်ခုတည်းကို သုံးပြီး aggregate (COUNT၊ SUM လို row အများကနေ တန်ဖိုး တစ်ခု တွက်တဲ့ SQL function)၊ GROUP BY ဒါမှမဟုတ် DISTINCT မပါရပါဘူး။ View ကနေ INSERT လုပ်ဖို့ဆိုရင် table ထဲမှာ တန်ဖိုး မဖြစ်မနေ လိုပြီး default value (သတ်မှတ်မထားရင် သုံးတဲ့ တန်ဖိုး) မရှိတဲ့ column အားလုံးကိုလည်း view မှာ ထည့်ထားရပါမယ်။ ဒါကြောင့် အဲဒီလို column ကို ချန်ထားတဲ့ view တစ်ခုက UPDATE နဲ့ DELETE ကို လက်ခံပေမယ့် INSERT ကို လက်မခံတာမျိုး ဖြစ်နိုင်ပါတယ်။

Aggregate၊ GROUP BY ဒါမှမဟုတ် DISTINCT ပါတဲ့ view တွေက read-only ဖြစ်ပါတယ်: ဖတ်လို့ရပေမယ့် သူတို့ကနေ ဒေတာ ပြောင်းဖို့ ကြိုးစားရင် error ပြပါတယ်။ Table တွေကို join လုပ်ထားတဲ့ view တွေကတော့ DBMS တစ်ခုနဲ့ တစ်ခု မတူပါဘူး: MySQL နဲ့ SQL Server က အဲဒီလို view တချို့ကနေ UPDATE ကို လက်ခံပါတယ်၊ UPDATE က table တစ်ခုတည်းရဲ့ column တွေကိုပဲ ပြောင်းပြီး view က DBMS ရဲ့ တခြား အခြေအနေတွေနဲ့ ကိုက်ညီတဲ့အခါမှာပါ (အဲဒီလို view ကနေ DELETE လုပ်တာကိုတော့ ငြင်းပါတယ်)။ PostgreSQL ကတော့ code အပို မရေးထားရင် အဲဒီ view တွေကို read-only အဖြစ် သတ်မှတ်ပါတယ်။ SQLite က code အပို မရေးထားရင် view အားလုံးကို read-only အဖြစ် သတ်မှတ်ပါတယ်။

အပိုင်း 2: Transaction နဲ့ ACID (A3.3.6)

Transaction ဆိုတာ ဘာလဲ

Database transaction ဆိုတာ DBMS က တစ်ခုတည်းလို ကိုင်တွယ်တဲ့ database operation (database ပေါ်မှာ လုပ်တဲ့ လုပ်ဆောင်ချက်) အစု တစ်ခုပါ။ SQL statement (database ကို ညွှန်ကြားတဲ့ SQL language နဲ့ ရေးထားတဲ့ ညွှန်ကြားချက်) တစ်ခုတည်းကနေ statement ရာနဲ့ချီ အထိ ပါနိုင်ပါတယ်။ Transaction ပြီးဆုံးတဲ့အခါ သူ့ရဲ့ ပြောင်းလဲမှု အားလုံးကို သိမ်းထားမယ်၊ ဒါမှမဟုတ် တစ်ခုမှ မသိမ်းဘူး။

ပုံမှန် ဥပမာက ဘဏ်ငွေလွှဲခြင်းပါ:

BEGIN TRANSACTION;

UPDATE Account SET Balance = Balance - 250 WHERE AccountID = 1001;  -- debit
UPDATE Account SET Balance = Balance + 250 WHERE AccountID = 2002;  -- credit

COMMIT;

Update နှစ်ခုလုံး အကျိုးသက်ရောက်မယ်၊ ဒါမှမဟုတ် တစ်ခုမှ မသက်ရောက်ဘူး။ Debit (account 1001 ထဲက 250 ကို နုတ်ယူခြင်း) အောင်မြင်ပြီး credit (account 2002 ထဲကို 250 ထည့်ခြင်း) မအောင်မြင်ရင်၊ ဥပမာ network (ကွန်ရက်) ချိတ်ဆက်မှု ပြတ်သွားလို့၊ application (database ကို သုံးနေတဲ့ program) crash (program ရုတ်တရက် ပျက်ပြီး ရပ်သွားခြင်း) ဖြစ်သွားလို့ ဒါမှမဟုတ် စစ်ဆေးချက် တစ်ခုက ငွေလက်ခံမယ့် account ကို ငြင်းလိုက်လို့ဆိုရင် 250 က account တစ်ခုကနေ ထွက်သွားပြီး ဘယ် account ကိုမှ မရောက်ပါဘူး။ Transaction က ဒါကို ကာကွယ်ပေးပါတယ်: update နှစ်ခုလုံးကို COMMIT (ပြောင်းလဲမှုတွေကို အပြီးသတ် သိမ်းတဲ့ command) မှာ အတူတူ သိမ်းမယ်၊ ဒါမှမဟုတ် နှစ်ခုလုံးကို ROLLBACK (ပြောင်းလဲမှုတွေကို ပြန်ဖျက်တဲ့ command) မှာ အတူတူ ပြန်ဖျက်မယ်။

Database တစ်ခုက “ဒီပြောင်းလဲမှု အားလုံး ဖြစ်မယ်၊ ဒါမှမဟုတ် တစ်ခုမှ မဖြစ်ဘူး” ဆိုတာကို transaction တွေနဲ့ ပေးပါတယ်။ Transaction မရှိရင် အဆင့် အများနဲ့ လုပ်တဲ့ ပြောင်းလဲမှု တစ်ခုက တစ်ဝက်တစ်ပျက်နဲ့ ကျန်ခဲ့ပြီး ဒေတာတွေ အချင်းချင်း ဆန့်ကျင်နေနိုင်ပါတယ်။

ACID Properties (ACID ဂုဏ်သတ္တိ လေးခု)

ACID property လေးခုက transaction တစ်ခု ပေးတဲ့ အာမခံချက်တွေကို အတူတကွ ဖော်ပြပါတယ်။ Property တစ်ခုချင်းစီမှာ သူ့ကိုယ်ပိုင် တာဝန် ရှိပါတယ်:

Property အာမခံပေးတဲ့ အရာ
Atomicity (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှ မဖြစ်ခြင်း) Transaction ထဲက operation အားလုံး အတူတူ commit (အပြီးသတ် သိမ်း) ဖြစ်မယ်၊ ဒါမှမဟုတ် တစ်ခုမှ မဖြစ်ဘူး။ တစ်စိတ်တစ်ပိုင်းပဲ commit ဖြစ်တာမျိုး မရှိပါဘူး။
Consistency (database ကို စည်းမျဉ်းတွေနဲ့ ကိုက်ညီတဲ့ အခြေအနေမှာ ထားခြင်း) Transaction တစ်ခုက database ကို valid state (စည်းမျဉ်း အားလုံးနဲ့ ကိုက်ညီတဲ့ အခြေအနေ) တစ်ခုကနေ နောက် valid state တစ်ခုဆီ ရောက်စေပါတယ်: transaction မတိုင်ခင်ရော ပြီးတဲ့နောက်ပါ ဒေတာက database မှာ သတ်မှတ်ထားတဲ့ စည်းမျဉ်း အားလုံးကို လိုက်နာပါတယ်။ အဲဒီ စည်းမျဉ်းတွေက primary key (row တစ်ခုချင်းကို ခွဲခြားပေးတဲ့ key)၊ foreign key (တခြား table ရဲ့ primary key ကို ညွှန်းတဲ့ column)၊ CHECK rule (column တန်ဖိုး လိုက်နာရမယ့် အခြေအနေ) တွေနဲ့ DBMS အများစုမှာ data type (ဒေတာ အမျိုးအစား) တွေပါ။ Statement တစ်ခုက စည်းမျဉ်း တစ်ခုကို ချိုးဖောက်မယ်ဆိုရင် DBMS က အဲဒီ statement ကို ငြင်းပြီး application က transaction တစ်ခုလုံးကို rollback လုပ်ပါတယ်။
Isolation (တစ်ခုနဲ့ တစ်ခု သီးခြား ခွဲထားမှု) တစ်ချိန်တည်း run နေတဲ့ transaction တွေက အချင်းချင်းရဲ့ uncommitted (commit မလုပ်ရသေးတဲ့) ပြောင်းလဲမှုတွေကို မမြင်ရပါဘူး။ အတင်းကျပ်ဆုံး isolation level (transaction တွေကို ဘယ်လောက် တင်းတင်းကျပ်ကျပ် ခွဲထားမလဲ သတ်မှတ်တဲ့ setting) မှာ ရလဒ်က transaction တွေကို တစ်ခုပြီးမှ တစ်ခု run တာနဲ့ အတူတူပါပဲ။
Durability (commit လုပ်ပြီးသား ပြောင်းလဲမှုတွေ မပျောက်ဘဲ ကျန်ခြင်း) Transaction တစ်ခု commit ဖြစ်ပြီးတာနဲ့ သူ့ရဲ့ အကျိုးသက်ရောက်မှုတွေက system failure (ပါဝါ ပြတ်တာ၊ crash ဖြစ်တာ) ကို ကျော်ပြီး ကျန်ပါတယ်။ DBMS က commit ကို အတည်မပြုခင် ပြောင်းလဲမှုတွေကို disk ပေါ်မှာ လုံခြုံအောင် လုပ်ထားတာနဲ့ ဒါကို ပေးပါတယ်၊ များသောအားဖြင့် log (ဖြစ်ခဲ့တာတွေကို အစဉ်လိုက် မှတ်ထားတဲ့ မှတ်တမ်း) ထဲမှာပါ။

ACID property တစ်ခုကို ရှင်းပြတဲ့အခါ အချက် သုံးချက် ပြောပါ: ဘာကို အာမခံသလဲ၊ DBMS က အဲဒါကို ဘယ်လို ပေးသလဲ၊ အဲဒါ မရှိရင် ဘာမှားသွားမလဲ။ နာမည် လေးခုကို စာရင်း ချပြရုံနဲ့ ဘယ်တစ်ခုကိုမှ ရှင်းပြတာ မဖြစ်ပါဘူး။ အောက်က အပိုင်းတွေက ဒီပုံစံအတိုင်း သွားပါတယ်။

Atomicity အသေးစိတ်

အလုပ်လုပ်ပုံ (mechanism)။ DBMS က BEGIN TRANSACTION ... COMMIT ထဲမှာ လုပ်တဲ့ ပြောင်းလဲမှု တိုင်းကို ပြန်ဖျက်နိုင်အောင် မှတ်ထားပါတယ်။ COMMIT မတိုင်ခင် server (တခြား ကွန်ပျူတာတွေကို ဝန်ဆောင်မှု ပေးတဲ့ ကွန်ပျူတာ) crash ဖြစ်သွားရင်၊ ပါဝါ ပြတ်သွားရင် ဒါမှမဟုတ် application ရဲ့ ချိတ်ဆက်မှု ပြတ်သွားရင် DBMS က transaction လုပ်ခဲ့တဲ့ ပြောင်းလဲမှု အားလုံးကို ပြန်ဖျက်ပါတယ်။ ဒါကြောင့် ပြောင်းခဲ့တဲ့ row တွေက သူတို့ရဲ့ အရင် တန်ဖိုးတွေ ပြန်ဖြစ်သွားပါတယ်။ Statement တစ်ခု မအောင်မြင်ရင် (ဥပမာ စည်းမျဉ်း တစ်ခုကို ချိုးဖောက်မယ့် statement ဖြစ်လို့) နောက်ဘာဖြစ်မလဲဆိုတာ DBMS ပေါ် မူတည်ပါတယ်။ SQLite နဲ့ error အများစုအတွက် MySQL က အဲဒီ statement တစ်ခုကိုပဲ ပြန်ဖျက်ပြီး transaction ကို ဆက်ဖွင့်ထားပါတယ်။ ဒါကြောင့် ကျန်တာတွေကို ပြန်ဖျက်ဖို့ application က ROLLBACK ကို ခေါ်ရပါတယ်။ PostgreSQL ကတော့ transaction တစ်ခုလုံးကို မအောင်မြင်ဘူးလို့ မှတ်ပြီး ROLLBACK မလုပ်မချင်း နောက်ထပ် statement တွေကို ငြင်းပါတယ်။ Deadlock (အချင်းချင်း စောင့်ရင်း ပိတ်မိနေခြင်း) လို failure တချို့မှာ DBMS က transaction တစ်ခုလုံးကို ကိုယ်တိုင် rollback လုပ်ပါတယ် (deadlock အကြောင်းကို transaction တွေ တစ်ပြိုင်နက် မှန်ကန်စွာ run အောင် ထိန်းတဲ့ Concurrency Control အပိုင်းမှာ ကြည့်ပါ)။

ရလဒ် (consequence)။ ငွေလွှဲတာလို အဆင့် အများနဲ့ လုပ်တဲ့ operation တစ်ခုက တစ်ဝက်တစ်ပျက်နဲ့ မကျန်ခဲ့ပါဘူး။ Credit အဆင့် မအောင်မြင်ရင် debit အဆင့်ကိုလည်း rollback လုပ်တာကြောင့် ငွေ ပျောက်မသွားပါဘူး။

Atomicity မရှိရင်: ငွေလွှဲမှု တစ်ခုက account တစ်ခုထဲက ငွေကို နုတ်ယူပြီး တခြား account ထဲ မထည့်ဘဲ ဖြစ်သွားနိုင်ပါတယ်။

Consistency အသေးစိတ်

အလုပ်လုပ်ပုံ။ DBMS က transaction ထဲက ပြောင်းလဲမှု တိုင်းကို schema (database ဖွဲ့စည်းပုံ ဖော်ပြချက်) ထဲမှာ သတ်မှတ်ထားတဲ့ constraint (database ထဲမှာ သတ်မှတ်ထားတဲ့ စည်းမျဉ်း) တွေနဲ့ တိုက်စစ်ပါတယ်: primary key တန်ဖိုး တစ်ခုချင်းက မထပ်ရဘူး၊ foreign key တန်ဖိုး တစ်ခုချင်းက တကယ် ရှိတဲ့ row တစ်ခုနဲ့ ကိုက်ရမယ် (referential integrity: foreign key တွေ မှန်ကန်စွာ ချိတ်ထားရမယ့် စည်းမျဉ်း)၊ CHECK constraint တစ်ခုချင်းက မှန်နေရမယ်၊ ပြီးတော့ DBMS အများစုမှာ တန်ဖိုး တစ်ခုချင်းက သူ့ column ရဲ့ data type နဲ့ ကိုက်ရပါမယ်။ SQLite ကတော့ ခြွင်းချက်ပါ: SQLite ရဲ့ သာမန် table က ဂဏန်း column ထဲမှာ text လို type မှားနေတဲ့ တန်ဖိုးကို လက်ခံပြီး သိမ်းပါတယ်။ STRICT option နဲ့ ဖန်တီးထားတဲ့ table ကပဲ type တွေကို စစ်ပါတယ်။ Trigger (ဒေတာ ပြောင်းတဲ့အခါ DBMS က အလိုအလျောက် run တဲ့ code) တွေက application လိုအပ်တဲ့ နောက်ထပ် စည်းမျဉ်းတွေကို စစ်ပေးနိုင်ပါတယ်။

ရလဒ်။ Commit ဖြစ်တဲ့ transaction တိုင်းက ဒေတာကို သူ့စည်းမျဉ်းတွေနဲ့ ကိုက်ညီအောင် ထားခဲ့ပါတယ်။ စည်းမျဉ်း တစ်ခုကို ချိုးဖောက်မယ့် statement ကို ငြင်းပါတယ်၊ ဥပမာ မရှိတဲ့ row ကို ညွှန်းနေတဲ့ foreign key ဒါမှမဟုတ် CHECK constraint က တားထားတဲ့အခါ သုညအောက် ရောက်သွားတဲ့ balance (account ထဲက လက်ကျန်ငွေ) ပါ။ ဒါကြောင့် သူ့ရဲ့ ပြောင်းလဲမှုကို မသိမ်းပါဘူး၊ ပြီးတော့ application က transaction ရဲ့ ကျန်တဲ့ အပိုင်းကို rollback လုပ်ပါတယ်။

Consistency မရှိရင်: booking တစ်ခုက မရှိတဲ့ member တစ်ယောက်ကို ညွှန်းနေနိုင်ပါတယ် (orphan row: ချိတ်ရမယ့် row မရှိတော့တဲ့ row)၊ ဒါမှမဟုတ် balance က သုညအောက် ကျသွားနိုင်ပါတယ်။ ပြီးတော့ တစ်ယောက်ယောက်က အဲဒီ row တွေကို ရှာပြီး ပြင်ရပါလိမ့်မယ်။

Isolation အသေးစိတ်

အလုပ်လုပ်ပုံ။ Transaction နှစ်ခု တစ်ချိန်တည်း run တဲ့အခါ DBMS က သူတို့ကို ခွဲထားပါတယ်: transaction တစ်ခုက တခြား transaction တစ်ခု လုပ်ထားတဲ့ ပြောင်းလဲမှုတွေကို အဲဒီ transaction commit မလုပ်မချင်း မမြင်ရပါဘူး (အောက်မှာ ဖော်ပြထားတဲ့ အပျော့ဆုံး isolation level မှာကလွဲရင်)။ DBMS က ဒါကို lock (တခြား transaction တွေကို row တစ်ခု မသုံးခင် စောင့်ခိုင်းတဲ့ အရာ) တွေနဲ့၊ ပြောင်းထားတဲ့ row တွေရဲ့ အရင် version တွေကို သိမ်းထားတာနဲ့၊ ဒါမှမဟုတ် COMMIT မှာ စစ်ဆေးတာနဲ့ လုပ်ပါတယ်။ အဲဒီ သုံးမျိုးကို အောက်က Concurrency Control မှာ ရှင်းပြထားပါတယ်။ DBMS အများစုက program တစ်ခုကို isolation level ရွေးခွင့်လည်း ပေးပါတယ်: အဲဒါက program ရဲ့ transaction တွေကို ဘယ်လောက် တင်းတင်းကျပ်ကျပ် ခွဲထားမလဲ ဆုံးဖြတ်တဲ့ setting တစ်ခုပါ။

ရလဒ်။ User တွေက အချင်းချင်းရဲ့ တစ်ဝက်တစ်ပျက် အလုပ်ကို မဖတ်မိပါဘူး။ အတင်းကျပ်ဆုံး isolation level ဖြစ်တဲ့ Serializable မှာ ရလဒ်က transaction တွေကို တစ်ခုပြီးမှ တစ်ခု run ခဲ့သလိုပဲ ဖြစ်ပါတယ်။ ပိုပျော့တဲ့ level တွေက transaction တွေ စောင့်ရတာကို နည်းစေပြီး အဲဒီအစား ဒီဇယားထဲက ပြဿနာ တချို့ ဖြစ်ခွင့် ပေးပါတယ် (ပြဿနာ တစ်ခုချင်းကို ဇယားအောက်မှာ ရှင်းပြထားပါတယ်):

Isolation level Dirty read Non-repeatable read Phantom read
Read Uncommitted ဖြစ်နိုင်တယ် ဖြစ်နိုင်တယ် ဖြစ်နိုင်တယ်
Read Committed တားပေးတယ် ဖြစ်နိုင်တယ် ဖြစ်နိုင်တယ်
Repeatable Read တားပေးတယ် တားပေးတယ် ဖြစ်နိုင်တယ်
Serializable တားပေးတယ် တားပေးတယ် တားပေးတယ်
  • Dirty read (commit မလုပ်ရသေးတဲ့ ဒေတာကို ဖတ်မိခြင်း) ဆိုတာ တခြား transaction တစ်ခုက ပြောင်းထားပေမယ့် commit မလုပ်ရသေးတဲ့၊ rollback ဖြစ်သွားနိုင်သေးတဲ့ ဒေတာကို ဖတ်တာပါ (ဥပမာ 3 ကို ကြည့်ပါ)။
  • Non-repeatable read (ထပ်ဖတ်ရင် တန်ဖိုး ပြောင်းနေခြင်း) က transaction တစ်ခုက row တစ်ခုတည်းကို နှစ်ကြိမ် ဖတ်ပြီး မတူတဲ့ တန်ဖိုး နှစ်ခု ရတဲ့အခါ ဖြစ်ပါတယ်။ အကြောင်းက အဲဒီ နှစ်ကြိမ်ကြားမှာ တခြား transaction တစ်ခုက row ကို ပြောင်းပြီး commit လုပ်သွားလို့ပါ။
  • Phantom read (ထပ်ဖတ်ရင် row တွေ တိုးလာခြင်း ဒါမှမဟုတ် လျော့သွားခြင်း) က transaction တစ်ခုက query တစ်ခုတည်းကို နှစ်ကြိမ် run ပြီး row အစု မတူတာ ရတဲ့အခါ ဖြစ်ပါတယ်။ အကြောင်းက အဲဒီ နှစ်ကြိမ်ကြားမှာ တခြား transaction တစ်ခုက query နဲ့ ကိုက်ညီတဲ့ row တွေကို ထည့်လိုက် ဒါမှမဟုတ် ဖယ်လိုက်လို့ပါ။

DBMS တစ်ခုချင်းက သူ့ default level ကို ကိုယ်တိုင် ရွေးပါတယ်: PostgreSQL နဲ့ SQL Server မှာ Read Committed၊ MySQL မှာ Repeatable Read၊ SQLite မှာ Serializable ပါ။ DBMS တချို့က ဇယားမှာ လိုအပ်တာထက် ပြဿနာ ပိုများများကို တားပေးပါတယ်။ ဥပမာ PostgreSQL က ဘယ် level မှာမှ dirty read ကို ခွင့်မပြုပါဘူး။ Level တွေရဲ့ နာမည်တွေက သိထားရင် အသုံးဝင်တဲ့ နောက်ခံ အချက်တွေပါ: syllabus (IB သင်ရိုး) က isolation ရဲ့ အခန်းကဏ္ဍအကြောင်း မေးတာပါ၊ level တွေအကြောင်း မမေးပါဘူး။

Lost update (ပြောင်းလဲမှု တစ်ခု ပျောက်သွားခြင်း) က သိထားသင့်တဲ့ နောက်ထပ် ပြဿနာ တစ်ခုပါ: transaction နှစ်ခုက တန်ဖိုး တစ်ခုတည်းကို ဖတ်ပြီး တစ်ခုချင်းက အဲဒီ တန်ဖိုးကနေ တန်ဖိုး အသစ် တစ်ခုကို တွက်ပါတယ်။ ဒုတိယ transaction ရေးလိုက်တဲ့ တန်ဖိုးက ပထမ transaction ရေးထားတဲ့ တန်ဖိုးကို အစားထိုးလိုက်တာကြောင့် ပထမ ပြောင်းလဲမှု ပျောက်သွားပါတယ်။ Program က တန်ဖိုး တစ်ခုကို သာမန် SELECT နဲ့ ဖတ်၊ တန်ဖိုး အသစ်ကို ကိုယ်တိုင် တွက်ပြီး ပြန်ရေးတဲ့အခါ MySQL နဲ့ PostgreSQL ရဲ့ default level တွေက ဒါကို မတားပါဘူး၊ ဘာလို့လဲဆိုတော့ သာမန် SELECT က row ကို lock မလုပ်လို့ပါ။ Program က row ကို ဖတ်တဲ့အချိန်မှာပဲ lock လုပ်တာ (MySQL နဲ့ PostgreSQL မှာ SELECT ... FOR UPDATE)၊ ပိုတင်းကျပ်တဲ့ isolation level ကို ရွေးတာ၊ ဒါမှမဟုတ် ဥပမာ 3 ရဲ့ SET Raised = Raised + 500 လို UPDATE statement တစ်ခုတည်းက တန်ဖိုးကို ဖတ်တာရော ရေးတာပါ တစ်ပြိုင်တည်း လုပ်စေတာနဲ့ ဒါကို ကာကွယ်နိုင်ပါတယ်။

Isolation မရှိရင်: user တစ်ယောက်ရဲ့ ပြောင်းလဲမှုက တခြား user တစ်ယောက်ရဲ့ ပြောင်းလဲမှုကို နှစ်ယောက်စလုံး သတိမထားမိဘဲ အစားထိုးသွားနိုင်ပါတယ်။ ပြီးတော့ နောက်မှ rollback ဖြစ်သွားမယ့် ဒေတာပေါ် အခြေခံပြီး ဆုံးဖြတ်ချက် ချမိနိုင်ပါတယ် (ဥပမာ 3 ကို ကြည့်ပါ)။

Durability အသေးစိတ်

အလုပ်လုပ်ပုံ။ COMMIT အောင်မြင်ပြီလို့ မပြောခင် DBMS က transaction ရဲ့ ပြောင်းလဲမှုတွေကို ပါဝါ မရှိလည်း ဒေတာ မပျောက်တဲ့ storage (ဥပမာ disk) ကနေ ပြန်ယူလို့ရအောင် သေချာလုပ်ပါတယ်။ MySQL၊ PostgreSQL နဲ့ SQL Server သုံးတဲ့ အသုံးများတဲ့ နည်းက transaction log (ပြောင်းလဲမှု တစ်ခုချင်းကို မှတ်ထားတဲ့ file) ပါ: DBMS က ပြောင်းလဲမှုတွေကို log ထဲ အရင် ရေးပါတယ်။ COMMIT ပြီးပြီးချင်း server ပါဝါ ပြတ်သွားရင် ပြန်စတဲ့အခါ log ကို ဖတ်ပြီး commit ဖြစ်ပြီးသား ပြောင်းလဲမှုတွေကို ပြန်လုပ်ပါတယ်။ SQLite ရဲ့ default နည်းကတော့ မတူပါဘူး: ဒေတာ အဟောင်းရဲ့ copy ကို journal file (မှတ်တမ်း file) ထဲမှာ သိမ်းထားပြီး COMMIT မပြီးခင် ပြောင်းလဲမှုတွေကို database file ထဲ တိုက်ရိုက် ရေးပါတယ်။ Crash ဖြစ်ပြီးရင် မပြီးသေးတဲ့ transaction ကို journal သုံးပြီး ပြန်ဖျက်ပါတယ်။

ရလဒ်။ “Transaction committed” (transaction ကို commit လုပ်ပြီးပါပြီ) ဆိုတဲ့ message ကို မြင်ရတဲ့ user က ပြောင်းလဲမှုကို သိမ်းထားမယ်လို့ ယုံကြည်နိုင်ပါတယ်။ ပါဝါ ပြတ်တာ ဒါမှမဟုတ် operating system (ကွန်ပျူတာကို စီမံတဲ့ အဓိက software) crash ဖြစ်တာက commit ဖြစ်ပြီးသား transaction တွေကို မပျောက်စေပါဘူး၊ ဘာလို့လဲဆိုတော့ commit ကို အတည်မပြုခင် သူတို့ရဲ့ ပြောင်းလဲမှုတွေက disk ပေါ်မှာ လုံခြုံနေပြီးသားမို့ပါ။ Disk ပျက်သွားရင်တော့ သူ့ log ပါ ပါသွားတာကြောင့် ပျက်သွားတဲ့ disk ပေါ်က commit ဖြစ်ပြီးသား ဒေတာကို backup (အရန် မိတ္တူ) ကနေ ဒါမှမဟုတ် တခြား disk ပေါ်က copy ကနေ ပြန်ယူရပါမယ်။

Durability မရှိရင်: app တစ်ခုက customer ကို ငွေပေးချေမှု အောင်မြင်ပြီလို့ ပြောပေမယ့် ပါဝါ ပြတ်ပြီးတဲ့နောက် database မှာ အဲဒီ မှတ်တမ်း မရှိတော့ပါဘူး။

Transaction Control Language (TCL၊ transaction ကို ထိန်းချုပ်တဲ့ SQL command များ)

TCL command သုံးခုက:

BEGIN TRANSACTION;     -- mark the start of a transaction
...
COMMIT;                -- save all changes since BEGIN TRANSACTION
-- or --
ROLLBACK;              -- undo all changes since BEGIN TRANSACTION

Code ထဲက comment တွေက BEGIN TRANSACTION က transaction ရဲ့ အစကို မှတ်တယ်၊ COMMIT က BEGIN TRANSACTION ကတည်းက ပြောင်းလဲမှု အားလုံးကို သိမ်းတယ်၊ ROLLBACK က BEGIN TRANSACTION ကတည်းက ပြောင်းလဲမှု အားလုံးကို ပြန်ဖျက်တယ် လို့ ဆိုလိုပါတယ်။ -- or -- က “ဒါမှမဟုတ်” ပါ။

COMMIT က transaction ရဲ့ ပြောင်းလဲမှုတွေကို အပြီးအပိုင် သိမ်းပြီး တခြား transaction တွေ မြင်ရအောင် လုပ်ပါတယ်။ ROLLBACK က ဒီ transaction ရဲ့ ပြောင်းလဲမှုတွေကို ပယ်ဖျက်ပါတယ်၊ တခြား transaction တွေ commit လုပ်ထားတဲ့ ပြောင်းလဲမှုတွေကိုတော့ မထိခိုက်ပါဘူး။

Transaction စတဲ့ command က DBMS တစ်ခုနဲ့ တစ်ခု မတူပါဘူး။ SQL Server က BEGIN TRANSACTION ကို သုံးပါတယ်။ PostgreSQL က BEGIN TRANSACTION၊ BEGIN ဒါမှမဟုတ် START TRANSACTION ကို လက်ခံပါတယ်။ MySQL က START TRANSACTION ဒါမှမဟုတ် BEGIN ကို သုံးပြီး BEGIN TRANSACTION ကို လက်မခံပါဘူး။ SQLite က BEGIN TRANSACTION ဒါမှမဟုတ် BEGIN ကို သုံးပြီး START TRANSACTION ကို လက်မခံပါဘူး။ Transaction အကြောင်း ရေးတဲ့အခါ ဒီပုံစံတွေထဲက ဘယ်ဟာကိုမဆို သုံးလို့ရပါတယ်။ ဒီစာမျက်နှာမှာတော့ BEGIN TRANSACTION ကို သုံးပါတယ်။ COMMIT နဲ့ ROLLBACK ကတော့ လေးခုလုံးမှာ အတူတူပါပဲ။

Auto-commit (statement တစ်ခုချင်းကို အလိုအလျောက် commit လုပ်ခြင်း)။ Default အနေနဲ့ MySQL၊ PostgreSQL၊ SQL Server နဲ့ SQLite အပါအဝင် DBMS အများစုက statement တစ်ခုချင်းကို သူ့ဘာသာ transaction တစ်ခုအဖြစ် သတ်မှတ်ပြီး run ပြီးတာနဲ့ ချက်ချင်း သိမ်းပါတယ်။ Statement အများ အတူတူ အောင်မြင်ဖို့ ဒါမှမဟုတ် အတူတူ မအောင်မြင်ဖို့ လိုတဲ့အခါမှသာ BEGIN TRANSACTION ကို ရေးဖို့ လိုပါတယ်။

Concurrency Control (transaction တွေ တစ်ပြိုင်နက် မှန်ကန်စွာ run အောင် ထိန်းခြင်း)

BEGIN TRANSACTION ရှိရင်တောင် DBMS က တစ်ချိန်တည်း run နေတဲ့ transaction တွေကို ညှိပေးရပါသေးတယ်။ ဥပမာ 1 က အားကစား club မှာ ဖြစ်တဲ့ အခြေအနေ တစ်ခုကို ကြည့်ကြရအောင်: coach (နည်းပြ) တစ်ယောက်ရဲ့ transaction က class C402 ကို 17:30 ကနေ 18:15 ကို ရွှေ့နေပြီး commit မလုပ်ရသေးပါဘူး။ တစ်ချိန်တည်းမှာ receptionist (ဧည့်ကြို ဝန်ထမ်း) ရဲ့ transaction က ဒီနေ့ အချိန်ဇယားကို print ထုတ်ဖို့ C402 ရဲ့ row ကို ဖတ်နေပါတယ်။ DBMS တွေက နည်း သုံးမျိုးကို သုံးကြပြီး များသောအားဖြင့် တစ်မျိုးထက် ပိုပြီး တစ်ပြိုင်တည်း သုံးပါတယ်။ နည်း တစ်မျိုးချင်းက receptionist ရဲ့ ဖတ်တာကို မတူတဲ့ ပုံစံနဲ့ ကိုင်တွယ်ပါတယ်:

နည်း Receptionist ရဲ့ ဖတ်တာ ဘာဖြစ်သလဲ ပေးရတဲ့ အဖိုး
Locking (pessimistic concurrency control: transaction တွေ ဒေတာ တစ်ခုတည်းကို တိုက်မိတာ မဖြစ်ခင် တားတဲ့ နည်း) Coach ရဲ့ transaction က commit မလုပ်မချင်း C402 ရဲ့ row ပေါ်မှာ lock ကို ကိုင်ထားတာကြောင့် ဖတ်တာက စောင့်ရပြီး ပြီးမှ 18:15 ကို print ထုတ်ပါတယ်။ User တွေက အချင်းချင်း စောင့်ရပါတယ်။ Transaction နှစ်ခုက တစ်ခုချင်းစီ တစ်ဖက်က ကိုင်ထားတဲ့ lock ကို စောင့်နေကြရင် deadlock ဖြစ်ပါတယ်။ DBMS အများစုက အဲဒါကို သိရှိပြီး တစ်ခုကို ဖျက်သိမ်းလိုက်ပြီး program က အဲဒါကို ပြန် run ပါတယ်။
Multi-version concurrency control (MVCC၊ row ရဲ့ version အဟောင်းတွေကိုပါ သိမ်းထားတဲ့ နည်း) DBMS က row ရဲ့ commit ဖြစ်ပြီးသား version အဟောင်းကို သိမ်းထားတာကြောင့် ဖတ်တာက မစောင့်ရပါဘူး: receptionist ရဲ့ transaction မြင်ခွင့်ရှိတဲ့ version ဖြစ်တဲ့ 17:30 ကို print ထုတ်ပါတယ်။ Coach commit လုပ်ပြီးမှ စတဲ့ ဖတ်မှုကတော့ 18:15 ကို ပြပါတယ်။ Version အဟောင်းတွေက ဘယ် transaction မှ မလိုတော့တဲ့အထိ storage ကို နေရာယူပါတယ်။ ပြီးတော့ ရေးတဲ့ transaction တွေက သူတို့ ပြောင်းတဲ့ row တွေကို lock လုပ်ဆဲမို့ အဲဒီအချိန်မှာပဲ C402 ကို ပြောင်းနေတဲ့ ဒုတိယ coach က စောင့်ရပါတယ်။
Optimistic concurrency control (တိုက်မိတာ ရှားတယ်လို့ ယူဆတဲ့ နည်း) ဘာကိုမှ lock မလုပ်ပါဘူး။ ဒီမှာ ဖော်ပြထားတဲ့ ပုံစံမှာ COMMIT လုပ်တဲ့အချိန် DBMS က transaction ဖတ်ခဲ့တဲ့ row တစ်ခုခုကို ကြားထဲမှာ commit လုပ်သွားတဲ့ တခြား transaction တစ်ခုက ပြောင်းထားသလားလို့ စစ်ပါတယ်၊ ပြီးတော့ အဲဒီ စစ်ဆေးချက် အောင်မြင်ပြီးမှ အချိန်ဇယားကို print ထုတ်ပါတယ်။ Coach က အရင် commit လုပ်သွားရင် စစ်ဆေးချက် မအောင်မြင်ဘဲ receptionist ရဲ့ transaction ကို ဖျက်သိမ်းလိုက်ပြီး program က အဲဒါကို ပြန် run ပါတယ်။ ဒုတိယ အကြိမ် run တာက 18:15 ကို print ထုတ်ပါတယ်။ တိုက်မိတာ ရှားတဲ့အခါ မြန်ပါတယ်။ ခဏခဏ တိုက်မိတဲ့အခါ လုပ်ထားတဲ့ အလုပ် အများကြီးကို ပစ်လိုက်ရပါတယ်။

PostgreSQL၊ MySQL (သူ့ရဲ့ default storage engine ဖြစ်တဲ့ InnoDB နဲ့ ဆိုရင်၊ storage engine ဆိုတာ MySQL ထဲမှာ ဒေတာကို သိမ်းပေးတဲ့ အပိုင်းပါ) နဲ့ Oracle တို့က ဖတ်ဖို့ MVCC ကို သုံးပြီး row တွေ ပြောင်းဖို့ lock တွေကို သုံးပါတယ်။ Isolation level က ဒီနည်းတွေထဲက ဘယ်ဟာ သုံးမလဲ ရွေးတာ မဟုတ်ပါဘူး။ Isolation အသေးစိတ် ထဲက ပြဿနာတွေထဲက ဘယ်ဟာတွေကို တားမလဲ ဆုံးဖြတ်တာပါ၊ ပြီးတော့ DBMS က အဲဒီ level ကို ပေးဖို့ သူ့ရဲ့ lock တွေ၊ သိမ်းထားတဲ့ version တွေနဲ့ စစ်ဆေးချက်တွေကို သုံးပါတယ်။

ဒါတွေ အားလုံး ဘာကြောင့် အရေးကြီးသလဲ

Transaction တွေနဲ့ ACID ကြောင့် ဘဏ်တွေ၊ ဆေးရုံတွေ၊ အစိုးရတွေနဲ့ တခြား အဖွဲ့အစည်းတွေက row တိုင်း မှန်ရမယ့် သူတို့ရဲ့ တရားဝင် မှတ်တမ်းတွေကို relational database (table တွေ ချိတ်ဆက်ထားတဲ့ database) မှာ ယုံကြည်စိတ်ချ သိမ်းကြတာပါ။ NoSQL database (ပုံသေ table ပုံစံ မသုံးတဲ့ database) တချို့က ဒေတာ ပိုများများနဲ့ user ပိုများများကို ကိုင်တွယ်နိုင်ဖို့ ဒီ အာမခံချက်တွေရဲ့ တစ်စိတ်တစ်ပိုင်းကို တမင် စွန့်လွှတ်ကြပါတယ် (Alternative Databases နဲ့ Distributed Databases မှာ လေ့လာရပါမယ်)။

ဖြေရှင်းပြထားတဲ့ ဥပမာများ

ဥပမာ 1: Virtual View တစ်ခုကို သတ်မှတ်ခြင်း

အားကစား club ရဲ့ coach တွေက member တစ်ယောက်ချင်းစီ 2026 ခုနှစ် ဇန်နဝါရီလ 1 ရက်နေ့ကတည်းက booking ဘယ်နှစ်ခု လုပ်ခဲ့လဲ သိချင်ကြပါတယ်၊ booking တစ်ခုမှ မလုပ်ခဲ့တဲ့ member တွေလည်း ပါရပါမယ်။ Table နှစ်ခုကို join လုပ်တဲ့ query ကို view အဖြစ် သိမ်းပါ:

CREATE VIEW MemberBookingSummary AS
SELECT m.MemberID,
       m.FirstName,
       m.Surname,
       m.Tier,
       COUNT(b.BookingID) AS BookingCount
FROM   Member m
LEFT JOIN Booking b ON m.MemberID = b.MemberID
                    AND b.BookedOn >= '2026-01-01'
GROUP BY m.MemberID, m.FirstName, m.Surname, m.Tier;

LEFT JOIN က member အားလုံးကို ထားပေးပါတယ်၊ အဲဒီ ရက်ကတည်းက booking မရှိတဲ့ member တွေလည်း ပါပါတယ်။ သူတို့က BookingCount 0 နဲ့ ပေါ်လာပါတယ်။ အခု coach တွေက view ပေါ်မှာ ရိုးရှင်းတဲ့ query တွေကို run လို့ရပါပြီ:

SELECT FirstName, Surname, BookingCount
FROM   MemberBookingSummary
WHERE  Tier = 'Premium' AND BookingCount > 10;

View ကို ဖတ်တိုင်း သူ့ရဲ့ join ကို ပြန် run တာကြောင့် ရလဒ်က နောက်ဆုံး ဒေတာ ဖြစ်ပြီး storage အပို မသုံးပါဘူး။ ဒေတာ များလာလို့ JOIN က အရမ်း နှေးလာရင် ရလဒ်ကို materialised view အဖြစ် သိမ်းပါ။ Virtual view နဲ့ materialised view က နာမည် တစ်ခုတည်းကို မျှသုံးလို့ မရတာကြောင့် ဒီ view မှာ သူ့ကိုယ်ပိုင် နာမည် ရှိပါတယ်:

CREATE MATERIALIZED VIEW MemberBookingSnapshot AS ...
-- and refresh on demand:
REFRESH MATERIALIZED VIEW MemberBookingSnapshot;

Code ထဲက -- and refresh on demand: comment က “ပြီးတော့ လိုတဲ့အခါ refresh လုပ်ပါ” လို့ ဆိုလိုပါတယ်။

(SQL ရေးထုံးက DBMS တစ်ခုနဲ့ တစ်ခု မတူပါဘူး။ PostgreSQL က အပေါ်က ပုံစံကို သုံးပါတယ်။ Oracle ကလည်း CREATE MATERIALIZED VIEW ကို သုံးပြီး သူ့ကိုယ်ပိုင် refresh option တွေ ရှိပါတယ်။ SQL Server က indexed view တွေကို သုံးပြီး table တွေ ပြောင်းတာနဲ့အမျှ သူ့ဘာသာ နောက်ဆုံး ဒေတာ ဖြစ်အောင် ထိန်းထားပါတယ် (indexed view တွေမှာ စည်းမျဉ်း ပိုတင်းကျပ်ပါတယ်: ဥပမာ outer join ကို သုံးလို့ မရပါဘူး)။ MySQL နဲ့ SQLite မှာ materialised view မရှိပါဘူး: အချိန်ဇယားအတိုင်း run တဲ့ job တစ်ခုက ပြန်ဖြည့်ပေးတဲ့ table တစ်ခုက အလုပ် အတူတူကို လုပ်ပေးပါတယ်။)

ဥပမာ 2: Atomic ဖြစ်တဲ့ ဘဏ်ငွေလွှဲမှု

Coral Bank က customer တစ်ယောက်က သူ့ current account (နေ့စဉ် သုံးတဲ့ ငွေစာရင်း၊ AccountID = 1001) ကနေ savings account (ငွေစုစာရင်း၊ AccountID = 2002) ကို 250 ဒေါ်လာ လွှဲပါတယ်။ Transaction က all-or-nothing (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှ မဖြစ်) ဖြစ်ရပါမယ်:

BEGIN TRANSACTION;

UPDATE Account
SET    Balance = Balance - 250
WHERE  AccountID = 1001;

-- Check the source account did not go below zero
-- (handled by the application or a CHECK constraint)

UPDATE Account
SET    Balance = Balance + 250
WHERE  AccountID = 2002;

INSERT INTO Transfer (FromAccountID, ToAccountID, Amount, TransferredAt)
VALUES (1001, 2002, 250, '2026-05-22 09:14:00');

COMMIT;

Code ထဲက comment က “ငွေထုတ်တဲ့ account က သုညအောက် မရောက်ကြောင်း စစ်ပါ (application ဒါမှမဟုတ် CHECK constraint က စစ်ပေးတယ်)” လို့ ဆိုလိုပါတယ်။

Statement တစ်ခုခု မအောင်မြင်ရင် (ဥပမာ CHECK constraint က သုညအောက် balance ကို ငြင်းလိုက်ရင်)၊ ဒါမှမဟုတ် account နံပါတ် မရှိလို့ UPDATE တစ်ခုက row တစ်ခုမှ မပြောင်းရင် application က COMMIT အစား ROLLBACK ကို ခေါ်ပါတယ်၊ ပြီးတော့ statement သုံးခုထဲက တစ်ခုမှ အကျိုးသက်ရောက်မှု မရှိပါဘူး။ Row တစ်ခုမှ မကိုက်တဲ့ UPDATE က error မဟုတ်ပါဘူး၊ ဒါကြောင့် application က statement တစ်ခုချင်း row ဘယ်နှစ်ခု ပြောင်းသွားလဲ စစ်ပါတယ်။

ဥပမာ 3: Isolation ကို လက်တွေ့ ကြည့်ခြင်း၊ Dirty Read

ကျောင်းတစ်ကျောင်းရဲ့ charity appeal (အလှူငွေ ကောက်ခံပွဲ) က သူ့ရဲ့ လက်ရှိ စုစုပေါင်း ငွေကို Appeal(AppealID, Raised, Target) table ထဲမှာ သိမ်းပါတယ်။ Appeal 7 က ပန်းတိုင် 2000 အတွက် 1800 ကောက်ခံပြီးပါပြီ။ မိဘ တစ်ယောက်က online ကနေ 500 လှူမယ်လို့ ကတိပေးပါတယ်၊ တစ်ချိန်တည်းမှာ website ရဲ့ progress job (ပန်းတိုင် ရောက်မရောက် စစ်တဲ့ အလုပ်) က ပန်းတိုင် ရောက်ပြီလား စစ်နေပါတယ်။ Isolation မရှိရင် ဖြစ်နိုင်တာက ဒီလိုပါ:

အချိန် Transaction A (500 ကတိကို မှတ်တမ်းတင်တယ်) Transaction B (website progress job)
t1 BEGIN TRANSACTION  
t2 UPDATE Appeal SET Raised = Raised + 500 WHERE AppealID = 7 (Raised က အခု 2300၊ commit မလုပ်ရသေးဘူး)  
t3   BEGIN TRANSACTION
t4   SELECT Raised FROM Appeal WHERE AppealID = 7 -> 2300 ကို ပြန်ပေးတယ်
t5   2300 က 2000 ထက် မနည်းတာကြောင့် B က INSERT INTO Notice (AppealID, Message) VALUES (7, 'Target reached') ကို run ပြီး COMMIT လုပ်တယ်
t6 Card ငွေပေးချေမှုကို ငြင်းလိုက်တာကြောင့် application က ROLLBACK ကို ခေါ်တယ် (Raised က 1800 ကို ပြန်ဖြစ်သွားတယ်)  

t4 မှာ B က A commit မလုပ်ရသေးတဲ့ တန်ဖိုး တစ်ခုကို ဖတ်ခဲ့ပါတယ်: ဒါက dirty read ပါ။ A က rollback လုပ်ပြီးတဲ့နောက် table က 1800 ကောက်ခံပြီးတယ်လို့ ပြနေပေမယ့် website ကတော့ ပန်းတိုင် ရောက်ပြီ (‘Target reached’) လို့ ပြောတဲ့ notice ကို ပြနေပါတယ်။ B က ဘယ်တုန်းကမှ မသိမ်းခဲ့တဲ့ စုစုပေါင်း တန်ဖိုး ပေါ်မှာ ဆုံးဖြတ်ချက် ချခဲ့တာပါ။

Isolation ရှိရင် A ရဲ့ UPDATE က A commit ဒါမှမဟုတ် rollback မလုပ်မချင်း row ကို lock လုပ်ထားပါတယ်။ t4 မှာ B ရဲ့ SELECT က lock ကို စောင့်ပါတယ်၊ ဒါမှမဟုတ် multi-version concurrency control သုံးတဲ့ DBMS မှာဆိုရင် row ရဲ့ commit ဖြစ်ပြီးသား version ကို ဖတ်ပါတယ်။ ဘယ်လိုပဲ ဖြစ်ဖြစ် B က 1800 ကို မြင်ရပြီး ပန်းတိုင် မရောက်သေးတာကြောင့် notice မတင်ပါဘူး။

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

Q1. Virtual view ကို အကောင်းဆုံး ဖော်ပြထားတာ ဘယ်ဟာလဲ။

Q2. Virtual view ထက် materialised view ကို အသုံးပြုသင့်ဆုံး အခြေအနေက ဘယ်ဟာလဲ။

Q3. ဘဏ်ငွေလွှဲမှု တစ်ခုက account တစ်ခုထဲက ငွေကို နုတ်ပြီး နောက် account တစ်ခုထဲ ငွေ ထည့်ပါတယ်။ Update နှစ်ခုလုံး အကျိုးသက်ရောက်မယ်၊ ဒါမှမဟုတ် တစ်ခုမှ မသက်ရောက်ဘူး ဆိုတာကို ဘယ် ACID property က သေချာစေသလဲ။

Q4. Transaction တစ်ခုရဲ့ commit ဖြစ်ပြီးသား ပြောင်းလဲမှုတွေက ရုတ်တရက် ပါဝါ ပြတ်တာကို ကျော်ပြီး ကျန်မယ်လို့ ဘယ် ACID property က အာမခံသလဲ။

Q5. Transaction တစ်ခုက UPDATE statement သုံးခုကို run ပြီးပါပြီ၊ ဒါပေမယ့် commit မလုပ်ရသေးပါဘူး။ Application က error တစ်ခုကို တွေ့ပြီး ROLLBACK ကို ခေါ်ပါတယ်။ ဘာဖြစ်မလဲ။

Q6. ACID ရဲ့ Isolation property က ဘယ်ပြဿနာကို တားပေးသလဲ။

Trace the Transaction (transaction ကို တစ်ဆင့်ချင်း လိုက်ကြည့်ခြင်း)

ဘဏ်ငွေလွှဲ အခြေအနေများ။ Account A မှာ 1000 နဲ့ စပြီး Account B မှာ 200 နဲ့ စပါတယ်။ အခြေအနေ တစ်ခုစီမှာ A ကနေ B ကို 300 လွှဲဖို့ ကြိုးစားတဲ့ transaction တစ်ခု run ပါတယ်။ အခြေအနေ ပြီးဆုံးတဲ့အခါ Account A ရဲ့ နောက်ဆုံး လက်ကျန်ငွေကို ဂဏန်းနဲ့ ရိုက်ထည့်ပါ။

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

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

TCL command တွေနဲ့ ACID ဝေါဟာရတွေကို ဖြည့်ပါ။ Command ကွက်လပ် တစ်ခုစီမှာ command ရဲ့ စကားလုံးတွေကိုပဲ ဖြည့်ဖို့ လိုပါတယ်: semicolon (;) က ပါပြီးသားပါ။ အဖြေတွေကို English လို ရိုက်ထည့်ပါ။

TRANSACTIONS AND ACID
=====================
Start a transaction:
;

Save every change since the start, permanently:
;

Undo every change since the start:
;

THE ACID PROPERTIES
-------------------
 = all or nothing
 = valid state to valid state
 = concurrent transactions do not interfere
 = committed changes survive failure

စာကြောင်းတွေရဲ့ အဓိပ္ပာယ်: Start a transaction (transaction ကို စပါ)၊ Save every change since the start, permanently (စကတည်းက ပြောင်းလဲမှု အားလုံးကို အပြီးအပိုင် သိမ်းပါ)၊ Undo every change since the start (စကတည်းက ပြောင်းလဲမှု အားလုံးကို ပြန်ဖျက်ပါ)။ THE ACID PROPERTIES အောက်မှာတော့ all or nothing (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှ မဖြစ်)၊ valid state to valid state (valid state တစ်ခုကနေ နောက် valid state တစ်ခုဆီ)၊ concurrent transactions do not interfere (တစ်ပြိုင်နက် run တဲ့ transaction တွေ အချင်းချင်း မနှောင့်ယှက်)၊ committed changes survive failure (commit ဖြစ်ပြီးသား ပြောင်းလဲမှုတွေ failure ကို ကျော်ပြီး ကျန်) လို့ ဆိုလိုပါတယ်။

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

Developer တစ်ယောက်က ငွေလွှဲမှု တစ်ခုကို transaction အဖြစ် ရေးထားပါတယ်။ Application က statement တစ်ခုချင်းကို စစ်ပြီး တစ်ခုခု မအောင်မြင်ရင် ဒါမှမဟုတ် row တစ်ခုမှ မပြောင်းရင် ROLLBACK ကို ခေါ်ပါတယ်။ ဒါပေမယ့် credit မပါဘဲ debit ကို သိမ်းမိသွားနိုင်ပါသေးတယ်။ Line တစ်ကြောင်းမှာ အမှား ပါပါတယ်။ အမှားပါတဲ့ line ကို ရွေးပါ၊ ပြီးရင် မှန်ကန်တဲ့ ပြင်နည်းကို ရွေးပါ။

1BEGIN TRANSACTION; 2UPDATE Account SET Balance = Balance - 250 WHERE AccountID = 1001; 3COMMIT; 4UPDATE Account SET Balance = Balance + 250 WHERE AccountID = 2002; 5COMMIT;

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

Identify the Property (ACID property ကို ခွဲခြား ဖော်ထုတ်ခြင်း)

အားကစား club တစ်ခုရဲ့ အပတ်စဉ် report က transaction တစ်ခုအဖြစ် run ပါတယ်။ Report က club ရဲ့ Class table ထဲကနေ class C401 ရဲ့ capacity (ဆံ့နိုင်တဲ့ ပမာဏ) ကို ဖတ်ပြီး report ရဲ့ ထိပ်ဆုံးမှာ print ထုတ်ပါတယ်။ အဲဒီ transaction ထဲမှာပဲ နောက်ပိုင်းမှာ နေရာ ဘယ်နှစ်ခု လွတ်သေးလဲ တွက်ဖို့ row တစ်ခုတည်းကို ထပ်ဖတ်ပါတယ်။ ဖတ်တဲ့ နှစ်ကြိမ်ကြားမှာ coach တစ်ယောက်က class ရဲ့ capacity ကို 20 ကနေ 25 ကို တိုးပြီး ပြောင်းလဲမှုကို commit လုပ်လိုက်တာကြောင့် report ရဲ့ ထိပ်ပိုင်းနဲ့ အောက်ပိုင်း မကိုက်တော့ပါဘူး။ ဘယ် ACID property ကို တင်းတင်းကျပ်ကျပ် လိုက်နာစေခဲ့ရင် ဒါကို တားနိုင်ခဲ့မလဲ။

Property နာမည်ကို English လို ရိုက်ထည့်ပါ (ဥပမာ Atomicity)။

ဆရာ တစ်ယောက်က ကျောင်းရဲ့ reporting system (အမှတ်စာရင်းနဲ့ report ထုတ်တဲ့ စနစ်) ထဲမှာ ကျောင်းသား တစ်ယောက်ရဲ့ နောက်ဆုံး အမှတ်ကို သိမ်းလိုက်ပြီး system က ပြောင်းလဲမှုကို commit လုပ်ပြီးပြီလို့ ပြပါတယ်။ မိနစ်အနည်းငယ် ကြာတော့ database server ပေါ်က operating system crash ဖြစ်သွားပါတယ်။ Server ပြန် run တဲ့အခါ အမှတ်က မရှိတော့ပါဘူး။ ဘယ် ACID property ကို ချိုးဖောက်ခဲ့သလဲ။

Property နာမည်ကို ရိုက်ထည့်ပါ။

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

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

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

  1. [Core] Views (HL) [4 marks] virtual view နဲ့ materialised view ဆိုတဲ့ ဝေါဟာရ နှစ်ခုကို Define (အဓိပ္ပာယ်ကို တိတိကျကျ ဖော်ပြပါ) လုပ်ပြီး သူတို့ကြားက အဓိက ကွာခြားချက် တစ်ခုကို state (ဖော်ပြပါ) လုပ်ပါ။

  2. [Core] Transactions (HL) [2 marks] ကျောင်း app တစ်ခုက statement နှစ်ခုနဲ့ ကျောင်းသား တစ်ယောက်ကို club တစ်ခုမှာ စာရင်းသွင်းပေးပါတယ်: Membership ထဲကို INSERT တစ်ခုနဲ့ club ရဲ့ MemberCount ကို 1 တိုးတဲ့ UPDATE တစ်ခုပါ။ ဒီ statement နှစ်ခုကို transaction တစ်ခုအဖြစ် run တယ်ဆိုတာ ဘာကို ဆိုလိုလဲ Outline (အကျဉ်းချုပ် ဖော်ပြပါ) လုပ်ပါ။

  3. [Core] Transactions (HL) [4 marks] ACID property လေးခုကို State လုပ်ပြီး တစ်ခုချင်းစီအတွက် စာကြောင်း တစ်ကြောင်းစီနဲ့ အကျဉ်းချုပ် ပေးပါ။

  4. [Core] Views (HL) [3 marks] ခွေး လမ်းလျှောက်ပေးတဲ့ လုပ်ငန်း တစ်ခုက သူ့ရဲ့ walker (ခွေး လမ်းလျှောက်ပေးသူ) တွေကို Walker(WalkerID, FullName, Phone, HomeAddress, HourlyRate, CheckExpires) table ထဲမှာ သိမ်းပါတယ်။ CheckExpires က walker ရဲ့ background check (နောက်ခံ စစ်ဆေးချက်) သက်တမ်း ကုန်မယ့် ရက်စွဲပါ။ Customer တွေ ခွေး လမ်းလျှောက်ခိုင်းဖို့ booking လုပ်တဲ့ app က walker တစ်ယောက်ချင်းရဲ့ နာမည်နဲ့ CheckExpires ကို ပြရပါမယ်၊ ဒါပေမယ့် သူတို့ရဲ့ ဖုန်းနံပါတ်၊ နေအိမ်လိပ်စာ ဒါမှမဟုတ် တစ်နာရီ လုပ်ခကို မပြရပါဘူး။ View တစ်ခုက တခြား column တွေကို လျှို့ဝှက်ထားရင်း app ကို လိုအပ်တဲ့ ဒေတာ ဘယ်လို ပေးနိုင်လဲ Describe (ဖော်ပြရှင်းပြပါ) လုပ်ပါ၊ ပြီးတော့ app ကို တည်ဆောက်တဲ့သူတွေအတွက် view ပေးတဲ့ တခြား အကျိုးကျေးဇူး တစ်ခုကို outline လုပ်ပါ။

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

  1. [Extension] Transactions (HL) [3 marks] မူလတန်းကျောင်း တစ်ကျောင်းရဲ့ စာဖတ် စိန်ခေါ်မှု app က ကျောင်းသား တစ်ယောက်ချင်း ဒီနေ့ ဖတ်ခဲ့တဲ့ စာမျက်နှာ အရေအတွက်ကို Pupil table ရဲ့ PagesToday column ထဲမှာ သိမ်းပါတယ်။ ညတိုင်း job တစ်ခုက statement နှစ်ခု run ပါတယ်: ကျောင်းသား တစ်ယောက်ချင်းရဲ့ PagesToday ကို ရက်စွဲနဲ့အတူ ReadingLog table ထဲ ကူးထည့်တဲ့ INSERT တစ်ခု၊ ပြီးရင် ကျောင်းသား အားလုံးရဲ့ PagesToday ကို 0 ပြန်ထားတဲ့ UPDATE တစ်ခုပါ။ ဒီ statement နှစ်ခုကို atomic transaction တစ်ခုအဖြစ် ဘာကြောင့် run သင့်လဲ Explain (ရှင်းပြပါ) လုပ်ပါ။

  2. [Extension] Transactions (HL) [3 marks] Server က ဘယ်အချိန်မဆို crash ဖြစ်နိုင်တဲ့အခါမှာတောင် transaction durability ကို ဘယ်လို ရအောင် လုပ်လဲ Explain လုပ်ပါ။

  3. [Extension] Transactions (HL) [3 marks] ACID property တွေကို အကောင်အထည်ဖော်ရာမှာ BEGIN TRANSACTION၊ COMMIT နဲ့ ROLLBACK ဆိုတဲ့ TCL command သုံးခုရဲ့ အခန်းကဏ္ဍကို Describe လုပ်ပါ။

  4. [Extension] Transactions (HL) [4 marks] ကျောင်းတစ်ကျောင်းရဲ့ အနုပညာ ဌာနက သူ့ရဲ့ ပစ္စည်းတွေကို Supply(SupplyID, SupplyName, OnHand) table ထဲမှာ မှတ်တမ်းတင်ပါတယ်။ ဆရာ နှစ်ယောက်က acrylic ဆေးဘူး (tube) တွေ ယူသွားတာကို တစ်ချိန်တည်းမှာ မှတ်တမ်းတင်ကြပါတယ်။ ဆရာ တစ်ယောက်ချင်းရဲ့ app က OnHand ကို ဖတ်၊ ယူသွားတဲ့ အရေအတွက်ကို နုတ်ပြီး တန်ဖိုး အသစ်ကို ပြန်ရေးပါတယ်။ Concurrency control မရှိရင် အဆင့်တွေက ဒီအစဉ်အတိုင်း run ပါတယ်: Transaction A က OnHand ကို 40 လို့ ဖတ်တယ်၊ Transaction B က OnHand ကို 40 လို့ ဖတ်တယ်၊ A က 34 ကို ရေးပြီး (ဘူး 6 ဘူး ယူသွားတယ်) commit လုပ်တယ်၊ B က 35 ကို ရေးပြီး (ဘူး 5 ဘူး ယူသွားတယ်) commit လုပ်တယ်။ OnHand ရဲ့ နောက်ဆုံး တန်ဖိုးနဲ့ ဖြစ်သင့်တဲ့ တန်ဖိုးကို State လုပ်ပါ၊ ပြဿနာကို identify (ဖြစ်နိုင်တဲ့ အဖြေတွေထဲက ရွေးပြီး ဖော်ပြပါ) လုပ်ပါ၊ ပြီးတော့ A ဖတ်ချိန်ကနေ A commit လုပ်ချိန်အထိ row ကို lock လုပ်ထားတဲ့ Isolation property က နောက်ဆုံး တန်ဖိုး မှန်လာအောင် ဒီအဆင့်တွေကို ဘယ်လို ပြောင်းစေလဲ explain လုပ်ပါ။

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

  1. [Challenge] Views (HL) [6 marks] တစ်ရက်ကို အကြိမ် 5000 လောက် ဖွင့်ကြည့်တဲ့ “top 100 customers this month” (ဒီလရဲ့ ထိပ်တန်း customer 100) report အတွက် reporting team တစ်ခုက virtual view သုံးသင့်လား materialised view သုံးသင့်လား Evaluate (အားသာချက်နဲ့ အားနည်းချက်တွေကို ချိန်ဆပြီး အကဲဖြတ်ပါ) လုပ်ပါ။ ဖတ်တဲ့ မြန်နှုန်း၊ freshness၊ storage နဲ့ refresh strategy (ဘယ်အချိန် ဘယ်လို refresh လုပ်မလဲ ဆိုတဲ့ နည်းဗျူဟာ) တို့ကို ကိုးကားပါ။

  2. [Challenge] Transactions (HL) [8 marks] ACID ကို တင်းတင်းကျပ်ကျပ် လိုက်နာတဲ့ relational database နဲ့ ပိုမြင့်တဲ့ write throughput (တစ်စက္ကန့်မှာ ရေးနိုင်တဲ့ အကြိမ်ရေ ပိုများခြင်း) ရဖို့ consistency အာမခံချက် ပိုအားနည်းတာကို လက်ခံတဲ့ NoSQL database ကြား ရွေးရတဲ့အခါ engineering team တစ်ခု ကြုံရတဲ့ trade-off (တစ်ခု ရဖို့ တစ်ခု လျှော့ရတာ) တွေကို Discuss (အမြင် အမျိုးမျိုးကို ချိန်ဆပြီး ဆွေးနွေးပါ) လုပ်ပါ။ တိကျတဲ့ property တွေနဲ့ ရွေးချယ်မှု တစ်ခုစီ သင့်တော်တဲ့ အခြေအနေတွေကို ကိုးကားပါ။

IB CS သင်တန်း တက်နေသူတွေအတွက် မှတ်ချက်: View တွေ (A3.3.5) နဲ့ ACID ပါတဲ့ transaction တွေ (A3.3.6) က HL အတွက်သာ ဖြစ်ပါတယ်။ A3.3.5 မှာ “view” ဆိုတာ database ထဲမှာ သိမ်းထားတဲ့ အရာ တစ်ခု (virtual ဒါမှမဟုတ် materialised) ဖြစ်ပြီး English စကားလုံး view ရဲ့ နေ့စဉ် အဓိပ္ပာယ် (မြင်ကွင်း၊ အမြင်) ထက် ပိုကျဉ်းပါတယ်။ ACID property တစ်ခုကို ရှင်းပြတဲ့အခါ နာမည် ပြောရုံနဲ့ မလုံလောက်ပါဘူး: အလုပ်လုပ်ပုံ (mechanism) နဲ့ ရလဒ် (consequence) ကို ပေးပါ။

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

  • အရင် လေ့လာထားရမယ့် ခေါင်းစဉ်: SQL Updates။ Transaction တစ်ခုက all-or-nothing unit တစ်ခုအဖြစ် စုပေါင်းပေးတဲ့ INSERT၊ UPDATE နဲ့ DELETE statement တွေပါ။
  • အရင် လေ့လာထားရမယ့် ခေါင်းစဉ်: SQL Queries။ View တွေက သိမ်းထားတဲ့ SELECT query တွေဖြစ်ပြီး တခြား query တွေနဲ့ syntax (code ရေးထုံး) အတူတူနဲ့ ရေးပါတယ်။
  • ဆက်စပ် ခေါင်းစဉ်: Data Types and Keys။ Consistency property က လိုက်နာစေတဲ့ constraint တွေပါ။
  • ဆက်စပ် ခေါင်းစဉ် (HL): Distributed Databases။ ACID ကို စက် အများကြားမှာ ပေးဖို့ အများကြီး ပိုခက်ပါတယ်။ ဒါကြောင့် distributed system (ကွန်ပျူတာ အများ ပေါင်းပြီး အလုပ်လုပ်တဲ့ စနစ်) တွေက စက်တွေကြားက network ပြတ်သွားတဲ့အခါ ဆက်အလုပ်လုပ်နိုင်ဖို့ အာမခံချက် တချို့ကို တခါတလေ စွန့်လွှတ်ကြပါတယ်။ ဒီလို network ပြတ်နေချိန်မှာ ဆက်အလုပ်လုပ်နိုင်တာကို partition tolerance လို့ ခေါ်ပြီး CAP theorem (distributed system တွေရဲ့ အာမခံချက် သုံးခုအကြောင်း သီအိုရီ) ရဲ့ အစိတ်အပိုင်း တစ်ခုပါ။
  • ဆက်စပ် ခေါင်းစဉ် (HL): Alternative Databases။ NoSQL database အများအပြားက scalability (server တွေ ထပ်ထည့်ပြီး ဒေတာ ပိုများများနဲ့ user ပိုများများကို ကိုင်တွယ်နိုင်မှု) ရဖို့ ပိုအားနည်းတဲ့ consistency ကို လက်ခံကြပါတယ်: ACID အစား BASE (ACID လောက် မတင်းကျပ်တဲ့ အာမခံချက် ပုံစံ) ကို သုံးကြပါတယ်။

© 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 နဲ့ တည်ဆောက်ထားပါတယ်။