SQL Server Analysis Service üzerinde küp adı verilen yapılar hakkında önceki yazımızda detaylı incelemeler yapmıştık. Hatırlayacağımız gibi, istenebilecek veriler veya başka bir deyişle ölçümler (measures) ve bu verilerin karşılaştırmalı olarak alınacağı boyutlar (dimensions), küp (cube) adı verdiğimiz saklama modeli ile tutuluyordu.
Şimdi bir küp modeli oluşturmak için gereken adımları inceleyelim ve bu aşamalarda karşımıza çıkacak olan kavramlar hakkında incelemeler yapalım. Öncelikli olarak basit bir küp ihtiyacını ortaya çıkaran örnek bir rapor ele alalım. Bir üretim firmasının dönem ve bölgelere göre satış miktarı raporunda, dönem ve bölgeyi boyut (dimension), satış değerlerini ise ölçüm (measure) olarak düşünebiliriz. Birden fazla boyutta inceleme yaptığımız ölçüm değerlerini tutan bu örnek küp aşağıdaki gibi düşünülebilir:
Resim-1
Boyutlu bir veri ambarında ölçüm değerlerinin (measures) detaylarını tutan tablolara gerçek tablosu (fact table) denir. Aşağıdaki resimde örnek bir fact table görüyoruz:
Resim-2
Bu fact table’ı analiz edersek, State, Product ve Month boyut (dimension), Units ve Dollars ise ölçüm (measures) olarak değerlendirilmelidir. Üstteki iki resmi karşılıklı olarak incelediğimiz zaman, küp gösterimi ile fact table’da bu gösterimin taban olarak alındığı verileri görebiliyoruz.
Fact table’ların aslında dimension ve measure’ları kombine eden küp yapıları için bir veri temeli olduğunu düşünebiliriz. Fact table’lar her bir measure için bir kolon tutarak, bunları dimension’larla eşler. Bu noktada, yıldız şeması (star schema) ve kar tanesi şeması (snowflake schema) arasındaki farkı vurgulamamız gerekir. Normal bir ilişkisel veritabanında yukarıdaki fact table’daki ürün, bölge ve ay bilgileri sayısal değerler halinde diğer tablolara foreign key ile ilişki kurarak çekilen değerler olarak değerlendirilir ve hatta bu tablolar da başka detay tablolarla ilişki halinde olurdu. Normalizasyon olarak adlandırılan bu yapı, veri ambarı yapısında da aynı şekilde tutulacak olursa bir fact table’ın bir veya birden fazla dimension tablosuna ve onların da ilşkide olduğu diğer tablolara bağlanması söz konusu olur ki, bu tip yapılar kar tanesi şeması (snowflake schema) olarak nitelendirilirler. Eğer dimension tabloları denormalize edilerek, tüm detay değerleri serbest veri olarak tek tabloda tutulursa ve fact table’lar bu tip denormalize bir veya birden fazla dimension tablosuna bağlanmışsa bu tip yapılara yıldız şeması (star schema) adı verilir.
Resim-3
Şekildeki star schemayı incelersek örneğin Product tablosundaki Product Type ve Product Sub Type gibi alanların normal bir ilişkisel veritabanının aksine denormalize edilerek tek tabloda serbest veri olarak tutulduğunu göryoruz. Aynı şeyi bu dizayndaki Sales Manager tablosunda Department alanı için ve herhangibir dizaynda herhangi detay alanı için de söylememiz mümkün. Eğer bu alanlar da başka tablolarla ilişkisel bir yapıda tutularak çekilse idi buna snowflake schema adı verilecekti.
Bu bilgiyi verikten sonra bir kübün en az 1 adet boyuta (dimension) sahip olması gerektiğini vurgulayarak devam edelim. Genel olarak bir küp dizayn ederken, öncelikli olarak boyutları (dimension) oluşturmaya başlamak gerekir. Tabii daha evvelki yazımızda vurguladığımız üzere herşeyden önce OLTP bir sistemi veri kaynağı olarak tanımlamamız gerekir.
SQL Server Business Intelligence Development Studio üzerinde yeni bir proje açarak, Solution Explorer üzerinde Data Sources dizinine sağ tıklayarak New Data Source tıklayarak erişmek istediğimiz server üzerindeki database için kullanıcı adı ve şifre vererek bağlantıyı sağlayabiliriz.
Resim-4
Analysis Service’in verileri barındıran canlı veri kaynağına bağlantısını bu şekilde sağlamış olduk. Şimdi bir yeni kavramla daha tanışalım. Şu an itibariyle bir veri kaynağına bağlanıp, bir veri ambarı projesi ve OLAP küpleri için ilk adımı attık. Bu adımda ise bu veri kaynağındaki nesnelerin hangilerini projemizde kullanacağımızı belirlememiz gerekiyor. Data Source View (kısaca DSV) olarak adlandırılan yapı bir veya daha fazla veri kaynağından alınan fiziksel tabloların mantıksal gösterimi şeklinde tanımlanabilir. DSV, fiziksel veri tabanı ile küp ve boyut yapıları arasında orta bir katman şeklinde duran Unified Dimensional Model (UDM)’in önemli bir bileşenidir.
Yeni bir Data Source View oluşturmak için, Solution Explorer üzerinde New Data Source View’a sağ tıklayarak bir önceki adımda belirlediğimiz Data Source üzerinden istediğimiz tabloları seçerek, Included Objects içine dahil edebiliriz. Unutmamamız gereken bir nokta, gerek Data Source View, gerekse küp ve diğer yapılar kolaylıkla güncellenebilen, esnek yapılardır. İstenen tablolar zaman içinde eklenip çıkarılabilir. Aşağıdaki resimde örnek bir Data Source View görüyoruz.
Resim-5
Bu işlemin ardından Solution Explorer üzerindeki Dimensions dizinine sağ tıklayarak New Dimension seçilir ve Dimension Wizard ile yeni bir boyut (dimension) ekleyerek kübü oluşturmak için yeni bir adım atılmış olacaktır. Dimension Wizard üzerinde Auto Build seçeneğini tercihen bu örnekte ve genel olarak seçmemek yolunda hareket ediyoruz. Zira Auto Build seçeneği bir boyut (dimension) üzerindeki tüm attribute’ları otomatik olarak oluşturur. Oysa biz oluşturduğumuz dimension’ın sadece istediğimiz ve ihtiyaç duyduğumuz attribute’ları oluşturarak daha verimli çalışmış oluyoruz.
Resim-6
Yukarıdaki resimde görüldüğü üzere bu örnekte ana tablo (main table) olarak Product seçildi. Key column’dan kasıt ayırt edici alandır, bu tablodaki ilgili olan Product_Key alanı olduğu için bu alanı seçtik, member name ise görünecek olan alan (value member / display member gibi düşünülebilir) – Product_Name olarak belirlendi.
Resim-7
Dimension’ın attribute’larını da yukarıdaki resimde görüldüğü gibi Select Dimension Attributes üzerinden seçiyoruz. Relational database mantığında bir tablo için alanlar ne ise Dimension için de attribute’lar odur diyebiliriz. Küp raporda görünmesini isteyebileceğimiz faydalanabileceğimiz ilgili tüm attribute’ları buradan seçebiliriz.
Son adımda da dimension type olarak Regular seçilerek Dimension için uygun isim belirlenir (bu örnek için Product diyebiliriz) ve ilgili Dimension eklenmiş olur. Unutmamamız gereken en önemli nokta, işlemlerimizi tamamladıktan sonra projemizi Deploy etmemizdir.
Resim-8
Bu işlemin ardından Dimension kullanıma hazır durumdadır. Küp raporda istediğimiz diğer tüm dimension’ları da bu yöntemle eklemeliyiz. Dimension tipi olarak burada tercih ettiğimiz gibi Standart bir dimension seçebileceğimiz gibi, Time dimension ve Parent – Child dimension da ekleyebiliriz. Özellikle küp raporlar için sık duyacağımız bir nokta olarak genelde tüm küplerin zaman periyodunda incelenen raporlar olduğunu ve zaman boyutu olmayan bir küp raporun çok da anlamlı olmadığını görürüz. Parent – Child tipi bir dimension’a örnek olarak çalışan hiyerarşisi, ilçe – il, bölge – ülke ilişkilerini gösterebiliriz.
Bir küp oluştururken bir diğer önemli nokta Measure’ları oluşturmaktır. Bir kübün aslında Measure’ları Dimension’larla birden fazla bakış açısında eşleyen yapılar olduklarını unutmayalım. Sistemi Dimension’ları oluşturarak kurmaya başladık. Şimdi Measure’ları oluşturmaya başlayabiliriz. Öncelikli olarak bir kural daha verelim. Bir küpte en az bir Measure olması zorunludur ve bu Measure da bir Measure Group altında tanımlanır. Bu işlemleri gerçekleştirebilmek için Solution Explorer üzerinde Cubes dizinine sağ tıklayarak New Cube seçilir ve Cube Wizard açılır.
Resim-9
Cube Wizard üzerinde ilgili adımları geçerek Fact ve Dimension table’ları seçtiğimiz bu pencere açılır. Product ve Date tablolarını Dimension tablosu olarak belirledikten sonra fact table olarak detay değerlerin tutulduğu Sales tablosu seçilir.
Resim-10
Resimde görüldüğü üzere Sales measure group altında Sales Dollars, Sales Units ve Sales Count measure olarak seçili geldi. Bu measure’larla beraber değerlendirmek istediğimiz uygun Dimension’ları da seçiyoruz. Son adımda küp için uygun isim belirlenir ve işlem sonlandırılır. Artık küp kullanıma hazır durumdadır.
Şimdiki adımda ise oluşturduğumuz kübe göz atacağız. Bu işlem için Cubes dizini altında oluşturduğumuz kübe sağ tıklayarak Browse ekranını seçeceğiz.
Resim-11
Cube Browser adını verdiğimiz bu ekranda Drop Total or Detail Field Here yazan ortadaki bölüme, Measures altındaki ilgili Measure’ı sürükleyip bırakmamız ve sütün / satırlara da istediğimiz Dimension’ları süreklememiz yeterlidir.
Resim-12
Sonuçta alacağımız örnek rapor çıktısını bu resimdeki gibi düşünebiliriz.
Böylelikle baştan sona bir küp dizayn ederken geçilen aşamaları incelemiş olduk. Bir sonraki yazımızda bir Analysis Service projesinin güvenliği ile ilgili kavramları ele alacağız.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
