http://www.computerworld.com.tr/erkan-ogur-destekli-pardus-2011-yayinda-detay_5727-referer_bulten-uid_15517-bid_609.html

Doğru Strateji ve Yol Haritası Ne Olmalı?

Değerli Davetlimiz,

Bulut Bilişim’in hız ve maliyet konularında net olarak faydalar getirdiğini biliyoruz,

Peki aşağıdaki soruların yanıtlarını bildiğinize emin misiniz?

* Bulut Bilişim konusundaki umutlar, yanılgılar ve gerçekler nelerdir?
* Bulut Bilişim’e nasıl geçiş yapılmalıdır?
* Mevcut BT yatırımından nasıl faydalanılabilir?
* BT yönetim süreçleri Bulut Bilişim ile nasıl optimize edilebilir?
* BT departmanı, doğru strateji ve yol haritası ile kurum içi bulut bilişimin tasarlanması, hayata geçirilmesi ve yönetilmesi konusunda nasıl üstün bir servis sağlayıcıya dönüşebilir?

Şimdi kayıt olun!

9 Şubat 2011 
9:30 - 17:15

Ritz Carlton
Balo Salonu
Süzer Plaza, 
Askerocağı Cad. No: 15 
Elmadağ, 
Şişli - İstanbul

---

İster Bulut Bilişim kurumunuz için hala düşünce aşamasında olsun, ister kurumunuzda çoktan bir Bulut Bilişim modeli benimsenmiş olsun. Etkinliğimize katılarak kurumunuzun Bulut Bilişim modelinden nasıl tam anlamıyla fayda sağlayabileceği konusunda pratik yaklaşımlar görme fırsatı elde edeceksiniz.

Oracle ile sağlam ve güvenilir bir temel üzerine inşa edilecek Bulut Bilişim modelinin farkını, referans mimariler ve proje örnekleri ile ortaya koyacağımız etkinliğimize katılımınızdan onur duyacağız.

Saygılarımızla,
Oracle Türkiye

Oracle Data Integrator kurulduktan sonra master ve work repositoryleri oluşturulması hakkında makalemizi  paylaşıyor olacağım.Bu makaleyi link vermeden veya sitemizin ismi geçmeden paylaşabilirsiniz.Önemli olan bu yazıyı okurken bizim sizlere küçükte olsa bi katkı sağlayabilmemizdir.

Master Repository : Şirketin IT kaynaklarının yapısını , güvenlik bilgilerini , proje ve veri kaynaklarıyla ilgili bilgilerin tutulduğu repository’dir.Sadece bir tane master repository gereklidir.

Work Repository : Veri kaynakları , projeler ve kullanımlarıyla ilgili bilgilerin tutulduğu repository’dir.

Repository’leri yaratmak için adım adım şunlar yapılmalıdır :

Repository disk alanları yaratılır.

Master Repository yaratılır.

Master Repository’e bağlanılır.

Work Repository yaratılır.

Work Repository’e bağlanılır.

NOT : Repositoryler ANSI ISO 89 syntaxını destekleyen her hangi bir ilişkisel veri tabanında yaratılabilir.Her bir repository için 200 mblik yer gereklidir.

REPOSITORY  DİSK ALANI YARATMA

Oracle : Master repository’e karşılık snpm , Work repository’e karşılık snpw şemaları yaratılır.

SQL> create user identified by   default tablespace temporary tablespace   ;

SQL> grant connect, resource to ;

Örnek :

create user SNPM_MASTER_YUSUF identified by SNPM_MASTER_YUSUF default tablespace USERS temporary tablespace TEMP; 

grant connect, resource to SNPM_MASTER_YUSUF; 

create user SNPW_WORK_YUSUF identified by SNPW_WORK_YUSUF default tablespace USERS temporary tablespace TEMP; 

grant connect, resource to SNPW_WORK_YUSUF;

Microsof SQL Server : Master repository’e karşılık db_snpm , Work repository’e karşılık db_snpw veri tabanları yaratılır.Bu veritabanlarına yetkili snpm ve snpw kullanıcıları yaratılır.

CREATE LOGIN

WITH PASSWORD = '',

DEFAULT_DATABASE = ,

DEFAULT_LANGUAGE = us_english;

USE ;

MASTER REPOSITORY YARATMA

1-Start Menu, Programs > Oracle Data Integrator > Repository Management > Master Repository Creation seçilir.

 

2-Aşağıdaki sahalar doldurulur.

Driver : Repository’nin yaratılacağı veri tabanına erişmek için kullanılacak driverdır. 

URL : Veri tabanına erişmek için kullanılacak url’dir. 

User : “snpm” şemasına erişmek için yaratılan kullanıcı. 

Password : Kullanıcının şifresi. 

ID : 0’dan farklı spesifik bir id.Repositoryler arasındaki import – export işlemlerini etkiler. 

Technologies : Repository’nin bulunacağı teknoloji seçilir. 

Language : Master repository’nin dili seçilir. 

    3-  ‘OK’ butonuna basılıp , master repository yaratılır.

Şekil 1 : Master Repository Yaratma Ekranı

MASTER REPOSITORY’E BAĞLANMA

Master repository’e bağlanmak için :

1) Start Menu, Programs > Oracle Data Integrator > Topology Manager seçilir.

2) “New” butonuna basılır.(“Login Name”in yanındaki ilk buton.)

3) Aşağıdaki alanlar doldurulur.

Oracle Data Integrator Connection :

Login Name : Genel bir ad.(Örnek : Repository) 

User : SUPERVISOR (Büyük Harflerle) 

Password : SUNOPSIS (Büyük Harflerle) 

DBMS Connection (Master Repository) :

User : Master Repository’e erişmek için tanımladığınız kullanıcı. 

Password : Kullanıcının şifresi.

Driver’s List : Master Repository’e bağlanmak için gerekli olan driver seçilir. 

URL : Veri tabanına erişmek için kullanılacak url’dir. 

4)  “Test” butonuna basılarak , bağlantının çalışıp çalışmadığı kontrol edilir.

5)  “OK” butonuna basılır ve “Topology Manager” açılır.

 

WORK REPOSITORY YARATMA

1)  “Topology Manager” ile master repository’e bağlanılır.

2)   Açılan ekranda Topology -> Repositories -> Work repositories’e sağ tıklanır ve “Insert Work Repository” seçilir.Açılan ekranda “work repository”e bağlanabilmek için , bağlantı parametreleri girilir.

3)  Aşağıdaki alanlar doldurulur :

Name : Work Repository bağlantı adı girilir. 

Technology : Work Repository’nin bulunacağı teknoloji seçilir. 

User : Work Repository’e erişmek için tanımladığınız kullanıcı. 

Password : Kullanıcının şifresi. 

JDBC Tabında -> JDBC Driver : Work Repository’nin yaratılacağı veri tabanına erişmek için kullanılacak driverdır. 

JDBC Tabında -> JDBC URL : Work Repository’nin bulunacağı veri tabanına erişmek için kullanılacak url’dir. 

4)  “Test” butonuna basılarak , bağlantının doğru çalışıp çalışmadığı test edilir.

5 ) “OK” butonuna basılarak , Work Repository bağlantı bilgileri ekranı kapatılır.Açılan ekranda Repository için uniq isim ve id girilmesi istenir.

