SQL İLE VERİ KALİTESİ KONTROLLERİ: TUTARLILIK, TEKİLLİK VE ANOMALİ YAKALAMA

Veri kalitesi, çoğu ekipte “veri temizliği” olarak konuşulsa da gerçekte bir mühendislik disiplini: ölçülebilir kurallar, tekrarlanabilir testler ve hızla aksiyona dönüşen raporlar ister. En kritik noktaysa şu: hatayı BI katmanında veya model eğitiminde görmek yerine, kaynağa en yakın yerde yakalamak maliyeti dramatik biçimde düşürür.

SQL hâlâ veri ekosisteminin ortak dili. ETL/ELT, veri ambarı, lakehouse ya da operasyonel veritabanı… Her yerde en az bir katman SQL konuşur. Bu yüzden veri kalitesi kontrollerinin önemli bir bölümü, araç bağımsız olarak SQL ile tanımlanabilir. Üstelik doğru yazılmış SQL kontrolleri, hem küçük ekiplerde hızlı bir başlangıç sağlar hem de olgun veri platformlarında merkezi test yaklaşımına dönüşebilir.

Bu yazıda, SQL ile tutarlılık, tekillik ve anomali yakalama kontrollerini nasıl tasarlayacağınızı; örnek sorgularla nasıl doğrulayacağınızı ve operasyonel süreçlere nasıl entegre edeceğinizi adım adım ele alacağız. Son bölümde ise otomasyon, raporlama ve sorumluluk modeliyle birlikte, “bulduk ama kim düzeltecek?” sorusunu çözeceğiz.

Veri Kalitesi Neden SQL ile Başlar?

Veri kalitesi hedefi, yalnızca hatalı satırları “silmek” değildir; güvenilir karar alma için veriyi bir sözleşme gibi yönetmektir. Bu sözleşme; alanların beklenen aralıklarda olması, ilişkilerin kopmaması, anahtarların benzersiz kalması ve normal davranışın dışındaki sıçramaların erkenden görülmesi gibi kuralları kapsar. SQL, bu kuralları doğrudan verinin bulunduğu yerde ölçmenizi sağlar.

Veri kalitesi kontrollerini SQL ile başlatmanın bir başka avantajı da şeffaflıktır. Kontroller genellikle basit toplulaştırmalar, filtreler ve join’lerle ifade edilir. Bu sayede ürün, finans, risk veya operasyon gibi iş birimleriyle “kuralın ne olduğunu” aynı dilde konuşabilirsiniz. Kuralların okunabilir olması, itirazları azaltır ve değişen iş ihtiyaçlarına uyum hızını artırır.

Kalite boyutlarını netleştirme

Kontrol yazmadan önce, hangi kalite boyutunu ölçtüğünüzü açıkça adlandırın: doğruluk, tamlık, tutarlılık, tekillik, zamanlılık, geçerlilik gibi. Bu yazıda odak, veri setlerinde en hızlı iş değeri üreten üç boyut: tutarlılık (iş kuralları ve referans ilişkiler), tekillik (benzersiz anahtarlar), anomali (beklenmeyen dağılım veya sıçramalar).

Kontrol seviyeleri: satır, grup, tablo

Kontrolleri üç seviyede düşünmek faydalıdır. Satır seviyesi: belirli alanların boş olmaması, tarih aralığı gibi tek kayda bakarak karar veren kontroller. Grup seviyesi: aynı müşteri, aynı sipariş, aynı gün gibi kümelerde toplam/ortalama ile kontrol. Tablo seviyesi: genel satır sayısı trendi, duplicate oranı, eksik alan oranı gibi metrikler. Bu ayrım, hem performans hem de sahiplik açısından tasarımı kolaylaştırır.

Tutarlılık Kontrolleri: İş Kuralları ve Referans Bütünlüğü

Tutarlılık, verinin kendi içinde ve ilişkili tablolarla uyumlu olmasıdır. Örneğin “iptal edilmiş siparişin teslim tarihi olamaz” ya da “şehir kodu, şehir referans tablosunda bulunmalı” gibi kurallar tipik tutarlılık kontrolleridir. Bu kontroller, çoğu zaman birim fiyat hesapları, statü geçişleri veya hiyerarşi ilişkileri nedeniyle kritik hale gelir.

Tutarlılık kontrollerinde iki ana yaklaşım vardır: (1) iş kuralı tabanlı kontroller (case/where), (2) referans tablo/foreign key doğrulamaları (join). Operasyonel sistemlerde foreign key kısıtları her zaman aktif olmayabilir; lakehouse gibi ortamlarda zaten fiziksel kısıt bulunmayabilir. Bu durumda “mantıksal foreign key” kontrolü SQL ile yazılır.

