Uzmanına Sor

OLAP Sisteminin Özellikleri
OLAP sistemleri verinin analizi ve analiz sonuçlarının sunumuna odaklanmış bir altyapı sunar. Bu altyapı OLAP sistemlerini efektif karar verme gereksinimi duyan kullanıcılar için doğal bir seçim haline getirir.

Multidimensional Database
OLAP sistemleri measure, dimension, hierarchy ve cube’ler şeklinde organize edilmiş verilere dayanır. Transactional veritabanlarının tablo, satır, sütun ve ilişkiler içerdiğini hatırlayalım. Bu multidimensional yaklaşım kullanıcıların verileri gereksinim duydukları şekilde bölümlendirme ve filtrelemelerine olanak tanır. Kullanıcılar dimensionlar aracılığıyla verileri farklı açılardan görebilir, hierachyler sayesinde drill yaparak gördükleri bir veriye ait detaylara ulaşabilirler.

Multidimensional bir veritabanı iş zekasına yönelik verilerin saklanması için en sık kullanılan alternatiftir. Multidimensional veritabanlarının analize yönelik verilerin saklanması için en uygun alternatif olmasının yanı sıra, sundukları bir diğer önemli avantajda preprocessed değerlerin saklanmasına uygun bir altyapı sunuyor olmalarıdır.

Preprocessed Aggregates
Bir karar verici, belirli bir ölçütün, belirli boyutlara bağlı değerini görmek istediğinde, göreceği değerler o anda on-the-fly olarak hesaplanır. Karar vericinin bu hesaplama işlemi sırasında beklemesi gerekecektir. Bu özellikle veriye erişim hızının önemli olduğu ve büyük boyutlu veritabanlarında istenmeyen bir durum olarak karşımıza çıkacaktır.

OLAP sistemlerinin amacı, karar vericilerin veri ile etkileşim içinde olmasını sağlamak olduğuna göre, hesaplamaların hızlı bir şekilde geri dönmesi gerekir. Bu nedenle OLAP sistemleri bazı değerleri önceden hesaplar. Bu ön-hesaplama, data load ve update işlemlerinin bir parçası olarak, arkaplanda gerçekleştirilen bir işlemdir. Ön-hesaplama bir arkaplan işlemi olarak gerçekleştirildiğinden dolayı, kullanıcılara doğrudan bir etkisi yoktur. Hesaplanan bu değerler küpün içinde saklanmaktadır.

Bir karar verici belirli bir ölçütün, belirli boyutlara göre değerini görmek istediğinde, veriler on-the-fly hesaplanmak yerine veritabanından okunarak kullanıcıya iletilebilecektir. Bu sistemin tepki süresini çok büyük oranda hızlandıracaktır.

Kolayca Anlaşılabilir Bir Yapı
OLTP sistemlerde veri normalize olarak saklanır ve tablolar arasındaki bağlar karmaşık foreign key ilişkileri ile sağlanır. Burada amaç tekrarlayan veri miktarını minimuma indirgemektir. Karar vericilerin bu veriler arasından gereksinim duyduğu veriyi elde edebilmesi için inner ve outer join ifadelerini kullanarak gerekli sorguları hazırlaması gerekecektir. Bir ölçütün hesaplanma yöntemini belirleyen iş kuralları kod tarafında yer alacak ve karar vericinin bir ölçütü kullanmak istemesi durumunda bu hesaplamalar raporun her açılışında yeniden gerçekleştirilecektir.

Çoğu zaman OLTP sistemlerdeki field ve tablolar yazılım geliştiriciler için bir anlam ifade etse de, son kullanıcı açısından bir anlam ifade etmez. Veritabanı sistemi kullanılacak isimlerin biçim ve uzunlukları konusunda kısıtlamalar getiriyor olabilir. Saydıklarım ve benzeri durumlarda ortaya çıkacak tablo ve field isimleri son kullanıcı açısından şifrelenmiş veri izlenimi yaratabilir. Karar vericinin bir alanın aslında hangi veriyi sakladığını anlamakla zaman harcamak ve doğru verinin sorgulandığından emin olmak yerine, veriye odaklanması gerekir.

OLAP sistemlerde ise durum tam tersidir.  Verinin yapısı dimension ve hierarchyler ile temsil edilir. OLAP sistemi doğru tasarlanırsa, bu dimension ve hierarchyler organizasyonun yapısı ile örtüşecektir. Bu nedenle veri yapısı karar vericiler açısından son derece tanıdık olacaktır.

OLAP sistemlerinde bir ölçütün hesaplanmasında kullanılan iş kuralları, ilgili ölçütün hesaplamalar alanı içinde barındırılır. Kullanıcının hesaplamaları ölçütün her kullanılışında yeniden oluşturmasına ihtiyaç yoktur. Örnek vermek gerekirse; işletmemizin net kar değerini şu formülle hesapladığını varsayalım:

Net Kar = Satış Fiyatı – (Hammadde Maliyeti + Personel Maliyeti + Satış Komisyonları)

İlişkisel ortamda net kar verisi aşağıdaki gibi hatalı bir biçimde raporlanabilir:

Net Kar = Satış Fiyatı – (Hammadde Maliyeti + Personel Maliyeti )

ya da

Net Kar = Satış Fiyatı – (Hammadde Maliyeti + Satış Komisyonları)

Bu tutarsızlık karışıklığa ve daha kötüsü yanlış kararların alınmasına neden olabilir. OLAP yapısında ise net kar ölçütü için kullanılacak formül bir noktada tanımlıdır ve karar verici bu ölçüte baktığında her zaman gerekli verileri kullanarak doğru sonucu ürün, ay ya da satış bölgesi gibi bir boyut bazında verir.

Son olarak OLAP sistemleri iş zekasına yönelik yapılar olduğundan, ölçüt, boyut, hiyerarşi ve benzeri tüm OLAP unsurlarıu, karar verici tarafından kolayca anlaşılabilir şekilde isimlendirilebilir, daha iyisi istenilen diğer dillere tercüme edilerek farklı dilleri anlayan kullanıcılar için ayrı sistemler tasarlamak yerine tek sistemin, tüm kullanıcılar tarafından kullanılabilmesi sağlanabilir.

Bir sonraki bölümde, OLAP sistemlerinin mimarisini ele alıyor olacağız.

Paylaş

Hide Sites