6)  “Work Repository” ekranında aşağıdaki parametreler girilir.

ID : Work Repository’e 1’den 998’e kadar uniq bir id verilir. 

Name : Work Repository’e uniq bir isim verilir.(Örnek : WORKREP1) 

Type : Listeden “development” seçilir.            

7) “Ok” butonuna basılır ve “Work Repository” yaratna işlemi başlatılır.

8) “Work Repository” yaratıldığı zaman “Work Repository” ekranı kapanır. “Work Repository”e , “Designer” ve “Operator” modullerinden ulaşılabilir.

WORK REPOSITORY’E BAĞLANMA

Workr repository’e bağlanmak için :

1) Start Menu, Programs > Oracle Data Integrator > Designer seçilir.

2) “New” butonuna basılır.(“Login Name”in yanındaki ilk buton.)

3) Aşağıdaki alanlar doldurulur.

Oracle Data Integrator Connection :

Login Name : Genel bir ad.(Örnek : Repository) 

User : SUPERVISOR (Büyük Harflerle) 

Password : SUNOPSIS (Büyük Harflerle) 

DBMS Connection (Master Repository) :

User : Master Repository’e erişmek için tanımladığınız kullanıcı. 

Password : Kullanıcının şifresi.

Driver’s List : Master Repository’e bağlanmak için gerekli olan driver seçilir. 

URL : Veri tabanına erişmek için kullanılacak url’dir. 

Work Repository :

Work Repository Name : Work Repository yaratırken verdiğiniz isim.(Örnek : WORKREP1) 

4)  “Test” butonuna basılarak , bağlantının çalışıp çalışmadığı kontrol edilir.

5)  “OK” butonuna basılır ve “Topology Manager” açılır.

DEMO PROJE

Start Menu > Programs > Oracle Data Integrator > Examples , Start Demo Environment seçilireke , demo için hazırlanmış olan , repositoryler başlatılır.

DESİGNER’I BAŞLATMA

1) Start Menu > Programs > Oracle Data Integrator > Designer

2) Login Name kısmından uygun olan kullanıcı adı seçilir.Demo için “Getting Started – ETL Project” seçilir ve şifre boş bırakılır.

3) “Ok” butonuna basılarak , repository’e bağlanılır.

4) “Designer” ekranı açılır.(Designer açılırken karşınıza çıkan ekrandan “Close” butonuna basıp , çıkınız.)

 

 

 

 

Datawarehouse sistemleriyle ilgili araştırmalarımda çok güzel bir yazıyla karşılaştım 

http://www.iszekasi.com/joomla155/index.php/tr/blog/23-oracledb/202-oracle-data-integrator.html sitesinde de göreceğiniz gibi ODI kullanımı ve çözümlerine yönelik dökümanı inceleyelim

