Normalization BCNF 3NF - Database Management System

Bölüm 01

İyi Bir Relasyonel Tasarım Nedir?

Kötü tasarlanmış bir tablo, farklı konulara ait verileri tek bir yerde birleştirir. Bu durum hem veri tekrarına hem de çeşitli anomalilere yol açar. Örneğin aşağıdaki inst_dept tablosu hem öğretim üyesi bilgilerini (ID, name, salary) hem de bölüm bilgilerini (dept_name, building, budget) aynı anda tutar.

ID	name	salary	dept_name	building	budget
22222	Einstein	95000	Physics	Watson	70000
12121	Wu	90000	Finance	Painter	120000
45565	Katz	75000	Comp. Sci.	Taylor	100000
15151	Mozart	40000	Music	Packard	80000
33456	Gold	87000	Physics	Watson	70000
76543	Singh	80000	Finance	Painter	120000

Sarı renkteki satırlarda aynı bölüm bilgisinin tekrar ettiğine dikkat edin. Bu tekrar, üç tür anomaliye neden olur:

⚠️

Ekleme Anomalisi (Insertion)

Hiç öğretim üyesi olmayan yeni bir bölüm eklemek istesek, öğretim üyesi ID'si alanını NULL bırakmak zorunda kalırız. Bu veri bütünlüğünü bozar.

🔄

Güncelleme Anomalisi (Update)

Physics bölümünün binasını değiştirmek istediğimizde, bölüme ait tüm satırları güncellememiz gerekir. Bir tanesini atlamak tutarsızlık yaratır.

🗑️

Silme Anomalisi (Deletion)

15151 numaralı Mozart'ı tablodan silersek, Music bölümüne ait tüm bilgileri de kaybederiz. Bölüm hakkındaki veri yanlışlıkla silinmiş olur.

Çözüm: Ayrışım

Çözüm, büyük tabloyu daha küçük, anomalisiz tablolara ayırmaktır (decomposition). Örneğin inst_dept tablosunu ikiye bölebiliriz:

❌ Orijinal (Sorunlu)

inst_dept(ID, name, salary, dept_name, building, budget)

→

✅ Tablo 1

Instructors(ID, name, salary, dept_name)

✅ Tablo 2

Departments(dept_name, building, budget)

    ⚠ Dikkat: Kayıplı Ayrışım (Lossy Decomposition)
    Tüm ayrışımlar iyi değildir! Örneğin employee(ID, name, street, city, salary) tablosunu
    employee1(ID, name) ve employee2(name, street, city, salary) olarak böldüğümüzde,
    "name" ortak alan olur ama aynı isme sahip iki kişi varsa doğal birleşim (JOIN) yanlış satırlar üretir.
    Orijinal tablo geri kazanılamaz → bu kayıplı ayrışımdır.
  

    ✓ Kayıpsız Ayrışım (Lossless Decomposition)
    R = (A, B, C) → R1 = (A, B) ve R2 = (B, C) şeklinde böldüğümüzde,
    B ortak alan üzerinden JOIN yaparak orijinal tabloyu geri kazanabiliriz.
    B üzerinde fonksiyonel bağımlılık varsa bu her zaman kayıpsuzdur.
  

Bölüm 02

Fonksiyonel Bağımlılıklar (FD)

