Agile DWH Design Methodologies ၏ ခြုံငုံသုံးသပ်ချက်

သိုလှောင်ရုံတစ်ခု တည်ဆောက်ခြင်းသည် ရှည်လျားပြီး လေးနက်သော လုပ်ငန်းတစ်ခုဖြစ်သည်။

ပရောဂျက်တစ်ခု၏အသက်တာတွင် များစွာသောအရာဝတ္ထုပုံစံနှင့် အခြေခံတည်ဆောက်ပုံတို့ကို အစတွင် မည်မျှကောင်းမွန်စွာတွေးခေါ်မည်အပေါ်မူတည်ပါသည်။

ယေဘူယျလက်ခံထားသော ချဉ်းကပ်မှုသည် ကြယ်အစီအစဥ်ကို တတိယပုံမှန်ပုံစံနှင့် ပေါင်းစပ်ခြင်း၏ အမျိုးမျိုးသော မူကွဲများ ကျန်ရှိနေသည်။ စည်းမျဉ်းအရ၊ နိယာမအရ - ကနဦးဒေတာ - 3NF၊ showcases - ကြယ်ပွင့်။ သုတေသနပမာဏများစွာဖြင့် အချိန်-စမ်းသပ်ပြီး ပံ့ပိုးပေးထားသည့် ဤချဉ်းကပ်နည်းသည် ခွဲခြမ်းစိတ်ဖြာသောသိုလှောင်မှုပုံစံဖြစ်သင့်သည်ကို တွေးတောသည့်အခါ အတွေ့အကြုံရှိ DWH ပါရဂူတစ်ဦး၏စိတ်ထဲမှာ ပထမဆုံး (တစ်ခါတစ်ရံ တစ်ခုတည်းသော) အရာဖြစ်သည်။

အခြားတစ်ဖက်တွင်၊ ယေဘုယျအားဖြင့် စီးပွားရေးလုပ်ငန်းနှင့် အထူးသဖြင့် ဖောက်သည်လိုအပ်ချက်များသည် လျင်မြန်စွာပြောင်းလဲလေ့ရှိပြီး ဒေတာများသည် “နက်ရှိုင်းသော” နှင့် “အနံ” နှစ်ခုစလုံးတွင် ကြီးထွားလာတတ်သည်။ ဤနေရာတွင် ကြယ်တစ်ပွင့်၏ အဓိကအားနည်းချက်မှာ အကန့်အသတ် ပေါ်လာသည်။ ပြောင်းလွယ်ပြင်လွယ်.

DWH developer တစ်ယောက်အနေဖြင့် သင့်တိတ်ဆိတ်အေးချမ်းသောဘဝတွင် ရုတ်တရက်ဆိုလျှင်၊

• တာဝန်က “အနည်းဆုံး တစ်ခုခုကို မြန်မြန်လုပ်၊ ပြီးရင် ငါတို့တွေ့မယ်”၊
• အရင်းအမြစ်အသစ်များ၏ ချိတ်ဆက်မှုနှင့် လုပ်ငန်းပုံစံကို အနည်းဆုံး တစ်ပတ်လျှင် တစ်ကြိမ် ပြန်လည်လုပ်ဆောင်ခြင်းဖြင့် လျင်မြန်စွာ ဖွံ့ဖြိုးတိုးတက်နေသော ပရောဂျက်တစ်ခု ပေါ်လာသည်။
• ဖောက်သည်တစ်ဦးသည် စနစ်၏ပုံသဏ္ဍာန်နှင့် နောက်ဆုံးတွင် ၎င်းလုပ်ဆောင်သင့်သည့်လုပ်ဆောင်ချက်များကို မသိရှိသော်လည်း ၎င်းနှင့်နီးကပ်လာစဉ်တွင် အလိုရှိသောရလဒ်ကို အဆက်မပြတ်ပြန်လည်ပြင်ဆင်ရန် အဆင်သင့်ဖြစ်နေပြီဖြစ်သည်။
• ပရောဂျက်မန်နေဂျာသည် သတင်းကောင်းဖြင့် “ယခုကျွန်ုပ်တို့ သွက်လက်လာပြီ!”

သို့မဟုတ် သိုလှောင်ရုံများကို သင်မည်ကဲ့သို့ တည်ဆောက်နိုင်သည်ကို သင်စိတ်ဝင်စားပါက၊ ဖြတ်တောက်ခြင်းမှ ကြိုဆိုပါတယ်။

"ပြောင်းလွယ်ပြင်လွယ်" ဆိုသည်မှာ အဘယ်နည်း။

ဦးစွာ၊ “ပြောင်းလွယ်ပြင်လွယ်” ​​ဟုခေါ်ရန်အတွက် စနစ်တစ်ခုတွင် မည်သည့်ဂုဏ်သတ္တိများ ရှိရမည်ကို သတ်မှတ်ကြပါစို့။

သီးခြားဖော်ပြထားသည်မှာ ဖော်ပြထားသော ဂုဏ်သတ္တိများနှင့် အထူးဆက်စပ်သင့်သည်ဟု မှတ်သားထိုက်ပါသည်။ စနစ်မဟုတ်ဘူး၊ လုပ်ငန်းစဉ် ၎င်း၏ဖွံ့ဖြိုးတိုးတက်မှု။ ထို့ကြောင့် Agile ကို ဖွံ့ဖြိုးတိုးတက်ရေး နည်းစနစ်တစ်ခုအနေဖြင့် ဖတ်လိုပါက အခြားဆောင်းပါးများကို ဖတ်ရှုခြင်းက ပိုကောင်းပါတယ်။ ဥပမာအားဖြင့်၊ Habré တွင်၊ ထိုနေရာတွင် စိတ်ဝင်စားစရာကောင်းသော အကြောင်းအရာများစွာရှိသည် (ကဲ့သို့သော သုံးသပ်ချက် и လက်တွေ့နှင့် ပြဿနာရှိသော).

၎င်းသည် ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်နှင့် ဒေတာဂိုဒေါင်၏ဖွဲ့စည်းပုံနှင့် လုံးဝသက်ဆိုင်သည်ဟု မဆိုလိုပါ။ ယေဘုယျအားဖြင့်၊ သွက်လက်သောဗိသုကာတစ်ခုအတွက် Agile repository ကို တီထွင်ရန် သိသိသာသာပိုမိုလွယ်ကူသင့်သည်။ သို့သော်၊ လက်တွေ့တွင်၊ Kimbal နှင့် DataVault အရ Kimbal နှင့် DataVault အရ ဂန္ထဝင် DWH ၏ Agile ဖွံ့ဖြိုးတိုးတက်မှုတွင် ရွေးချယ်စရာများပိုများသည် - Waterfall အရ၊ ပရောဂျက်တစ်ခုတွင် ၎င်း၏ပုံစံနှစ်မျိုးရှိ လိုက်လျောညီထွေဖြစ်မှု၏ ပျော်ရွှင်ဖွယ်တိုက်ဆိုင်မှုများထက် မကြာခဏဖြစ်သည်။

ဒါဆို၊ ပြောင်းလွယ်ပြင်လွယ် သိုလှောင်မှုမှာ ဘယ်လိုစွမ်းဆောင်ရည်တွေ ရှိသင့်သလဲ။ ဤနေရာတွင် အချက်သုံးချက်ရှိသည်။