İş Zekası projelerinin %60-%80 eforu verinin kaynak sistemlerden çıkarılması, gerekli çevrimlerin yapılması ve hedef sistemlere yüklenmesi (ETL) aşamalarında harcanmaktadır. Bu amaç için çok çeşitli ürünler aynı yöntemlerle veri çevrimlerini yapmakta ve veri akışını oluşturmakta. İşte bu ESKİ ihtiyaca YENİ bir yaklaşım getirmektedir Oracle Data Integrator (ODI) . Önceleri sadece veri ambarlarının oluşturulması için kullanılmakta olan bu tür ürünler artık bir kurumdaki tüm veri entegrasyon amaçları için  de kullanılıyor ve  veri entegrasyonu konusunda uzmanlaşmış olan veri ambarı uzmanları ise artık kurumların veri entegrasyon ortamlarının da oluşmasında önemli roller oynamakta. Oracle Data Integrator  heterojen ortamların batch, real time, event oriented, message oriented, service oriented veri entegrasyonu için tekleştirilmiş bir arayüz ile yeni bir yaklaşım getirmekte ve entegrasyon süreçlerinin geliştirilmesi için gereken eforu projenin %60-%80 lerinden %30-%40 larına düşürebilmektedir. ODI’ın öne çıkan özelliklerini aşağıdaki başlıklarda inceleyelim: -          ETL değil ELT -          Knowledge moduller (şablonları) -          Her aşamada veri çevrimi (kaynak, hedef ve veri işleme alanlarında) -          Changed Data Capture (Değişen verinin bulunması) -          Master Data Management -          Servis Odaklı Mimari (SOA ) -          Java mimarisi – Tüm platformlar için tek uygulama -          Erişebilirlik -          Öğrenme hızı ETL Değil ELT Bu tür ürünlerin tarihçesine baktığımızda 3 ana aşamayı görüyoruz. 1-      Veri taşınması ve çevrimi için kod üreten ürünler. Bunlar platformalara göre Cobol, C kodları üreten uygulamalardı. 2-      Kendi server’ında veri işlemeyi yapan ürünler. 3-      Veri tabanlarını kullanıp veri işleyen ürünler. ODI üçüncü nesil bir ürün, veri işleme işini bu konuda zaten büyük yatırımlar yapan veri tablarına bırakmakta ve kendisi veri tabanlarının en güçlü yanlarını kullanarak verinin çevrimini sağlamakta. Diğer birçok ürün piyasaya çıktığında veri tabanlarının SQL lerinde  CASE komutu yoktu, böyle düşününce veriyi işleyecek ayrı bir server fikri anlamlıydı. Oysa günümüzde veri tabanlarına baktığımızda (ör: Oracle 10g, Teradata, DB2, SQL Server 2005, Sybase IQ ) veri işleme anlamında çok güçlüler. Kurumlar veri tabanlarına ciddi bir yatırımı halihazırda yapmış bulunuyorlar. Bu gücü iş zekası ortamlarının oluşturulması için gereken veri işleme aşamasında neden kullanmasınlar? ODI kaynak sistemlerden veriyi toparlayıp tasarıma göre staging veya hedef veri kaynağında birleştirip konsolide ediyor ve gereken çevrimi veri tabanı içerisinde yapıp hedefe yüklüyor. Kaynak ve hedef veri kaynaklarının en güçlü yanlarını kullanarak çevrimi yapabiliyor. Yapılan çevrimlerin %90 ı SQL’ler ile yapılabiliyor. ELT kelimesinden de anlaşılacağı üzere önce veri kaynaktan çıkarılıyor (Extract) sonra hedef veya staginge yükleniyor (Load) ve çevrim yapılıyor (Transform). ELT yaklaşımında kaynak ile hedef arasında herhangi bir server olmadığından verinin network üzerinden yolculuğu da kısalmış oluyor. ETL ürünlerindeki gibi ayrı bir server’ın bakımı ve kurulumu gibi yüklerde ortadan kalkmış oluyor. Veri tabanları üzerinde çevrim yapmaktan bahsediyorsak bunun SQL’ler ile yapıldığını tahmin etmişsinizdir. Yeni bir scripting öğrenmenize gerek kalmadan tüm veri  çevrim işini SQL in gücünü kullanarak yapabiliyorsunuz. ELT yaklaşımında veri genel olarak bulk olarak işleniyor. Veri tabanlarının bu konuda yapmış oldukları performans yatırımlarını düşündüğünüzde performans arttırma konusunda da elimizdeki veri tabanımızın bize sunduğu fırsatları kullanıyor oluyoruz. Kısaca ODI ile veri tabanları üzerinde, ayrı bir scripting öğrenmeden, yüksek performans ile ve geliştirme süresini ciddi miktarda azaltarak veri entegrasyonu yapılabiliyor. Knowledge Modul’ler (Şablonlar) Lego parçacıkları gibi birçok veri işleme modülünüzün olduğunu düşünün, onlarca modül (sort, transform, join vs.) ve karşımızda bir veri entegrasyonu problemi var. Bu modulleri kullanarak bir süreç tasarlayacaksınız. Tasarladınız, ileriki aşamalarda optimizasyonunu yapacaksınız. Optimizasyonu yaptıktan sonra benzer durumdaki belkide yüzlerce akış için aynı işi tekrarlayacaksınız. ODI ın devrimsel farkı bu noktada ortaya çıkmakta, knowledge modul adı verdiğimiz şablonlarınız var ve yukarıda bahsedilen zorluklarla uğraşmanıza gerek kalmıyor. Verinin bir ortamdan başka bir ortama taşınması, değişik ortamlardaki verinin entegre edilmesi, değişen veri ile hedef sistemlerin beslenmesi vs. gibi aşamaların her birisi için çeşitli şablonlar bulunmakta. Knowledge Modul (KM) ler binlerce kişi tarafından test edilmiş, optimum çözümleri size sunmuş oluyor.  İş zekası projelerinde veri entegrasyonu için harcanan zamanın çoğu ETL için harcanıyor demiştik. ETL süreci içerisinde de en fazla efor ise karşımıza çıkan problemler için geliştirmek zorunda olduğumuz veri akışlarının tasarımı. ODI birçok değişik durum için bu tür problemlerin çözümünü de beraberinde sunmasıyla hayatımızı kolaylaştırmaktadır. Her Aşamada Veri Çevrimi Verinin çevrimi çoğunlukla SQL’ler ile yapılıyor demiştik; kaynak, hedef ve staging veri kaynaklarımızın olduğunu düşünürsek çevrimin nerede yapılacağı ihtiyacımıza ve zorunluluklarımıza göre ODI içerisinde tasarlanabiliyor. Basit bir örnekle verecek olursak: kaynak sistemde text bir bilgi var ve uzunluğu 100 karakter, hedef ise 80 karakter, uzunluğu 100 den 80’e indirirken SUBSTR komutunu 2 nokta çalıştırabiliriz. -          Kaynaktan veriyi çekerken -          Kaynak sistemdiki bilgiyi staging’e aynı uzunlukla taşıyıp konsolide ederken -          Hedef veri kaynağına yüklerken çalıştırabiliriz Bu esnekliğin bize kazandırdıklarını da şöyle özetleyebiliriz: -          Veri işleme yükünün veri tabanları arasında istenen şekilde dağıtılması -          Network trafiğinin azaltılması -          Her veri tabanının güçlü yanını kullanabilme Changed Data Capture (Değişen Verinin İşlenmesi) Günlük olarak yükleme yapılan bir veri ambarı düşündüğümüzde kaynak sistemlerden değişen verinin alınması zorunluluğu ortaya çıkmktadır. ODI içerisinde değişen verinin veri tabanı loglarından okunarak veya triggerlar ile bulunabilmesi için çeşitli knowledge moduller de bulunmaktadır. Örneğin kaynak sistemi Oracle olan bir kurumda operasyonel sistem tablolarından değişen verinin sisteme en az yük getirecek şekilde bulunabilmesi basit bir şekilde mümkün olmaktadır. Değişen verinin veya tüm verinin işlenmesi için iki farklı akışın oluşturulması da gerekmemektedir, sadece bir check box ın işaretlenmesi ile akışın değişen veriyle çalışmasının sağlanması mümkün olmaktadır. Master Data Management Bugüne kadar kurumda bulunan hiçbir operasyonel sistemin sorumluluğu müşteri, ürün vs. verisinin tekliğini, doğruluğunu ve bütünlüğünü gözetmek değildi. Master Data’yı  ise bu sorumluluğu alan sistem olarak düşünebiliriz. ODI değişik ortamlarda bulunan master verinin Master Data üzerinde konsolide edilmesi ve diğer tüm sistemlerle paylaşılması konusunda organizasyonlara yardımcı olabilmektedir. Veri seviyesinde yapılan bu entegrasyon aynı zamanda Servis Odaklı Mimari geçişlerinde de servislerin tanımlama zorluklarını da basitleştirmiş olmaktadır. Servis Odaklı Mimari ODI ile oluşturulan veri çevrimin ve verinin kendisi web service’ler ile dış kullanımlara açılabilmektedir. Veri çevrimi için dış ortamlarda bulunan web service leri de ODI içerisinden kullanılabilmektedir. Bu olanaklar ile verinin ve veri çevrim süreçlerinin kurumların SOA altyapıları ile entegrasyonu mümkün olabilmektedir. Java Mimarisi ODI tamamı ile java ile geliştirilmiş ve dolayısıyla ortam bağımlılığı yoktur. Aynı kodun windows, linux ve unix ortamlarında çalışabiliyor olması uygulamanın geliştirme maliyetinide düşürdüğünden kurumlara maliyet olarak avantaj sağlayacağı da düşünülebilir. Erişebilirlik ODI tüm JDBC,ODBC desteği olan populer veri tabanlarını ayrı bir connectore ihtiyaç duymadan kaynak veya hedef olarak kullanabilmektedir. İlişkisel veri tabanları yanında çok boyutlu veri tabanları (Essbase), text dosyalar, xml, JMS tabanlı veri kaynaklarını da kullanabilmektedir. Öğrenme Hızı Son olarak ODI ı öğrenmek için harcayacağımız efordan bahsedelim; SQL bilgisi olan bir uygulamacı 2 günlük bir eğitim sonunda  ELT işleri tasarlayabiliyor duruma gelebiliyor. Bazı durumlarda uygulamacıların uzun zamanlarını alan hata mesajlarının anlaşılması da önemli bir konu. Veri ile uğraşan her uygulamacının SQL bildiği varsayılabilir ve ODI ın hata mesajları SQL hataları şeklinde kullanıcılara sunuluyor. Bu fark Hataların anlaşılması aşamasında ciddi bir kolaylık sağlayabiliyor. Knowledge Moduller sayesinde değişik uygulamacıların geliştirdikleri uygulamaların standartlaştırması  kaygısı ortadan kaybolmaktadır. Her kullanıcının geliştirmesi gereken  onlarca adım zaten ODI tarafından KM ile hazır sunulmaktadır. Uygulamacılar verinin akışı ile ilgili herhangi bir tasarım yapmamakta sadece veri eşleştirilmesi (mapping) yapmaktadırlar. Sonuç Yukarıda öne çıkan özellikleri anlatılan ODI ürünü içerisinde aynı zamanda metadata yönetimi, scheduling, process flow tasarımı, data quality firewall gibi birçok özellikleri de mevcuttur. Özet olarak söyleyecek olursak; veri tabanlarını en iyi şekilde kullanıp, basit ve yüksek performansta veri entegrasyonu yapabileceğimiz bir ürün ODI. Veri ambarı ve veri entegrasyonu projelerinde yeni bir yaklaşımla benzer geleneksel ürünlerin bir adım önüne çıkmaktadır.

