Etiketler: , | Kategoriler: Sql Server Emrah Uslu | 06.10.2011 15:27

 

Bu yazı, sql server için yedekleme ve kurtarma konusunda kendim için tuttuğum notlardan oluştuğu ve fazla düzenleme yapmadan burada paylaştığım için yazıdaki dilden dolayı özür dileyerek başlayayım.

Ayrıca okumadıysanız serinin ilk yazısına aşağıdaki linkten ulaşabilirsiniz.

Backup Restore Planlaması - I

Sql Server çok çeşitli backup süreçlerine sahiptir. Bunlar tek başlarına yada bir arada kullanılabilirler. Aynı zamanda backup sırasında database online ve kullanıcılara açık olabilir. Ayrıca sql server eş zamanlı olarak 64 backup device'ını destekler. MS Sql Server'da alternatif olarak şu backup çeşitleri bulunmaktadır :

Full Backup

- Transaction log dahil bütün verinin kopyası alınır.

- Restore edildiğinde backup alınan tarih/saate döner.

- Bütün backup stratejileri için alınması zorunlu olan backup çeşididir.

- En temel backup'dır ve bazen diğer backup'ların restore edilmesinden önce ilk olarak restore edilmesi gerekir.

- Full backup'dan restore yapıldığı zaman bütün database dosyaları (mdf, ldf, ndf's) restore edilir. Ardından database online olur ve transaction'lar açısından tutarlı konumdadır.

 

Partial Backup

- 2005 versiyonunda geldi.

- Veritabanının sadece değişen parçaları için backup alınmasının bir yoludur.

- Bu, backup alınma zamanını ve backup boyutunu düşürür.

- Primary filegroup ve read-write filegroup'ların bir kopyasıdır.

- Bu backup tipinin avantajlarından faydalanmak için değişmeyen referans dataları yada artık arşiv olmuş transactional dataları (partial table mantığı ile) bir filegroup'ta toplamak ve bu filegroup read-only olarak işaretlenmelidir.

- Partial backup sırasında primary filegroup'un ve read/write filegroup'ların backup'ı alınır. Optional olarak read-only filegroup'lar dahil edilebilir. Günde, haftada yada ayda bir kez de olsa, read-only filegroup'ların da backup'larını almak lazım.

- Özellikle read-only datası büyük olan bir db'de backup alınma süresini kısaltır

 

File/FileGroup Backup

- Veritabanındaki file yada filegroup'ların kopyasıdır.

- Çok büyük miktarda veriye sahip ve full backup alınması çok anlamlı olmayan db'ler için kullanılır.

- Eğer read/write files yada filegroups'ların backup'ı alınıyorsa, olası restore işlemi için log backup'da alınmalıdır.

- Bu backup çeşidinin dezavantajı şu olabilir : Büyük miktarda dataya sahip veritabanında çok sayıda file/filegroup olması olasıdır ve bunların bakımları, saklanması sorun teşkil edebilir. Aynı zamanda restore ederken bunların her birini restore etmek gereklidir ki bu da çok sayıda adım sonrasında restore işleminin tamamlanması anlamına gelir.

Not : Bir tablo ve o tabloya ait bütün indeksler aynı backup içerisinde yer almalıdır. Sql Server bunu kontrol eder ve bu kural ihlal edildiğinde hata verir. File/Filegroup backup kullanacaksak, index'lerin lokasyonu için backup plan'ını hesaba katmak gerekir.

 

Differential Backup

 - En son full backup'ın ardından değişen bütün dataların saklandığı kopyadır.

- Bir kayıta ait değişen datanın sadece son versiyonu saklanır. Değeri 5 olan bir veri full backuptan sonra sırasıyla 3,6,9 olarak update edilmişse differential backup içerisinde ilgili kayıtta sadece 9 verisi bulunur.

- En son full backup'a differential'ın base'i denir.

- Base ne kadar önceden alınmışsa, differential'ın boyutu o kadar büyüktür.

- Sql Server 2008 değişen extent'leri takip eder (bitmap page ile) ve bunların backup'ını alır.

Not : Sql server veriyi page'lerde tutar. Page 8k'lık veri saklayan en küçük veri saklama birimidir. Yani 1mb'da 128 page bulunur.

Bununla birlikte extent, 8 tane page'in bir araya gelmesiyle meydana gelen veri saklama birimidir. Yani 1 mb'da 16 extent bulunur.

Yukarıdaki şemada 24 tane extent var. Differential backup alındığı sırada bunların 6'sındaki data değişmiş. Değişmeyen extent'ler 0, değişen extentler 1 ile işaretlenerek bir differential bitmap page oluşturulur. Differential backup sırasında bu bitmap page'e göre hangi extent'lerin backup'ının alınacağına karar verilir.

- Differential backup'lar kümülatiftir.Pazar gecesi full backup aldıktan sonra Pazartesi akşam differential backup alırsak, bu Pazar gecesinden itibaren gerçekleşen bütün değişiklikleri içerir. Salı akşam bir differential backup daha alırsak, bu 2.differential backup yine Pazar gecesinden itibaren meyadana gelen bütün değişiklikleri içerecektir. Restore etme ihtiyacı olduğunda önce en son full backup restore edilir, ardından o full backup'dan sonra alınan en son differential backup restore edilmelidir. Ardından da son differential backup'dan sonra alınmış eldeki transaction log backup’lar restore edilir. Bu şekilde hızlı bir biçimde kurtarma operasyonu tamamlanır.

 - Full database backup'dan sonra ne kadar miktarda datanın değiştiğine göre differential backup'dan faydalanma oranı değişir. Değişen kayıtlar, veritabanındaki kayıt miktarına yaklaşırsa o zaman yeni bir full backup alıp, ardından yeni bir differential ile devam etmek daha sağlıklı olacaktır.

 - Differential'ın bir diğer avantajı ise şöyle açıklanabilir. Bir grup veri, tekrarlayan bir job ile birlikte belirli aralıklarla değişiyorsa transaction log'un içerisinde bu değişikliklerin hepsi saklanır ve olası bir restore ihtiyacında bütün bu değişiklikler arka arkaya çalıştırılarak değişen verilerin en son değerleri elde edilir. Bu uzun süren bir restore süreci gerektirebilir. Eğer elde bu sürece ait differential backup'lar varsa, son diff. backup restore edilerek doğrudan verilerin son hali elde edilmiş olur.

  

Partial Differential Backup

 - Differential backup'la aynıdır. Sadece partial backup'daki datalarla eşleşir ve partial backup içerisindeki değişen verileri takip edip kayıt eder. Restore etmek için partial backup'a ihtiyaç vardır.

 - Sql Server Management Studio ve Maintenance Plan Wizard tarafından desteklenmez; sql script ile gerçekleştirilir.

  

File Differential Backup

- Alınmış en son file yada filegroup backup'dan sonra gerçekleşen değişikliklerin kopyasıdır.