1. စောလျင်စွာ ပေးပို့ခြင်းနှင့် အမြန်လွှဲပြောင်းပေးခြင်း - ဆိုလိုသည်မှာ စနစ်တစ်ခုလုံးကို အပြည့်အဝ ဒီဇိုင်းဆွဲပြီး အကောင်အထည်မဖော်မီတွင်ပင် ပထမဆုံး လုပ်ငန်းရလဒ် (ဥပမာ၊ ပထမဆုံး အလုပ်အစီရင်ခံစာများ) ကို တတ်နိုင်သမျှ စောစီးစွာ ရယူသင့်သည်ဟု ဆိုလိုပါသည်။ ထို့အပြင်၊ နောက်ဆက်တွဲပြန်လည်ပြင်ဆင်မှုတစ်ခုစီသည် တတ်နိုင်သမျှ အချိန်အနည်းငယ်ယူသင့်သည်။
2. ထပ်ခါထပ်ခါ သန့်စင်ခြင်း။ - ဆိုလိုသည်မှာ နောက်ဆက်တွဲတိုးတက်မှုတစ်ခုစီသည် လုပ်ဆောင်နေပြီးဖြစ်သော လုပ်ဆောင်နိုင်စွမ်းကို မထိခိုက်စေသင့်ပါ။ ဤအခိုက်အတန့်သည် ပရောဂျက်ကြီးများတွင် အကြီးမားဆုံးအိပ်မက်ဆိုးတစ်ခု ဖြစ်လာတတ်သည် - များမကြာမီ သို့မဟုတ် နောက်ပိုင်းတွင်၊ အရာဝတ္ထုတစ်ခုချင်းစီသည် ချိတ်ဆက်မှုများစွာကို စတင်ရရှိလာသောကြောင့် ၎င်းသည် ရှိပြီးသားဇယားတစ်ခုသို့ အကွက်တစ်ခုထည့်ခြင်းထက် အနီးနားရှိကော်ပီတစ်ခုတွင် ယုတ္တိဗေဒကို လုံးဝပြန်လုပ်ရန် ပိုမိုလွယ်ကူလာသည်။ လက်ရှိအရာဝတ္ထုများအပေါ် တိုးတက်မှုများ၏ အကျိုးသက်ရောက်မှုကို ခွဲခြမ်းစိတ်ဖြာခြင်းသည် ၎င်းတို့ကိုယ်တိုင် တိုးတက်မှုထက် အချိန်ပိုကြာနိုင်သည်ကို သင်အံ့သြမိပါက၊ သင်သည် ဘဏ်လုပ်ငန်း သို့မဟုတ် တယ်လီကွန်းများရှိ ဒေတာသိုလှောင်ရုံကြီးများနှင့် အလုပ်မလုပ်သေးပါ။
3. ပြောင်းလဲနေသော လုပ်ငန်းလိုအပ်ချက်များနှင့် အဆက်မပြတ် လိုက်လျောညီထွေနေပါ။ - ဖြစ်နိုင်ချေရှိသော ချဲ့ထွင်မှုကို ထည့်သွင်းစဉ်းစားရုံမျှမက အရာဝတ္ထုတစ်ခုလုံး၏ ဖွဲ့စည်းပုံကို ဒီဇိုင်းထုတ်သင့်သည်၊ သို့သော် ဤနောက်ထပ်ချဲ့ထွင်မှု၏ ဦးတည်ချက်ကို ဒီဇိုင်းအဆင့်တွင်ပင် စိတ်ကူးမယဉ်နိုင်ပါ။

ဟုတ်ပါသည်၊ ဤလိုအပ်ချက်အားလုံးကို စနစ်တစ်ခုတွင် ဖြည့်ဆည်းပေးနိုင်သည် (ဟုတ်ပါတယ်၊ အချို့သောကိစ္စများတွင်၊ အချို့သော ကြိုတင်စာရင်းသွင်းမှုများဖြင့်)။

အောက်တွင် ကျွန်ုပ်သည် ဒေတာသိုလှောင်ရုံများအတွက် ရေပန်းအစားဆုံး ပေါ့ပါးသွက်လက်သော ဒီဇိုင်းနည်းစနစ်နှစ်ခုကို သုံးသပ်ပါမည်။ Anchor မော်ဒယ် и Data Vault. ဥပမာအားဖြင့် EAV၊ 6NF (၎င်း၏စစ်မှန်သောပုံစံဖြင့်) နှင့် NoSQL ဖြေရှင်းချက်များနှင့်ပတ်သက်သည့်အရာအားလုံးသည် အလွန်ကောင်းမွန်သောနည်းပညာများဖြစ်သည် - ၎င်းတို့သည် တစ်နည်းနည်းဖြင့် ပိုဆိုးသောကြောင့်မဟုတ်ပါ၊ ဤကိစ္စတွင် ဆောင်းပါးသည် ရယူရန် ခြိမ်းခြောက်နေသောကြောင့်ပင်မဟုတ်ပါ၊ ပျမ်းမျှ disser ၏အသံအတိုးအကျယ်။ ဤအရာအားလုံးသည် အနည်းငယ်ကွဲပြားသော လူတန်းစား၏ ဖြေရှင်းချက်များနှင့် သက်ဆိုင်သည် - သင့်ပရောဂျက်၏ အလုံးစုံတည်ဆောက်ပုံ (EAV ကဲ့သို့) မသက်ဆိုင်ဘဲ သီးခြားကိစ္စများတွင် သင်အသုံးပြုနိုင်သည့် နည်းပညာများနှင့် သို့မဟုတ် ကမ္ဘာလုံးဆိုင်ရာ အခြားသော အချက်အလက်သိမ်းဆည်းမှုဆိုင်ရာ စံနှုန်းများနှင့် သက်ဆိုင်သည် (ဥပမာ ဂရပ်ဒေတာဘေ့စ်များကဲ့သို့၊ နှင့် အခြားရွေးချယ်စရာ NoSQL)။

“ဂန္ထဝင်” ချဉ်းကပ်မှုဆိုင်ရာ ပြဿနာများနှင့် လိုက်လျောညီထွေရှိသော နည်းလမ်းများတွင် ၎င်းတို့၏ ဖြေရှင်းနည်းများ

"ဂန္ထဝင်" ချဉ်းကပ်မှုအားဖြင့် ကျွန်ုပ်ဆိုလိုသည်မှာ ကြယ်ပွင့်ကောင်း (အခြေခံအလွှာများကို အတိအကျ အကောင်အထည်ဖော်မှု မည်သို့ပင်ဖြစ်စေ Kimball၊ Inmon နှင့် CDM တို့၏ နောက်လိုက်များက ကျွန်ုပ်ကို ခွင့်လွှတ်နိုင်ပါစေ)။

1. ချိတ်ဆက်မှုများ၏ တောင့်တင်းသော ကာဒီနယ်လစ်

ဤပုံစံသည် အချက်အလက်များကို ရှင်းရှင်းလင်းလင်း ခွဲဝေမှုအပေါ် အခြေခံထားသည်။ အတိုင်းအတာ и အချက်အလက်. ဤအရာသည် ယုတ္တိကျပါသည်၊ ခြုံငုံမိသော ကိစ္စများတွင် ဒေတာခွဲခြမ်းစိတ်ဖြာခြင်းသည် အချို့သော ကဏ္ဍများ (အတိုင်းအတာ) ရှိ အချို့သော ကိန်းဂဏာန်းညွှန်းကိန်းများ (အချက်အလက်) ခွဲခြမ်းစိတ်ဖြာခြင်းမှ ဆင်းသက်လာသည်။

ဤကိစ္စတွင်၊ အရာဝတ္ထုများအကြား ချိတ်ဆက်မှုများကို နိုင်ငံခြားသော့ကို အသုံးပြု၍ ဇယားများကြား ဆက်ဆံရေးပုံစံဖြင့် တည်ဆောက်ထားသည်။ ဒါက အတော်လေး သဘာဝကျပုံရတယ်၊ ဒါပေမယ့် ပျော့ပြောင်းမှုရဲ့ ပထမဆုံး ကန့်သတ်ချက်ကို ချက်ချင်း ဖြစ်ပေါ်စေတယ်။ ဆက်သွယ်မှုများ၏ တိကျသော အဓိပ္ပါယ်ဖွင့်ဆိုချက်.

ဆိုလိုသည်မှာ ဇယားဒီဇိုင်းအဆင့်တွင်၊ ဆက်စပ်အရာဝတ္ထုအတွဲတစ်ခုစီအတွက် ၎င်းတို့သည် များစွာမှတစ်ခုသို့ ဆက်စပ်နိုင်သည် သို့မဟုတ် 1-ntau နှင့် “မည်သည့်ဦးတည်ချက်တွင်” တို့ကို တိကျစွာဆုံးဖြတ်ရမည်ဖြစ်သည်။ ၎င်းသည် မည်သည့်ဇယားတွင် အဓိကသော့ရှိမည်ဖြစ်ပြီး မည်သည့်နိုင်ငံခြားသော့ရှိမည်ကို တိုက်ရိုက်ဆုံးဖြတ်သည်။ လိုအပ်ချက်အသစ်များကို လက်ခံရရှိသောအခါတွင် ဤသဘောထားကို ပြောင်းလဲခြင်းသည် အခြေခံ၏ ပြန်လည်ပြုပြင်ခြင်းဆီသို့ ဦးတည်သွားနိုင်သည်။

ဥပမာအားဖြင့်၊ "ငွေလက်ခံဖြတ်ပိုင်း" အရာဝတ္တုကို ဒီဇိုင်းဆွဲသောအခါ၊ သင်သည် အရောင်းဌာန၏ ကျိန်ဆိုချက်များကို အားကိုးပြီး လုပ်ဆောင်နိုင်ခြေကို ချမှတ်ခဲ့သည်။ စစ်ဆေးမှုရာထူးများစွာအတွက် ပရိုမိုးရှင်းတစ်ခု (သို့သော် အပြန်အလှန်မဟုတ်ပါ)။

အချိန်အတော်ကြာပြီးနောက်၊ လုပ်ဖော်ကိုင်ဖက်များသည် တူညီသောအနေအထားတွင် လုပ်ဆောင်နိုင်သည့် စျေးကွက်ရှာဖွေရေးဗျူဟာအသစ်ကို မိတ်ဆက်ပေးခဲ့သည်။ တစ်ချိန်တည်းမှာ ပရိုမိုးရှင်းပေါင်းများစွာ. ယခုတွင် သင်သည် ဆက်နွယ်မှုကို သီးခြားအရာဝတ္ထုတစ်ခုအဖြစ် ပိုင်းခြားခြင်းဖြင့် ဇယားများကို ပြင်ဆင်ရန် လိုအပ်သည်။

