Database Structure: Field

Field

Field (သို့မဟုတ် Attribute) ဆိုတာ database တစ်ခုထဲမှာ ပါဝင်တဲ့အသေးဆုံးယူနစ် တစ်ခုဖြစ်ပါတယ်။ Entity တစ်ခုရဲ့ characteristic ဒါမှမဟုတ် property တစ်ခုစီကို ကိုယ်စားပြုပါတယ်။ Field တွေက record တစ်ခုစီအတွက် တကယ့် data တန်ဖိုးတွေကို သိမ်းဆည်းပေးပါတယ်။

ဥပမာ -

Employees

ID	Name	Position
1	Alice	Director
2	Bob	Manager

Employees table တစ်ခုမှာ ID, Name, Position စတဲ့ column တွေက Field တစ်ခုစီဖြစ်ပါတယ်။ Field တစ်ခုစီက ဝန်ထမ်းတစ်ဦးစီရဲ့ information တစ်ခုစီကို သိမ်းဆည်းပေးပါတယ်။

Database ဒီဇိုင်းဆွဲရာတွင် အဖြစ်များသော အမှားများ

Multipart (Composite) Field

Multipart Field ဆိုတာက information နှစ်ခု (သို့မဟုတ်) နှစ်ခုထက်ပိုပြီး ပေါင်းစပ်ထားတဲ့ တန်ဖိုးတစ်ခုတည်းကို သိမ်းဆည်းထားတဲ့ field တစ်ခု ဖြစ်ပါတယ်။

ဘာကြောင့်မကောင်းတာလဲ။

ဒီလို field မျိုးက data searching, sorting နှင့် data updating လုပ်ဆောင်ရာတွင် ခက်ခဲစေပါတယ်။

ဥပမာ -

❌ Bad design: Students table မှာ FullName (အမည်အပြည့်အစုံ) ဆိုတဲ့ field တစ်ခုတည်းကနေ “Alice Chen” လို့ သိမ်းဆည်းထားတာမျိုး။

StudentId	FullName
1	Alice Chen
2	Bob Smith
3	Charlie Davis

✅ Good design: FirstName နှင့် LastName ဆိုပြီး field နှစ်ခု ခွဲထားခြင်း။ ဒါဆိုရင် LastName ဖြင့်သာ ရှာဖွေချင်တယ်ဆိုရင် ရှာဖွေရ ပိုလွယ်ကူသွားမှာဖြစ်ပါတယ်။

StudentId	FirstName	LastName
1	Alice	Chen
2	Bob	Smith
3	Charlie	Davis

Multivalued Field

Multivalued Field ဆိုတာ record(column) တစ်ခုတည်းမှာ အမျိုးအစားတူညီတဲ့ value များစွာကို စုပေါင်းသိမ်းဆည်းထားတဲ့ field တစ်ခု ဖြစ်ပါတယ်။

ဘာကြောင့်မကောင်းတာလဲ။

dabatase ဒီဇိုင်းရဲ့ အခြေခံစည်းမျဉ်းတစ်ခုဖြစ်တဲ့ “field တစ်ခုစီဟာ value တစ်ခုတည်း (atomic value) ကိုသာ သိမ်းဆည်းသင့်တယ်” ဆိုတဲ့အချက်ကို ချိုးဖောက်ရာရောက်ပါတယ်။ ဒါကြောင့် data တွေကို query ဒါမှမဟုတ် indexing တွေ လုပ်တဲ့အခါမှာ ခက်ခဲစေပါတယ်။

ဥပမာ -

❌ Bad design: Customers table မှာ PhoneNumbers ဆိုတဲ့ field တစ်ခုတည်းမှာ “01-555-1234, 01-555-5678” လို့ ဖုန်းနံပါတ်နှစ်ခုကို ပေါင်းပြီးသိမ်းဆည်းထားတာမျိုး။

CustomerId	PhoneNumbers
1	01-555-1234, 01-555-5678
2	01-333-1234, 01-202-5248

✅ Good design: ဖုန်းနံပါတ်တစ်ခုစီအတွက် သီးခြား records တွေခွဲပြီး သိမ်းဆည်းခြင်း။ (ဥပမာ- PhoneNumber1, PhoneNumber2 သို့မဟုတ် ဖုန်းနံပါတ်တွေအတွက် သီးခြား table တစ်ခု (PhoneNumbers table) ထားရှိခြင်း)။

CustomerId	PhoneNumber1	PhoneNumber2
1	01-555-1234	01-555-5678
2	01-333-1234	01-202-5248

Calculated Field

Calculated Field ဆိုတာက တခြား field တွေကနေ ဆက်စပ်တွက်ချက်ပြီး ရလာတဲ့ တန်ဖိုး (ဥပမာ- စာသားတွေပေါင်းစပ်ခြင်း ဒါမှမဟုတ် သင်္ချာတွက်ချက်မှု ရလဒ်) ကို သိမ်းဆည်းထားတဲ့ field တစ်ခု ဖြစ်ပါတယ်။

ဘာကြောင့်မကောင်းတာလဲ။

တွက်ချက်ထားတဲ့ တန်ဖိုးတွေကို သိမ်းဆည်းထားခြင်းဟာ သေချာမစီမံရင် data inconsistency နှင့် redundancy တွေ ဖြစ်စေနိုင်ပါတယ်။ ပုံမှန်အားဖြင့် ဒီလိုတန်ဖိုးတွေကို queries တွေ ဒါမှမဟုတ် application logic တွေထဲမှာ လိုအပ်တဲ့အချိန်မှ တွက်ချက်ထုတ်ယူတာက ပိုကောင်းပါတယ်။

ဥပမာ -

❌ Bad design: Employees table မှာ FirstName နှင့် LastName ကို ပေါင်းပြီး FullName ဆိုတဲ့ field အသစ်နောက်တစ်ခု ထပ်ထည့်ထားတာမျိုး။ OrderDetails table မှာ Quantity (အရေအတွက်) နှင့် UnitPrice (ပစ္စည်းတစ်ခုချင်းစီရဲ့ဈေးနှုန်း) ကို မြှောက်ပြီး TotalPrice (စုစုပေါင်းဈေးနှုန်း) ဆိုတဲ့ field ကို ထပ်ထည့်ထားတာမျိုး။

ProductId	Price	Quantity	TotalPrice
1	10	2	20
2	20	3	60

✅ Good design: FullName လိုအပ်ရင် FirstName နှင့် LastName field တွေကို query ဒါမှမဟုတ် report ထဲမှာမှ ပေါင်းစပ်ပြီး ဖော်ပြခြင်း။ TotalPrice ကို လိုအပ်ရင် Quantity * UnitPrice ဆိုပြီး query ထဲမှာမှ တွက်ချက်ခြင်း။ ဒီလိုလုပ်ခြင်းအားဖြင့် Quantity ဒါမှမဟုတ် UnitPrice ပြောင်းသွားရင် TotalPrice ကို သက်သက်လိုက်ပြင်နေစရာမလိုတော့ဘဲ query ခေါ်ယူတိုင်း နောက်ဆုံးတန်ဖိုးကို အမြဲတမ်း တွက်ချက်ပေးသွားမှာဖြစ်ပါတယ်။

ProductId	Price	Quantity
1	10	2
2	20	3

TotalPrice = Quantity * Price

ဒီအမှားတွေကို ရှောင်ရှားခြင်းအားဖြင့် ပိုမိုကောင်းမွန်တဲ့ database ဒီဇိုင်းတွေကို ဖန်တီးနိုင်မှာဖြစ်ပါတယ်။