Yazı dizimizin son bölümünde star şemaları incelemiş ve örnek firmamızın veritabanı modeli üzerinde çalışmıştık. Bu bölümde ise star şemalara alternatif olarak kullanılan snowflake şemalarını inceliyor olacağız.

Snowflake şemaları ilişkisel veritabanlarından aşina olduğumuz ilişkisel bir yapı sunar. Snowflake yapısında hiyerarşinin her bir katmanı, ayrı bir tabloda saklanır. Aşağıdaki grafikte bunu görebilirsiniz. Star yapısı gibi snowflake yapısıda ismini tasarım sonrasında ortaya çıkan görünümden almaktadır.

Start yapısında olduğu gibi, bu yapıdada ilişkiler foreign keyler aracılığıyla yönetilir. Bu nedenle fact table, tüm üyelerin en alt seviyesinin kombinasyonları için ayrı ve eşsiz bir kayıt içerir. Bu hiyerarşi seviyeleri için ölçütler star şemadaki gibi hesaplama yöntemi ile elde edilirler.

Snowflake Yapısı, Star Yapısı ve Analysis Services
Snowflake ilişkisel tasarımın tüm avantajlarına sahiptir. Duplicate veri oluşumu söz konusu değildir ve bu nedenle yönetimi daha kolaydır. Ek olarak ilişkisel veritabanları üzerinde deneyim sahibi kişiler için anlaşılması ve kullanımı daha kolaydır.

Snowflake yapısının dezavantajı ise ölçütlerin hesaplanması sırasında pek çok join gerektiriyor olmasıdır. Büyük ölçekli data martlarda bu son derece ciddi performans sıkıntılarına yol açabilmektedir.

Hem snowflake, hem de star yapısında hesaplamalarımızı on the fly gerçekleştiririz. Çok sayıda dimension içeren ya da çok fazla üyeye sahip dimensionlarda bu ciddi zaman gerektirebilmektedir. Bu measureları önceden hesaplayarak data martta, disk üzerinde saklayabiliriz ancak bu data mart’ın yapısını oldukça karmaşık hala getirerek yönetimini zorlaştırabilir.m Peki data mart’ın sorumlularının akli dengesini bozmadan yüksek performanslı bir yapıyı nasıl oluşturabiliriz? Bu noktada OLAP altyapıları devreye girmektedir.

Altyapı konusunda bir sonraki adımda bahsedeceğimiz Analysis Services ya da en az Microsoft’un Analysis Services ürünü kadar yaygın olan Oracle BI ürünleri bu noktada devreye girer ve bu işin sağlıklı, yüksek performanslı ve kolay yönetilebilir bir hal almasını sağlarlar. Ben yazı dizisinin ilerleyen bölümlerinde Analysis Services ürününü kullanıyor olacağım. Bir sonraki bölümde Microsoft SQL Server Analysis Services ürününü tanıyor olacağız.

Etiketler: analysis services, star schema, snowflake schema, fact table

Star Schema
Measure ve Dimension’lar data mart’ta iki şekilde saklanırlar. İlk olarak star schema’yı ele alacağız. Bu şemanın ismi, bu türdeki data mart için oluşan ilişkisel database diagramın görünümünden gelir. Star schema 2 tür tablo kullanır: fact table ve dimension table.

Bir start schema’nın merkezinde fact table yer alır. Fact table measure için bir sütun içerir ve her dimension’ın üyeleri için bir foreign key alan içerir. Bu tablonun primary key alanı, tüm foreign ket alanların birbirine bağlanması ile ortaya çıkar. Bu yapıya aynı zamanda composite key ismi verilir. Fact table’lar içerdikleri measure’ın isminin sonuna Fact ekinin eklenmesiyle isimlendirilirler. Örneğimizdeki fact table bu şekilde isimlendirilerek SalesFact ismini almıştır.

Dimensionlar dimension tablolarında barındırılırlar. Dimension table’lar dimension’ın üyelerini tanımlamakta kullanılan eşsiz genellikle integer olarak tanımlanan bir anahtar alanına ve bu üyeyi açıklayan bir açıklama alanına sahiptir. Dimension tablosunda saklanan her dimension için ayrı bir satır oluşturulur. Dimension tabloları içerdikleri dimension’a göre başına Dim ön eki getirilerek isimlendirilir. DimProductType dimension tablosunun satırları şu şekilde olacaktır.

Dimension tablolarını şemaya eklediğimizde, aşağıdaki grafiktekine benzer bir görünüm elde ederiz.

Büyük ihtimalle, fact tablosu dimension üyelerinin ortaya çıkaracağı eşsiz kombinasyonları içerecektir. Büyük ihtimalle dememin nedeni, dimension üyelerinin bazı kombinasyonlarının değer içermemesidir.

Örneğimize göre, “Milliyet Gazetesi Reklam Kampanyası” “marketing campaign” dimension’ının bir üyesi olursa, Sales Fact tablosunun içeriği şöyle olacaktır.

Örneğimizde “marketing campaign” dimension’ının 8 üyesi olacağını, yıl dimension’ının 6 üyesi olacağını, product type dimension’ının 4 üyesi olacağını, sales region dimension’ının 7 üyesi olacağını ve buyer’s age dimension’ının 6 üyesi olacağını düşünecek olursak Fact tablosunda 8 x 6 x 4 x 7 x 6 adet veya 8.064 adet satırımız olacaktır. Bu yapıda çok büyük bir değer gibi görünmese de, on ya da yüzlerce üyeniz olduğunda, fact tablonuzun boyutu ciddi oranda büyüyecektir.

Gerçekte, fact table dimension üyeleri için açıklama değil identifier bilgilerini içerir. Bu kullanılan disk alanında ciddi tasarruf sağlar. Satır sayınız milyonlara ya da 100 GB ve üzerinde bir veritabanı ile çalışmaya başladığınızda burada bahsettiğim şeyin önemini çok daha iyi anlayabilirsiniz.

