SON YAZILAR
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 yayınlandı.
download : http://msdn.microsoft.com/entlib
Ş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.)
Ş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.)
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
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
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
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!
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
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...
İş 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.
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.
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!
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...
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 : )
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...
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.
İş 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
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 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
İş 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!
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.
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.
İş zekası çözümünün unsurlarını bileşenler ve süreçler olarak ayırabiliriz.
Temelde bulunması gereken bileşenler şunlardır:
Süreçleri ise şöyle sıralayabiliriz:
- ETL (Extract, transform, load - Veri çek, Veriyi dönüştür, Veriyi yükle)
- Veri temizleme
- Küplerin proses edilmesi
- Veri madenciliği
BI (Business Intelligence - İş Zekası) konusunda beni izlemeye devam edin...
Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com
İş zekası, var olan iş performansını anlamak ve bilgiye dayalı iş kararları almak için tüm organizasyon çapında iş verilerinin analizidir. İş zekası çözümü tarafından sağlanan bilgi hedefe yönelik olmalıdır ve hedeflenen kullanıcı grubu için yeterli detay seviyesine ve sunum biçimine sahip olmalıdır.
(Microsoft'un konuyla ilgili giriş eğitiminden alıntı. Türkçe'ye çeviri benden...)
Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com
Çünkü rekabet!
İdeal serbest piyasada kar yoktur. Müşteriler tüm seçenekleri bildikleri için, en uygununu tercih ederler. Günümüzün başarılı şirketleri, kar marjlarının hızla eridiği zamanımızda işini karlı olarak yapabilenler.
Globalizasyon acımasızca hüküm sürerken bu pek de kolay değil. Bırakın şirketleri, bireyler bile artık uluslar arası bir rekabetin içinde. Hem giderlerinizi kontrol altında tutmanız, hem de gelir fırsatlarını iyi değerlendirmeniz gerekiyor. Bunun için de işinize çok iyi hakim olmanız gerekli. İşinizi bilmeniz, işinizin detaylarını bilmeniz, buna göre kararlar alabilmeniz, geleceğinizi sürekli yeniden şekillendirmeniz zorunlu.
İş zekası, on yıl önce, belki sadece hayli büyük firmaların ilgilendiği, biraz akademik, biraz geleceğe dair, hayli de pahalı bir alandı. Artık öyle değil.
Orta ölçekli firmalar, kontrol edilebilir maliyetlerle, akademik yönlerine de pek bulaşmadan iş zekası kullanabilir hale geldiler.
Yarının teknolojisi değil artık bu. İş zekası deyince yarın artık bugündür.
Öncelikle bir açıklama: Manyak, benim yerine göre övgü için kullandığım bir kelimedir. Olumsuz anlamıyla da pek kullanmam zaten.
Senaryoya gelmeden önce basit bir hatırlatma:
SQL Server'ın 2005'den önceki versiyonlarında, şema yerine kullanıcı kavramı vardı. Standartlara uymayan bu durum hem hayli kafa karıştırıcıydı, hem de kullanım açısından yapılabilecek bazı şeylerin yapılamamasına sebep oluyordu. Mesela, nesneleri kullanıcılara bağlı olarak oluşturduğunuzda, o kişinin aynı zamanda login olmak için kullandığı bir hesaba bağlamış oluyordunuz. Bu tür karmaşıklıklar yüzünden de ya her şey dbo'nun altında oluşturuluyordu ya da karmaşık bir sistemle uğraşmanız gerekiyordu.
2005 versiyonuyla birlikte şemalar geldi! Artık kullanıcı ayrı bir şey, şema ayrı bir şey. Böylelikle şemaları olması gerektiği gibi, yani bir nesne gruplama deposu olarak kullanabileceksiniz. Ama bunu zaten bir şekilde duymuşsunuzdur şu ana kadar büyük olasıkla?
Gelelim manyak senaryoya:
Şemaların sahibi olarak kullanıcıları, database rollerini ya da application rollerini atayabiliyorsunuz. Böylelikle o şema altında yer alacak nesnelerin sahibi bir grubun tüm üyeleri olabiliyor.
Nesne sahipliğini tekil olarak kişilerden soyutlamanın çok iyi bir yolu?
Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com
Eski ilke yeni ürün!
Kullanıcı girdisini her zaman suçlu olarak kabul edin. Denetleyin, masumsa işleme devam edin.
Bu eski ilke.
Yeni ürün ne? Notification Services. Notification Services?a üyelik sistemi ile erişilebiliyor. Üye olmak için kullanıcıların bilgi girdiği bir alan varsa, bu alanın girdi güvenliğini kendiniz uygulamanız gerekli. Notification Services headerlarda kendisi böyle bir kontrol yapmıyor.
Yeni her zaman tehlikelidir, unutmayın! Güvenlikle ilgili oluşabilecek açıklar ve önlemlerinin bilgisi yavaş yavaş yayılır. Saldırganlar genelde bu bilgi yayılmasının kaynağına, korumayla görevli kişilerden daha yakın dururlar. Acı ama gerçek!
Güvenlik alanında çokça yapılan hatalardan birisi, korunması gereken noktalardan birini ihmal etmektir.
Düşünün ki, bir savaşa hazırlanıyorsunuz. Yüzüklerin Efendisinin size özgü modundasınız mesela? Kalenin her tarafı çok güvenli. Zaten yıllardır çeşitli saldırıları püskürtmüş. Ama dışarıdan içeriye doğru surların altından akan bir su yolu var ve mazgallarla korunmuş. Ork'un biri, koruma altında oraya patlayıcılarla hücum ediyor. (Sahneyi hatırladınız mı? Miğferdibi kalesini?)
Tek bir noktayı ihmal etmeniz, diğer taraflarda çok iyi bir güvenlik seviyesi de sağlamış olsanız, tüm güvenliğinizi yok edebilir.
Bu durumun IT'deki bir benzeri, kurum içinde artık çok kullanılmayan, kıyıda unutulmuş bir file serverlığa kadar düşmüş bir sunucu olabilir. Bu sunucu o kadar az kullanılmaktadır ki, artık IT yöneticileri de fiziksel olarak ona doğru baktıklarında bile bir şey görmemektedirler. Doğal olarak güvenlikle ilgili önlemler düşünülürken de bu sunucu unutulabilmektedir. Oysa o sunucuya bir şekilde erişen bir saldırgan, oradan sistemin kalanına da rahatlıkla sızabilir.
Yine benzer bir durum, şu anki güncel ürünlerden biri olan SQL Server 2005'te gerçekleşebilir. SQL Server 2005, güvenlikte önemli yenilikler ve iyileştirmeler getirmiş bir ürün. Ama öte yandan mimari olarak da pek çok yeni işlevsellik ve eski bazı yapılarda değişiklik getiriyor. Bu durumda, DBA'ler, yeni sisteme adapte olurken güvenlik tasarımında hata yapabilirler. Hakim olmadıkları, kendileri için farklı bir alanda yürüyor olacakları için, tehlike altındalar.
Eğer SQL Server 2005'e geçmişseniz, güvenlik açısından korumanız gereken unsurların neler olduğunu yeniden gözden geçirmelisiniz. Size yardımcı olabilecek kısa bir yol haritası sunuyorum. Bu yol haritası sayesinde kendi SQL Serverınızda güvenlik ayarlarını 'düşünmeniz' gereken nesneleri tespit edebilmiş olacaksınız.
- Öncelikle tasarımınızda yer alan veritabanı servislerini belirleyin; Service Broker, Notification Services, Database Engine, ne varsa? Bu servisler için kullanılan uçnoktaları (endpoints) düşünün ve aralarındaki etkileşimleri anlayın. Son olarak da sunucunuzda oluşturulmuş tüm girişleri (login) belirleyin. Bu durumda mesela Service Broker için hangi uçnoktaları oluşturduğunuzu ve bunları kullanmak için oluşturulmuş girişleri belgelemiş olacaksınız.
- Tüm veritabanlarını ve bu veritabanları içinde bir şema belirteci altında oluşturulmamış nesneleri, mesela kullanıcıları, rolleri, sertifikaları listeleyin.
- Sonra tüm şemaların içinde yer alan nesneleri, mesela tabloları, görünümleri (view) ve fonksiyonları sıralayın.
Bu yaklaşım sayesinde kapsamı sunucu olanlar, veritabanı içinde yer alan ama bir şema altında olmayanlar ve veritabanlarında şema altında olanlar şeklinde güvenliğini düzenlemeniz gereken nesneler ortaya çıkmış olacak. Bunların güvenlik ayarlarını yaparken de her zaman yapıldığı gibi mümkün olduğunca gruplamaya çalışmanız gerekecek.
Burada kritik olan nokta, bir önceki versiyonda aktif kullanımı olmayan şemaların artık aktif kullanılacak bir katman olarak gelmiş olması.
Şema ve kullanıcı artık aynı şey değil. SQL Server 2000'de derin bir deneyiminiz varsa, bu değişikliği ihmal edebilirsiniz. Bu durumda SQL Server 2005'teki çözüm tasarımlarınız bu önemli avantajı kullanmamış olur. Yapılabilecek ikinci bir hata da şemaların bize sunduğu yeni olanaklardan yararlanmak ama güvenlik ayarlarını yaparken, şemaları sanki veritabanı katmanında gibi düşünüp, veritabanı altında yer alan ama bir şema altında bulunmayan nesnelerin güvenlik ayarlarını atlamak olabilir.
Miğferdibinde olsanız, o koca kalenin altında bir nokta gibi kalan su yoluna meşaleyle koşan Ork'u görmek içinizi cız ettirirdi sanırım. Ardından bir de patlamayı duymak, o yıkılmaz surun büyükçe bir diliminin çöktüğünü görmek ve bir yığın orkun içeriye akın etmesine şahit olmak, pek hoş olmazdı.
Güvenlik açısından atlayacağınız bir nokta, benzer bir sonuçla karşılaşmanıza sebep olabilir.
Saldırganlar Ork olmasalar da, verdikleri hasar onlarınki kadar olabilecektir.
4 Ekim'de BTHaber'in İş Zekası etkinliğindeydim.
İş Zekası şu ana kadarki gelişimime çok iyi uyan ve ufkumun da önemli bir kısmını kaplayan bir konu. Blog'umda bu konuyla ilgili sık ve uzun girdilere rastlayacağınızı umuyorum.
Ama iş zekası kavramının kendisiyle ilgili bir sorun var. Bu etkinlikte de üzerinde birkaç kez kuruldu. Kavramın İngilizcesi 'business intelligence'. Uzmanlar zeka kelimesinin intelligence kelimesini karşılamadığı ve istihbaratın daha doğru bir kelime olduğunu, ama zeka kelimesinin de albenisinin ve kavramın kabullenilmesine katkısının olumlu olduğunu belirttiler. İş malumatı, bilgisi, vukufiyeti (biraz eski oldu :) ) diye de düşünülebilir.
Ama bence burada daha problemli olan kelime ilki: İş.
Şu an aklıma gelen 4 ayrı İngilizce kelime için iş karşılığını kullanıyoruz: Business, work, job, task.
Bunlardan job için meslek kelimesini ve task için görev kelimesini de kullanıyoruz. Böylelikle biraz ayırt etme şansımız oluyor gerektiğinde. Work'un tam karşılığı ise iş zaten, onda sorun yok. Ama şu business kelimesinin de tek karşılığının iş olması bence ciddi karışıklığa sebep oluyor.
Şöyle bir cümle düşünün: "Bugün işte kendi işimi kurma düşüncesi yine birden aklıma gelince elimdeki işi bir türlü bitiremediğimden işçilerin çıkardığı işin kalitesini inceleme için ayırdığım saati atlamışım."
Hayda çık çıkabilirsen, İŞin içinden. (Aklıma gelmemiş bir kullanım, burada doğrudan sorunlu durum anlamına geliyor.)
Zekaya göz yumuyorum da, şu iş kelimesinin karşığılı güzel bi şey bulamadım henüz. Bulsam bile, bunca zamandır kullanılan kalıbı artık değiştirmek zor. O yüzden Business Intelligence'ın anlamını çok da sarih ifade eden bir kalıp olduğunu düşündüğüm halde, Türkçe olması için bu kategorideki girdilerimi İş Zekası başlığı altında toplayacağım... (Bu son kategorizasyon, aşağıda linkini verdiğim kişisel blogumda yapılmaktadır.)
2005 Ekim'iydi sanırım. Seattle'daki MVP toplantısında en çok hoşuma giden sunumlardan biri Jim Allchin'in, Vista'yı tanıtımı olmuştu. Bu sunumda da beni en çok etkileyen iki şey, Jim Allchin'in kendisi ve Vista'daki USB çubuğu bellek olarak kullanma özelliğiydi.
Jim Allchin, uzun yıllardır Microsoft'un platformlarını geliştiren kişi. IT'den emekli olacak yaşta bir insan, çokça emek vermiş. Ak saçlı, etkileyici bir karizma sahibi...
USB'den bellek yapmak, tam da böyle bir 'bilge' görünümle uyuşan bir fikir. Fikrin kaynağının kim olduğunu bilmiyorum ama çok iyi örtüşüyor Jim'le.
Aslında çok basit bir yaklaşım. Bellek pahalı, o yüzden yeterince fazla bellek koyamıyoruz bilgisayarlara. Disk dediğimiz şeyse, günümüz bilgisayarlarındaki en eski ve demoda teknoloji ile çalışıyor. Elektronik değil, mesela optik de değil, bildiğiniz mekanik bir teknoloji. Belleği daha fazla kullanabilelim diye az kullanılan, bir müddettir kullanılmamış kısımlar, bellek dolduğunda diske aktarılıyor ve gerektiğinde diskten geri çağrılıyor. Attan inip eşeğe biniyorsunuz yani! Ama arada daha iyi bir alternatif var: USB 2.0, diskten daha hızlı. O zaman belleğin takviyesini, şu çok eski teknoloji olan diskten önce USB 2.0 bellekle yapalım!...
Güzelliği basitliğinde. O kadar basit bir fikir ki, görmek çok zor.
Bu basit fikri keşfedenlere saygılar. Zekanızla yaşayın!
Vista'da yer alan en ilgi çekici özelliklerden birisi 15-20 metre çaplı alanlarda, vista yüklü ve kablosuz erişim donanımı olan cihazlar arasında peer to peer network kurabilmesi. Bunun için bir kablosuz erişim ağı altyapısına da ihtiyacınız yok üstelik!
Benim olayım, işin teknik detayları olmayacak ama. Bu bağlantıyı sağlamanın adımları ve sağladıktan sonra "windows meeting space"i kullanarak beraber dosyalar üzerinde nasıl çalışabileceğinizin adım adım detayları üzerinde durmayacağım.
Burada asıl önemli olan, böyle bir adımın hayatlarımızı nasıl etkileyeceği. Teknolojinin nereye gittiği ve hayatımızın içine ne kadar girebileceğine bir bakış. Aslında yanlış oldu, ne kadar girdiğine demeliydim.
Teknoloji parmaklarınızın ucunda. Makul paralar harcayarak, 5 yıl önce çok az kişinin hayal edebildiği, 300 yıl önceyse, daha basitleştirilmiş olanlarına sadece padişahların, kıralların, soyluların ulaşabildiği imkanlar satın alınabilir konumda.
Bir yandan dünya çapında kullanıcı grupları, milyonlarca üyesi olan internet toplulukları ortalığı kasıp kavururken, bir yandan da lokal alanınızda küçük topluluklar oluşturmaya, bu tür toplulukların hayatlarını kolaylaştırmaya yönelik imkanlar hızla genişliyor.
Geçenlerde bir dergide, vistanın bilgisayarlarla desteklediği bu hizmetin benzerini, bazı cep telefonu servislerinin kendi ortamlarında verdiğini okudum. Dokunabileceğiniz mesafedeki, size adımlar uzaklığında kalbi atan ekosistemi keşfetmek de heyecan verici değil mi? Hem zaten birlikte yaşıyor/çalışıyor olduğunuz insanlarla teknoloji imkanlarını kullanarak paylaşımınızı artırmış olacaksınız, hem de yakın çevrenizdeki teknolojik kapı komşularını keşfetme şansınız olacak.
Fen Lisesindeyken, önceki senelerden mezun olanlardan tanıdıklarımızın kaldığı bir öğrenci evi vardı Hisarüstü'nde. Haftasonları falan takılırdık. Bir keresinde ilginç bir tipe denk gelmiştim. Kurtlar Vadisi'ndeki Akrep lakaplı mıydı ne, o adamın gençliğini andıran bir tipti. : ) Elinde bir amatör telsiz, Hisarüstü'nden mandallıyordu: Arkadaş arıyorum arkadaş...
Vista'nın bu özelliğini, mesela işyerinde canı sıkıldığı bir gün, komşu şirketlerde kimler var geyik yapılacak diye 'mandallamak' için kullanan çıkmaz mı dersiniz?
Enteresan açılımlar geliyor sanki...
SQL Server'la gelen yeniliklerden biri HTTP Endpoint kullanma imkanı. Ama bu teknoloji, çoğunlukla kısıtlı yapılarda anlamlı. Departman bazlı, XML desteklemesi gereken bir ihtiyacınız varsa kullanılması tavsiye ediliyor.
Güvenlik (veritabanına doğrudan erişim sağlanması), ölçeklenebilirlik (arada başka platformlar kullanmadığınız için katmanlı yapının avantajlarından yararlanmamış oluyorsunuz) ve performans sebepleriyle dışarıya yönelik ve daha kritik uygulamalarınızda HTTP Endpoint'leri kullanMAMAnız tavsiye edilir.
Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com/
Full text index kullanımı sizin için önemliyse, SQL Server 2005'te gelen yenilikleri seveceksiniz.
İşte bazıları:
- Artık full text index sorgularınızı bir kolon ya da tüm kolonlarda (*) yapmak zorunda değilsiniz. Kaç kolonda gerekiyorsa, sorgunuzu yapabiliyorsunuz.
- Full text index sorgularınızı bağlantılı sunucular için de yapabiliyorsunuz.
- Full text index sorgularınızda LANGUAGE anahtar kelimesini kullanarak dil belirtebiliyorsunuz.
- Full text indexleriniz, artık veritabanının yedeklenmesiyle yedeklenebiliyor.
Kategori bazlı olarak tüm yazılarımı içeren blog'um için:
http://mustafaacungil.spaces.live.com/