Developing Relationship and Data Modelling
Data Model ဆိုသည်မှာ Power Pivot ထဲသို့ ထည့်သွင်းထားပြီး Relationship များဖြင့် ချိတ်ဆက်ထားသည့် Data Table များကို ဆိုလိုသည်။ Data Modelling ဆိုသည်မှာ Table များအကြား Relationship ချိတ်ဆက်တည်ဆောက်ခြင်းကို ဆိုလိုခြင်းဖြစ်သည်။ သို့ရာတွင် Power Pivot တွင် ထည့်သွင်းထားသည့် Table တစ်ခုထဲသည်လည်း Data Model ပင်ဖြစ်ပါသည်။
Relationship တည်ဆောက်ရာတွင် One-to-Many Relationship နှင့် Many-to-Many Relationship ဟူ၍ နှစ်မျိုးရှိသည်။
One-to-Many Relationship Sample
ဤစာမျက်နှာတွင်ပါဝင်သည့် ခေါင်းစဉ်များ
2.3 Data Modelling ဆိုင်ရာ သဘောတရားများ
အထက်ဖော်ပြပါ ဥပမာတွင် Product ID သည် Table နှစ်ခုလုံးတွင် ပါဝင်သည့်အတွက် ထို Table နှစ်ခုကို ချိတ်ဆက်မည့် Primary Key Column ဖြစ်ပါသည်။ Primary Key များသည် Product Table တွင် တစ်ကြိမ်သာ ပါဝင်ပြီး Sale Table တွင် ကြိမ်ဖန်များစွာပါဝင်ပါသည်။ ထို့ကြောင့် Product Table သည် One Side Table ဖြစ်ပြီး Sale Table သည် Many Side Table ဖြစ်ပါသည်။ ထိုကဲ့သို့ Table နှစ်ခုချိတ်ဆက်ခြင်းကို One-to-Many Relationship ဟု ခေါ်ဆိုခြင်း ဖြစ်သည်။
အောက်ဖော်ပြပါပုံတွင် One-to-Many Relationship သဘောတရားကို ပို၍ မြင်သာနိုင်ရန် မြှားများဖြင့် ဖော်ပြထားပါသည်။
Many-to-Many Relationship Sample
အောက်တွင်ဖော်ပြထားသည့် Table များမှ Sale Table နှင့် Customer Table တို့အား ချိတ်ဆက် လိုလျင် Customer ID Column အား Primary Column အဖြစ် အသုံးပြု၍ One-to-Many Relationship အဖြစ် ချိတ်ဆက်နိုင်မည် ဖြစ်ပါသည်။
သို့ရာတွင် Customer တစ်ဦးမှ ဝယ်ယူသည့် Product အရေအတွက်ကို တွက်ချက်လိုသည် ဆိုပါစို့။ အထက်ပါ Table များတွင် မြင်တွေ့ ရသည့်အတိုင်း Product Table နှင့် Customer Table အား ချိတ်ဆက်နိုင်မည့် Primary Column မပါရှိသည့်အတွက် Physical Relationship အဖြစ် တိုက်ရိုက် ချိတ်ဆက် မရနိုင်ပါ။ အဆိုပါ Table နှစ်ခုလုံးသည် Sale Table နှင့် Relationship ချိတ်ဆက်ထားသည့်အတွက် ကျနော်တို့ လိုချင်သည့် ရလဒ်ရရှိနိုင်ရန် DAX Formula များ ရေးသားပြီး တွက်ချက်ရယူနိုင်ပါသည်။
ထိုသို့ တွက်ချက်ရာတွင် Product တစ်ခုအား Customer တစ်ဦးထက်ပိုပြီး ဝယ်ယူနိုင်သကဲ့သို့ Customer တစ်ဦးသည်လည်း Product များစွာ ဝယ်ယူနိုင်သည်ကို သတိမူရမည် ဖြစ်ပါသည်။ အထက်ပါ Sale Table စာရင်းအရ Product Table နှင့် Customer Table နှစ်ခုကြား ဆက်စပ်ပတ်သက်မှုကို အောက်ပါအတိုင်း မှန်းဆကြည့်နိုင်သည်။
2.3.1 Relationship အမျိုးအစားများ
အထက်ပါပုံကို လေ့လာကြည့်မည်ဆိုပါက Many-to-Many Relationship သဘောတရားကို မှန်းဆ နားလည်နိုင်မည် ထင်ပါသည်။ ဤ Table နှစ်ခုကြားတွင် Physical Relationship တည်ဆောက်ရန် မဖြစ်နိုင်သည့်အတွက် Many-to-Many Relationship သဘောတရားဖြင့် တွက်ချက် နိုင်ရန် DAX Formula ကို အသုံးပြုရမည် ဖြစ်ပါသည်။ လက်တွေ့သင်ခန်းစာများကို နောက်ပိုင်း သင်ခန်းစာများတွင် ဆက်လက်လေ့လာရမည် ဖြစ်ပါသည်။
One-to-Many Relationship မှာ ပို၍ အသုံးများပါသည်။ Many-to-Many Relationship သည် ပို၍ ခက်ခဲရှုပ်ထွေးသော်လည်း အချို့ အခြေအနေများတွင် ဤ Relationship နည်းဖြင့်သာ အသုံးပြုဖြေရှင်းနိုင်မည် ဖြစ်သည်။
One-to-Many Relationship တွင် Fact Table ( Many-Side ) နှင့် Dimension Table ( One-Side ) နှစ်မျိုးကိုသာ အသုံးပြုပြီး Many-to-Many Relationship တွင် တစ်ခါတစ်ရံ Bridge Table များပါ အသုံးပြုရန်လိုအပ်လေ့ရှိသည်။ One-to-Many Relationship အတွက် Physical Relationship ကို အဓိက အသုံးပြုလေ့ရှိပြီး Many-to-Many Relationship အတွက် Formula ဖြင့် ရေးသားချိတ်ဆက်တွက်ချက်လေ့ရှိပါသည်။
Data Table များတည်ဆောက်ထားပုံနှင့် Relationship ချိတ်ဆက်ပုံ ပေါ်မူတည်၍ Data Model တည်ဆောက်ပုံ အမျိုးအစားများ ကွဲပြားခြားနားနိုင်သည်။ ပုံစံများစွာရှိသည့်အနက်မှ အသုံးများသည့် Star Schema နှင့် Snow Flake ပုံစံနှစ်မျိုးအား အောက်တွင် ဖော်ပြပေးထားပါသည်။
Star schema
အကယ်၍ Data Model အတွင်းတွင် Fact Table တစ်ခုနှင့် အခြား Dimension Table များစွာပါရှိပြီး ပါဝင်သည့် Dimension Table များသည် Fact Table နှင့် Relationship တိုက်ရိုက် ချိတ်ဆက်ထားပါသည် ဆိုပါစို့။ Fact Table အား အလယ်မှာထားရှိပြီး Dimension Table များဖြင့် ဝန်းရံထားသကဲ့သို့ Diagram View တွင် Arrangement ပြုလုပ်နိုင်သည်။ ထိုအခါ Star ပုံစံ Data Model တစ်ခု မြင်တွေ့ရမည် ဖြစ်ပါသည်။ ထို့ကြောင့် ဤကဲ့သို့ Data Model ကို Star Schema ဟု သတ်မှတ်ခေါ်ဝေါ် သုံးစွဲလေ့ရှိသည်။
Star Schema သည် အသုံးအများဆုံး Model Type ဖြစ်ပြီး ကိုင်တွယ်ရသည် မှာလည်း များစွာ အဆင်ပြေသည့် အပြင် DAX Formula ရေးသားတွက်ချက်ရသည်မှာလည်း အခြား Model Type များထက် ပိုမိုလွယ်ကူပါသည်။
2.3.2 Data Model အမျိုးအစားများ
Snowflake schema
Data Model တစ်ခုအတွင်းရှိ အချို့ Dimension Table များမှာ Fact Table နှင့် တိုက်ရိုက် ချိတ်ဆက်မှုမရှိပဲ အခြား Dimension Table နှင့် Relationship ချိတ်ဆက်ရန် လိုအပ်သည့် အခြေအနေမျိုးရှိတတ်သည်။ ထိုကဲ့သို့ Data Model အမျိုးအစားကို Snowflake Schema ဟု သတ်မှတ်ခေါ်ဝေါ်ခြင်း ဖြစ်သည်။
အထက်ပါ Table ( Fact Table ) တွင် Customer Name, Township, Product Name ကဲ့သို့သော Column များတွင် ဒေတာများကို ထပ်ခါ ထပ်ခါ ထည့်သွင်းနေရမည် ဖြစ်သည်။ ထိုကဲ့သို့ ကြိမ်ဖန်များစွာ ထည့်သွင်းနေရမည့် Column များအား Table တစ်ခုတည်းတွင် ထည့်သွင်းထား ခြင်းမှာ မလိုအပ်ပဲ ဖိုင်ဆိုဒ်ကို ကြီးနေစေသကဲ့သို့ ဖြစ်နေသည်။ ထို့အတွက် ဒေတာထည့်သွင်းရမည့် အဓိက Column များကိုသာ Table တွင် ထည့်သွင်းထားပြီး ကျန် ထပ်ခါထပ်ခါထည့်သွင်းရမည့် Column များကို အောက်ပါ အတိုင်း Dimension Table များ အဖြစ် ခွဲထုတ်ပြီး ထို Table များအကြား Relationship ချိတ်ဆက် ပေးခြင်းက ဖိုင်ဆိုဒ်လျော့ကျစေသည့်အပြင် တွက်ချက်မှု Speed လဲများစွာ မြန်ဆန်လာမည်ဖြစ်ပါ သည်။ ထိုကဲ့သို့ Flattened Table များကို သက်ဆိုင်ရာ Dimension Table များအဖြစ်ခွဲထုတ်ပြီး Relationship ချိတ်ဆက်ခြင်းကို Normalization ပြုလုပ်သည် ဟု သတ်မှတ် ခေါ်ဝေါ်ခြင်း ဖြစ်သည်။
Star Schema Model အမျိုးအစားသည် Snow Flake Model အမျိုးအစားထက် ပိုပြီး နားလည်ရ လွယ်ကူကြောင်းနှင့် Formula များရေးသားရာတွင်လည်း မျာစွာ ပိုမိုအဆင်ပြေစေကြောင်း အထက်တွင် ဖော်ပြခဲ့ပြီးဖြစ်ပါသည်။ သို့ဖြစ်၍ Dimension Table အရမ်းမများသည့် Snow Flake Data Model များတွင် Fact Table နှင့် တိုက်ရိုက်မချိတ်ဆက်သည့် Dimension Table များကို လျှော့ချပြီး အဆိုပါ Data များကို Fact Table နှင့် တိုက်ရိုက်ချိတ် ဆက်သည့် Table များတွင် ပေါင်းစပ်ထည့်သွင်းခြင်းဖြင့် Snow Flake မှ Star Schema သို့ ပြောင်းလဲနိုင်သည်။ ထိုကဲ့သို့ Multiple Table မှ အချက်အလက် များကို Table တစ်ခုအတွင်းတွင် ပေါင်းစပ်ထည့်သွင်းခြင်းကို Denormalization ဟု သတ်မှတ် ခေါ်ဝေါ်ခြင်း ဖြစ်သည်။
2.3.3 Normalization and Denormalization
Denormalization
အထက်ပါ ရှင်းလင်းချက်ကို အနှစ်ချုပ်ရလျင်
-
Column များစွာပါသည့် Table တစ်ခုကို သက်ဆိုင်ရာ Data Column များအား ခွဲထုတ်ကာ Table အသေးများစွာအဖြစ် ပြောင်းလဲပြီး Relationship ချိတ်ဆက်၍ Data Modelling ပြုလုပ်ခြင်းကို Normalization ဟု ခေါ်သည်။
-
Table အသီးသီးမှ ဒေတာ Column များကို Table တစ်ခုအတွင်းတွင် Column များ ပေါင်းစပ် ဖွဲ့စည်းခြင်းဖြင့်Data Model အတွင်း Table များ လျှော့ချခြင်းကို Denormalization ဟု ခေါ်သည်။
မည်သည့် နည်းလမ်းသည် ပိုမိုကောင်းမွန်သဖြင့် အသုံးပြုသင့်သည်ဟု တရားသေ သတ်မှတ်၍ မရပါ။ မိမိကိုင်တွယ်ရမည့် ဒေတာအပေါ်မူတည်ပြီး အသုံးပြုသင့်သည့် နည်းလမ်းကို ဆုံးဖြတ်ရန် ဖြစ်သည်။
အောက်ပါ Sale Table တွင် Product Information နှင့် Customer Information Column များ ထည့်သွင်းခြင်းသည် မလိုအပ်ပဲ ဒေတာများကို ထပ်ခါထပ်ခါ ထည့်သွင်းစေရသဖြင့် Table မှာ Column များပြားစွာပါဝင်ပြီး ကိုင်တွယ်ရသည်မှာ မရိုးရှင်းပဲ ဖိုင်ဆိုဒ်လဲ ကြီးစေမည် ဖြစ်သည်။ ဤအခြေ အနေမျိုးတွင် Product Table နှင့် Customer Table နှစ်အခုအဖြစ် သက်ဆိုင်ရာ Column များကို ဆွဲထုတ်ခြင်းက များစွာ အကျိုးရှိစေမည်ဖြစ်သဖြင့် Normalization ပြုလုပ်သင့်သည့် အခြေအနေဟု သတ်မှတ်ယူဆနိုင်သည်။
သို့ရာတွင် အောက်ပါ Table နှစ်ခု ( Product Table နှင့် Product Category ) တွင် Product Category Table ၌ Analyze ပြုလုပ်ရာတွင် အသုံးပြုမည့် Data Column နှစ်ခုသာ ပါရှိပါသည်။ ထို Column နှစ်ခုအတွက် သီးခြား Table တစ်ခု တည်ဆောက်ခြင်းမှာ Data Model တွင် မလိုအပ်ပဲ Table များ ဖောင်းပွစေသည့်အပြင် DAX Formula ရေးသားရာတွင်လည်း မလိုအပ်ပဲ ပိုမိုရှုပ်ထွေးစေ မည် ဖြစ်ပါသည်။
ယေဘုယျအားဖြင့် ပြောရလျင် Table တစ်ခုတွင် Analyze ပြုလုပ်ရာတွင် အသုံးပြုမည့် Column အနည်းငယ်သာ ( <= 3 Columns ) ပါရှိလျင် အခြား ဆက်စပ်ပါတ်သက်သည့် Table တစ်ခုတွင် ပေါင်းစပ်ထည့်သွင်းသင့်၊ Denormalization ပြုလုပ်သင့်ပါသည်။ အကယ်၍ Analyze ပြုလုပ်မည့် Column များ သုံးခုအထက် ပါဝင်နေလျင်တော့ သီးခြား Table အဖြစ်သာ ထားရှိသင့်သည်။ သို့ရာတွင် ဤသည်မှာလည်း အကြမ်းဖျဉ်းသတ်မှတ်ချက်သာဖြစ်ပြီး မိမိ ဒေတာပေါ်တွင် မူတည်ကာ Denormalization လုပ်သင့် မလုပ်သင့် ဆုံးဖြတ်ရမည် ဖြစ်ပါသည်။
After Denormalization
ဆက်လက်လေ့လာရမည့် သင်ခန်းစာ
Normalization