Ek olarak, tek bir fact table, birden çok measure içerebilir. Bu iki ya da daha fazla measure’ın, aynı dimension’ı kullandığı durumlarda karşılaşılan bir durumdur. Birden çok measure’ı, aunı dimension’larla aynı fact table’a koymak, data mart tarafından kullanılan disk alanında ciddi tasarruf sağlayacaktır.

Attribute’lar
Bazı durumlarda dimension üyeleriyle ilgili bazı ek bilgileri saklama ihtiyacı duyarız. Bu dimension’ın üyelerini daha iyi tanımlamamıza yardımcı olur. Bu ek bilgiler dimension’ın attribute’ı olarak adlandırılır.

Attribute’lar dimension üyelerini daha iyi tanımlamak için kullanılırlar. Kullanıcılarının çıktı olarak isteyebilecekleri bazı bilgileri içerebilecekleri gibi, data mart’tan analiz esnasında çekilecek verilerin kısıtlanması ya da filtrelenmesi amacıyla kullanılmak üzere bazı bilgileri barındırabilirler. Attribute’lar dimension tablolarında aşağıdaki grafikte görüldüğü gibi ek alanlar şeklinde saklanırlar.

Hiyerarşiler
Çoğu durumda dimensionlar daha büyük bir yapının üyesi durumundadırlar. Bu yapıya hiyerarşi adı verilir. Örneğimizde yıl, product type ve sales region dimension’ları kendi hiyerarşilerinin parçalarını oluştururlar.

Hiyerarşiler iki ya da daha fazla ilişkili dimension’dan meydana gelen yapılardır. Üst seviyede bulunan bir dimenison, bir sonraki seviyeye ait bir daha daha fazla dimension’ı içerir.

Örneğin; Yıl dimension’ı çeyrek, çeyrek dimension’ı ay dimension’ını içerir. Product Type dimension’ı alt ürün gruplarını, alt ürün grupları da ürünleri içerir.

Hiyerarşiler kullanıcıların data mart içinde yer alan measure’lar içinde hareket ederek eldeki veriyi farklı açılardan görmelerini sağlar. Örnek vermek gerekirse, bir kullanıcı “İstanbul Serisi” ürün ailesinin alt ürün türlerine bakabilir. Sonrasında Karadeniz bölgesi için satış detaylarını inceleyebilir. Sonrasında bu satışların sadece 2007 yılının ilk çeyreğine ait olanlarını görüntüleyebilir. Sonuçta tüm bu verilerin toplamına yani toplam satış tutarına göz atabilir. Kullanıcı verinin içinde hareket ederek karar vermek için gerekli bilgilere kolayca ulaşabilir.

Start şemasında, hiyerarşilerle ilgili bilgiler, dimension tablolarında tutulur. Her dimension tablosunun primary key alanı, hiyerarşinin en alt noktasını oluşturur. Bu nedenle fact tablosu, içerdiği foreign keylerin bu alanları göstereceği şekilde güncellenmelidir. Bu, fact tablosu, hiyerarşinin en alt seviyesinin kombinasyonu için bir kayıt içerecektir.

Hiyerarşilerin en alt seviyelerinin dışındaki katmanlar data mart’ta saklanmaz, bunun yerine çalışma zamanında saklanan verilere dayanan hesaplamalarla elde edilirler. Örneğin bir kullanıcı Karadeniz bölgesi için toplam satış bilgisini talep ederse, bu veri, Karadeniz bölgesindeki tüm alt bölgelere ait satışlar toplanarak elde edilir.

Bir sonraki bölümde SnowFlake şemasını ele alıyor olacağız.

Etiketler: veri madenciligi, is zekasi hakkinda hersey, star schema, fact table, dimension table, attribute, hiyerarsi, dimension

Data Mart
Önceki bölümde bahsettiğim gibi işletmenin OLTP sistemlerini İş Zekası platformuna veri kaynağı olarak tanımlamamız durumunda ciddi sorunlarla karşılaşabiliriz. Bu sorunların önüne geçebilmek için OLTP sisteminde yer alan verileri OLTP sistemi dışında, ayrı bir alana aktarırız ve yapacağımız hesaplamalara kaynak olarak bu veri kaynağını kullanırız. Bu ayrı alana Data Mart adını veriyoruz.

Data Mart’ların Özellikleri
Data Mart’lar İş Zekası çözümüne kaynak olarak tasarlandıkları için, işleri işletmenin günlük işlemlerini yürütmek olan OLTP sistemlerden farklı bir yapıya sahiptirler. Normalizasyon kurallarına bağlı olarak tasarlanmalarına karşın, data mart’lar hızlı erişime göre optimize edilmişlerdir. Data Mart bir ilişkisel beritabanı olmakla birlikte, daha az join gerektirecek şekilde tasarlanırlar. Data Mart’larda hız kazanmak amacıyla denormalize (tekrarlayan) veri kabul edilebilir.

Bir Data Mart tasarımı yaparken, normalizasyon kuralları “fact”ler etrafında kümelenen farklı bir yapı ile değiştirilirler. Yeni tasarım yapısı “stars” ve “snowflakes” olarak adlandırılırlar. Bu iki kavramı bu ve sonraki bölümlerde inceliyor olacağız.

Gerçek Zamanlı Olmayan Veri
OLTP sistemler business transactionlara dair verileri bu transactionlar gerçekleştiği anda kaydeder. Data Mart’lar ise belirli aralıklarla güncellenirler. Veri OLTP sistemlerden belirli aralıklarla Data Mart’a aktarılır. Bu işleme “data load” olarak adlandırılır.

Data Mart’lar OLTP sistemlerden tamamen ayrı oldukları için, İş Zekası uygulamalarının Data Mart’lara erişimleri, OLTP sistemler üzerinde herhangi bir yük oluşturmaz. Bu durumun tek istisnası, data load işlemidir. Data Load sırasında OLTP sistemler kopyalanacak verilerin hazırlanması için ciddi yük altına girebilirler. Burada avantajımız, data load işleminin scheduled olarak off-peak zamanlarda çalıştırılabilecek bir işlem olmasıdır.