Data Cleansing, data martlarımızı oluşturmadan önce mutlaka ayarlanması gereken ve ilerde ETL süreçlerimizde bizi sıkıntıya sokacak türden verilen kullanımını engeller ve aynı formata girmesini sağlar.Örneğin tarih alanlarımızda a,d,56,!..vb gibi karakterler görüyorsak bunları null,sysdate veya bizim belirlediğimiz herhangi bir alanda istediğimiz şekilde o veriyi tutmamız gerekecektir.

İşte bu yüzden işzekası nda bulunan bu güzel yazıyı paylaşıyorum

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.

Merhaba Arkadaşlar,

Uzun süren çalışmalardan sonra alanımızdaki başarılarımız gün geçtikçe artıyor.Türkiyede ilk olma özelliğimizin yanısıra dünyada datawarehouse searchlerinde 4. sırada yer almamız bizi ayrıca mutlu etmiş durumda.

Şimdi daha pratik daha hızlı çözümler üretmek amacıyla google grubumuz bulunmaktadır.

http://groups.google.com/group/trdatawarehouse

Bu e-Posta adresi istek dışı postalardan korunmaktadır, görüntülüyebilmek için JavaScript etkinleştirilmelidir

adresinden grubumuza katılabilir, dwh hakkında sorularınızı gruptaki arkadaşlarla paylaşabilir ve doğru bilgiye kısa zamanda ulaşabilirsiniz.Yararlı olması dileğiyle

 

Yusuf Arslan

Site-Admin

  

Microsoft, verinin olusumundan/depolanmasından baslayarak, son kullanıcının

mevcut veri uzerinden gecmisle ilgili analiz ve gelecekle ilgili kestirimlerde bulunmasını

sağlayacak bir dizi arac ve yontem sunmakta ve bunların butunune “İs Zekası”

uygulamaları demektedir.

Karar vericilerin en doğru kararları verebilmesi icin organizasyonun urettiği verilerin

veritabanı uzmanlarınca en doğru sekilde yapılandırılarak saklanması, gerektiğinde

farklı ortamlardan alınan verilerin uygun bir bicimde bir araya getirilmesi ve veri

analistlerince uygun yontemlerle is analistlerine sunulması ve is analistlerince

yorumlanarak karar vericilerin anlayabileceği bicime donusturulmesi gerekmektedir.

Microsoft bu sureclere destek vermek icin SQL Server urununu OLTP veritabanı

sunucusu olarak, SQL Server Integration Services urununu veri transferi ve temizleme

aracı olarak, SQL Server Analysis Server aracını veri madenciliği ve analiz aracı

olarak, son olarak da SQL Server Reporting Services aracını, sonucları son kullanıcılara

gostermek amacıyla raporlama aracı olarak sunmaktadır.

Ayrıcı Excel ve bazı diğer web bilesenleriyle, veri madenciliği ve analizi sonuclarını son

kullanıcıların daha rahat ve etkin kullanacağı araclar da sunmaktadır

. İş Zekâsı ve Microsoft

Günümüzde işletmeler için kullanılabilir bilgi çok önemli bir değerdir. 21. yüzyıl

ekonomisinin rekabetçi ortamında, firmaların sürdürülebilir rekabet avantajı

sağlayabilmeleri için bilginin gücünü daha etkin bir şekilde kullanabilmeleri gerekir.

Kurumların bilgiyi kullanma çabalarında ulaşılan son aşama, iş zekâsı uygulamalarıdır. İş

zekâsına küçük-büyük tüm işletmelerin ihtiyacı vardır ve iş zekâsı çözümleri karar alma

süreçlerinde önemli rol oynar.

Kurum ve kuruluşların karar vericileri, en doğru kararı verebilmek için en doğru bilgilere

gereksinim duymaktadırlar. Karar vericilere bilgiye dayalı ilerleme imkânı sunarak,

kurumun gelir ve performansını en üst düzeye ulaştırmayı hedefleyen iş zekâsı

uygulamaları, tüm kuruluşlara rekabet gücü sağlamaktadır.

Hedefi yüksek performansa ulaşmak olan kurum ve kuruluşlar için bilgiye ulaşmak, ulaşılan

bilgileri paylaşmak ve kullanabilmek hayati öneme sahiptir. Bunu gerçekleştirmenin en

kolay, pratik ve güvenilir yolu iş zekâsı çözümleridir. İş zekâsı çözümleri, kurum içi ve dışı

verileri bir platformda toplayıp analiz etme yeteneğinde olup işletmelerin bilgiyi

yönetebilmeleri ve bir değere dönüştürebilmelerine imkân tanır. Dolayısıyla

organizasyonların daha yüksek performans düzeyine ulaşmalarına yardımcı olur,

operasyonel verimlilik ve şeffaflık sağlar. Aynı zamanda CRM “Customer Relations

Management” , ERP “Enterprice Resource Planning” gibi kurumda şu ana kadar yapılmış

olan iş ve BT “Bilgi Teknolojileri” yatırımlarının da etkin geri dönüşüne imkân sağlar.

İş zekâsı uygulamaları sayesinde karar vericiler, stratejik ve operasyonel kararlarında daha

doğru ve hızlı adımlar atabilmektedirler. İş zekâsı çözümleri, etkin bilgi yönetimi sürecinin

vazgeçilmez bir parçası olarak karşımıza çıkmaktadır. İş zekâsı çözümleri, başlangıçta daha

çok kurum ve kuruluşlarda karar vericilere hitap eden bir çözümler bütünü olarak ortaya

çıkmıştır. Hâlbuki sadece karar vericilerde değil, kurumların her aşamasında iş zekâsı

uygulamalarına ihtiyaç vardır ve her aşamada kritik bir öneme sahiptir.

İş zekâsı uygulamalarıyla, verilerin bilgiye, bilginin yoruma, yorumun karara ve kararın

eyleme dönüştürülebilmesi mümkün hale gelmektedir. İş zekâsını bir süreç olarak

düşünürsek; veri bilgiye, bilgi yoruma, yorum karara ve karar eyleme dönüştüğünde gerçek

bir iş zekâsından bahsedilebilmektedir.

Neden Microsoft Araç Seti?

Microsoft teknolojilerini kullanarak bir DW/BI (Data Warehouse / Business Intelligence)

sistemini nasıl inşa edeceğimizi tarif etmeye devam etmeden önce, şu soruyu sormak

yerinde olur: Microsoft araç setini ilgi çekici kılan ne?

Bütünlük: İşletim sisteminden, veritabanı motorlarından ve geliştirme ortamlarından Office

ve Excel masaüstüne kadar sadece Microsoft yazılımı kullanarak bütün bir DW/BI sistemi

inşa edebilirsiniz. Tüm bileşenlerin etkin bir şekilde birlikte çalışacağına duyacağınız

güvende ekstra bir rahatlık alanına sahipsiniz.

Düşük Sahip Olma Maliyeti: SQL Server'ın lisanslama maliyetleri diğer yazılım

üreticilerinin karşılaştırılabilir ürün kümelerine göre daha düşük olagelmiştir; ancak toplam

