Slowly Changing Dimension (SCD)

ရက်စွဲ - ၂၅. ၁၂. ၂၀၁၉ (ဗုဒ္ဓဟူး)

Data management နဲ့ Data warehousing တွေမှာ Dimensions တွေ နဲ့ Facts Tables တွေ ရှိပါတယ်။ Facts Tables တွေကို data tables တွေလို့လည်းခေါ်ပြီး Dimension tables တွေကို lookup tables တွေလို့လည်း ခေါ်ပါတယ်။ Dimensions တွေမှာ ဆက်စပ်မှု တွေရှိနေမယ့် static data (master data) တွေ (ဥပမာ - geographical locations, customers, or products) ပါ၀င်ပါတယ်။ Facts Tables တွေကတော့ transaction data တွေပါ။ (ဥပမာ - sales record လိုမျိုး data တွေပါ။) Fact tables နဲ့ Dimension tables တွေကို link ချိတ်ထားပါတယ်။ Star Schema ပုံမျိုးနဲ့ပေါ့။ ဆိုလိုတာက Fact table တစ်ခုမှာ Dimension တွေအများကြီးရှိနိုင်လို့ Dimension tables တွေက Fact table တစ်ခုကို ၀န်းရံ link ချိတ်ထားတဲ့သဘော ဖြစ်ပါတယ်။ Star Schema မှာ Dimension table တွေက အဆင့်ဆင့် မရှိပါဘူး။ Snowflake Schema ဆိုတာရှိပါသေးတယ်။ သူကကျတော့ chains of dimension tables တွေရှိနေလို့ပါ။ ဥပမာ - Sales table ကို Product, Customer, Batch table တွေက လာချိတ်မှာ ဖြစ်ပြီး Sales table က Product Sub Category, Product Brand table တွေကို တိုက်ရိုက်ချိတ် လို့မရဘဲ Product ကနေမှတဆင့်အောက် level တွေကိုအဆင့်ဆင့် ချိတ်ရတာပါ။

Data Warehouse ထဲက ခုနကပြောတဲ့ static data တွေက မမျှော်လင့်ထားဘဲ ပြောင်းလဲသွားတတ်ပါတယ်။

ဘယ်လိုမျိုး ပြောင်းလဲသွားတာပါလဲ????

Dimension data တွေဖြစ်တဲ့ customer/supplier ဒါမှမဟုတ် salesperson လိုမျိုးကို စဉ်းစားကြည့်ရအောင်ပါ။ Customer/Supplier တွေရဲ့ address/state တွေ ၊ Salesperson တွေရဲ့ office region တွေဟာ ပြောင်းလဲသွား နိုင်ပါတယ်။ ဒီလိုဆိုရင် ဒီလိုပြောင်းလဲသွားမှုတွေကို Update လုပ်မှာလား? Overwrite လုပ်မှာလား? Ignore လုပ်မှာလား? ဒီလို issues တွေအတွက် SCD management methodologies (Type 0 to 6) ရှိပါတယ်။

• Type 0: retain original

• Type 1: overwrite

• Type 2: add new row

• Type 3: add new attribute

• Type 4: add history table

• Type 5

• Type 6: Combined Approach

Type 0: retain original

ဘယ်တော့မှမပြောင်းလဲနိုင်တဲ့ durable values တွေကို original လို့သတ်မှတ်ပါတယ်။ ဥပမာ - Date of Birth, Original Credit Score. Type 0 တွေဟာ များသောအားဖြင့် Date Dimension Attributes တွေဖြစ်ကြပါတယ်။

Type 1: overwrite

ပြောင်းသွားတဲ့ data အဟောင်းနေရာမှ data အသစ်နဲ့ အစားထိုးသိမ်းလိုက်ခြင်းဖြစ်ပါတယ်။ ဒါကြောင့် သူ့မှာ historical data ကျန်လေ့မရှိပါဘူး။

Example of a supplier table:

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State
123	ABC	Acme Supply Co	CA

Supplier_Code is the natural key (business key) and Supplier_Key is a surrogate key (synthetic key, entity identifier, system-generated key, database sequence number, fact less key, technical key, or arbitrary unique identifier)