Önceki bölümlerde değindiğimiz gibi, data mart’ta bulunan veriler gerçek zamanlı değildir. Çoğu durumda işlem gerçekleşmesi ile gerçekleşen işleme dair verilerin data mart’a aktarılması arasında zaman olur. Eğer data load işlemi her ay, ay sonu işlemlerinden sonra gerçekleşecek şekilde schedule edilirse, data mart 1 aylık gecikmeye sahip olacaktır. Data load gecelik olarak çalışırsa, data mart 1 günlük gecikmeye sahip olacaktır.

İş Zekası gereksinimlerinin tam ve doğru olarak karşılanabilmesi için kabul edilebilir ve uygulanabilir gecikme doğru olarak belirlenmeli ve altyapı bu gecikme süresine göre tasarlanmalıdır. Data mart tarafından sunulacak veriler, sağlıklı karar verme sürecini destekleyecek yeterlilikte olmalıdır. Bununla birlikte data load işlemi, OLTP sistemin üzerinde gereksiz bir yük oluşturacak sıklıkta olmamalıdır.

Konsolidasyon ve Cleansing
Farklı OLTP sistemlerden gelen veriler tek bir data mart içinde birleştirilebilirler. Bu bazı complex hesaplamaları yapmamızı sağlar. Ancak daha önce bahsettiğim gibi bu gereksinimin önünde bazı engeller vardır. Birden çok OLTP sistem, veriyi saklamak için farklı formatlar kullanıyor olabilir. Aynı türden veri için tutarsız veri türleri ile karşılaşabiliriz. Aynı entity için eşleşmeyen identifier alanlar söz konusu olabilir ve farklı zamansal periyod ve tarih formatları kullanılıyor olabilir. Tüm bu farklılıklar, farklı sistemlerde yer alan verilerin birleştirilmesini zorlaştıracaktır.

Bu tür sorunlar veriler data mart’ta saklanmadan önce çözümlenmelidir. Bunun için cleansing adını verdiğimiz işlemi gerçekleştiririz.

Data Cleansing verileri data mart ortamında sorunsuz bir şekilde kullanabileceğimiz hale getirir. Tutarsız veri türlerini tek bir türe dönüştürür. Eşleşmeyen identifier alanları standart bir yapıya çevirir. Yapacağımız hesaplamalar için uygun olmayan verileri düzenler veya siler.

Data cleansing genelde daha büyük bir işlemin bir parçası olarak gerçekleştirilir. Bu büyük işlem verileri OLTP sistemden alır ve data mart’a aktarır. Bu nedenle bu sürecin tümüne verilen isim “extract, transform and load” kelimelerinin kısaltması olan ETL’dir. ETL süreci verileri OLTP sistemden alır, gerekli cleansing işlemlerini gerçekleştirir ve veriyi data mart’a aktarır.

Bir Data Martın Yapısı
İş zekası için kullandığımız veriyi 4 ana başlık altında inceleyebiliriz: measure, dimension, attribute ve hierarchy. Bu 4 veri türü bize bir data mart’ın yapısını tanımlamada yardımcı olur. Şimdi sırayla bu veri türlerini inceleyelim.

Measure
Measure olarak adlandırdığımız yapı İş Zekası başlığı altında yapacağımız her işin temelidir. Measure’lar olmadan iş zekası olamaz tespiti hiç de yanlış olmaz. Makalenin ilk bölümlerinde değindiğim gibi measure’lar, sağlıklı karar verme sürecinin en temel parçalarıdır.

Bir measure, işletmenin performansının ölçümünde kullanılmak üzere hesaplanan belirli bir konunun toplam değeridir. Measure, aynı zamanda fact olarak da adlandırılır. Measure bilgilerini içeren tablolara fact table ismi verilse de, fact table’lar fact’lerden daha fazlasını barındırırlar.

Dimension
Toplam satış miktarı karar verme sürecinde kullanılabilecek bir measure’dır. Ancak karar vericiler şirketin o güne kadar yaptığı toplam satışı görmek istemezler. Çünkü tüm satış personelinin, tüm ürünlerde, şirket kurulduğu günden o güne kadar yaptıkları toplam satış, tek bir rakamsal değer olarak çok anlamlı değildir. Bunun yerine karar vericiler bu değeri daha ufak parçalar halinde görmek isterler. Dimension’lar bu bölümlendirmede kullanılırlar.

Dimension’lar belirli bir measure ile ilgili kategorizasyon yapmamızı sağlar. Örnek vermek gerekirse toplam satış tutarını tek bir bilgi olarak kabul edelim. Geometride bir noktanın boyutu yoktur.

Bir kategorizasyon yaparak (ya da dimension) bu tek bir noktayı temsil eden veriyi bölümlendirebiliriz. Örneğimize eldeki satış verilerini yıllık kategorilendirmeye tabi tutalım.

Artık elimizde yıl isimli dimension’da her bir yıl için bir nokta içeren bir çizgi mevcut. Geometride çizgi tek boyutlu bir nesnedir. Bu nedenle elimizdeki measure’a bir dimension ekledik ve 2002, 2003, 2004, 2005, 2006, 2007 değerlerinin her biri Yıl isimli dimension’ın üyeleri (member) oldu.

Bu noktada toplam satış bilgisinin ürün bazında kırılımını elde edebiliriz.

Toplam satışa ait measure’lar artık bir kare içinde hizalanmış durumdadır. Kare iki boyutlu bir nesne olduğu için oluşturduğumuz measure’a bir dimension daha ekledik. Ürün isimli bu dimension’ın “Ankara Serisi”, “İstanbul Serisi”, “İstanbul 2010 Kültür Başkenti” ve “Diyarbakır Serisi” isimli üyeleri vardır.

Şimdi toplam satış verisini bir defa daha, bölge bilgisiyle bölümlendirelim. Toplam satış measure’ı artık üç boyutlu bir nesne olan küp halini alacaktır. Görebileceğiniz üzere eklediğimiz her yeni kriter, elimizdeki measure’ın dimensionality oranını arttırmaktadır, bu nedenle ismi dimension’dır.