(ယခု ပရိုမိုးရှင်းစစ်ဆေးမှုတွင် ပါဝင်ထားသည့် ဆင်းသက်လာသော အရာများအားလုံးကိုလည်း မြှင့်တင်ရန် လိုအပ်ပါသည်။)

Data Vault နှင့် Anchor Model ရှိ ဆက်စပ်မှုများ

ဤအခြေအနေကို ရှောင်ကြဉ်ခြင်းသည် အလွန်ရိုးရှင်းသည်- ဤသို့လုပ်ဆောင်ရန် အရောင်းဌာနကို ယုံကြည်ရန် မလိုအပ်ပါ။ ချိတ်ဆက်မှုအားလုံးကို အစပိုင်းတွင် သီးခြားဇယားများတွင် သိမ်းဆည်းထားသည်။ ၎င်းကို အများအပြားမှ အများအပြားလုပ်ဆောင်ပါ။

ဤချဉ်းကပ်မှုကို အဆိုပြုခဲ့သည်။ Dan Linstedt ပါရာဒိုင်း၏တစ်စိတ်တစ်ပိုင်းအဖြစ် Data Vault အပြည့်အဝထောက်ခံပါတယ်။ Lars Rönnbäck в Anchor Model ပါ။.

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် ပြောင်းလွယ်ပြင်လွယ်သောနည်းလမ်းများ၏ ပထမဆုံးထူးခြားသောအင်္ဂါရပ်ကို ရရှိပါသည်-

အရာဝတ္တုများကြားရှိ ဆက်စပ်မှုများကို ပင်မအရာဝတ္တုများ၏ ရည်ညွှန်းချက်များတွင် သိမ်းဆည်းမထားသော်လည်း သီးခြားအရာဝတ္ထုတစ်ခုဖြစ်သည်။

В Data Vault ထိုကဲ့သို့ linking table များကို ခေါ်သည်။ လင့်ခ်နှင့် Anchor Model ပါ။ - လည်စည်း. ပထမတစ်ချက်တွင်၊ ၎င်းတို့၏ကွဲလွဲချက်များသည် အမည်နှင့်အဆုံးမသတ်သော်လည်း (အောက်တွင်ဆွေးနွေးမည့်) အလွန်ဆင်တူပါသည်။ ဗိသုကာ နှစ်ခုလုံးတွင် လင့်ဇယားများ ချိတ်ဆက်နိုင်သည်။ မည်သည့် entities အရေအတွက် (၂) မလိုအပ်ပါ။

ပထမတစ်ချက်တွင်၊ ဤအထပ်ထပ်သည် ပြုပြင်မွမ်းမံမှုအတွက် သိသာထင်ရှားသော ပြောင်းလွယ်ပြင်လွယ်ကို ပေးဆောင်သည်။ ထိုသို့သောဖွဲ့စည်းပုံသည် ရှိပြီးသားလင့်ခ်များ၏ cardinality အပြောင်းအလဲအတွက်သာမက အသစ်များ ထပ်တိုးခြင်းကိုလည်း ခံနိုင်ရည်ရှိလာသည် - အကယ်၍ ယခု ချက်လက်မှတ်တစ်ခုတွင် ၎င်းကိုဖွင့်သော ငွေကိုင်သူထံ လင့်ခ်တစ်ခုပါရှိနေပါက၊ ထိုလင့်ခ်၏ အသွင်အပြင်သည် ရိုးရိုးရှင်းရှင်းဖြစ်သွားပါလိမ့်မည်။ ရှိပြီးသား အရာဝတ္ထုများနှင့် လုပ်ငန်းစဉ်များကို မထိခိုက်စေဘဲ ရှိပြီးသား ဇယားများပေါ်တွင် အပိုပရိုဂရမ်တစ်ခု။

2. Data ပွားခြင်း။

လိုက်လျောညီထွေရှိသော ဗိသုကာလက်ရာများဖြင့် ဖြေရှင်းသော ဒုတိယပြဿနာမှာ ထင်ရှားနည်းပါးပြီး ပထမနေရာတွင် တည်ရှိနေသည်။ SCD2 အမျိုးအစား တိုင်းတာခြင်း (ဒုတိယအမျိုးအစား၏ အတိုင်းအတာများကို ဖြည်းဖြည်းချင်းပြောင်းလဲခြင်း) ၎င်းတို့သာမက။

ဂန္ထဝင်ဂိုဒေါင်တစ်ခုတွင်၊ အတိုင်းအတာသည် ပုံမှန်အားဖြင့် အငှားသော့ (PK အဖြစ်) နှင့် သီးခြားကော်လံများတွင် လုပ်ငန်းကီးများနှင့် ရည်ညွှန်းချက်များပါရှိသော ဇယားတစ်ခုဖြစ်သည်။

အတိုင်းအတာတစ်ခုသည် ဗားရှင်းပြောင်းလဲခြင်းကို ပံ့ပိုးပါက၊ ဗားရှင်း၏တရားဝင်မှုဘောင်များကို စံကွက်လပ်အစုံတွင် ပေါင်းထည့်မည်ဖြစ်ပြီး အရင်းအမြစ်ရှိ အတန်းတစ်ခုအတွက်၊ သိုလှောင်မှုတွင် ဗားရှင်းများစွာ ပေါ်လာသည် (ဗားရှင်းပြုလုပ်ထားသည့် အရည်အချင်းတစ်ခုစီအတွက် ဗားရှင်းတစ်ခုစီ) ပေါ်လာသည်။

အတိုင်းအတာတစ်ခုတွင် အနည်းဆုံး မကြာခဏပြောင်းလဲနေသော ဗားရှင်းရှိ ရည်ညွှန်းချက်တစ်ခု ပါဝင်နေပါက၊ ထိုသို့သော အတိုင်းအတာ၏ ဗားရှင်းအရေအတွက်သည် အထင်ကြီးစရာဖြစ်လိမ့်မည် (ကျန်ရှိသော အင်္ဂါရပ်များကို ဗားရှင်းမွမ်းမံထားလျှင် သို့မဟုတ် ဘယ်တော့မှ မပြောင်းလဲသော်လည်း) နှင့် ထိုသို့သော အရည်အချင်းများစွာရှိလျှင် ဗားရှင်းအရေအတွက် လုပ်နိုင်သည် သူတို့ရဲ့ အရေအတွက်ကနေ အဆတိုးလာပါတယ်။ ၎င်းသိမ်းဆည်းထားသည့် ဒေတာအများစုသည် အခြားအတန်းများမှ မပြောင်းလဲနိုင်သော attribute တန်ဖိုးများ ထပ်တူနေသော်လည်း၊ ဤအတိုင်းအတာသည် သိသိသာသာ disk space ကို ယူနိုင်သည်။

တစ်ချိန်တည်းမှာပင် ၎င်းကို အလွန်အသုံးများသည်။ ပုံမှန်မဟုတ်ခြင်း — အချို့သော attribute များကို ရည်ညွှန်းစာအုပ် သို့မဟုတ် အခြားအတိုင်းအတာတစ်ခုသို့ လင့်ခ်တစ်ခုအဖြစ် မဟုတ်ဘဲ တန်ဖိုးတစ်ခုအဖြစ် ရည်ရွယ်ချက်ရှိရှိ သိမ်းဆည်းထားသည်။ ဤချဉ်းကပ်မှုသည် အတိုင်းအတာတစ်ခုသို့ဝင်ရောက်သည့်အခါ ပါဝင်မှုအရေအတွက်ကို လျှော့ချပြီး ဒေတာဝင်ရောက်မှုကို အရှိန်မြှင့်ပေးသည်။

အများအားဖြင့်၊ တူညီသော အချက်အလက်များကို နေရာများစွာတွင် တပြိုင်နက် သိမ်းဆည်းထားသည်။. ဥပမာအားဖြင့်၊ နေထိုင်ရာဒေသနှင့် ဖောက်သည်၏အမျိုးအစားအကြောင်း အချက်အလက်များကို "Client" အတိုင်းအတာများနှင့် "ဝယ်ယူခြင်း"၊ "ပေးပို့ခြင်း" နှင့် "Call Center ခေါ်ဆိုမှုများ" ဖြစ်ရပ်မှန်များအပြင် "Client - Client Manager တွင် တစ်ပြိုင်နက် သိမ်းဆည်းနိုင်ပါသည်။ "လင့်ဇယား။

