Monday, May 19, 2008

Natural Key

database နဲ႔ software development လုပ္ရာမွာ primary key၊ foreign key နဲ႔ candidate key တို႕ကို အမ်ားက ရင္းနီးၿပီး ျဖစ္မယ္။ အခု ေျပာခ်င္တာကေတာ့ natural key နဲ႔ surrogate key အေၾကာင္းျဖစ္ပါတယ္။ သိၿပီးသား ျဖစ္ေပမယ့္ သက္ဆိုင္ေနလို႔ ျပန္ေျပာခ်င္တာကေတာ့ primary key ရဲ႕ characteristic ေတြပါ။ primary key ဟာ
- record တစ္ခုစီ အတြက္ unique ျဖစ္ရမယ္
- null value ျဖစ္လို႔ မရဘူး
- immutable ျဖစ္ရမယ္ (ေျပာင္းလို႔ မရႏိုင္ရဘူး။ record တစ္ခု အတြက္ key ေပးၿပီး သြားရင္ ျပန္မေျပာင္းရဘူး။)
တျခား လိုက္နာသင့္တာေတြက ေတာ့
- numeric value ျဖစ္ရမယ္
attribute တတ္ႏိုင္သမွ် နည္းရမည္။ (column တစ္ခု ထက္ပိုၿပီး composite key လုပ္ျခင္းကို တတ္ႏိုင္ သမွ် ေ႐ွာင္႐ွားရမည္)
- recycle မလုပ္ရဘူး။ (ဖ်က္လိုက္တဲ့ record ရဲ႕ primary key ကို record အသစ္အတြက္ ျပန္သံုးျခင္း)

primary key အတြက္ သင့္ေတာ္ရာ column တစ္ခု ကို ေရြးခ်ယ္ရာမွာ natural key ကေန စၿပီး စဥ္းစားႏိုင္ပါတယ္။ ဥပမာ book ဆိုတဲ့ table မွာ ISBN number ဟာ unique လည္း ျဖစ္တယ္။ စာအုပ္တိုင္းမွာလည္း ႐ွိႏိုင္တဲ့ အတြက္ primary key ျဖစ္ႏိုင္တဲ့ အရည္ အခ်င္း ႐ွိတဲ့ candidate key တစ္ခုပါ။ အဲဒီလို primary key အရည္အခ်င္းလည္း ႐ွိၿပီး ျပင္ပေလာကမွာ နားလည္ႏိုင္တဲ့ (business meaning ႐ွိတဲ့) key ကို natural key လို႔ ေခၚပါတယ္။ အေမရိကားမွာ ဆိုရင္ person ဆိုတဲ့ table မွာ SSN (social security number) ဆိုတဲ့ column ဟာ primary key အျဖစ္ သံုးႏိုင္ပါတယ္။ စကၤာပူမွာ ဆိုရင္ေတာ့ IC No (identification card no) လိုမ်ိဳးပါ။ ေၾသာ္ဇီမွာဆိုရင္ employee ဆိုတဲ့ table တစ္ခုမွာ TFN (tax file number) column ဟာ primary key ျဖစ္ႏိုင္ပါတယ္။