Elimizdeki Measure’ı ek dimensionlar oluşturarak daha detaylı kırılımlar elde edebiliriz. Örneğin pazarlama kampanyası ve müşteri yaş grubu dimensionlarını ekleyerek önce 4 sonrasında ise 5 boyutlu bir nesne elde edebiliriz. Bu durumda nesnemiz bir grafikle görüntülemek için oldukça karmaşık bir hal alır. Bu 4 ve daha çok boyutlu nesneleri küp olarak tanımlarız. İlerleyen bölümlerde küpleri ilgili son derece detaylı olarak ele alıyor olacağız.

Bir sonraki bölümde start schema yapısını ele alıyor olacağız.

Etiketler: veri madenciligi, is zekasi hakkinda hersey, data mart, star schema, snowflake schema, fact table, konsolidasyon ve cleansing, measure, dimension

Önceki bölümlerde İş Zekası ile ilgili pek çok temel konuyu, örneklerle ele aldık ve iş zekasının karar verme sürecindeki önemini vurguladık. Bununla birlikte İş Zekasının işletmedeki pek çok farklı seviye için önemini ve kullanım alanlarını açıkladık. Son olaraksa örnek işletmemiz olan “TinyToys Ltd” firmasını yakından tanıdık.

Sıradaki adımımız, “TinyToys Ltd” firmasının ihtiyaç duyduğu iş zekası çözümünü geliştirirken kullanacağımız örnek veritabanı yapılarını oluşturmak olacak. Bazı durumlarda İş Zekası için kaynak durumunda olan veriler doğrudan bazı veritabanı veya dosyalardan temin edilebilir durumda olurken, bazı durumlarda ise bu verilerin İş Zekası amacıyla kullanılabilir hale getirilmesi için gereken ön işlemleri yapabileceğimiz ayrı bir alana taşınması gerekir. Bu ayrı alana İş Zekası terminolojisinde “data mart” adı verilmektedir.

Kaynağın Aranması
İş Zekasının işletmelerin sağlıklı karar verebilmesi açısından önemini gördük. Bu bizi şu soruya yönlendiriyor: “İş Zekası’nın kaynağı nedir?”.  İş Zekası çözümlerinde kaynak olarak kullanılan bilgi işletmenin zaten günlük işleyişiyle ortaya çıkarttığı transactional verilerdir.

Transactional Veri
Pek çok işletme gerçekleştirdiği işlemlerin takibini yapmaktadır. Alınan siparişler, üretilen ürünler, verilen servisler, müşterilerden alınan ödemeler ve tedarikçilere yapılan ödemeler gibi. Tüm bu işlemlere genel olarak “Business Transaction” ismini veriyoruz. Bu işlemler sonucunda oluşan verileri ise “transactional data” olarak adlandırıyoruz.

Bir işletmenin sağlıklı yürüyebilmesi için gerçekleşen “Business Transaction”ların takip edilmesi, ürün ve servisler için ödemelerin alınması, alınan ürün ve hizmetler için ise ödemelerin yapılması, sipariş ve servis taleplerinin karşılanması gerekmektedir. İşletmeler genellikle nelerin yapıldığı ve nelerin yapılması gerektiği ile ilgili kayıt tutmak zorundadırlar. Bu bilgilerin bilgisayar tarafından yönetilmesi ve bilgisayarda saklanması durumunu “Online Transaction Processing” ya da kısaca “OLTP” olarak adlandırıyoruz.

OLTP sisteminde saklanan verilerin toplamı, işletmenin geçmişini oluşturmaktadır. OLTP sistemleri, önceki bölümlerde değindiğim ölçütleri hesaplamak için gerekli ham verileri içermektedir. Bu nedenle İş Zekası çözümümüzü geliştirebilmek için bu verilere gereksinim duyarız.

Transactional Verilerin İş Zekası Çözümünde Kullanımının Zorlukları
OLTP sistemleri ölçütleri hesaplamak ve İş Zekası çözümümüzü geliştirebilmemiz için gereksinim duyduğumuz ham verileri barındırır demiştik. Ancak bu verilere erişimde bazı sıkıntılarla karşılaşabiliriz. Bu problemleri kısaca özetleyelim:

Tasarım Kısıtları: İyi tasarlanmış OLTP sistemleri transactionların sağlıklı bir şekilde işlenmesi ve saklanmasını sağlamak için optimize edilmiştir. Bu verilerin normalizasyon kuralları doğrultusunda daha ufak parçalara bölünmesi anlamına gelir. Bu OLTP sistemlerin çok sayıda transaction’ı eşzamanlı olarak yürütebilmesini sağlar. Bu tür verilerin saklanması için en sağlıklı platform ilişkisel veritabanı yönetim sistemleridir.

Diğer yandan İş Zekası için kullanacağımız ölçütler bir transaction’a ait olayları yansıtmak için değil, bir grup transaction’ın istenen zaman dilimi içindeki net sonucunu yansıtmak için tasarlanmıştır. İş zekası ölçütleri çoğunlukla yüzlerce, binlerce hatta milyonlarca ayrı transaction’ın hesaplanması ile elde edilirler. Bu sonuçları hesaplayabilmesi için sistemin bir grup farklı optimizasyondan geçirilmesi gerekecektir.

OLTP sistemler, tasarım amaçları ve yöntemlerinden dolayı bu tarz hesaplamalar konusunda çok başarılı değillerdir. Bu, zaten OLTP sistemlerin geliştirilme amacının dışındadır. Bu hesaplamaların sağlıklı çalışması için farklı bir veri saklama optimizasyonu ile çalışmamız gerekir.