Büyük çaplı yazılım projelerinin geliştirilmesi pek çok risk içermektedir. Standish Group’un yaptığı ünlü araştırmalar başarısızlıklarla dolu yazılım projelerinin her dönem için büyük bir kabus olduğunu gösteriyor. 2000 yılında “CHAOS: A Recipe for Success” başlığı ile yayınlanan istatistiğe göre yazılım projelerinin sadece %28’i belirlenen özelliklerle, belirlenen bütçe ve zaman içinde tamamlanabildiğini gösteriyor. Bir başka deyişle, istatistiğe dahil edilen binlerce yazılım projesinden %76’sı, belirlenen özelliklerle, belirlenen zaman ve bütçe ile tamamlanamadı, veya tamamen başarısız oldu. Standish group ortaya çıkan tabloyu iyimser bir üslupla “kaos” olarak nitelendirmiş. Yazılım sistemlerinin iş akışını etkileyebildiği sistemlerde bu gerçekten korkutucu bir durum. Örneğin internet üzerinden açık arttırma yapılan eBay firmasının yazılım sisteminin sadece bir kaç saat için servis dışı kalmasının firmaya maliyetini milyon dolarlar ile ölçebiliriz. Konuya Microsoft açısından baktığımızda, ürünlerin belirlenen tarihlerde hazır durumda olmaması veya beklenilen şekilde çalışmaması durumunda firmanın kaybının yine milyon dolarlar seviyesinde (özellikle yeni ürünlerin yayınlanacağı tarihe yetişmemesi durumunda yapılan anlaşma, pazarlama ve reklam faaliyetlerini hesaba katarsak maliyeti yüz milyonlarca dolar olarak) hesaplayabiliriz. Küçük ve orta ölçekli projelerin maliyeti, projenin belirlenen zamanı aşması ile birlikte öngörülen maliyetin üzerine çıkmaya başlar. 10 kişilik bir proje ekibinde 1 çalışanın saatlik maliyeti 100 USD ise, şirket her iş günü için ortalama 40.000 USD harcıyor demektir. Tabi günlük maliyete kaçan fırsatları, kaybedilen satışları ve kazanılan memnuniyetsiz müşterileri de eklemek gerekir ki bu üç unsur, günlük maliyetten çok daha önemli bir kayıptır.

Pek çok firma process-oriented metodolojileri kullanarak gecikme ve başarısızlıkları azaltmayı / ortadan kaldırmayı ummaktadır ancak bu metodolojiler çoğu durumda iş yoğunluğunu ve buna bağlı olarak gecikmeleri arttırırken, nadiren başarı için katkı sağlamaktadır. Bu metodolojiler aynı zamanda çalışma grubunun bir problemle karşılaştığında, bir çözüm üretmeye yönlendirmektedir ancak üretilen çözüm çoğu durumda, çözümün üretilmemiş olmasına göre daha olumsuz sonuçların ortaya çıkmasına neden olur ve kıdemli (senior) yönetim sorunlardan ya ekip belirli bir milestone’ı kaçırdığı zaman, ya da müşteriler hata rapor ettiği zaman haberdar olur ve sorunu çözmek için projenin kapsamını azaltarak veya diğer projelerin kaynaklarını kullanarak çabalarlar. Sonuçta firma projeyi aşırı maliyetli olmasından dolayı sonlandırır.

Bu gibi sorunların ortadan kaldırılması için daha esnek geliştirme deneyimlerine dayanan “Önleyici Risk Yönetimi”nin kullanımı çoğu durumda olumlu sonuçlar verir. Uygulamanın ana fikri, uygulama geliştirme ve yayınlama sürecinde gecikmeye veya projenin başarısız olmasına neden olabilecek tüm adımlarının tanımlanması ve tanımlanan riskin ortaya çıkması durumunda uygulanarak, riski ortadan kaldıracak veya etkisini hafifletecek stratejilerin planlanmasıdır. Proje ekiplerinin riskleri sadece ortaya çıktıkları / gerçekleştikleri anda tanımladıkları ve ortadan kaldırmaya / etkilerini hafifletmeye çalıştıkları prescriptive risk yönetiminin aksine bu sistemde proje ekibi riskleri, geliştirme süreci öncesinde ve geliştirme sürecinde öngörerek karşı stratejilerini planlamaktadır.

Risklerin Tanımlanması ve Değerlendirilmesi

Risk yönetiminde ilk adım risklerin tanımlanmasıdır ve riskleri ortaya çıkartmak için sormamız gereken ilk soru “Projenin planlanan zamanı aşmasına veya başarısız olmasına ne(ler) neden olabilir?” olmalıdır. Risklerin sınıflandırılması proje grubuna tanımlama sürecinde yol gösterebilir ancak sınıflandırma işleminin gerçekleştirilmesi de son derece uzun ve zahmetlidir. Bununle birlikte her türlü projede karşılaşılabilecek türden bazı risklerin gözden kaçırılması ihtimali söz konusudur. Software Engineering Institute’ın sınıflandırması, örneğin tasarım ve entegrasyon gibi internal proje risklerine odaklanmıştır ve iş gereksinimlerinin değişmesi, platform bağımlılıkları gibi external riskler neredeyse tamamen göz ardı edilmiştir. “Gerçek Projelerde Risk Kategorileri” bölümü bu tür external risklerin projeleri nasıl etkileyebileceğini ele almaktadır.

Risk tanımlamasında risklerin her an değiştiğini kabul etmeliyiz. Proje ekibinin herhangi bir plan yapmadığı riskler her an ortaya çıkabilmektedir. Microsoft Solutions Framework, risklerde meydana gelebilecek değişikliklere ve ortaya çıkabilecek yeni risklere karşı yöneticilerin riskleri sürekli olarak değerlendirmelerini öneren sayılı metodolojilerden biridir.

Risklerin yönetiminde tanımlamadan sonra gelen ikinci adım ise risklerin değerlendirilmesidir. Risk değerlendirmesi, proje ekibinin, proje hedeflerini belirlemesinin hemen sonrasında başlamalı ve tüm proje süresince sürmelidir. Proje ekibi riski tanımladıktan sonra aşağıdaki adımları izleyebilir:

Olası darbeyi öngörün: Riskin uygulamanın test edileceği platformun planlanandan iki hafta geç hazır olabilecek olması olduğunu varsayalım. Eğer ters öngörülen gecikme sürecinden önce başlamak zorundaysa darbe şiddetli olacaktır ancak test işlemini öngörülen gecikmenin sonrasına bırakabiliyorsak etkisi daha hafif olacaktır. Ancak altyapının kurulmasının dağıtım tarihinin sonrasına sarkması riski hala sürmekte ve dikkate alınmalıdır. Olası darbeye göre riskleri derecelendirin: Derecelendirme “yüksek”, “orta” ve “düşük” şeklinde olabilir. Riskin meydana gelme olasılığını hesaplayın: Bunun içinde “yüksek”, “orta” ve “düşük” şeklinde derecelendirme yapmak yeterli olacaktır. Kesin yüzdeler elde etmek ne zorunluluktur, ne de mümkündür. Risklerin bir arada ortaya çıkması durumunda olası darbeyi ve meydana gelme olasılıklarını derecelendirin:İzlenmesi gereken kombinasyonlar; yüksek etki – yüksek gerçekleşme olasılığı, yüksek etki – orta gerçekleşme olasılığı, orta etki – yüksek gerçekleşme olasılılığı, orta etki – orta gerçekleşme olasılığı dır. Major Riskler için olasılık planları yapın: Birden çok planınız, en azından her zaman için bir b ve c planlarınız olmalı. Abartıyor gibi görünebilirim ancak değeri milyon dolarlar ile ölçülen bir projenin başında olduğunuzda bu planları hazırlamaktan “zevk duyacağınızı” garanti ederim . Olasılık planları için kaynak gereksinimlerini belirleyin: Bu size her olasılık planınıız için yaklaşık maliyeti öngörebilme imkanı verecektir. Risk bilgilerini “Review Plan”’a ekleyin: Sonrasında sponsor ve development manager’lar ile iletişim kurabilirsiniz. Aynı zamanda olasılık planları ve bu planların maliyetleri ile ilgili bilgileri de ederek herkesin aynı noktada bulunmasını sağlayabilirsiniz. Riskleri proje süreçleri olarak izleyin: Bazı riskler tartışma konusu olabilir. Diğerleri ise daha nadir görülür veya olası etkileri hafifler. Önceki review sonrasında yeni riskler ortaya çıkabilir. Riskleri haftalık raporlarla izleyin. Böylece proje sürecinin tüm üyeleri gelişmelerden eş zamanlı olarak haberdar olur. Risk değerlendirme yaklaşımınızı düzenli olarak değerlendirin ve düzenleyin: Risk değerlendirme ve yönetiminizin etkinliğini gözden geçirmek için post-project toplantılarını kullanın. Süreçleri geliştirmek için mümkün olduğunca fazla feedback toplayın.</LI>

Proaktif Önleme
Önleyici risk yönetimi üç önemli alanda proaktif yönetim gerektirir: insan, süreçler ve kontrol sistemleri.

İnsan
Üçünün içinde insan en önemli etkendir. Eğer işbirliği içinde olmazlar ve birbirleriyle çalıışmak konusunda isteksiz olurlarsa, projeler genellikle başarısız olur. İncelediğim bazı projelerde; insanlar, daha iyi karar verebilme gücü, proglamlama ve risk yönetimi becerileri konusunda eğitilmesinin proje başarılarında oldukça yardımcı olduğu bilinmektedir. Bu beceriler, daha iyi karar verebilme ve daha iyi zamanlama gücünü doğurmaktadır; sonuç olarak 80 saatlik bir zaman dilimi kazanılmış ve stres seviyesi azaltılmıştır. Projeleri son günlerine kadar yetiştirme hedefi takım ruhunu yaratmış bu da insanların birbirlerine daha sabırlı olmasını ve problem çözmede daha istekli olmalarını sağlamıştır. Diğer bir yandan da projeleri son güne yetiştirmek için sürekli bir mücadele içinde olmak takım içinde kötü niyete neden olabilir. Stres artar, insanların birbirlerine daha az sabırlı olduğu gözlenir ve birbirlerine karşı daha az yardımcı olurlar. Herkes sadece projenin son gününe ve dağ gibi olmuş problemlere odaklanır ve yönetim projeyi tamamlamak için acil bir durum yaratana kadar herşey daha kötü gidecektir.

Süreçler
Prosesler aynı zamanda risk yönetimini etkilemektedir. Esnek, değişikliklere kolay adapte olabilen prosesler, proje ekibinin değişikliklere daha kolay yanıt vermesini sağlamaktadır. Bunlar olmadan, projeyi belirli bir izde tutmak son derece zordur. Eğer her gereksinim değişikliğini onaylamak için bir grup toplantısı gerekiyorsa ve bu toplantılar haftada sadece bir defa yapılıyorsa, proje ekibi yeni fikirleri nasıl deneyecek? Pek çok projede proje gruplarının, önceden belirlenmiş bir gereksinim üzerinde yaptığı çalışmaların tamamının, gereksinim değerlendirme toplantısı sonrasında gereksinimlerin değiştiğinin görülmesi üzerine boşa gittiğini, bununda motivasyonun bozulması başta olmak üzere pek çok olumsuz unsuru tetiklediğini görmekteyiz. Varolma nedenleri proje sürecinde faydası olmayan unsurları ortadan kaldırmak olan Exteme programming, feature-driven programming ve lean programming gibi agile metodları bu olumsuz etkilerden kaçınmamıza katkıda bulunurlar. Bu metodlar, gereksinim değişiklikleri ile birlikte çalışmak için düşük maliyetli yöntemler sunmaktadırlar. Detaylı gereksinim dokumanları yerine, uygulama geliştiriciler ve müşteriler arasında daha yakın iletişim kurarak gereksinimlerin net olarak yorumlanarak karşılanmalarını sağlarlar. Aynı zamanda birden çok versiyonun geliştirilmesini, böylece kullanılabilir kodun mümkün olan en kısa sürede kullanılabilir hale gelmesini önerir. Böylece kullanıcılardan, proje ekibinin daha verimli bir geliştirme süreci oluşturmalarına katkı sağlayacak feedbackler toplanabilmesini sağlar. Son olarak bu metodlar, otomatize edilmiş test senaryolarına odaklanarak bir sürümden sonraki sürüme kadar geçen süreçteki bug’ları sürekli olarak denetler. Özetle agile metodları gereksinimlerin çok hızlı değişebildiği durumlarda son derece iyi sonuçlar elde edilmesini sağlayabilmektedir.