Bir tablodaki iki özellik (attribute) kümesi arasındaki belirleyicilik ilişkisine fonksiyonel bağımlılık denir. Sezgisel anlamı: "X değerini biliyorsak, Y değerini de kesin olarak biliyoruz."

    Tanım — Formal
    X → Y (X, Y'yi fonksiyonel olarak belirler)

    ∀ t, u ∈ R :  t[X] = u[X]  ⟹  t[Y] = u[Y]

    Yani: R ilişkisindeki herhangi iki kayıt X sütunlarında aynı değere sahipse, Y sütunlarında da aynı değere sahip olmak zorundadır.

Somut Örnek

Öğrenci tablosunu düşünelim: Student(SSN, SName, address, HScode, HSname, HScity, GPA, priority)

Üniversite politikasına göre öncelik (priority) tamamen GPA'ya göre belirleniyor:

GPA > 3.8 → priority = 1

3.3 < GPA ≤ 3.8 → priority = 2

GPA ≤ 3.3 → priority = 3

Aynı GPA'ya sahip iki öğrenci her zaman aynı önceliğe sahip olacağından:

    FD: GPA → priority
    ∀ t, u ∈ student:  t.GPA = u.GPA  ⟹  t.priority = u.priority
  

SSN	GPA	priority
111	3.9	1
222	3.9	1
333	3.4	2

Müşteri Örneği

Customers(name, addr, drinksLiked, manf, favDrink) tablosunda mantıklı FD'ler:

name → addr, favDrink

Aynı isme sahip iki müşteri, aynı adrese ve aynı favori içeceğe sahip olmak zorundadır. (Ad benzersiz kabul ediliyor.)

drinksLiked → manf

Aynı içeceği seven iki müşterinin üretici bilgisi aynı olmak zorundadır. Üretici, kişiye değil içeceğe bağlıdır.

    ⚡ Önemli Not
    Fonksiyonel bağımlılıklar gerçek dünya bilgisine dayanır. Yalnızca tablodaki veriye bakarak karar veremeyiz —
    alan (domain) bilgisi gerekir. Örneğin GPA → priority ilişkisi, okulun politikasından gelir; rastgele veriden çıkarılamaz.
  

Bölüm 03

FD Kuralları

Fonksiyonel bağımlılıklarla çalışırken kullanabileceğimiz temel dört kural vardır:

1. Bölme Kuralı (Splitting)

X → A₁A₂…Aₙ
⟺
X → A₁, X → A₂, …, X → Aₙ

Örnek: A → BC ≡ A → B ve A → C

⚠ Sol taraf bölünemez! AB → C ≠ A → C veya B → C

2. Birleştirme Kuralı (Combining)

X → A ve X → B
⟹
X → AB

Örnek: A→B, A→C, A→D ⟹ A→BCD

Bölme kuralının tersidir.

3. Geçişkenlik Kuralı (Transitive)

A → B ve B → C
⟹
A → C

Örnek: SSN→GPA, GPA→priority ⟹ SSN→priority

SSN'den GPA'ya, GPA'dan priority'ye ulaşıyorsak, SSN'den priority'ye de ulaşabiliriz.

4. Önemsiz (Trivial) FD Kuralı

X → Y, Y ⊆ X
⟹ Önemsiz (Trivial)

Örnekler: AB→A ✓, AB→B ✓, AB→AB ✓ (hepsi trivial)

Sağ taraf zaten sol tarafın içindeyse bu her zaman doğrudur, yeni bilgi vermez. "Trivial" denir çünkü bize hiçbir şey söylemez.

Ek Trivial Kurallar

X → Y ⟹ X → X ∪ Y

Birleşim kuralı: Eğer A→B ise, A→AB de geçerlidir (sol taraf zaten A'yı içeriyor).

X → Y ⟹ X → X ∩ Y

Kesişim kuralı: Eğer AB→BC ise, AB→B de geçerlidir (bölme kuralından türer).

Bölüm 04

Özellik Kapanışı (Closure)

Bir X özellik kümesinin kapanışı X⁺, X bilindiğinde kesin olarak elde edebileceğimiz tüm özelliklerin kümesidir.

    Soru
    "X'i bilirsem, hangi özellikleri de kesin olarak bilirim?"
  

Kapanış Hesaplama Algoritması

FD'lerin sağ taraflarını gerekiyorsa tek özelliğe böl (splitting rule).

Kapanışı sadece X ile başlat: X⁺ = {X}

Değişim duruncaya kadar tekrarla: Eğer sol tarafı tamamen X⁺ içinde olan bir FD (X→Y) varsa, Y'yi X⁺'a ekle.

Değişim olmadığında dur. Elde ettiğin küme X⁺'tır.

Örnek 1

Verilen FD'ler: A → B ve B → D

A⁺ Hesaplama

Başlangıç:

{A}

— başlangıç kümesi

A→B bulundu:

{A, B}

A mevcut, B eklendi

B→D bulundu:

{A, B, D}

B mevcut, D eklendi

Değişim yok:

A⁺ = {A, B, D}

✓ Sonuç

B⁺ Hesaplama

Başlangıç:

{B}

— başlangıç kümesi

B→D bulundu:

{B, D}

B mevcut, D eklendi

Değişim yok:

B⁺ = {B, D}

✓ Sonuç

Örnek 2 — Kapsamlı

Student(SSN, SName, address, HScode, HSname, HScity, GPA, priority)
FD'ler: SSN → SName address GPA | GPA → priority | HScode → HSname HScity

Soru: {SSN, HScode}⁺ = ?

Başlangıç:

{SSN, HScode}

—

SSN→SName address GPA:

{SSN, HScode, SName, address, GPA}

SSN mevcut

HScode→HSname HScity:

{SSN, HScode, SName, address, GPA, HSname, HScity}

HScode mevcut

GPA→priority:

{SSN, HScode, SName, address, GPA, HSname, HScity, priority}

GPA mevcut

Sonuç:

{SSN, HScode}⁺ = TÜM ÖZELLİKLER ✓

Süper Anahtar!

Bölüm 05

Süper Anahtar ve Anahtar

🔑

Süper Anahtar (Superkey)

K özellik kümesinin kapanışı K⁺ = tablodaki tüm özellikler ise, K bir süper anahtardır. Yani K, tablodaki her satırı benzersiz biçimde tanımlar.

K⁺ = tüm özellikler ⟹ K süper anahtar

🗝️

Anahtar (Key)

K bir süper anahtar ise VE K'nın hiçbir gerçek alt kümesi süper anahtar değilse, K bir anahtardır. Yani minimal (en küçük) süper anahtardır.

K süper anahtar ∧ ∄ K' ⊂ K : K' süper anahtar

Customers Örneği

Customers(name, addr, drinksLiked, manf, favDrink)
FD'ler: name → addr favDrink | drinksLiked → manf

Anahtar Bulma Süreci

{name}⁺ = {name, addr, favDrink} → manf eksik → süper anahtar değil

{drinksLiked}⁺ = {drinksLiked, manf} → name, addr, favDrink eksik → süper anahtar değil

{name, drinksLiked}⁺ = {name, addr, favDrink, drinksLiked, manf} = TÜM ÖZELLİKLER ✓ → Süper anahtar!

Alt kümeleri süper anahtar değil, {name, drinksLiked} minimal → Bu bir Anahtar (Key)!

    Sonuç
    {name, drinksLiked} → tek anahtar

    {name, drinksLiked, addr}, {name, drinksLiked, manf}, ... → Süper anahtarlar (ama minimal değil)
  

Bölüm 06

Boyce-Codd Normal Formu (BCNF)

Anomalilerin olmadığını garanti eden koşul BCNF'dir. Bir ilişki BCNF'dedir — eğer sahip olduğu her önemsiz olmayan (nontrivial) FD'nin sol tarafı bir süper anahtarsa.

    BCNF Tanımı
    R ilişkisi BCNF'dedir ⟺

    X → Y (nontrivial, yani Y ⊄ X) olan her FD için X bir süper anahtardır.
  

BCNF İhlali Örneği

Customers(name, addr, drinksLiked, manf, favDrink)
FD'ler: name → addr favDrink | drinksLiked → manf

🔍

Tek anahtar: {name, drinksLiked}

❌

name → addr: "name" bir süper anahtar mı? HAYIR → BCNF İHLALİ!

❌

drinksLiked → manf: "drinksLiked" bir süper anahtar mı? HAYIR → BCNF İHLALİ!

BCNF'ye Ayrışım Algoritması

X → Y İhlaliyle R'yi Ayrıştırma

BCNF ihlali olan bir FD seç: X → Y (X süper anahtar değil)

X'in kapanışını hesapla: X⁺

R₁ = X⁺ (X ve X'in belirlediği her şey)

R₂ = R – (X⁺ – X) (Orijinal tablo eksi yalnızca X ile belirlenenler, X kalsın)

R₁ ve R₂'yi ayrı ayrı BCNF kontrolünden geçir. İhlal varsa tekrar ayrıştır.

Tam Örnek: Customers Ayrışımı

Adım 1: name → addr ihlalini seç. {name}⁺ = {name, addr, favDrink}

Başlangıç

Customers(name, addr, drinksLiked, manf, favDrink)

→

R₁ = X⁺

Customers1(name, addr, favDrink)

FD: name → addr, favDrink ✓ BCNF

R₂ = R – (X⁺ – X)

Customers2(name, drinksLiked, manf)

drinksLiked → manf ihlali var!

Adım 2: Customers2'yi ayrıştır. {drinksLiked}⁺ = {drinksLiked, manf}

Customers2 (İhlal var)

Customers2(name, drinksLiked, manf)

→

Customers3 = X⁺

Customers3(drinksLiked, manf)

Anahtar: drinksLiked → BCNF ✓

Customers4 = R – (X⁺ – X)

Customers4(name, drinksLiked)

Anahtar: {name, drinksLiked} → BCNF ✓

    ✓ Nihai BCNF Ayrışımı
    Customers1(name, addr, favDrink) → Müşteri bilgileri

    Customers3(drinksLiked, manf)     → İçecek bilgileri

    Customers4(name, drinksLiked)     → Müşteri-İçecek ilişkisi

Bölüm 07

Üçüncü Normal Form (3NF)

BCNF mükemmeldir ama bir sorunu vardır: Bazı durumlarda ayrışım sırasında FD'leri kaybederiz. Bu, bazı kısıtları doğrulamak için pahalı JOIN işlemleri gerektiren bir durumdur. 3NF bu sorunu çözmek için BCNF'nin biraz daha gevşetilmiş halidir.

BCNF'nin Sorunu

Problem Senaryosu

R = (A, B, C)
FD1: AB → C
FD2: C → B

A = sokak adresi, B = şehir, C = posta kodu olarak düşünün.

Anahtarlar: {A,B} ve {A,C}

BCNF Ayrışımı

C → B ihlali var (C süper anahtar değil).

C⁺ = {C, B}
R1 = (B, C)
R2 = (A, C)

Problem: AB → C artık hiçbir tabloda doğrulanamaz! A, R1'de yok; B, R2'de yok.

R2 = (A=street, C=zip)		R1 = (B=city, C=zip)
545 Tech Sq.	02138	Cambridge — 02138
545 Tech Sq.	02139	Cambridge — 02139

    ⚠ Bağımlılık Kaybı!
    JOIN yapıldığında aynı sokağın iki farklı posta koduna bağlandığı görülüyor. AB→C kısıtı ihlal edildi ama tablo başına bu kontrol yapılamıyor. Dependency Preservation kaybedildi!
  

3NF Çözümü

3NF, BCNF koşulunu biraz gevşeterek bağımlılık korunumunu garanti eder.

    Prime Attribute (Asal Özellik) Tanımı
    Bir özellik, herhangi bir anahtarın üyesiyse "prime" (asal) denir.
  

    3NF Kuralı
    X → A, 3NF'yi ihlal eder  ⟺

    (1) X bir süper anahtar DEĞİL  VE

    (2) A bir prime (asal) özellik DEĞİL

3NF Örnek: R = (A, B, C)

Anahtarlar

{A,B}⁺ = {A,B,C} ✓ → Anahtar
{A,C}⁺ = {A,C,B} ✓ → Anahtar

Prime Özellikler

A → {AB}'de var → prime ✓
B → {AB}'de var → prime ✓
C → {AC}'de var → prime ✓
Tüm özellikler prime!

C → B, 3NF İhlali mi?

C süper anahtar mı? HAYIR ✗
B prime özellik mi? EVET ✓
Her iki koşul birden sağlanmalı → İkinci koşul sağlanmadığından 3NF İHLALİ YOK!
→ R = (A, B, C) 3NF'dedir ve ayrışıma gerek yoktur.

    ✓ Temel Fark
    BCNF'de C → B ihlali (C süper anahtar değil) → Ayrışım gerekir, FD kaybolur.

    3NF'de C → B ihlal değil (B prime, yani bir anahtarın üyesi) → Ayrışım gerekmez, FD korunur.
  

Bölüm 08

BCNF vs 3NF — Karşılaştırma

Her iki normal form da ayrışım için iki önemli özelliği hedefler:

🔗

Kayıpsız Birleşim (Lossless Join)

Ayrışımdan sonra JOIN yaparak orijinal tabloyu geri kazanabilmek. Hem BCNF hem 3NF bunu her zaman garantiler.

📋

Bağımlılık Korunumu (Dependency Preservation)

Ayrışımdan sonra tüm FD'leri ayrı tablolarda doğrulayabilmek (JOIN'siz). Yalnızca 3NF bunu her zaman garantiler.

Özellik	BCNF	3NF
Kayıpsız Birleşim	✓ Her zaman	✓ Her zaman
Bağımlılık Korunumu	✗ Her zaman değil	✓ Her zaman
Tekrarlılık (Redundancy)	✓ Hiç yok	⚠ Bazı tekrar olabilir
Her zaman elde edilebilir mi?	✓ Evet	✓ Evet
Koşul (İhlal)	X → Y, X süper anahtar değil	X → A, X süper anahtar değil VE A prime değil
Ne zaman kullan?	Bağımlılık korunumu önemsiz, sıfır tekrar isteniyor	Bağımlılık korunumu şart, biraz tekrar kabul edilebilir

Özet Kural Hatırlatması

BCNF Kontrol Adımları

1. Her FD için sol tarafı al
2. Kapanışını hesapla
3. Kapanış = tüm özellikler? → Süper anahtar → OK
4. Değilse → BCNF ihlali → Ayrıştır

3NF Kontrol Adımları

1. Tüm anahtarları bul
2. Prime (asal) özellikleri belirle
3. Her FD X→A için:
  — X süper anahtar ise → OK
  — A prime ise → OK
  — İkisi de değilse → 3NF ihlali

Genel Özet

Temel anomali türü: Ekleme, Güncelleme, Silme

Temel FD kuralı: Bölme, Birleştirme, Geçişkenlik, Önemsiz

X⁺

Kapanış: X'i bilirsek kesin olarak bildiğimiz her şey

Normal form: BCNF (güçlü) ve 3NF (esnek)

    Tasarım Rehberi
    ▸ Her FD'nin sol tarafı süper anahtar ise → BCNF (en güçlü)

    ▸ FD kaybetme riski varsa → 3NF tercih et

    ▸ Her iki normal form da kayıpsız birleşimi garanti eder

    ▸ Sadece 3NF, bağımlılık korumunu her zaman garanti eder

    ▸ BCNF seçersen, bazı FD'leri JOIN ile doğrulamak gerekebilir

BCNF ⟹ 3NF ama tersi doğru değil

3NF daha gevşek, daha esnek

Her ikisi de kayıpsız ayrışım garantiler

Multideğerli bağımlılıklar → 4NF