Günlük İşlemler: OLTP sistemler işletmemizin günlük işlerini destekler. Çoğu durumda işletmenin reaksiyon hızı bu sistemlerin performansı ile orantılıdır.  Eğer sipariş sistemi veya müşteri yönetim sistemi cevap vermez hale gelirse, işletmemizin işleri ciddi oranda aksayabilir. OLTP sistemler üzerinde az önce bahsettiğim hesaplamaları yapmak, bu sistemlerin işlem gücünü ve kaynaklarını ciddi oranda kullanacak ve hesaplamanın tamamlanması oldukça uzun zaman alacaktır. Hesaplama sırasında pek çok kaydın bloke olması da güçlü bir ihtimaldir ki bu, bu kayıtlara dayanan günlük işlemlerin o kayıtlardaki lock kalkana kadar durması anlamına gelecektir. Sanırım bu hesaplamaların OLTP sistemler üzerinde yapılmasının sakıncalarını saymaya devam etmeme gerek yoktur. Sadece bir rapor oluşturmak için muhasebe sisteminin durduğunu ya da e-ticaret platformunuzun cevap veremez hale geldiğini düşünün.

Arşivleme: OLTP sistemler günlük işlemlere odaklanmış olduğundan, uzak geçmişe yönelik verilerle ilgilenmez.Bu sistemler kısa bir döneme ait veriyi kaydeder ve/veya veri sadece o anki durumu gösterir. Bir ürünün o anki stok durumu gibi. Veriler bir yıl için kaydedilip sonrasında bir yıllık işlem tarafından silinebilir. Farklı bir formatta arşivlenebilir veya basitçe, silinebilir. Hangi durum olursa olsun, arşivlenen bu verilere erişim kolay olmayacaktır.

OLTP sistemler bu tarz arşivleme yöntemlerini sistemin sağlıklı çalışmasını garanti etmek için desteklerler. Bir transaction tablosu çok fazla kayıt içerirse, OLTP sistemi yavaş çalışmaya başlayabilir. Arşivleme, bu sistemlerin sağlıklı ve beklenen performansla çalışmasını sağlamak amacıyla da kullanılabilir. Ancak arşivleme İş Zekası açısından ciddi bir problem olabilir. Ölçütlerimizdeki trendlere bakarken geçen yılın değerlerini bu yıl ile hatta pek çok yılı birbiri ile kıyaslamak isteriz. Geçmiş yıllara ait veriler arşivlendiğinde ya da silindiğinde bu işlemin yapılması oldukça zorlaşacaktır.

Farklı Noktalardaki Veriler: İşletmelerin operasyonlarını yürüttüğü pek çok farklı OLTP sistemi olabilir. Örnek firmamızda olduğu gibi veriler farklı iş operasyonlar için farklı sistemlerde, farklı formatlarda saklanabilir. Hatta işletmenin tüm verilerinin tek bir sistemde saklandığı bir yapıyla büyük ihtimalle hiç bir zaman karşılaşamayacaksınız diyebilirim.

Diğer yandan İş Zekası çözümümüzde yer alacak ölçütler bu tür bir ayrımı desteklememektedir. Bunun yerine tüm işletmeyi bir bütün olarak görürler. Örneğin sıklıkla ihtiyaç duyulan ölçütlerden biri belirli bir ürüne dair kar payıdır. Bu ölçütü hesaplayabilmek için üretim sisteminden bu ürünün üretiminde kullanılan hammaddelerle ilgili bilgilere, muhasebe sisteminden bu hammaddelerin maliyetlerine, puantaj sisteminden bu ürünün üretimi için harcanan işgücü bilgisine, sipariş sisteminden ürün için ödenen rakama ihtiyaç duyarız. Bu, bu tür bir ölçütün hesaplanabilmesi için tüm bu farklı sistemlere ait verilerin bir araya getirilmesi gerektiği anlamına geliyor.

Sistemler arasındaki iletişime gelmeden önce, önümüzde farklı bir sorun var. Tüm bu sistemler, büyük ihtimalle farklı ürün tanımlama şemaları, kodlar ve takvimler kullanmaktadır. Aynı ürün üretim sisteminde “17187” ürün kodu ile tanımlıyken, e-ticaret sisteminde “EB-17RXQ” kodu ile tanımlı olabilir. Bordro programı 2 haftalık ödeme sistemi ile çalışırken, muhasebe sistemi mali aylarla çalışabilir. Farklı sistemlerdeki veriler bir araya getirildiğinde yapmamız gereken ilk iş, verilerin eşleştirilmesi olacaktır ki inanın bu çoğu durumda bir kaç sunucunun birbirleri ile iletişimini sağlamaktan çok daha basit bir işlemdir.

Yazı dizimizin bir sonraki bölümünde “Data Mart” konusunu ele alıyor olacağız.

Etiketler: veri madenciligi, is zekasi hakkinda hersey, data mart, business transaction, online transaction processing, oltp, tasarim kisitlari, arsivleme, farkli noktalardaki veriler

Önceki bölümlerde İş Zekası kavramını, işletmeler açısından önemini ve uygulama alanlarını detaylıca ele aldık. İş Zekası konusunda teknik konulara geçmeden önce sizleri örneklerimizde rol alacak aktörle tanıştırmak istiyorum: “TinyToys Ltd”.

“TinyToys Ltd” dekoratif biblolar ve cam ürünleri üreten ve satan bir firmadır. “TinyToys Ltd” pek çok farklı ürün serisine sahiptir. Örneğin 2010 yılına özel “İstanbul, 2010 Kültür Başkenti” serisi, bunun dışında Türkiye’nin farklı illerinin kültürek simgelerini konu alan seriler mevcuttur. Bu ürünlerin üretiminde cam, kil, kalay ve alüminyum kullanılmaktadır.

“TinyToys Ltd” ürünlerini üç farklı kanal aracılığıyla pazarlamaktadır. Bunlar;

• Kendisine ait olan ve sadece kendi ürünlerinin satıldığı 5 adet “TinyToys Ltd” mağazası.
• Kendisine ait olan ve ürünlerinin internet üzerinden satışının yapıldığı “TinyToys Ltd” web sitesi.
• Diğer perakendecilere yapılan toplu satışlar