Dinamik methodlar kullanılan yazılım projeleri daha başarılı ve daha kullanılabilir olmaktadır. Sürekli kullanıcı girişine ve çalışan yazılımın tekrar tekrar uygulanmasına odaklanılmasıgereksiz vakit ve güç kaybını engeller. Takım üyelerinin yakın etkileşimi, proje üstünde tüm takım üyelerinin payı olması anlamına gelir. Sorumlu olduğum bir projede yayınlarımız başka bir projenin yayınlarıyla aynı anda gelmiştir. Bu da, az çalışanı olan destek takımı için bazı problemler yaratmıştır. Bu çatışmayı bazı takım üyelerine ek destek sağlayarak ve yayın turunu değiştirerek çözdük 

Kontrol Sistemleri
Proje ekiplerinin, risk yönetimi de dahil olmak üzere projenin her bölümünü gözlemleyen ve ölçümlendiren bir mekanizmaya gereksinim duymalarından dolayı yönetim kontrol sistemleri oldukça önemlidir. Yeterli ve başarılı bir gözlem ve ölçümlendirme bir projeyi kurtarabileceği gibi, zayıf ve yetersiz yapılacak gözlem ve ölçümlendirme çalışmaları projelerin başarısızlığına neden olabilir. Pek çok proje sürecinde, proje ekibinin bir riski gözardı etmesine rağmen, kontrol sisteminin proje grubunu, çok geç olmadan risk için önlem almak zorunda bıraktığı durumlarla karşılaşıyoruz. Örnek vermek gerekirse bir projede firmanın professional-services ekibinin, yazılım grubunun bazı güvenlik varsayım ve önlemlerini sorgulaması, yazılım grubunun projenin bazı ilgili bölümlerini yeniden gözden geçirerek çeşitli değişiklikler yapmalarına neden olmuştu. Bir diğer proje sürecinde ise, firma üst yönetimi, proje sürecinde firmanın ürünlerinin uluslararası pazara sunulmasında yaşanan bazı problemlerden dolayı kaygı duymaya başlamıştı. Tüm proje ekipleri farklı tarih ve riskler raporluyordu. Tüm bunlar, üst yönetimin firmanın yapmaya çalıştığı şeye daha dikkatli bakmasını ve yapılanları daha detaylı yargılamasını tetikledi. Süreçler daha yakından izlendiğinde, tüm ekiplerin (pek çoğu doğru olmayan) farklı teknikler uyguladığı görüldü. Eğer yönetim bu uyumsuzluğu gözden kaçırmış olsaydı, harcanan tüm efor, para ve zaman boşa gitmiş olacaktı.

Şimdi proje süreçlerinde karşılaşabileceğimiz risk kategorilerine kısaca göz atalım..

Pek çok risk sınıflandırma yöntemi, projeleri ciddi anlamda etkileyebilecek dış riskleri gözden kaçırmaktadır. Aşağıdaki liste, günümüz projelerinde sıklıkla karşılaştığımız risk kategorilerini listelemektedir. Esnek bir geliştirme süreci, ilk üç kategorideki risklerin etkisini hafifletmeye yardımcı olmalıdır. Proje ekibinin gereksinimlerin tanımlanmasında, sistem tasarımlarının veya platformların düzenlenmesinde serbest kalması, ileride çeşitli riskleri beraberinde getirecek başarısız ortaklıkların çevresinde dönüp durmasına göre çok daha iyidir.

Gereksinimler: Belirsiz, netleştirilmemiş gereksinimler her zaman için projeler açısından risk anlamına gelmektedir. Bu en sık karşılaşılan ve başarısızlığa uğramış, gecikmiş projelerde yaşanan en temel problemlerden biridir. Rekabete koşulları ve yapılan yeni anlaşmalar her zaman için kurumların yazılım sistemlerinin değişmesi ihtiyacını ortaya çıkartmıştır. Kullanıcılar, ihtiyaç duydukları fonksiyonları sunan optimum yazılımı kullanana kadar akıllarında canlandıramazlar ve bu gereksinimlerin belirsiz ve değişikliğe açık olmasına neden olur.

Teknoloji: Geliştirme sürecinin bir noktasında (genellikle sürecin orta ve sonrasında kalan bölümlerinde) geliştirme grubu kullanılan teknolojinin sistem gereksinimlerini tam olarak karşılayamayacağını farkedebilir. Örneğin takım üyeleri kullandıkları veritabanı sisteminin kolay bir şekilde hasar görmeyeceğini düşünebilir ancak sistem geliştirildikçe kullanılan veritabanı sisteminin verilerin hasar görmesine neden olabilecek çeşitli hatalar içerdiğini farkedebilir ki bu noktada, böyle bir alanda yaşanacak değişiklik, proje için ölümcül olabilir.

İş:İş süreçlerinde verilen kararlar pek çok riski beraberinde getirebilir. Bir vendor ile yapılacak anlaşma, beklenen platformun oluşmasını sağlamayabilir veya projenin bir bölümünü veya proje için çeşitli kaynaklar sağlayan bir iş ortağı ile yaşanacak sorun projenin ilerleyişinin yavaşlamasına hatta sorunun ciddiyetine bağlı olarak durmasına dahi neden olabilir.

Politik: Bunları, üstesinden gelmesi en zor olan riskler olarak tanımlayabiliriz. Büyük organizasyonlar, büyük aileler gibi davranmaya mecburdur. Ancak pek çok nedenden dolayı ailenin bazı üyeleri, bütçenin kısıtlanmasına veya tamamen kaldırılmasına hatta projenin tamamen iptaline neden olacak adımlar atabilir. Bu tür durumlara karşı planlar hazırlamak, sonradan pek çok olumsuz sonuç doğurabileceğinden dolayı son derece zordur. Elbette yaptığınız karşı planların yine bu kişilerce öğrenilmesi, ayrı bir risk unsurudur.

Kaynaklar: Bir projenin ihtiyaç duyduğu insan, para veya donanım kaynaklarını alamaması belirlenen takvimin dışına çıkılmasına neden olduğu gibi, projede çalışanların moralinin kaybolmasına da neden olur. Her zaman için alternatif kaynakların belirlenmesi bu gibi sorunların ortadan kolayca kaldırılmasını sağlayacaktır.

Beceriler: </I>Bu riskler proje ekibinin kullanılacak teknoloji veya üzerinde çalışılacak iş süreçleri hakkında yeterli bilgi sahibi olmamasından kaynaklanırlar. Eksik kalan bilgi ve beceriler konusunda proje ekibine gerekli eğitimlerin verilmesi veya danışmanlık desteği sağlanması riskin ortadan kalkması için yeterli olacaktır.

