slowly changing dimensions समझाएं और बताएं कि type 2 आप कैसे लागू करेंगे।

slowly changing dimensions बताते हैं कि dimension tables में attribute के बदलावों को आप कैसे संभालते हैं। Type 1 पुराना मान मिटाकर लिख देता है और इतिहास खो देता है। Type 2 हर बदलाव पर एक नई row डालता है, जिसमें surrogate key, valid_from और valid_to timestamps, और एक current flag होता है, ताकि facts उसी attribute version से जुड़ें जो उस वक्त सच था। Type 3 सिर्फ एक पिछली स्थिति के लिए previous value का column रखता है।

Type 1 बस मान के ऊपर लिख देता है, इसलिए इतिहास चला जाता है। Type 2 हर बार attribute बदलने पर एक row जोड़कर इतिहास रखता है। व्यावहारिक तौर पर इसका मतलब है primary key के तौर पर एक surrogate key, उसके साथ असली business key, valid_from और valid_to timestamps, और सहूलियत के लिए एक is_current boolean। fact table वही surrogate key रखता है जो event होते वक्त current थी, इसलिए मार्च का कोई sales fact आज भी उस sales rep के मार्च वाले territory से जुड़ता है, उनके आज वाले से नहीं। यही फर्क पूरी बात है, और गलती होने पर finance वाले सबसे पहले यही पकड़ेंगे। load एक merge होता है: वे rows ढूंढें जिनके tracked columns बदले हैं, मौजूदा row पर valid_to सेट करें, और valid_from भरकर तथा valid_to को null या बहुत आगे की तारीख रखकर नई row डालें। मैं आम तौर पर tracked columns को hash करके एक change key बना देता हूं ताकि तुलना बीस के बजाय एक equality check रह जाए।