“TinyToys Ltd” Firmasının Gereksinimleri
“TinyToys Ltd” son üç yılda oldukça ciddi büyüme kaydetmiş, sipariş miktarında %300 oranında bir artış gerçekleşmiştir. Bu büyüme “TinyToys Ltd” firmasının mevcut iş zekası çözümü olan “statik rapor”ların önünde ciddi engeller olduğunu farketmesini sağladı. Bir kaç yıl öncesine kadar statik raporlar karar destek sürecini başarıyla destekliyordu ancak artık bu yöntem, raporların oluşması ve anlaşılması için bir saatten fazla zaman gerekmesi nedeniyle ihtiyaca cevap vermemeye başlamıştır. Bu raporlar çok kısmi bir özetleme ile çalışmaktadır.

“TinyToys Ltd” firması pek çok farklı ürün ailesine sahiptir ve bu alanlardaki rekabette başarılı olabilmek için sağlıklı bir karar verme mekanizmasına ihtiyaç duyulmaktadır. “TinyToys Ltd” firmasının mevcut iş zekası altyapısı malesef bu konuda gereksinim duyulan desteği sağlamamaktadır.

Bu nedenlerden dolayı, “TinyToys Ltd” firması karar verme sürecine daha sağlıklı destek verecek bir "İş Zekası” platformu oluşturulması için yeni bir proje başlattı. Bu proje datawarehouse tasarımını, datawarehouse’ın mevcut sistemlerdeki verilerle oluşturulması ve işletmenin tüm kademelerindeki karar vericilere yönelik analiz uygulamalarının geliştirilmesini kapsamaktadır. Yeni iş zekası platformu SQL Server 2008 platformu üzerinde kurgulanmaktadır.

Makale dizisinin bundan sonraki bölümlerinde “TinyToys Ltd” firmasının yeni iş zekası projesinin tüm aşamalarına tanık olacağız. Ancak başlamadan önce “TinyToys Ltd” firmasının mevcut sistemini inceleyelim.

Mevcut Sistem
Geliştirilecek olan İş Zekası platformunda veri kaynağı olarak rol alacak 5 farklı sistem mevcuttur. Bu sistemlerin genel görünümü için aşağıdaki grafiği inceleyebilirsiniz.

Üretim Otomasyonu
Üretim otomasyon sistemi bir ürünün üretilmesi için kullanılan tüm materyallerin takibini yapar. Bu sistem aynı zamanda hangi üretim hattında hangi ürünlerin üretildiğini takip eder. Son olarak bu sistem her mesai döneminde kaç ürün üretildiğini takip eder.

Bu sistem özel bir veri saklama formatı kullanır. Veriler bu sistemden comma-delimited metin dosyaları halinde export edilebilir. Bu dosya üretim sisteminin verilerinin İş Zekası sistemine aktarımında kullanılacaktır.

Sipariş Sistemi
Sipariş sistemi tüm ürünler için stok bilgisini barındırır. Bununla birlikte “TinyToys Ltd” firmasının tedarikçilerinin verdiği toplu sipariş bilgisini içerir. Sipariş Sistemi bu bilgilerle birlikte “TinyToys Ltd” mağazaları ve “xyz.com” web sitesinden gelen sipariş verilerini de içerir.

Sipariş sistemi, teslimat dahil olmak üzere sipariş durum bilgisini yönetir, faturaları oluşturur ve ödemelerini yönetir. Ek olarak bayilerden geri gönderilen ürünlerle ilgili kayıtları tutar.

Bu sistem verileri Microsoft SQL Server veritabanında barındırmaktadır.

POS Sistemi
POS sistemi firmaya ait 5 mağazada yapılan ödemeleri yönetir. Bu sistem aynı zamanda bu mağazalardaki stok yönetimini UPC (Universal Product Code) sistemini kullanarark gerçekleştirir. Bu sistem hem nakit hem kredi kartı ile yapılan ödemeleri yönetir. Aynı zamanda müşteriden geri dönen ürünlerle ilgili takip yine bu sistem üzerinden yapılmaktadır.

Tüm POS sistemlerinde oluşan veriler bir XML dosyasına aktarılarak gecelik olarak ftp ile merkezi bir alana aktarılmaktadır. Bu xml dosyaları POS verilerinin İş Zekası platformuna aktarımında kullanılmaktadır.

xyz.com Web Sitesi
xyz.com online mağazası ASP.NET ile geliştirilmiş ve veritabanı olarak SQL Server kullanmaktadır. Tüm satışlar kredi kartı ile gerçekleştirilmektedir. Müşterilerin her satın alma için ad, adres, telefon numarası ve email bilgilerini vermeleri gerekmektedir.

Online mağaza tüm siparişlerin, müşterilerden geri dönen ürünlerin ve promosyon ve indirimlerin kaydını tutmaktadır.

Muhasebe Sistemi
Muhasebe sistemi “TinyToys Ltd” firmasının tüm finansal işlemlerinin kaydını tutmaktadır. Bu kayıtlaraa hammadde alımı da dahildir. Muhasebe sistemi SQL Server veritabanı kullanmaktadır.

İş Zekası Sisteminin Geliştirilmesi
Yazı dizisinin sonraki bölümlerinde mevcut sistem ve gereksinimleri dikkate alarak ihtiyaç duyulan İş Zekası platformunu geliştirmek için ilk adımları atıyor olacağız.

Etiketler: veri madenciligi, is zekasi hakkinda hersey

Farklı Seviyelerde “İş Zekası”
Önceki bölümlerde İş Zekası’na işletmelerin her seviyesinde gereksinim duyulduğuna değinmiştim. Gerçekten İş Zekası ile işletmenin tüm seviyelerine yönelik “cevap”lar oluşturulabilir. Ancak İş Zekası ile oluşturulan her “cevap”, işletmenin tüm seviyelerinde gereklidir sonucuna varmak hata olacaktır. İşletmelerde yer alan farklı seviyeler, farklı türde bilgilere gereksinim duyarlar. Bu bölümde işletmelerde hangi seviyede ne tür bilgilere gereksinim duyulduğunu, bir piramit üzerinden anlatıyor olacağım.