sahip olma maliyeti, lisanslama maliyetlerinin yanı sıra, sürekli destek, eğitim ve operasyon

maliyetlerine de bir o kadar bağlıdır. Microsoft, SQL Server sistemlerinin rakip ürünlere göre

daha az yönetsel kaynak gerektirdiğini iddia etmektedir. Organizasyonunuzda .NET

programlama yetenekleri zaten var olabilir. Eğer öyleyse, DW/BI sisteminizi özelleştirmek ve

genişletmek gerçekten kolay olabilir.

Açıklık: Her ne kadar tüm bir DW/BI sistemini Microsoft yazılımıyla inşa etmeniz

mümkünse de -ki bu kitap bunun nasıl yapılacağını anlatıyor- böyle davranmak zorunda

değilsiniz. Microsoft DW/BI çatısının her hangi bir bileşeni üçüncü bir parti ürünü için

çıkarılabilir ve pek çok müşteri Microsoft DW/BI sistemlerini heterojen ortamlarda

oluşturmaktadırlar.

Yüksek Performans ve Ölçeklenebilirlik: Bu kitabın yazıldığı sıralarda, terabaytlık

hacimlere sahip DW/BI sistemleri hayli yaygın ve 10-20 TB çok da nadir değil. DW/BI

sistemleri klikleme akışı ve RFID veri akışları gibi alt seviye işlemlere dayanmaya

yöneldikçe, ortalama büyüklükte organizasyonlar bile kendilerini "terabayt kulübü"nde

bulabilirler. Microsoft bu eğilimi fark etmiş durumda ve ürünlerini özellikle de SQL Server

bileşenlerini yüksek veri hacimlerinde iyi performans göstermek üzere test etmiş bulunuyor.

İş Zekâsında Microsoft Yatırımı: SQL Server 2005 iş zekâsı çözümleri, bir arada dikişsiz

değilse bile çok profesyonel dikişlere sahip olarak çalışan gerçek araçlardan oluşmaktadır.

Araçlardan bazıları -özellikle Analysis Services- türünün en iyileri. Tüm ürünler rakipleri

olan tek başına çalışan ürünlerle, sadece kendi özellikleriyle de rekabet edebilir durumdalar.

Microsoft açık bir şekilde mükemmel iş zekâsı uygulamaları geliştirmeniz için gerekli

araçları inşa etmeye kendini adamış bulunuyor. Ve Microsoft'un uzun bir süre boyunca

etrafta olacağına mantıklı bir güven duyabilirsiniz.

Yaygın Olarak Kullanılan İş Zekâsı Terimlerine Genel Bir Bakış

İşletmeler genellikle iş sistemlerinden ikisini kullanırlar. Bu sistemler;

1. Çevrimiçi hareket işleme (OLTP) olarak ta bilinen Operasyonel işlemler,

2. Kullanıcılara işlerinde daha etkili kararlar alabilmesini sağlayan ve bu amacı

gerçekleştirebilmek için operasyonel verileri uygun bir şekilde seçerek alan Karar

Destek Sistemleri’dir.

Bazı şirketler bu iki işlemi tek bir sistemde gerçekleştirmelerine rağmen genellik bu durum

aşağıda açıklayacağım nedenlerden dolayı pek uygun olmamaktadır.

· Operasyonel sistemler içinde bulunan OLTP verileri tekrarlamayı önlemek üzere

normalleştirilirler ve bu verilerin analiz işlemlerinde kullanılması için daha karmaşık

sorgular yazılmasını gerektirir.

· OLTP sistemler Veri Ekleme, Düzenleme ve Silme işlemleri için uyarlanmışlardır ve

genellikle yüksek bir indekslemeye tabii tutulmamışlardır. İndekslerin az olması

nedeniylede analitik verileri almak için kullanılan sorgularda performans problemleri

olması yüksek bir olasılıktır.

BI çözümlerinin temel hedefi geniş ölçekli karar destek yeteneği ve kullanıcıların iyi organize

edilmiş ve çeşitli kullanıcı gruplarından gelmiş verileri kolay kullanabileceği araçlar

sunmaktır. BU nedenle veriler OLTP sistemlerinde olsalar bile bir BI sistemine aktarılıp bu

sistemde etkin karar destek sorgulamalarına gidilmelidir.

Aşağıda BI çözümleri için kullanılan temel BI terimleri ve açıklamaları anlatılmıştır.

ETL : Operasyonel sistemlerde tutulan veriler işletmede kullanılan uygulamalara özel bir

şekilde tutulduğu için kullandığımız BI sistemine direkt olarak atılmaya uygun olmayabilir.

Bu tür heterojen yapılardan gelen verilerin BI sistemine Aktarılması, Uygun Şekilde

Çevrilmesi (işimize yaramayan verilerin ayıklanması, veri tiplerinin uygun hale getirilmesi,

vb.) ve son olarak BI sistemine Yüklenmesi işlemine ETL adı verilmektedir. ETL konusu

daha detaylı bir şekilde 4. bölümde işlenecektir.

Data Warehouse : Veri ambarı olarak da adlandırabileceğimiz Data Warehouse, BI

sistemlerinde kullanılan tutarlı verilerin tutulduğu merkezileştirilmiş ambarlardır. Bu kısa

tanımla birlikte aslında veri ambarları, veri analizi, veri madenciliği ve raporlama

işlemlerinin her biri için verinin farklı kopyalarını da tutarlar. Ayrıca sorgu performansını

artırmak için bir çok durumda Denomalize işlemine tabi tutulmaları gerekmektedir.

Data Mart : Data Mart’ları Veri Ambarının bir parçası olarak tanımlayabiliriz. Örnek vermek

gerekirse, bir şirket içerisinde bulunan Pazarlama ve Satış departmanlarına ait analizleri Veri

Ambarının tamamından değilde sadece Pazarlama yada sadece Satış departmanlarına ait

bölümlerinde çekip işlemeye Data Mart adını verebiliriz.

OLAP : Çevrimiçi Analitik İşleme olarakta bilinen OLAP en çok kullanılan analizlerden

olan çok boyutlu analizdir. Bu sayede veriyi işletmenin kabul ettiği sınırlar dahilinde bir

7

OLAP küpü içine yerleştirebilir ve bu şekilde detaylı bir analiz gerçekleştirebiliriz. Örneğin;

kullanıcıların satış toplamlarını ürüne, sipariş tarihine, müşteriye ve satıldığı lokasyona göre

ayrı ayrı gösteren bir küp oluşturabilriz.

Data Mining : Veri Madenciliği, veriyi analiz etmek ve veri içerisinde bulunan örnek ve

istatistiklere bağlı olarak tahmin yürütebilmek için matematiksel algoritmalar kullanan bir

çözümdür. Veri Madenciliği çözümleri içerisinde eğilimleri, kümeleri yada istatistiksel

ilişkileri barındıran bir yada daha fazla veri madeni algortiması içerebilir. Örneğin; bir

müşterinin daha önceden almış olduğu malları kullanıp o müşterinin hangi tür ürünlere

eğilim gösterdiği tahmin edilebilir ve müşteriye eğilim gösterdiği ürün kategorisinde yeni

