YazGeliştir Blogs

Sql Server Management Studio - IDEnizi Daha Hızlı Kullanın

Cem SISMAN — Fri, 27 Apr 2007 13:50:00 GMT

Treeview üzerinde databaseleri , tabloları dolaşırken Management Studio'nun size daha hızlı cevap vermesini isterseniz aşağıdaki yolu izleyin.

Bu sayede Summery tabını da kapatmış, IDEnize fazladan iş yükü bindirmemiş olacaksınız.

Enterprise Library 3.0 - April 2007 Released

Cem SISMAN — Fri, 06 Apr 2007 09:43:00 GMT

Enterprise Library 3.0 yayınlandı.

Validation Application Block.
Policy Injection Application Block.
Application Block Software Factory.
Visual Studio-integrated Configuration Editor.
Environmental Overrides.
WCF Integration.
Pre-compiled, strong-named binaries.

download : http://msdn.microsoft.com/entlib

Microsoft Visual Studio 2005 Service Pack 1 (SP1)

Cem SISMAN — Wed, 03 Jan 2007 18:49:00 GMT

Visual Studio 2005 Team Suite Service Pack 1
http://www.microsoft.com/downloads/details.aspx?FamilyID=bb4a75ab-e2d4-4c96-b39d-37baf6b5b1dc&displaylang=en

Visual Studio 2005 Team Foundation Server Service Pack 1
http://www.microsoft.com/downloads/details.aspx?FamilyID=a9ab638c-04d2-4aee-8ae8-9f00dd454ab8&DisplayLang=en

Visual Studio 2005 Express Edition Service Pack 1
http://www.microsoft.com/downloads/details.aspx?FamilyID=7b0b0339-613a-46e6-ab4d-080d4d4a8c4e&DisplayLang=en

Visual Studio 2005 Service Pack 1 Update For Windows Vista Beta
http://www.microsoft.com/downloads/details.aspx?FamilyID=fb6bb56a-10b7-4c05-b81c-5863284503cf&DisplayLang=en

Execution planlarında da xml!..

Mustafa Acungil — Sun, 10 Dec 2006 15:39:00 GMT

Şaşılacak bir şey değil tabii, Office 2007'de artık word, excel dosyalarınız bile xml olarak kaydediliyor.

SQL Server 2005'de de artık execution planları sqlplan uzantısıyla xml olarak kaydetmek mümkün. Böylelikle mesela bu xml dosyasını tartışmak üzere bir arkadaşınıza mail atabilir, ya da bir indexten önceki ve sonraki execution planları arşivleyebilirsiniz. sqlplan uzantılı bu dosyaları SQL Server Management Studio'da istediğiniz zaman açıp -sorgu içinde geçen tablolara ya da veritabanına ihtiyaç olmaksızın- inceleyebilirsiniz.

Ne diyim, güzel olmuş! : )

Not: Üstelik bilgi zenginliği açısından xml olarak alınan planlar, en iyileri. Örneğin, planın büyüklüğünü (CachedPlanSize), planın hangi parametre değerleri için optimize edildiği (!) (ParameterList) gibi bilgileri sadece xml olarak alınan planlar veriyor. (SET SHOWPLAN_XML ON, SET STATISTICS XML ON... İlki tahmin, ikincisi gerçekleşeni almak için.)

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Execution planlarında da xml!..

Mustafa Acungil — Sun, 10 Dec 2006 14:38:00 GMT

Şaşılacak bir şey değil tabii, Office 2007'de artık word, excel dosyalarınız bile xml olarak kaydediliyor.

Ne diyim, güzel olmuş! : )

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Her outer join outer join midir?

Mustafa Acungil — Sun, 10 Dec 2006 14:37:00 GMT

Elinizin altında bir AdventureWorks veritabanı varsa, aşağıdaki iki sorgudan oluşan scripti çalıştırın. Ama çalıştırmadan önce, SQL Server Management Studio'nun sorgu ekranında "include actual execution plan" düğmesini tıklayın. Böylece sorgu sonucunuzun yanısıra bir sekmede execution plan görüntülenecektir. İşte script:

use AdventureWorks

SELECT C.CustomerID, COUNT(O.SalesOrderID) AS NumOrders

FROM Sales.Customer AS C

LEFT OUTER JOIN Sales.SalesOrderHeader AS O

ON C.CustomerID = O.CustomerID

WHERE C.Territoryid = 10

GROUP BY C.CustomerID

HAVING COUNT(O.SalesOrderID) > 5

ORDER BY NumOrders;

use AdventureWorks

SELECT C.CustomerID, COUNT(O.SalesOrderID) AS NumOrders

FROM Sales.Customer AS C

LEFT OUTER JOIN Sales.SalesOrderHeader AS O

ON C.CustomerID = O.CustomerID

WHERE C.Territoryid = 10 and (O.SalesOrderID > 0 or O.SalesOrderID <= 0)

GROUP BY C.CustomerID

HAVING COUNT(O.SalesOrderID) > 5

ORDER BY NumOrders;

İki sorgu, where satırındaki and (O.SalesOrderID > 0 or O.SalesOrderID <= 0) koşulu hariç tamamen aynı.

Execution planları incelediniz mi? Aralarındaki en önemli fark, ilk sorguda outer join yapılırken ikincide inner join yapılmış olması.

Where'e eklediğiniz koşul, sağ tablodan null değer dönmesini engelliyor. Left outer join'le inner joinin tek farkı ise, sağ tabloda karşığılı null olan satırların da sonuca dahil olmasıdır. Yani ikinci sorguda siz outer yazsanız da, pratikte bir inner join istemiş oluyorsunuz. Siz bunun farkında değilken, SQL Server fark edip gerekli optimizasyonu yapıyor.

Aferin sana zeki şey! : )

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Küme bazlı mı satır bazlı mı?

Mustafa Acungil — Sun, 10 Dec 2006 14:36:00 GMT

Veritabanı ile uğraşıyorsanız ve küme bazlı işlemlerle satır bazlı işlemler üzerine (ya da set based operations vs cursors) kafanız karışmışsa, olayı gözünüzde tam canlandıramıyorsanız, elinizin altındaki bir veritabanında şu sorguyu çalıştırın, hatta çalıştırmadan önce düşünün ne olacağını, tahminde bulunun, sonra çalıştırıp görün:

Create table islemlerKumeli (TId int identity(1,1), Turkce char(5), English char(5))

insert into islemlerKumeli (Turkce, English) values ('bir', 'one')

insert into islemlerKumeli (Turkce, English) values ('iki', 'two')

insert into islemlerKumeli (Turkce, English) values ('üç', 'three')

select * from islemlerKumeli

update islemlerKumeli set Turkce = English, English = Turkce

select * from islemlerKumeli

Nasıl? İlginç, değil mi?

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

SQL 2005'ten küçük bir yenilik

Mustafa Acungil — Sun, 10 Dec 2006 14:35:00 GMT

