Veritabanı normalizasyonu nedir (ve kurallar ne zaman çiğnenmeli)?

Veritabanı normalizasyonu, birinci normal form, ikinci normal form gibi kulağa Latince gelen kurallarla dolu akademik bir konu olarak bilinir. Oysa altında yatan fikir ferahlatıcı derecede pratiktir: Verilerinizi, aynı bilginin asla iki ayrı yerde saklanmasına gerek kalmayacak şekilde düzenleyin; çünkü saklandığı anda o iki yer er geç birbiriyle çelişecektir.

Normalizasyonun çözdüğü temel sorun

Bir siparişi, müşterinin tam adı ve e-posta adresiyle birlikte her satıra doğrudan kaydeden bir tablo düşünün. O müşteri e-posta adresini güncellediğinde, ondan bahseden tüm sipariş satırlarını güncellemeniz gerekir. Tek bir satırı bile atlarsanız verileriniz sessizce tutarsız hâle gelir ve aynı veritabanında iki farklı “gerçek” yaşamaya başlar. Normalizasyon bu sorunu, müşteri bilgilerini tek bir yerde (bir müşteriler tablosunda) saklayıp ihtiyaç duyulan her yerden ID ile referans vererek çözer.

Jargonsuz normal formlar

• Birinci normal form: Her sütun tek bir alana sıkıştırılmış bir liste değil, tek bir değer tutar. Virgülle ayrılmış üç numara içeren bir “phone_numbers” sütunu bu kuralı çiğner.
• İkinci normal form: Anahtar olmayan her sütun, birincil anahtarın yalnızca bir kısmına değil, tamamına bağlıdır. Bu, esas olarak bileşik anahtarlı tablolar için geçerlidir.
• Üçüncü normal form: Anahtar olmayan sütunlar birbirine değil, yalnızca anahtara bağlıdır. Bir müşterinin şehri posta kodundan çıkarılabiliyorsa, ikisini birden doğrudan saklamak er geç birbirleriyle çelişmelerine davetiye çıkarır.

Pratikte iyi tasarlanmış sistemlerin çoğu üçüncü normal formu hedefler ve orada durur. Daha ötesi çoğunlukla gerçek canlı şemalarda değil, ders kitaplarında karşımıza çıkar.

Normalizasyon size ne kazandırır?

Yanlışlıkla senkronizasyonu bozulabilecek tekrarlanmış bilgiler içermeyen tutarlı veriler; aynı değerleri satırlar boyunca tekrarlamadığınız için daha az depolama alanı; ve daha kolay güncellemeler: Bir bilgiyi tek bir yerde değiştirirsiniz, ona yapılan her referans değişikliği otomatik olarak yansıtır.

Katı normalizasyonun size maliyet çıkarmaya başladığı yer

Bunun bedeli sorgu karmaşıklığıdır. Çok sayıda küçük tabloya dağılmış, yüksek düzeyde normalize edilmiş veriler çoğu zaman basit bir soruyu cevaplamak için yarım düzine tabloyu birleştirmek anlamına gelir ve her join'in gerçek bir performans maliyeti vardır. Okuma ağırlıklı sistemlerde — raporlama panelleri, analitik ya da yazmaktan çok daha sık sorgu yaptığınız her şey — bu maliyet gerçekten önem kazanabilir.

Bilinçli denormalizasyon tam da burada devreye girer: daha hızlı okumalar karşılığında maliyetli join'lerden kaçınmak için bazı verileri kasıtlı olarak tekrarlamak. Bu, bilinçli bir tercih olduğu ve kazara yapılmadığı sürece bir tasarım kusuru değil, meşru ve yaygın bir stratejidir. Pek çok gerçek sistem, temel işlem verilerini normalize eder ve ardından özellikle raporlama ya da paneller için okumaya optimize edilmiş, denormalize bir kopya tutar.

Pratik sonuç

Varsayılan olarak normalize edin; özellikle tutarlılığın gerçekten önemli olduğu veriler için: para, stok ya da asla sessizce kendisiyle çelişmemesi gereken her şey. Denormalizasyonu ise bilinçli olarak ve yalnızca join'lerin yol açtığı gerçek bir performans sorununu ölçtüğünüz yerlerde yapın. Bu ödünleşimi önce ölçmeden, herhangi bir yönde tahmine dayalı olarak yönetmek, şemaların ya verimli şekilde sorgulanması imkânsız ya da belli belirsiz senkronizasyonu bozulmuş verilerle dolu hâle gelmesinin sebebidir. Bu dengeyi belirli bir ürünün gerçek okuma ve yazma kalıplarına göre doğru kurmak, özel yazılım ve altyapı çalışmalarımızın özünde yer alır.