အဲဒီလို natural key မ႐ွိတဲ့ data ေတြ အတြက္ေသာ္ လည္းေကာင္း၊ ႐ွိေသာ္လည္း natural key ကို မသံုးခ်င္ရင္ေသာ္ လည္းေကာင္း key တစ္ခုကို generate လုပ္ၿပီး သံုးပါတယ္။ synthetic identifiers ေတြ သံုးႏိုင္ပါတယ္။ အဲဒီလို မိမိ ဘာသာ generate လုပ္တဲ့ ၊ ဒါမွမဟုတ္ database က generate လုပ္ေပးတဲ့ key ကို surrogate key လို႔ ေခၚပါတယ္။ မိမိဘာသာ လုပ္မယ္ဆို ဥပမာ max(id) + 1 ဆိုၿပီး လုပ္ႏိုင္ေပမယ့္ ေနာက္ဆံုးမွ ထည့္ထားတဲ့ record ကုိ ဖ်က္ၿပီး key generate လုပ္မယ္ဆိုရင္ေတာ့ key အေဟာင္းႀကီးကို record အသစ္အတြက္ ျပန္သံုးမိႏိုင္ပါတယ္။ အဲဒီ table မွာ unique ျဖစ္ေပမယ့္ ဒီလို တစ္ခါသံုးၿပီးသား key ကို ျပန္မသံုး သင့္ပါဘူး။ surrogate key သံုးမယ္ဆိုရင္လည္း database က support လုပ္တဲ့ key ကို သံုးသင့္ပါတယ္။ ဥပမာ MS SQL မွာ identity၊ Oracle မွာဆိုရင္ sequence နဲ႔ postgreSQL မွာ serial လိုမ်ိဳးပါ။ ဒီထက္ ပိုမိုၿပီး ႐ႈပ္ေထြးေပမယ့္ unique ပုိျဖစ္ေအာင္ UUID တို႔ GUID တို႔ သံုးႏိုင္ပါေသးတယ္။ ဒီလို key ေတြကေတာ့ မိမိ system မွာသာ မက တကမၻာလံုးမွာ ႐ွိတဲ့ system ေတြမွာပါ unique ျဖစ္ေစႏိုင္ပါတယ္။ surrogate key ေတြဟာ system generated key လည္း ျဖစ္တဲ့ အျပင္ business meaning လည္း မ႐ွိတဲ့ အတြက္ အဲဒီ တန္ဖိုးေတြကို end users ေတြကို မျပသင့္ပါဘူး။ end user ကို ျပတာ ေပးသံုးတာကို naturalise လုပ္တယ္ ေခၚၿပီး အဲဒီလို လုပ္လိုက္ရင္ surrogate key ရဲ႕ဂုဏ္ကို ထိခိုက္ႏိုင္ပါတယ္။ system ကို debug/trace လုပ္ဖို႔ logging လုပ္ဖို႔ mechanism/feature တစ္ခု ႐ွိထားရင္ အဲဒီမွာေတာ့ ျပႏိုင္ပါတယ္။

natural key ေတြဟာ business meaning ႐ွိတယ္ ဆိုေပမယ့္ အဲဒီ key ကို ၾကည့္လိုက္႐ံုနဲ႔ record တစ္ခုလံုးရဲ႕ information ကို မသိႏိုင္ပါဘူး။ ဥပမာ ISBN နံပါတ္ သိ႐ံုနဲ႔ အဲဒီ စာအုပ္အေၾကာင္းကို ခ်က္ခ်င္း မသိႏိုင္ပါဘူး။ အဲဒီအခါ key ကို ၾကည့္လိုက္႐ံုနဲ႔ ဒါဘာလဲဆိုတာ အနည္းနဲ႔ အမ်ား ခန္႔မွန္းႏိုင္တဲ့ smart key ေတြ သံုးခ်င္လာပါတယ္။ ဥပမာ employee table မွာ empid ကို ေ႐ွ႕က စာလံုး ႏွစ္လုံးကို department ရဲ႕ အတိုေကာက္ေတြ ထည့္တာပါ။ IT001, IT002, AC003 လိုမ်ိဳးေတြပါ။ US zip code ေတြကို ၾကည့္လိုက္ရင္လည္း ပထမ ႏွစ္လံုးက ဘယ္ ျပည္နယ္ကလည္းလို႔ ေျပာပါတယ္။ ဒါေပမယ့္ ဒီလို smart key ေတြကို လံုး၀ မသံုးသင့္ပါဘူး။ ဘာျဖစ္လို႔လဲ ဆိုေတာ့ ဒီလို smart key ေတြကို generate လုပ္ရတာ ၾကာလာရင္ ေျပာင္းဖို႔ လိုလာတတ္လို႔ပါ။

