Data Dimensional Modelling, Facts və Dimensions nələrdir.

Data Dimensional Modelling(DDM)

DDM Verilənlər Xəzinəsində məlumatları səmərəli şəkildə saxlamaq üçün Dimensions və Fact -lardan istifadə edən texnikadır. Bu model verilənlərin əldə edilməsi üçün əlverişli və optimal üsullardan biridir. DDM verilənlərin artıqlığının(data redundancy)olmamasını təmin etmək və performansı yaxşılaşdırmaq üçün məlumatları ən optimallaşdırılmış şəkildə saxlanmanı təmin edir. DDM-ə aşağıdakı şəkili nümunə göstərə bilərik.

DDM -ə adi nümunə

DDM müxtəlif Məlumat Anbarlarında mövcud olan məlumatları təhlil etməyin unikal üsuluna görə populyarlıq qazanmışdır. Bu modelin 3 əsas xüsusiyyətini qeyd etmək istərdim:

1. Asan başa düşüləndir. DDM developerlərin biznes userlərin istəklərinə uyğun olaraq yeni baza və schema-ların asanlıqla yarada bilməsini təmin edir.
2. Verilənlərin keyfiyyətinin qoruyur. DDM dimension ve fact cədvəlləri arasında istifadə edilən xarici açar (foreign key) vasitəsi ilə fraudulent(saxta) verilənlərin bazaya yüklənməsinin qarşısını alır.
3. Performansı optimallaşdırır. DDM məlumatları Dimension -lara və Fact -lara bölür ki onları da xarici açarlar əlaqələndirir və bununla da data redundancy azaldır. Məlumatlar optimallaşdırılmış formada saxlanılır və buna görə də yaddaşda daha az yer tutur və daha sürətli əldə edilə bilir.

Facts

Facts cədvəlləri star schema və ya snowflake schemalarının mərkəzində yerləşir və əsasən transaction (əməliyyatlar) məlumatlarını özündə saxlayırlar. Məsələn: ödəniş əməliyyatları cədvəli.
Mərkəzdə bir neçə facts cədvəlindən istifadə edildikdə fact constellation schema( ulduzlar qrupu ) sxeması əldə edilir. Facts cədvəlində əsasən 2 növ sütunlar olur. Birincisi Faktlar haqqında məlumatları özündə saxlayan sütunlar digəri isə dimensions cəvəlləri ilə xarici açar olanlar.
Faktlar cədvəlinin əsas açarı(primary key) adətən onun bütün xarici açarlarından ibarət olan mürəkkəb açardır.

Faktların üç növü var:

1. additive
   Bu növ fakt -lar facts cədvəlində olan bütün növ dimention -lar üzrə agregate etmək olar.
   Nümunə — Fərz edək ki, pərakəndə satış şirkəti üçün aşağıdakı sütunlara malik satışlar adlı fakt cədvəlimiz var: tarix, produkt, mağaza, satılan_produktlar
   Bu cədvəldən bütün mağazalar üzrə satılan məhsulların sayını qeyd etmək üçün istifadə olunur. Bu halda biz satılan_produktlar sütununu digər bütün dimension sütunlar(tarix, produkt, mağaza) üçün ümumiləşdirə bilərik. Burada satılan_produktlar additive fakt deyilir, çünki fakt cədvəlindəki bütün ölçülərə baxmayaraq ümumiləşdirilə bilər.
2. non-additive
   Bu növ fakt -ları facts cədvəlində olan heç bir dimention üzrə agregate etmək olmur.
   Nümunə — eyni adda cədvəl olsun amma indi satılan_productlar deyil də mənfəət sütunu olsun cədvəldə: tarix, produkt, mağaza, mənfəət
   Tutaq ki, 1-ci gün üçün mənfəət 70%, 2-ci gün üçün isə 30% təşkil edib.
   Bu halda ümumi mənfəətin də agrigate edilərək 100% olduğunu deyə bilmərik, yanlış data olar. Burada balans semi-additive faktdır.
3. semi-additive
   Bu növ fakt -ları facts cədvəlində olan bəzi dimentionlar üzrə agregate etmək olur.
   Nümunə — Fərz edək ki, aşağıdakı sütunlara malik balans adlı fakt cədvəlimiz var: tarix, account, balans
   Bu halda müəyyən bir gün üçün bütün hesab balansını aggregate etmək məna kəsb edir, lakin balansı zaman ölçüsü ilə aggregate etməyin mənası yoxdur. Burada balans semi-additive faktdır.

Dimensions

