Veritabanında Kaostan Düzene: Normalizasyonun Hikayesi

Bir gün uyandığınızı ve şirketinizin tüm müşteri verilerinin, siparişlerinin ve ürün stoklarının tek bir Excel dosyasında, rastgele girildiğini hayal edin. Bir müşterinin adresini güncellemek için 500 satırı değiştirmeniz gerekiyor; bir satırı sildiğinizde ise o ayki tüm satış raporlarınız yok oluyor. İşte bu, veri anomalisinin tam kendisidir.

Veritabanı dünyasında bu kaostan kurtulmanın yolu Normalizasyon basamaklarını tırmanmaktan geçer. Gelin, “Kabus Tablo” adını verdiğimiz bir yapıyı alalım ve onu modern bir veritabanı mimarisine dönüştürelim.

0. Adım: Kaosun Başlangıcı (0NF)

Elimizde her şeyin iç içe geçtiği bir tablo var. Bir satırda birden fazla kurs, her kursta farklı eğitmenler ve tekrarlayan bilgiler…

Kabus Tablo (Normalleşmemiş)

[!CAUTION] Buradaki Sorunlar:

• Atomik Olmayan Veri: AlınanKurslar sütununda birden fazla değer var. Programatik olarak bir öğrencinin kaç kurs aldığını saymak bile bir işkence.

• Veri Tekrarı: Berk Can ismi her SQL kursunda tekrar edecek.

• Silme Anomalisi: Ahmet Yılmaz kaydını silersek, Java kursunun bilgisini ve ücretini de kaybederiz.

1. Normal Form (1NF): Atomik Güç

Kural: Her hücrede tek bir değer olmalı ve her satır eşsiz olmalıdır.

Neyi Değiştiriyoruz?

AlınanKurslar ve KursEgitmeni sütunlarını parçalıyoruz. Her kursu ayrı bir satır yapıyoruz.

1NF Sonrası Yapı

Neden Detaylı Anlatım: Artık verilerimiz atomik. Ancak hâlâ büyük bir sorunumuz var: Kısmi Bağımlılık. OgrenciAdı sadece OgrenciID‘ye bağlı, ama bu tablonun birincil anahtarı artık (OgrenciID + KursAdı) birleşimidir.

2. Normal Form (2NF): Kısmi Bağımlılıklara Veda

Kural: 1NF sağlanmalı ve anahtar olmayan tüm sütunlar, birleşik anahtarın tamamına bağımlı olmalıdır.

Neyi Değiştiriyoruz?

Sadece öğrenci bilgisini içeren sütunlarını (OgrenciAdı) ve kurs bilgisini içeren sütunlarını (KursUcreti, EgitmenAdı) birbirinden ayırıyoruz.

Tablo: Öğrenciler (2NF)

Tablo: Kurs Kayıtları (2NF)

[!TIP] Analiz: Bu adımda öğrenci ismini bir kez saklayarak veri tekrarını büyük oranda azalttık. Ancak KursKayitlari tablosunda hâlâ bir problem var: KursUcreti aslında KursAdı‘na bağlıdır, eğitmenin kim olduğuyla doğrudan ilgisi yoktur. Bu da bizi 3NF’ye götürür.

3. Normal Form (3NF): Geçişli Bağımlılık Zincirini Kırmak

Kural: 2NF sağlanmalı ve anahtar olmayan sütunlar arasında bağımlılık olmamalıdır (A -> B -> C durumu).

Neyi Değiştiriyoruz?

KursAdı, EgitmenAdı ve KursUcreti arasındaki ilişkiyi koparıp kurs detaylarını kendi tablosuna alıyoruz.

Tablo: Kurs Detayları (3NF)

Tablo: Kurs Katılımları (3NF)

Sonuç: Artık bir kursun ücretini değiştirmek istediğimizde sadece Kurs Detayları (3NF) tablosunda tek bir hücreyi güncellememiz yeterli. Binlerce kayıt arasında tutarsızlık çıkma ihtimali sıfıra indi!

İleri Formlar: BCNF ve Ötesi

Bazen 3NF bile yetmeyebilir. Özellikle aday anahtarların çakıştığı karmaşık senaryolarda Boyce-Codd Normal Formu (BCNF) devreye girer. BCNF, “Her belirleyici (determinant) bir aday anahtar olmalıdır” der.

Eğer bir eğitmen birden fazla kurs verebiliyorsa ama her kursun sadece bir eğitmeni varsa, bu ilişkiyi de tabloları daha fazla bölerek (Eğitmen-Kurs tablosu gibi) optimize etmek gerekir.

Özet: Hangi Adımda Ne Yaptık?

Son Söz

Normalizasyon bir varış noktası değil, bir denge arayışıdır. Veritabanını çok fazla bölerseniz JOIN işlemleri sistemi yorabilir; az bölerseniz veri anomalileri işinizi mahvedebilir. Profesyonel bir tasarımcı, genellikle 3NF veya BCNF seviyesinde durur ve sistemin ihtiyacına göre dengeyi kurar.

Verinizi düzenli tutun, veritabınız size sadık kalsın!