- read/write files yada filegroups için alınan differential backup'dan sonra transaction-log backup alınması gerekir.

- Aynı şekilde file differential backup restore edildikten sonra transaction log backup'ın da restore edilmesi gerekir.

- File backup ve file differential backup, restore sürecinin kompleksliğini artırır.

 

Copy-only Backup

- Genellikle alınan backup'lar sonraki backup/restore serilerini etkiler, başlangıç-bitiş noktaları işaretler. Bunlar gerçekleşmeden mesela test yada uygulama geliştirme amaçlı backup, log backup almak için copy-only backup kullanılabilir.

- Dolayısıyla normal düzendeki sql backup/restore senaryolarının dışında backup çeşididir.

- Full backup ve transaction log backup için kullanılabilir.

- Full backup, differential backup'ları resetlerken copy-only full backup resetlemez.

- Transaction Log Backup, log'u truncate ederken, copy-only transaction log backup log'u truncate etmez ve aynı zamanda sonraki normal transaction log backup'ı etkilemez

 

Log Backup

3 çeşit olarak sayılabilir.

a) Pure Transaction-Log Backup

 - Bütün veri modifikasyonları, burada tutulur.

- En iyi veri koruma şeklidir.

- İstenen ana geri dönebilmeyi sağlar.

- Recovery model, Full yada Bulk-Logged olması durumunda alınabilir. Recovery mode Bulk-logged olarak set edildiyse, bulk işlemler log dosyasına yazılmaz. Simple recovery mode için alınması zaten anlamsızdır.

LSN=Log Sequence Number              SAN=Storage Area Network            WAL=Write Ahead Logging - this is a protocol

 b) Bulk Transaction-Log Backup

 - Recovery model, bulk-logged olduğunda alınan transaction-log backup çeşididir.

 - Syntax olarak pure transaction log backup ile farkı yoktur.

 - Sql server otomatik olarak db'nin o anki recovery model'ini detect eder.

 - Bu şekilde alınan bir log backup, zamanda istenen noktaya geri dönmeyi sağlamaz.

 - Bulk işlemlerin performansını artırmak için kısa süreliğine db'nin recovery modelini Bulk-Logged'a çekmek en doğru tercih olacaktır.

 - Transaction-log backup sırasında eğer bulk-loglanmış data varsa sql server bu datayı backup dosyasına dahil eder, bu yüzden log backup dosyasının boyutu küçük olmayacaktır.

 - Transaction log backup, restore edilmeden önce, eldeki en son full backup, ardından da varsa en son differential backup restore edilir. Bunların ardından full yada varsa differential backup'dan sonra alınmış transaction log backup'lar sırasıyla restore edilebilir.

 c) Tail Transaction-Log Backup

 - Veritabanı bozulduktan sonra alınabilecek transaction-log backup çeşididir.

 - Her gece full backup alınıyor, her saat başı transaction log backup alınıyor. Data dosyası saat 16.30'da bozuldu diyelim. Önceki geceye ait full backup ve ardından eldeki bütün transaction log backup'lar arka arkaya restore edildiğinde db'nin saat 16.00'daki durumuna geri dönülür. Ya 16.00 ile 16.30 arası? Data dosyası bozulmuş olsa da log dosyası hala sağlam. Bu durumda log dosyasından son bir transaction log-backup alınabilir. Bu da tail transaction log backup olur. Bu backup, son alınan transaction log backup'ın ardından gelen transaction'ları içerir. Tail backup'ın da restore edilmesinin ardından db, bozulduğu ana geri dönmüş olur.

 - Buradaki risklerden birisi, restore işlemlerine başlamadan önce tail log backup alınmasının unutulmasıdır. Aksiyon alınmadan önce tail log backup alınması gerekir.

 - Eğer db, bulk-logged recovery model'da ise ve bununla birlikte bulk işlemler gerçekleşmişse , tail transaction-log backup alınamaz. Çünkü bu durumda tail transaction-log backup, bulk işlemler sonucunda gerçekleşen data modifikasyonlarını data dosyasından elde etmek isteyecek; ancak data dosyamız bozuk olduğu için bunu gerçekleştiremeyecektir.

 - Management Studio üzerinden Tail log backup almak için Master db'ine yada başka bir database'e gidip bu işlemi yapmak lazım. Çünkü bizim database'imiz erişilmez durumdadır. Bunu yapmak için transaction-log back seçilir ve ardından aşağıda yer alan

            Backup the tail of the log and leave the database in restoring mode

 checkbox'ı seçilir. Bunun ardından database restoring mode'da bırakılır ve arkasından restore işlemleri sırayla yapılır, son olarak bu alınan tail log backup restore edilir.

 

 Attach/Detach

 Sql server'ı kapatıp, data dosyalarını kopyalamak ve sql server'a bağlanıp bunları ataçlamak.

 

 Backup Compression (Yedek Dosyasını Sıkıştırma)

 - Daha hızlı backup alma süreci ve daha küçük backup dosyası sağlar.

 - Bu işlem ram ve cpu harcar. O yüzden resource governor'dan ilgili administration işlemi için ram ve cpu sınırlaması yapılabilir.

 - Alınmış normal backup rar'landığında da %90'a kadar sıkıştırma yapılır.

 

Bu serinin sonraki yazısına aşağıdaki linkten ulaşabilirsiniz.

Backup Restore Planlaması - III

 

Kaynak : Wrox SQL Server 2008 Administration, MSDN

 

Etiketler: , | Kategoriler: Sql Server Emrah Uslu | 06.10.2011 14:17

 

Bu yazı, sql server için yedekleme ve kurtarma konusunda kendim için tuttuğum notlardan oluştuğu ve fazla düzenleme yapmadan burada paylaştığım için yazıdaki dilden dolayı özür dileyerek başlayayım.

Şirketler iş süreçlerinin devamlılığı için veritabanı yönetim sistemleri üzerinde Yüksek Erişilebilirlik (High Availability) çözümleri uygularlar.

  - Failover Cluster
  - Database Mirroring
  - Transaction Log Shipping
  - Replication

Böylece canlı sql sunucusunun bir sebeple taleplere yanıt verememesinin ardından stand by bir sunucu üzerinde iş süreçlerinin devam etmesi sağlanır. Yüksek erişilebilirlik çözümleri datanın online olmasını sağlamasına rağmen iş verisini korumak için bir backup stratejisinin varlığı zorunludur. Mesela geliştirici yada admin kaynaklı veri hatası, aşırı yüklenmeden dolayı veritabanının erişilemez olması gibi durumlarda admin, backup'dan recover ederek db'nin tutarlı bir konuma geçmesini sağlar.

VERİTABANININ BOZULMA SEBEPLERİ