Dimension cədvəlləri Facts cədvəllərinin ayrılmaz hissələridirlər. Yuxarıda da dediyimiz kimi Facts cədvəlləri star schema və ya snowflake schemalarının mərkəzində yerləşdiyi halda Dimension cədvəlləri də bu Fact cədvəlləri ətrafında olaraq əməliyyat, hadisə və s. ilə əlaqəli “kim, nə, harada, nə vaxt, necə və niyə” kimi məlumatlarını özündə saxlayırlar. Məsələn, satış Verilənlər Xəzinəsində Fact cədvəli ümumi satış məbləğini saxladığı halda, Dimension cədvəli satış tarixi, satılan məhsul və satışın yeri kimi məlumatları saxlaya bilər. Dimension cədvəllərində çoxlu sayda sütunlar olur. Dimension cədvəlində 50–100 atributunun olması qeyri-adi hal deyil, baxmayaraq ki, bəzi dimensionlar yalnız az sayda atributlara malik olurlar. Dimension cədvəlləri Fact cədvəllərindən daha az sətir sayına malik olduqları kimi, bir çox böyük mətn sütunlarını da özündə ehtiva edə bilərlər.

Dimension cədvəllərinin bəzi növlərinə baxaq:

1. Conformed dimension — bu növ dimensionlar yalnız bir Fact cədvəli üçün deyil də bir neçəsi üçün ortaq olan məlumatları saxlayır. Məsələn time dimension deyə bilərik. Time dimension yuxarıda qeyd edilmiş olan hem satışlar Fact cədvəli ilə, həm də balans Fact cədvəli ilə işlədilə bilər.
2. Degenerate dimension — bu növ dimension ayrıca cədvəl kimi yox, Fact cədvəli içində sütun kimi də anlamaq olar, hansı ki, bizə heç bir ayrıntı vermir. Məsələn transactions cədvəlində transaction_id sütunu.
3. Junk dimension — bu növ dimension fact cədvəldə olan transactional code, flags və s. kimi sütunları özündə birləşdirməklə fact cədvəlində sütun sayını azaldır.
4. Role-playing dimension — bu növ dimension cədvəli eyni fact cədvəlinin müxtəlif dimension sütunları ilə işlədilə bilər. Məsələn satışlar fact cədvəlimiz var olsun, sütunları da id, sales date, shipping date olsun. Time dimension bu satışlar fact cədvəlinin həm sales date, həm də shipping date sütunları ilə işlədilə bilər.

Slowly-Changing Dimensions (SCDs)

Bəzən dimention cədvəllərində dəyişikliklər baş verə bilir. Məsələn, müştəri məlumatları saxlayan customer_info deyə dimension cədvəlində bəzi demografik məlumatlar (adres, telefon nömrəsi və. s) dəyişə bilər. Bu dəyişikliklər core cədvəllərdə olan zaman Verilənlər Xəzinəsində də etmək lazımdır. SCDs -in də bir neçə növü var ki, bunlardan əsas olaraq düşündüklərim haqqında yazaq.

1. SCD 1(overwrite) — Core sistemdə dəyişiklik edilir və bu məlumat Verilənlər Xəzinəsinə load edilən zaman köhnə data silinir və yenisi yazılır əvəzində. Bu halda biz dəyişiklikləri historik olaraq görə bilmirik.
2. SCD 2(add new row) — Core sisemdə dəyişiklik edilir və bu məlumat dimension cədvəlimizə load edilən zaman köhnə məlumatı saxlayan sətir inactive edilir(flag sütun əlavə edilir dimension cədvəlinə) və yeni sətir əlavə edilir cədvələ. Bu halda historik məlumat qalır, amma zaman keçdikcə dimension cədvəlimizin həcmi böyüyür və performans problemləri yaranır.
3. SCD 3 (add new attribute) — Core sisemdə dəyişiklik edilir və bu məlumat dimension cədvəlimizə load edilən zaman köhnə məlumat olan sətir qalır olduğu kimi, amma yeni sütun əlavə edilir dimension cədvəlinə hansı ki update edilmiş versiyanı saxlayır. Bu halda SCD 2 ilə oxşardır, amma SCD 2-də olduğu kimi table size o qədər də artmır. Buna baxmayaraq historik olaraq yalnız ən son edilmiş dəyişiklikləri görə bilirik. Çünki hər dəyişiklik edilən zaman köhnə sütun yeni sütun datası ilə update edilir və yeni sütuna core sistemdəki dəyişilmiş up to date məlumat yazılır.
4. SCD 4 (adding history table) — Fikrimə görə ən etibarlısı budur :)
   Bu halda original dimension cədvəlimizin historikal versiyası yaradılır ki, həmin cədvəldə ya bütün dimension cədvəlinin kopyası plus edilən dəyişikliklər saxlanılır (bir növ SCD 2 kimi), və ya həmin cədvəldə ancaq dəyişikliklər edilən sətirlər saxlanılır. Original dimension cədvəlimizdə isə coreda edilən son dəyişikliklər saxlanılmış olur.

İstifadə etdiyim qaynaqlar:

https://www.linkedin.com/pulse/data-dimensional-modelling-nishi-kumari/
https://az.wikipedia.org/wiki/Veril%C9%99nl%C9%99r_x%C9%99zin%C9%99si
https://www.simplilearn.com/fact-table-vs-dimension-table-article#fact_table_vs_dimension_table
https://vertabelo.com/blog/facts-dimensions-data-warehouse/