Piramidin Zirvesi
İşletmelerin üst düzey karar vericileri büyük fotoğrafa bakmak zorundadırlar. İşletme için uzun vadeli hedefler belirlemekle sorumludurlar ve ufak detaylara takılıp zaman kaybetmemek için sorumluluk alanları ile ilgili çok detaylı bilgi yerine bu bilginin doğru şekilde özetlenmiş ve biçimlendirilmiş haline sahip olmalıdırlar.

                                                        Şekil 1.1: İşletmenin Farklı seviyelerindeki hedefler

Özetlenmiş Ölçütler
İş Zekası bu seviyelerin gereksinimlerini karşılayacak şekilde tasarlanmıştır. Ölçütler karar vericilere özetlenmiş olarak iletilmelidir. Çoğu durumda ölçütler sayılarla değil, çeşitli grafiksel öğelerle ifade edilirler. Bu grafiksel öğeler ölçütün kabul edilebilir değerler içinde olup olmadığını, gecikmeyi veya kabul edilmesi mümkün olmayan değerleri ifade eder. Bu grafiksel öğelere İş Zekası konusunda “Key Performance Indicator” kısaca KPI adı verilir.

                                                                               Şekil 1.2: Somut Ölçütler

KPI’lar üst düzey karar vericilere işletmenin belirli bir alandaki anlık durumu ile ilgili görsel, kolay algılanabilen ve kolay yorumlanabilen bilgi sağlar. KPI’lar sıklıkla trafik lamlabaları veya gauge grafikleri gibi anlık durumu ifade eden grafiksel öğeler olarak sunulur. KPI’ları ilerleyen bölümlerde detaylıca ele alıyor olacağız.

Yüksek Gecikme
Üst düzey karar vericiler genellikle uzun vadeli hedefler üzerinde çalıştığından, anlık verilere gereksinim duymazlar. Bu, bu seviyedeki iş zekası uygulamalarının dayandığı verilerin, çoğunlukla anlık güncelleniyor olması zorunluluğunun olmadığı anlamına gelir. Bu seviyedeki karar vericilerin belirli bir konuya dair belirli bir dönemdeki trendi görmeleri gerekir.

 
                     Şekil 1.3: Karar verici seviyelerine göre gereksinim duyulan veri güncelleme sıklığı

Orta Seviye
Orta düzey karar vericiler departman ve diğer birimlerin yönetimini gerçekleştirirler. Kısa vadeli hedefler belirlerler ve sorumlulukları kapsamındaki birimler için planlama yaparlar. Orta düzey karar vericiler günlük süreçlere dair detaylı verilere gereksinim duymazlar.

Özetlenmiş Ölçütler ve Drilldown
Bu seviyedeki karar vericilerde özetlenmiş verilere gereksinim duyarlar ancak sıklıkla belirli bilgilerin detayını görmek isterler (drilldown). Bu nedenle bu seviyedeki karar vericiler raporları, veri odaklı analize izin veren interaktif sistemlerle birlikte kullanırlar. Bu tür karar vericiler veri madenciliği teknikleri ile oluşturulmuş verileri de kullanabilirler.

Kabul Edilebilir Gecikme
Bu karar vericiler işletmenin günlük işlevlerine daha yakın olduklarından, bazı durumlarda daha düşük gecikmeye gereksinim duyarlar. Ölçütlerin günlük olarak güncellenmesine gereksinim duyma olasılıkları olmakla birlikte, genellikle haftalık ya da aylık periyodlara ilişkin verilere gereksinim duyarlar.

Piramidin Temeli
Piramidin temelini oluşturan insanlar, yani çalışanlarımız, yöneticilerimiz ve grup liderlerimiz günlük işlemleri gerçekleştirir. Bu insanlar günlük operasyonel hedefleri belriler ve bir sonraki haftaya, güne veya mesai dönemine ilişkin kaynak planlamasıyla ilgili kararları alırlar. Bir sonraki satış kampanyasını ya da satış aramasını planlarlar. Bu karar vericiler genellikle yüksek erişilebilirliğe ve yüksek tepki süresine sahip İş Zekası sistemlerine gereksinim duyarlar.

Detay Seviyesinde Ölçütler
Bu karar vericiler işletmenin tüm operasyonlarıyla ilgili detaylarla ilgilenirler ve detaylı veriye gereksinim duyarlar. Bu karar vericiler bazı durumlarda ölçütlerin özetlenmesi ancak drilldown ile detaylara inilebilmesine gereksinim duyarlar. Bununla birlikte veri madenciliğinden faydalanarak belirli trend ve korelasyonları günlük bazda izleme gereksinimi duyabilirler.

Düşük Gecikme
Bu seviyedeki karar vericiler günlük operasyonlarla ilgilendiğinden, bilgideki değişikliklerden en hızlı şekilde haberdar olmalıdırlar. Bu nedenle bu seviyede çok düşük bir gecikmeye tolerans gösterilebilir. Bazı kritik durumlarda günlük, saatlik hatta daha küçük bir periyodu içeren verilere gereksinim duyarlar.

Etiketler: veri madenciligi, is zekasi hakkinda hersey, kpi, key performance indicator, drilldown

Önceki bölümlerde efektif karar verme sürecinin bir işletmenin başarısına olan etkisini ele aldık. Bununla birlikte karar verme sürecinin spesifik hedeflere, hedefe olan uzaklığımızı görebilmek için ölçülebilir bazı kriterlere ve bu kriterlerle ilgili geri beslemeye ihtiyaç duyduğumuzu öğrendik. Ve son olarak, son iki maddeyi iş zekasının tanımında kullandık.

Bu ve sonraki bir kaç bölümde ise iş zekasının cevaplayabileceği soruları incelemeye ağyırıyor olacağım. Bununla birlikte işletmelerin farklı seviyelerinde ihtiyaç duyulan farklı iş zekası çözümlerine değineceğim. Son olarak sonraki tüm bölümlerde göstereceğim örneklerde kullanacağım örnek şirketimiz Hamza A.Ş. ile ilgili bilgiler veriyor olacağım.