တကယ်က surrogate key က မလိုပါဘူး။ ဒါပေမယ့် performance ကို optimize လုပ်ဖို့အတွက်ဆိုရင်တော့ character key ဖြစ်တဲ့ supplier code ထက် integer key ဖြစ်တဲ့ surrogate key ကိုသုံးတာ ပိုအဆင်ပြေ ပါတယ်။ natural key ကို သုံးတာဟာလည်း မသင့်တော်တဲ့ အတွက်ကြောင့် surrogate key ကိုသုံးရတာပါ။

If the supplier relocates the headquarters to Illinois the record would be overwritten:

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State
123	ABC	Acme Supply Co	IL

ဒီလို overwrite လုပ်လိုက်တဲ့အတွက်ကြောင့် maintain လုပ်ရတာတော့ပိုလွယ်သွားပါတယ်။ ဒါပေမယ့် historical data တော့မကျန်ပါဘူး။ အကယ်၍များ Supplier_State နဲ့များ aggregate လုပ်ထားခဲ့မယ်ဆိုရင် recalculate ပြန်လုပ်ပေးရပါမယ်။

Type 2: add new row

Historical data ကျန်အောင်လို့ record တွေ (field တွေရောပါ ပါတယ်) ထပ်တိုးထည့်ခြင်းဖြစ်ပါတယ်။ ထပ်တိုး ထည့်မယ့် history record တွေကို limit တော့လုပ်မထားပါဘူး။ ကြိုက်သလောက်ထပ်တိုးထည့်နိုင်ပါတယ်။ Row တိုးတိုင်း Surrogate Key ကိုထည့်သွင်း အသုံးပြုပြင်ဆင်ခြင်းဖြစ်ပါတယ်။

For example (1) version column ထပ်တိုးခြင်း

Supplier_Key	Supplier_Code	Supplier_Name	Supplier	Version
123	ABC	Acme Supply Co	CA	0
124	ABC	Acme Supply Co	IL	1

For example (2) Start Date/End Date (Effective Date) ထပ်တိုးခြင်း

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State	Start_Date	End_Date
123	ABC	Acme Supply Co	CA	2000-01-01T00:00:00	2004-12-22T00:00:00
124	ABC	Acme Supply Co	IL	2004-12-22T00:00:00	NULL

For example (3) Current Flag ထပ်တိုးခြင်း

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State	Effective_Date	Current_Flag
123	ABC	Acme Supply Co	CA	2000-01-01T00:00:00	N
124	ABC	Acme Supply Co	IL	2004-12-22T00:00:00	Y

Type 3: add new attribute

Rows တွေထပ်တိုးမယ့်အစား Columns တွေထပ်တိုးခြင်းဖြင့် historical data ကျန်စေပါမယ်။

For example (1)

Supplier_Key	Supplier_Code	Supplier_Name	Original_Supplier_State	Effective_Date	Current_Supplier_State
123	ABC	Acme Supply Co	CA	2004-12-22T00:00:00	IL

Example မှာပြထားတဲ့ Original_Supplier_State အစား Previous_Supplier_State ဆိုပြီး create လုပ်ခြင်းက historical data ကို track လုပ်ရာမှာ ပိုအဆင်ပြေစေမှာပါ။

Type 4: add history table

Current table လည်းထားတယ်။ History table ကိုလည်းထပ်ခွဲထားလိုက်ပါတယ်။ ပြီးမှ current table နဲ့ history table ကို relation ပြန်ထားထားပါမယ်။

For example (1)

Supplier
Supplier_key	Supplier_Code	Supplier_Name	Supplier_State
124	ABC	Acme & Johnson Supply Co	IL

Supplier_History
Supplier_key	Supplier_Code	Supplier_Name	Supplier_State	Create_Date
123	ABC	Acme Supply Co	CA	2003-06-14T00:00:00
124	ABC	Acme & Johnson Supply Co	IL	2004-12-22T00:00:00

Type 5

There is no SCD type 5.

Type 6: combine approach

Type 6 ကို Hybrid SCDs လို့လည်းခေါ်ပါတယ်။ Type 1+2+3 ပေါင်းပြီးတော့ Type 6 ဖြစ်လာတာပါ။

(Ralph Kimball calls this method "Unpredictable Changes with Single-Version Overlay" in The Data Warehouse Toolkit)

For example (1) ပထမဆုံးက record တစ်ကြောင်းပဲရှိပါဦးမယ်။

