← Kursa Dön
📄 Text · 40 min

Normalizasyon: 1NF, 2NF, 3NF, BCNF

Giriş — Neden Verileri Bölüyoruz?

Normalizasyon, veritabanındaki veri tekrarını azaltma ve veri bütünlüğünü artırma sürecidir. Amaç: her bilgi sadece bir yerde saklansın, güncelleme anomalileri oluşmasın.

🎯 Analoji: Telefon rehberinde her kişinin adresini yazdığını düşün. Bir kişi taşınırsa, o kişinin geçtiği her yerdeki adresini güncellemelisin. Normalizasyon: adresi ayrı bir yerde tut, kişiye sadece referans ver.


Normalizasyon Problemleri (Anomaliler)

Normalize edilmemiş tabloda üç tür anomali oluşur:

Denormalize tablo:
| order_id | customer_name | customer_city | product_name | price |
|----------|--------------|---------------|--------------|-------|
| 1        | Ahmet Yılmaz | İstanbul      | MacBook Pro  | 55000 |
| 2        | Ahmet Yılmaz | İstanbul      | Mouse        | 300   |
| 3        | Zeynep Kaya  | Ankara        | iPhone       | 65000 |
  • Ekleme anomalisi: Yeni ürün eklemek istiyorsun ama sipariş yok — satır ekleyemezsin

  • Güncelleme anomalisi: Ahmet taşındı → iki satırda güncelleme gerekir → birini unutursan tutarsızlık

  • Silme anomalisi: Zeynep'in siparişini silersen, müşteri bilgisi de kaybolur


1NF — Birinci Normal Form

Kurallar:

  • Her hücrede tek bir değer (atomik)

  • Her satır benzersiz (primary key var)

  • Tekrar eden gruplar yok

-- ❌ 1NF ihlali: Birden fazla telefon tek hücrede
| customer_id | name  | phones                    |
| 1           | Ahmet | 0555-111, 0555-222        |

-- ✅ 1NF: Her telefon ayrı satırda veya ayrı tabloda
CREATE TABLE customer_phones (
    phone_id INT PRIMARY KEY AUTO_INCREMENT,
    customer_id INT NOT NULL,
    phone VARCHAR(20) NOT NULL,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

2NF — İkinci Normal Form

Kurallar: 1NF + kısmi bağımlılık yok (composite PK'daki her sütuna tam bağımlılık)

-- ❌ 2NF ihlali: product_name sadece product_id'ye bağlı (order_id'ye değil)
-- PK: (order_id, product_id)
| order_id | product_id | quantity | product_name | product_price |
|----------|-----------|----------|--------------|---------------|

-- ✅ 2NF: Ürün bilgilerini ayır
-- order_items tablosu: order_id, product_id, quantity, unit_price
-- products tablosu: product_id, product_name, price

3NF — Üçüncü Normal Form

Kurallar: 2NF + geçişli bağımlılık yok (non-key sütun başka non-key sütuna bağlı olmamalı)

-- ❌ 3NF ihlali: city → country (geçişli bağımlılık)
| customer_id | name  | city     | country |
-- city country'i belirliyor, customer_id city'i belirliyor

-- ✅ 3NF: Şehir-ülke ilişkisini ayır
-- customers: customer_id, name, city_id
-- cities: city_id, city_name, country

Pratikte çoğu uygulama 3NF'e kadar normalize eder — yeterlidir.


BCNF — Boyce-Codd Normal Form

3NF'in güçlendirilmiş hali. Her determinant (belirleyici) aday anahtar olmalı.

-- ❌ BCNF ihlali: 
-- professor bir subject'i belirliyor ama aday anahtar değil
| student | subject | professor |
-- professor → subject (ama professor PK değil)

-- ✅ BCNF: Ayrı tabloya al
-- student_courses: student_id, professor_id
-- professors: professor_id, subject_id

Normalizasyon Düzeyleri Karşılaştırma

NFKuralÖzet
1NFAtomik değerler, PK varHer hücrede tek değer
2NF1NF + kısmi bağımlılık yokPK'nın tamamına bağımlı
3NF2NF + geçişli bağımlılık yokNon-key → non-key bağımlılık yok
BCNFHer determinant aday anahtar3NF'in güçlendirilmişi

Pratik Kural

💡 Çoğu uygulama için 3NF yeterlidir. Aşırı normalizasyon sorgu karmaşıklığını ve JOIN sayısını artırır. Denormalizasyon ne zaman yapılacağını bir sonraki derste göreceğiz.


Özet

  • Normalizasyon veri tekrarını azaltır, anomalileri önler

  • 1NF: atomik değerler, PK var

  • 2NF: kısmi bağımlılık yok (composite PK'ya tam bağımlılık)

  • 3NF: geçişli bağımlılık yok (non-key sütunlar sadece PK'ya bağımlı)

  • BCNF: her determinant aday anahtar

  • Pratikte 3NF hedefi yeterlidir — performans gerekiyorsa denormalizasyon düşün