Dağıtım ve Destek: Proje ekibi uygulamanın dağıtımını gerekli altyapının zamanında hazırlanamamış olmasından, destek ekibinin eğitim ve destek için hazır olmaması gibi nedenlerden dolayı planlanan zamanda deploy edemeyebilir. Deployment ekibinin proje ekibinin ve geliştirilen projenin yaptıklarıyla ilgili fikir sahibi olmaması, bu tür risklerin ortaya çıkmasına neden olan en genel unsurdur ve çok kolay bir çözümü vardır: proje sürecinde çalışacak tüm ekiplerin birbirleri ile iletişim içinde olmasını sağlamak.

Entegrasyon: Uygulama geliştiricilerin en sık karşılaştığı gereksinimlerden biri, geliştirilecek olan uygulamanın, farklı uygulamalar ile entegre çalışmasını sağlamaktır. Yetersiz iletişim ve yanlış anlaşılmalar yapılan çalışmaların sonunda uygulamaların bir arada beklenen şekilde çalışmaması ile sonuçlanabilir. Bu sorunu ortadan kaldırmanın en kolay yolu, yeterli iletişimi sağlamak ve mümkün olan durumlarda entegrasyon işlemini uygulamaların geliştirme sürecinde gerçekleştirmektir. 

Takvim ve Zamanlama: Çeşitli unsurların gerekli oldukları anlarda hazır olmamasından kaynaklanan takvim ve zamanlama sorunları proje maliyetine en fazla olumsuz katkıda bulunan konuların başında gelir. Bu tür sorunları yaşamamanın tek yolu doğru ve başarılı bir planlama süreci sonrasında tüm alt süreçleri gerçek zamanlı olarak izlemek ve takvimin dışına çıkılmasına neden olacak her durumun önüne geçilmesidir.

Bakım ve İyileştirme: Şirket dokumantasyonun yetersiz olması ve destek ekibinin yeterli hazırlığı yapmamış, gerekli eğitimleri almamış olması durumunda uygulamayı doğru olarak yönetemez, geliştiremez. Gerekli eğitimler ve dokumantasyon hazırlığı için gerekli zamanın planlanması bu tür riskleri ortadan kaldıracaktır. Esnek bir proje sürecinde, proje yöneticilerinin eğitim, dokumantasyon ve destek için yeterli iş gücünü, zamanı ve bütçeyi tahsis etmemesi, işlerin kötüye gitmesine neden olacaktır.<I> </I>

Tasarım: Hatalı tasarımlar uygulamaların kullanılabilirliğini ve performansını düşürecektir. Esnek bir geliştirme sürecinde kullanıcılardan alınacak feedbackler dikkate alınır ve bu feedbackler doğrultusunda tasarım iyileştirmeleri gerçekleştirilerek bu tür riskler ortadan kaldırılabilir.

Elbette bu gibi öngörülebilecek riskler söz konusu olduğu gibi, öngörmenin pek mümkün olmadığı ancak geliştirme sürecini aksatabilecek virüs saldırıları, şirket ofisine yapılacak bir saldırı (paranoya mı? J ) gibi pek çok durum söz konusu olabilir. Bu tür beklenmedik durumlarla başetmek için mümkün olduğunca paranoyak davranarak söz konusu olabilecek her türlü riski, gerçekleşme olasılığına bakmaksızın listelemek ve olası çözüm planlarını, en uygun back-up stratejisini hazırlamak en yerinde hareket olacaktır. (Bu konuda paranoyanın ulaştığı seviyeyi vurgulayabilmek adına bir bankanın uyguladığı back-up planından kısaca bahsedeyim. Banka ilk olarak bir şubesinin herhangi bir nedenden dolayı tamamen yok olması durumunda en az veri kaybını nasıl sağlayabileceğini, bunun bir adım sonrasında şubenin bulunduğu ilin yok olması durumunu, sonrasında şubenin bulunduğu ülkenin yok olması, son olarakta şubenin bulunduğu ilin bulunduğu ülkenin bulunduğu kıtanın yok olması durumunu hesaba katarak buna göre bir yedekleme ve geri yükleme stratejisi kurmuş durumda.. Sanırım bu uygulamanın yanında benim şirket ofisine saldırı olasılığını dikkate almam normal karşılanabilir.)

Beklenmedik riskler her zaman için projelerimizi tehdit etmekte ve önemli gecikmelere hatta başarısızlıklara neden olabilmektedir. Günümüz IT projelerinde doğru uygulanacak risk yönetimi, beklenmedik nahoş sürprizlerle karşılaşmamak için proje yöneticilerinin gözardı etmemesi gerek bir uygulama. Esnek proje süreçleri risklerin öngörülmesini, karşı planların hazırlanmasını ve uygulamaya konmasını kolaylaştıran proaktif risk yönetimini kullanmaktadır. Proje sürecine ihtiyaç duyulan esnekliği kazandırmanın yolu ise proje ekibinin becerilerinin arttırılmasından geçmektedir. Aynı zamanda projelerde en efektif planlama, ölçümleme ve paylaşımın gerçekleştirilebilmesi için en uygun kontrol & yönetim sistemlerinin kullanılması gerekmektedir. Buraya kadar ele aldığımız konular ve bunlara eklenebilecek pek çok madde ile birlikte proje süreçleri beklenmedik durumlara karşı daha hazır hale getirilerek projelerin en başta bahsettiğimiz istatistiklerde başarısız olarak tanımlanan projeler arasında yer alması önlenebilir.

Paylaş

Hide Sites

Veri odaklı projelerde en sık kullanılan nesnelerin başında DataSet ve DataTable nesneleri yer alıyor. Ancak çalıştığımız veriler ve yapılar arttıkça, bu nesnelerle verileri taşımak oldukça zahmetli olabiliyor.
Şu anda yürüttüğüm projeden bir örnek vererek durumu açıklamak istiyorum;

 
Grafikte gördüğünüz senaryoda A noktasındaki merkezi sisteme B, C ve D noktalarından veri aktarımı gerekiyor. Aktarılacak veri 100 MB ile 5 GB arasında değişiyor. C ve D noktalarındaki bağlantı metro ethernet olduğu için herhangi bir sorun yaşamıyoruz ancak B noktasına giden hat bir noktaya kadar fiberken, B noktasının lokasyonunun getirdiği bir zorunluluktan dolayı bağlantı PDH oluyor ve ciddi oranda yavaşlık ortaya çıkıyor. Veri çekmek istediğimiz B sistemini günün 24 saati 400 ayrı lokasyondaki client kullandığı için hat üzerindeki yük, hattın kaldırabileceğinin çok üzerinde kalıyor. Bu noktadan çekmek istediğimiz veri dataset olarak 4.2 GB civarında.