Hardware failure : High availability çözümleri var; ancak bir diskin I/O failure vermesi ve datayı bozması gibi yüksek erişilebilirlik çözümlerinin devreye giremediği durumlar gerçekleşebilir.

User Error : Yanlışlıkla data silmek, delete'e where eklememek, tabloyu drop etmek, test sunucusunda sanıp, canlıda değişiklik yapmak, transaction kullanmamak.

Not : Bazı tool'lar transaction log'ları okuyup istenen transaction'ları restore edebiliyor (Log Explorer, ApexSQL vb.)

Application Failure : Uygulamadaki bir bug

Software Failure : İşletim sistemi çökebilir. Driver'lardan biri bozulabilir.Bundan korunmak için service pack ve patch'leri takip etmek ve kurmak gerekir. Bu sql yada makineyi restart etmeyi gerektirebilir ancak high availablility çözümünün devreye girmesindense planlanmış kısa bir bakım tercih edilebilir. Desteklenen ve güncellenmiş driver'lar makinenin ve dolayısıyla makine üzerinde çalışan uygulamaların performansını artırır.

Haddinden Fazla Yetki : Sql server login'lerini kullanan uygulamalar ve kişiler, olması gerkenden daha fazla yetkiye sahip olabilirler. Mesela dbowner, sysadmin vb. gibi yetkilerle bug veya free-form sorgu ekranında yanlış tablo silinebilir. DBA'ler de normal kullanıcı ve sysadmin kullanıcısını ayrı ayrı kullanırlarsa onlar da "ahh, yanlış sorguyu yanlış yerde çalıştırdım" dan sakınmış olurlar.

Lokal Felaket : Data Center'ın zarar görmesine sebep olacak deprem, sel vb. felaketler için farklı coğrafyalarda yüksek erişilebilirlik çözümleri ve backup merkezleri olmalıdır. Bütün bu durumlar için kurumsal bir plan yapilmalıdır :

  - High Availability (Yüksek erişilebilirlik)
  - Backup/Restore (Yedekleme/Geri Yükleme)
  - Disaster recovery (Felaket Kurtarma)

Bu planları hayata geçirmek için risk/fayda analizi yapmak lazım. Downtime süresi ve bize potansiyel maliyeti, gerçekleşen olayla ilgili bize diğer potansiyel maliyetleri, üretilecek çözümün bize maliyeti hesaba katılmalıdır. Bunun için riskler, maliyet ve faydalar için araştırma ve ardından dokümantasyon yapılmalıdır. Burada risk yönetiminin karar vericisi DBA (veritabanı yöneticisi) değildir, şirketin yönetimidir. Ardından DBA, oluşturulan planı hayata geçirmeli ve düzenli aralıklarla test etmelidir.

 

BACKUP / RECOVERY PLAN

1. İş Gereksinimlerini Analiz Et

  • Her uygulamanın ve veritabanının sahibi kim
  • Bu veritabanının amacı ne
  • Bu uygulama / veritabanı için kabul edilebilir downtime nedir
  • Değişen veriler hangileridir ve ne sıklıkla değişirler
  • Ne kadarlık bir veri kaybı kabul edilebilir (Bu zamanla değişebilir, o yüzden backup plan ve stratejileri zamanla güncellenmelidir)
  • Veritabanının boyutu ve büyümesi nedir
  • Bu veritabanı için Maintenance Window nedir? (index, dbcc, backup, sistemin online response'unu etkileyebilir. Bunların zamanlarını kontrol et)
  • Bu veritabanı için belli bir bütçe var mı?
  • Bir veritabanı hatası gerçekleştiğinde kimin haberi olacak, nasıl haberi olacak 

 

2. Veritabanlarını Kurtarma Kriterlerine Göre Kategorize Et

Kritiklik : mission-critical (article, statistic, sales tabloları gibi)

Size : Büyük veritabanlarının, küçüklere göre backup ve restore süreleri daha uzun olacaktır. Bu süre filegroup backup'ı ve diğer yöntemlerle azaltılabilir.

Volatility : Büyük miktarda veri değişimi alan veritabanlarının, aktif olmayan veritabanlarına göre farklı bir plana ihtiyaçları vardır.

Bu 3 kritere göre hangi veritabanının, hangi kategoriye gireceğine karar verilir; ardından planlar bu gruplara göre yapılabilir.

 

3. Kategorilere İsim Ver

 Aşağıdakilere benzer, faydalı olabilecek şekilde gruplar isimlendilir.

  • Mission Critical with High Acticity (Yüksek aktiviteli iş kritik)
  • Mission Critical with Low Acticity (Düşük aktiviteli iş kritik)
  • Non-Critical  (Kritik olmayan)  

 

4. Her kategori için aşağıdakilere karar vermek gerekiyor

 a) Recovery Modeli

  • Veri kaybını minimize et (FULL)
  • Bulk load işlemlerinin performansını artır (BULK-LOGGED)
  • Bakım maliyetlerini düşür (SIMPLE)

 b) Backup Planı

Her bir kategoriye giren veritabanı için full backup, belirli periyotlarla alınacaktır. Bunun dışında aşağıdaki kriterler göz önünde bulundurularak diğer yedekleme alternatifleri plana dahil edilmelidir.

  • Belirlenen kategori ve recovery modeline göre
  • İhtiyaç duyulan backup sıklığına göre
  • Backup Güvenlik politikasına göre

 

5. Dokümantasyon yapmak lazım

 Şu ana kadar 2 tane dokümantasyonun hazırlanmış olması gerekiyor.

  • Biri iş gereksinimleri için insanlarla yapılan görüşmelerden ortaya çıkan liste
  • İkincisi ise veritabanı kategorizasyonu ile ilgili olan liste.

Bu 2 doküman haricinde şunların da dokümante edilmesi gerekir :

i) Contact List

Acil durumlarda kimler aranacak, onları kim arayacak, bunların telefon numaraları, mail adresleri, ev adresleri vb. Aynı zamanda ihtiyaç halinde vendor, teknisyen, ulaşım hizmet verenler vb. iletişim bilgileri bulunsa iyi olur.

ii) Karar Ağacı

Hangi durumda ne yapılacağını sırayla ve mantıklı bir şekilde anlatan bir doküman. Stres halindeyken yardımcı olması amacıyla kullanılır.

iii) Recovery'nin Başarılı Kriterleri

Veritabanlarına göre geri dönüşün başarılı olduğundan emin olmak için kullanılır.

iv) Key'ler, backup'lar, yazılım ve donanımların lokasyonu

Makinelerin ip'leri, şifreler, otomatik backup'ların nereye alındığı vb.

v) Infrastructure Dokümantasyonu

İsimlendirme düzeni, dns/network bilgileri vb.

 

6. Planı Onaylamak, Uygulamak ve Test Etmek

Belki işin en zor kısmı budur. Planı hazırlamak yetmez. Çalışmayan bir plan işe yaramayacaktır.

 