Supplier_Key	Row_Key	Supplier_Code	Supplier_Name	Current_State	Historical_State	Start_Date	End_Date	Current_Flag
123	1	ABC	Acme Supply Co	CA	CA	2000-01-01T00:00:00	9999-12-31T23:59:59	Y

ပြီးရင် Type 1 အရ ပထမဆုံးရှိပြီးသား တကြောင်းတည်းသော record မှာပဲ အရင်ပြင်ပါမယ်။ history data ကျန်ဖို့ Type 2 နဲ့ Type 3 အရ new record (new row) နဲ့ new attributes ထပ်တိုးပါမယ်။

For example (2)

Supplier_Key	Row_Key	Supplier_Code	Supplier_Name	Current_State	Historical_State	Start_Date	End_Date	Current_Flag
123	1	ABC	Acme Supply Co	IL	CA	2000-01-01T00:00:00	2004-12-22T00:00:00	N
123	2	ABC	Acme Supply Co	IL	IL	2004-12-22T00:00:00	9999-12-31T23:59:59	Y

အကယ်၍များ supplier က နေရာထပ်ရွှေ့ဦးမယ် ဆိုရင်တောင် Row_Key ကိုပဲ တိုးပြီး ပြောင်း ပြောင်းသွားရင် ရပါပြီ။

For example (3)

Supplier_Key	Row_Key	Supplier_Code	Supplier_Name	Current_State	Historical_State	Start_Date	End_Date	Current_Flag
123	1	ABC	Acme Supply Co	NY	CA	2000-01-01T00:00:00	2004-12-22T00:00:00	N
123	2	ABC	Acme Supply Co	NY	IL	2004-12-22T00:00:00	2008-02-04T00:00:00	N
123	3	ABC	Acme Supply Co	NY	NY	2008-02-04T00:00:00	9999-12-31T23:59:59	Y

Type 2 and Type 6 fact implementation

Type 2 ရော Type 6 ရော နှစ်ခုလုံးရဲ့ implementation တော်တော်များများမှာ__data repository ထဲကိုfact data တွေဆွဲတင်တဲ့အခါ အဲ့ဒီ fact data တွေရှိတဲ့ fact table ထဲကို dimension table ထဲက natural key အစား surrogate key ကိုပဲထည့်ပေးလိုက်ပါတယ်။ (လက်ရှိ ရှိထားတဲ့) Fact table အတွက် surrogate key ကို ရွေးလိုက်ခြင်းဟာ dimension table ထဲက effective date/start date/end date တွေပေါ်မှာမူတည်ထားပါတယ်. ဒီလိုမျိုး surrogate key ကိုအစားထိုး ပြောင်းသုံးလိုက်ခြင်းကြောင့် dimension data နဲ့ fact data ကို join တဲ့အခါ မှာ ပိုပြီးမှန်ကန် တိကျစေပါလိမ့်မယ်။ Effective Date အရပဲကြည့်ကြည့် ပိုပြီး အဆင်ပြေပါစေမယ်။ ဒါကို Type 6 Hybrid methodology လို့ခေါ်ပါတယ်။

For example (1)

Supplier_Key	Supplier_Code	Supplier_Name	Current_State	Historical_State	Start_Date	End_Date	Current_Flag
123	ABC	Acme Supply Co	NY	CA	2000-01-01T00:00:00	2004-12-22T00:00:00	N
124	ABC	Acme Supply Co	NY	IL	2004-12-22T00:00:00	2008-02-04T00:00:00	N
125	ABC	Acme Supply Co	NY	NY	2008-02-04T00:00:00	9999-12-31T23:59:59	Y

• Table (Same Table) တစ်ခုတည်းက column (field) တစ်ခုချင်းစီကို မတူညီကွဲပြားတဲ့ SCDs Type တွေ သုံးနိုင်ပါတယ်။ ဥပမာ - “Supplier_Name” ကို Type 1 ပေးသုံးပြီး “Supplier_State” ကို Type 2 နဲ့ သုံးထားတာမျိုးပါ။

Pure Type 6 Implementation

