İki Büyük Felsefe — Inmon ve Kimball

Veri ambarı tasarımı söz konusu olduğunda, sektörde uzun süredir hakim olan iki temel mimari yaklaşım bulunmaktadır: Bill Inmon (Top-Down) ve Ralph Kimball (Bottom-Up).

Peki, bu iki felsefe arasındaki temel fark nedir? Bu seçim, yalnızca teknik bir tercih değil; aynı zamanda bir organizasyonun veriye nasıl yaklaştığını belirleyen felsefi bir karardır.

Bill Inmon: “Top-Down” Yaklaşım

Genellikle “Veri Ambarının Babası” olarak anılan Bill Inmon, DWH’yi tüm işletme için tek bir merkezi gerçeklik kaynağı (single source of truth) olarak görür.

Mimari ve Felsefe:

• Kurumsal çapta (enterprise-wide) bir yaklaşımdır.
• Veriler, kaynak sistemlerden çıkarılır ve merkezi bir Kurumsal Veri Ambarı (Enterprise Data Warehouse — EDW)’ya yüklenir.
• EDW, veri bütünlüğünü sağlamak ve veri tekrarını önlemek için yüksek düzeyde normalize edilmiştir.
• Departmanların ihtiyaç duyduğu özel analiz alanları (Data Mart’lar) bu merkezi ve normalize edilmiş EDW’den beslenir.

Avantajları:

• Yüksek veri bütünlüğü ve düşük veri tekrarı.
• Normalize yapı sayesinde güncellemeler daha kolaydır, esneklik sağlar.
• Kurumsal çapta çeşitli ve entegre raporlama gereksinimlerini karşılar.

Dezavantajları:

• Kurulumu karmaşık, zaman alıcı ve pahalıdır.
• Uzman ve maliyetli bir ekip gerektirir.
• Yüksek başlangıç maliyeti vardır.

Ralph Kimball: “Bottom-Up” Yaklaşım

Ralph Kimball, daha pragmatik ve çevik bir yaklaşım sunar. Bu model, tüm işletmeyi bir kerede modellemek yerine bireysel iş süreçlerine odaklanır.

Mimari ve Felsefe:

• DWH, aşağıdan yukarıya doğru Data Mart’lar şeklinde inşa edilir.
• Her Data Mart, belirli bir iş sürecini (satış, finans, envanter vb.) modellemek için tasarlanır.
• Analiz ve sorgu performansını artırmak için denormalize yapı (Yıldız Şeması) kullanılır.
• Tüm Data Mart’lar birleşerek mantıksal bir DWH oluşturur (Kimball’un “data bus” yaklaşımı).

Avantajları:

• Kurulumu hızlıdır ve ilk aşamalar kısa sürede teslim edilir.
• Boyutsal model, iş kullanıcıları tarafından kolay anlaşılır.
• Başlangıç maliyeti düşüktür ve yinelemeli proje yönetimi yapılabilir.
• Daha küçük ve genel yetenekli ekipler yönetebilir.

Dezavantajları:

• Denormalize yapı, veri tekrarına yol açabilir.
• Farklı Data Mart’lar arasında tutarlılık sağlamak zor olabilir.
• Kurumsal çapta bütüncül analizlerde eksiklik olabilir.

Analist Görüşü: Felsefi Savaş

Bu seçim, teknik bir karardan çok örgütsel bir karardır. Kararı etkileyen faktörler:

• Raporlama Gereksinimleri: Stratejik ve kurumsal çapta raporlama gerekiyorsa Inmon.
• Proje Aciliyeti: Hızlı sonuç gerekiyorsa Kimball.
• Organizasyon Kültürü ve Bütçe: Uzun vadeli değer ve uzman ekip varsa Inmon, hızlı ve çevik çözüm gerekiyorsa Kimball.

Modern Gerçeklik: Hibrit Modellerin Yükselişi

• Modern bulut platformları (Snowflake, BigQuery) depolamayı ve işlemeyi ayırır.
• Depolama maliyetleri neredeyse sıfıra yaklaşır, işlem gücü anlık ölçeklenebilir.
• Hibrit model: Veriler önce merkezi, normalize bir Data Lake veya Staging katmanında saklanır (Inmon benzeri).
• Analistler ve BI araçları için veriler, yüksek performanslı, denormalize Data Mart’lara veya görünümlere dönüştürülür (Kimball benzeri).
• Böylece veri bütünlüğü ve analiz hızı aynı mimaride birleştirilmiş olur.

Mimari Akışların Görselleştirilmesi

Karşılaştırmalı Tablo

Bölüm Özeti