7. Backup Hata Alırsa Bundan Haberdar Olun

Düzenli backup alma sürecinin başarılı bir şekilde devam ettiğini, alınan backup'ların kullanılır olduğunu garanti etmek gereklidir.  Eğer süreçte bir hata varsa bundan haberdar olunması gerekir.

Ayrıca dikkat edilmesi gereken bir diğer konu şudur : Db backup işlemi, diğer bakım işlemlerinden sonra alınmalıdır. Index, db shrinking gibi. 

 

Bu serinin sonraki yazılarına aşağıdaki linklerden ulaşabilirsiniz.

Backup Restore Planlaması - II

Backup Restore Planlaması - III

 

Kaynak : Wrox SQL Server 2008 Administration, MSDN

 

Etiketler: , , | Kategoriler: Sql Server Emrah Uslu | 27.09.2011 09:37

Hangi raporlama aracı olursa olsun (gerek kendi yazdığımız, gerek Microsoft ya da başka bir şirketin ki) veritabanı biraz büyüdükçe işler karışmaya başlar. Bir uygulama için veritabanı tasarlanırken iki ana amaç vardır ve veritabanı motorunun en önemli görevleri de bunlardır :

  • insert, update, delete işlemleri hızlı çalışsın. Tablolar arasında ilişkiler olsun.
  • Veriler tutarlılığını korusun. Veri tekrarı olmasın.

Neden Analiz Servis?
Analiz servis gibi bir yapıya ihtiyaç duyulmasının sebebi raporlamanın canlı ve büyük veritabanı sistemleri üzerinden doğrudan alınmak istenmemesinden kaynaklanır aslında.Çünkü canlı sistemlerde (-OLTP- yani şirket bünyesinde bir ya da daha fazla uygulamanın doğrudan beslediği/beslendiği veritabanı sistemleri) kendimizi tekrar etmemek ve veri bütünlüğünü sağlamak için normalizasyon yapılır. Böyle bir veritabanında rapor almak istediğimiz vakit örneğin 10 tane tabloya gitmek gerekebilir; ki bunların çoğu da hatırı sayılır boyutlarda kayıt ve kolon kombinasyonuna sahip olabilir. Kullanılan ram'in maksimum 8 - 16 gb. olduğunu düşünürsek (Tabi bunun tamamını rapor sistemleri için ayıramadığımızı gözden kaçırmayalım) bu boyutta verinin belleğe çıkması sorun olacaktır.(Arttırılabilse de 32 bit makinelerde sql server'ın adresleyebileceği bellek alanı varsayılan olarak bu değerlere çıkamaz zaten) Bu sorunlar, rapor alanların raporlarını yavaş alması, sistemin çalıştığı uygulamalardan birinin yavaşlaması ya da kilitlemesi şeklinde baş gösterebilir. Sonrasında senaryo genelde şu şekilde cereyan eder : Programı kullanan son kullanıcı şirketteki yazılım departmanını, raporu alan son kullanıcı ise şirketin veritabanı yöneticisini arar ve derdini anlatır. Problem karşısında alınabilecek tek aksiyon çoğu zaman uygulamanın ve/veya rapor sürecinin durdurulması ve sırayla!!! tekrar başlatılması olur. Hatta veritabanı yöneticisi, -gerçek problemin farkında ya da değil- raporun sorgusunu inceler ve "dur ben şu kolona bir index atayım da rapor hızlansın" şeklinde geçici çözümler üreterek günü kurtarmaya çalışabilir. Canlı sistemdeki ham verinin, aynı zamanda raporlama ve analiz için kullanılması sağlıklı değil, tamam; peki neler yapılabilir?

Özet Tablolar
Canlı sistemin DML (Data Manipulation Language -veri üzerinde güncelleme yapan komutlar kümesi-) sorgularının dışında kalması gereken farklı bir tablo yapısı için akla gelebilecek olan çözümlerden birisi, aynı veritabanı yapısı içerisinde özet tablolar ile çalışmak olabilir. Ham veri içeren tablolardan trigger'lar ile beslenen ya da bir uygulama ile belli aralıklarla hesaplatılan özet tablolar örneğin yıllara, şehirlere ve mağazalara göre toplam satış rakamlarını hazır bir şekilde saklayabilir. Almak istenilen her rapor için bu konseptte özet tablolar hazırlanıp ve bu tablolardan hızlı bir şekilde raporlama yapılabilir. Ancak özet tabloların güncellenmesi trigger'lar yerine bir uygulama aracılığıyla yapılırsa kaçak olması ihtimali vardır; yani yanlış özet bilgilerin hesaplanması mümkündür. Tabi ki tutarsız veri istemeyiz. Bu tarz kaçakları önlemek için trigger'lardan faydalnılsa dahi yönetim zorluğundan kurtulmak için başka çözümler aranabilir.

Indexed View
Rapor alınmak istenen özet tablo bir view olarak saklanabilir. Üzerine clustered index atılmış bir view, verisini sıralı tutmak isteyeceğinden kendi üzerinden saklar ve veri dosyasında bağımsız bir bellek alanı kullanmaya başlar. Gerçek verilerin orjinal tablolardan hesaplanarak view'e aktarılması, sql server database engine'i tarafından sağlanacağından veri tutarsızlığı problemi aşılmış olur ve yine raporlar hızlıca alınabilir.. Bu aşamada dikkat edilmesi gerekn bir detay ise OLTP sistemdeki transaction'ların yazılmasının yavaşlayacaktır. Çünkü yapılan her işlem, aynı zamandan bir view üzerinde aggregate function'larla (sum, avg, count vb.) hesaplanan işlemleri yanında getirdiği için 2 adım ileri gitmeye çalışırken 1 adım geri gitmeye sebep olabilir. Tabi bu senaryo, verinin boyutunun anlamlı büyüklüklere ulaştığı zaman geçerli olacaktır.

OLAP Cube
Bu yüzden cube denen ve verinin OLTP'dekinden farklı yapıda saklandığı sistemler vardır. Küpler ile veri yapısnın, istenen raporların alınması için önceden hazırlanması amaçlanır. Farklı boyutlarda (ürün, zaman, müşteri, mekan vb) farklı ölçülebilir büyüklüklerin (satış, karlılık vb.) bütün kesişimlerindeki verilerin raporlanmak için hazır bekleyeceği bir altyapı sunan OLAP küpleri sayesinde sağlıklı bir veri yapısı ve hızlı bir raporlama altyapısına sahip olunabilir.Bu arada küp teriminin kullanılmasından dolayı, hesaplanmış bir şekilde bekleyen verilerin bulunduğu yüzlerin sayısının matematikteki küp'ün yüz sayısı (6) ile aynı olmak zorunda olduğu akla gelmesin. Sadece çok boyutlu bir yapıyı temsil ettiğini göstermek için bu terim kullanılmaktadır. Bir analiz servisi kübü üzerinden çeşitli araçlar ile analizler yapılabilir ve raporlar tasarlanabilir. Bunlara örnek olarak aşağıdakiler gösterilebilir:

  • Sql Server Reporting Service,
  • Sharepoint Performance Point Service,
  • MS Office Excel ya da sql server analiz servisin kendisi ile veri madenciliği (data mining),
  • Analiz servisin kendi sağladığı arayüzde pivot table mantığında analizler,
  • PowerPivot 