ယေဘုယျအားဖြင့်၊ အထက်တွင်ဖော်ပြထားသည့်အရာများသည် ပုံမှန် (ဗားရှင်းမဟုတ်သော) အတိုင်းအတာများနှင့် သက်ဆိုင်သော်လည်း ဗားရှင်းပုံစံများတွင် ၎င်းတို့တွင် မတူညီသောစကေးရှိနိုင်သည်- အရာဝတ္ထုတစ်ခု၏ ဗားရှင်းအသစ်တစ်ခု၏ အသွင်အပြင်သည် (အထူးသဖြင့် နောက်ကြောင်းပြန်ကြည့်ရာတွင်) ဆက်စပ်မှုအားလုံးကို အပ်ဒိတ်လုပ်ရုံသာမက၊ Table 1 ကိုတည်ဆောက်သည့်အခါတွင် Table 2 ကိုအသုံးပြုပြီး Table 2 နှင့် Table 3 ကိုတည်ဆောက်ရန်အတွက် Table 1 ကိုအသုံးပြုသောအခါတွင်ဆက်စပ်အရာဝတ္ထုအသစ်များ၏ဗားရှင်းအသစ်များ၏ cascading အသွင်အပြင်ကိုအသုံးပြုသည်။ Table 3 ၏ ရည်ညွှန်းချက်တစ်ခုတည်းသည် Table 2 တည်ဆောက်မှုတွင် မပါဝင်သော်လည်း (အခြားရင်းမြစ်များမှရရှိသော Table 3 ၏အခြားသောဂုဏ်ရည်များပါဝင်သည်)၊ ဤတည်ဆောက်မှုပုံစံကို ပြုလုပ်ခြင်းဖြင့် အနည်းဆုံးအားဖြင့် အပိုဆောင်းအပိုဆောင်းဆီသို့ ဦးတည်သွားမည်ဖြစ်ပြီး အမြင့်ဆုံးမှ အပိုအထိ ဇယား XNUMX တွင် ဗားရှင်းများနှင့် လုံးဝသက်ဆိုင်ခြင်းမရှိသည့်အပြင် ကွင်းဆက်အောက်သို့ ဆင်းသွားပါသည်။

3. ပြန်လည်လုပ်ဆောင်ခြင်း၏ မျဉ်းဖြောင့်မဟုတ်သော ရှုပ်ထွေးမှု

တစ်ချိန်တည်းမှာပင်၊ အခြားတစ်ခုအပေါ်အခြေခံ၍ တည်ဆောက်ထားသော စတိုးဆိုင်အသစ်တစ်ခုစီသည် ETL သို့ ပြောင်းလဲမှုများပြုလုပ်သောအခါ ဒေတာ “ကွဲပြားနိုင်သည်” ဆိုသည့် နေရာအရေအတွက်ကို တိုးစေသည်။ ၎င်းသည် နောက်ဆက်တွဲပြန်လည်ပြင်ဆင်မှုတစ်ခုစီ၏ ရှုပ်ထွေးမှု (နှင့် ကြာချိန်) တိုးလာစေသည်။

အထက်ဖော်ပြပါ ပြုပြင်မွမ်းမံခဲသော ETL လုပ်ငန်းစဉ်များပါသည့် စနစ်များကို ဖော်ပြပါက၊ သင်သည် ထိုကဲ့သို့သော ပါရာဒိုင်းတွင် နေထိုင်နိုင်သည် - ဆက်စပ်အရာဝတ္တုအားလုံးအတွက် ပြုပြင်မွမ်းမံမှုအသစ်များကို မှန်ကန်စွာပြုလုပ်ထားကြောင်း သေချာစေရန်လိုအပ်ပါသည်။ ပြန်လည်ပြင်ဆင်မှုများ မကြာခဏဖြစ်ပေါ်ပါက၊ မတော်တဆဆက်သွယ်မှုအများအပြား "ပျောက်ဆုံးခြင်း" ဖြစ်နိုင်ခြေ သိသိသာသာတိုးလာပါသည်။

ထို့အပြင်၊ "ဗားရှင်း" ETL သည် "ဗားရှင်းမဟုတ်သော" တစ်ခုထက်သိသိသာသာပိုမိုရှုပ်ထွေးသည်ဟုကျွန်ုပ်တို့ထည့်သွင်းစဉ်းစားပါက၊ ဤစက်ရုံတစ်ခုလုံးကိုမကြာခဏမွမ်းမံသည့်အခါအမှားများကိုရှောင်ရှားရန်အတော်လေးခက်ခဲလာသည်။

Data Vault နှင့် Anchor Model တွင် အရာဝတ္ထုများနှင့် အရည်အချင်းများကို သိမ်းဆည်းခြင်း။

လိုက်လျောညီထွေရှိသော ဗိသုကာပညာရှင်များမှ အဆိုပြုထားသော ချဉ်းကပ်နည်းကို အောက်ပါအတိုင်း ပုံဖော်နိုင်ပါသည်။

ဘယ်အရာက ပြောင်းလဲနေလဲ ဆိုတာကို ခွဲခြားထားဖို့ လိုပါတယ်။ ဆိုလိုသည်မှာ၊ attribute များမှ သီးခြားသော့များကို သိမ်းဆည်းပါ။

သို့သော် တစ်ဦးတည်း မရောထွေးသင့်ပါ။ ဗားရှင်းမထားပါ။ attribute တို့နဲ့ မပြောင်းလဲ− ပထမတစ်ခုသည် ၎င်း၏ပြောင်းလဲမှုများ၏သမိုင်းကို သိမ်းဆည်းမထားသော်လည်း ပြောင်းလဲနိုင်သည် (ဥပမာ၊ ထည့်သွင်းမှုအမှားတစ်ခုကို ပြုပြင်သည့်အခါ သို့မဟုတ် ဒေတာအသစ်လက်ခံရရှိခြင်း)၊ ဒုတိယတစ်ခုသည် မည်သည့်အခါမျှ ပြောင်းလဲခြင်းမရှိပါ။

Data Vault နှင့် Anchor Model တွင် အတိအကျ မပြောင်းလဲနိုင်ဟု ယူဆနိုင်သည့် ရှုထောင့်များ ကွဲပြားသည်။

ဗိသုကာအမြင်ကနေ Data Vaultမပြောင်းလဲဟု ယူဆနိုင်ပါသည်။ သော့အစုံ - သဘာဝ (အဖွဲ့အစည်း၏ TIN၊ အရင်းအမြစ်စနစ်ရှိ ထုတ်ကုန်ကုဒ် စသည်ဖြင့်) နှင့် အငှားချပါ။ ဤကိစ္စတွင်၊ ပြောင်းလဲမှုများ၏ အရင်းအမြစ်နှင့်/သို့မဟုတ် အကြိမ်ရေအလိုက် ကျန်ရှိသော attribute များကို အုပ်စုများအဖြစ် ခွဲခြားနိုင်ပြီး၊ အုပ်စုတစ်ခုစီအတွက် သီးခြားဇယားတစ်ခုထားရှိပါ။ သီးခြားဗားရှင်းများနှင့်အတူ။

နို်င်ငံ Anchor Model ပါ။ မပြောင်းလဲဟု ယူဆပါသည်။ surrogate key ပဲရှိတယ်။ အနှစ်သာရ, အချုပ်။ အခြားအရာအားလုံး (သဘာဝသော့များအပါအဝင်) သည် ၎င်း၏ဂုဏ်ရည်တော်များ၏ အထူးကိစ္စရပ်တစ်ခုဖြစ်သည်။ ဓမ္မဒူတ အရည်အချင်းအားလုံးသည် ပုံသေအားဖြင့် တစ်ခုနှင့်တစ်ခု သီးခြားဖြစ်သည်။ထို့ကြောင့် attribute တစ်ခုစီအတွက် သီးခြားစားပွဲ.

В Data Vault entity သော့များပါရှိသော ဇယားများကို ခေါ်သည်။ Hubami. Hubs တွင် ပုံသေသတ်မှတ်ထားသော အကွက်များ အမြဲပါရှိပါသည်။

• သဘာဝအလျောက်သော့များ
• အငှားချကီး
• အရင်းအမြစ်သို့ ချိတ်ဆက်ပါ။
• ထည့်ချိန်ကို မှတ်တမ်းတင်ပါ။

Hubs ရှိ ပို့စ်များ ဘယ်တော့မှ မပြောင်းဘဲ ဗားရှင်းများ မရှိပါ။. ပြင်ပတွင်၊ hubs များသည် အချို့သောစနစ်များတွင်အသုံးပြုသော ID-map အမျိုးအစားဇယားများနှင့် အလွန်ဆင်တူသော်လည်း၊ Data Vault တွင် အငှားကိုယ်စားလှယ်များအဖြစ် လုပ်ငန်းကီးအစုတစ်ခုမှ hash တစ်ခုကို အသုံးပြုရန် အကြံပြုထားသည်။ ဤနည်းလမ်းသည် ရင်းမြစ်များမှ ဆက်ဆံရေးနှင့် ရည်ညွှန်းချက်များကို ရိုးရှင်းလွယ်ကူစေသည် (အငှားတစ်ခုရရန် hub တွင်ပါဝင်ရန်မလိုအပ်ပါ၊ သဘာဝကီးတစ်ခု၏ hash ကို တွက်ချက်ရုံသာ)၊ သို့သော် အခြားပြဿနာများ (ဥပမာ၊ ဆက်စပ်၊ တိုက်မိခြင်း၊ ဖြစ်ရပ်မှန်နှင့် ပုံနှိပ်မရနိုင်သော ပြဿနာများကို ဖြစ်စေနိုင်သည်။ string keys စသည်တို့တွင် စာလုံးများ .p.) ထို့ကြောင့် ၎င်းကို ယေဘူယျအားဖြင့် လက်မခံပါ။