• Inmon (Top-Down): Önce merkezi, normalize EDW kuruluyor; Data Mart’lara dağıtılıyor. Bütünlük yüksek, ama yavaş ve maliyetli.
• Kimball (Bottom-Up): Önce departman ihtiyaçlarına odaklanıyor; Data Mart’lar birleşerek DWH’yi oluşturuyor. Hızlı ama veri tekrarı olabilir.
• Modern Hibrit Yaklaşım: Merkezi Data Lake + performans odaklı denormalize Data Mart’lar. Bütünlük ve hız aynı mimaride birleşiyor.

Günümüzde kurumlar, farklı sistemlerden akan büyük ve dağınık veriyle karşı karşıya. E-ticaret siparişleri, CRM kayıtları, IoT sensör çıktıları, mobil uygulama log’ları… Her bir sistem kendi içinde anlamlıdır, ancak kurumsal ölçekte karar almayı desteklemek için bu verilerin ortak bir yapıda bir araya getirilmesi gerekir. Veri Ambarı (DWH) tam olarak bu ihtiyaca yanıt verir.

Bu yazı dizisinin ilk bölümünde, veri ambarının ne olduğuna, neden ihtiyaç duyulduğuna ve onu operasyonel veritabanlarından ayıran temel kavramlara odaklanacağız.

Neden Veri Ambarına İhtiyaç Duyulur?

Farklı departmanlarda tutulan veriler genellikle dağınıktır. Finans, pazarlama, üretim, insan kaynakları, web uygulamaları veya mobil sistemlerin her biri kendi içinde tutarlı olabilir; ancak kurum genelinde bütünleşik bir bakış sağlamaz. Bir yöneticinin “Son altı ayda müşteri başına ortalama gelir nedir?” gibi basit görünen bir soruya yanıt alabilmesi bile çoğu zaman zordur.

Veri ambarı tam bu noktada devreye girer. Amaç, farklı kaynaklardan gelen verileri merkezileştirerek analiz edilebilir, güvenilir ve tutarlı bir yapıya dönüştürmektir. Ayrıca veri ambarları, operasyonel sistemlerde bulunmayan tarihsel veriyi (SCD, snapshot mantığı) saklama imkânı sunar. Bu sayede geçmişe dönük trendler, değişim kayıtları ve uzun dönemli karşılaştırmalar yapılabilir. Bunun yanında performans açısından da kritik bir rol oynar; analitik sorguların operasyonel sistemleri yavaşlatmasını engeller ve yüksek hacimli okuma işlemlerini verimli şekilde çalıştırır. Tüm bu özellikler bir araya geldiğinde, veri ambarı kurum içinde veri tutarlılığını artırır ve stratejik karar alma süreçlerini kolaylaştırır.

Veri Ambarı Nedir?

Veri ambarı, en temel hâliyle “analiz ve raporlama amacıyla bir araya getirilmiş, temizlenmiş ve dönüştürülmüş verilerin depolandığı sistemdir.”

Operasyonel veritabanlarından farklı olarak veri ambarının hedefi, hızlı yazma işlemleri değil; karmaşık sorguların, toplulaştırmaların ve uzun dönemli analizlerin verimli şekilde çalışmasıdır.

Bir üniversite örneği üzerinden düşünelim. Başvuru sayıları, öğrenci bilgileri, mezuniyet kayıtları, çalışan listeleri gibi veriler farklı sistemlerde bulunur. Üniversite, ilgili kurumlara düzenli raporlamalar yapmak zorundadır. Bu verilerin tek bir model altında toplanması ancak bir veri ambarı aracılığıyla mümkündür.

E-ticarette de benzer bir durum görülür.
“Hangi müşteriler hangi ürünleri hangi kampanya koduyla aldı?”
“Son üç yılda kategori bazlı satış trendi nasıl değişti?”
Bu tip analizler, farklı sistemlerden gelen verilerin bir araya getirilmesiyle yapılabilir.

OLTP ve DWH Arasındaki Temel Fark

Veri ambarını anlamanın en iyi yolu, onu OLTP (Online Transaction Processing) sistemleriyle karşılaştırmaktır.

OLTP (Operasyonel Sistemler)

• Asıl amacı günlük operasyonları yürütmektir.
• Sepete ürün ekleme, ödeme alma, kullanıcı kayıt işlemleri gibi küçük ama yoğun işlemleri yönetir.
• Genellikle yüksek derecede normalize edilmiş, ilişkisel ve satır bazlı tablo yapıları kullanır.
• INSERT ve UPDATE işlemleri çok hızlıdır; çünkü bu sistemler yüksek eşzamanlı yazma trafiğine göre optimize edilmiştir.
• Sorgular çoğunlukla ufak, hedefli SELECT’lerdir (örneğin tek bir kullanıcıyı, siparişi veya ürünü çekmek gibi).
• Temel amaç, operasyonun kesintisiz ve performanslı şekilde ilerlemesidir; bu yüzden analitik sorgulara uygun değildir.