Bu senaryoya bakacak olursak, durumun vehametini açıkça kavrayabiliriz.
Bu noktada uygulayacağımız basit bir çözümle, bu dataset’in boyutunu ciddi oranda minimize edebiliriz.

Visual Studio 2005 ile birlikte gelen System.IO.Compression alan adı zip ve gzip sıkıştırma algoritmalarını sunmakta. Bu makalede, bu algoritmaları kullanarak bir dataset nesnesini nasıl sıkıştırıp, nasıl açabileceğimizi göreceğiz.

İlk olarak sıkıştırma fonksiyonumuzu yazıyoruz;

public static byte[] CompressDataSet(DataSet ds)
{
    ds.RemotingFormat = SerializationFormat.Binary;
    BinaryFormatter bf = new BinaryFormatter();
    MemoryStream ms = new MemoryStream();
    bf.Serialize(ms, ds);
    byte[] inbyt = ms.ToArray();
    MemoryStream objStream = new MemoryStream();
    DeflateStream objZS = new DeflateStream(objStream, CompressionMode.Compress);
    objZS.Write(inbyt, 0, inbyt.Length);
    objZS.Flush();
    objZS.Close();
    return objStream.ToArray();
}

İkinci aşamada sıkıştırmayı tersine çevirecek fonksiyonu yazıyoruz:

public static DataSet DecompressDataSet(byte[] bytDs, out int len)
       {
           System.Diagnostics.Debug.Write(bytDs.Length.ToString());
           DataSet outDs = new DataSet();
           MemoryStream inMs = new MemoryStream(bytDs);
           inMs.Seek(0, 0);
           DeflateStream zipStream = new DeflateStream(inMs, CompressionMode.Decompress, true);
           byte[] outByt = ReadFullStream(zipStream);
           zipStream.Flush();
           zipStream.Close();
           MemoryStream outMs = new MemoryStream(outByt);
           outMs.Seek(0, 0);
           outDs.RemotingFormat = SerializationFormat.Binary;
           BinaryFormatter bf = new BinaryFormatter();
           len = (int)outMs.Length;
           outDs = (DataSet)bf.Deserialize(outMs, null);
           return outDs;
       }

       public static byte[] ReadFullStream(Stream stream)
       {
           byte[] buffer = new byte[32768];
           using (MemoryStream ms = new MemoryStream())
           {
               while (true)
               {
                   int read = stream.Read(buffer, 0, buffer.Length);
                   if (read <= 0)
                       return ms.ToArray();
                   ms.Write(buffer, 0, read);
               }

           }
       }

Son olarak bu fonksiyonların kullanımını örnekliyoruz:

private DataSet _dataSet = new DataSet();
      private byte[] _compressedDs;
      private DataSet _deCompressedDs;

      private void button1_Click(object sender, EventArgs e)
      {
          DateTime start = DateTime.Now;

          byte[] compressedDs = CompressDataSet(_dataSet);
          File.WriteAllBytes("CompressedDataSetContent.txt", compressedDs);
          int i;
          _deCompressedDs = DecompressDataSet(compressedDs, out i);
          _deCompressedDs.WriteXml("DecompressedDataSet.xml");

          TimeSpan ts = DateTime.Now – start;
          MessageBox.Show(string.Format("{0}dk, {1}sn, {2}sl", ts.Minutes, ts.Seconds, ts.Milliseconds));
      }

Sonuçlara gelecek olursak, bu kodlarla sıkıştırdığımız 154.736 KB’lık bir dataset, 15 saniye gibi bir sürede  8.535 KB’ya düşüyor. Bu da senaryodaki gibi bir network ortamında oldukça önemli bir kazanım.

Paylaş

Hide Sites

Merhaba arkadaslar, bu makalemde sizlere .NET Compact Framework ve Mobile programlamayı anlatacağım. Örneklerde tahmin edeceğiniz üzere C# kullanacağım. VB’ciler için VB.NET ile de anlatmak isterdim ama VB’ye bir türlü ısınamadım. C# olduğu sürecede ısınabileceğimi pek düşünmüyorum.

Bildiğiniz üzere ülkemizde bilgisayardan çok cep telefonu kullanılmaktadır. Hazır önümüz 3G ve 4G iken mobile programlamada gelişen telefonlarla beraber popüler olacaktır. Bence Türkiye mobile yazılım alanda atılımlar yapmak için güzel bir yer ve şuan sektöründe bu atılımlara ihtiyacı var.

Kısaca şöyle bir mutfağamıza bakacak olursak;

Elimizde bir adet Visual Studio.NET 2008 var. Bunun yanında bolca C# ve .NETCF var. Şimdi bunları kullanarak güzel mobile uygulamalar çıkartacağız.

İlk olarak Yeni bir proje oluştur diyoruz ve açılan menüden Visual C# > Smart Device > Smart Device Project yolu ile yeni bir proje oluşturuyoruz.

Ilk basta vazgecilmez ornegimiz olan ”Hello World” yazarak baslamak istiyorum.Resimde de gordugunuz uzere bir adet button koyduk, ve button’un click eventinde ekranda bir messageBox kullanarak “Hello World” yazisini basacagiz.

private void button1_Click_1(object sender, EventArgs e)
        {
            MessageBox.Show("Hello World!");
        }

Gordugunuz uzere normal bir Windows Application gelistirmekten pek bir farki yok. Bu windows mobile applicaton development’a giris icin kucuk bir adim oldu Asil size bahsetmek istedigim konu ise Windows Mobile 6.5 uzerinde gelistirilebilen Widgetlar.

Bu test süreci birkaç aşamadan oluşmaktadır. Öncelikle widget için hazırladığınız dosyaları *.zip haline getirmeniz gerekmekte. Bir sonraki aşamada bu *.zip uzantısını *.wgt ya da *.widget olarak değiştirmeniz gerekmekte ve bu dosyayı emulatör üzerinde kopyalayıp (bu kopyalama işleminide emulatör ile paylaşımlı bir klasör üzerinden gerçekleştirebilirsiniz) gerekli kurumları yapmanız gerekmekte. Ayrıca bir önce test’ ten kalan kurulumunuzu kaldırmanız ve yeni halini kurmanız test’ i daha stabil kılmaktadır.

Her seferinde bu süreç can sıkıcı olabildiğinden geçen hafta tam ihtiyaç duyulan bir çalışmaya CodePlex üzerinde rastladım ; Windows Mobile Widget Emulator !

