Database Schemas (Database ဖွဲ့စည်းပုံ ဖော်ပြချက်များ)

A3.2.1: Describe database schemas (conceptual, logical, physical).
မြန်မာလို: database schema (database ဖွဲ့စည်းပုံ ဖော်ပြချက်) တွေကို ဖော်ပြရှင်းပြနိုင်ရပါမယ်: conceptual (လုပ်ငန်းက ဘာတွေကို မှတ်ထားချင်လဲ ပြတဲ့ အဆင့်)၊ logical (table၊ column၊ key နဲ့ type တွေကို ပြတဲ့ အဆင့်) နဲ့ physical (ဒေတာကို disk ပေါ်မှာ ဘယ်လို သိမ်းမလဲ ပြတဲ့ အဆင့်)။

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

Schema ဆိုတာ ဘာလဲ

Schema (database ဖွဲ့စည်းပုံ ဖော်ပြချက်) ဆိုတာ database (ဒေတာ သိမ်းဆည်းတဲ့ စနစ်) ရဲ့ ဖွဲ့စည်းပုံပါ။ ဘယ် table (database ထဲက ဇယား) တွေ ရှိလဲ၊ table တစ်ခုစီမှာ ဘယ် column (ဒေါင်လိုက် ကော်လံ) တွေ ပါလဲ၊ အဲဒီ column တွေက ဘယ် type တွေလဲ၊ ဘယ် column တွေက row (အလျားလိုက် အတန်း) တွေကို ခွဲခြားပေးလဲ၊ table တွေ အချင်းချင်း ဘယ်လို ချိတ်ဆက်နေလဲ ဆိုတာကို ပြတဲ့ blueprint (တည်ဆောက်ဖို့ ပုံစံ ပုံကြမ်း) ပါ။ Schema ထဲမှာ တကယ့် ဒေတာ ဘာမှ မပါပါဘူး၊ ဒေတာ ရောက်လာတဲ့အခါ ယူမယ့် ပုံသဏ္ဌာန် ကို ဖော်ပြတာပါ။

Database တစ်ခုကို ဒီဇိုင်းဆွဲတယ် ဆိုတာ row တစ်ကြောင်းမှ မသိမ်းခင် schema ကို အရင် ရေးဆွဲတာပါ။ ဒီအဆင့်ကို ကျော်လိုက်ရင် “database ကို ဘာကြောင့် သုံးတာလဲ” ဆွေးနွေးမှု တိုင်းမှာ ပြောလေ့ရှိတဲ့ ပြဿနာတွေ ဖြစ်လာပါတယ်: ခက်ခက်ခဲခဲ ပြန်ဒီဇိုင်းဆွဲရတာ၊ ဒေတာ မလိုအပ်ဘဲ ထပ်နေတာ၊ data integrity (ဒေတာ မှန်ကန်ပြီး မပျက်စီးဘဲ ရှိနေခြင်း) ပျက်သွားတာ။

Schema နဲ့ database ရဲ့ ဆက်စပ်မှုက ဗိသုကာ ပုံကြမ်းနဲ့ အဆောက်အအုံ ဆက်စပ်မှုလိုပါပဲ။ စာရွက်ပေါ်က ပုံကြမ်းကို ကုန်ကျစရိတ် နည်းနည်းနဲ့ ပြင်လို့ ရပါတယ်၊ အုတ်မြစ် ချပြီးသွားရင်တော့ ပြင်ရတာ မြန်မြန် ဈေးကြီးလာပါတယ်။ ကြမ်းကြမ်းတမ်းတမ်း ရေးထားတဲ့ မှားနေတဲ့ schema က ပထမနေ့မှာ အလုပ်လုပ်သလို ထင်ရပေမယ့် database ကြီးလာတဲ့ လပေါင်းများစွာ ကြာမှ ပြဿနာ ဖြစ်လာနိုင်ပါတယ်။

Schema အဆင့် သုံးဆင့်

Schema ကို ပုံမှန်အားဖြင့် အလွှာ သုံးလွှာ ခွဲပါတယ်။ အလွှာ တစ်ခုစီက database တစ်ခုတည်းကို ဖော်ပြပေမယ့် abstraction (မလိုတဲ့ အသေးစိတ်ကို ဖယ်ပြီး အဓိကကိုပဲ ကြည့်ခြင်း) အဆင့် မတူပါဘူး။ သုံးလွှာ ပေါင်းလိုက်တော့ “ဘာကို model လုပ်နေလဲ” (conceptual)၊ “database ထဲမှာ ဒေတာကို ဘယ်လို စီစဉ်ထားလဲ” (logical) နဲ့ “bit တွေ disk ပေါ်မှာ ဘယ်လို ရှိနေလဲ” (physical) ဆိုတာတွေကို ခွဲထားပေးပါတယ်။

Level (အဆင့်)	ဘာတွေ ပါလဲ	ပုံမှန် ထွက်လာတဲ့ ပစ္စည်း
Conceptual (လုပ်ငန်းရဲ့ အမြင်)	အမြင့်ဆုံး အဆင့် အမြင်: ဘယ် entity (database ထဲမှာ ဒေတာ သိမ်းမယ့် အရာ တစ်ခု) တွေ ရှိလဲ၊ သူတို့ကြား အဓိက relationship (table တွေကြား ဆက်နွယ်မှု) တွေက ဘာလဲ။ ဝေါဟာရကို ဦးစားပေးပြီး implementation (လက်တွေ့ တည်ဆောက်ပုံ) အသေးစိတ် မပါသလောက်ပါပဲ။	Entity နာမည်တွေပဲ ပါတဲ့ အမြင့်ဆုံး အဆင့် entity-relationship ပုံကြမ်း
Logical (table ဒီဇိုင်း)	Table၊ column၊ data type (ဒေတာ အမျိုးအစား)၊ primary key (row တစ်ခုချင်းကို ခွဲခြားပေးတဲ့ key)၊ foreign key (တခြား table ရဲ့ primary key ကို ညွှန်းတဲ့ column) နဲ့ normalisation (ဒေတာ ထပ်မနေအောင် table တွေကို စီစဉ်ခြင်း) လုပ်ထားတဲ့ ဖွဲ့စည်းပုံတို့ရဲ့ အသေးစိတ် အပြည့်အစုံ။ DBMS (database ကို စီမံပေးတဲ့ software) တစ်ခုခုပေါ် မမူတည်ပါဘူး။	Attribute တွေ ပါတဲ့ ERD (entity တွေနဲ့ ဆက်နွယ်မှုတွေကို ပြတဲ့ ပုံ) နဲ့ normalise လုပ်ထားတဲ့ relational model
Physical (disk ပေါ်မှာ သိမ်းပုံ)	အဲဒီ table တွေကို တကယ် ဘယ်လို သိမ်းထားလဲ: file layout (file ထဲမှာ ဒေတာ စီထားပုံ)၊ index (ရှာတာ မြန်အောင် လုပ်ထားတဲ့ ညွှန်းစာရင်း)၊ partitioning (database ကို အပိုင်းတွေ ခွဲသိမ်းခြင်း)၊ page size (disk ပေါ်က ဒေတာ အကွက် တစ်ကွက်ရဲ့ အရွယ်)၊ storage engine (ဒေတာကို disk ပေါ် တကယ် သိမ်းပေးတဲ့ DBMS အစိတ်အပိုင်း) နဲ့ disk ပေါ်က ပုံစံ။ DBMS နဲ့ hardware ပေါ် မူတည်ပါတယ်။	`CREATE INDEX` ပါတဲ့ DDL (database ဖွဲ့စည်းပုံကို သတ်မှတ်တဲ့ SQL အပိုင်း) statement တွေ၊ tablespace (table တွေ သိမ်းတဲ့ disk နေရာ) သတ်မှတ်ချက်တွေ၊ storage parameter (သိမ်းပုံ setting) တွေ