Data Warehouse
Bir OLAP kübünün verisini nereden aldığı incelenecek olursa process denen bir süreç sonunda verinin bir veritabanı sisteminden çok boyutlu yapılara alındığı söylenebilir.Bir kübün process edilmesi ile kaynak verileri alarak yüzeylerindeki hesaplamaları güncellemesi sağlanır. Tahmin edersiniz ki raporlanacak verinin, taze veri olma ihtiyacına bağlı olarak bu işlem belirli aralıklarla tekrarlanmalıdır (job'lar yardımıyla) Burada kübe kaynak veriyi sağlayan veritabanı ortamı, canlı bir uygulama grubunun beslediği bir OLTP veritabanı sistemi olabileceği gibi OLTP ve OLAP kübünün arasında yerini alacak başka bir veritabanı ortamı da olabilir. Bu ara veritabanı ortamının veri yapısı, canlı sistemin isteklerinin aksine raporlama sisteminin isteklerini gözetecek şekilde dizayn edilir. Veri ambarı (data warehouse) diyeceğimiz bu sistemde, OLTP veritabanlarının aksine veri tekrarı yapmaktan korkmayız, daha genel bir ifadeyle normalizasyonu sıfıra yakın kullanırız; böylece mağazalarımızın adreslerini tutmak için 5-6 ayrı tablo yerine tek tablo kullanabiliriz, hesaplanan kolonları veri dosyasına yazılı bir şekilde tutarız, anahtarlar ve kısıtlamalardan olabildiğince kaçarız vb. Bütün bunların amacı, veriyi canlı veritabanı sisteminden veri ambarına daha hızlı bir şekilde pompalamak ve raporlamaya uygun bir şekilde hızlı select atılabilmesini sağlamaktır. Veriyi canlı sistemden veri ambarına pompalamak için bir ETL (Extract - Transform - Load) aracının kullanılması gerekir. Microsoft Sql Server 2005 içerisinde bu iş için kullanılan araç SSIS'dir (Sql Server Integration Service). Veri transferi için hazırlanan SSIS paketleri belirli aralıklarla çalıştırılarak rapor verisinin veri ambarına aktarılmasında başrol oynar. Veri ambarı içerisinde tartışılması gereken fact tablolar, dimension tabloları vb. kavramları sonraki makalere bırakalım. Akla gelebilecek bir soruyu cevaplandırarak makaleyi sonlandıralım: Madem veri ambarının veri yapısı OLTP'ye nazaran raporlamaya daha uygun yapıdadır ve canlı sistemin güncellemelerinden uzakta ayrı bir veritabanı yapısı olarak tasarlanmakta ve beslenmektedir; neden raporları buradan almıyoruz da gidip bir de analiz servis ile küp tasarlıyoruz ve raporları oradan alıyoruz? Aslında bu sorunun cevabı yukarıda bulunmaktadır. En başta veri ambarı, her ne kadar veriyi OLTP bir veritabanına göre raporlamaya daha uygun tutsa da bir OLAP kübünün yaptığı gibi farklı boyutlardaki ve ölçülebilir büyüklükteki veriyi küpte tasarlanan çok boyutlu veri yapısındaki her kesişim noktası için hesaplayarak (process işlemi sonrası) rapor alınmaya hazır bir şekilde bekletmez. Rapor anında birçok hesaplamanın yapılması gerekir ki bu da bizi birincil amacımız olan daha performanslı raporlar almaktan uzaklaştırır.Ayrıca eklenebilecek ikinci bir sebep, küp üzerinden kolayca gözlem ve analiz yapılmasını sağlayan pivot mantığının sadece veri ambarı ile bu kolay yapılamayacak olmasıdır.

Etiketler: , , | Kategoriler: Sql Server Emrah Uslu | 26.09.2011 22:47

OLAP kavramını tanımlamak zor olsa da; zaman, ürün, müşteri, lokasyon bilgisi vb. farklı boyutların hepsinin ya da bazılarının dahil olduğu çok boyutlu metrikleri analiz edebilme yeteneği olarak ifade edilebilir. Bu tanım çerçevesinde business intelligence (kurumsal iş zekası) dünyasını tanımak için yol alalım.

Veri Analizine Neden İhtiyaç Duyulur?

Şirketler, anahtar iş performansı metriklerini anlamaya ihtiyaç duyarlar. Bunlar kar ve kayıp ya da birim satış olabileceği gibi iş tipine göre çok sayıda metriği bi arada barındırabilir. Örneğin bir hava yolu şirketi, doluluk oranları ile ilgilenirken; üretim yapan bir fabrika, hatalı üretim oranları ile ilgilenebilir. Şirketler, iş trendlerini ve konularını belirlemek isterler. Ayrıca kesitirmci modeller kullanarak, tahmin edebilecekleri davranışları belirlemek isterler. Predictive (kestirimci) modeller, geçmiş veriye bakarak gelecek sonuçları tahmin ederler. Örnek olarak borsa verilerini değerlendirmek ya da geçmiş kredi ödemelerine bakarak bir banka müşterisinin yeni kredi başvurusunu değerlendirmek vb. verilebilir.

Veri Analizi Çözüm Tipleri

Veri analizi çözümlerinin farklı formları vardır. İş sürecinin farklı ihtiyaçlarına göre hangisinin uygulanacağı değişkenlik gösterir. Veri üretmek için gerekli süreç, çözümün toplam ownership maliyeti (TCO –total cost of ownership-), ilişki ihtiyacı ve tahmin trendleri, hangi çözümün seçileceğini etkiler.

Relational Reporting:
Doğrudan OLTP veri kaynaklarından (canlı sistemlerin beslediği/beslendiği veritabanı sistemleri diyebiliriz) anlamlı veri çıkarmak için Sql Server Reporting Service gibi araçlar kullanılır. İlişkisel raporlama, kullanıcılara özet veri göstermek için hızlı ve efektif çözüm sunar. Veri, rapor üretildiği sırada özetlendiği için canlı sisteme büyük işlem yükü getirir. Buna çözüm olarak raporlar cache’lenebilir.

OLAP Reporting:
Olap sistemleri, çeşitli kategoriler üzerinden çeşitli düzeyde veriyi toplar ve saklar. Bu format interaktif analizler için idealdir ve tipik oltp raporlama uygulamalarına göre daha hızlı ve sezgiseldir. Canlı sistem tarafından taze veri ihtiyacına bğlı olarak belirli aralıklarla beslenen bir veri ambarı üzerinden bir raporlama aracı kullanılarak elde edilen çözümlerdir.

Data Mining :
Veri madenciliği, gizli modeller ve ilişkileri bulmak için büyük miktarda veri üzerinde çeşitli algoritmalar kullanarak arama yapma sürecidir. İş sorumlusu, sorumlu olduğu alanda süreci etkileyen ana sebepleri bilmesine rağmen bir veri madenciliği algoritması, etkenlerin her birini ağırlıklandırır ve gözden kaçabilen ilişkileri gösterebilir. Başarılı bir algoritma, geçmiş veriye bakarak gelecek verileri tahmin eder; ayrıca tahminler eldeki veriler ile test edilir. Veri madenciliği, OLTP ve OLAP sistemlerin her ikisi üzerinde de kullanılabilir.

Temel OLAP Konseptleri

OLAP çözümleriyle ilgili çok sayıda anahtar konsept mevcuttur. Analiz servis ile OLAP çözümleri planlanıp uygulanırken bu konseptlerin anlaşılmış olması önemlidir:

Data Warehouse (Veri ambarı):
Veri ambarı, iş analiz sürecine veri sağlamak için doğrulanmış farklı yapıdaki kaynak veriyi birleştirir. Veri ambarındaki veri, genellikle de-normalize durumdadır; böylece veri analizi için optimum şemayı oluşturmak ve veri ambarı tablolarından OLAP çözümünü inşa etmek kolaylaşır. Bir veri ambarı, data mart’ların sanal bir birleşimi ya da data mart’lardan kaynak veri sağlayan merkezileşmiş bir saklama yeri olabilir.

Data Mart:
Belli bir konu ya da iş aktivitesi üzerine veri sağlayan birkaç veri ambarı kümesidir.

Fact:
Facts, ağırlıklı olarak fiyat ya da miktar gibi nümerik ölçülerdir. Toplamak ve analiz etmek istenen anahtar iş parametrelerini temsil eder. Facts, hesaplamanın temellerini oluşturur ve çoğu zaman fact’leri bir dimension’ın üyeleri için toplarız.

Dimension (Boyut):
Dimension, fact’ler için bir alan oluşturur, sonucu etkileyen eksenlerdir. Toplanan, ortalaması alınan vb. fact’ler tarafından işin görünümü tanımlanır. Örneğin bir dimension, bir ürün ya da bir mağaza olabilir. Tipik bir sorgu ise her bir mağazada satılan her bir ürün biriminin toplam miktarlarını elde eden bir sorgu olabilir.

Cube:
Küp, çok boyutlu yapıların içerisinde işlenmiş (ya da özetlenmiş) fact ve dimension verisini saklar. Küpler, kendilerinden veri okunması için optimize edilmiştir ve kullanıcların veri ambarındaki veriye erişmek için giriş noktalarıdır.

Slicing and Dicing :
Bu terimler, iş analistlerinin OLAP kübü içerisindeki veriyi nasıl kullanacaklarını tanımlamak için kullanılırlar. Slicing, bir dimension’ın bir ya da faha fazla üyesini izole etmeyi ve onu diğer dimension’lar üzerinden hesaplamayı gerektirir. Örneğin her ay, her mağazanın bisiklet satışları hesaplanabilir. Bu örnekte bisiklet verisi döndürmek için ürün dimension’ı slice edilir. Dicing ise tek bir sonuç döndürmek için çoklu dimension’lardan üyeleri izole etmeyi gerektirir. Örneğin 2011 Mart’ında Münih’deki bisiklet satışları hesaplanabilir.

Pivot Table :
Pivot tabloları, kullanıcılara OLAP küplerini taramak için sezgisel bir arayüz sağlar. Kullanıcılar detaylı bilgi için drill down yaparak, özet bilgi için drill up yaparak pivot tablolarını kullabilirler. Aynı zamanda kullacılara veriyi slice ve dice edebilmek için de arayüz sağlamaktadır.

Etiketler: , | Kategoriler: Sql Server Emrah Uslu | 26.09.2011 22:26

Veri madenciliği yüzlerce iş problemini çözmek için kullanılabilir. Problemin doğasına bağlı olarak bu görevleri gruplamak mümkündür. Makalede bu gruplama, Microsoft Sql Server ile veri madenciliğinden bağımsız olarak ele alınmaktadır. İşte veri madenciliği görevlerinden en önemlileri :

Classification:
Sınıflandırma, en popüler veri madenciliği görevlerinden biridir. Churn analyze, risk management, ad targeting, çoğunlukla sınıflandırma yapmayı gerektirir. Sınıflandırma, tahmin edilebilir bir kolon tabanlı olarak kategorilere case’ler atanması ile ilgilidir. Her case, birkaç tane attribute’dan oluşur ve bu attribute’lardan bir tanesi class attribute’udur (yani tahmin edilecek olan kolon). Bu görev, input attribute’larının bir fonksiyonu olarak class attribute’unu tanımlayan bir model bulmayı gerektirir. Bir sınıflandırma modelini eğitmek için training dataSet’i içerisindeki input case’lerinin class value’su bilinmelidir. (Yani input case’leri iq, aile teşviki ise bu case’lerdeki lise öğrencileri koleje devam etmişler mi bilgisi elimizde olmalı. Bu veri de çoğunlukla geçmiş verilerdir). Bir şeyler öğrenmeye çalışan veri madenciliği algoritmaları supervised algorithm olarak bilinir. Tipik sınıflandırma algoritmaları : Decision tree, neural network, naive bayes olabilir.

Clustering:
Aynı zamanda segmentation adıyla da bilinir. Birkaç tane attribute tabanlı case’lerin doğal gruplaşmasını tespit etmek için kullanılır. Aynı gruptaki case’ler, çok ya da az benzer attribute değerlerine sahiptir. Aşağıdaki basit müşteri veri kümesi iki tane attribute içermektedir: Yaş ve gelir. Clustering algoritması, bu iki attribute tabanlı olarak veri kümesini 3 segmentte gruplar.

  • Cluster 1, düşük gelir grubuna sahip genç popülasyon
  • Cluster 2, daha yüksek gelirli ve orta-yaşlı popülasyon
  • Cluster 3 ise daha düşük gelirli ve yaşlı popülasyonu temsil ediyor.

Clustering, unsupervised bir veri madenciliği görevidir (Yani kullanılan model eğitilerek birşeyler öğrenmeye çalışmaz). Training sürecine rehberlik etmek için tek bir attribute kullanılmaz. Bütün input attribute’ları eşit görülür. Birçok clustering algoritması, sayısız döngü kullanıp model yakınsayınca durarak modeli oluşturur. Modelin yakınsamasından kasıt; segment sınırlarının stabil hale gelmesidir.

Kümeleme sonucu:

 

Association:
Popüler bir veri madenciliği görevidir. Diğer adı market basket analyse dır. Tipik bir association iş problemi, satış hareketlerini analiz etmek ve satılan ürünlerin bazen aynı alış-veriş sepetinde yer aldığını tespit etmektir. Association tekniğinin yaygın kullanımı; birlikte alınan parça setlerinin ve cross-satış kurallarının tespitidir. Association açısından, her ürün (ya da daha genel olarak her attribute/değer çifti), bir item olarak ele alınır.

Association görevinin iki temel amacı vardır:
1) Sık karşılaşılan item set’leri bulmak
2) İlişki kurallarını bulmak