အခြားသော entity attribute အားလုံးကို ခေါ်သော အထူးဇယားများတွင် သိမ်းဆည်းထားသည်။ ဂြိုလ်တုများ. hub တစ်ခုတွင် မတူညီသော attribute အစုံကို သိမ်းဆည်းထားသော ဂြိုလ်တုများစွာ ရှိနိုင်ပါသည်။

ဂြိုလ်တုများအကြား ဂုဏ်တော်များ ဖြန့်ဝေခြင်းသည် နိယာမအရ ဖြစ်ပေါ်သည်။ ပူးတွဲပြောင်းလဲမှု — ဂြိုလ်တု၏ဗားရှင်းမဟုတ်သော attribute တစ်ခုတွင် (ဥပမာ- မွေးသက္ကရာဇ်နှင့် တစ်ဦးချင်းစီအတွက် SNILS) ကို သိမ်းဆည်းထားနိုင်သည်၊ နောက်တစ်ခုတွင်- ဗားရှင်းပြောင်းခဲသည့်အရာများ (ဥပမာ၊ အမည်နှင့် နိုင်ငံကူးလက်မှတ်နံပါတ်)၊ တတိယတွင်- မကြာခဏပြောင်းလဲနေပါသည်။ (ဥပမာ၊ ပေးပို့ရမည့်လိပ်စာ၊ အမျိုးအစား၊ နောက်ဆုံးမှာယူသည့်ရက်စွဲ၊ စသည်ဖြင့်)။ ဤကိစ္စတွင်၊ ဂြိုဟ်တုတစ်ခုစီ၏အဆင့်တွင် ဗားရှင်းတင်ခြင်းကို လုပ်ဆောင်သည်မဟုတ်ဘဲ တစ်ခုလုံးအတွက်မဟုတ်ဘဲ၊ ထို့ကြောင့် ဂြိုလ်တုတစ်ခုအတွင်းရှိဗားရှင်းများ၏လမ်းဆုံကို အနည်းငယ်မျှသာဖြစ်စေရန် ရည်ညွှန်းချက်များကို ဖြန့်ဝေရန် အကြံပြုလိုပါသည် (သိမ်းဆည်းထားသောဗားရှင်းစုစုပေါင်းအရေအတွက်ကို လျှော့ချပေးသည်။ )

ထို့အပြင်၊ ဒေတာတင်ခြင်းလုပ်ငန်းစဉ်ကို အကောင်းဆုံးဖြစ်အောင်၊ အမျိုးမျိုးသောရင်းမြစ်များမှရရှိသော attribute များကို ဂြိုလ်တုတစ်ခုချင်းစီတွင် ထည့်သွင်းလေ့ရှိသည်။

ဂြိုလ်တုများသည် Hub မှတဆင့် ဆက်သွယ်သည်။ နိုင်ငံခြားသော့ (၁-မှ-များစွာသော ကာဒီနယ်လီနှင့် သက်ဆိုင်သည်)။ ဆိုလိုသည်မှာ များစွာသော attribute တန်ဖိုးများ (ဥပမာ၊ client တစ်ခုအတွက် အဆက်အသွယ် ဖုန်းနံပါတ်များစွာ) ကို ဤ "မူလ" ဗိသုကာမှ ပံ့ပိုးထားပါသည်။

В Anchor Model ပါ။ သော့များသိမ်းဆည်းသော ဇယားများကို ခေါ်သည်။ ကျောက်ဆူးများ. ပြီးတော့ သူတို့က

• အငှားသော့များသာ
• အရင်းအမြစ်သို့ ချိတ်ဆက်ပါ။
• ထည့်ချိန်ကို မှတ်တမ်းတင်ပါ။

Anchor Model ၏ ရှုထောင့်မှ သဘာဝသော့များကို ထည့်သွင်းစဉ်းစားသည်။ သာမန်ဂုဏ်ရည်များ. ဤရွေးချယ်မှုသည် နားလည်ရန် ပိုခက်ခဲပုံရသည်၊ သို့သော် ၎င်းသည် အရာဝတ္တုကို ဖော်ထုတ်ရန်အတွက် နယ်ပယ်များစွာကို ပေးဆောင်သည်။

ဥပမာအားဖြင့်၊ တူညီသည့်အရာနှင့်ပတ်သက်သည့် ဒေတာများသည် မတူညီသောစနစ်များမှ လာပါက၊ တစ်ခုချင်းစီသည် ၎င်း၏ကိုယ်ပိုင်သဘာဝသော့ကို အသုံးပြုသည်။ Data Vault တွင်၊ ၎င်းသည် များစွာသော hubs (အရင်းအမြစ်တစ်ခုလျှင် တစ်ခု + ပေါင်းစပ်ထားသော master ဗားရှင်း) ကို ဖြစ်ပေါ်စေနိုင်သော်လည်း Anchor မော်ဒယ်တွင်၊ အရင်းအမြစ်တစ်ခုစီ၏ သဘာဝသော့သည် ၎င်း၏ကိုယ်ပိုင် attribute ထဲသို့ ကျသွားပြီး သီးခြား loading လုပ်သည့်အခါတွင် အသုံးပြုနိုင်သည်။ အခြားသူအားလုံး။

သို့သော် ဤနေရာတွင် ယုတ်မာသောအချက်တစ်ခုလည်း ရှိသည်- မတူညီသော စနစ်များမှ အင်္ဂါရပ်များကို အရာဝတ္ထုတစ်ခုတွင် ပေါင်းစပ်ထားပါက၊ အချို့မှာ ဖြစ်နိုင်ချေများပါသည်။ "ချိတ်" ၏စည်းမျဉ်းများမတူညီသောရင်းမြစ်များမှ မှတ်တမ်းများသည် အကြောင်းအရာတစ်ခု၏ ဥပမာတစ်ခုနှင့် သက်ဆိုင်ကြောင်း စနစ်က နားလည်ရပါမည်။

В Data Vault ဤစည်းမျဥ်းများသည် ဖွဲ့စည်းမှုကို ဆုံးဖြတ်နိုင်ခြေများသည်။ Master entity ၏ "အငှားဗဟို" သဘာဝအရင်းအမြစ်သော့များနှင့် ၎င်းတို့၏မူလဂုဏ်ရည်များကို သိမ်းဆည်းသည့် Hubs များကို မည်သည့်နည်းဖြင့်မျှ လွှမ်းမိုးမှုမပြုပါ။ တစ်ချိန်ချိန်တွင် ပေါင်းစပ်စည်းမျဥ်းများ ပြောင်းလဲသွားပါက (သို့မဟုတ် ၎င်းလုပ်ဆောင်သည့် အရည်အချင်းများကို အပ်ဒိတ်လုပ်ထားသည်)၊ ၎င်းသည် surrogate hubs များကို ပြန်လည်ပြင်ဆင်ရန် လုံလောက်ပါလိမ့်မည်။

В Anchor မော်ဒယ် ထိုသို့သော entity သည် အများအားဖြင့် သိမ်းဆည်းထားလိမ့်မည်။ တစ်ခုတည်းသောကျောက်ဆူး. ဆိုလိုသည်မှာ ၎င်းတို့သည် မည်သည့်အရင်းအမြစ်မှ လာသည်ဖြစ်စေ ဂုဏ်တော်များအားလုံးသည် တူညီသောအငှားဖြင့် ချည်နှောင်ထားမည်ဖြစ်သည်။ မှားယွင်းစွာ ပေါင်းစည်းထားသော မှတ်တမ်းများကို ခွဲထုတ်ခြင်းနှင့် ယေဘုယျအားဖြင့်၊ ထိုသို့သော စနစ်တစ်ခုတွင် ပေါင်းစည်းခြင်း၏ ဆက်စပ်မှုကို စောင့်ကြည့်ခြင်းမှာ ပိုမိုခက်ခဲနိုင်သည်၊ အထူးသဖြင့် စည်းမျဉ်းများသည် အလွန်ရှုပ်ထွေးပြီး မကြာခဏ ပြောင်းလဲပါက၊ တူညီသော ရည်ညွှန်းချက်ကို မတူညီသော အရင်းအမြစ်များမှ ရရှိနိုင်သည် (သေချာသော်လည်း၊ ရည်ညွှန်းချက်ဗားရှင်းတစ်ခုစီသည် ၎င်း၏ရင်းမြစ်သို့ လင့်ခ်တစ်ခုကို ထိန်းသိမ်းထားသောကြောင့် ဖြစ်နိုင်သည်။)