မှတ်ရလွယ်တဲ့ နည်း: conceptual = “what” (ဘာ) / logical = “how” (ဘယ်လို) / physical = “where and how fast” (ဘယ်မှာ၊ ဘယ်လောက် မြန်မြန်)။

Conceptual Schema (“ဘာ” ကို ပြတဲ့ အဆင့်)

Conceptual schema (လုပ်ငန်းက ဘာတွေကို မှတ်ထားချင်လဲ ပြတဲ့ schema) က database ရဲ့ အမြင့်ဆုံး အဆင့်၊ လုပ်ငန်းဘက်က ကြည့်တဲ့ ပုံကို ပေးပါတယ်။ ဒီလို မေးခွန်းတွေကို ဖြေပါတယ်:

မှတ်ထားဖို့ လိုတဲ့ အဓိက အရာတွေက ဘာတွေလဲ။ ဥပမာ: Member, Class, Booking။
သူတို့ အချင်းချင်း အကြမ်းအားဖြင့် ဘယ်လို ဆက်စပ်နေလဲ။ ဥပမာ: Member တွေက booking (ကြိုတင် စာရင်းသွင်းခြင်း) တွေ လုပ်တယ်၊ class တွေမှာ booking တွေ ရှိတယ်။

Conceptual schema က:

Entity တွေကို နာမည်ပေးပါတယ်၊ ဒါပေမယ့် attribute (record တိုင်းမှာ ပါတဲ့ အချက်အလက် တစ်ခု) တိုင်းကို စာရင်း မပြုရသေးပါဘူး
အဓိက relationship တွေကို လုပ်ငန်း စကားနဲ့ ဖော်ပြပါတယ် (ဥပမာ “booking တစ်ခုစီကို member တစ်ယောက်တည်းက လုပ်တယ်”)၊ key တွေ၊ column တွေ မပါပါဘူး
DBMS-independent (ဘယ် DBMS ကိုမှ မမှီခိုတဲ့) ဖြစ်ပါတယ်: MySQL ကနေ PostgreSQL ကို ပြောင်းလိုက်ရင်တောင် ဒီမှာ ဘာမှ မပြောင်းပါဘူး
ရိုးရိုး လုပ်ငန်း စကားနဲ့ ရေးထားလို့ နည်းပညာ နောက်ခံ မရှိတဲ့ stakeholder (စနစ်နဲ့ သက်ဆိုင်သူ) တွေနဲ့ ဆွေးနွေးရ လွယ်ပါတယ်

ကျောင်းအုပ်ကြီး၊ အသင်း မန်နေဂျာ ဒါမှမဟုတ် လုပ်ငန်းရှင် တစ်ယောက်က database နောက်ခံ ဗဟုသုတ မရှိဘဲ ဖတ်နိုင်တဲ့ စာမျက်နှာ တစ်မျက်နှာစာ ပုံကြမ်း တစ်ခုလို့ မြင်ကြည့်ပါ။

Logical Schema (“ဘယ်လို” ကို ပြတဲ့ အဆင့်)

Logical schema (table၊ column၊ key နဲ့ type တွေကို အပြည့်အစုံ ပြတဲ့ schema) က database ကို တကယ် တည်ဆောက်ဖို့ လိုတဲ့ ဖွဲ့စည်းပုံ အသေးစိတ် အားလုံးကို ဖြည့်ပေးပါတယ်၊ ဒါပေမယ့် သီးခြား storage နည်းပညာ တစ်ခုကို မရွေးရသေးပါဘူး။ ဒါတွေကို ပြပါတယ်:

Table ဖြစ်လာမယ့် entity တိုင်း
Table တစ်ခုစီရဲ့ attribute (column) အားလုံးနဲ့ သူတို့ရဲ့ data type တွေ
Table တစ်ခုစီရဲ့ primary key
Foreign key တိုင်းနဲ့ အဲဒါ ညွှန်းထားတဲ့ table
Foreign key တွေနဲ့ ဖော်ပြထားတဲ့ relationship တွေ၊ key တွေနဲ့ constraint (column ထဲ ထည့်တဲ့ ဒေတာ လိုက်နာရမယ့် စည်းမျဉ်း) တွေက ဖော်ပြတဲ့ cardinality (ဆက်နွယ်မှု တစ်ဖက်စီရဲ့ အများဆုံး အရေအတွက်: 1:1, 1:M) နဲ့ modality (ဆက်နွယ်မှုမှာ မဖြစ်မနေ ပါရမလား ဆိုတာ: mandatory ဒါမှမဟုတ် optional) တို့နဲ့အတူ။ M:M relationship ကိုတော့ junction table (many-to-many ဆက်နွယ်မှုကို ဖြေရှင်းပေးတဲ့ ကြားခံ table) တစ်ခုနဲ့ ဖြေရှင်းပါတယ်။
Normalisation ရဲ့ ရလဒ်၊ ပုံမှန်အားဖြင့် 3NF (normalisation ရဲ့ တတိယ အဆင့်) အထိ အပြည့်အစုံ ရောက်တဲ့ ဖွဲ့စည်းပုံ

Logical schema က database designer တစ်ယောက်က database ကို တည်ဆောက်မယ့် developer တွေဆီ လွှဲပေးတဲ့ ဒီဇိုင်းပါ။ DBMS-independent ဖြစ်ပါတယ်: logical schema တစ်ခုတည်းကို MySQL၊ PostgreSQL၊ SQL Server ဒါမှမဟုတ် Oracle မှာ type နာမည် အနည်းငယ်ကိုပဲ ပြောင်းပြီး တည်ဆောက်နိုင်ပါတယ် (ဥပမာ SQL Server က ရက်စွဲနဲ့ အချိန် column ကို DATETIME2 လို့ ခေါ်ပါတယ်)။

