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, price3NF — Üçü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, countryPratikte ç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_idNormalizasyon Düzeyleri Karşılaştırma
| NF | Kural | Özet |
|---|---|---|
| 1NF | Atomik değerler, PK var | Her hücrede tek değer |
| 2NF | 1NF + kısmi bağımlılık yok | PK'nın tamamına bağımlı |
| 3NF | 2NF + geçişli bağımlılık yok | Non-key → non-key bağımlılık yok |
| BCNF | Her determinant aday anahtar | 3NF'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
AI Asistan
Sorularını yanıtlamaya hazır