İş kuralı tabanlı tutarlılık örnekleri

İş kuralları genellikle, bir alanın başka bir alanla uyumunu kontrol eder. Örneğin sipariş durumuna göre alanların dolu/boş olması, tutarların negatif olmaması, tarih sıralaması gibi. Burada amaç, “hangi kayıtlar hatalı?” sorusunu doğrudan yanıtlayabilmektir. Kontrol sonucunu, hatalı kayıtların sayısı ve örnek satırlarla raporlamak, düzeltme süresini kısaltır.

Referans tablolarla doğrulama ve kırık ilişkiler

Referans bütünlüğü kontrolleri, en çok master data (müşteri, ürün, lokasyon) değiştiğinde bozulur. Yeni gelen bir ürün kodu referansta yoksa, satış raporları kategorisiz kalabilir. Bu tür kontrolleri, özellikle boyut tabloları ve fact tabloları arasında düzenli çalıştırmak gerekir. Kırık ilişki oranı (orphan rate), veri platformunun sağlığını takip etmek için güçlü bir metriktir.

-- Tutarlılık + referans bütünlüğü kontrolü (örnek)
-- 1) İptal edilmiş siparişin teslim tarihi dolu olamaz
-- 2) Ürün kodu ürün referans tablosunda bulunmalı

WITH invalid_orders AS (
  SELECT
    o.order_id,
    o.customer_id,
    o.product_code,
    o.status,
    o.order_date,
    o.delivered_at
  FROM fact_orders o
  WHERE o.status = 'CANCELLED'
    AND o.delivered_at IS NOT NULL
),
orphan_products AS (
  SELECT
    o.order_id,
    o.product_code
  FROM fact_orders o
  LEFT JOIN dim_products p
    ON p.product_code = o.product_code
  WHERE p.product_code IS NULL
)
SELECT 'cancelled_has_delivery' AS check_name, COUNT(*) AS fail_count
FROM invalid_orders
UNION ALL
SELECT 'orphan_product_code' AS check_name, COUNT(*) AS fail_count
FROM orphan_products;

Bu sorgu iki kontrolü tek çıktıda toplar. Üretim ortamlarında kontrol başına tek metrik döndürmek, alarm ve eşik yönetimini kolaylaştırır. Örneğin “orphan_product_code fail_count > 0” kritik hata sayılabilir; “cancelled_has_delivery” ise belirli bir eşikten sonra uyarı üretebilir.

Tekillik Kontrolleri: Benzersiz Anahtarlar ve Duplicate Analizi

Tekillik, bir anahtarın veya anahtar kombinasyonunun her kaydı benzersiz tanımlamasıdır. Tekillik bozulduğunda, raporlarda çift sayım başlar, müşteri 360 görünümleri parçalanır, doğru “son durum” seçilemez. Bu yüzden tekillik kontrolleri, veri kalitesi portföyünün çekirdeğinde yer alır.

Tekillik yalnızca “primary key duplicate” değildir. Bazen iş anahtarı (business key) benzersiz olmalıdır: örneğin “(customer_id, email)” ya da “(order_id, line_no)” gibi. Ayrıca “son sürüm” mantığı olan tablolarda, aynı anahtarın birden fazla aktif kaydı olması da tekillik ihlalidir.

Birincil anahtar ve bileşik anahtar doğrulaması

En temel yaklaşım, ilgili anahtar(lar) için group by yapıp count>1 olan grupları yakalamaktır. Bu kontrol hem anlaşılırdır hem de kolayca metrikleşir. Ancak çok büyük tablolarda performans için partition stratejisi, indeksler veya incremental kontrol (son N gün) gibi teknikleri düşünmek gerekir.

Pencere fonksiyonları ile “aktif kayıt” tekilliği

SCD Type 2 gibi modellerde aynı anahtar için birden fazla satır olabilir; fakat “aktif” satır tek olmalıdır. Burada window function’lar ile active flag veya valid_to alanına göre kontrol yapmak daha doğru sonuç verir. Ayrıca “en güncel kayıt hangisi?” gibi iş mantıklarını netleştirmek, yanlış alarm riskini azaltır.

-- Duplicate tespiti + aktif kayıt tekilliği (örnek)
-- 1) order_line (order_id, line_no) benzersiz olmalı
-- 2) customer_profile tablosunda aynı customer_id için birden fazla aktif kayıt olmamalı

SELECT
  'order_line_duplicate' AS check_name,
  COUNT(*) AS fail_count