Diyelim ki işlemleri tuttuğunuz bir tablonuz var SQL Server'da. Bir sorguyla her yılın işlem sayısının toplamını, bu işlemlerin gerçekleştiği yılı ve vergilendirilecekleri yılı vermeniz gerekiyor. Vergilendirme yılı da her zaman işlem yılını takip eden yıl.

Bu durumda, şu sorgu işinizi görecektir:

SELECT Count(*), year(transactiondate) as [İşlem Yılı], year(transactiondate) + 1 as [vergilendirme Yılı]

from production.transactionhistory

group by year(transactiondate)

Ama eğer SQL Server 2005 kullanıyorsanız! SQL Server 2000, gruplanmış bir kolon üzerinde işlem yapmanıza izin vermez. [year(transactiondate) + 1]

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

NULL: Dikkat, ısırır!

Mustafa Acungil — Sun, 10 Dec 2006 14:34:00 GMT

Bir veritabanı tasarlıyorsanız, değerini bilemediğiniz hücrelerin nasıl davranacağına da kafa yormanız gerekir.

Normalde yazılımda, bir mantık ifadesinin karşılığı True ya da False'tur. Oysa veritabanında durum böyle olmaz. True, False yanısıra bir de Unknown durumu vardır. Doğru, yanlış, bilinmeyen...

Bir sınıftaki öğrencilerin boy bilgilerini tutan basit bir tablo düşünün. Öğrencilerin boylarını ölçüp tabloya giriyorsunuz ama ölçümü yaptığınız gün iki öğrenci yoktu. Bu durumda boylarına 0 girerseniz, olmaz. Bir değer giremeyeceğiniz için bu kolonda NULL'e izin vermeniz gerekecek. Yani bilinmiyor demiş olacaksınız.

Ne yapmış oluyorsunuz?

Bu iki kaçak öğrenciden birinin boyunu sınıftan bir başkasıyla karşılaştırırsanız, sonuç NULL döner. (Veritabanı ANSI opsiyonlarında değişiklik yapılmışsa geri dönüşünde farklılıklar olabilir, hata vermek ya da NULL dönmek gibi.)

Peki kaçak iki öğrencinin boyunu birbirleriyle karşılaştırırsanız? Yine NULL döner. Bu da beklenen bir şey. Ama ya boyu 170'den fazla olanları, bir de 170 ya da altı olanları iki ayrı sorguda sorgularsanız ne olacak? İki kaçak öğrencimizin sonucu her iki sorguda da yer almaz. Sadece boyu bilinenleri esas alır iki sorgunuz. Çünkü NULL hiçbir şeyden büyük de değildir, küçük de değildir, hiçbir şeye eşit de değildir.

