Database Structure: Table

Table

Table ဆိုတာကတော့ relational database တွေမှာ data တွေကို စနစ်တကျ သိမ်းဆည်းပေးတဲ့ အဓိကကျတဲ့ (structure) ဖြစ်ပါတယ်။ Table တစ်ခုစီက သီးခြားအကြောင်းအရာ (subject) တစ်ခု ဒါမှမဟုတ် အရာဝတ္ထု (entity) တစ်ခုစီကို ကိုယ်စားပြုပါတယ်။ ဥပမာ - ဝန်ထမ်းများ (employees)၊ ကုန်ပစ္စည်းများ (products)၊ ဒါမှမဟုတ် မှာယူမှုများ (orders) စသဖြင့်ပေါ့။ Table တိုင်းမှာ အနည်းဆုံး Primary Key လို့ခေါ်တဲ့ အဓိက Field တစ်ခု အမြဲတမ်း ပါဝင်ပါတယ်။

Table အမျိုးအစားများ

၁။ Data Table (Transaction Table)

Data Table ဆိုတာကတော့ လုပ်ငန်းတစ်ခုရဲ့ နေ့စဉ်လုပ်ငန်းဆောင်တာတွေကနေ ဖြစ်ပေါ်လာတဲ့ အဓိက data တွေကို သိမ်းဆည်းပေးတဲ့ Table အမျိုးအစားဖြစ်ပါတယ်။ Relational database တွေမှာ အသုံးအများဆုံး table လည်း ဖြစ်ပါတယ်။ ဒီ table တွေမှာ dynamic data တွေပါဝင်ပါတယ်။ ဆိုလိုတာကတော့ data အသစ်တွေ ထပ်ထည့်တာ၊ ရှိပြီးသား data တွေကို ပြင်တာ ဒါမှမဟုတ် ဖျက်တာမျိုး အမြဲလုပ်နေရတာမျိုးဖြစ်ပါတယ်။

ဥပမာ -

Employees table

ID	Name	Department	Salary
1	Alice	IT	5000
2	Bob	IT	4000

ဒီဥပမာကို ကြည့်မယ်ဆိုရင်။

ဒီ table ရဲ့ အဓိက အကြောင်းအရာ (subject) ကတော့ “ဝန်ထမ်း” (Employee) ဖြစ်ပါတယ်။
ID ကတော့ ဒီ table ရဲ့ Primary Key ဖြစ်ပါတယ်။
ဒီ table ထဲက data တွေဟာ အချိန်နှင့်အမျှ ပြောင်းလဲနိုင်ပါတယ်။ (ဥပမာ- လစာတွေ ပြင်ဆင်တာ၊ ဝန်ထမ်းအသစ်တွေ ထပ်ဝင်လာတာ စသဖြင့်)။

၂။ Linking Table (Junction Table/ Bridge Table)

Linking table ဆိုတာ many-to-many relationship ရှိနေတဲ့ table နှစ်ခုကြားမှာ relation တစ်ခုကို တည်ဆောက်ပေးတဲ့ table ဖြစ်ပါတယ်။

ဥပမာ -

table နှစ်ခုရှိတယ်ဆိုပါစို့။

Students

StudentId (PK)	Name
1	Alice
2	Bob
3	Charlie

Courses

CourseId (PK)	Name
101	Math
102	English
103	Science

ကျောင်းသားတစ်ဦးတည်းက သင်တန်းတွေအများကြီး တက်ရောက်နိုင်သလို၊ သင်တန်းတစ်ခုတည်းမှာလည်း ကျောင်းသားတွေအများကြီး ရှိနိုင်ပါတယ်။ ဒါကို Many-to-Many relationship လို့ခေါ်ပါတယ်။

ဒါပေမယ့် relational databases တွေက many-to-many relationship တွေကို တိုက်ရိုက်မချိတ်ဆက်နိုင်ပါဘူး။

ဒါကြောင့် linking table က many-to-many relationship ရှိနေတဲ့ table နှစ်ခုကြားမှာ တံတားတစ်ခုလို လုပ်ဆောင်ပေးပါတယ်။

✅ Good Design: StudentEnrollment Table

EnrollmentID (PK)	StudentId (FK)	CourseId (FK)
1	1	101
2	1	102
3	2	101
4	2	103
5	3	102

Linking Table မသုံးပဲနှင့် relationship တွေကို မှန်ကန်စွာ မတည်ဆောက်ထားဘူးဆိုရင် အောက်ပါပြဿနာတွေနှင့် ကြုံတွေ့ရမှာ ဖြစ်ပါတယ်။

၁။ Table တစ်ခုစီကနေ data တွေ ပြန်ထုတ်ယူဖို့ ခက်ခဲပါလိမ့်မယ်။

❌ Bad Design 1: ID များစွာကို column တစ်ခုတည်းမှာ သိမ်းဆည်းခြင်း။

