Type 2 — Slowly Changing Dimension modelida atribut o‘zgarganda mavjud satrni ustidan yozmay, yangi versiya satri yaratib tarixni saqlash usulidir. Har versiya amal qilish vaqt oralig‘i va ko‘pincha alohida surrogate keyga ega. Fact recordlar hodisa sodir bo‘lgan paytda amalda bo‘lgan dimension versiyasiga bog‘lanib, tarixiy hisobot o‘sha davrdagi holatni ko‘rsatadi.
Versiya tuzilishi
Dimension odatda business key, surrogate key, atributlar, valid_from, valid_to va is_current maydonlarini saqlaydi. Joriy satrning tugash vaqti ochiq maksimum yoki null bo‘lishi mumkin. Mijoz segmenti Standarddan Premiumga o‘zgarsa, eski versiya yopiladi va yangi surrogate key bilan Premium versiya ochiladi.
Vaqt intervallari ustma-ust tushmasligi va business key uchun ayni paytda bittadan ko‘p joriy satr bo‘lmasligi invariantdir. Inclusive va exclusive chegara aniq belgilanadi. [valid_from, valid_to) shakli ayni timestampda eski va yangi satrning ikkalasiga mos kelishni oldini oladi.
Fact bilan bog‘lash
Fact yuklanganda business key va event time orqali tegishli dimension versiyasi topiladi. Faqat joriy versiyaga join qilish eski faktlarni yangi segmentga ko‘chirib yuboradi. Factda surrogate dimension key saqlansa, keyingi Type 2 o‘zgarish avvalgi fact joinini o‘zgartirmaydi.
Late-arriving fact o‘tmishdagi versiyaga bog‘lanishi kerak. Late-arriving dimension esa oldin noma’lum tarixiy o‘zgarishni olib keladi va mavjud intervalni bo‘lishi mumkin. Factlar surrogate keyni materializatsiya qilgan bo‘lsa, ta’sirlangan vaqt oralig‘i qayta keylanadi yoki unknown member siyosati qo‘llanadi.
ETL atomikligi
O‘zgarish topilganda eski rowni yopish va yangi rowni insert qilish bitta tranzaksiyada bajariladi. Jarayon o‘rtada to‘xtasa ikkita current row yoki umuman current rowsiz holat qolmasligi kerak. Source version, event time va deduplication key retry ni idempotent qiladi.
Change detection barcha Type 2 atributlar hashiga asoslanishi mumkin. Null, whitespace, timezone va standardizatsiya bir xil canonical shaklda taqqoslanadi; aks holda mazmunsiz yangi versiyalar ko‘payadi. Source bir batchda bir entity uchun ketma-ket bir nechta o‘zgarish bersa, ular source tartibida qo‘llanadi.
Xarajat va so‘rov
Type 2 dimension satrlar sonini oshiradi. Fact load uchun temporal lookup va indeks talab qilinadi. Foydalanuvchi joriy holatni so‘rasa is_current=true, tarixiy holatni so‘rasa factdagi surrogate key yoki vaqt intervalini ishlatadi. Semantika BI qatlamida yashirilsa xato joinlar kamayadi.
Retention talabi tugagan eski versiyalarni o‘chirish tarixiy fact referensiyasini buzishi mumkin. Data privacy bo‘yicha shaxsiy atributni tarixiy saqlash qonuniy asosga ega bo‘lishi kerak; pseudonymization yoki alohida himoya qo‘llanadi.
Type 1 bilan birga
Imlo tuzatishi barcha versiyaga Type 1 tarzida qo‘llanishi, segment o‘zgarishi esa Type 2 bo‘lishi mumkin. Qaysi ustun qaysi siyosatga tegishli ekani data dictionaryda yoziladi. Testlar interval, current row, surrogate uniqueness, late data va rerun holatlarini tekshiradi. Type 2 faqat “ko‘proq tarix” emas, hisobotning vaqt semantikasini qat’iy belgilovchi modeldir.
Delete va qayta faollashish
Source entity o‘chirilsa, joriy Type 2 row yopilishi va deleted holatdagi yangi versiya yaratilishi mumkin. Hard delete tarixiy fact joinini buzadi. Entity keyin qaytsa, yangi versiya ochiladi; eski surrogate key qayta ishlatilmaydi. “Yo‘qolgan source snapshot” bilan haqiqiy delete farqlanadi, aks holda vaqtinchalik ingest xatosi barcha dimensionlarni yopishi mumkin.
Bitemporal kengayish
Valid time biznes holatini, system time warehouse qachon bu versiyani bilganini saqlasa kech tuzatishlar ham audit qilinadi. Bu oddiy Type 2dan murakkabroq, ammo “o‘sha paytdagi bilim”ni qayta yaratadi.
Bog‘liq tushunchalar
Slowly Changing Dimension, Type 1, Temporal table, Surrogate key, Dimension table, Late-arriving data, Data warehouse