SQL VERİ KALİTESİ KONTROLLERİ

SQL veritabanı silindiri üstünde üç ayrı kalite rozetinin yer aldığı veri sağlığı kontrol kompozisyonu

Bir raporun yanlış çıkmasının yüzde sekseni sorgudan değil, veriden gelir. Sorgu doğru yazılmıştır, mantık tutarlıdır, ama temelde duran veri kirlidir. Mükerrer kayıtlar, eksik referanslar, beklenmedik değerler raporu sessizce çarpıtır ve hata genellikle yöneticinin "bu rakam bana yanlış geldi" yorumuyla geç fark edilir. SQL veri kalitesi kontrolleri bu durumu önlemenin sistematik yoludur; her veri çekildiğinde sorulması gereken bir dizi sorudur.

Tekillik Kontrolü

Bir tablonun her satırının eşsiz olması beklenir; mesela müşteri tablosunda her müşteri ID'si tek satırda durmalıdır. Pratikte bu çoğu zaman böyle değildir; yıllar içinde aynı müşteri farklı kayıtlarla eklenmiş olabilir. Tekillik kontrolü basit bir GROUP BY ile yapılır: müşteri ID'sini grupla, COUNT al, biri büyük olanları listele. Çıkan listeyle mükerrer kayıtların kim olduğu görünür.

Tekillik sadece tek bir alan üzerinden değil, birleşik anahtar üzerinden de kontrol edilir. Fatura tablosunda fatura numarası tek olmalıdır ama farklı şirketlerin aynı fatura numarasını kullandığı durumlarda şirket + fatura kombinasyonunun tek olması gerekir. Bu kontrol birleşik anahtara göre yapılır.

Pratik kontrol sorgusu basit bir GROUP BY ile yazılır:

-- Tekrarlanan müşteri ID'lerini bul
SELECT musteri_id, COUNT(*) AS satir_sayisi
FROM musteriler
GROUP BY musteri_id
HAVING COUNT(*) > 1
ORDER BY satir_sayisi DESC;

-- Eksik (NULL veya boş) ad kontrolü
SELECT COUNT(*) AS bos_ad_sayisi
FROM musteriler
WHERE ad IS NULL OR TRIM(ad) = '';

-- Referans bütünlüğü: müşterisi olmayan faturalar
SELECT f.fatura_no, f.musteri_id
FROM faturalar f
LEFT JOIN musteriler m ON f.musteri_id = m.musteri_id
WHERE m.musteri_id IS NULL;
Müşteri tablosunda tekrar eden ID satırlarını GROUP BY HAVING ile bulan Türkçe sonuç tablosu

Tamlık Kontrolü

Bir alanın olması gereken yerlerde gerçekten dolu olup olmadığını kontrol etmektir. NULL değerler tüm sütunlarda olabilir ama bazı sütunların kesinlikle dolu olması beklenir; müşteri tablosunda ad sütunu, fatura tablosunda tarih sütunu gibi. Tamlık kontrolünde basitçe COUNT ile NULL olmayan değer sayısı çekilir ve toplam satır sayısıyla karşılaştırılır.

NULL değerler her zaman görünür olmaz. Bazen "" boş metin olarak yazılmış, bazen "BİLİNMİYOR" gibi varsayılan değer doldurulmuş olabilir. Tamlık kontrolünde bu örtük boş değerleri de yakalamak gerekir. Distinct değer listesi çekilip alışılmamış kategoriler olup olmadığı incelenir.

Referans Bütünlüğü

İlişkisel veritabanlarında bir tablonun başka bir tabloya referans veren alanları bulunur. Fatura tablosundaki müşteri ID'sinin müşteri tablosunda gerçekten bir karşılığı olması beklenir. Bu kuralın bozulmuş olması yaygın bir sorundur; bir tablodan kayıt silinmiş ama referans veren tablodaki kayıtlar kalmıştır. LEFT JOIN ile bağlantı kurup karşı tarafı NULL olan satırlar süzülürse referans bütünlüğü olmayan kayıtlar yakalanır.

Veritabanı seviyesinde FOREIGN KEY tanımlanmışsa bu sorun başlangıçta engellenir; ama eski sistemlerde veya veri ambarı yapılarında bu kısıtlar genellikle bulunmaz ve bütünlük her seferinde manuel kontrol edilir. Bu sebeple veri kalitesi kontrol sorgusu olarak referans bütünlüğü düzenli olarak çalıştırılması gereken bir testtir.

Aralık ve Mantık Kontrolleri

Bir değerin makul aralıkta olup olmadığı kontrol edilebilir. Tipik aralık kuralları:

  • Yaş: 0 ile 120 arası; dışı şüpheli.
  • Tutar: Sıfır veya negatif değer iş kuralına göre yasak ya da işaretli olmalı.
  • Tarih: Geleceğe sarkan satış tarihi veya 1900 öncesi doğum tarihi anomali.
  • Yüzde: 0 ile 100 arası; sapma kayıp ondalık ayırıcıdır.
  • Telefon: 10-11 haneli rakam dizisi; alfabetik karakter şüpheli.
  • Posta kodu: 5 hane; kısa veya uzun ise format hatası.