çıkmış bir ürüne ait bilgiler gönderilebilir yada ona benzer özellikler gösteren farklı

müşterilerin almış oldukları diğer ürünler öneri olarak sunulabilir.

Dashboard ve Scorecard : İşletmenin kısa ve uzun vadeli taktik anlayışlarını belirlediği

araçlara verilen isimlerdir. Scoreboard’lar haftalık ve aylık taktik belirlemeye dolayısı ile

uzun vadeli işlemler için kullanılırken Dashboard’lar ise daha kısa süreli örneğin bir iki saat

aralıklarla bile güncellenebilirler. Bu nedenle Dashboardlar içerisinde scoreboard’lar

barındırılabilir.

Raporlama : Standart sabit raporlardan verilen parametrelere bağlı olarak belli seviyelerde

içerisinde gezinebileceğimiz raporlarımız olabilir. Ek olarak raporlama sistemi kullanıcılara

yetkilerine bağlı olarak raporların en güncel durumlarını otomatik olarak sunabilmelidir.

3. İş Zekası Adımları ve Microsoft’un İlgili Araçları ve

Teknolojileri

İş Zekası Adımları

Bir iş zekası projesini kolay bir şekilde yönetebilmek için bir çok şey yapılabilir. Aşağıda

bahsedilen konu başlıkları bir İş Zekası projesini nasıl daha yapısal ve disiplinli bir hale

getirebileceğimiz anlatılmaktadır.

İş Zekası Projesindeki farklı İş Zekası Komponentlerini Alt Projelermiş gibi

Değerlendirmek

Bir İş Zekası projesi; Çekme, Dönüştüme, Yükleme(ETL), Veri Madenciliği(Data Mining),

Çevrimiçi Analitil İşleme(OLAP) ve Raporlama gibi birbirlerinden farklı bir çok alt

komponentten oluşur. Geliştirme aşamasında bu alt komponentlerin her birini Ana Proje

altında alt projeler olarak ayrı ayrı tanımlayarak bu alt projelere özel ihtiyaçları daha

kolaylıkla ortaya çıkarabiliriz. Örneğin; yukarıda da bahsettiğim gibi İş Zekası projesi

8

içerisinde ETL ve OLAP işlemleri o projenin bütününde yer almasına rağmen, ETL, veri akışı

ve bu verilerin işleme sıralamasıyla alakalı işleri yaparken, OLAP ise ETL’de işlenip Veri

Ambarına aktarılmış haline çok boyutlu analizler yapmak üzere tasarlanmıştır. Bu

farklılıklardan dolayı bu iki işlemi ayrı projeler olarak değerlendirmek hem bu işlemlere özel

ihtiyaçların hem de her iki işlem arasında yapılacak bağlantıların belirlenmesini

kolaylaştıracaktır.

Analiz Çözümleri Veri Modellemesi için İşletme Gereksinimlerini Kullanmak

Veri Ambarı ve OLAP küpleri için en önemli unsure işletme ihtiyaçlarını karşılayan Veri

Modelleri kullanmaktır. Bu nedenle veri modelleri oluşturulurken sadece işletmenin

kendisini değil işletmeyle birlikte iş yapan diğer kurumları da, işletmeyle ilişkilerine bağlı

olarak değerlendirip, bu değerlendirme sonuçlarına gore hazırlanmalıdır.

ETL Çözümünde Kullanılacak Veri Kaynakları ve Hedeflerini Belirlemek İçin

Analiz Sonuçları Kullanmak

Hangi Veri kaynağının kullanılacağı ve alınan verilerin nereye yükleneceğinin belirlenmesi

İş Zekası projelerinin en önemli adımını oluşturmaktadır. Bu nedenle projeye başlamadan

önce bu analizlerin düzgün bir şekilde yapılması gerekmektedir. Analiz esnasında aşağıda

yazılı unsurların kesinlikle belirlenmesi projenin başarıyla sonuçlanmasında önemli bir yer

teşkil etmektedir.

1. Kesin Kaynaklar ve bu kaynaklara ait karakteristikler(Veri Tipi vb.)

2. Veriyi çekmek için kullanılacak teknoloji. Örneğin OLEDB kullanarak mı yoksa

ODBC kullanarak mı veri kaynağına bağlanacağız?

3. Çekilecek verinin boyutu

4. Ne sıklıkta veri çekileceği

5. Çekilen veriyi doğrulama ve çevirme işlemine tabi tutulup tutulmayacağı

6. Çekilen verinin saklanması için araya başka veri kaynaklarının alınıp alınmayacağı

İhtiyaç analizi yukarı bahsedilen adımların detaylı bir şekilde tanımlanması işletme için en

uygun ETL çözümünü sunmamızı sağlayacaktır. Bu adımda önemle durulmalıdır çünkü

ETL çözümleri hatalı yada eksik analizler neticesinde çok büyük zaman ve para kaybına

neden olabilirler.

Raporlama Çözümleri İçin Analiz Sonuçları Kullanmak

Bir İş Zekası projesinde OLAP küpleri ve veri kaynakları raporlama amacıyla kullanılabilir.

Raporlama çözümlerinde sıklıkla kullanılan yöntem son kullanıcıların hali hazırda

kullandıkları raporları örnek alıp o raporlara uygun çözümler sunmak işimizi

kolaylaştırabilir. Aynı şekilde yeni projeyle yeni raporlama ihtiyaçlarıda ortaya çıkacağından

bu ihtiyaçların karşılanması için, yöneticiler, son kullanıcılar, kısacası tüm kademelerdeki

çalışanların görüşleri alınıp alınan bu görüşlerin dokümante edilmesi gerekir. Tüm

raporlama çözümleri aşağıda yazılı unsurları ne kadarını karşılayacağı önceden

belirlenmelidir.

1. Detay seviyesi

2. Rapor üretim sıklığı

Inmonism vs Kimballism

 

 

Veri ambari olayının iki büyük üstadı: Bill Inmon, Ralph Kimball. Yıllardır sorulmaya devam eden soru: Hangisinin yaklaşımı daha doğru?

Inmon’in işaret ettiği yöntem, tarihsel derinliği olan, kalıcı, konu odaklı ve entegre bir yapı kurup tüm kurumsal veriyi burada depolamak. Bunu yaparken verinin normalize bir formda tutulmasını önemsiyor Inmon. Çünkü her bir verinin tek bir erişim noktasının olmasını sağlamak istiyor.(Single version of truth). Böyle bir yapıyla veri entegrasyonu sağlanmış oluyor.(Veri entegrasyonundan anlaşılan su olmalı: Birincisi, her türlü kaynaktan alınan veri tek bir ortamda ayni veri deseni altında toplanmıştır(Veri konsolidasyonu).İkincisi de, ulaşılmak istenen bilginin tek bir adresinin olması sağlanmıştır).

Bahsettiğimiz yapıdaki bir veri ambarından -normalize ve en atomik yapıda olmasından dolayı- veri çekmek zordur. Bu yüzden genel yaklaşım yalnızca bu veri ambarını kaynak olarak kullanan departmantal datamartlar gelistirmektir. Kullanıcı da bu datamartlar üstünden sorgularını çeker, analizini yapar. Bu şekilde merkezi bir veri ambarı ve bu veri ambarına bağlı datamartlardan oluşan mimariye hub-and-spoke mimarisi deniyor.