Physical Schema (“ဘယ်မှာ၊ ဘယ်လောက် မြန်မြန်” ကို ပြတဲ့ အဆင့်)

Physical schema (ဒေတာကို disk ပေါ်မှာ ဘယ်လို သိမ်းမလဲ ပြတဲ့ schema) က storage medium (ဒေတာ သိမ်းတဲ့ ပစ္စည်း) ပေါ်မှာ ဒေတာကို ဘယ်လို စီထားလဲ ဆိုတာကို ဖော်ပြပါတယ်။ ရွေးထားတဲ့ DBMS နဲ့ စနစ်က လိုအပ်တဲ့ performance (စွမ်းဆောင်ရည်) ဂုဏ်သတ္တိတွေပေါ် မူတည်ပါတယ်။ ဒါတွေ ပါပါတယ်:

Row တွေကို disk ပေါ်မှာ ဘယ်လို စီထားလဲ: heap file (row တွေကို အစဉ်မစီဘဲ သိမ်းထားတဲ့ file)၊ clustered index (row တွေကို key အစဉ်အတိုင်း သိမ်းထားတဲ့ index) ဒါမှမဟုတ် columnar storage (column အလိုက် ခွဲသိမ်းခြင်း)
ဘယ် column တွေမှာ index ရှိလဲ (index က ဖတ်တာကို မြန်စေပေမယ့် ရေးတာကို နှေးစေပါတယ်)
Partitioning: table ကြီး တစ်ခုကို file အများ ဒါမှမဟုတ် စက် အများမှာ ခွဲထားခြင်း
Storage engine အမျိုးမျိုး ပေးတဲ့ DBMS တွေမှာ ဘယ် storage engine ကို ရွေးမလဲ (ဥပမာ MySQL မှာ InnoDB နဲ့ MyISAM)
Page size၊ fill factor (page တစ်ခုကို ဘယ်လောက် ပြည့်အောင် ဖြည့်မလဲ)၊ compression (ဒေတာ ချုံ့ခြင်း) ရွေးချယ်စရာတွေနဲ့ tablespace ကို ဘယ်မှာ ထားမလဲ
Replication (ဒေတာ copy တွေကို နေရာ အများမှာ ထားခြင်း) နဲ့ backup (အရန် မိတ္တူ) စီစဉ်ပုံ

Logical schema တူတဲ့ database နှစ်ခုမှာ physical schema တွေ အလွန် ကွာခြားနိုင်ပါတယ်။ ဥပမာ တစ်ခုကို embedded system (စက်ပစ္စည်း တစ်ခုထဲမှာ ထည့်ထားတဲ့ ကွန်ပျူတာ စနစ်) သေးသေးလေးအတွက် ညှိထားပြီး နောက်တစ်ခုကို user သန်းပေါင်းများစွာကို ဝန်ဆောင်ပေးတဲ့ လူသုံးများတဲ့ web platform အတွက် ညှိထားနိုင်ပါတယ်။ အဲဒီ database နှစ်ခုက လက်တွေ့မှာ အလုပ်လုပ်ပုံ အများကြီး ကွာပါတယ်။

အဆင့် သုံးဆင့်ကို အတူတကွ ကြည့်ခြင်း

Conceptual schema ဘာကို model လုပ်လဲ

ဘယ် entity တွေ၊ ဘယ် relationship တွေ ရှိလဲ။

Member, Class, Booking
Member တွေက Booking တွေ လုပ်တယ်
Class တွေမှာ Booking တွေ ရှိတယ်

↓

Logical schema ဘယ်လို စီစဉ်လဲ

ဘယ် table၊ column၊ key၊ type တွေလဲ။

MEMBER(MemberID, FirstName, Surname, DateOfBirth, MembershipTier)
CLASS(ClassID, Title, Coach, StartsAt)
BOOKING(BookingID, MemberID*, ClassID*, BookedOn, Status)
* = foreign key

↓

Physical schema ဘယ်မှာ၊ ဘယ်လောက် မြန်မြန်

Disk ပေါ်မှာ ဘယ်လို သိမ်းလဲ။

InnoDB storage engine၊ 16 KB page တွေ
Table တစ်ခုစီကို primary key အစဉ်အတိုင်း သိမ်းတယ် (clustered index)
BOOKING(BookedOn) ပေါ်မှာ secondary index
MEMBER(Surname, FirstName) ပေါ်မှာ secondary index
ညတိုင်း off-site storage (တခြား နေရာမှာ ရှိတဲ့ storage) ဆီ backup လုပ်တယ်

ပုံထဲက secondary index ဆိုတာ primary key မဟုတ်တဲ့ column တွေပေါ်မှာ ထပ်လုပ်ထားတဲ့ index ပါ။

အောက်က အဆင့် တစ်ခုစီက သူ့အပေါ်က အဆင့်ကို အသေးစိတ် ထပ်ဖြည့်ပါတယ်။ အပေါ်က အဆင့် တစ်ခုစီက အောက်က ရွေးချယ်မှုတွေပေါ် မမူတည်ပါဘူး: MySQL ကနေ PostgreSQL ကို ပြောင်းရင် physical schema က လုံးဝ ပြောင်းသွားပြီး conceptual schema က မပြောင်းပါဘူး၊ logical schema မှာတော့ အများဆုံး type နာမည် အနည်းငယ်ပဲ ပြောင်းပါတယ်။ Designer တွေက ပုံမှန်အားဖြင့် ဒီအစဉ်အတိုင်း အလုပ်လုပ်ပါတယ်: conceptual အရင်၊ ပြီးရင် logical၊ ပြီးမှ physical။

အလွှာ သုံးလွှာ ဘာကြောင့် ခွဲထားလဲ

အလွှာ သုံးလွှာ ခွဲထားရတာက မတူတဲ့ နှုန်းတွေနဲ့ ပြောင်းလဲပြီး မတူတဲ့ လူတွေ ဂရုစိုက်တဲ့ ကိစ္စတွေကို ခွဲထားပေးလို့ပါ:

လုပ်ငန်းက conceptual schema ကို ပြောင်းပါတယ်: entity အသစ် တစ်ခု ထည့်တဲ့အခါမျိုးပါ (“အခု Trainer တွေကိုပါ မှတ်ထားမယ်”)။ ဒါက model ကို ပြန်ဆွဲရလို့ ရှားပါတယ်။
Database designer က logical schema ကို ပြောင်းပါတယ်: table တွေကို ပြန်စီစဉ်တဲ့အခါ ဒါမှမဟုတ် field (record တစ်ခုထဲက အချက်အလက် တစ်ကွက်) အသစ်တွေ ထည့်တဲ့အခါမျိုးပါ။ ဒါက ပိုဖြစ်လေ့ ရှိပေမယ့် တမင် စဉ်းစားပြီးမှ လုပ်တာပါ။
DBA (database ကို ထိန်းသိမ်း စီမံတဲ့ တာဝန်ခံ) က physical schema ကို ပြောင်းပါတယ်: index ထည့်တာ၊ partition ပြန်ခွဲတာ၊ storage engine ပြောင်းတာလို performance ညှိတဲ့အခါမျိုးပါ။ User တွေ သတိမထားမိဘဲ ဖြစ်နိုင်ပါတယ်။

