Business Intelligence Projelerinin Temel Elementleri - 2
Genellikle N tane temel işlevler yapan ETL paketleri hazırlanarak bir tane hepsini çalıştıran master ETL paketi hazırlandığında ETL sürecini yönetmek daha rahat olacaktır. Çünkü özellikle kullanım rahatlığından ötürü MS Visio gibi çok rahat bir kullanımı olsa dahi kimi zamanlarda işin içinden çıkılamayabiliyor. Puzzle mantığında hareket edilirse bir hata anında çok daha hızlı aksiyon alınarak çözüm oluşturulabilir.
OLAP Cube
Bir önceki yazıda belirtmiş olduğumuz fact tablosu ve dimension tablolarından oluşan yapıdır. Verilere çok farklı boyutlardan bakabilmemiz sebebi ile bu yapılara cube denilmiştir.
Belirlenen boyutlar (dimension) ile hesaplanan alanların (measures) derinlemesine analiz edilebildiği bu yapılarda karşımıza SQL script dışında farklı sorgulama dilleri de çıkmaktadır.
Bunlardan ilk kullanılacak olan MDX (Multidimensional Expressions)‘dır. Sorgulaması gerçekçi olmak gerekirse SQL script kadar rahat değildir. MDX ile beraber karşımıza ihtiyaç dahilinde DMX (Data
Mining Extensions) ve XMLA (XML For Analysis Services) çıkmaktadır.
Özellikle Microsoft SQL Server üzerinde yer alan Analysis Services projeleri geliştirirken ürünün oldukça fazla user friendly olmasından ötürü bu sorgulama dillerini kullanmıyor durumunda olabilirsiniz. Fakat bu her zaman olmayacak demek değildir. Kimi hesaplama durumlarını MDX yerine veriambarına yükleyebilirsiniz.
Star Schema & Snowflake Schema
Veriambarında yer alan iki farklı tablo yapımız vardır. Bunlar fact tabloları ve boyut (dimension) tabloları. Bu iki tablo yapısının ilişkileri iki farklı modelde karşımıza çıkmaktadır. Ortada tek bir fact tablosunun olduğu, buna bağlı boyut tablolarının yer aldığı yapıya “star schema” denilmektedir. N fact tablosunun N boyut tablosu ile ilişkilendirildiği yapılara ise “snowflake” denir.
Snowflake şemalarıyla gerçekleştirilen projelerin process maliyeti daha yüksek olduğu için dikkat etmek gerekir.
SSAS′de, BIDS (Business Intelligence Development Studio) küp tasarım arayüzündeki SSAS veri matrisi tabı (data matrix) size farklı fact tabloların boyut tablolarındaki kayıtlara ilişkilendirmenizi sağlayacak ilişki dokularını (grain) tanımlama imkanı sunmaktadır.
Bir tek, büyük (hatta devasa) küp (ya da ticari veri görünümü) üzerine kurulmuş çoğu iş zekası çözümünde bu gelişmiş esneklik uygulanmaktadır. Bu tarz bir modellemenin ilişkili iş verisinin tek ve ortak bir sürümünün (unified version) gereksiniminden ihtiyaç olarak yansıdığını düşünebiliriz.
Bu tasarımdaki küp, veriyi belirli son kullanıcılara anlamlı gelecek her detay seviyesinde sunumu sağlamaktadır. Bu da verinin istenildiği gibi özetlenmesi, detaylanması ya da bu iki hareketin de kombinasyonudur denebilir.
En çok kullanılan ilişkilendirme modelinin karşısında bir de “snowflake” modellemesi vardır ki bizim gibi kullananların bir musibet saydığı üzere iş gereksinimleri kullanımlarını yerinde saymadığı sürece kullanımından kaçınılmalıdır çünkü bu kar tanesi modeli küp süreçlemeleri ve küp sorgulama sürelerine aşırı yükleme (overhead) ekleyecektir ve doğrudan performansı olumsuz etkileyecektir.
Star Schema
Bu yapının performans maliyeti oluşturmasının nedeni ise veri basitçe doğrudan alınmak yerine süreçleme (process) ve sorgulama (query) anında bağlanmak (joining) zorundadır.
Basit bir sorgulama ve raporlama sistemi oluştururken dahi denormalize olmuş (join kullanımı indirgenmiş) yapılardan raporlamanın her zaman daha az kaynak maliyeti olduğunu anlatmıştık.
İşte küp modellemelerinin de veri tablolarının normalize ve denormalize yapılarına paralel snowflake ve starschema yapıları mevcuttur. Özetle starschema denormalizasyonun OLAP karşılığıdır.