Type 1 — data warehousedagi Slowly Changing Dimension tasnifida dimension atributi o‘zgarganda eski qiymatni yangi qiymat bilan ustidan yozish usulidir. U tarixni saqlamaydi: jadvalda entity uchun faqat joriy holat qoladi. Atama boshqa sohalarda ham ishlatiladi, ammo dimension va keyingi Type 2 kontekstida u SCD Type 1 ma’nosini bildiradi.
Ishlash usuli
Mijoz dimensionida city='Samarqand' qiymati city='Toshkent'ga tuzatilsa, Type 1 update ayni dimension satrini o‘zgartiradi. Surrogate key saqlanib qoladi. Fact jadvalidagi eski va yangi tranzaksiyalar shu keyga bog‘langanligi sabab, tarixiy report ham mijozni Toshkent deb ko‘rsatadi.
Bu xususiyat xato tuzatish, imlo standardizatsiyasi yoki tarixiy tahlilda ahamiyatsiz atribut uchun foydali. Agar manbadagi ism noto‘g‘ri yozilgan bo‘lsa, barcha davrda to‘g‘ri ko‘rinishi istaladi. Mijozning haqiqiy hudud ko‘chishi esa “sotuv paytida qaysi hududda edi” savoli uchun tarixiy ma’noga ega va Type 2 talab qilishi mumkin.
ETL amalga oshirishi
Pipeline business key bo‘yicha source recordni dimensiondan topadi. Kuzatiladigan Type 1 ustunlar hash yoki alohida taqqoslanadi. Farq bo‘lsa UPDATE bajariladi, yangi entity bo‘lsa INSERT. Modified timestamp va source version audit uchun saqlanishi mumkin, lekin ular atributning oldingi qiymatini tiklamaydi.
Merge amali insert va update ni birlashtiradi. Source batchda bir business key uchun bir nechta record bo‘lsa, qaysi biri joriy ekani event time yoki source sequence bilan aniqlanadi. Nondeterministic tartib har rerunda boshqa natija berishi mumkin. Idempotent pipeline ayni inputni qayta ishlaganda qo‘shimcha o‘zgarish yaratmaydi.
Afzallik va cheklov
Type 1 sodda, dimension kichik va join odatiy. Har entity uchun bitta satr bo‘lgani sabab storage va query sharti kamayadi. Foydalanuvchi is_current yoki effective date bilan ishlamaydi.
Asosiy cheklov tarix yo‘qolishidir. Backup yoki CDC log mavjud bo‘lsa ham analitik modelning rasmiy tarixiy semantikasi bo‘lib qolmaydi. Kecha chiqarilgan hisobot bugun atribut update qilingach o‘tgan davr uchun boshqa natija ko‘rsatishi mumkin. Audit yoki “o‘sha paytdagi holat” talabi bo‘lsa bu qabul qilinmaydi.
Aralash siyosat
Bitta dimensionning ayrim ustuni Type 1, boshqasi Type 2 bo‘lishi mumkin. Masalan, ism xatosi Type 1, mijoz segmenti Type 2 saqlanadi. Type 2 o‘zgarishda yangi dimension row yaratiladi; bir vaqtda Type 1 ustuni o‘zgarsa, ayrim tashkilotlar faqat joriy rowni, boshqalari barcha tarixiy rowlarni yangilaydi. Siyosat oldindan hujjatlashtiriladi.
Data dictionary har atributning SCD turini ko‘rsatadi. Testlar surrogate key barqarorligi, uniqueness, null semantikasi va qayta ishlashni tekshiradi. Type 1 “noto‘g‘ri” emas; u tarix kerak bo‘lmagan aniq biznes savoli uchun ongli tanlovdir.
Factni qayta tasniflash
Type 1 update tarixiy factning dimension atributi bo‘yicha guruhlanishini o‘zgartiradi, garchi fact satri tegilmasa ham. Bu ba’zan maqsad: noto‘g‘ri mahsulot kategoriyasi tuzatilganda barcha tarixiy sotuv to‘g‘ri kategoriyada chiqadi. Agar oldingi rasmiy hisobotni aynan qayta yaratish talab qilinsa, report snapshot, semantic version yoki Type 2 tarix kerak. Qaror regulatory va boshqaruv talabi bilan belgilanadi.
CDC bilan ishlash
Source faqat joriy holat snapshotini bersa, qaysi atribut qachon o‘zgargani ma’lum emas. Type 1 uchun bu yetarli bo‘lishi mumkin. CDC oldingi va yangi qiymatni bersa ham pipeline tarixni saqlamasdan update qiladi, ammo audit logda hodisa qolishi mumkin.
Bog‘liq tushunchalar
Slowly Changing Dimension, Type 2, Dimension table, Surrogate key, ETL, Data warehouse, MERGE