SQL RAPOR KATMANI

Genel müdür yardımcısı toplantıda "geçen ayki gelir rakamı niye iki farklı raporda farklı çıkıyor?" diye sordu. Üç farklı kişi üç farklı sorgu yazmıştı; biri iade satırlarını dahil etmiş, biri etmemiş. Bu sahne çoğu kurumda tanıdıktır. Rapor katmanı, tam olarak bu sorunu önlemek için var.

Rapor Katmanı Nedir?

Rapor katmanı, ham verinin doğrudan raporlanmadığı, arada hesap kuralları, isimlendirme standardı ve birleşim mantığının yaşadığı kalıcı bir SQL yapısıdır. Genellikle VIEW, materialized view veya katmanlı şema tabloları üzerinden inşa edilir. Amaç, "geliri herkes aynı şekilde hesaplasın" mantığını tek bir noktaya çekmektir.

Olgunlaşmış veri ekiplerinde sık karşılaşılan bronze-silver-gold yaklaşımı bu fikrin somut bir uygulamasıdır: bronze ham veri, silver temizlenmiş veri, gold rapora hazır son katmandır.

Neden View Doğrudan SELECT'ten Daha İyi?

Ham tablodan doğrudan rapor çekmek kısa vadede pratik görünür, uzun vadede borçtur. Tipik sıkıntılar:

• Tekrarlanan iş mantığı: Net gelir tanımı 12 farklı sorguda yazılır, biri güncellenir, diğerleri eskir.
• Şema değişimine kırılganlık: Bir kolon yeniden adlandırıldığında onlarca rapor patlar.
• Yetkilendirme zorluğu: Ham tabloya erişim verirken hassas kolonları gizlemek zor.
• Performans: Karmaşık birleşimler her seferinde sıfırdan hesaplanır.
• Tutarsız raporlar: Aynı KPI iki kişinin elinde iki farklı sayı verir.

View bu sorunları tek bir tanımı paylaşarak çözer. Şemada değişiklik olursa sadece view güncellenir; raporlar dokunulmadan çalışmaya devam eder.

Üç Katmanlı Yaklaşım

Her seviye kendi sorumluluğuna odaklanır. Bu sayede bakım, hata ayıklama ve yetki yönetimi netleşir.

Bronze — Ham Veri

Kaynak sistemlerden olduğu gibi gelen tablolar. Hiçbir dönüştürme yok; sadece kopyalama. Tarih damgası ve yükleme zamanı eklenir. Geri dönüp orijinali görmek istediğinizde tek doğru kaynak burasıdır.

Silver — Temizlenmiş Veri

Veri tipleri standardize edilir, null değerler ele alınır, mükerrer kayıtlar temizlenir. Bu konunun güncel ayrıntıları Wikipedia'nın SQL sayfasında yer alır. Müşteri tablosundaki cust_nm ve customer_name tek bir kolona indirgenir. Tarih formatları tek standarda çekilir.

CREATE OR REPLACE VIEW silver.musteri AS
SELECT
 TRIM(LOWER(email)) AS email,
 COALESCE(ad, 'Bilinmiyor') AS ad,
 CAST(kayit_tarih AS DATE) AS kayit_tarih
FROM bronze.musteri_raw
WHERE email IS NOT NULL;

Gold — Rapora Hazır

İş tanımları burada uygulanır. Net gelir, aktif müşteri, sadık müşteri gibi tanımlar yazılı kurala dönüşür. Raporlar ve Power BI gibi araçlar yalnızca gold katmanına bağlanır.

CREATE OR REPLACE VIEW gold.aylik_gelir AS
SELECT
 DATE_TRUNC('month', s.tarih) AS ay,
 SUM(s.tutar) - COALESCE(SUM(i.tutar), 0) AS net_gelir
FROM silver.siparis s
LEFT JOIN silver.iade i ON s.id = i.siparis_id
GROUP BY DATE_TRUNC('month', s.tarih);

Materialized View Ne Zaman Gerekir?

Normal view her çalıştırıldığında sorgu sıfırdan yürütülür. Karmaşık birleşimler ve büyük tablolar söz konusuysa rapor sürekli yavaşlar. Materialized view, sonucu fiziksel olarak saklar ve belirli aralıklarla yeniler:

CREATE MATERIALIZED VIEW gold.aylik_gelir_mat AS
SELECT ay, net_gelir FROM gold.aylik_gelir;

REFRESH MATERIALIZED VIEW gold.aylik_gelir_mat;

Gece yapılan otomatik refresh, gündüz boyunca raporun saniyeler içinde açılmasını sağlar. Anlık veriye ihtiyacınız varsa normal view, geçmiş raporlama için materialized view tercih edilir.

İsimlendirme Standardı

Katmanlı yapı ancak isimlendirme tutarlıysa işe yarar. Birkaç ay sonra yeni gelen birinin "bu view ne işe yarıyor" diye sorduğu her sorgu, isimlendirme borcunun faturasıdır.

• Şema öneki: bronze_, silver_, gold_ veya ayrı schema'lar.
• İş varlığı: musteri, siparis, fatura — Türkçe veya İngilizce, ekip içinde tek dilde tutarlı.
• Granülarite: gunluk_, aylik_, kohort_ önekleriyle özet seviyesi belli olsun.
• Kısaltma yok: mst_grp_pvt üç ay sonra anlam kaybeder; musteri_grup_pivot hep okunur.

Erişim ve Yetkilendirme

Katmanlı yapı yetkilendirmeyi basitleştirir. Veri mühendisleri bronze ve silver'a yazabilir; analistler sadece gold'u görebilir. Hassas kolonlar (TC, telefon) silver katmanında maskelenir, gold'a maskelenmiş olarak gelir. Bu sayede üyelik veya iş değişikliğinde yetki yönetimi katman düzeyinde tek noktadan yapılır.

Performans İpuçları

1. Sık kullanılan join anahtarlarında mutlaka indeks olsun.
2. Karmaşık gold view'lar materialized view'a dönüştürülsün, gece refresh edilsin.
3. Büyük tablolar tarih bazlı partition edilsin; sorgular son ay için yalnızca ilgili partition'ı tarasın.
4. Sorgu yürütme planları belirli aralıklarla incelenip darboğazlar düzeltilsin.

Rapor katmanını sistematik kurmak, ileri SQL ve veri modelleme pratiği gerektirir. Veri analistliği veya BI yönüne ilerlemek isteyenlerin bu yapı taşlarını gerçek senaryolarla pekiştirebileceği bir uygulamalı SQL eğitimi teoriyi pratik problemlere bağlar.

Doğru kurulmuş bir rapor katmanı, raporlar arasındaki tutarsızlığı, "geçen ay neyi nasıl saymıştık" tartışmasını ve şema değişikliği panaltısını büyük ölçüde ortadan kaldırır. Sadece SQL yazma değil, SQL'i organize etme meselesidir.