Birçok association tipindeki algoritma, sık karşılaşılan item set’leri bulmak için veri kümesini (dataset) defalarca tarar. Frequency threshold (sıklık desteği), model process edilmeden önce kullanıcı tarafından belirlenir. Örneğin support = 2% ‘ nin anlamı şudur : Model, alış-veriş kartının minimum yüzde 2’sinde bulunan ürünleri analiz eder. Sık sık karşılaşılabilcek olan bir item-set şöyle olabilir:

{Ürün = “Cola-Turka” , Ürün = “Cips” , Ürün = “Meyva suyu”}.

Her item-set’in (ürün paketinin) bir boyutu vardır; bu da item-set’in içerdiği ürünlerin (items) sayısıdır. Yukarıdaki item-set’in boyutu (size) 3’tür. Belirlenen support yüzdesindeki sık karşılaşılan item-set’lerin tespiti dışında birçok association algoritması aynı zamanda kurallar bulur. Bir association kuralı şu şekiledir : Belli bir olasılıkla A, B => C. Burada A,B ve C her biri ayrı item-set’ler, yani ürün paketleri.

Veri madenciliği literatüründe olasılık (probability) aynı zamanda güvenilirlik (confidence) olarak da adlandırılır. Güvenilirlik düzeyi, kullanıcının bir association modelini train etmeden önce belirlemesi gereken bir sıklık destek değeridir. Yani analiz sonucunun % kaç güvenilirlik düzeyindeki sonuçları getirmesi istenildiği belirlenir.