Bu kontroller WHERE şartlarıyla anormal değerleri çeker. Daha ileri ayrıntılar Wikipedia'nın SQL sayfasında ele alınır. Hata sıklığı raporlamasıyla en sık problemli alanlar belirlenir ve veri girişi tarafına geri bildirim verilir.

Mantık kontrolleri biraz daha incedir. Başlangıç tarihi bitiş tarihinden büyük olamaz; bir müşterinin doğum tarihi şirkete kayıt tarihinden sonra olamaz; bir faturanın ödenen tutarı toplam tutarından büyük olamaz. Bu tip iş kurallarını sorguya dökmek hatalı satırları görünür kılar.

Tutarlılık Kontrolleri

Aynı bilginin farklı yerlerde aynı şekilde durması gerekir. Müşteri adı müşteri tablosunda "ABC Ltd." yazıyorsa fatura tablosunda da aynı olmalıdır. Veri ambarlarında bu tip tutarsızlık denormalizasyon gerektiren tablolarda sıkça görülür. İki tablodaki aynı alan için aşağıdaki gibi bir karşılaştırma yapılır: müşteri ID'siyle JOIN, ad alanlarını karşılaştır, farklı olanları listele.

Tutarlılık aynı zamanda zaman içindeki sabitlik anlamına da gelir. Geçen ay 1.245 olarak raporlanan satır bu ay birden 1.183 olmuşsa veri arkadan değişmiş demektir. Veri kalitesi izleme sistemleri bu tür değişimleri yakalamak için anlık görüntü (snapshot) saklar ve dönem dönem karşılaştırma yapar.

Anomali Tespiti

Tüm yukarıdaki kontroller bilinen kuralları test eder. Anomali tespiti ise bilinmeyen bozukluğa bakar; istatistik olarak alışılmadık değerleri arar. Bir sütunun ortalaması ve standart sapması alınır, ortalamadan üç standart sapma uzakta olan değerler aday olur. Bu basit yaklaşım çoğu zaman gerçek hataları yakalar; bir fatura tutarı 12 milyon TL olarak gözüküyorsa ve diğer faturalar binlerde gezdiyse anormaldir.

Anomali kontrolü zaman serilerinde de uygulanır. Aylık satış adetinin yıllık ortalamadan ne kadar saptığı izlenir; ani sıçramalar ya kampanya etkisidir ya da veri kalitesi sorunudur. İkincisini ayırt etmek için anomali raporları haftalık olarak ilgili birime gönderilir ve açıklama beklenir.

Üç standart sapma dışında kırmızı vurgulu uç değerleri gösteren fatura tutarı dağılım grafiği

Kontrol Sorgularının Düzeni

Veri kalitesi kontrol sorguları rastgele yazılırsa zamanla unutulur. Bunları bir SQL dosyasında toplamak ve haftalık otomatik çalıştırmak iyi pratiktir. Her kontrol sorgusunun bir adı, ne yaptığı açıklaması ve geçti/kaldı kuralı olur. Bir kontrol kaldıysa ilgili kişiye otomatik bildirim gönderilir. Bu yapı veri kalitesini bir kerelik bir iş olmaktan çıkarıp düzenli bir izleme süreci haline getirir.

Power BI veya Excel raporlarına yansıtılmadan önce verinin tüm bu kontrolleri geçmiş olması beklenir. Aksi halde kötü veri rapor yapısının içine yerleşir ve sonradan ayıklamak çok daha pahalı olur.

Veri kalitesi olmadan veri analizi yapmak boşlukta yürümektir. SQL eğitimi bu kontrol seti ve metodolojiyi gerçek tablolar üzerinde uygulamalı olarak gösterir.

Sıkça Sorulan Sorular

Bu kontroller hangi sıklıkla çalıştırılmalı?

Veri taze beslenen ortamlarda günlük veya saatlik, daha statik ortamlarda haftalık yeterlidir. Önemli olan düzenli olması ve sonuçların izlenmesidir.

Veri kalitesi sorumluluğu kimde olmalı?

Veriyi üreten kaynak sistemde, ama izleme sorumluluğu veri ambarı veya iş zekâsı ekibindedir. İki taraf birlikte sorunu kaynağına götürmelidir.

Hatalı kayıtları otomatik düzeltmek doğru mu?

Genellikle hayır. Düzeltme kaynak sistemde yapılmalıdır; veri ambarında düzeltme yapmak iki sistemin tutarsız olmasına yol açar. Sadece kayıt için işlenmiş bir veri kategorisi olabilir.

Performans için bu kontroller pahalı olmaz mı?

Tablo büyüklüğüne göre değişir. Kritik kontroller doğru indekslerle hızlı çalışır; çok pahalı kontroller geceleri çalıştırılır.

Veri kalitesi araçları (DQ tool) gerekli mi?

Küçük ve orta ölçekte SQL sorguları yeterlidir. Büyük veri ambarlarında özel araçlar (Great Expectations, dbt tests gibi) ölçekleme ve raporlama sağlar.

Tutarsız değerler temizlendikten sonra eski raporlar değişir mi?

Evet, geçmişe dönük raporlar yeniden hesaplandığında farklı değerler verebilir. Bu yüzden geçmiş rapor anlık görüntüleri ayrıca arşivlenir.