မည်သို့ပင်ဆိုစေကာမူ သင့်စနစ်သည် လုပ်ဆောင်နိုင်စွမ်းကို အကောင်အထည်ဖော်ရန် လိုအပ်နေပါက၊ ထုတ်ယူခြင်း၊ မှတ်တမ်းများနှင့် အခြား MDM ဒြပ်စင်များ ပေါင်းစည်းခြင်း။လျင်မြန်သောနည်းလမ်းများတွင် သဘာဝသော့များသိမ်းဆည်းခြင်းဆိုင်ရာ ကဏ္ဍများကို အထူးဂရုပြုသင့်ပါသည်။ ပိုမိုကြီးမားသော Data Vault ဒီဇိုင်းသည် ပေါင်းစည်းခြင်းဆိုင်ရာ အမှားအယွင်းများနှင့်ပတ်သက်၍ ရုတ်တရက် ပိုမိုလုံခြုံလာဖွယ်ရှိသည်။

Anchor မော်ဒယ် ထပ်လောင်းခေါ်တဲ့ အရာဝတ္ထုအမျိုးအစားကိုလည်း ပေးတယ်။ ထုံး မရှိမဖြစ်လိုအပ်ပါသည်။ ကျောက်ဆူးအမျိုးအစား ပျက်ယွင်းခြင်း။ရည်ညွှန်းချက်တစ်ခုသာ ပါဝင်နိုင်သည်။ node များကို flat directory များ (ဥပမာ၊ လိင်၊ အိမ်ထောင်ရေး အခြေအနေ၊ ဖောက်သည် ဝန်ဆောင်မှု အမျိုးအစား စသည်) ကို သိမ်းဆည်းရန် အသုံးပြုသင့်သည်။ Anchor နဲ့ မတူတာက Knot ပါ။ ဆက်စပ် ရည်ညွှန်းချက်ဇယားများ မရှိပါ။နှင့် ၎င်း၏တစ်ခုတည်းသော attribute (အမည်) ကို သော့ဖြင့် ဇယားတစ်ခုတည်းတွင် အမြဲသိမ်းဆည်းထားသည်။ Node များကို Anchors တစ်ခုနှင့်တစ်ခုချိတ်ဆက်ထားသကဲ့သို့တူညီသော Tie ဇယားများ (Tie) ဖြင့် Anchors နှင့်ချိတ်ဆက်ထားသည်။

Nodes အသုံးပြုမှုနှင့် ပတ်သက်၍ ရှင်းရှင်းလင်းလင်း သဘောထား မရှိပါ။ ဥပမာအားဖြင့်, Nikolay Golovရုရှားနိုင်ငံရှိ Anchor Model ကိုအသုံးပြုခြင်းကို တက်ကြွစွာ အားပေးသူသည် ကိုးကားချက်စာအုပ်တစ်အုပ်တည်းအတွက် ၎င်းကိုသေချာစွာဖော်ပြနိုင်သည်ဟု (ယုတ္တိမတန်ဘဲ) ယုံကြည်ပါသည်။ အမြဲ တည်ငြိမ်ပြီး အဆင့်တစ်ခုတည်းရှိမည်ဖြစ်သောကြောင့် အရာဝတ္ထုအားလုံးအတွက် ပြည့်စုံသော Anchor ကို ချက်ချင်းအသုံးပြုခြင်းသည် ပိုကောင်းပါသည်။

Data Vault နှင့် Anchor မော်ဒယ်အကြား နောက်ထပ်အရေးကြီးသော ကွာခြားချက်မှာ ရရှိနိုင်မှုဖြစ်သည်။ ချိတ်ဆက်မှုများ၏အရည်အချင်းများ:

В Data Vault လင့်ခ်များသည် Hubs ကဲ့သို့ ပြည့်စုံသော အရာဝတ္ထုများနှင့် တူညီပြီး ရှိနိုင်ပါသည်။ ကိုယ်ပိုင်အရည်အချင်းများ။ အဆိုပါ Anchor မော်ဒယ် လင့်ခ်များကို Anchors နှင့် ချိတ်ဆက်ရန်အတွက်သာ အသုံးပြုပါသည်။ သူတို့ရဲ့ကိုယ်ပိုင်အရည်အချင်းတွေရှိလို့မရဘူး. ဤခြားနားချက်သည် သိသိသာသာကွဲပြားခြားနားသော မော်ဒယ်လ်ချဉ်းကပ်မှုများ ကိုဖြစ်ပေါ်စေသည်။ အချက်အလက်ဆက်လက်ဆွေးနွေးသွားပါမည်။

အဖြစ်မှန်သိုလှောင်မှု

ဒီမတိုင်ခင်မှာ တိုင်းတာမှု ပုံစံထုတ်ခြင်းအကြောင်းကို အဓိကထားပြီး ဆွေးနွေးခဲ့ပါတယ်။ အဖြစ်မှန်က နည်းနည်းရှင်းပါတယ်။

В Data Vault အချက်အလက်များကို သိမ်းဆည်းရန်အတွက် ပုံမှန်အရာဝတ္ထုတစ်ခုဖြစ်သည်။ လင့်ဂြိုဟ်တုများ၏ မှန်ကန်သော ညွှန်ကိန်းများကို ထည့်သွင်းထားသည်။

ဒီချဉ်းကပ်မှုဟာ အလိုလိုသိပုံရတယ်။ ၎င်းသည် ခွဲခြမ်းစိတ်ဖြာထားသော ညွှန်ကိန်းများကို လွယ်ကူစွာ ဝင်ရောက်ကြည့်ရှုနိုင်စေကာ ယေဘုယျအားဖြင့် ရိုးရာအချက်အလက်ဇယားတစ်ခုနှင့် ဆင်တူသည် (ညွှန်ကိန်းများကို ဇယားတွင်သာ သိမ်းဆည်းမထားသော်လည်း “အိမ်နီးချင်း” တစ်ခုတွင်)။ သို့သော် ချို့ယွင်းချက်များလည်း ရှိပါသည်- မော်ဒယ်၏ ပုံမှန် ပြုပြင်မွမ်းမံမှုများထဲမှ တစ်ခု - အချက်ကို ချဲ့ထွင်ခြင်း - လိုအပ်သည် Link တွင်နိုင်ငံခြားကီးအသစ်တစ်ခုထည့်ခြင်း။. ၎င်းသည် တစ်ဖန်၊ ၎င်းသည် modularity ကို "ချိုးဖျက်" ပြီး အခြားအရာဝတ္ထုများကို ပြုပြင်မွမ်းမံရန် လိုအပ်လာနိုင်သည်။

В Anchor မော်ဒယ် ချိတ်ဆက်မှုတစ်ခုတွင် ၎င်း၏ကိုယ်ပိုင် attribute များမပါဝင်နိုင်ပါ၊ ထို့ကြောင့် ဤချဉ်းကပ်နည်းသည် အလုပ်မဖြစ်ပါ - လုံးဝ attribute နှင့် indicators အားလုံးကို သီးခြား anchor တစ်ခုနှင့် ချိတ်ဆက်ရပါမည်။ ဒီကနေ ကောက်ချက်ချတာက ရိုးရှင်းပါတယ်- အမှန်တရားတစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင်ကျောက်ဆူးလည်း လိုအပ်ပါသည်။. ဖြစ်ရပ်မှန်များဟု ကျွန်ုပ်တို့ထင်မြင်လေ့ရှိသည့်အရာအချို့အတွက်၊ ၎င်းသည် သဘာဝကျပုံပေါက်နိုင်သည် - ဥပမာအားဖြင့်၊ ဝယ်ယူမှုတစ်ခု၏အချက်ကို အရာဝတ္ထု "မှာယူမှု" သို့မဟုတ် "ပြေစာ"၊ ဆိုက်တစ်ခုသို့ သွားရောက်လည်ပတ်ခြင်း စသည်ဖြင့် ဝယ်ယူမှုတစ်ခုသို့ အပြည့်အဝလျှော့ချနိုင်သည်။ သို့သော် ထိုကဲ့သို့သော သဘာဝ “သယ်ဆောင်သူအရာဝတ္ထု” ကို ရှာတွေ့ရန် မလွယ်ကူသည့်အချက်များလည်း ရှိသည် - ဥပမာ၊ နေ့စဥ်အစတွင် ဂိုဒေါင်များရှိ ကုန်ပစ္စည်းအကြွင်းအကျန်များ။

ထို့ကြောင့်၊ Anchor မော်ဒယ်တွင် အချက်ပြသော့ကို ချဲ့ထွင်ရာတွင် မော်ဂျူလာစနစ် ပြဿနာများ မပေါ်ပေါက်ပါ (၎င်းသည် သက်ဆိုင်ရာ Anchor သို့ ဆက်စပ်မှုအသစ်တစ်ခု ထပ်ထည့်ရန် လုံလောက်သည်)၊ သို့သော် အချက်အလက်များကို ဖော်ပြရန်အတွက် မော်ဒယ်ကို ဒီဇိုင်းဆွဲခြင်းသည် ရှင်းရှင်းလင်းလင်း နည်းပါးသည်; "အတု" Anchors များ ပေါ်လာနိုင်ပါသည်။ လုပ်ငန်းအရာဝတ္ထုပုံစံကို မရှင်းလင်းသောနည်းဖြင့် ပြသသည်။