Kimball’in yaklaşımı ise merkezi bir ortamda ve ortak bir desende veriyi toplamadan, direk departmantal veya konu odaklı datamartlar geliştirmek ve bu datamartlari kullanıcının kullanımıma açmak seklindedir.
Bu yaklaşımda, veri ambarı dediğimizde oluşturulmuş datamartların tümünü anlamalıyız. Kimball’in yaklaşımında en önemli kavramlardan biri conformed dimension’lardır. Veri konsolidasyonunu sağlamak amacıyla ortak dimension ve measure’lardan oluşan bir katman(conformed dimensions) vardır ve bu katman tüm datamartlarda kullanılarak herhangi iki datamartın bu katman üzerinden konsolide edilmesi sağlanır.

Süreç açısından iki yaklaşımı karşılaştırdığımızda Inmon yaklaşımında ODS ve/veya staging alan üzerinden tüm kaynak sistem verilerini tek bir sistemde veriyi tekilleştirip ve konsolide edip toplamak sonrasında bu entegre sistem üzerinden ilgili datamartları geliştirmek varken; Kimball yaklaşımında yine ODS, staging alan üzerinden birbirinden bağımsız ama conformed dimensionlarla birbirine bağlanabilecek datamartlar geliştirmek vardır. Birincisinde, kaynaktaki veriler nasıl bir araya getirilir diyerek işe başlanırken, diğerinde iş ihtiyaçları nedir diyerek projeye başlanır.

Piyasada kullanırlıklarına baktığımızda çoklukla Inmon yaklaşımının uygulanıp hub-and-spoke mimari tasarlandığını görüyoruz. Bu yaklaşımı uygularken genelde vendorların, bu yaklaşıma uygun olarak tasarladıkları mantıksal veri modelleri kullanılıyor.

Peki hangi yaklaşım daha doğrudur?  Ben de “duruma göre değişir” genel kanaatine katılıyorum.  İki yaklaşımı kıyasladığımızda, birinde daha sağlam ama geç bir teslimat diğerinde ise hızlı ve isteklere cevap veren bir teslimat ama ileriye dönük olarak oluşabilecek entegrasyon sorunları muhtemeldir. Her ikisini de belli noktalarda diğerine yaklaştırıp riski azaltmak elbette mümkün. Inmon yaklaşımında, entegre yapının tamamen bitmesini beklemeden bittikçe teslimatlar sağlamak, Kimball yaklaşımında conformed katman üstünde yoğunlaşıp burada entegrasyon sorunlarını çözmek gibi. Ama şu kesin ki Inmon yaklaşımında biraz daha fazla sabır, biraz daha fazla üst yönetim desteği gerekli. 

Bu soruya cevap verirken düşünmemiz gereken en önemli konu da aslında kaynak sistemlerimizdir. Eğer çok az sayıda kaynak sistemimiz varsa entegrasyon için teslimatları ertelemek mantıklı olmayabilir. Çünkü belirttiğim gibi entegrasyonun iki aşaması vardır. Veri konsolidasyonu: Zaten az sayıda kaynak sistem olduğundan küçük bir sorun. Veri Tekilleştirme/Normalizasyonu: yine zaten operasyonel sistemlerin doğası gereği normalize yapıları vardır ve kaynak sistem az olduğundan farklı yerlerde de veri çoğullanmamıştır. Dolayısıyla tek ya da az sayıda ve düzenli kaynak sistemi olan bir organizasyonda tekrardan bir katman oluşturmak yerine direk olarak datamartlar geliştirmek daha akılcı bir çözüm olabilir. Ancak çok sayıda kaynak sistemi olan bir organizasyonda da Kimball yaklaşımı bir süre sonra entegrasyon sorunlarını ciddi seviyelere çıkaracaktır.

Mantıksal Veri Modelleri:
Inmon yaklaşımını benimseyen organizasyonlar, genellikle IBM, Teradata, Oracle gibi vendorların sağladıkları mantıksal veri modelleriyle işe başlıyorlar. Bu veri modelleriyle kaynak sistemlerdeki hangi tip verilerin bir araya getirilip hangilerinin arasında ilişki tanımlanmalı gibi sorular cevaplanıyor. Kullanılıp kullanılmaması konusunda benim kanaatim, tüm modeller için olan kanaatimle paralel. Modellerin çoğunun çok faydalı olduğunu düşünüyorum ama hiç birinin herhangi bir organizasyonun ihtiyacını direk karşılayacağını düşünmüyorum. Modelleri bir analiz dökümanı gibi değerlendirip okumanın ve çıkarımlar yapmanın çok faydalı olacağı, çok önemli bir rehber olacağı kesin ama bir modeli ulaşılmak istenen son nokta gibi konumlandırmak çok yanlış. Bir organizasyon eğer tüm mantıksal tabloları birebir fizikselleştiriyorsa bu yanlışa düşmüş demektir. Adı üstünde mantıksal veri modeli. Mantıksal kalmalı, birebir fizikselleşmemeli.

 kurumsalzeka.com

 

ETL süreci, veri ambarı olayının en meşakkatli işi diyebiliriz. Veri ambarı kurulduktan sonra hergün devam eden aksadığında organizasyonda yüksek seslerin çıkmasına sebep olan, sürekli düzgün gitmesi de mümkün olmayan, organizasyondaki tüm teknik sistemlere dokunan bir iş. Her ne kadar ne yaparsan yap yine sıkıntı kaçınılmaz gibi bir resim çizmiş olsam da işin en başından bazı durumlar için kafa yorarsak bu problemleri minimize edebiliriz.

Veri ambarı projesinin ETL’e bakan kısımlarını yürütürken alacağımız kararlar, üstünde düşünmemiz gereken bazı konuları sıralayalım:

1. ETL işi için bir ürün satın almalı mıyız yoksa in-house çözümlerle bu işin üstesinden gelebilir miyiz? Veri ambarınin ilk çıktığı zamanlarda in-house çözümlerle bu işler götürülmüş ama günümüzde çok gelişmiş ürünler var dolayısıyla hazır bir ürün kullanmak işleri kolaylaştıracaktır. Her şeyden önce hiç kod yazmadan sürükle bırakla bir sistemden diğerine veri transferi yapmak mümkün. Bunun dışında, herhangi bir ürünle staging olayını ortadan kaldırıp direk final formda veri ambarında tabloları tutabiliriz. Çünkü etl ürünleri artık her türlü transformasyonu memory üstünde yapabiliyor. dolayısıyla önce aynen bir staging alana alayım sonra ordan sql ile transform edeyim derdi yok. Bir avantajı da ürünlerin tüm süreci yönetip, izlemeyi sağlayan önyüzler sağlaması. Etl ürünü almayı tercih etmezsek, her şeyden önce bir tasarruf yapmış oluruz. Ürün olduğu duruma göre çok yavaş da gitmez aslında işler ama bakım aşamasında işler biraz zorlaşacaktır. Lisanslama ücretleri fazla geliyorsa bir de yeni bir ürüne adaptasyon, eğitim ihtiyacı vs gibi sebepler ürün almayalım noktasına götürebilir şirketleri. Kaldı ki, gerçekten süreç iyi yönetilip standartlar oluşturulursa gayet de güzel gider işler ama her durumda bir scheduling ürününe ihtiyaç olacaktır.