ဒီလို မခွဲထားရင် performance ကို နည်းနည်း ညှိတိုင်း လုပ်ငန်းဘက်က model ကို ထိခိုက်ပြီး လုပ်ငန်းက ပြောင်းလဲမှု တိုင်းအတွက် storage အလွှာကို ပြန်ရေးရပါလိမ့်မယ်။

Schema တွေ ဘာကြောင့် အရေးကြီးလဲ (Data Modelling)

Data modelling (ဒေတာ model ကို ဒီဇိုင်းဆွဲခြင်း) ဆိုတာ schema ကို ထုတ်ပေးတဲ့ ဒီဇိုင်း အလုပ်ပါ: ဒေတာ တစ်ခုမှ မသိမ်းခင် database က ဘာတွေကို မှတ်မလဲ၊ သူ့ table တွေ ဘယ်လို ချိတ်ဆက်မလဲ ဆုံးဖြတ်တာပါ။

Model ကို အရင် ဆွဲရတဲ့ အခိုင်မာဆုံး အကြောင်းရင်းက နောက်မှ စိတ်ပြောင်းရင် ကုန်ကျမယ့် စရိတ်ပါ။ ပုံကို ပြန်ဆွဲတာ မိနစ်ပိုင်းပဲ ကြာပါတယ်။ Database ထဲမှာ တစ်နှစ်စာ record (အချက်အလက် အများကြီး စုထားတဲ့ ဒေတာ တစ်ခု) တွေ ရှိနေပြီး program အများက အဲဒီကနေ ဖတ်နေပြီဆိုရင်တော့ အဲဒီ အပြောင်းအလဲ တစ်ခုတည်းအတွက် သိမ်းထားတဲ့ row တိုင်းကို table အသစ်တွေထဲ ရွှေ့ရပြီး သူတို့ကို သုံးတဲ့ query (database ထဲက ဒေတာကို ရှာ၊ ပြင်ဖို့ ပေးတဲ့ အမိန့်) တွေနဲ့ screen တွေကို ပြန်ရေးရပါတယ်၊ ဒါကိုလည်း လူတွေ စနစ်ကို ဆက်သုံးနေတုန်းမှာ လုပ်ရပါတယ်။

Model က ပါဝင်သူ အားလုံးကို စစ်ကြည့်ဖို့ ပုံ တစ်ခုတည်းကိုလည်း ပေးပါတယ်။ Member၊ class နဲ့ booking တွေရဲ့ ပုံကို ဖတ်တဲ့ အသင်း မန်နေဂျာ တစ်ယောက်က table တစ်ခုမှ မရှိခင်မှာပဲ ဘယ် coach (နည်းပြ) က ဘယ် class ကို ဦးဆောင်ခွင့် ရှိလဲ ဆိုတာကိုပါ အသင်းက မှတ်ထားဖို့ လိုတယ်လို့ ထောက်ပြနိုင်ပါတယ်။ Developer က အဲဒီ ပုံ တစ်ခုတည်းကနေ တည်ဆောက်ပြီး project ထဲ နောက်ထပ် ဝင်လာမယ့် developer ကလည်း အဲဒီ ပုံကနေပဲ တည်ဆောက်ပါတယ်။

အလုပ် အများစုက ဒီဇိုင်း မေးခွန်း အနည်းငယ်ကို ကံကြမ္မာအတိုင်း မထားဘဲ တမင် စဉ်းစားပြီး ဖြေတာပါ:

လူတွေက ဘာကို သိချင်ကြမလဲ။ အဖွဲ့အစည်း တစ်ခုက အဖြေ လိုတဲ့ မေးခွန်းတွေက ဘယ်အရာတွေ table ဖြစ်မလဲ၊ table တစ်ခုစီက ဘယ် အသေးစိတ်တွေကို သိမ်းမလဲ ဆိုတာကို ဆုံးဖြတ်ပါတယ်။ Harbour Run အားကစား အသင်းက ဘယ် member တွေ လာတက်တာ ရပ်သွားပြီလဲ သိချင်ရင် booking တစ်ခုစီမှာ member လာခဲ့လား ဆိုတာကို မှတ်ရပါမယ်၊ ဒီမေးခွန်းတွေထဲက ဘယ်မေးခွန်းကမှ မလိုတဲ့ အသေးစိတ်ကိုတော့ ချန်ထားလို့ ရပါတယ်။
Table တွေ ဘယ်လို ချိတ်ဆက်မလဲ။ အခု ရွေးထားတဲ့ key တွေနဲ့ relationship တွေက နောက်ပိုင်းမှာ table တွေကို join (table တွေကို ချိတ်ပြီး ဒေတာ ပေါင်းယူခြင်း) လုပ်ပြီး ဘယ် မေးခွန်းတွေကို ဖြေနိုင်မလဲ ဆုံးဖြတ်ပါတယ်၊ ဥပမာ ပြီးခဲ့တဲ့ လက class တစ်ခုစီ ဘယ်လောက် ပြည့်ခဲ့လဲ ဆိုတာမျိုးပါ။
အချက် တစ်ခုစီက ဘယ်မှာ ရှိမလဲ။ အချက် တစ်ခုစီကို နေရာ တစ်ခုတည်းမှာ သိမ်းအောင် table တွေကို စီစဉ်ထားရင် အဲဒီ အချက်ရဲ့ copy တွေ အချင်းချင်း မကိုက်ညီ ဖြစ်တာကို တားပေးပါတယ်။ ဒီအကြောင်းကို Normalisation (ဒေတာ ထပ်မနေအောင် table တွေကို စီစဉ်ခြင်း) မှာ လေ့လာနိုင်ပါတယ်။

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

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

ဥပမာ 1: Database တစ်ခု၊ Schema သုံးခု

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

Conceptual schema (မန်နေဂျာ တစ်ယောက်က အတည်ပြု လက်မှတ်ထိုးမယ့် စာပိုဒ် တစ်ပိုဒ်စာ လုပ်ငန်း ဖော်ပြချက်):