Peki, kolonda bir CHECK kısıtınız varsa ne olacak? Bu durumda da (eğer kolonda NULL'e izin verdiyseniz) NULL'le karşılaştırma doğru dönecek.

Kaçak iki öğrencinin boylarının birbirine eşitliğini bir WHERE koşulunda test edersek, bilinmez değil FALSE gibi işlem görür. Oysa boy kolonunda bir unique index oluşturursanız, bu sefer de NULL bir değermiş ve iki satırda NULL olması birbirlerine eşitmiş gibi yorumlanır ve birden fazla NULL değere izin verilmez.

Kafanız karıştı değil mi? Amaç buydu zaten. NULL karışık bir konudur. Kurallarını öğrenirsiniz, biraz alışınca bunlar doğal da gelir, ama gerçek hayatta durum asıl karışıklığıyla ortaya çıkar. Milyonlarca satırınız varsa, bunlarla ilgili binlerce satır TSQL kodunuz çeşitli yerlerde çalışıyorsa, NULL'leri nerede nasıl ele aldığınızı hatırlamak ve takip etmek son derece zorlaşabilir.

NULL'lere dikkat edin! Dikkat etmezseniz, ısırırlar!

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

İş Zekası çözümleri yaygınlaşıyor

Mustafa Acungil — Sun, 10 Dec 2006 14:32:00 GMT

1991?de dünyanın en ?süper bilgisayarı? 40 milyon dolarlık bir maliyete sahipti. 7 yıl geçip 1998?e geldiğimizde aynı performansı 1 milyon dolarlık bir süper bilgisayarla elde edebiliyordunuz. 2005?te ise, 4 düğümlü bir clusterla aynı performansı 4 bin doların altına satın alabiliyordunuz.

Donanım yeteneklerinin gelişmesi ve ucuzlamasıyla birlikte kullanılan araçların ucuzlaşıp yaygınlaşması ve iş zekası alanındaki bilgi birikiminin artmasıyla, iş zekası uygulamaları artamaya başladı. Öyle görünüyor ki, çok yaygınlaşması için aşması gereken kritik eşik de yakınlarda. Gartner, yaptığı araştırmaların sonucunda, geçen seneye kadar en fazla yatırımı güvenlik alanına yapan IT yöneticilerinin bu seneden itibaren en çok İş Zekası uygulamalarına yatırım yapacaklarını belirttiklerini açıkladı.

Bir iş zekası çözümünü hayata geçirebilmek, standart bir veritabanı uygulamasını kullanıma almaktan çok daha zor. Kurumun en üst seviyelerinden destek görmeyen iş zekası uygulamaları büyük sıkıntılar yaşıyorlar. Ama öte yandan bütüncül bir şekilde iş zekası kullanmaya başlayan kurumların ve sektörlerin maliyetleri düşüyor, satış olasılıkları artıyor. Perakende, ulaşım, telekomünikasyon gibi öncü alanlarda, iş zekası uygulamalarını hayata geçiren kurumlar, günlük yaşantımızı değiştiren gelişmeler sağlıyorlar.

İyi haber, Microsoft?un İş Zekası alanında yapmaya başladığı atılımlarla, orta ölçekli kurumların da bu teknolojinin nimetlerinden makul yatırımlarla yararlanmaya başlayabileceği.

Bir iş zekası çözümü oluşturmak için kullanılması gereken temel hizmetlerden olan OLAP sistemi ve ELT sistemi, Microsoft SQL Server?la birlikte ücretsiz olarak sunuluyor Microsoft tarafından. OLAP için Microsoft SQL Server Analysis Services ve ELT (Extract Transform Load) için SQL Server Integration Services.

SQL Server 2000?de bile OLAP pazarında önemli bir pazar payı yakalayan Microsoft, bu alanda büyümeye devam ediyor. Hem Gartner hem de International Data Corporation?a (IDC) göre, Microsoft İş Zekası alanında rakiplerinden çok daha hızlı büyüyor. Gartner?a göre 2005?de Microsoft?un sağladığı büyüme % 35.9. Üstelik Microsoft?un çok iddialı ürünü SQL Server 2005 Aralık?a kadar piyasaya sürülmemişti. IDC?nin verilerine göre aynı dönemde Microsoft?un bu alandaki büyüme oranı % 25.5. Endüstrinin genel büyüme oranı ise % 11.5.

Microsoft?un bu alanda iddialı olduğunun bir başka göstergesi ise, istemci uygulamalarında önde gelen iş ortağı ProClarity?yi satın almış olması. Yakın zamanda istemci tarafıyla ilgili olarak da kendi ürünüyle piyasada olacak Microsoft. Excel ise zaten Microsoft?un OLAP küplerine bağlanarak analiz yapmada çok yoğun olarak kullanılan bir aracı.

Microsoft şu an sektörde dördüncü. Onun önünde yer alan üç kurum ise, Business Objects, SAS ve Cognos.

Microsoft seçeneğinin en önemli iki avantajı var:

- Lisans ücretlerinin ve ileride muhtemelen iş yapabilir nitelikte uzmanların daha uygun maliyette olması.

- Son derece kullanıcı dostu araçları olması ve bunların altyapıda yer alan SQL Server ve diğer Microsoft araçları ile birlikte iyi çalışması.

Bu araçlardan birisi olan SQL Server Integration Services?tan biraz bahsedelim. SSIS, SQL 2000?de kullanılan DTS?in yerine yazılmış bir bileşen. Yeni versiyonu diyemiyorum çünkü gerçekten baştan inşa edilmiş.

DTS, SQL Server kullanıcılarının % 70?i tarafından kullanılan bir araçtı. SSIS ise DTS?den çok daha başarılı.

En önemli özelliklerinden birisi, SSIS?in bellek kullanımının çok iyileştirilmiş olması. Pek çok işlemi, bellekte, data transformasyon işlemlerini ard arda değil bir akış şeklinde gerçekleştiriyor. Üstelik daha önce kolay yapılamayan pek çok şey, artık hazır bileşenler halinde sunuluyor. DTS kullanırken script yazarak yaptığınız pek çok şeyi, artık sadece görsel bileşenler kullanıp bunların özelliklerini ayarlayarak kotarabiliyorsunuz.

SSIS?le geliştiribileceğiniz çözümlerle büyük işler yapabilirsiniz. Biz çok karmaşık konulara girmeden, sadece hazır gelen bileşenlerle neleri kolayca yapabileceğinize birkaç örnek verelim.

Audit görevini kullanarak, veri akışınıza yaygın olarak eklediğiniz bazı bilgileri kolayca ekleyebilirsiniz.

Conditional split görevini kullanarak, bellekteki bir veri akışını, belirlediğiniz bir koşula göre farklı akışlara kolaylıkla bölebilirsiniz. Bunun için kod yazmanıza gerek yok. Sadece bölmenin mantığını ifade eden deyimi yazmanız gerekecek.

Import column ve export column görevlerini kullanarak dosyalarınızı, resimlerinizi kolaylıkla dosya sisteminden veritabanına ya da veritabanından dosya sistemine aktarabilirsiniz.

Fuzzy Lookup görevini kullanarak mesela il isimlerini koyduğunuz referans bir tablo yardımıyla, milyonlarca satırlık bir akışınızdaki il alanında girilmiş değerleri otomatik kontrol ettirebilirsiniz. İzmir yerine yazılmış Izmir?leri, İzmır?leri, Izmır?leri, İsmir?leri sizin için ayıklamak gibi, konuyla uğraşmış olanların kulağına inanılmaz tatlı gelecek bir işi kolaylıkla yapabilirsiniz.

Fuzzy Grouping görevini kullanarak tanımadığınız bir veri akışındaki bir kolonun olası değer seçeneklerinin neler olduğunu gruplatabilirsiniz. Basit bir distinct sorgusundan öte, birbirine yakın olan yanlış girilmiş ifadeleri sizin için gruplayıp öneride bulunacaktır.

Pivot ve unpivot görevlerini kullanarak denormalize edilmiş verileri normalize edebilir, ya da normalize edilmiş verileri denormalize edebilirsiniz.

Lookup görevini kullanarak, referans tablolarına bağlantı kurup buradan ilgili bir ya da birkaç kolonu veri akışınıza katabilirsiniz.

Sort görevini kullanarak bellekte sıralama yaptırabilirsiniz.

Slowly Changing Dimension görevini ve sihirbazını kullanarak, tarihçesini tutmanız gereken verileri yönetebilirsiniz.

Üstelik tüm bunlar, seçeneklerden sadece bazıları...

SQL Server lisansınız varsa, SSIS bileşenini inceleyin. Kesin bir işinize yarayacaktır.

DTS paketleriniz varsa, SSIS?in temel yaklaşımını öğrendikten sonra, bunları SSIS?te yeniden planlayın. Paketlerinizin ne kadar basitleştiğini ve hızlandığını görüp şaşıracaksınız.

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Kod, şifre, parola, şifrelemek

Mustafa Acungil — Sun, 10 Dec 2006 14:28:00 GMT

Bazı kitapların tercümelerini okumak çok zor oluyor. İngilizcesinden okusam daha iyi anlayacağım kitaplar var.

Tabii ki bunun böyle olmaması gerekir. Ama kitabın ilgili olduğu konuyu çevirmenden daha iyi biliyorsanız, çevirmenin yaptığı iş en azından konuyla ilgili bir editörün elinden geçmediyse, bazı kitapları okumak acı verici olabiliyor. Robert Slater'ın yazdığı Microsoft'un Yeniden Doğuşu'nu okurken de bunları hissettim. Büyük Mavi'yi Kurtarırken adlı kitabını, Türkçe çevirisinden çok beğenerek okumuştum. Slater'ın tarzının çok akıcı olduğunu biliyorum. Üstelik bu yeni kitabının konusu da benim için son derece ilgi çekiciydi. Çok yakından ilgili olduğum bir kurum olan Microsoft'un tekelleşme odaklı davası sürecinde ve sonrasında yaşananları anlatıyordu. Ama ah o kelimeler...

Kod yazmak, şifrelemek olarak çevrilemez. İngilizce'deki code ve coding, Türkçe'de kod ve kod yazmak olarak çevrilebilir. Türkçe'de kod kelimesinin kazanmış olduğu şifreyi çağrıştıran anlam yüzünden, Bill Gates'in en son 1983'te şifreleme yaptığını yazan bir cümle kuruyorsanız, siz bu alanda çeviri yapacak yeterlilikte değilsiniz demektir. Ya da en azından çevirinizin konunun uzmanı birinin elinden geçmesi gerekir.

Kitap çok güzel, çeviri berbat! Çeviriyi yapan kişini hakkını yemeyeyim. Bence burada asıl sorumlu yayınevi... Ya da editörlük kurumunun yurdumuzda yeterince gelişmemiş olması.

Bu kitapta geçmese de bağlantılı ve yaygın olarak kullanılan bir başka hatalı kelime geldi aklıma: Parola yerine şifre. Yazılımdaki kod yerine şifre kullanımı hatası gibi, kullanıcı ismi ve paroladaki parola yerine de şifre kullanılıyordu bir dönem. Sanırım bu yanlışlık artık bir hayli azaldı.

Öldük size kaldı herşey başlıklı bir şiirim vardı, henüz yayınlamadım. Orada iki mısra şöyle:

"Kelimeler, kelimeler hele de ah illa kelimeler

Öldük size kaldı herşey"

Kelimelerimiz olmasa naparız? Onların böyle yanlış şekillerde, yakışmayan biçimlerde, kafaları gözleri yarılmış olarak kullanılmalarını görmek ne kadar acı!

Öte yandan ne güzel bir nehir gibi akan cümleler içinde onların sesini dinlemek.

Sizi seviyorum kelimelerim. Ve ey dilim, Türkçem, belki en çok da seni!

Kelimeler, kelimeler, hele de ah illa kelimeler...

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Veri Madenciliği: Bilim mi bilişim mi?

Mustafa Acungil — Sun, 10 Dec 2006 14:27:00 GMT

İş zekası çözümleri içinde belki en az anlaşılanı veri madenciliği. Çokça kişinin dilinde olan ama öyle çok fazla da anlaşılmayan bir konu.

Temel zorluklarından birisi, farklı disiplinlerle ilgili yönleri bulunması.

Veri madenciliğini gerçek anlamda yapabilmek için devasa veri havuzlarını değerlendirebilecek işleme ve saklama kapasiteleri gerekiyor. Bu tür kapasiteler yeni yeni yaygınlaşabilecek fiyat seviyelerine inmiş durumda.

Öte yandan çalışacak uygulamaların gerekli yetenekleri kazanması da zamanla mümkün oluyor.

Hem araç gereç hem de teknik donanımın yeni yeni yaygınlaşmaya başlaması yüzünden, veri madenciliğiyle ilgililenme lüksüne yakın zamana kadar çok az kişi sahip oldu.

Ama araç gereç ve imkan bolluğu da veri madenciliği için yeterli değil. İş zekasını kurgulamak zor bir iş olsa da veri madenciliğine göre nispeten daha kolay. Çünkü veri madenciliğinde teknik yeterlilikten başka yaratıcı ve bilimsel disipline sahip zeka da gerekiyor. Devasa veri havuzlarında desenler tespit edebilmek için, kaba güç analizlerine başvurmak akıllıca bir yöntem değil. Bunun yerine, daha küçük analizlerle hipotezler geliştirmek ve bu hipotezleri test etmek gerekiyor.

Yaratıcı veri madenciliğine örnekler açısından Malcolm Gladwell'in 'Blink' adlı kitabını okuyabilirsiniz. İşin ilginci, bu kitapta temel yaklaşım, anlık karar verebilme yeteneği üzerine kurgulanmış. Kitapta anlatılan pekçok vaka temelde veri madenciliğinin başarılı örnekleri olarak da okunabilir. Ama bu paralel okuma, yazarın asıl vurgulamak istediği kanal değil. İş zekası konusuna özel ilgim olduğu halde, ben de okurken veri madenciliği örnekleri okuyor olduğumu algılayamadım aslında. Ama kitabı bitirdikten birkaç hafta sonra, arka planda bilinç altım bu ilişkiyi kurdu.

Göğüs ağrılarından şikayetçi bir hastanın, kalp krizi geçiriyor ya da geçirmek üzere olduğunun anlaşılmasına ilişkin geliştirilmiş bir test mekanizmasını anlatıyor bir bölüm. Onlarca yıllık deneyime sahip doktorların birinci elden teşhislerine göre daha başarılı sonuçlar vermesi çok ilginç. Çok az veriyi inceleyen bu test mekanizması, tam da bahsettiğimiz gibi çarpıcı bir zekanın oluşturduğu bir hipotezin uzunca süre denenmesi sonucu ortaya çıkmış. Yani az veri ile önce bir hipotez geliştirilmiş, sonra da bu hipotez daha geniş veri havuzunda uzunca süre çalıştırılarak geçerliliği ispatlanmış.

Bir diğer örnek de, 20 dakikalık sıradan konular üzerinde eşler arasında yapılan konuşmaların analizi ile, evliliklerinin geleceğinin tahmin edilmesine ilişkin. Burada da görece kısacık bir süre değerlendiriliyor ama arkada yıllara dayanan bir veri madenciliği çalışması ve bunun sonucunda oluşturulmuş bir desen analizi var.

Veri madenciliği ile ilgileniyorsanız, bu kitabı okuyun. Ama yazara kaptırmayın kendinizi (çok akıcı bir kitap yazmış), veri madenciliği bakış açısıyla hareket ettiğinizi unutmadan okuyun.

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

READ_COMMITTED_SNAPSHOT ve SNAPSHOT ISOLATION LEVEL

Mustafa Acungil — Sun, 10 Dec 2006 14:26:00 GMT

Oracle kökenli olup şimdi SQL Server yöneten ya da SQL Server da yöneten DBA'ler SQL Server 2005'le gelen bu iki özelliğe bayılacak.

READ_COMMITTED_SNAPSHOT bir veritabanı opsiyonu. Seçilince tüm veritabanında geçerli oluyor. Veritabanında çalışan SELECT'lerin paylaşılan kilit koymamasını, bunun yerine çalıştırıldıkları andaki satır bilgilerini satır versiyonlarına güvenerek okumasını sağlıyor.

SELECT'ler paylaşılan kilit koymadıkları için UPDATE'ler onları beklemek zorunda kalmıyor. SELECT'ler de okudukları datanın tutarlı olması için değiştirilmiş satırların kendileri başladığı handaki orijinal halini okuyorlar. Performans açısından hoş, ama bence daha önemlisi, Oracle kökenli DBA ya da programcıların alışık olduğu bir davranış modelini SQL Server tarafında gerçeklemesi.

SNAPSHOT ISOLATION da aynı çalışma şeklini transaction bazında getiriyor. Transaction isolation levelını böyle seçerseniz, ilgili transaction içinde SELECT'lerin davranışı tarif ettiğim şekilde gerçekleşiyor.

Oracle kökenliler konuyu hemen anlamıştır. SQL Server kökenli olup konuyu karışık bulanlar daha detaylı açıklama isterlerse yorum ekleyerek sorularını sorabilirler.

Not: SNAPSHOT ISOLATION kullandığınızda, SELECT'lerin gördüğü veri versiyonu kendilerinin çalıştırıldıkları an değil, transactionın ilk başladığı andır.

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

SQL Server 2005'te UNSAFE assemblyler

Mustafa Acungil — Sun, 10 Dec 2006 14:24:00 GMT

SQL Server 2005'te .net kodu yazabiliyorsunuz.

Bunu yapmaya başlamak için SQL Server'ın CLR'ını aktif hale getirmeniz yeterli. Oluşturduğunuz assembly'leri güvenlik açısından 3 seviyede ayarlayabilirsiniz:

SAFE

EXTERNAL_ACCESS

UNSAFE

UNSAFE'le ilgili bir şeye dikkatinizi çekmek istiyorum. UNSAFE olarak işaretlenmiş bir kodun, bellekteki erişimleri CLR tarafından denetim altında tutulmaz. Güvenlikle ilgili 3 temel açık olan buffer overrun, sql injection ve cross-site scripting'ten buffer overrun'a kapı açmış olursunuz bu durumda.

Veritabanı gibi hassas bir uygulamanın bellek alanını tehlikeye açık hale getirmek, pek tavsiye edilebilecek bir durum değil. Dikkat!

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Cross Database Ownership Chaining

Mustafa Acungil — Sun, 10 Dec 2006 14:23:00 GMT

SQL Server, sahiplik zinciri kırıldığında, hakları yeniden kontrol eder.

Mesela A tablonuz, B görünümünüz (view) var. B, A'nın bazı kolonlarını içeriyor. Eğer tablonun da görünümün de sahibi sizseniz, sadece görünümde hak verdiğiniz birisi alttaki tabloda hakkı olmasa bile görünümü kullanabilir.

Ama sizin A tablonuz üzerinde, bir başkası B görünümünü oluşturdu diyelim. Bunun için görünüm oluşturma hakkı ve sizin tablonuza erişim hakkı olması yeterli. Farklı olan, sahiplik zincirinin kırılmış olması. Tablo sizin, bu tabloyu referans alan görünüm ise başkasına ait. Görünümü oluşturan kişi üçüncü bir kişiye izin verirse, bu üçüncü kişinin görünümü kullanmak için alttaki tablodan kullanılan kolonlara da erişim hakkının olması ayrıca gerekir.

SQL Server, server çapındaki bir opsiyonla, birden fazla veritabanında ownership chain (sahiplik zinciri) kurulmasına izin verebilir. Varsayılan ayarda bu sahiplik zincirine izin verilmemektedir. İzin vermenizi tavsiye etmem. Tasarımınız bunu gerektiriyorsa izin vermek zorunda kalabilirsiniz ama bakın nasıl bir riski var.

Diyelim ki İK diye bir insan kaynakları veritabanınız ve bunun altında Maaşlar diye bir tablonuz var. İçeriden meraklı bir arkadaş bu tabloya erişmek istiyor ama hakları buna yeterli değil. Öte yandan Sacit diye bir arkadaşın bu tabloya erişim hakkı olduğunu da biliyor. Meraklı, eğer veritabanı oluşturma hakkına sahipse, kendisine ait bir veritabanı oluşturur. Bu veritabanında vMaaşlar diye bir görünüm yapar. Bu görünümde İK veritabanındaki Maaşlar tablosunu baz alır. Görünümün sahibi olarak da Sacit'i atar.

Durumu bir değerlendirelim:

Meraklı'nın veritabanında Sacit'e ait bir görünüm var. Bu görünüm, Sacit'in erişim hakkı olan İK veritabanındaki Maaşlar tablosunu baz almış. SQL Server'da Cross Database Ownership Chaining'e izin verilmişse, sorun yok. Yasal bir erişim bu. İlginç olan, Meraklı'nın vMaaşların yer aldığı veritabanında tüm haklara sahip olması. Yani, aslında erişimi olmayan maaş bilgilerine bu şekilde erişmiş oldu.

Aklınızda bulunsun...

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Multi-thread'in nesi zor?

Mustafa Acungil — Sun, 10 Dec 2006 14:22:00 GMT

Aslında multi-thread uygulama yazmak, günümüzdeki dillerle hayli kolaylaşmış durumda. .Net'te altyapıyı kullanırken bazı durumlarda multi-threadden zaten yararlanıyorsunuz. Mesela ASP.NET yazıyorsanız, IIS'in çalışma yapısı sayesinde, ziyaretçileriniz threadlere dağılıyor. Kendi kodlarınızı multi-thread yapmanız gereken zamanlarda da kullanabileceğiniz çok iyi mekanizmalar oluşturulmuş durumda. İşin zorluğu, multi-threadin uygulanmasında değil, doğru ve performanslı uygulanmasında. Bunun için de iyi analiz ve tasarım gerekiyor.

Öncelikle uygulamanızı baştan multi-thread yazmanız çoğu durumda gereksiz. Performansla ilgili pek çok konuda yapılması gerektiği gibi, uygulamanızı önce normal yazıp, analizini yapıp, en fazla zaman geçirdiği kısımları performans açısından iyileştirmeniz yeterli. Bunu söylerken tabii ki genel geçer performans ilkelerine dikkat etmeyin demiyorum. Sonradan iyileştirmek, daha özel performans ayarları için (multi-threading gibi) geçerli. (Daha detaylı bilgi için bakınız: Code Complete Second Edition, Steve McConnell, Chapter 25 Code-Tuning Strategies, Chapter 26 Code-Tuning Techniques.)

Uygulamanızın belki yüzde 80'i multi-thread'den yararlanabilir. Ama tüm uygulamanızın işlemci zamanının yüzde 80'i uygulamanızın sadece yüzde 20'sinde geçiyorsa, sadece bu yüzde 20'lik kısmı multi-thread yapmanız büyük olasılıkla yeterli olacaktır.

Peki niye yapmışken kalan yüzde 60'ı da multi-thread yapmayalım? Çünkü herşeyin bir bedeli var. Kod yazma anlamında uygulaması çok kolay olsa da, multi-thread kodun doğruluk ve performansla ilgili sıkıntıları olabiliyor.

Doğruluk ve performansla ilgili oluşabilecek sıkıntının kaynağı, ortak veri üzerinde birden fazla threadin işlem yapmasından kaynaklanıyor. Nasıl veritabanlarında eş zamanlı kullanımın trafiğini iyi yönetemezseniz kördüğümler ve bekleten kilitler oluşursa, threadleriniz de kördüğümlere takılabiliyor ya da birbirlerini bekletebiliyorlar. Daha da kötüsü, tamamen kuralsız bir şekilde hızlı giden thread verilerde istediği değişikliği yaparsa, uygulamanız yanlış çalışabiliyor.

Üstelik multi-thread çalışan kodun test ve debug edilmesi de normal koddan daha zor.

Dimyat'taki pirince giderken evdeki bulgurdan olmak derler ya... İyi planlamazsanız, bilgi birikiminizde ya da çalışacak olan kodun profilini tanımada eksikleriniz varsa, debug iyi yapamıyorsanız, normalde doğru ve belirli bir performansta çalışan kodunuz, yanlış çalışır hale gelebilir ya da beklediğiniz performans getirisinin çok altında kalabilir.

Kolay gelsin : )

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Intel: Programcıların knowhow'ı uygulamalarının performansı için artık çok daha önemli!