DWH (OLAP — Analitik Sistemler)

• Amaç operasyonu değil, kurumsal analitiği desteklemektir.
• Yoğun okuma, toplu sorgular, trend analizleri ve uzun dönemli raporlamalar için optimize edilmiştir.
• Genellikle denormalize, analitik odaklı ve sorgu performansını artıracak şekilde tasarlanmış veri modelleri kullanır (ör. yıldız ve kar tanesi şemaları).
• Çoğu modern veri ambarı sütun bazlı depolama yapısını tercih eder; bu sayede büyük hacimli tablolar üzerinde yapılan SELECT, GROUP BY, JOIN gibi ağır analitik sorgulara çok hızlı yanıt verir.
• Veriye bütüncül bir bakış sağlar; farklı sistemlerden gelen verilerin ortak bir boyutsal modelde birleşmesini mümkün kılar.

Bu nedenle OLTP ve DWH birbirini tamamlayan iki farklı dünya gibi düşünülebilir.

Staging Area: Veri Ambarının Temizlenme Katmanı

Veri kaynakları her zaman düzenli gelmez. Eksik alanlar, farklı formatlar, tekrarlayan kayıtlar veya tutarsız değerler olabilir. Bu nedenle veri ambarına doğrudan yükleme yapılmaz.

Staging Area, ETL sürecinin en kritik katmanıdır.
Veriler bu alanda:

• Birleştirilir
• Temizlenir
• Standartlaştırılır
• Dönüştürülmeye hazırlanır

Bu sayede hem veri kalitesi yükselir hem de veri ambarının performansı korunur.

OLAP: Analitiğin Çalıştığı Katman

OLAP, veri ambarındaki verilerin çok boyutlu analizini sağlar.
Kullanıcılar veriyi farklı açılardan inceleyebilir:

• Slice (belirli bir boyuttan kesme)
• Dice (alt küme oluşturma)
• Drill-down (detaya inme)
• Roll-up (toplulaştırma)

Bu yapı, iş zekâsı araçlarının hızlı ve esnek analizler üretmesini mümkün kılar.

Sonuç

Bu bölümde veri ambarının temel motivasyonunu, OLTP ve DWH arasındaki farkı, Staging Area’nın önemini ve OLAP’ın analitik dünyadaki rolünü ele aldık. Böylece veri ambarı mimarisinin üzerine kurulduğu temel kavramlar netleşmiş oldu.

Serinin bir sonraki bölümünde, veri ambarı tasarımına yön veren iki klasik yaklaşımı, yani Bill Inmon ve Ralph Kimball metodolojilerini derinlemesine inceleyeceğiz.

Pek sayılmaz.

Veri bilimi dünyasında, metrikler göründüklerinden daha fazlasını anlatır. Basit bir %99 doğruluk oranı, modelinizin işe yaramaz olduğunun da işareti olabilir.
Peki, bir modelin gerçekten “iyi” olduğunu nasıl anlarız?

Bu noktada, doğru performans metriklerini seçme ve yorumlama sanatı devreye girer.
Bu yazıda, metriklerin ne anlama geldiğini, hangi durumda hangisini kullanmanız gerektiğini ve iş hedefleriyle nasıl ilişkilendireceğinizi gerçek dünya senaryolarıyla keşfedeceğiz.

🎯 Sınıflandırma Dünyası: Doğru mu, Yanlış mı?

🔹 Hata Matrisi (Confusion Matrix)

Model performansını anlamanın ilk adımı:

✅ TP (True Positive — Doğru Pozitif)

Modelin “pozitif” olarak tahmin ettiği ve gerçekten de pozitif olan sınıflar.

Örnek: Model bir e-postayı spam olarak işaretledi ve gerçekten de spam çıktı.
Tahmin: 1 | Gerçek: 1

✅ TN (True Negative — Doğru Negatif)

Modelin “negatif” olarak tahmin ettiği ve gerçekten de negatif olan sınıflar.

Örnek: Model bir e-postayı spam değil dedi ve e-posta gerçekten de spam değildi.
Tahmin: 0 | Gerçek: 0

❌ FP (False Positive — Yanlış Pozitif)

Modelin “pozitif” dediği ama aslında negatif olan sınıflar.

