Veritabanı normalizasyonu — 1NF, 2NF, 3NF tek cümlede

Veritabanı normalizasyonu tek cümlede şöyle özetlenebilir: "Aynı gerçeği yalnızca tek bir yerde saklayın." Bunu sistemli biçimde yapmanın yolu da 1NF → 2NF → 3NF’dir.

Neden önemli? Çünkü aynı bilgi birden fazla satıra dağılmışsa, siz birini güncelleyip diğerlerini güncellemediğiniz anda veri çelişkili hale gelir. Buna güncelleme anomalisi denir. Aşağıda bunu doğrudan deneyimleyin.

Prof.A’nın ofisi değiştiğinde, normalleştirilmemiş bir tabloda 2 satırı da elle güncellemeniz gerekir. Bir tanesini bile atlarsanız, "Prof.A hem Room 301’de hem de Room 502’de" gibi bir çelişki ortaya çıkar. 3NF tabloda ise yalnızca 1 satırı güncellemeniz yeterlidir.

Normalizasyonun özü tam olarak budur — geri kalan her şey, "hangi sütun nereye konmalı ki bilgi yalnızca tek bir yerde saklansın?" sorusuna cevap veren kurallardır.

Fonksiyonel bağımlılık — normalizasyonun karar ölçütü

Normalizasyon, "bu sütun neye bağlı?" sorusunu inceler. Buna fonksiyonel bağımlılık denir.

Örneğin student_id → student_name, "öğrenci ID’sini biliyorsanız adı belirlenir" anlamına gelir.

Aşağıdaki diyagramda okların renklerine dikkat edin:

• Yeşil = tüm anahtara bağlı (normal)
• Sarı = anahtarın yalnızca bir kısmına bağlı (kısmi bağımlılık → 2NF ihlali)
• Kırmızı kesikli = anahtar olmayan bir sütun üzerinden bağlı (geçişli bağımlılık → 3NF ihlali)

Sarı ve kırmızı okları ortadan kaldırmak = tabloyu bölmek = normalizasyon yapmak demektir.

1NF → 2NF → 3NF’e tek bakışta

Aşağıda tabloların adım adım nasıl bölündüğünü tıklayarak inceleyin. Kırmızı hücreler, "bu sütun burada olmamalı" anlamına gelir.

1NF: Bir hücrede tek değer

Bir hücreye MATH101, CS102 gibi birden fazla değer koyarsanız ne düzgün arama yapabilirsiniz ne de JOIN kullanabilirsiniz.

Kural: Tüm hücreler atomik olmalıdır, yani her hücrede tek bir değer bulunmalıdır.

phone1, phone2, phone3 gibi sütunlar da aynı sorunu taşır — sadece değeri sütun adının içine gizlemiş olursunuz.

2NF: Kısmi bağımlılığı kaldırma

Bileşik anahtarı (student_id, course_id) olan bir tabloda student_name, yalnızca student_id’ye bağlıdır. Yani tüm anahtara değil, sadece bir kısmına bağlıdır — buna kısmi fonksiyonel bağımlılık denir.

Kural: Anahtar olmayan tüm sütunlar anahtarın tamamına bağlı olmalıdır.

Kısmi bağımlılık varsa, o sütunu ayırıp ayrı bir tabloya taşırsınız.

Anahtar tek sütundan oluşuyorsa ne olur? Kısmi bağımlılık zaten mümkün değildir; dolayısıyla tablo 1NF ise otomatik olarak 2NF’tedir.

3NF: Geçişli bağımlılığı kaldırma

Courses tablosunda instructor_office, doğrudan course_id’ye (anahtara) bağlı değildir. Bunun yerine course_id → instructor_id → instructor_office yolunu izler — yani anahtar olmayan bir sütun, başka bir anahtar olmayan sütuna bağlıdır. Buna geçişli bağımlılık denir.

Kural: Anahtar olmayan sütunlar yalnızca anahtar üzerinden bağımlı olmalıdır. Arada başka bir anahtar olmayan sütun olmamalıdır.

Çözüm: instructor_office sütununu Instructors tablosuna ayırmak.

Ezber yerine tek bir soru

"Anahtar olmayan tüm öznitelikler anahtara, anahtarın tamamına ve yalnızca anahtara bağlı olmalıdır."

Bütün mesele bu cümlede:

• anahtara = 1NF (bir gerçeğin anahtarla tanımlanabilir olması gerekir)
• anahtarın tamamına = 2NF (anahtarın bir kısmına değil, tamamına bağlı olmalı)
• yalnızca anahtara = 3NF (başka anahtar olmayan sütunlar üzerinden değil, doğrudan anahtara bağlı olmalı)

Sınavda bir normalizasyon sorusu görürseniz, sadece şu soruyu sorun: "Bu sütun kime bağlı? Tüm anahtara mı, anahtarın bir kısmına mı, yoksa anahtar olmayan başka bir sütuna mı?"

Sık yapılan hatalar

"3NF’ye geldiysek iş bitti" — 3NF iyi bir başlangıç noktasıdır, ama son durak değildir. Bazı durumlarda daha katı olan BCNF gerekir; bazı durumlarda ise performans için bilinçli olarak denormalization yapılır.

"Ne kadar çok tabloya bölersek o kadar iyi" — normalizasyonun amacı tablo sayısını artırmak değil, "her tablonun yalnızca tek tür gerçeği temsil etmesini" sağlamaktır. Ortada bölmeyi gerektiren bir neden (bağımlılık ilişkisi) yokken tabloyu bölmek sadece JOIN’leri gereksiz yere karmaşıklaştırır.

"NoSQL kullanıyorsam normalizasyona gerek yok" — normalizasyon ilişkisel DB’ye özgü bir terimdir, ama "tekrarlanan verinin tutarlılığını koruma" problemi her tür DB’de vardır. Denormalization yaparken bile, "neyden vazgeçtiğinizi" bilerek yapmalısınız.

Kendiniz kontrol edin

Kendi projenizden bir tablo seçin ve şunları yapın:

1. Anahtarın ne olduğunu yazın.
2. Her anahtar olmayan sütunun, anahtarın tamamına mı yoksa sadece bir kısmına mı bağlı olduğunu kontrol edin. → Sadece bir kısmına bağlıysa 2NF ihlalidir.
3. Anahtar olmayan bir sütunun başka bir anahtar olmayan sütuna bağlı olup olmadığını kontrol edin. → Varsa 3NF ihlalidir.

Sadece bu 3 adımla, normalizasyonla ilgili sorunların büyük kısmını yakalayabilirsiniz.