Tipik bir ilişki kuralı şöyledir : %80 güvenilirlikle Ürün = “Cola-Turka”, Ürün = “Cips” => Ürün = “Meyva Suyu“. Bu kuralın açıklaması gayet basittir. Kola ve cips alan bir müşterinin bunlarının yanında meyva suyu alma şansı %80’dir.

Yukarıdaki şekil, bir ürün ilişki desenini göstermektedir. Şekildeki her node bir ürünü; her çizgi ise ilişkiyi temsil etmektedir. Çizginin yönü, ilişkinin yönünü belirler. Örneğin Milk’den Cheese’e giden çizgi, süt alan birinin aynı zamanda peynir de aldığını gösterir.

Regression:
Classification’a benzer. Temel fark, tahmin edilecek olan attribute’un continious number (parçalanabilir birimler -1.5, 23.8 gibi-) olmasıdır. Regresyon tekniği yüzyıllardır istatistik ana bilim dalının bir kolu olarak öğretilmektedir.Lineer ve lojistik regresyon, en popüler regresyon metotlarındandır. Diğer regresyon teknikleri ise regresyon ağaçları ve sinir ağlarıdır (neural network). Regresyon görevi ile birçok iş problemi çözülebilir. Örneğin nominal değerine, dağılım metoduna, dağılım hacmine bakarak bono ödeme oranları tahmin edilebilir. Ya da sıcaklık, hava basıncı ve nem değerlerine göre sıcaklık tahmini yapılabilir.

Forecasting:
Yarın ki borsa değeri ne olacak?... A şirketinin önümüzdeki ay toplam satış miktarı ne olacak?... Forecasting bu tarz soruların cevaplanmasına yardımcı olur. Genellikle girdi olarak bir zaman serisi veri kümesi alır; örneğin zamanı temsil eden bir attribute ile bir dizi sayı. Zaman serileri verileri genellikle sıra bağımlı bir şekilde birbirine yakın değerlere sahip olurlar. Forecasting teknikleri, genel trendler, periyodiklik ve gürültülü gürültü filtreleme (noisy noise filtering) ile uğraşır. En popüler zaman serileri tekniği ARIMA’dır. (AutoRegressive Integrated Moving Average)

Diğer önemli veri madenciliği görevleri:
Sequence Analysis, Deviation Analysis

Etiketler: , | Kategoriler: Sql Server Emrah Uslu | 25.09.2011 10:00

Business intelligence (kurumsal iş zekası) ürün ailesinin anahtar üyelerinden birisidir. Bu ailenin diğer üyeleri; etl, olap ve enterprise raporlamadır (MS Sql Server'ın bu üyeler için var olan çözüm araçları sırasıyla Sql Server Integration Service, Sql Server Analyse Service ve Sql Server Reporting Service'dir). Veri madenciliğinden, veriyi analiz etmek ve veri kümesi içinde yer alan gizli modelleri keşfetmek için faydalanılır. Daha sonra bu modeller, veriyi daha detaylı bir şekilde yorumlamak ve geleceğe yönelik tahminler yapmak için kullanılır. Yani esas amaç, veriyi bilgiye dönüştürmektir.

Örneğin, <<lise mezunlarının üniversiteye devam etmelerini etkileyen faktörler nelerdir>> sorusu sorulduğunda bunun için tabloda kaç tane erkek öğrencinin üniversiteyeye devam ettiğini, kaç tane kız öğrencinin üniversiteye devam ettiğini elde eden sorgular yazarız. Bunun yanında aile desteğinin etkisini test edecek bir sorgu yazarız. Peki ya aile desteği alan erkek öğrenciler ve aile desteği almayan bayan öğrenciler? Bütün bu kombinasyonları ele almak için satırlarca sorgu yazmak gerekir. Ayrıca IQ, aile geliri gibi sayısal formattaki alanların analiz edilmesi daha sıkıntıldır. Bu numerik alanlar için isteğe bağlı aralıklar seçmek gerekir. Peki ya onlarca kolon varsa? Elinizdeki tabloda yer alan veriniz hakkında sorulan basit bir sorunun cevabını verebilmek için yönetmesi imkansız hale gelen sayısız sorguya sahip oluruz.