Mustafa Acungil — Sun, 10 Dec 2006 14:20:00 GMT

9 Kasım'da The Marmara'da Intel'in "Çok çekirdekli mimariye geçiş" başlıklı yazılım seminerindeydim.

Yıllardır yaşadığımız bir yakınsama var; çeşitli uzmanlık alanları başka uzmanlık alanlarıyla giderek yakınlaşıyor. Bunun en mega trendini telekomünikasyon dünyası ve bilişim dünyası arasında yaşıyoruz. Ama daha küçükleri, her an her yerde karşımıza çıkıyor. Sistemcilerin xml'den, yazılımdan biraz anlaması gerekiyor. Yazılımcıların veritabanıyla ilgili indeks, performans bilgilerini edinmeleri giderek daha çok önem kazanıyor, vs vs...

Şimdi de yazılımcıların işlemcilerle ilgili daha derin bir dikkate ihtiyaçları var. Neden mi?

Bugüne kadar Moore yasası (http://tr.wikipedia.org/wiki/Moore_Yasas%C4%B1) uyarınca tek bir işlemcinin hızını artırmaya odaklanan Intel, daha büyük performans artışı ve bununla birlikte enerji tüketiminin az artması için, tek işlemciyi hızlandırmak yerine çoklu çekirdeğe geçmeye karar verdi. Yine işlem kapasiteleri artmaya devam edecek, hatta eskisinden belki daha hızlı artacak ama klasik programlamaya devam ederseniz, sizin yazdığınız programlar bundan yararlanamayacaklar.

Öncelikle bazı kavramlara açıklık getirelim... Eskiden socket, işlemci, çekirdek hepsi aynı anlama geliyordu. Çünkü her sockette tek bir işlemci tek bir çekirdekle yer alıyordu. Ama artık öyle değil. Artık bir sockette 2, 4, ve daha ileride de 'çok' çekirdek yer alacak. Dual core, quadro core, multicore... Intel performans artışını frekansı neredeyse sabitleyip çekirdek sayısını artırarak geliştirecek artık.

Bunun anlamını biraz daha net ifade edecek olursak: Çoklu işlemcili sistemler artık evlere kadar girecek.

Multi-threading bir anda çok büyük bir önem kazanıyor. Eskiden sadece çoklu işlemcili sistemlerde koşan programlarda multi-threaded uygulamalar yazmaya gerek vardı. IIS gibi uygulamalar ise zaten kendi içinde multi-threadi destekliyordu. Oysa artık, multicore işlemciler yayıldıkça, multi-thread yazmanız ya da uygulamalarınızı multi-threade çevirmeniz büyük avantajlar sağlamaya başlayacak.

Bir örnek vermek gerekirse, seminerde Logo'dan Ürün ve Teknoloji Geliştirme Danışmanı Ayhan İnal, yaptıkları bir testi anlattı. SQL 2000'de koşan bir uygulamalarındaki bir prosesin süresi 900 saniyenin üzerinde. Bu prosesi SQL 2005 kullanan dual core bir makinede 5 threadli olarak çalıştırdıkları zaman süre 200 küsur saniyeye iniyor. Aynı makinede single thread çalıştığında ise 500 küsur saniye sürüyor.

Böyle bir hız farkı uygulamanız için kritik olabilir. Daha kritik olan: İşlemcinin bu performans artışından otomatik olarak yararlanamıyorsunuz, ancak multi-thread yazarsanız yararlanabiliyorsunuz. Yani eskiden tüm programcılar işlemci hızındaki artışlardan aynı oranda yararlanıyorlarken, artık multi-thread yazanlar multi-core'un getirdiği hızdan yararlanırken normal yazanlar yararlanamayacaklar.

Aslında multi-thread yazmak zor değil, ama multi-threadi doğru analiz etmek ve doğru uygulamak zor.

Başka bir yazıda da multi-thread'de dikkat edilmesi gereken noktaları yazmayı düşünüyorum...

Beni izlemeye devam edin...

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Departman seviyesinde uygulamalar

Mustafa Acungil — Sun, 10 Dec 2006 14:19:00 GMT

Microsoft teknolojilerinde yaşanan bir evrim, şu an önemli bir boşluk ortaya çıkarmış durumda.

VBA tarzı uygulamalar artık tarihe karışıyor. Ama aslında tarihe karışan, VBA tarzı uygulamalar değil, VBA'in kendisi.

Kurumsal seviyede büyük uygulamalar kendi yolunda ilerliyor. Departman seviyesinde uygulamalar da ise önemli değişiklikler var. Artık Access yerine SQL Server Express Edition kullanma şansınız var. VBA yerine Visual Studio Tools For Office... Üstelik Visual Studio.net'le, çok derin yazılım bilginiz olmadan uygulama geliştirmek artık eskisinden de daha kolay.

Biraz Visual Studio öğrenerek, biraz SQL Server öğrenerek, Office'te gelen yeniliklerden yararlanarak, bir de bunları Sharepoint yapısı kullanma şansınız varsa burada entegre ederek, departman seviyesinde sorunlarınız için harika programatik çözümler oluşturabilirsiniz.

Bence buraya iki taraftan profesyoneller kayacak yavaş yavaş:

Birincisi, pozisyon olarak iş tarafında bulunmuş ama teknik tarafa da meraklı olan, kendi kendine küçük programlar geliştiren insanlar. Bunların içinde teknik yönünü biraz daha geliştirmeye meyilli olanlar, yeni teknoloji imkanlarından çok hoşlanacaktır.

İkincisi, profesyonel uygulama geliştiricilerden hardcore coder olmaya daha uzak duran, business tarafına yakınlığı daha fazla olan, yazılımı bir bütün olarak değil de, küçük küçük bileşenlerden oluşan bir araçlar kutusu gibi görmeye daha meyilli kişiler.

Sonuçta tüm işletmelerin kurumsal seviyede karmaşık yapılı programlara ihtiyaçları yok. KOBİ'lerde adı geçen teknolojilerle çok güzel uygulamalar geliştirilebilir.

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Bir iş zekası çözümü için teknoloji gereksinimleri

Mustafa Acungil — Tue, 05 Dec 2006 13:20:00 GMT

İş zekası çözümleri yazılım projelerine benzer bir şekilde gerçekleştirilir. Ama kapsam olarak genelde standart yazılım projelerinden daha geniştir ve daha fazla kaynak ister.

Bir iş zekası çözümü planlarken, özellikle hangi teknolojileri kullanmanız gerekeceğini dikkatli bir şekilde düşünmüş olmalısınız, aksi taktirde gerekli donanıma ya da bilgiye sahip olmadığınızı sonradan fark ederek hayal kırıklığına uğrayabilirsiniz. Ya da doğru yaptığınızı düşünürken, birşeyleri eksik bırakmış olabilirsiniz. İşte işinize yarayabilecek bir gerekli teknolojiler listesi:

Network altyapısı - LAN ve WAN, intranet, Internet. Bağlantısız çalışan bir şey kurgulamaya çalışmak zaten anlamsız...
Veriye ulaşabilirlik ve ETL.
İstemci ve sunucu tarafında uygulama geliştirme. Her ne kadar teknolojiler yazılması gereken kod miktarını giderek düşürüyor olsa da, belirli miktar kod yazılması gerekiyor yine.
Web sitesi - sunum, yük dağılımı, veriyi işleme...
Veri saklama alanı
Veri düzenleme
Güvenlik
Sunucu yönetimi
Uygulama testleri
İş analizi
Raporlama
Sunum

Bunlardan birini bile ihmal etmeniz, projede önemli zaaflara sebep olabilir. Mesela proje sponsoru genel müdürün istediği kalitede bi sunum ortamı sağlayan bir dashboard yapamazsanız, arkada ne kadar iyi ve karmaşık bir sistem kurmuş olursanız olun, önemli bir eksiğiniz var demektir. Bu eksik, projenin kaderinde etkiye sahip olacak denli önemli hale gelebilir de...

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Veri madenciliğinde CRISP-DM yaklaşımı

Mustafa Acungil — Tue, 05 Dec 2006 13:13:00 GMT

Daha önceki blog girdilerimden birinde, veri madenciliğinin tüm BI düzleminde akademik çalışmayla en yakından ilgili alan olduğunu söylemiştim. Bu alandaki yaklaşımlardan birinin adımlarını sıraladığımda ne demek istediğimi daha iyi anlayacaksınız.

Yaklaşımın ismi CRISP-DM (CRoss-Industry Standard Process for data mining). Orijinal üyeleri Daimler-Benz, SPSS ve NCR olan bir konsorsiyum tarafından geliştirilmiş.

CRISP-DM yaklaşımındaki veri madenciliği yaşam adımları şunlar:

İşi anlamak - hedefleri ve gereklilikleri geliştir.
Veriyi anlamak - veriyi detaylı olarak incele, saklı desenler hakkında hipotez geliştir.
Veriyi hazırlamak - veri kaynağıyla bağlantı kur ve veri madenciliği modelinde kullanılacak veri kümesini oluştur.
Modelleme - bir ya da daha fazla veri madenciliği modeli seç, parametreleri belirle, dene ve iyileştir.
Deneme - iş hedeflerine göre model ya da modelleri dene, gözden geçir ve gerekiyorsa iyileştirmeleri yap.
Sahaya sürmek - model sonuçlarını analistlere ve son kullanıcılara sun, model sonuçlarını iş süreçlerine yorumlanacak ve uygulanacak şekilde rafine et.

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

OLAP çözümleri oluşturmada Kimball/Ross 4 adımlı yaklaşımı

Mustafa Acungil — Tue, 05 Dec 2006 13:10:00 GMT

OLAP çözümleri oluşturmada en çok temel alınan geleneksel yaklaşımlardan birisi Kimball/Ross 4 adımlı yaklaşımıdır. Microsoft kaynaklarında bu yaklaşım şöyle özetleniyor:

Süreci seç - veri marketi odak alanını belirle.
Veri marketiğinin en küçük birimini (grain: darı) belirle - gerçek tablosunun detay seviyesini belirle.
Birden fazla küpte kullanılabilecek boyutları belirle.
Gerçekleri ve ölçütlerin en küçük birimlerini veri marketinin en küçük birimiyle uyumlu olacak şekilde belirle. İdeal durumda bunların birbirleriyle toplanabilir olması gerekir. (elma ile elma, armut ile armut...)

Kimball sonradan gelişen çalışmalarıyla, bu 4 maddeye 4 yeni madde daha eklemiştir:

Performansı artırmak için türetilmiş gerçek değerleri belirle ve önceden hesapla.
Boyut tablosunu detaylı tariflerle zenginleştir.
Veritabanının ömrünü belirle - gerçeklerin ve ölçütlerin ömürlerini...
Yavaşça değişen boyutları belirle ve onları nasıl idare edeceğine karar ver.

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Büyük olsun!

Mustafa Acungil — Tue, 05 Dec 2006 13:09:00 GMT

İş zekası uygulamalarının yakın zamanlara kadar pahalı olmasının önemli sebeplerinden birisi de, işlem gücü ve donanım olarak önemli kaynak gerektirmesiydi.

Tipik olarak iş zekasına yönelen firmaların, analiz edilince firmaya büyük katkılar sağlayabilecek kadar çok verisi vardır. Bu veriler, şirketin çeşitli farklı sunucularında ayrı ayrı tutulur genelde. Çok büyük ölçüde de denormalize olarak.

Ama iş zekası uygulamasının etkin olabilmesi için öncelikle şirketteki tüm verileri (ya da tercih edilmiş alt bölümleri) kapsaması gerekir. Bu veriler her ne kadar OLAP sistemlerine özetlenerek de alınsa, denormalize tutulmaları büyüklüklerini daha da artırır. Bir de üstüne, tam bir analiz için dış kaynaklardan alınan çeşitli verilerin de sisteme eklenmesinin gerekmesi konunun tuzu biberi olur.

İş zekası çözümü peşindeyseniz, donanım harcaması yapmanız gerekebileceğini göz ardı etmeyin. Ayrıca tasarım da son derece önemli. İyi bir tasarım yapmazsanız, hem gereğinden fazla bir işlem gücü ve depolama alanına ihtiyaç duyulabilir, hem de -tabii çok daha kötüsü- verilerin temiz ve doğru olduğundan emin olamayabilirsiniz!

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

Zamanya

Mustafa Acungil — Tue, 05 Dec 2006 13:07:00 GMT

Yiğit Kulabaş'ı ilk ne zaman gördüm? Sanırım Microsoft'un ilk Zirvesinde, Office'le ilgili sahnelemiş oldukları oyundaydı. Kaleminin bu kadar güçlü olduğunu yeterince anlamamıştım o zaman.

Sonra ortak bir proje girişimimiz kapsamında, bir kaç toplantı yaptık. O toplantılardan birinde söylediği "Büyük düşünelim, küçük başlayalım" lafı hala kulağımda. Aslında çok orijinal bir söz değil ama, içinde bulunduğumuz ortamda bende bıraktığı etkiyle, "kulağımda küpe oldu".

Yiğit Kulabaş'ın kitabını karşımda görünce, hoş bir sürpriz yaşadım. Kendim de yazmaya meraklı olduğum için, benimle ortak özellikleri olan ya da sosyal temasım olan kişilerin yazdıklarını daha bir ilgiyle okurum. Orhan Pamuk'un İTÜ Mimarlığı bırakıp yazarlık kariyerinde karar kılması, Semih Gümüş'ün Ankara Fen Lisesi'nde okumuş olması, bunlar beni etkileyen şeyler. Yiğit Kulabaş da Microsoft kariyeriyle ve kısa süreli de olsa bir proje ile ilgili birlikte çalışmışlığımızla, yazdıklarını okumayı ilginç bulacağımı düşündüğüm bir yazardı.

Beklentilerimi aştığını söyleyebilirim. Zamanya çok hoş bir kitap.

Kitabın tamamı bir günde geçiyor. Hatta mesai saatleri içinde neredeyse. Biraz erken başlayan ve biraz geç biten bir mesai olarak düşünebiliriz. Orhan Pamuk'un Kara Kitap'ında iki kuzenin dönüşümlü bölüm paylaşımı gibi, burada da beraber kalan iki kafadar Kerim ve Selim'in gün boyu ayrı ayrı süren maceraları, dönüşümlü olarak anlatılıyor.

Kitap bir günde geçse de, on civarında ülkeyi ve daha fazla sayıda şehri kapsıyor. Çok da geniş bir zaman çizelgesini.

Bir yandan Alice Harikalar Diyarı'nda dolaşırken, bir yandan günümüzün çok rastlanan bir ofis ortamının 'ofis-politiğine' bata çıka bir gün yaşıyorsunuz. Eğlenceli bir dil, günümüz iş hayatına dair keskin gözlemler, hepsi bir arada.

Tüm bunların üstüne sos olarak da, zamanla ilgili pek çok kavramı, projeyi, ilginç bilgiyi kitap boyunca edinebilirsiniz.

Benim en hoşuma giden kısımlardan biri, her hafta tatillerin aynı güne gelmesi için Kerim'in önerdiği formüldü: 1 Ocak 'günsüz' olsun, 4 yılda bir 29 Şubat da günsüz olsun, işi bağlayalım. : ) Böylelikle mesela her 31 Aralık Pazar günü olacak. Her 1 Ocak hafta günü etiketi taşımayan özel bir gün olacak ve her 2 Şubat Pazartesi olacak.

Yiğit Kulabaş'a okurlarına hediye ettiği bu güzel kitap için binlerce teşekkür. Umarım ardından başka eserler de gelir.

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com

İş zekasının temel kavramları

Mustafa Acungil — Tue, 05 Dec 2006 13:06:00 GMT

OLTP:

İşleme dayalı gündelik bir iş sisteminin verilerini tutan operasyonel bir veritabanı sistemidir.

OLAP:

Operasyonel verilerden yararlı bilgileri çeken ve bilgiye dayalı iş kararları alınmasına destek olan veritabanı sistemidir. Bazı durumlarda şirketler bu verileri doğrudan OLTP sistemleri üzerinden kullanırlar ama geliştirilen çözümün zorluğu ve performans açısından bu genelde doğru bir yaklaşım değildir. OLTP sistemleri genelde fazlaca normalizedir ve okumanın yanısıra yazma faaliyetleri de olduğu için yeterince detaylı indeks yapıları kurulmamıştır. İş zekası için gerekli sorguları yazmak hayli karmaşık olacağı gibi, bu sorguların performansı da düşük olur.

ETL:

Operasyonel OLTP sistemlerinde tutulan verilerin yapısı, sistemin gereksinimlerine göre düzenlenmiştir. BI için gerekli olan yapıyla uyumlu olmadığı için, OLAP tarafında kullanılabilmek üzere bu veri yapısı üzerinde çalışılması gerekir. ETL sistemleri çeşitli veri kaynaklarından (OLTP, excel dosyaları, csv dosyaları vb...) verileri çeker, bunları temizler ve birbirleriyle uyumlu hale getirir, sonra da bu verileri merkezi veri ambarına gerektiği gibi yükler.

Veri Ambarı:

Bir veri ambarı, uyumlu verilerin merkezi bir depolama alanıdır. Her operasyonel sistem, işin bir yönüyle ilgili veriler tutar. Veri ambarı ise, her ne kadar OLTP yapısındaysa da, çeşitli sistemlerden bir araya getirilmiş ve uyumlu bir yapıya sokulmuş verileri bütüncül bir yaklaşımla içerir. Standart operasyonel veritabanlarından ayrı bir yapı olduğu için, veri ambarına dayalı veri analizi, veri madenciliği ve raporlama çalışmaları, operasyonel sistemlerin performansı üzerinde olumsuz bir etki yapmaz. Veri ambarındaki veriler çoğu durumda sorgu performansını ençoklamak için denormalize durumdadır. Veri ambarının normal operasyonel sistemlerden ayrı yapısı belirli aralıklarla operasyonel sistemlerle senkronize edilir. Böylece analiz daha güncel veriler üzerinden devam eder. Çoğu durumlarda bu güncellemeler her gece olarak programlanır.

Veri Marketi (Data Mart):
Bir veri marketinin temel özelliği, konu odaklı ve departman bazlı bir depolama birimi olmasıdır. Mesela pazarlama verisi, muhasebe verisi gibi... Organizasyonlar analiz birimi olarak bazen doğrudan veri marketlerini kullanırlar. Bazen de bu veri gruplarından daha büyük veri ambarı oluşturulur.

Veri Madenciliği:

Veri madenciliği çözümleri veriyi analiz etmek ve verideki desenlere ve istatistiğe dayalı olarak trendler ve tahminler oluşturmak için matematiksel algoritmalar kullanırlar. İş zekasının en akademik kısmı budur ve halen akademik çalışmalarla gelişmeye devam etmektedir. Veri madenciliği uygulamaları sayesinde normalde ulaşılamayacak değerli davranış desenlerine ulaşılabilir. Teröre karşı çalışmalardan, milyonlarca müşterisi olan firmaların müşteri sınıflandırmasına kadar pek çok alanda veri madenciliği kullanılmaktadır.

Gösterge ekranları ve skor kartları (dashboards and scorecards):

Gösterge ekranları sayesinde, temel özet verileri bir bakışta görme şansınız olur. Bir arabanın durumunu ve sorunlarını nasıl tek bir bakış alanı içinde görüyorsanız, gösterge ekranları da bir işin gidişatını bu şekilde görmenizi sağlar. Gösterge ekranı genelde bir web uygulamasıdır.

Skor kartları da gösterge panolarına benzer bir işlev görür. Ama skor kartları kişi ve grup bazlıdır. Böylelikle genel hedeflerin aşağıya doğru dağılımı takip edilmiş olur. Eğer tüm bireyler kendi hedeflerini gerçekleyebilirse, şirket de hedefine ulaşmış olur. Çalışma dönemleri boyunca, yöneticiler ve bireyler performansları izleyebilir durumda olduğu için, genel hedefe ulaşma yönünde önemli bir motivasyon etkenidir.

Raporlama:

Statik ya da olabildiğince dinamik raporlar oluşturulabilir. BI altyapısı ve verinin raporlamaya çok uygun bir şekle getirilmiş olması bunu sağlar. Parametrik raporlar, genelden özele detaylandırılabilir raporlar, rapor teslimlerinin otomatikleştirilmesi gibi pek çok avantajlı uygulama, raporlama araçlarının gelişmesiyle kolayca yapılabilir hale gelmiştir.

Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com