StudentId	Name	CourseIds
1	Alice	101,102
2	Bob	101,103
3	Charlie	102

Student table ထဲမှာ ကျောင်းသားတစ်ယောက်တက်တဲ့ Class ID တွေကို “101,102” စသဖြင့် ကော်မာခံပြီး column (single column) တစ်ခုအနေဖြင့် သိမ်းတာက လုံးဝမှားယွင်းတဲ့ ဒီဇိုင်းဖြစ်ပါတယ်။ (ဒီလိုသိမ်းဆည်းခြင်းက data တွေကို ရှာဖွေတာ၊ analysis လုပ်တာတွေကို ခက်ခဲစေပါတယ်။)

၂။ Table တစ်ခုမှာ ထပ်နေတဲ့ data တွေ (duplicate data) အများကြီး ပါဝင်နေပါလိမ့်မယ်။

❌ Bad Design 2: Row တစ်ခုလုံးကို ထပ်ခါထပ်ခါ သိမ်းဆည်းခြင်း။

StudentId	Name	Course
1	Alice	Math
1	Alice	English
1	Alice	Science
1	Alice	History
1	Alice	Physics

ကျောင်းသားတစ်ယောက်က ဘာသာရပ် (၅)ခု သင်ကြားတယ်ဆိုပါစို့။ ကျောင်းသားရဲ့ data တွေကို ဘာသာရပ်တစ်ခုစီအတွက် တစ်ကြိမ်စီ၊ စုစုပေါင်း (၅)ကြိမ် ထပ်ခါတလဲလဲ ဒီလိုလုပ်ခြင်းက data အပိုတွေ အများကြီး ဖြစ်စေခြင်း (massive redundancy)၊ သိမ်းဆည်းမှုနေရာ ပိုမိုကုန်ကျခြင်း (increased storage) နှင့် data ပြင်တဲ့အခါ မကိုက်ညီခြင်း (updates inconsistent) တွေကို ဖြစ်ပေါ်စေပါတယ်။ (ဥပမာ- ကျောင်းသားနာမည်ကို ပြောင်းချင်ရင် (၅)နေရာမှာ လိုက်ပြင်ရပါလိမ့်မယ်)။

၃။ data query ရာတွင်အလွန်ခက်ခဲပြီး performance နိမ့်ကျသွားနိုင်ပါတယ်။

ကျောင်းသားတစ်ယောက်တက်နေတဲ့ Class တွေအားလုံးကို ဘယ်လိုရှာမလဲ။

ကျောင်းသားရဲ့ Class ID တွေကို ကော်မာခံပြီး string တစ်ခုတည်းအဖြစ် သိမ်းဆည်းထားတယ်ဆိုရင် အဲဒီ Class တွေအားလုံးကို ရှာဖွေဖို့အတွက် string တွေကို ပြန်ခွဲထုတ်ရပါလိမ့်မယ် (parse strings)။ ဒီလို string တွေကို ခွဲထုတ်တဲ့ process က နှေးကွေးပြီး အမှားအယွင်း ဖြစ်နိုင်ခြေလည်း များပါတယ်။

Class တစ်ခုထဲမှာရှိတဲ့ ကျောင်းသားအားလုံးကို ဘယ်လိုရှာမလဲ။

အလားတူပဲ Class ID တွေကို string ထဲမှာ ထည့်သိမ်းထားတဲ့အတွက် ကျောင်းသားအားလုံးကို ရှာဖို့အတွက်လည်း string တွေထဲမှာ လိုက်ရှာဖွေရပါလိမ့်မယ် (search within strings)။ ဒါကလည်း ရှာဖွေမှုတွေကို ခက်ခဲစေပါတယ်။

၃။ Validation Table (Lookup Table/ Reference Table)

Validation table ကတော့ ပြောင်းလဲမှုမရှိတဲ့ (static) ဒါမှမဟုတ် အနည်းငယ်သာ ပြောင်းလဲတတ်တဲ့ (semi-static) data တွေကို သိမ်းဆည်းဖို့ အသုံးပြုတဲ့ table အမျိုးအစား ဖြစ်ပါတယ်။ ဒီ table ရဲ့ အဓိကတာဝန်က data ထည့်သွင်းတဲ့အခါ မှန်ကန်တိကျပြီး ကိုက်ညီမှုရှိအောင် (Data Integrity) စစ်ဆေးပေးဖို့ ဖြစ်ပါတယ်။ ဒီ table တွေကို Data Table တွေကနေ Foreign Key (FK) တွေကတစ်ဆင့် ကိုးကား အသုံးပြုကြပြီး မှားယွင်းတဲ့ ဒါမှမဟုတ် ကိုက်ညီမှုမရှိတဲ့ data တွေ မရှိအောင်တားဆီးပေးပါတယ်။

ဥပမာ -