လိုက်လျောညီထွေဖြစ်အောင် ဘယ်လိုလုပ်မလဲ။

နှစ်ခုလုံးတွင် ဖြစ်ပေါ်လာသော ဆောက်လုပ်ရေးကိစ္စများတွင် ပါရှိသည်။ ဇယားများ သိသိသာသာ ပိုများလာသည်။သမားရိုးကျတိုင်းတာမှုထက်။ ဒါပေမယ့် ကြာနိုင်တယ်။ disk space သိသိသာသာနည်းပါတယ်။ သမားရိုးကျ အတိုင်းအတာကဲ့သို့ ဗားရှင်းထုတ်ထားသော အရည်အချင်းများ အစုအဝေးနှင့်။ သဘာဝအားဖြင့်၊ ဤနေရာတွင် မှော်ပညာမရှိပါ - ၎င်းသည် ပုံမှန်ပြုလုပ်ခြင်းအကြောင်းဖြစ်သည်။ Satellites (Data Vault တွင်) သို့မဟုတ် ဇယားတစ်ခုချင်းစီ (Anchor Model) တစ်လျှောက် အင်္ဂါရပ်များကို ဖြန့်ဝေခြင်းဖြင့် ကျွန်ုပ်တို့သည် (သို့မဟုတ်) လုံးဝဖယ်ရှားပစ်ခြင်း အချို့သော attribute များ၏တန်ဖိုးများကိုအခြားသူများကိုပြောင်းလဲသည့်အခါ duplication.

အတွက် Data Vault အနိုင်ရရှိမှုများသည် ဂြိုလ်တုများကြားတွင် အင်္ဂါရပ်များ ဖြန့်ဖြူးမှုအပေါ် မူတည်သည်။ Anchor မော်ဒယ် — တိုင်းတာမှုအရာဝတ္ထုတစ်ခုအတွက် ပျမ်းမျှဗားရှင်းအရေအတွက်နှင့် တိုက်ရိုက်အချိုးကျနီးပါးဖြစ်သည်။

သို့သော်၊ နေရာချွေတာမှုသည် သီးခြား attribute များကို သိမ်းဆည်းခြင်း၏ အဓိက အားသာချက်မဟုတ်ပေ။ ဆက်ဆံရေး၏ သီးခြားသိုလှောင်မှုနှင့်အတူ၊ ဤချဉ်းကပ်မှုသည် စတိုးဆိုင်ကို ဖြစ်စေသည်။ modular ဒီဇိုင်း. ဆိုလိုသည်မှာ ထိုပုံစံတစ်ခုတွင် တစ်ဦးချင်း အရည်အချင်းများနှင့် ဘာသာရပ်နယ်ပယ်အသစ် တစ်ခုလုံးကို ထည့်သွင်းပုံရသည်။ superstructure ၎င်းတို့ကို မပြောင်းလဲဘဲ ရှိပြီးသား အရာဝတ္ထုအစုအဝေးတစ်ခုအပေါ်။ ဤအရာသည် ဖော်ပြထားသော နည်းစနစ်များကို လိုက်လျောညီထွေဖြစ်စေသော အရာဖြစ်သည်။

၎င်းသည် အပိုင်းပိုင်းထုတ်လုပ်ခြင်းမှ အစုလိုက်အပြုံလိုက် ထုတ်လုပ်မှုသို့ ကူးပြောင်းခြင်းနှင့် ဆင်တူသည် - အကယ်၍ မော်ဒယ်၏ ဇယားတစ်ခုစီသည် ရိုးရာချဉ်းကပ်မှုတွင် ထူးခြားပြီး အထူးအာရုံစိုက်မှု လိုအပ်ပါက၊ လိုက်လျောညီထွေရှိသော နည်းလမ်းများတွင် ၎င်းသည် စံ "အစိတ်အပိုင်းများ" အစုတစ်ခု ဖြစ်နေပါပြီ။ တစ်ဖက်တွင်၊ ဇယားများ ပိုများလာပြီး ဒေတာတင်ခြင်းနှင့် ပြန်လည်ရယူခြင်း လုပ်ငန်းစဉ်များသည် ပိုမိုရှုပ်ထွေးနေမည် ဖြစ်သည်။ တစ်ဖက်ကလည်း ဖြစ်လာတယ်။ ပုံမှန်. ဆိုလိုတာက ရှိနိုင်တယ်။ အလိုအလျောက်နှင့် မက်တာဒေတာကို မောင်းနှင်သည်။. "ကျွန်ုပ်တို့ အဲဒါကို ဘယ်လို ချထားမလဲ" ဆိုတဲ့ မေးခွန်း၊ ဒီဇိုင်းမြှင့်တင်ခြင်းဆိုင်ရာ အလုပ်ရဲ့ အရေးပါတဲ့ အစိတ်အပိုင်းကို ယူဆောင်နိုင်တဲ့ အဖြေဟာ အခုချိန်မှာတော့ အဲဒါနဲ့ မထိုက်တန်ပါဘူး (အပြင် လုပ်ငန်းခွင် လုပ်ငန်းစဉ်တွေအပေါ် မော်ဒယ်ကို ပြောင်းလဲခြင်းရဲ့ သက်ရောက်မှုနဲ့ ပတ်သက်တဲ့ မေးခွန်း၊ )

ထိုသို့သောစနစ်တစ်ခုတွင် ခွဲခြမ်းစိတ်ဖြာသူများကို လုံးဝမလိုအပ်ဟု မဆိုလိုပါ - တစ်စုံတစ်ဦးသည် အင်္ဂါရပ်များပါရှိသော အရာဝတ္ထုအစုအဝေးများမှတစ်ဆင့် လုပ်ဆောင်ရမည်ဖြစ်ပြီး ၎င်းအားလုံးကို မည်သည့်နေရာနှင့် မည်သို့တင်ရမည်ကို တွက်ချက်ရမည်ဖြစ်သည်။ ဒါပေမယ့် အလုပ်ပမာဏအပြင် အမှားအယွင်းဖြစ်နိုင်ခြေနဲ့ ကုန်ကျစရိတ်တွေက သိသိသာသာ လျော့ကျသွားပါတယ်။ ခွဲခြမ်းစိတ်ဖြာမှုအဆင့်တွင်နှင့် ETL ၏ဖွံ့ဖြိုးတိုးတက်မှုကာလအတွင်း နှစ်ခုစလုံးသည် သိသာထင်ရှားသောအစိတ်အပိုင်းတစ်ခုတွင် မက်တာဒေတာကိုတည်းဖြတ်ရန် လျှော့ချနိုင်သည်။

အမှောင်ခြမ်း

အထက်ပါအချက်များအားလုံးသည် ချဉ်းကပ်မှုနှစ်ခုစလုံးကို အမှန်တကယ်ပြောင်းလွယ်ပြင်လွယ်၊ နည်းပညာအဆင့်မြင့်ပြီး ထပ်ခါထပ်ခါ တိုးတက်မှုအတွက် သင့်လျော်စေသည်။ ဟုတ်ပါတယ်၊ “ဆီမွှေးထဲမှာ ဗူး” လည်း ရှိတယ်၊ မင်း ခန့်မှန်းလို့ ရနေပြီ ထင်ပါတယ်။

ပြောင်းလွယ်ပြင်လွယ်ရှိသော ဗိသုကာပညာ၏ အသွင်အပြင်ကို နောက်ခံပြုထားသည့် ဒေတာပြိုကွဲမှုသည် ဇယားအရေအတွက် တိုးလာစေပြီး၊ ပေါ်ကနေ sampling လုပ်တဲ့အခါ join ဖို့။ အတိုင်းအတာတစ်ခု၏ ဂုဏ်ရည်များအားလုံးကို ရိုးရိုးရှင်းရှင်းရနိုင်ရန်၊ ဂန္တဝင်စတိုးတစ်ခုတွင် ရွေးချယ်မှုတစ်ခုသည် လုံလောက်သော်လည်း လိုက်လျောညီထွေရှိသော ဗိသုကာလက်ရာတစ်ခုသည် အတွဲလိုက်အားလုံး လိုအပ်မည်ဖြစ်သည်။ ထို့အပြင်၊ ဤအရာအားလုံးကို အစီရင်ခံစာအတွက် ကြိုတင်ရေးသားနိုင်လျှင် SQL ကို လက်ဖြင့်ရေးသားလေ့ရှိသော အကဲဖြတ်သူများသည် နှစ်ဆခံစားရမည်ဖြစ်ပါသည်။

ဤအခြေအနေကိုပိုမိုလွယ်ကူစေသည့်အချက်များစွာရှိပါသည်။