CodePlex üzerinde açık kaynaklı olarak gelişimine devam eden çalışma, kullanıcılara geliştirdikleri Windows Mobile Widget’ ları Emülatör’ e kurmaya gerek kalmadan "sanki mobil cihaz üzerinde çalıştırılıyormuş gibi" test imkanı sağlamaktadır.

Örneğin CodePlex üzerinden alınan yukarıdaki ekran görüntüsün, geliştirilen bir widget’ ın masaüstü ortamında Windows Mobile Widget Emulator ile çalıştırıldığı görülmektedir.

Peki Nasıl Kullanacağız ?

http://widgetemulator.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=31211 adresinden gerekli paketi indirdiğimizde aşağıdaki islemleri uyguluyoruz: assests klasörü uygulamanın çalıştırılabilmesi için gereken sistemsel dosyaları içermektedir. widgets klasörü "geliştirdiğimiz widget’ ı paketlemeden yerleştireceğimiz" bölgedir. index.htm ise widget’ ımızı test edeceğimiz standart bir HTML dosyasıdır.

Yukarıda da belirttiğimiz üzere geliştirdiğimiz widget’ ı "paketlemeden" widgets klasörü içerisine yerleştirmemiz gerekmektedir. Sadece bu kadar!

Windows Mobile 6.5 üzerinde geliştirilen widget’ larda yararlanılabilecek bir başka nokta ise bir önceki yazımızda ifade ettiğimiz “widget” javascript objesi üzerinden oluşturulabilecek SystemState objesidir. SystemState objesi vasıtasıyla geliştirdiğiniz widget’ lar içerisinden “bazı belirli” sistemsel özelliklerin değerlerine ulaşabilir, bu değerlerin değiştiğini algılayabilir ve istenilen kod bloklarını çalıştırabilmektesiniz. Aşağıdaki listede SystemState objesi üzerinden ulaşılabilecek değerlerin bir listesi listelenmiştir.

CradlePresent – Cihazın “cradle” (cihazın bilgisayarınız ile olan fiziksel bağlantısı) üzerine takılıp takılmadığının değerini döndürür.

DisplayRotation – Ekranın anlık görüntüsünün kaç derecelik bir açıyla gösterildiğinin değerini döndürür. (0 – 360 Derece Arası)

PhoneHomeService – Cihazın anlık network ile kayıtlı olup olmadığının değerini döndürür.

PhoneOperatorName – Cihazın anlık network (operatör) isim değerini döndürür.

PhoneRoaming – Cihazın anlık olarak “Roaming (Yurtdışında farklı bir operatör üzerinden bağlantı)” içerisinde olup olmadığının değerini döndürür.

PhoneSignalStrength – Cihazın operatör ile arasındaki bağlantı kalitesinin değerini yüzdelik olarak döndürür.

PowerBatteryState – Cihazın anlık batarya güç değerini düşük, güçlü, orta şeklinde tanımlı değerlerinin numerik karşılıklarını döndürür.

PowerBatteryStrength – Cihazın anlık batarya güç değerini yüzdelik değer olarak döndürür.

Bir sonraki makalemde sizlerle bu yukarida bahsetmis oldugum SystemState objelerini kullanaraktan Mobile Application gelistirecegiz.

Paylaş

Hide Sites

Unified Dimensional Model
İlk bölümlerde İş Zekası’nın sağlıklı karar verme sürecini desteklemek için nasıl kullanılabileceğine değindik. Sonrasında iş zekası’na kaynak olacak veriyi tanımladık ve çoğu durumda ihtiyaç duyduğumuz verilerin OLTP sistemlerde yer aldığını gördük.

OLTP sistemleri incelediğimizde, bu sistemlerin iş zekası için çok sağlıklı bir veri kaynağı olmadığını farkettik. OLTP sistemler gerçekleşen her işleme dair oluşan verileri saklamak için tasarlanmışlardır. Hesaplamalar yaparak özet veriler sunmak için optimize edilmiş bir yapıya sahip değillerdir.

OLTP sistemlerin iş zekası alanındaki yetersizlikleri bizi data mart yapısına yöneltti. Data mart yapısı, büyük miktarda tarihsel verilerin barındırılması için tasarlanmış bir ilişkisel veritabanı sistemidir. Data mart yapısını incelerken kullanıcıların büyük miktardaki tarihsel veri üzerinde çeşitli hesaplamalar yapmak isteyeceklerini ve bu hesaplamaların büyük miktardaki veriler ile yapılması durumunda ciddi bir performans sıkıntısının ortaya çıkacağını belirtmiştik ve cevabın Online Analytical Processing (OLAP) olduğunu  belirtmiştik.

Online Analytical Processing
İlişkisel veritabanı ve OLTP teorisinin yaratıcılarından E.F: Codd, 1993 yılında veri analistlerinin gereksinimlerine göre optimiz edilmiş yeni bir sistem fikrini sundu. Bu sistemi “Online Analytical Processing” kısaca OLAP olarak isimlendirdi. Codd tarafından ortaya çıkarılan fikir genel anlamda pek fazla kabul görmesede, OLAP ismi İş Zekası için tasarlanan sistemlerin genel adı olarak kullanılmaya devam etmektedir.

OLAP yapısı, kullanıcıların analiz esnasında veri ile etkileşim içinde olmasına izin verecek şekilde tasarlanmıştır. Kullanıcılar verileri bölümlendirebilir, gruplandırabilir, farklı görünümlerle analiz edebilir, dwill-down yaparak belirli bir veriyi oluşturan detay verilere ulaşabilir. Bu esnek ve gelişmiş yapı, OLAP yapısını sıklıkla kullanılan statik raporlardan ayırmaktadır.

OLAP yapısı kullanıcıların verilere hızlı ve kolay bir şekilde erişmesini sağlamak amacıyla tasarlanmıştır. Veriler genellikle bir data mart’ta saklanır. OLAP sistemi data mart içindeki verinin hızlı bir şekilde görüntülenmesi ve analizi için gerekli yapıyı sunar. OLAP sisteminde veriler measure, dimension, hierarchy ve cube unsurlarından oluşmaktadır.

Gerçekte OLAP sistemi daha önceki bölümlerde kısaca değindiğim küplere odaklanmıştır. OLAP yapısı ile ilgili teknik detaylara girmeden önce, küplere biraz daha değinmekte fayda görüyorum. Bu sefer ay, ürün ve satış sorumlusu bilgilerini dimension olarak kullanıyoruz. Ortaya çıkan küp aşağıdaki gibi görünecektir.