စနစ်က အသင်းရဲ့ member တွေ၊ coach တွေ ဦးဆောင်တဲ့ class တွေနဲ့ member တွေကို class တွေနဲ့ ချိတ်ပေးတဲ့ booking တွေကို မှတ်ထားပါတယ်။ Member တစ်ယောက်က class အများကို booking လုပ်နိုင်ပါတယ်၊ class တစ်ခုကိုလည်း member အများက booking လုပ်နိုင်ပါတယ်။ Booking တစ်ခုက member တစ်ယောက်တည်းနဲ့ class တစ်ခုတည်းနဲ့ပဲ အမြဲ သက်ဆိုင်ပါတယ်။ Booking တွေကို သတ်မှတ်ထားတဲ့ ရက်စွဲ တစ်ခုမှာ လုပ်ပြီး status (အခြေအနေ) တစ်ခု ရှိပါတယ်: confirmed (အတည်ပြုပြီး)၊ cancelled (ပယ်ဖျက်ပြီး)၊ attended (လာတက်ခဲ့)၊ no-show (မလာခဲ့)။

ဒီမှာ column၊ type ဒါမှမဟုတ် storage အကြောင်း ဘာမှ မပြောတာကို သတိပြုပါ။ လုပ်ငန်း စကားနဲ့ ရေးထားတဲ့ entity တွေနဲ့ relationship တွေ အကြောင်းသက်သက်ပါ။

Logical schema (DBMS-independent ဖြစ်ပြီး တည်ဆောက်ဖို့ အသင့်):

Table	Column များ	မှတ်ချက်
`MEMBER`	`MemberID` (INT, PK), `FirstName` (VARCHAR 50), `Surname` (VARCHAR 50), `DateOfBirth` (DATE), `MembershipTier` (VARCHAR 20)
`CLASS`	`ClassID` (VARCHAR 8, PK), `Title` (VARCHAR 80), `Coach` (VARCHAR 60), `StartsAt` (TIMESTAMP)
`BOOKING`	`BookingID` (VARCHAR 8, PK), `MemberID` (INT, FK -> MEMBER), `ClassID` (VARCHAR 8, FK -> CLASS), `BookedOn` (DATE), `Status` (VARCHAR 20)	MEMBER နဲ့ CLASS ကြား M:M relationship ကို ဖြေရှင်းပေးတဲ့ junction table

PK က primary key၊ FK က foreign key ပါ။

Physical schema (အသင်းရဲ့ Linux server သေးသေးလေးပေါ်က MySQL အတွက်ပဲ သီးသန့်):

- Storage engine: InnoDB (transactional, supports foreign keys)
- Default page size: 16 KB
- Indexes:
    PRIMARY KEY on each table (auto-clustered by InnoDB)
    Secondary index on MEMBER(Surname, FirstName) for member search
    Secondary index on BOOKING(BookedOn) for daily booking reports
    Composite index on BOOKING(MemberID, BookedOn) for "my bookings" queries
- Backup: nightly mysqldump to off-site cloud bucket
- Replication: none initially (single-server deployment)

Block ထဲက အချက်တွေရဲ့ အဓိပ္ပာယ်:

Storage engine: InnoDB (transaction တွေနဲ့ foreign key တွေကို ထောက်ပံ့တယ်)
Default page size: 16 KB
Index တွေ: table တိုင်းမှာ PRIMARY KEY (InnoDB က အလိုအလျောက် cluster လုပ်ပေးတယ်)၊ member ရှာဖို့ MEMBER(Surname, FirstName) ပေါ်မှာ secondary index၊ နေ့စဉ် booking report တွေအတွက် BOOKING(BookedOn) ပေါ်မှာ secondary index၊ “my bookings” (ကိုယ့် booking များ) query တွေအတွက် BOOKING(MemberID, BookedOn) ပေါ်မှာ composite index (column အများပေါ်မှာ လုပ်ထားတဲ့ index)
Backup: ညတိုင်း mysqldump (MySQL database ကို file အဖြစ် ထုတ်ပေးတဲ့ tool) နဲ့ off-site cloud bucket (တခြား နေရာမှာ ရှိတဲ့ cloud storage) ထဲကို
Replication: အစပိုင်းမှာ မလုပ်သေးဘူး (server တစ်လုံးတည်းနဲ့ run တယ်)

ဥပမာ 2: Logical schema တစ်ခုတည်း၊ physical implementation နှစ်မျိုး

တစ်နိုင်ငံလုံးမှာ အသင်းခွဲတွေ ရှိတဲ့ အားကစား အသင်း အုပ်စု တစ်ခုက နေရာတိုင်းမှာ software တစ်ခုတည်းကို run ပါတယ်။ အသင်း 200 လုံးအတွက် logical schema က အတူတူပါပဲ။ Physical schema ကတော့ အစွန်းဆုံး နှစ်ဖက်ကြားမှာ အများကြီး ကွာပါတယ်:

ရွာက အသင်း သေးသေးလေး၊ member 80၊ server တစ်လုံး:

မျှသုံးတဲ့ Linux စက် တစ်လုံးပေါ်မှာ MySQL instance (run နေတဲ့ MySQL server program) တစ်ခုတည်း
Partitioning မလုပ်ပါ၊ BOOKING table တစ်ခုလုံးက file တစ်ခုတည်းပါ
Index စုစုပေါင်း သုံးခု
နေ့စဉ် file နဲ့ backup လုပ်တယ်၊ ပြန်ဆယ်ယူချိန် (recovery time) က နာရီ ပိုင်း ကြာပေမယ့် လက်ခံနိုင်ပါတယ်

နိုင်ငံလုံးဆိုင်ရာ ရုံးချုပ်ရဲ့ report ထုတ်တဲ့ database၊ member 1.2 သန်း၊ တစ်နှစ်ကို booking 40 သန်း:

စက် သုံးလုံး ပေါင်းပြီး cluster (စက် အများ အဖွဲ့လိုက် အလုပ်လုပ်ခြင်း) ဖွဲ့ထားတဲ့ PostgreSQL စနစ်
BOOKING ကို နှစ်အလိုက် partition လုပ်ထားလို့ range query (တန်ဖိုး အပိုင်းအခြား တစ်ခုအတွင်း ရှာတဲ့ query) တွေ မြန်တယ်
အသုံးအများဆုံး report တွေအတွက် covering index (query လိုတဲ့ column အားလုံး ပါပြီးသား index) တွေ အပါအဝင် index ရှစ်ခု
Hot standby (ပင်မ server ပျက်ရင် ချက်ချင်း အစားဝင်ဖို့ အသင့် run ထားတဲ့ server) ဆီကို ပြောင်းလဲမှုတွေကို ဆက်တိုက် ကူးပို့တဲ့ streaming replication
Read replica (ဖတ်ဖို့ သက်သက် ထားတဲ့ database copy) တွေက dashboard တွေကို ဒေတာ ပေးလို့ primary server က ရေးတဲ့ အလုပ်အတွက် အားနေပါတယ်

Conceptual schema နဲ့ logical schema တွေ အတူတူ၊ physical schema တွေ လုံးဝ မတူ။ ဒါက အလွှာ သုံးလွှာ model ကို ကိုင်တွယ်ဖို့ ဒီဇိုင်းဆွဲခဲ့တဲ့ အခြေအနေ အတိအကျပါ။