FROM (
  SELECT order_id, line_no
  FROM fact_order_lines
  GROUP BY order_id, line_no
  HAVING COUNT(*) > 1
) d
UNION ALL
SELECT
  'customer_active_multi' AS check_name,
  COUNT(*) AS fail_count
FROM (
  SELECT customer_id
  FROM dim_customer_profile
  WHERE is_active = 1
  GROUP BY customer_id
  HAVING COUNT(*) > 1
) a;

Tekillik kontrollerini yalnızca “fail_count” ile bırakmak, düzeltme sürecini uzatır. İkinci bir sorgu ile örnek anahtarları (ilk 50 gibi) loglamak, veri ekibinin hızlı triage yapmasını sağlar. Kritik sistemlerde, duplicate kayıtların hangi kaynaktan geldiğini bulmak için ingest metadata (source_file, ingest_batch_id) gibi alanlar da kontrol çıktısına eklenmelidir.

Anomali Yakalama: Trend, Dağılım ve İş Kuralı Sıçramaları

Anomali, veri hatası ile işteki gerçek değişimin aynı anda olabileceği gri bir alandır. Bu yüzden anomali kontrolleri “kesin hatadır” demek yerine, “incelemeye değer sapma” üretir. Satır sayısının bir günde %80 düşmesi, belirli bir ülkede satışın sıfırlanması, ortalama sepet tutarının aniden iki katına çıkması gibi örnekler; hem teknik hem iş tarafında hızlı aksiyon gerektirir.

Anomali yakalamada iki yöntem pratikte çok kullanılır: (1) tarihsel kıyas (moving average / week-over-week), (2) istatistiksel eşik (z-score, robust yöntemler). SQL ile her ikisini de yapmak mümkündür. Önemli olan, metrikleri doğru seçmek ve iş takvimi etkilerini (hafta içi/sonu, kampanya, ay sonu) hesaba katmaktır.

Basit trend kontrolleri: dün, geçen hafta, ortalama

En hızlı başlangıç, günlük metrikleri hesaplayıp önceki dönemle karşılaştırmaktır. Örneğin “günlük sipariş adedi, son 28 gün ortalamasının %40 altına düşerse uyar” gibi bir kural, birçok entegrasyon kırılmasını erken yakalar. Burada sezonsallık varsa, geçen haftanın aynı günüyle kıyaslamak daha stabil sonuç verir.

Z-score ile istatistiksel sapma tespiti

Z-score yaklaşımı, bir metrikin ortalamadan kaç standart sapma uzaklaştığını ölçer. Büyük veri setlerinde hızlı ve uygulanabilir olsa da uç değerlerden etkilenebilir. Bu nedenle özellikle finansal metriklerde robust alternatifler (median, MAD) daha güvenlidir. Yine de çoğu ekip, operasyonel veri akışlarında önce z-score ile başlar, sonra kritik metriklerde robust eşiklere geçer.

Robust yaklaşım: Median ve MAD ile daha az yanlış alarm

Median Absolute Deviation (MAD), uç değerlerden daha az etkilenir. SQL’de median hesaplamak bazı sistemlerde farklılık gösterebilir (percentile_cont gibi fonksiyonlar). Destekleyen sistemlerde MAD tabanlı eşik, “kampanya günü” gibi doğal piklerin yanlış alarm üretmesini azaltır. Desteklemeyen sistemlerde, yaklaşık quantile fonksiyonları veya ön hesaplanmış istatistik tablosu yaklaşımı uygulanabilir.

Aşağıdaki örnek, günlük sipariş adedinde haftalık kıyasla sapmayı izleyen sade bir kontrol mantığı gösterir. Eşik değerleri kurumun toleransına göre ayarlanmalıdır; ayrıca alarm üretmeden önce 2–3 gün üst üste sapma koşulu gibi bir “debounce” kuralı eklemek de faydalıdır.

• Günlük metrikleri tek bir “dq_metrics_daily” tablosunda toplamak
• Hafta içi/sonu ayrımı için ayrı eşikler tanımlamak
• Yeni ürün/pazar açılışlarında “öğrenme dönemi” uygulamak
• Uyarıları ekip ve iş birimi sahipleriyle birlikte triage etmek

Kontrol Sonuçlarını Standardize Etmek: Metrik, Eşik ve Şiddet

SQL kontrolleri yazmak kolay; zor olan, çıktıları standardize edip yönetilebilir hale getirmek. Her kontrolün adını, hedef tablosunu, kontrol tipini ve şiddetini (kritik/uyarı) net tanımlayın. Böylece kalite borcu büyüdükçe bile, hangi kontrollerin gerçekten “sayfayı durduracak” seviyede olduğunu ayırt edebilirsiniz.