မ်ားေသာအားျဖင့္ေတာ့ surrogate key ကိုပဲ primary key အျဖစ္ သံုးၾကပါတယ္။ natural key ေတြရဲ႕ တန္ဖိုးဟာ တစ္ခ်ိန္ခ်ိန္မွာ ေျပာင္းသြားႏိုင္ပါတယ္။ အဲဒါေၾကာင့္ primary key အျဖစ္ မသံုးရပါဘူး။ ဒါ့အျပင္ natural key ေတြဟာ numeric မဟုတ္ဘဲ text ေတြလည္း ျဖစ္ႏိုင္ပါတယ္။ text value ႐ွိတဲ့ column ကို primary key အျဖစ္ သံုးရင္ database system ကို ေႏွးေစႏိုင္ပါတယ္။ (UUID တို႔ GUID တို႔ကေတာ့ ႐ုတ္တရက္ ၾကည့္လိုက္ရင္ alpha numeric ျဖစ္ေပမယ့္ အတြင္းမွာေတာ့ hexa value နဲ႔ သိမ္းလို႔ ေတာ္႐ံုတန္႐ံုေတာ့ မေႏွးေစပါဘူး။) ေနာက္ၿပီး natural key ေတြဟာ business rule ေတြနဲ႔ coupled ျဖစ္ေနပါတယ္။ ဥပမာ customer no ကို အရင္က numeric ပဲသံုးေနရာကေန alpha numeric ေျပာင္းခ်င္ရင္ အခက္ေတြ႕ပါမယ္။

natural key ကိုပဲ primary key အျဖစ္ သံုးမယ္ဆိုရင္ေတာ့ table မွာ surrogate key အတြက္ column တစ္ခု အပို ထည့္စရာ မလိုေတာ့ပါဘူး။ ၿပီးေတာ့ end user ကလည္း နားလည္ႏိုင္ပါတယ္။ surrogate key ေတြကို primary key အျဖစ္ သံုးသင့္တယ္ ဆိုေပမယ့္ natural key ေတြကိုလည္း alternate key အျဖစ္ table မွာ ႐ွိႏိုင္ရင္ ႐ွိသင့္ပါတယ္။ အထူးသျဖင့္ search လုပ္ဖို႔ပါ။ ဥပမာ စာအုပ္ကို ႐ွာဖို႔ရာ ISBN နဲ႔ ႐ွာသလို မ်ိဳးပါ။ ေနာက္ထပ္ ေကာင္းတဲ့ အခ်က္ကေတာ့ မတူတဲ့ system ေတြ တစ္ခုနဲ႔ တစ္ခု ဆက္သြယ္ၿပီး အခ်က္အလက္ ဖလွယ္ဖို႔ (data interchange လုပ္ဖို႔) ပါ။ natural key ေတြဟာ standard key ေတြ ျဖစ္တတ္ပါတယ္။ ဥပမာ ISBN နံပါတ္ကို စနစ္တိုင္းက နားလည္ႏိုင္ပါတယ္။ ဒါေပမယ့္ တခ်ိဳ႕က တစ္ကမၻာလံုးအတြက္ standard ျဖစ္ေပမယ့္ တခ်ိဳ႕ကေတာ့ တစ္ႏိုင္ငံစာပဲ standard ျဖစ္ပါတယ္။ ဥပမာ zip code လိုမ်ိဳးပါ။

စနစ္တိုင္းရဲ႕ လိုအပ္ခ်က္နဲ႔ အကန္႔အသတ္ေတြက မတူညီႏိုင္တဲ့ အတြက္ ဘယ္ဟာကို သံုးမွ မွန္မယ္ဆိုတာကေတာ့ မ႐ွိပါဘူး။ အကန္႔အသတ္ေတြ အတြင္းကေန ေနာက္ပိုင္းအတြက္လည္း စိတ္ခ်ရမယ့္ (scalable ျဖစ္မယ့္) နည္းလမ္းကို သံုးတာေတာ့ အေကာင္းဆံုးပါပဲ။

4 comments:

KNAT - 5/20/08, 7:04 PM

Hello Ko Anday

Its really useful to read about ur working experiences and IT knowledge. But I also love to read about ur other posts. Pls contribute more about IT. I will be looking forward to read. Many Thanks

Andy Myint - 5/21/08, 9:57 PM
I will try to write more, KNAT.
Anonymous - 5/21/08, 10:05 PM

It is a good one & common for all IT audience. Thanks a lot for sharing.

TZA - 5/23/08, 12:26 PM

ဒီလိုနက္နဲတဲ့ပို႔စ္မ်ဳိးမွာ ေကာ္မန္႔မေရးရင္ နားမလည္ဘူးအထင္ခံရမွာစိုးလို႔ ခပ္တည္တည္နဲ႔ေကာ္မန္႔ေရးသြားတယ္၊ ဟိဟိ။
(နားမလည္ေသာ္ျငားလည္း ဖတ္ရတာအရသာရွိပါတယ္)

Post a Comment

Many thanks for dropping a comment…

Film


Files