ဥပမာ 3: “ဘာ” နဲ့ “ဘယ်လို” ကို ခွဲခြားခြင်း

မြို့ တစ်မြို့ရဲ့ tram (မြို့တွင်း ဓာတ်ရထား) စနစ်က ခရီးသွား ကတ်တွေအတွက် database တစ်ခု ဒီဇိုင်းဆွဲနေပါတယ်။ အောက်ပါ ဒီဇိုင်း ဆုံးဖြတ်ချက်တွေကို မှန်ကန်တဲ့ schema အလွှာအလိုက် ခွဲပါ:

ဆုံးဖြတ်ချက်	အလွှာ
“စနစ်က ခရီးသွား ကတ်တွေ၊ tram မှတ်တိုင်တွေနဲ့ ကတ် တစ်ခုစီနဲ့ သွားခဲ့တဲ့ ခရီးစဉ်တွေအကြောင်း သိဖို့ လိုတယ်။”	Conceptual
“`Journey` table မှာ `JourneyID`, `CardID`, `StartStopID`, `EndStopID`, `StartedAt` နဲ့ `Fare` column တွေ ပါမယ်။”	Logical
“တစ်နေ့ကို ခရီးစဉ် တစ်သန်းခန့် ထပ်တိုးလာပြီး ခရီးစဉ် အဟောင်းတွေကို မပြင်တော့လို့ `Journey` table ကို disk ပေါ်မှာ compress (ချုံ့) လုပ်ပြီး သိမ်းမယ်။”	Physical
“ခရီးစဉ် တစ်ခုစီကို ခရီးသွား ကတ် တစ်ခုတည်းနဲ့ သွားပြီး ကတ် တစ်ခုကို ခရီးစဉ် အများအတွက် သုံးနိုင်တယ်။”	Conceptual (အမြင့်ဆုံး အဆင့်က relationship)
“`Journey.Fare` က `DECIMAL(5, 2)` ဖြစ်မယ်၊ ပြီးတော့ ခရီးစဉ် တိုင်းမှာ စတင်ချိန် ရှိရမယ် (`StartedAt` က NOT NULL)။”	Logical
“ပင်မ server ပျက်ရင်လည်း ခရီးစဉ်တွေကို ဆက်မှတ်နိုင်အောင် database ကို မြို့ရဲ့ တခြား နေရာက ဒုတိယ server တစ်လုံးဆီ replicate လုပ်ပြီး ပြောင်းလဲမှု တိုင်းကို စက္ကန့်ပိုင်းအတွင်း ကူးပေးမယ်။”	Physical

စိတ်ချရတဲ့ စစ်နည်း: ဆုံးဖြတ်ချက်က လုပ်ငန်းက ဘာတွေကို မှတ်ထားချင်လဲ ဆိုတာကို ဖော်ပြရင် conceptual ပါ။ ဒေတာကို table၊ column၊ key နဲ့ type တွေအဖြစ် ဘယ်လို စီစဉ်ထားလဲ ဆိုတာကို ဖော်ပြရင် logical ပါ။ Performance နဲ့ reliability (ယုံကြည်စိတ်ချရမှု) အတွက် ဒေတာကို ဘယ်လို သိမ်းလဲ၊ copy ကူးထားလဲ၊ ညှိထားလဲ ဆိုတာကို ဖော်ပြရင် physical ပါ။

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

Q1. Schema ဆိုတဲ့ term ကို အကောင်းဆုံး အဓိပ္ပာယ် ဖွင့်ထားတာ ဘယ်ဟာလဲ။

Q2. Column နာမည်တွေ ဒါမှမဟုတ် data type တွေကို မပြဘဲ အဓိက entity တွေနဲ့ သူတို့ကြား အဓိက relationship တွေကို ဖော်ပြတဲ့ schema အဆင့်က ဘယ်ဟာလဲ။

Q3. Query တွေ မြန်လာအောင် မကြာခဏ ရှာတဲ့ column တစ်ခုပေါ်မှာ B-tree index (ရှာတာ မြန်အောင် tree ပုံစံနဲ့ စီထားတဲ့ index) ထည့်တာက ဘယ် schema အဆင့်မှာ လုပ်တဲ့ ဆုံးဖြတ်ချက်လဲ။

Q4. Logical schema ရဲ့ ဝိသေသ မဟုတ်တာ က ဘယ်ဟာလဲ။

Q5. Schema အဆင့် သုံးဆင့်ကို ပုံမှန်အားဖြင့် ဘယ်အစဉ်နဲ့ ဒီဇိုင်းဆွဲသလဲ။

ဆုံးဖြတ်ချက် တစ်ခုစီကို ခွဲခြားခြင်း

ဒီဇိုင်း ဆုံးဖြတ်ချက် တစ်ခုစီက ဘယ် schema အလွှာနဲ့ ဆိုင်လဲ ဖော်ပြပါ။ conceptual၊ logical ဒါမှမဟုတ် physical ကို English လို ရိုက်ထည့်ပါ။

ဆုံးဖြတ်ချက်	Schema အလွှာ
"စနစ်က Patient (လူနာ)၊ Doctor (ဆရာဝန်) နဲ့ Appointment (ချိန်းဆိုမှု) တွေကို မှတ်ထားတယ်။"
`Appointment.DurationMinutes` က `INT` type ဖြစ်ပြီး တန်ဖိုး အပေါင်း ဖြစ်ရမယ်ဆိုတဲ့ CHECK constraint ပါမယ်။
နေ့စဉ် အချိန်ဇယား query တွေ မြန်လာအောင် `(DoctorID, AppointmentDate)` ပေါ်မှာ covering index တစ်ခု ထည့်မယ်။
`Patient` ရဲ့ primary key က `PatientID` ဖြစ်မယ်။
Doctor တစ်ယောက်မှာ Appointment အများ ရှိနိုင်တယ်၊ Appointment တစ်ခုကို Doctor တစ်ယောက်တည်းက ဆောင်ရွက်တယ်။
Record အဟောင်းတွေကို ပိုနှေးတဲ့ archive (ရေရှည် သိမ်းဆည်းရာ) disk တွေပေါ်မှာ ထားနိုင်အောင် `Appointment` table ကို လအလိုက် partition လုပ်မယ်။

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

Three-schema architecture (schema သုံးဆင့် ဖွဲ့စည်းပုံ) ရဲ့ ဖော်ပြချက်ကို ပြည့်စုံအောင် ဖြည့်ပါ။ စာကြောင်းတွေက English လို ဖြစ်လို့ ကွက်လပ်တွေကို English စကားလုံးနဲ့ ရိုက်ထည့်ပါ။

THREE-SCHEMA ARCHITECTURE
=========================
The  schema is the high-level view: it identifies
the main entities and the main relationships, in business language.