Type 2 မှာအသုံးပြုတဲ့ surrogate key ရှိခြင်းဟာ တခါတရံမှာ ပြဿနာဖြစ်နိုင်ပါတယ်။ အကယ်၍ dimension table ကို ပြင်ဖို့လိုအပ်လာခဲ့မယ်ဆိုရင်ပေါ့။ Pure Type 6 မှာက surrogate key ကိုသုံးတော့သုံးမယ်_Type2 မှာလိုမျိုး surrogate key ကိုမတိုးပါဘူး။ ဆိုရရင် supplier_code အတူတူ (supplier တစ်ယောက်တည်းအတွက်) ဆိုရင် surrogate key ကို တစ်ခုတည်းပဲ ထားမှာပါ။

Type 2 မှာဆိုရင် => Supplier Code (ABC) အတွက် သူ changing လုပ်သမျှ record တိုင်းအတွက် (row တိုင်းမှာ) surrogate key တစ်ခုစီရှိပါမယ်။ 3 records ရှိရင် (1,2,3) ဆိုပြီး surrogate key (၃) ခုရှိပါမယ်။

Pure Type 6 မှာဆိုရင် => Supplier Code (ABC) အတွက် သူ changing လုပ်သမျှ record တိုင်းအတွက် (row တိုင်းမှာ) surrogate key တစ်ခုတည်းသာလျှင်ရှိပါမယ်။ 3 records ရှိလည်း surrogate key က 1 ဆိုရင် ၃ ကြောင်းလုံးက surrogate key 1 အနေနဲ့ပဲပြပေးပါမယ်။ ပြီးတော့နောက်တစ်ခုက Type 3 မှာလိုမျိုး attribute တိုးတာလည်း လုပ်မထားပါဘူး။ supplier ပြောင်းသွားတဲ့ state ကို column (၂) ခုအဖြစ် current state တွေ historical state တွေခွဲမထားဘဲထားလိုက်တာမျိုးပါ။

For example (1) အောက်မှာပြထားတဲ့ supplier table က pure type 6 methodology ကိုသုံးထားတာပါ။

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State	Start_Date	End_Date
456	ABC	Acme Supply Co	CA	2000-01-01T00:00:00	2004-12-22T00:00:00
456	ABC	Acme Supply Co	IL	2004-12-22T00:00:00	2008-02-04T00:00:00
456	ABC	Acme Supply Co	NY	2008-02-04T00:00:00	9999-12-31T23:59:59

အပေါ်မှာပြထားတဲ့ဥပမာအရဆိုရင် Start Date & End Date ကိုပြောလိုက်တာနဲ့ supplier ရဲ့ state ကိုတိကျစွာ သိနိုင်မှာ ဖြစ်ပါတယ်။

Advantages of Pure Type 6 methodology

1. DBMS ရဲ့ Referential Integrity ကိုသံသယမရှိ ပြေလည်စေပါမယ်။

    Remark – Referential Integrity ဆိုတာက master table (dimension table) မှာ မရှိဘဲ transaction table (fact table)            မှာပဲရှိနေတဲ့အခါ reference မရှိဘူး/လွဲနေတယ်လို့ ပြောချင်တာပါ။ အောက်မှာပြထားတဲ့ Fig: ကို ကြည့်ပေးပါ။

2. အကယ်၍ dimension table မှာ အပြောင်းအလဲ ရှိခဲ့မယ် ဆိုရင်တောင် fact table မှာလိုက်ပြောင်းပေးဖို့ reprocess လိုက်လုပ်ပေးဖို့ မလိုတော့ပါဘူး။

3. Time slice (effective date, start/stop date) တွေကိုသုံးပြီး dimension table ကိုတည်ဆောက်ထားတာ ဖြစ်တဲ့အတွက် bi-temporal (time instance တွေအတွက်သုံးတဲ့ temporal database) ကိုလည်းစဥ်းစား အသုံးပြုနိုင်သွားပါမယ်။

• နောက်တစ်ခုက Alternative implementation အနေနဲ့ surrogate key ရော natural key ရောနှစ်ခုလုံး ထည့်ဦးမယ် ဆိုရင်လည်း ရပါသေးတယ်။ ဒါပေမယ့် သူ့မှာတော့ caution အချို့ရှိပါတယ်။

REFERENCE - https://en.wikipedia.org/wiki/Slowly_changing_dimension

Noted & Referenced By: Zaw May

IT Consultant

Nynox Solution