Buna karşın veri madenciliği ile herşey çok daha basittir. Tek yapılması gereken, doğru veri madenciliği algoritmasını seçmek ve kolon kullanımlarını belirlemektir (Analizin amacı olan tahmin kolonları ve bu amaç için kullanılacak input kolonlarını belirlemek). Bir öğrencinin koleje devam kararında ailenin etkisini belirlemek için karar ağaçları (decision tree) işe yarayacaktır. IQ, cinsiyet, aile geliri ve aile desteği input kolonlar olarak belirlenir; koleje devam kararı kolonu ise tahmin kolonu olarak belirlenir. Karar ağaçları algoritması veriyi tararken, amaç ile ilgili input attribute’larının (kolonlarının) her birinin etkisini analiz eder ve bölmek için en anlamlı attribute’u seçer. Her bölüm, dataset’i iki alt parçaya böler. Böylece kolej planının değer dağılımı birbirinden olabildiğince farklı olur. Ağaç tamamen oluşuncaya kadar bu süreç, her alt parça üzerinde iç içe tekrar edilir. Öğrenme (training) süreci tamamlanınca ağacı gezerek, ortaya çıkan model (pattern) incelenebilir.



Kolej planı dataset’inin yukarıdaki karar ağacında root node‘dan leaf node’a kadar olan her yol ayrı birer kural anlamına gelmektedir. Yani IQ’su 100’den büyük olan ve ailesi destek veren çocuklar, % 94 olasılıkla koleje devam etmektedirler. Veriden bu bilgiyi keşfettik.

Anlatılan örnekte olduğu gibi veri madenciliği, veri kümelerine decision trees (karar ağaçları), clustering (gruplama), association (ilişkilendirme), time series (zaman serileri) gibi algoritmalar uygular ve içeriklerini analiz eder. Bu analizler, değerli bilginin keşfi için modeller üretir. Kullanılan algoritmaya bağlı olarak üretilen model, ağaçlar, kurallar, gruplar ya da basit bir matemetik formülü olabilir. Model içerisinde bulunan veri, satış stratejisi oluşturmaya rehberlik etmesi ve en önemlisi tahmin için raporlamada kullanılabilir. Örneğin önceki karar ağacının ürettiği kurallara bağlı olarak, orjinal dataset’de yer almayan lise öğrencilerinin koleje devam edip etmeyeceğinin tahmini yapılabilir.

Neden Veri Madenciliği?

Elde var olan büyük miktardaki veri:

Harddisk fiyatları son on yılda iyice düştü. Buna bağlı olarak şirketler, uygulamalar aracılığıyla büyük miktarda veri topladılar. Şirketler, keşfedilmeyi bekleyen bu verilerin iş stratejilerine rehberlik etmesi için gizli modelleri bulmak istiyorlar.
Rekabetin artması :
Modern satış ile internet ve iletişim gibi dağıtım kanallarının bir sonucu olarak rekabet çok yüksek. Şirketler uluslararası rekabet ile karşı karşıyalar ve bu noktada başarının anahtarı; var olan müşterileri korumak ve yenilerini elde etmek. Veri madenciliği, şirketlerin bu konuları etkileyen faktörleri analiz edebilmelerine izin veren teknolojiler içermektedir.
Hazır teknoloji :
Veri madenciliği teknoljileri, önceleri sadece akademik çevrede kabul görmekteydi. Ancak bu teknoljiler son yıllarda olgunlaştı ve günümüz endüstrisinde kullanılmak için hazır hale geldi. Algoritmalar daha doğru, daha etkili ve gittikçe artan karmaşıklıktaki veriyi ele alabilmektedir. Ayrıca veri madenciliği için kullanılan programlama arayüzleri standartlaşmakta, böylece geliştiriciler daha iyi veri madenciliği uygulamaları geliştirebilmektedirler.

Veri Madenciliğinin Çözüm Ürettiği İş Problemleri

Churn analyse :

Hangi müşterilerimiz rakiplerimize kaymaya daha çok meğilli... Telekom, bankacılık ve sigorta sektörleri günümüzde bu tehlike ile sürekli karşı karşıyalar. Churn analizi, şirketlere müşterilerinin neden başka şirletler ile çalışmak üzere göç ettiklerini anlamaları için yardımcı olur, müşteri ilişkilerini kuvvetlendirir ve sonunda müşteri sadakatini arttırır.

Cross selling :
Müşterilerimiz daha çok hangi ürünleri almaya meğilliler... Ürün satan şirketler için cross-selling önemli bir dinamiktir. Özellikle online satıcılar, satışlarını arttırmak için bu tekniği kullanırlar. Örneğin online olarak kitap satın almak için amazon.com gibi bir siteye girdiğinizde web sitesi o ana kadar ilgilendiğiniz kitaplarla ilgili olan başka kitaplar hakkında size çeşitli tavsiyelerde bulunur. Bu tavsiyeler veri madenciliği sonucu çıkarsanabilir.

Fraud Detection :
Acaba bu müşteri, sigorta talep eden bir sahtekar mı... Sigorta şirketleri günde binlerce talebi işleme alırlar. Her birinin gerçekliğini ayrı ayrı araştırmak çok da mümkün değildir. Veri madenciliği, gelen talebin sahte olabileceğini tanımlamak için yardımcı olabilir.

Risk Management :
Bu müşterinin kredi talebini onaylamalı mıyım... Bankacılıktaki en sık karşılaşılan sorulardan birisidir. Veri madenciliği teknikleri, müşteriye risk seviyesi skorlamak için yardımcı olabilirler. Böylece her müşteri için doğru kararın verilmesine yardımcı olunabilir.

Customer Segmentation :
Benim müşterilerim kimler... Müşteri kümeleme , satış yöneticilerinin farklı müşteri profillerini anlamaları ve bu profillere göre farklı aksiyon almaları konusunda yardımcı olur.

Targeted ads :
Spesifik bir kullanıcıya hangi reklamları göstermeliyim... Online satış yapan şirketler ve web portalları, web müşterileri için içeriklerini özelleştirmekten hoşlanırlar. Müşterinin sayfalar ve ürünler arası navigasyonu ve satın alma modellerini kullanarak müşteriye uygun ürünlerin reklamlarını göstermek için bu siteler veri madenciliği çözümlerini kullanabilirler.

Sales Forecast :
Gelecek ay bu mağazada kaç şişe şarap satacağım... Bir aydaki stok miktarım ne olacak? Veri madenciliği tahmin teknikleri, bu tarz zaman ilişkili sorulara cevap vermek için kullanılabilir.

Kategoriler: .NET, Etkinlik Emrah Uslu | 01.04.2011 17:42

Merhabalar,

31 Mart - 1 Nisan 2011 tarihlerinde İzmir'de Dokuz Eylül Üniversitesi tarafından düzenlenen Dokuz Eylül Üniversitesi Uluslararası Hukuk Kongresinde sonuçları yayınlanmak ve tartışılmak üzere bir anket çalışması hazırladım. Veri toplama ve ardından raporlanması şeklinde bir kapsama sahip web tabanlı anket platformunun başarılı bir şekilde sonuca ulaşmasından dolayı, organizasyon ekibi kongre sırasında aşağıdaki plaketi takdim etti. Liseden arkadaşım İlker Tepe'nin ricasıyla gerçekleştirdiğim bu projenin hatırası olarak bir kenarda dursun :)