Products လို့ခေါ်တဲ့ Data Table မှာ ကုန်ပစ္စည်းတွေရဲ့ဌာန (Department) ကို သိမ်းထားမယ့် field တစ်ခုရှိတယ်ဆိုပါစို့။ ဒီ Products Table ထဲမှာ “IT”, “HR”, “Sales” စသဖြင့် Department တွေကို လက်တန်းရေးထည့်နေမယ်ဆိုရင် စာလုံးပေါင်းမှားတာ၊ ကိုက်ညီမှုမရှိတာ၊ data ဖောင်းပွတာ (ဥပမာ- “IT” ကို တစ်ခါတစ်လေ “Information Technology” လို့ ရေးတာ) မျိုးတွေ ဖြစ်နိုင်ပါတယ်။

ဒီလိုမဖြစ်ရအောင် Departments လို့ခေါ်တဲ့ Validation Table တစ်ခုကို အောက်ပါအတိုင်း ထားရှိနိုင်ပါတယ်။

DepartmentID (PK)	DepartmentName	Description
101	IT	Information Technology
102	HR	Human Resource
103	Sales	Sales
104	Marketing	Digital Marketing

ပြီးရင် Products Table ထဲမှာ DepartmentID ကို Foreign Key အဖြစ် ထည့်သွင်းရပါမယ်။

ProductID (PK)	ProductName	DepartmentID (FK)	Price
P001	Laptop	101	1200
P002	Mouse	101	25
P003	T-Shirt	103	20
P004	Keyboard	101	70

Table တွေဘာကြောင့်အရေးကြီးသလဲ။

Table တွေဟာ database တစ်ခုရဲ့ အခြေခံအုတ်မြစ် (foundation) ဖြစ်ပါတယ်။ database နှင့်ဆိုင်တဲ့လုပ်ဆောင်ချက်တွေအကုန်လုံးက (ဥပမာ - queries, relationships, reports) table တွေကို ဘယ်လောက်ကောင်းအောင် ဒီဇိုင်းဆွဲထားသလဲ ဆိုတဲ့အပေါ်မှာပဲ မူတည်နေပါတယ်။

ကောင်းမွန်တဲ့ Table Design က အောက်ပါအချက်တွေကို မြှင့်တင်ပေးနိုင်ပါတယ်။

Data Integrity

Data တွေ မှန်ကန်ဖို့၊ တိကျဖို့နှင့် ယုံကြည်စိတ်ချရဖို့ သေချာစေပါတယ်။ ဥပမာ- Departments လို Validation Table ရှိခြင်းအားဖြင့် Products Table ထဲမှာ မှားယွင်းတဲ့ ဌာနအမည်တွေ ဝင်ရောက်လာတာကို ကာကွယ်ပေးပြီး data တွေရဲ့ အရည်အသွေးကို ထိန်းသိမ်းပေးပါတယ်။ Products table ထဲက DepartmentID ဟာ Departments table ထဲက DepartmentID ထဲမှာ ရှိတာကိုပဲ ရွေးထည့်လို့ရပါမယ်။ ဒါကြောင့် “Sales” ကို “Sale” လို့ စာလုံးပေါင်းမှားတာမျိုး မဖြစ်နိုင်တော့ဘဲ data မှန်ကန်မှုကို သေချာစေပါတယ်။

Consistency

Data တွေဟာ database တစ်ခုလုံးမှာ တစ်ခုနှင့်တစ်ခု ကိုက်ညီမှုရှိပြီး တစ်သမတ်တည်းရှိနေဖို့ အရေးကြီးပါတယ်။ Table ဒီဇိုင်းကောင်းခြင်းက data တွေ မတူညီတာ၊ ထပ်နေတာတွေကို လျှော့ချပေးပြီး information တွေ လုံးဝတစ်ထပ်တည်းဖြစ်နေအောင် ကူညီပေးပါတယ်။ ဥပမာ- “Marketing” ဆိုတဲ့ Department ရဲ့ Description ကို ပြင်ချင်ရင် Departments table ထဲမှာ တစ်နေရာတည်း ပြင်လိုက်ရုံပါပဲ။ Products table ထဲက သက်ဆိုင်ရာ Product တွေအားလုံး အလိုအလျောက် မှန်ကန်သွားပါမယ်။

Performance

Table တွေကို ကောင်းကောင်းဒီဇိုင်းလုပ်ထားရင် data တွေကို လျင်မြန်စွာ ရှာဖွေနိုင်မယ်၊ ထည့်သွင်းနိုင်မယ်၊ ပြင်ဆင်နိုင်မယ်၊ ဖျက်ပစ်နိုင်ပါမယ်။ database system တစ်ခုလုံးရဲ့ အလုပ်လုပ်ပုံကို ပိုမိုမြန်ဆန်စေပါတယ်။ ရှုပ်ထွေးတဲ့ table ဖွဲ့စည်းပုံတွေက system ကို နှေးကွေးစေနိုင်ပါတယ်။

Ease of Maintenance

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