Normalizasyon hangi derdi çözer?
Normalizasyonun temel derdi veri tekrarını azaltmak ve tutarlılığı korumaktır. Müşteri adresi tek yerde duruyorsa adres değiştiğinde tek kayıt güncellenir. Aynı adres sipariş, fatura, profil ve destek kaydında ayrı ayrı duruyorsa birinin eski kalması çok kolaydır.
İlişkisel dünyada bunu 1NF, 2NF, 3NF gibi kurallarla anlatırız. Bu kuralların dili akademik görünebilir ama pratik karşılığı nettir: her tablo tek tür şeyi anlatsın, her alan doğru anahtara bağlı olsun, başka tablonun gerçeğini kopyalayıp kendine aitmiş gibi davranmasın.
- 1NF: alanlar bölünemeyen, düzenli değerler taşımalı.
- 2NF: tablo birleşik anahtara sahipse alanlar anahtarın tamamına bağlı olmalı.
- 3NF: anahtar olmayan alanlar birbirinin gerçeğini taşımamalı.
- Amaç tablo sayısını artırmak değil, değişen verinin nerede değişeceğini netleştirmektir.
Sadece ilişkisel veritabanlarında mı geçerli?
Normalizasyon en resmi ve net hâliyle PostgreSQL, MySQL gibi ilişkisel veritabanlarında karşımıza çıkar. Foreign key, unique constraint, join ve transaction gibi araçlar normalleştirilmiş modeli doğal şekilde destekler.
Ama normalizasyonun arkasındaki fikir yalnızca RDBMS’e ait değildir. MongoDB’de embed mi reference mı diye karar verirken, ClickHouse’ta boyut verisini tabloya kopyalayıp kopyalamayacağınızı düşünürken, Redis’te aynı ürün bilgisini kaç key içinde tutacağınızı seçerken aynı soruyla karşılaşırsınız: tekrar mı, tutarlılık mı, hız mı?
- PostgreSQL/MySQL: normalizasyon veri tutarlılığı için güçlü başlangıçtır.
- MongoDB: doküman içine gömmek okuma kolaylığı sağlar, referans vermek tekrar riskini azaltır.
- ClickHouse: analitik sorgularda denormalizasyon çoğu zaman bilinçli performans tercihidir.
- Redis: kaynak gerçeklik genellikle Redis değil, Redis’in beslediği ana veritabanıdır.
Denormalizasyon hata değil, borçtur
Denormalizasyon, veriyi bilerek tekrar etmektir. Kötü olmak zorunda değildir; hatta analitik sistemlerde ve yüksek okuma trafiğinde çok yararlı olabilir. Sorun, bu tekrarın kimin tarafından ve ne zaman güncelleneceğinin yazılmamasıdır.
Bir ürün adını sipariş satırına kopyalamak bazen doğrudur; çünkü geçmiş siparişin o günkü ürün adını göstermesi istenir. Ama müşterinin güncel e-posta adresini on farklı yere kopyalamak genellikle ileride tutarsızlık üretir.
Karar soruları
Bu veri ne kadar sık değişiyor? Eski değer tarihsel kayıt olarak gerekli mi? Okuma mı daha kritik, yazma tutarlılığı mı? Tekrar eden değer nasıl güncellenecek? Tutarsızlık olursa kullanıcı ne görür? Geri dönüş ve doğrulama nasıl yapılacak?
Pratik kural: önce doğru modeli kur, sonra ölçerek gevşet
Özellikle OLTP sistemlerde iyi başlangıç çoğu zaman makul normalizasyondur. Kullanıcı, sipariş, ödeme, adres, fatura gibi kavramlar net ayrılır. Sonra gerçek sorgu desenleri, rapor ihtiyacı ve performans ölçümleriyle nerede denormalizasyon gerektiği anlaşılır.
En pahalı hata, daha ihtiyaç doğmadan “ileride hızlı olur” diye her şeyi kopyalamaktır. İkinci pahalı hata ise raporlama ve analitik ihtiyacı büyüdüğü halde hâlâ her şeyi canlı OLTP modelinden join ile okumaya çalışmaktır.