Bilindiği üzere bilişim sektöründe her yenilik, temelde bir teoriye ve bu teoriye bağlı geliştirilen bir modele dayanmaktadır. Bu günlerde popüler olan veri ambarı konusunun mantığı, aslında dimensional modelleme ile sağlanmıştır. Bu yazıda bu konuyu irdelemeye çalışarak veri ambarı konusuna daha fazla aşina olmaya çalışacağız.
Bu modelde amaç operasyonel sistemden alınan veriyi düzenli bilgiler halinde tutmaktır. Kesinlikle veriyi kopyalama işlemi değildir! Çünkü dimensional modellemede veriler anlamlı ve düzgün olmak durumundadır. Operasyonel sistemlerde veriler departmanların iş akışlarına uygun olarak eklenmez. Fakat bu modelleme ile veriler iş akışlarına uygun olarak transfer edilirler. Bunun anlamı verilerin hatalardan ayıklanmış hale getirilmesidir. Yani kalabalık ve anlamsız veriler çıkarılıp iş akışına uygun anlamlı veriler saklanır. Kaliteli, zenginleştirilmiş ve temiz veriler bu modelleme için bir lüks değildir. Böylelikle ihtiyaç duyulan veriler okunur durumda saklanacaktır. Tüm bu işlemler de bilindiği üzere ETL ve ELT araçlarıyla sağlanır ki günümüzde farklı algoritmalar kullanan onlarca ETL-ELT araçları mevcuttur.
Dimensional modellemede amaç SELECT sorgusuna çok hızlı yanıt verebilmektir. Her sistemde olduğu gibi bir tarafa ağırlık vermek, diğer taraftan taviz vermeyi gerektirir. Yani SELECT ne kadar hızlıysa, diğer DML işlemleri (INSERT-UPDATE-DELETE) bir o kadar yavaş sağlanır. Fakat veri ambarı sistemlerinde gün içerisinde mesai saatinde DML işlemleri uygulanmaz. Sadece gece 12:00 ile sabah 9:00 arasında DML sorguları işlenir. Bu da onların yavaş olmasının bir dezavantaj olmasını gerektirmez. Yani asıl amaç raporlama için SELECT sorgularını hızlıca sağlamak olup diğer sistemleri etkilememektir. Tüm bunların aksine operasyonel sistemler gün içerisinde sürekli DML sorguları çalıştırırlar. Fakat bir SELECT sorgusu ile işlem yapmak operasyonel sisteme inanılmaz yük getirir. Büyük ve pahalı sunucular bile bu yorgunluğa çözüm olamaz. Tek alternatif dimensional modelleme gibi görünüyor :)
Dimensional Modelleme bir analitik sistem modelleme tekniğidir. Nasıl ki operasyonel sistemler için modelleme teknikleri mevcutsa, analitik sistem için de henüz geliştirilmiş, alternatifi olmayan modelleme tekniği; dimensional modellemedir. Şimdi analitik sistem kavramlarına değinelim;
FACT: Ölçülebilen birimlere verilen tanımlamadır. Satış adedi, satışı iptal adedi, tarife değişikliği adedi, toplam fatura adedi gibi aritmetik işlem uygulanabilecek sayıları kapsayan birimlerdir.
DIMENSION: Aritmetik işlem uygulanamaz olup, tablolardaki metriklerin anlaşılır olarak okunması için kullanılırlar. Tarih bilgisi, müşteri bilgisi gibi...
Mesela satış adedi bir fact bilgisidir. İlçe ise dimension bilgisidir. İlçe bazında satış adedi ise anlamlı bir bütün olarak okunabilir bir rapor sistemini ifade eder.
Dimensional modellemenin sunduğu 3 adet mimari yaklaşımı mevcuttur. Bunları inceleyelim;
- Datamart: Okunabilirliği yüksek olan bir yapıdır. Dimension'lar ve fact'lar aynı tabloda incelenir. Herhangi bir join işlemine ayrıca gerek duyulmaz. Sisteme yabancı olan kullanıcıların rahatlıkla anlayabileceği bir yapıdadır. Tüm bilgileri aynı tabloda analiz etmek bir avantajdır. Ancak çok fazla dimension olması durumunda tablonun boyutları artacağı için bu yapılarda kullanılması okunurluğa ters etki yapabilir.
- Star Schema: Dimension ve fact veriler farklı tablolarda tutulurlar. Bir adet fact tablosu bulunur ve
dimension tablolar bu tablo ile ilişki kurmak için kolonlar kullanırlar. Bir rapor için fact tablosu ile arzu edilen dimension tablosu tek bir join ile işlenir ve sonuç analiz edilir. Bu sistemin avantajı birbiriyle alakası olmayan verileri aynı tabloda tutmaktan kurtulmaktır. Yani analiz yapılacak nesne, bilgi karmaşası olmadan getirilir. Sadece ilgilenilen veriler analiz edilir. Çok fazla dimension olması durumunda kullanılmalıdır. Aşağıdaki gibi ortada fact, kenarlarda tek bir ilişkiyle bağlanmış dimensionların yıldızı andıran şeması örnek olabilir;
- Snowflake: Yine dimension ve fact'lar farklı tablolardadır. Fact tablosu yine bir tanedir. Ancak bağlantı sayısı ve join sayısı birden fazladır. Aşağıdaki resimden bu görülebilir. Eğer bir dimensionun içeriği satırlarca uzunluktaysa bu dimension bölünmelidir. Bölünme işlemi yapıldıktan sonra bu mimari yaklaşım uygulanır. Böylelikle okunurluk korunmuş olsa da join işlemlerinin artması hiç bir zaman önerilmez. Yani en az join işlemi bizim için daha idealdir. Aşağıda bir fact tablosu etrafına sıralanmış birden fazla ilişki olan dimensionlar gözükmektedir.
Peki dimensional modelleme yapmamız gereken bir süreç olduğunda hangi sıralamayı takip edeceğiz? Elbette bu içinde bulunulan duruma göre farklılık gösterecektir. Nasıl ki bir operasyonel sistem problemini çözerken Yazılım Geliştirme Yaşam Döngüsü süreç çözümlerini kullanıyorsak burada da takip edilmesi profosyoneller tarafından uygun görülmüş bir sıralama mevcut:
- Ölçüm yapılacak süreç seçilir (Satış departmanı)
- Ölçüm ün neden yapılacağı belirlenir: Tarih, ürün ve satış temsilcisi bazında toplam satış adedi.
- Dimension'lar belirlenir: Tarih, ürüm, satış temsilcisi.
- Fact'lar belirlenir: Satış adedi, toplam ödenen ücret, her satıştaki kar.
Böylelikle sistem yukarıdaki 3 modelden en uygun olanıyla desteklenir ve gerçeklenir. Elbette hangi modeli kullanacağııza dimensionlarınızın yapısı, büyüklüğü ve sayısıyla karar vereceksiniz.
Şimdi de son olarak Dimensional modellemenin faydalarına bakalım:
- Anlaşılabilirlik: Operasyonel sistemler daha anlaşılır olabilmek adına Normal Formlarını kullanırlar. En ideali 3NF'dir. Bu form yapıları makine algısını optimize etmek amacıyla kullanılırken, dimensional modelleme insan algısını kolaylaştırmak adına uygulanır.
- Performans: SELECT sorgusu performansını arttırırlar.
- Genişletilebilirlik: Bu modelleme tekniği dinamiktir. Her zaman ekleme yaparak genişletmek mümkündür.
Böylelikle önemli bir konuyu daha tamamlamış olduk. Bakarsınız önümüzdeki yıllarda analitik sistemler için daha iyi modelle teknikleri keşfedilir.
Herkese iyi çalışmalar!
Hiç yorum yok:
Yorum Gönder