Pratik bir standart çıktı şeması şöyle olabilir: check_name, table_name, dimension (consistency/uniqueness/anomaly), fail_count, sample_keys, severity, run_ts. Sample_keys alanı, çok uzun olmamak kaydıyla JSON veya virgüllü değerler olabilir. Amaç, aynı sorgu setinin farklı sistemlerde (orchestrator, alerting) kolayca tüketilmesidir.

Eşik yönetimi ve alarm yorgunluğu

Anomali kontrollerinde eşiklerin ilk sürümde mükemmel olması beklenmez. İlk 2–4 hafta “gözlem” modu ile metrikleri toplayıp, yanlış alarm oranına göre eşikleri ayarlamak daha sağlıklıdır. Ayrıca kontrolleri “kritik” ve “uyarı” olarak ayırmak, alarm yorgunluğunu azaltır. Kritik kontroller genellikle tutarlılık ve tekillik ihlalleridir; anomali çoğu zaman uyarı seviyesinde başlar.

Otomasyon: Zamanlama, Artımlı Kontrol ve Süreç Entegrasyonu

Kontrollerin değeri, düzenli çalıştığında ortaya çıkar. Bu nedenle SQL kontrollerini bir orkestratöre bağlamak (ör. job scheduler, pipeline adımı, CI benzeri test koşusu) önemlidir. “Dün gelen veriyi kontrol et” gibi artımlı (incremental) yaklaşım, hem maliyeti düşürür hem de tespit süresini kısaltır. Büyük tablolarda tüm tarihçeyi taramak yerine, son 1–7 gün gibi pencerelerde kontrol koşmak çoğu zaman yeterlidir.

Otomasyon tasarımında iki kritik karar vardır: (1) Kontrol ne zaman çalışacak? (yükleme sonrası mı, raporlama öncesi mi) (2) Kontrol fail olursa ne olacak? (pipeline duracak mı, sadece uyarı mı) Kurumların olgunluk seviyesi arttıkça, kritik kontrollerin pipeline’ı durdurması daha yaygın hale gelir. Ancak geçiş döneminde, önce görünürlük kazanmak ve sahiplikleri netleştirmek daha doğru olabilir.

Veri kalitesi testlerini eğitimle güçlendirme

Veri ekibi ve analitik ekipleri aynı çerçevede hizalamak için, kontrolleri “neden böyle?” sorusuyla birlikte dokümante edin. Kurum içinde ortak bir pratik oluşturmak istiyorsanız, SQL eğitimi kapsamında veri profilleme, pencere fonksiyonları ve performans optimizasyonu konularını özellikle ele almak; kontrollerin kalitesini ve sürdürülebilirliğini artırır.

Raporlama ve Aksiyon: Hataları İşe Dönüştürmek

Veri kalitesinde başarının ölçüsü, kaç hata bulduğunuz değil; hataların ne kadar hızlı ve kalıcı biçimde çözüldüğüdür. Bu yüzden kontrol sonuçlarını yalnızca log’larda bırakmak yerine, görünür bir kalite panosu ve net bir aksiyon akışına bağlayın. “Hata sahibi kim?” sorusu cevapsız kalırsa, kontroller zamanla önemini kaybeder.

Aksiyon modeli için basit bir RACI yaklaşımı kullanılabilir: veri üreticisi (source owner) düzeltmeden sorumlu, veri platformu ekibi izleme ve otomasyondan sorumlu, analitik ekip etkileri doğrulayan taraf, ürün/iş birimi ise kuralın sahibi. Böylece “kural değişti mi, veri mi bozuldu?” tartışması daha hızlı çözülür.

Kalite skor kartı ve sürdürülebilirlik

Kalite skor kartında, tablo bazlı metrikler (fail_count, fail_rate), trendler ve son düzeltme zamanı gibi göstergeler yer alabilir. En önemli kazanım, veri kalitesini “tek seferlik temizlik” değil, süreklilik gerektiren bir ürün olarak yönetmeye başlamaktır. Zaman içinde, kontrollerin kapsamını genişletip (tamlık, geçerlilik), daha gelişmiş anomali tespit yaklaşımlarına geçebilirsiniz.

Sonuç olarak, SQL ile veri kalitesi kontrolleri; hızlı kazanım, şeffaf kural tanımı ve platform bağımsızlık sağlar. Doğru standardizasyon ve otomasyonla birleştiğinde ise, karar kalitesini yükselten, riskleri erken yakalayan ve veri ekibinin itibarını güçlendiren bir temel haline gelir.