The  schema shows full detail of tables, columns,
data types, primary keys, and foreign keys, but is DBMS-independent.

The  schema describes how the data is stored on
disk: file layout, indexes, partitioning, and storage engine.

The three are usually designed in the order
 ->  -> .

စာကြောင်းတွေရဲ့ အဓိပ္ပာယ် (____ က ကွက်လပ်ပါ):
THREE-SCHEMA ARCHITECTURE (schema သုံးဆင့် ဖွဲ့စည်းပုံ)
____ schema က အမြင့်ဆုံး အဆင့် အမြင်ပါ: အဓိက entity တွေနဲ့ အဓိက relationship တွေကို လုပ်ငန်း စကားနဲ့ ဖော်ပြပါတယ်။
____ schema က table၊ column၊ data type၊ primary key နဲ့ foreign key တွေကို အသေးစိတ် အပြည့်အစုံ ပြပေမယ့် DBMS-independent ဖြစ်ပါတယ်။
____ schema က ဒေတာကို disk ပေါ်မှာ ဘယ်လို သိမ်းလဲ ဖော်ပြပါတယ်: file layout၊ index၊ partitioning နဲ့ storage engine။
သုံးခုကို ပုံမှန်အားဖြင့် ____ -> ____ -> ____ အစဉ်နဲ့ ဒီဇိုင်းဆွဲပါတယ်။

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

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

1A schema is the structure of the database, not the data itself 2The conceptual schema names entities and main relationships without column-level detail 3The logical schema is DBMS-specific because it picks the storage engine and indexes 4The physical schema covers indexes, partitioning, and how rows are stored on disk 5The three schemas are usually designed conceptual -> logical -> physical

Line တွေရဲ့ အဓိပ္ပာယ်: (1) schema က database ရဲ့ ဖွဲ့စည်းပုံ ဖြစ်ပြီး ဒေတာ ကိုယ်တိုင် မဟုတ်ဘူး၊ (2) conceptual schema က column အဆင့် အသေးစိတ် မပါဘဲ entity တွေနဲ့ အဓိက relationship တွေကို နာမည်ပေးတယ်၊ (3) logical schema က storage engine နဲ့ index တွေကို ရွေးလို့ DBMS တစ်ခုနဲ့ပဲ ဆိုင်တယ်၊ (4) physical schema မှာ index၊ partitioning နဲ့ row တွေကို disk ပေါ်မှာ ဘယ်လို သိမ်းလဲ ဆိုတာ ပါတယ်၊ (5) schema သုံးခုကို ပုံမှန်အားဖြင့် conceptual -> logical -> physical အစဉ်နဲ့ ဒီဇိုင်းဆွဲတယ်။

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

အလွှာကို ခွဲခြားသိခြင်း

"Database က Book (စာအုပ်)၊ Member နဲ့ Loan (ငှားမှု) တွေကို မှတ်ထားတယ်။ Loan တစ်ခုစီမှာ Book တစ်အုပ်တည်းနဲ့ Member တစ်ယောက်တည်း ပါတယ်။ Member တစ်ယောက်မှာ Loan အများ ရှိနိုင်တယ်၊ Book တစ်အုပ်ကလည်း အချိန်ကြာလာတာနဲ့အမျှ Loan အများမှာ ပါနိုင်တယ်။"

ဒီဖော်ပြချက်က ဘယ် schema အလွှာနဲ့ ကိုက်ညီသလဲ။ (conceptual၊ logical ဒါမှမဟုတ် physical ကို English လို ရိုက်ပါ။)

"လစဉ် ပြန်မအပ်ရသေးတဲ့ ငှားမှု report က အရမ်း နှေးလာလို့ DBA က Loan.LoanDate ပေါ်မှာ B-tree index တစ်ခု ထည့်ဖို့ ဆုံးဖြတ်တယ်။"

ဒီဆုံးဖြတ်ချက်က ဘယ် schema အလွှာနဲ့ ဆိုင်သလဲ။ (conceptual၊ logical ဒါမှမဟုတ် physical ကို English လို ရိုက်ပါ။)

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

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

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

[Core] Schemas [2 marks] Relational database မှာ သုံးတဲ့ schema ဆိုတဲ့ term ကို Define (အဓိပ္ပာယ်ကို တိတိကျကျ ဖော်ပြပါ) လုပ်ပြီး schema အဆင့် သုံးဆင့်ကို State (ဖော်ပြပါ) လုပ်ပါ။
[Core] Schemas [4 marks] အမျိုးသား ဥယျာဉ် တစ်ခုရဲ့ တောင်ပေါ် တဲ booking ဝန်ဆောင်မှုက ဥယျာဉ်ရဲ့ မန်နေဂျာတွေနဲ့ ဒီ conceptual schema ကို သဘောတူထားပါတယ်: “ဝန်ဆောင်မှုက တောင်တက်သူတွေ၊ ဥယျာဉ်ရဲ့ တောင်ပေါ် တဲတွေနဲ့ တောင်တက်သူတွေ လုပ်တဲ့ booking တွေကို မှတ်ထားတယ်။ Booking တစ်ခုစီကို တောင်တက်သူ တစ်ယောက်က တဲ တစ်လုံးအတွက်၊ ည တစ်ညအတွက် လုပ်တယ်။ တောင်တက်သူ တစ်ယောက်က booking အများ လုပ်နိုင်ပြီး တဲ တစ်လုံးမှာလည်း booking အများ ရှိနိုင်တယ်။”
- (a) ဒီ ဝန်ဆောင်မှုရဲ့ logical schema မှာ ပါမယ့်၊ ဒီ conceptual schema မှာ မပါတဲ့ အသေးစိတ် အမျိုးအစား နှစ်မျိုးကို Identify (ဖြစ်နိုင်တဲ့ အဖြေတွေထဲက ရွေးပြီး ဖော်ပြပါ) လုပ်ပါ။ တစ်မျိုးစီအတွက် တဲ booking ဝန်ဆောင်မှုကနေ ဥပမာ တစ်ခုစီ ပေးပါ။ [2]
- (b) Conceptual schema က booking တစ်ခုစီဟာ တဲ တစ်လုံးအတွက်ပဲ ဖြစ်တယ်လို့ ဆိုပါတယ်။ Logical schema က ဒီစည်းမျဉ်းကို ဘယ်လို မှတ်တမ်းတင်လဲ Outline (အကျဉ်းချုပ် ဖော်ပြပါ) လုပ်ပါ။ [2]
[Core] Schemas [3 marks] Logical schema ရဲ့ ဝိသေသ သုံးခုကို Identify လုပ်ပါ။

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