Örnek: Model bir e-postayı spam olarak işaretledi ama e-posta aslında spam değildi.
Tahmin: 1 | Gerçek: 0

❌ FN (False Negative — Yanlış Negatif)

Modelin “negatif” dediği ama aslında pozitif olan sınıflar.

Örnek: Model bir e-postayı spam değil dedi ama e-posta aslında spamdı.
Tahmin: 0 | Gerçek: 1

✅ Doğruluk (Accuracy)

Tanım: Tüm tahminlerin içinde doğru olanların oranı.
Formül: (TP + TN) / (TP + FP + TN + FN)

⚠️ Uyarı: Dengesiz veri setlerinde yanıltıcı olabilir.

Senaryo:
Kanser teşhisinde %99 doğruluk = Sadece herkese “sağlıklısın” diyen bir model olabilir.
Bu da modelin asıl görevi olan hastayı bulma konusunda başarısız olduğunu gösterir.

🧠 Stratejik Seçim: Precision mı, Recall mü?

🎯 Hassasiyet (Precision)

Formül: TP / (TP + FP)
Ne zaman önemli? Yanlış pozitiflerin (FP) maliyeti yüksekse.

Örnekler:

• Spam Filtresi: Önemli bir e-postanın spam klasörüne gitmemesi gerekir.
• Çocuk Güvenliği: Uygunsuz bir videoyu güvenli olarak işaretlemek felaket olur.

🔍 Duyarlılık (Recall)

Formül: TP / (TP + FN)
Ne zaman önemli? Yanlış negatiflerin (FN) maliyeti yüksekse.

Örnekler:

• Kanser Teşhisi: Hastayı “sağlıklı” diyerek eve göndermek ölümcül olabilir.
• Kredi Kartı Dolandırıcılığı: Sahte işlemi kaçırmak ciddi finansal zarar verir.

⚖️ Barış Elçisi: F1 Skoru

Formül: 2 * (Precision * Recall) / (Precision + Recall)

Neden önemli?

• Precision ve Recall arasında denge kurar.
• Harmonik ortalama kullandığı için, düşük olan değeri cezalandırır.

Örnek:
Precision = 1.0, Recall = 0.1
→ Aritmetik ortalama = 0.55
→ F1 Skoru ≈ 0.18 (Gerçek durumu daha net yansıtır)

📈 Büyük Resim: AUC-ROC Eğrisi

Tanım: Modelin tüm eşik değerlerindeki performansını gösterir.

AUC (Area Under Curve):

• 1.0 → Mükemmel model
• 0.5 → Rastgele tahmin
• < 0.5 → Rastgeleden bile kötü (etiketler ters öğrenilmiş olabilir)

Yorum:
Modelin pozitif bir örneğe negatiften daha yüksek puan verme ihtimalini gösterir.

🔢 Regresyon Dünyası: Sayıları Ne Kadar İyi Tahmin Ediyoruz?

📏 Ortalama Mutlak Hata (MAE)

Tanım: Tüm hataların mutlak değerlerinin ortalaması.
Yorum: Dürüst, anlaşılır, aykırı değerlere duyarsız.

Örnek:
Ev fiyatı tahmininde MAE = 5.000₺ → Ortalama sapma bu kadardır.

📉 Kök Ortalama Kare Hata (RMSE)

Tanım: Hataların karelerinin ortalamasının karekökü.
Yorum: Büyük hataları daha sert cezalandırır.

Örnek:

• Hata = 2 → MSE’ye katkı = 4
• Hata = 10 → MSE’ye katkı = 100!

Ne zaman kullanılır?
Büyük hataların daha maliyetli olduğu durumlarda (örneğin finansal tahminler)

🧮 Hangisini Seçmeli?

📊 R-Kare (R²)

Tanım: Modelin hedef değişkendeki varyansın yüzde kaçını açıkladığını gösterir.
Yorum: 0.75’lik R² → Veri içindeki varyansın %75’i açıklanıyor demektir.

⚠️ Yeni değişken eklendiğinde R² asla düşmez, bu yüzden Düzeltilmiş R² daha güvenilirdir.

🧩 Sonuç: Metrikler Amaç Değil, Araçtır

En iyi metrik, problemin doğasına ve iş hedefine en uygun olan metriktir.

Unutmayın:
Bir modelin performansını değerlendirmek, sadece bir sayıya bakmak değil; modelin ruhunu anlamaktır.
Doğru metrik, bu diyaloğun en güçlü kelimesidir.

✨ Eğer bu yazı faydalı olduysa, alkışlamayı ve paylaşmayı unutma!
Yorumlarını da mutlaka görmek isterim.
Veriyle kal 💡