Giriş
Küçük liglerde düzgün ELO hesaplamaları ve güvenilir maç kayıtları, oyuncu performansını doğru okumak, adil sıralama yapmak ve turnuva yapısını korumak için hayati önemdedir. Ancak veri girişi hataları, eksik kayıtlar veya farklı formatlar ELO modellerinde ciddi sapmalara yol açar. Bu yazıda, sahada uygulanabilir ve teknik açıdan sağlam 7 adımlık rehberi paylaşıyorum. Her adım, somut örnekler, pratik SQL ve mantıksal kontrollerle desteklenmiştir.
Neden veri temizliği ELO için kritik?
ELO hesaplamaları zincirleme etki yapar: yanlış bir maç kaydı, iki oyuncunun ELO'sunu bozabilir, bu da sonraki maçların beklenen sonuçlarını hatalı tahmin eder. Küçük liglerde oyuncu sayısı sınırlı olduğundan tek bir hatanın etkisi daha büyüktür. Bu yüzden veri temizliği yalnızca “iyi bir uygulama” değil, sıralama modelinin doğruluğunu koruyan zorunlu bir süreçtir.
Genel yaklaşım: Önce doğrulama, sonra standardizasyon, en son izleme
Temizleme süreci üç katmana ayrılmalıdır:
- Doğrulama: Verinin mantıksal tutarlılığını kontrol et.
- Standardizasyon: Formatları, ID'leri, timestamp'leri birleştir.
- İzleme ve geri dönüş: Otomatize hata raporları ve düzeltilmiş kayıtlar.
7 Teknik Rehber
1) Mutlak zorunlu alanları ve tipleri zorunlu kılın
Her maç kaydının minimum şunları içermesi gerekir: maç_id, tarih (ISO 8601), oyuncu_a_id, oyuncu_b_id, skor_a, skor_b, maç_durumu (tamamlandı/iptal/erteleme). Veritabanı seviyesinde NOT NULL, doğru tür (DATE/TIMESTAMP, INTEGER) ve temel dış anahtar (foreign key) kısıtlamaları uygulayın.
Örnek SQL: ALTER TABLE matches ADD CONSTRAINT chk_scores CHECK (score_a IS NOT NULL AND score_b IS NOT NULL AND score_a>=0 AND score_b>=0);
Bu, eksik veya negatif skorları anında engeller.
2) Provisional (geçici) maçlar ve provizyon süresi
Kullanıcılar yanlışlıkla maç ekleyebilir. Yeni hesaplanan ELO'ların kalıcı olması için provizyon mantığı uygulayın: bir maç ilk girildiğinde 24-48 saat "pending" modunda dursun. Bu süre içinde değişiklik yapılabilir. Süre dolduğunda otomatik olarak doğrulansın ve ELO güncellemesi tetiklensin.
3) Kimlik çözümlenmesi ve eşleştirme (fuzzy matching)
Oyuncu isimleri farklı yazılabilir (Ör: "Ahmet Yildiz", "Ahmet Yıldız"). Oyuncuları benzersiz ID ile bağlayın; kayıt girilirken e-posta, telefon veya lisans numarası gibi ek doğrulayıcılar isteyin. Eski veriler için fuzzy matching (ör. Levenshtein) kullanarak potansiyel eşleşmeleri belirleyin ve insan onayından geçirin.
Uygulama önerisi: Eşleşme oranı > 90% ise otomatik birleştir; 70-90% ise insan doğrulaması iste.
4) Zaman damgası, saat dilimi ve tarih standardizasyonu
Maç tarihleri farklı formatlarda girildiğinde sıralama bozulur. Tüm tarihleri UTC'ye çevirin ve ISO 8601 (YYYY-MM-DDTHH:MM:SSZ) formatı kullanın. Ayrıca maçın oynandığı yerin saat dilimini saklayarak gerektiğinde yerel zamanı yeniden hesaplayın.
5) Çakışan ve çifte kayıtları önleme
Aynı maçın iki kaydı (duplicate) ELO hesaplamalarını ikiye katlayabilir. Önleyici yöntemler:
- İdempotent API uç noktaları: aynı dış anahtar (external_match_id) ile tekrar gönderim aynı kaydı günceller.
- Veritabanı seviyesinde UNIQUE constraint: (external_match_id) veya (player_a_id, player_b_id, date, event_id) kombinasyonuna unique kısıt.
- Arka uçta çakışma tespiti: benzer timestamp ve katılımcılar varsa uyarı gösterin.
6) Eksik veri tamamlama ve mantıksal onarım
Eksik skor, eksik tarih gibi durumlarda otomatik tamamlama bazen sakıncalıdır. Ancak aşağıdaki mantıksal düzeltmeler yararlıdır:
- Eğer maç tamamlandıysa fakat skor eksikse, kaydı "missing_score" olarak işaretleyip organizatöre bildirim gönderin.
- Tekrarlanabilir bilgi varsa (ör. sayfa geçmişi, live feed), otomatik doldurma için güven skorları tanımlayın; güven skorı yüksekse otomatik onar, düşükse insan onayı iste.
- Toplu düzeltmeler için bir "change set" sistemi kullanın: hangi kayıt, kim tarafından, ne değişti kaydı saklansın.
7) İzleme, uyarılar ve geri dönüş (audit) mekanizmaları
ELO hesaplamalarını ve veri kalitesini izlemek için metrikler oluşturun:
- Günlük doğrulama hatası sayısı
- Duplicate tespit oranı
- Provisional sürede iptal edilen maçların oranı
- ELO oynaklığı: aynı oyuncunun kısa sürede büyük dalgalanma yaşaması anormallik olabilir
Bu metrikler için alert kuralları oluşturun; örneğin günlük hatalar belirli eşiği geçerse Slack/e-posta bildirimi gönderilsin.
Pratik örnek: Hatalı maçın tespit akışı
Bir maç kaydı geldi. Sistem şu adımları uygular:
- ID ve zorunlu alanlar kontrol edilir.
- Oyuncu ID'leri çözülür; eğer eşleşme belirsizse "human review" kuyrukuna gönderilir.
- Tarih UTC'ye çevrilir; eğer tarih gelecekteyse uyarı atılır.
- Duplicate kontrolü yapılır; eğer aynı external_match_id varsa güncelleme uygulanır.
- Provisional süresi içinde ise kaydı beklet ve değişiklikleri günlük raporla yöneticilere gönder.
Kısa kod ve sorgu ipuçları
Duplicate kontrolü için basit SQL:
SELECT COUNT(*) FROM matches WHERE player_a_id = ? AND player_b_id = ? AND DATE(match_time) = ?;Fuzzy eşleştirme için örnek (PostgreSQL):
SELECT id, similarity(name, 'Ahmet Yildiz') AS s FROM players WHERE similarity(name, 'Ahmet Yildiz') > 0.4 ORDER BY s DESC;Sonuç: Süreç odaklı ve otomatik ama insan denetimli yaklaşım
Kirli veriyi tamamen ortadan kaldırmak mümkün değil, ancak doğru teknikler ve iş akışlarıyla hataları minimize edebilirsiniz. Özetle:
- Veritabanı kısıtlamaları ile başlangıçta filtreleme sağlanmalı.
- Provizyon ve idempotency uygulamalarına öncelik verin.
- Fuzzy eşleştirme ve insan onayı kombinasyonu eksik/çakışan kayıtları temizler.
- İzleme ve metrikler sayesinde sistemin sağlık durumunu sürekli takip edin.
Bu 7 teknik adımı küçük liglere uyguladığınızda, ELO hesaplamalarınızın güvenilirliği artacak, oyuncu ve organizatör güveni yükselecek, sonuç olarak lig kalitesi yükselecektir.
Uygulamaya dönük sorularınız varsa; örnek SQL, veri modeli veya pipeline önerileriyle yardımcı olabilirim.