2. Hangi tablolar hangi sıklıkta veri ambarına alınmalı? Bu konu aslında kullanıcı ihtiyaçlarına bağlı bir durum. Kullanıcılar kimi tabloların her gün, kimi tabloların haftada bir, kimisinin de belki de saatte bir güncellenmesini isteyebilir. ETL sürecinde günlük yüklemenin sistemi zorlayacağı durumlar olabilir. Bu durumlarda problem belirtilip kullanıcıyla mutabakata varmak gerekebilir veya analiz netleşmemişse hangi veri hangi sıklıkta gereklidir konusunda ihtiyaç analizi atlanmamalıdır.

3. Tabloları kaynak sistemden alırken her defasında tüm tabloyı yeniden mi almalıyız yoksa sadece değişen kısmı mı almalıyız? Bu konu da üzerinde fazlaca düşünülmesi gerekilen bir konu. Zaman kısıtı yoksa tüm tabloları yeniden almak çok kolay ve sağlam bir metot ama ne yazık ki zaman kısıtı hep var. Dolayısıyla kaynak sistemde, veri ambarına son yükleme tarihinden sonra hangi kayıtlar eklendi, hangi kayıtlar güncellendi ve hangi kayıtlar silindi sorusuna cevap bulabiliyor olmalıyız.(Bu olaya Change Data Capture(CDC) deniyor.). CDC yöntemlerinden ayrıca bir yazımızda bahsedeceğiz ama ETL sürecinde düşünülmesi gerekilen en önemli konulardan biri olduğunun altını çizmek lazım.

4. Staging yapmalı mıyız? Hangi tablolarda yapmalıyız? Bu konu da performansı direk etkileyen konulardan biri şöyle ki daha önce de belirttiğimiz gibi artık ETL ürünleriyle hiç staginge ihtiyaç duymadan her türlü transformasyonu yapıp direk final tabloya load edebiliyoruz. Bu durumda tekrar tekrar diske yazma işlemi yapmaktan kurtuluyoruz dolayısıyla ciddi bir hızlanma sağlanıyor. Ancak, bazı durumlar bu yaklaşımı değiştirmeye itiyor. Birincisi, CDC yaparken son load zamaninin verisine ihtiyaç duyulabilinir. İkincisi, büyük tablolarda tablonun alınıp havada transform edilip load edilmesi süresi uzun bir süre ve bir şekilde kesilmesi durumunda (OS veya DB vs kaynaklı olarak) zaman kaybı olacak. Genelde basamakları kısa tutmak gibi bir yaklaşım hep daha sağlamdır. Son bir sebep de transformasyon işleminde olabilecek problemleri kontrol etmek için kaynak sistemi sorgulamak zorunda olmak. Dolayısıyla staging yapmalı mıyız, hangi tabloları yapalım hangilerini yapmayalım konusu üstünde düşünülmesi gerekilen bir konu.

5. Veri kalitesi(Data Quality) ile ilgili yaklaşım ne olmalı? Veri kalitesi işi genelde Veri ambarı grubuna yıkılan bir iş oluyor dolayısıyla ETL sürecinde bunun için de bazı önlemler almak akıllıca olabilir. Kaldı ki kalitesiz veri zaten bazı varsayımlarımızı bozup ETL işlerinin patlamasına sebep de olabilir. Şöyle ki cinsiyet tutulması gereken kolonda ERKEK veya KADIN gibi değerler olacağını varsayarız buna göre transformasyon işlemleri yaparız fakat bu kolon da beklemediğimiz bir değer geldiğinde bu kaydı ne yapmalıyız? Kimball der ki, bu gibi durumlar için hem fact hem dimension tablolarında bir quality kolonu bulundurun ve böyle varsayım dışında kalan durumlarda o satırı işaretleyin ki veri kalite problemlerini görebilelim. Başka bir yaklaşım bu gibi durumlarda bu satırı komple başka bir hata tablosuna atıp esas tabloya atmamak olabilir ama hatalı kolondan bağımsız alınabilecek raporları kurtarmak adına bu yaklaşım çok sağlıklı değil.

6. ETL’in düzgün çalışıp çalışmadığını anlamak için nasıl bir mekanizma kurabiliriz? Problem olduğu düşünülen durumlar olduğunda kontrol amaçlı olarak transform edilmiş ve rapora açılan tablo ile kaynak tabloyu kıyaslamak durumunda kalıyoruz. Ancak normal süreçte tüm tablolar için bu kontrolü yapmak sürdürülebilir bir iş olmuyor. Bu amaçla şöyle bir yaklaşım geliştirebiliriz: Bazı istatistikî değerler için kabul aralıkları oluşturup ilgili günün o istatistik değerlerinin bu kabul aralığında olup olmadığını bir sql script yardımıyla yapıp sonuçları bir tabloya yazmak işleri çok kolaylaştırabilir. Başka bir yaklaşım olarak da önce kaynak sistem üstünde bazı istatistikler alıp sonra veri ambarında aynı istatistikleri alıp arada bariz fark olup olmadığını kontrol etmek olabilir. Bu istatistikî değerler; toplam satır sayısı, ortalama tutar gibi genel bazı değerler olsa da hata olup olmadığını çıkartmamızı sağlayacaktır.

7. Kaynak sistemlerde yapilan degisikliklerin veri ambarına etkisini nasil kontrol altinda tutabilirim? Bu konu ETL işlerinin patlamasina en fazla sebep olan konu diyebiliriz. Kaynak sistemdeki bir tabloda yapılan kolon ekleme, kolon çıkarma, kolon özelliğini değiştirme gibi durumlarda ETL işlerine müdahale edilmezse sonuç işlerin hata almasi şeklinde oluyor. Bu problemle baş etmenin ideal yolu kaynak sistemlerde yapılan değişikliklerin veri ambarına bildirilmesi için arada bir anlaşma yapmaktır ama ne kadar sadık kalınır tartışılır. Ama en azından geliştirme yaparken kaynak sistemde değişiklik yapılabileceği akılda bulundurularak yapılmalı. Mesela select * from.. şeklinde değil de select kolon1, kolon2 … gibi ifadeler kullanırsak bile kaynağa kolon eklenen durumlardan etkilenmemiş oluruz.

8. Değişen dimensionları(Slowly Changing Dimension(SCD)) nasil implement etmeliyiz? Sonrasinda ek iş çıkarmamasi açısından hangi SCD’lere hangi stratejiyi uygulayağımız belirlenmelidir. ETL sürecine gelene kadar bu alanda analiz yapılmamışsa, analiz yapılıp gereksinimlere göre strateji belirlenmelidir.

9. Yükleme performansını nasil kontrol altında tutabiliriz? Yükleme sürelerinin bazı sebeplerle(İşletim sistemi, network, kaynak sistemdeki değişiklik) hiçbir ek geliştirme olmasa da arttığını gözlemleriz. Bunun kaynağına inmeyi kolaylaştırmak için belli adımların çalışma sürelerini tutmak önemlidir dolayısıyla hangi adımın gereğiden fazla sürdüğü kolayca belirlenip ona göre aksiyon alınabilir.