Gördüğünüz gibi grafikteki küp, üç boyutun kesişim noktasındaki veriyi yani Zeynepcan tarafından Temmuz ayında İstanbul 2010 Kültür Başkenti serisi ürününden yapılan satış miktarını göstermektedir.

Zeynepcan, satış sorumlusu, İstanbul 2010 Kültür Başkenti, ürün, Temmuz ise Ay boyutunun bir üyesidir. Bu üç boyutun kesişim noktasındaki satış verisi ise 16.702 TL’dir.

Kesişim noktasında okuduğumuz değer “detail” ya da “leaf-level” value olarak adlandırılır. Grafikte yer alan 16.702 TL verisi, üç boyutun kesişim noktasındaki değer olduğu için leaf-level value’dur. Zeynepcan’ın Temmuz ayındaki toplam satış verisine ulaşmak için Zeynepcan’ın Temmuz ayında sattığı tüm ürünleri bir araya getirmemiz gerekir. Bunu aşağıdaki grafikte görebiliriz:

Aynı aydaki tüm satış sorumlularının yaptığı tüm satışların toplamını elde etmek için başka bir hesaplama daha yapmamız gerekir. Bu sefer tüm satış sorumlularının yaptığı Temmuz ayı içinde tüm satışları bir araya getirmemiz gerekir.

Bu hesaplamaları aynı zamanda boyutların içinde hareket ederken de kullanırız. Satış sorumlularının gruplanabildiğini, bölgelere ayrılabildiğini, ürünlerin ürün gruplarında ve ürün türlerinde gruplanabildiğini, ayların ise çeyrek ve yıl içinde gruplanabildiğini hatırlayın. Bir hiyerarşinin seviyeleri içinde yukarı doğru yapılan her harekette, alt seviyeye ait verilerin bir araya getirilmesi ve gruplanması için hesaplamalar yapılır. Örneğin Zeynepcan’ın İstanbul 2010 Kültür Başkenti ürününde 1. Çeyrekte yaptığı satış verisi, Zeynepcan’ın bu üründe Ocak, Şubat ve Mart aylarında yaptığı satışların toplamıdır.

Küpler pek çok boyut ve pek çok hesaplama gerektiren hiyerşi içerebilir. Hiyerarşilerin sayısının ve seviyesinin artması, işlem hızımızı azaltacaktır. Bunun üstesinden gelebilmek için eldeki verilerin tümü (ya da bir kısmı) önceden hesaplanır. Saklanan bu verilere “preprocessed aggregates” ismi verilir.

Bir sonraki bölümde OLAP sisteminin özelliklerini, avantajlarını ve dezavantajlarını ele alıyor olacağız.

Paylaş

Hide Sites

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.

Paylaş

Hide Sites

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.

Paylaş

Hide Sites

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.

Paylaş

Hide Sites

5 – System.Net.Mail ile Mail Send

Merhaba arkadaslar, bugun sizlere ASP.Net uzerinden Mail gonderme islemi uzerine ornek yapacagiz. Gunumuzde E-Mail yapisi bilmeyen pek az insan vardir sanirim. E-Mail, dunya capinda Bireysel ve Kurumsal olarak kullanilan bir yapidir. Bireysel kullanimlara ornek vermek istersek eger cok yaygin olan mail servislerinden ornek verebiliriz (gmail,hotmail,yahoo gibi). Kurumsal kullanimlarda genelde Microsoft Exchange Server tercih edilir. Exchange serverdan bahsetmek isterdim ama off topic olmamak adina bahsetmesem iyi olur. Gelelim mail gonderme islemini kendi yarattigimiz bir .aspx veya Windows Application uzerinden yapmaya. 2 yapi arasinda pek bir fark oldugu soylenemez acikcasi. Oncelikle bu islemi yapabilmek icin sahip oldugunuz mail adresinizi bir takim bilgilerine ihtiyac duyarsiniz. SMTP, Incoming – Outgoing adresleri gibi. Kendinize ozel bir isim hakki ve domaininiz var ise bu is daha kolay tabi. Ornek vermek gerekirse sahip oldugum www.serkanhekimoglu.com ismi, ve barindirdigim serverimin saglamis oldugu avantajlar dogrultusunda kendi alan adim uzantisinda mail adresi olusturabiliyor. (serkan@serkanhekimoglu.com) gibi. Incoming ve Outgoing bilgilerimde haliyle mail.serkanhekimoglu.com oluyor. Gelelim simdi bunu form uzerinde nasil yapacagimiza.

Isleme baslamak icin bir adet .aspx sayfasi olusturalim, ve .Net’in mail gonderme yapisini kullanabilmek icin gerekli referanslari ekleyelim :

using System.Net.Mail;
using System.Net;

Mail gonderim sirasinda ki islemi basitce dusunecek olursak eger, Mesajimiz, gonderen, alici, konu, ve ana mesajdan olusur. Bunlara ek olarakdan CC, BCC, veya Attachment gibi olaylarda mevcuttur. Dolayisiyla bu degerleri cekebilecegimiz textBoxlari .aspx sayfamiza ekleyelim. Ve gelen kod kismina:

MailAddress From = new MailAddress(txtEmailAddress.Text.ToString(), 

                       txtName.Text.ToString() + " " + 

                                   txtSurname.Text.ToString());
        MailAddress To = new MailAddress("serkan@serkanhekimoglu.com");
        MailMessage Email = new MailMessage(From, To);
        Email.IsBodyHtml = true;
        Email.Subject = "Message From Serkanhekimoglu.com";
        Email.Body = txtMessage.Text.ToString();
        SmtpClient MailClient = new SmtpClient();
        MailClient.Host = "mail.serkanhekimoglu.com";
        MailClient.UseDefaultCredentials = false;
        MailClient.Credentials = new 

        NetworkCredential("serkan@serkanhekimoglu.com", "MAILSIFRENIZ");
        MailClient.Port = 26;
        MailClient.Send(Email);

MailAddress’i biraz kurcalayacak olursaniz CC ve BCC gibi ozellikleride gorebilirsiniz. Burda sorun yaratabilecek tek sey Mail’in cikis port’u olabilir. Default port kullanilir veya manuel olarak cikis portu belirtilebilir. To kismini ister textbox’tan okursunuz ister kendiniz default bir mail adresi set edersiniz. (sekildeki gibi)

Paylaş

Hide Sites

Ö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.

Paylaş

Hide Sites