İş Zekası Sizin İçin Ne Yapabilir?
İlk bölümlerde İş Zekası’nın daha sağlıklı bir karar verme süreci oluşturabilmemize yardımcı olduğunu belirtmiştim. İş Zekası, bir karar vermemiz için ihtiyaç duyduğumuz pek çok bilgi ve analizi bize sağlayabilir. Bununla birlikte verdiğimiz kararların değerlendirmesini yapabilmemizi sağlayacak geri beslemeleri de sunabilir. İş Zekası bu bilgi ve geri beslemeleri pek çok farklı şekilde sunabilir.

Ne Aradığımızı Ne Zaman Biliriz?
Bazı durumlarda ne tür bir bilgiye ihtiyaç duyduğumuzu biliriz. Cevap istediğimiz bir ya da birkaç soru vardır. Örneğin hangi birim kaç dolarlık satış gerçekleştirmiş? En çok satış gerçekleştiren personellerin listesi? Doğru bir İş Zekası tasarımı ile hangi sorulara cevap istediğimizi bilmekle birlikte bu soruların cevapları ile ilgili bilgiyi nerede bulabileceğimizi de bilebiliriz.

Tasarım Odaklı Analiz
Cevaplanmasını istediğimiz soruyu ve cevabın nerede bulunabileceğini bildiğimiz zaman, İş Zekası’nun sunduğu cevabı printed raporlarla sunabiliriz. İş Zekası’nın en sık uygulandığı yöntemde budur ve bu yöntem pek çok durum için gayet iyi çalışır.

Örneğin, hangi birimin, hangi iş alanında, kaç dolarlık satış yaptığını öğrenmek istiyorsak ve bu bilgiyi nerede bulabileceğimizi biliyorsak, bu bilgiyi sunacak bir rapor tasarlayabilir ve istenilen zamanda / zaman aralığında yayınlanmasını / dağıtılmasını sağlayabiliriz. Raporlama oldukça başarılı bir iş zekası aracıdır. Ancak diyelimki raporumuz belirli bir iş alanı için satış rakamlarının olması gerekenden daha düşük olduğunu görüyoruz. Eğer rapor tasarımcısı gerekli detay verileri rapora dahil etmemişse sorunun ne olduğunu belirleyebilmek için inceleyebileceğimiz hiç bir detay olmayacaktır. Belki başarılı bir satış personeli farklı bir iş ailesi ile ilgili çalışmaya başlamıştır, belki önemli bir müşterimizi kaybetmişizdir. Rapor bize bu bilgiyi sağlamayacaktır. Malesef iş bu noktada biter.

Veri Odaklı Analiz
Bazı durumlarda ise soruyu biliriz ancak cevap için nereye bakmamız gerektiğiniz bilmeyiz. Bir önceki örnekte olduğu gibi bir anormal durumda, verilere farklı açılardan daha detaylı olarak bakmak isteyebiliriz.

Bazı durumlarda bu detaylı verilerin tamamını incelemek çok mantıklı olmaz. Bunun yerine daha üst seviye bir değer bulup bunun detaylarını inceleriz. İlgimizi çeken ve bizi ihtiyaç duyduğumuz bilgiye doğru yönlendiren verileri takip ederiz.

Veri odaklı analizi “eldeki verinin bir sonraki adımda hangi verileri inceleyeceğimizi belirlemesi” durumu şeklinde tanımlayabiliriz. Bu tür bir çözümü geliştiren kişi, rapor tasarımcısının / kullanıcısının gitmek isteyeceği tüm yolları bilemez. Bunun yerine geliştirici, kullanıcının verilerin içinde dilediği şekilde hareket edebilmesini sağlayacak bir altyapı sunmalıdır.

Veri odaklı analiz çözümlerini geliştirebilmek için drilldown yapısına ihtiyaç duyarız. İlgimizi çeken bir veri gördüğümüzde, bu veriyi tıklayarak o veriyi oluşturan detay veriye ulaşabilmek isteriz. Elbette bu düz, statik bir raporlama yapısıyla sağlanamaz. Bunun için online bir yapıya gereksinim duyuyoruz.

Yeni Soruların ve Cevaplarının Bulunması
Bazı durumlarda eldeki veri sormayı hiç düşünmediğimiz bazı soruların cevaplarını içerir. Bu veri bir insanın tasarım odaklı ya da veri odaklı bir raporlama yapısıyla elde etmesi imkansız olan trendler, korelasyonlar ve bağımlılıklar gibi bilgileri içerebilir. Bu tür ilişkiler bilgisayarlar tarafından data mining “veri madenciliği” olarak adlandırılan tekniklerle geliştirilir.

Tasarım ve veri odaklı analiz yapıları genellikle özetlenmiş verilerle çalışırken, data mining verinin en detaylı haliyle çalışmaktadır. Data Mining yapısı eldeki veri içinde yer alan karakteristik ve olaylar arasındaki korelasyonları bulmak için son derece karmaşık matematiksel algoritmalar kullanır. Data Mining ile cevaplayabildiğimiz sorulara bir kaç örnek vermek gerekirse;

• Firmamızdan A ürününü almış olan Z müşterisinin hangi farklı ürünü/ürünleri almaya eğilimlidir?
• Firmamızdan S servisini alan X müşterisinin önümüzdeki üç ay boyunca ihtiyaç duyma ihtimali olan diğer servisler ve bu servislere ihtiyaç duyma olasılıkları nedir?

Bu tür bilgiler pazarlama kampanyalarının planlanmasında, çapraz satış planlarında, gelecekle ilgili kapasite planlamalarının yapılmasında ve buna benzer karar gereksinimlerinin duyulduğu pek çok senaryoda son derece faydalı olacaktır.

Etiketler: veri madenciligi, is zekasi hakkinda hersey, tasarim odakli analiz, veri odakli analiz