Dimension — data warehouse va OLAP modelida faktlarni tavsiflash, filtrlash va guruhlash uchun ishlatiladigan biznes atributlari to‘plamidir. Mijoz, mahsulot, vaqt, hudud va kanal dimensionga misol. Fact jadvali “qancha” yoki “nima sodir bo‘ldi”ni saqlasa, dimension “kim, nima, qayerda, qachon va qanday turda” savollariga kontekst beradi.
Dimension jadvali
Dimension row odatda surrogate key, business key va tavsifiy atributlarga ega. product_key warehouse ichki join kaliti, product_id manba tizimidagi biznes identifikatori bo‘lishi mumkin. Category, brand, color va package size foydalanuvchiga hisobot kesimlarini beradi.
Dimension ko‘pincha de-normalizatsiya qilinadi. Star schema da fact bir jadvalga join qiladi, query sodda va tez bo‘ladi. Snowflake schema kategoriyani alohida jadvallarga ajratib takrorni kamaytiradi, lekin join va foydalanuvchi murakkabligini oshiradi. Tanlov engine va governance talabiga bog‘liq.
Grain va hierarchy
Dimension graini bitta row nimani anglatishini belgilaydi. Mahsulot dimensioni SKU darajasidami yoki model darajasidami, aniq bo‘lishi kerak. Fact SKU keyga ega bo‘lib, dimension model darajasida bo‘lsa many-to-many yoki noto‘g‘ri join paydo bo‘ladi.
Hierarchy drill-down yo‘lini beradi: yil → chorak → oy → kun yoki mamlakat → viloyat → tuman. Level munosabati qat’iy bo‘lmasa ragged hierarchy yuzaga keladi. Bir shahar bir nechta savdo hududiga tegishli bo‘lsa oddiy tree emas, bridge table talab qilinishi mumkin.
Vaqt dimensioni
Date dimension kalendar sana, hafta kuni, chorak, bayram, moliyaviy davr va ish kuni flaglarini oldindan saqlaydi. Timestampdan har queryda bir xil qoidani qayta hisoblash o‘rniga boshqariladigan kalendar beradi. Turli mamlakat va kompaniya fiscal calendar farq qilishi mumkin.
Role-playing dimension ayni date jadvalini order_date, ship_date va payment_date rollarida ishlatadi. SQL alias va semantic layer rollarni farqlaydi. Degenerate dimension alohida jadvalsiz factda saqlanadigan buyurtma raqami kabi atributdir.
Slowly changing atributlar
Dimension atributi vaqt bilan o‘zgaradi. Type 1 eski qiymatni ustidan yozadi, Type 2 yangi versiya yaratadi, boshqa SCD turlari oldingi qiymat yoki tarixni alohida usulda saqlaydi. Har atribut uchun tarixiy savolga mos siyosat belgilanadi.
Unknown yoki not applicable member factning dimension kaliti topilmaganda referential integrityni saqlaydi. Barcha noma’lum sababni bitta qiymatga qo‘shish sifat muammosini yashirishi mumkin; late arriving, missing source va haqiqiy “qo‘llanmaydi” alohida kodlanadi.
Conformed dimension
Conformed dimension bir nechta fact yoki data martda ayni ta’rif va key bilan ishlatiladi. Sotuv va qaytarish jadvallari bir mahsulot dimensioniga bog‘lansa, ko‘rsatkichlar izchil kesimda taqqoslanadi. Nomlari bir xil, lekin grain yoki SCD qoidasi boshqa bo‘lgan jadvallar conformed hisoblanmaydi.
Dimension sifati uniqueness, null, hierarchy integrity va source mapping bilan tekshiriladi. Surrogate key qayta ishlatilmaydi. Business glossary atribut ma’nosini, lineage esa qaysi manba va transformatsiyadan kelganini ko‘rsatadi.
Junk dimension
Bir factdagi ko‘plab past cardinalityli flag va kodlarni alohida kichik junk dimensionga birlashtirish mumkin. Har kombinatsiya surrogate key oladi. Bu fact jadval ustunlarini kamaytiradi va tavsiflarni boshqaradi, ammo mumkin bo‘lgan kombinatsiyalar soni portlamasligi kerak. Yuqori cardinality yoki mustaqil tarixga ega atribut junk dimensionga mos emas.
Mini-dimension
Tez o‘zgaradigan mijoz atributlari asosiy Type 2 dimensionni haddan tashqari ko‘paytirsa, demografik profil mini-dimensionga ajratiladi. Fact yoki bridge tegishli profil keyni saqlaydi. Bu tarixni ixchamlaydi, lekin query joinlari va joriy profilni topish mantiqini oshiradi.
Bog‘liq tushunchalar
Fact table, Star schema, Slowly Changing Dimension, Surrogate key, Hierarchy, Conformed dimension, OLAP