[Extension] Schemas [6 marks] Database တစ်ခုရဲ့ conceptual၊ logical နဲ့ physical schema တွေကြား Distinguish (အရာ နှစ်ခု ဒါမှမဟုတ် ပိုများတဲ့ အရာတွေကြားက ကွာခြားချက်ကို ရှင်းရှင်းလင်းလင်း ပြပါ) လုပ်ပါ။ အဆင့် တစ်ခုစီအတွက် အဲဒီ အဆင့်နဲ့ ဆိုင်တဲ့ ဆုံးဖြတ်ချက် တစ်ခုနဲ့ မဆိုင်တဲ့ ဆုံးဖြတ်ချက် တစ်ခုကို ဖော်ပြပါ။
[Extension] Schemas [6 marks] အက သင်ကျောင်း တစ်ကျောင်းရဲ့ developer က ဒေတာကို အရင် model မဆွဲဘဲ database ကို ချက်ချင်း တည်ဆောက်ခဲ့ပါတယ်။ အရာအားလုံးကို table တစ်ခုတည်းမှာ သိမ်းထားပါတယ်:

LESSON_LOG(LessonDate, StudentName, ParentPhone, DanceStyle, Teacher, Studio)

စာသင် အပိုင်း (term) တစ်ခု ပြီးတော့ ပြဿနာ သုံးခု ပေါ်လာပါတယ်။ Database ကို မတည်ဆောက်ခင် ဒေတာကို model ဆွဲထားခဲ့ရင် ပြဿနာ တစ်ခုစီကို ဘယ်လို ကာကွယ်နိုင်ခဲ့မလဲ Explain (ရှင်းပြပါ) လုပ်ပါ။
- (a) မိဘ တစ်ယောက် ဖုန်းနံပါတ် ပြောင်းလို့ နံပါတ်အသစ်ကို row 40 မှာ ရိုက်ထည့်ရပြီး သုံးကြောင်း ကျန်ခဲ့ပါတယ်။ [2]
- (b) စာရင်းသွင်းထားပေမယ့် သင်ခန်းစာ တစ်ခုမှ မလာတက်ရသေးတဲ့ ကျောင်းသားတွေကို စာရင်း ထုတ်ဖို့ ကျောင်းမှာ နည်းလမ်း မရှိပါဘူး။ [2]
- (c) ကျောင်းသား နှစ်ယောက်လုံး Mia Chen လို့ နာမည်တူလို့ သူတို့ရဲ့ သင်ခန်းစာတွေကို ခွဲခြားလို့ မရပါဘူး။ [2]

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

[Challenge] Schemas [6 marks] စာအုပ်ဆိုင် အုပ်စု တစ်ခုက တူညီတဲ့ ဆိုင် စီမံခန့်ခွဲမှု software ကို အခြေအနေ နှစ်မျိုးမှာ run ပါတယ်: ဆိုင်ခွဲ တစ်ခုက ရွာက ဆိုင် သေးသေးလေး ဖြစ်ပြီး နောက်တစ်ခုက အုပ်စုရဲ့ ရုံးချုပ်က report ထုတ်တဲ့ ဗဟို ဌာန ဖြစ်ပါတယ်။ ဒီ install လုပ်ထားမှု နှစ်ခုက logical schema တူတူ သုံးနိုင်ပေမယ့် physical schema တွေ ဘာကြောင့် အလွန် ကွာခြားဖို့ လိုနိုင်လဲ Explain လုပ်ပါ။ Physical အဆင့် ကိစ္စ အနည်းဆုံး သုံးခု (index၊ partitioning၊ storage engine၊ replication၊ backup စသဖြင့်) ကို ကိုးကားပါ။
[Challenge] Schemas [8 marks] To what extent (ဘယ်လောက်အထိ မှန်သလဲ: အကြောင်းပြချက်တွေကို ချိန်ဆပြီး ခိုင်လုံတဲ့ ကောက်ချက် ချပါ): developer တစ်ယောက်တည်းနဲ့ DBMS တစ်ခုတည်း သုံးပြီး application သေးသေးလေး အများကြီးကို မြန်မြန် တည်ဆောက်နေကြတဲ့ ခေတ်မှာ three-schema architecture က ဘယ်လောက်အထိ အသုံးဝင်နေဆဲလဲ။ ခွဲထားခြင်းရဲ့ သီးခြား အားသာချက်တွေနဲ့ over-engineering (လိုတာထက် ပိုရှုပ်ထွေးအောင် လုပ်ခြင်း) ဖြစ်နိုင်တဲ့ အခြေအနေ အနည်းဆုံး တစ်ခုကို ကိုးကားပါ။

IB CS သင်တန်း တက်နေသူတွေအတွက် မှတ်ချက်: Schema ရဲ့ အဓိပ္ပာယ်နဲ့ schema အလွှာ တစ်ခုစီရဲ့ ဝိသေသတွေကို လေ့လာထားပါ။ အလွှာ နှစ်ခုကို ခွဲခြားပြရမယ့်အခါ သီးခြား စာပိုဒ် နှစ်ပိုဒ် ရေးမယ့်အစား အတွဲလိုက် နှိုင်းယှဉ်ချက်တွေ ရေးပါ: “X does …, whereas Y does …” (“X က … လုပ်တယ်၊ Y ကတော့ … လုပ်တယ်”)။

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

အရင် လေ့လာထားရမယ့် ခေါင်းစဉ်: Relational Database Fundamentals (Relational database ရဲ့ အခြေခံများ): schema က ဖော်ပြတဲ့ model။
နောက်ထပ် လေ့လာမယ့် ခေါင်းစဉ်: Entity-Relationship Diagrams (Entity တွေနဲ့ ဆက်နွယ်မှုတွေကို ပြတဲ့ ပုံများ): conceptual schema နဲ့ logical schema တွေကို ပုံနဲ့ ဖော်ပြတဲ့ စံ နည်း။
ဆက်စပ် ခေါင်းစဉ်: Data Types and Keys (Data type နဲ့ key များ): column type တွေနဲ့ key ရွေးချယ်မှုတွေအကြောင်း logical schema ဆုံးဖြတ်ချက်များ။
ဆက်စပ် ခေါင်းစဉ်: Normalisation (ဒေတာ ထပ်မနေအောင် table တွေကို စီစဉ်ခြင်း): logical schema ကို redundancy (မလိုအပ်ဘဲ ထပ်နေတဲ့ ဒေတာ) နည်းတဲ့ ပုံစံ ဖြစ်အောင် ပြုပြင်တဲ့ လုပ်ငန်းစဉ်။
ရှေ့ဆက် လေ့လာရန်: SQL Queries (SQL query များ): logical schema ကို အလုပ်လုပ်တဲ့ database အဖြစ် ပြောင်းပေးတဲ့ DDL CREATE TABLE statement တွေနဲ့ physical schema ရွေးချယ်မှုတွေကို အကောင်အထည် ဖော်ပေးတဲ့ CREATE INDEX statement တွေ။