ကြီးမားသောအတိုင်းအတာများဖြင့် လုပ်ဆောင်သောအခါ၊ ၎င်း၏ attribute များအားလုံးကို တစ်ပြိုင်နက်အသုံးမပြုလုနီးပါးဖြစ်သည်။ ဆိုလိုသည်မှာ မော်ဒယ်ကို ပထမတစ်ချက်ကြည့်ခြင်းထက် ချိတ်ဆက်မှုနည်းပါးနိုင်သည်ဟု ဆိုလိုသည်။ Data Vault သည် ဂြိုလ်တုများထံသို့ attribute များခွဲဝေပေးသောအခါတွင် မျှဝေမည့် ကြိမ်နှုန်းကိုလည်း ထည့်သွင်းစဉ်းစားနိုင်သည်။ တစ်ချိန်တည်းမှာပင်၊ Hubs သို့မဟုတ် Anchors များသည် loading stage တွင် surrogates များကို ဖန်တီးခြင်းနှင့် မြေပုံဆွဲခြင်းအတွက် အဓိက လိုအပ်ပြီး queries များတွင် အသုံးပြုခဲသည် (၎င်းသည် Anchors အတွက် အထူးသဖြင့် မှန်သည်)။

ပါဝင်မှုအားလုံးသည် သော့ဖြင့်ဖြစ်သည်။ ထို့အပြင်၊ ဒေတာသိမ်းဆည်းခြင်း၏ပိုမို "ချုံ့ထားသော" နည်းလမ်းသည် လိုအပ်သည့်နေရာတွင် စကင်န်ဖတ်ခြင်းဇယားများ၏ အပေါ်ပိုင်းကို လျှော့ချပေးသည် (ဥပမာ၊ attribute တန်ဖိုးဖြင့် စစ်ထုတ်သည့်အခါ)။ ၎င်းသည် joins အများအပြားပါရှိသောပုံမှန်ဒေတာဘေ့စ်မှနမူနာယူခြင်းသည်အတန်းတစ်ခုလျှင်ဗားရှင်းများစွာရှိသောလေးလံသောအတိုင်းအတာတစ်ခုအားစကင်န်ဖတ်ခြင်းထက်ပင်ပိုမိုမြန်ဆန်လိမ့်မည်ဟူသောအချက်ကိုဖြစ်ပေါ်စေနိုင်သည်။

ဥပမာအားဖြင့်၊ ဤနေရာတွင် ဤ ဆောင်းပါးတွင် ဇယားတစ်ခုမှ နမူနာတစ်ခုနှင့်အတူ Anchor မော်ဒယ်၏ စွမ်းဆောင်ရည်ကို အသေးစိတ် နှိုင်းယှဉ်စမ်းသပ်မှုတစ်ခု ပါရှိသည်။

အင်ဂျင်အပေါ်မှာ အများကြီးမူတည်တယ်။ ခေတ်မီပလပ်ဖောင်းများစွာတွင် အတွင်းပိုင်းပူးပေါင်း၍ ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်သည့် ယန္တရားများရှိသည်။ ဥပမာအားဖြင့်၊ MS SQL နှင့် Oracle တို့သည် ၎င်းတို့၏ဒေတာများကို အခြားချိတ်ဆက်မှုများမှလွဲ၍ မည်သည့်နေရာတွင်မှအသုံးမပြုပါက၊ နောက်ဆုံးရွေးချယ်မှု (စားပွဲတင်/ပူးပေါင်းဖယ်ရှားခြင်း) နှင့် MPP Vertica ကို မထိခိုက်စေပါက MS SQL နှင့် Oracle တို့သည် ဇယားများသို့ “ကျော်သွား” နိုင်သည်။ Avito မှလုပ်ဖော်ကိုင်ဖက်များ၏အတွေ့အကြုံ, သည် query plan ၏ manual optimization အချို့ကိုပေးသော Anchor Model အတွက် အကောင်းဆုံးအင်ဂျင်ဖြစ်ကြောင်း သက်သေပြခဲ့သည်။ အခြားတစ်ဖက်တွင်၊ ဥပမာအားဖြင့်၊ Join Support အကန့်အသတ်ရှိသော Click House တွင် Anchor Model ကို သိမ်းဆည်းခြင်းသည် အလွန်ကောင်းမွန်သော အကြံဥာဏ်တစ်ခုနှင့်တူပါသည်။

ထို့အပြင် ဗိသုကာ နှစ်ခုလုံးအတွက် လည်း ရှိသေးသည်။ အထူးလှုပ်ရှားမှုများဒေတာဝင်ရောက်မှုကို ပိုမိုလွယ်ကူစေသည် (မေးမြန်းမှု စွမ်းဆောင်ရည်ရှုထောင့်မှ နှင့် သုံးစွဲသူများအတွက်)။ ဥပမာအားဖြင့်, Point-In-Time ဇယားများ Data Vault သို့မဟုတ် အထူးဇယားလုပ်ဆောင်ချက်များ Anchor မော်ဒယ်ထဲမှာ။

စုစုပေါင်း

ကွေးညွှတ်နိုင်သော ဗိသုကာလက်ရာများ ၏ အဓိကအနှစ်သာရမှာ ၎င်းတို့၏ "ဒီဇိုင်း" ၏ ပုံစံတူဖြစ်သည်။

၎င်းသည် ဤပိုင်ဆိုင်မှုကို ခွင့်ပြုသည်-

• metadata ဖြန့်ကျက်ခြင်းနှင့် အခြေခံ ETL algorithms များရေးသားခြင်းနှင့်ဆက်စပ်သော ကနဦးပြင်ဆင်မှုအချို့ပြီးနောက်၊ ဖောက်သည်အား ပထမရလဒ်ကို အမြန်ပေးသည်။ အရင်းအမြစ်အရာဝတ္တုအနည်းငယ်မှဒေတာများပါ ၀ င်သောအစီရင်ခံစာနှစ်စောင်၏ပုံစံဖြစ်သည်။ အရာဝတ္ထုမော်ဒယ်တစ်ခုလုံးကို (ထိပ်တန်းအဆင့်မှာတောင်) လုံးလုံးလျားလျား စဉ်းစားဖို့ မလိုအပ်ပါဘူး။
• ဒေတာမော်ဒယ်တစ်ခုသည် အရာဝတ္တု 2-3 ခုဖြင့် စတင်အလုပ်လုပ်နိုင်သည် (အသုံးဝင်သည်) တဖြည်းဖြည်းကြီးထွား (Anchor မော်ဒယ် Nikolai နှင့် ပတ်သက် အသုံးချသည် mycelium နှင့် နှိုင်းယှဉ်မှုကောင်းသည်။)
• ဘာသာရပ်နယ်ပယ်ချဲ့ထွင်ခြင်းနှင့် အရင်းအမြစ်အသစ်များထည့်ခြင်းအပါအဝင် တိုးတက်မှုအများစု လက်ရှိလုပ်ဆောင်နိုင်စွမ်းကို မထိခိုက်စေဘဲ လက်ရှိလုပ်ဆောင်နေသော အရာတစ်ခုကို ဖောက်ထွင်းခံရနိုင်ခြေ မရှိပါ။.
• စံဒြပ်စင်များအဖြစ်သို့ ပြိုကွဲသွားခြင်းကြောင့်၊ ထိုကဲ့သို့သော စနစ်များရှိ ETL လုပ်ငန်းစဉ်များသည် တူညီကြသည်၊ ၎င်းတို့၏ အရေးအသားသည် အယ်လဂိုရီသမ်ပြုခြင်းသို့ ချေးငှားပြီး နောက်ဆုံးတွင်၊ အလိုအလျောက်စနစ်.

စျေးနှုန်းသည်ဤပြောင်းလွယ်ပြင်လွယ်ဖြစ်ပါတယ်။ စွမ်းဆောင်ရည်. ထိုသို့သော မော်ဒယ်များတွင် လက်ခံနိုင်သော စွမ်းဆောင်ရည်ကို ရရှိရန် မဖြစ်နိုင်ဟု မဆိုလိုပါ။ များသောအားဖြင့်၊ သင်သည် သင်အလိုရှိသော မက်ထရစ်များရရှိရန် အသေးစိတ်ကို ပိုမိုအားစိုက်ထုတ်ရန်နှင့် အာရုံစိုက်ရန် လိုအပ်ပါသည်။

apps များ

Entity အမျိုးအစားများ Data Vault

Data Vault အကြောင်း နောက်ထပ် အချက်အလက်
Dan Lystadt ၏ဝဘ်ဆိုဒ်
ရုရှားလို Data Vault အကြောင်းအားလုံး
Habré ရှိ Data Vault အကြောင်း

Entity အမျိုးအစားများ Anchor Model ပါ။

Anchor Model အကြောင်း နောက်ထပ်အသေးစိတ်အချက်များ

Anchor Model ဖန်တီးသူများ၏ ဝဘ်ဆိုဒ်
Avito တွင် Anchor Model အကောင်အထည်ဖော်ခြင်းအတွေ့အကြုံအကြောင်း ဆောင်းပါး

ထည့်သွင်းစဉ်းစားထားသော ချဉ်းကပ်မှုများ၏ ဘုံအင်္ဂါရပ်များနှင့် ကွဲပြားမှုများပါရှိသော အကျဉ်းချုပ်ဇယား-

source: www.habr.com