SQL Veri Tabanı Normalizasyonu Nedir?

Web uygulamalarından büyük kurumsal sistemlere kadar, verilerin nasıl depolandığı ve yönetildiği bir projenin başarısını belirleyen en kritik unsurdur. Veritabanı tasarımı yaparken karşımıza çıkan en önemli mühendislik adımlarından biri olan Veritabanı Normalizasyonu (Database Normalization), verileri bir veritabanında en verimli ve mantıksal şekilde organize etme sürecidir.

Bir veritabanını normalize etmenin arkasında yatan iki temel amaç vardır: Birincisi, aynı verinin birden fazla tabloda tekrar tekrar saklanması gibi gereksiz veri fazlalıklarını (redundant data) ortadan kaldırmak; ikincisi ise veri bağımlılıklarının mantıklı bir yapıya oturmasını sağlamaktır. SQL (Yapılandırılmış Sorgu Dili), veritabanındaki tekrarları azaltmak ve verileri düzenlemek için normalizasyon süreçlerini temel bir standart olarak destekler. Bu işlemler sadece disk alanından tasarruf sağlamakla kalmaz, aynı zamanda sistemin veri bütünlüğünü (data integrity) garanti altına alarak verilerin güvenilirliğini artırır.

Normalizasyon yönergeleri, veritabanı yapınızın düzenlenme biçimini belirleyen ve “Normal Formlar” adı verilen belirli kurallar dizisine ayrılmıştır. Bir veritabanı tasarımı adım adım Birinci Normal Form (1NF), ardından İkinci Normal Form (2NF) ve Üçüncü Normal Form (3NF) kurallarına uygun hale getirilir. Sistemi Dördüncü (4NF) veya Beşinci Normal Form (5NF) seviyelerine taşımak da mümkün olsa da, endüstri standardı olarak genel kabul gören yaklaşım Üçüncü Normal Form’un (3NF) çoğu veritabanı projesi için yeterli ve en ideal seviye olmasıdır.

Aşağıda, ilişkisel veritabanı yönetim sistemlerinde (RDBMS) veriyi kusursuz bir şekilde yapılandırmanızı sağlayacak temel normalizasyon formlarını ve kurallarını inceleyebilirsiniz.

1. Birinci Normal Form (1NF – First Normal Form)

Birinci normal form, organize bir veritabanı için gereken en temel yapı taşlarını ve kuralları belirler. Tablonuzun 1NF kurallarına uyduğundan emin olmak için şu üç temel kuralı uygulamanız gerekir:

• Veri Öğelerini Tanımlayın: Depolanacak veriler sütunlar halinde organize edilmeli, her bir sütunun veri tipi (data type) belirlenmeli ve ilişkili sütunlar kendi özel tablolarına yerleştirilmelidir.
• Tekrarlayan Veri Gruplarını (Repeating Groups) Kaldırın: Tüm değerler atomik (bölünemez) olmalı ve tabloda aynı türden verilerin tekrar ettiği gruplar bulunmamalıdır.
• Birincil Anahtar (Primary Key) Atayın: Tablodaki her bir kaydı (satırı) diğerlerinden ayıran benzersiz bir anahtar bulunmalıdır.

Örnek Senaryo: Bir “Müşteriler” tablonuz olduğunu ve bir müşterinin birden fazla siparişini kaydetmek istediğinizi düşünün. Müşterinin adını, yaşını ve adresini her yeni sipariş için tekrar tekrar yeni satırlarda veritabanına girmek (Örn: Sachin – 36 – Cannon XL-200, Sachin – 36 – Battery XL-200 şeklinde alt alta yazmak) 1NF kuralını ihlal eder. Bunun yerine, veriler ikiye bölünmelidir: Müşteri bilgilerini tutan özel bir “MÜŞTERİLER” tablosu (ID, İsim, Yaş, Adres) ve siparişleri tutan ayrı bir “SİPARİŞLER” tablosu (ID, Müşteri_ID, Sipariş_İçeriği) oluşturulur. Ardından bu iki tablo benzersiz Müşteri ID’leri (Primary Key) üzerinden birbirine bağlanır.

2. İkinci Normal Form (2NF – Second Normal Form)

Bir tablonun 2NF olarak kabul edilebilmesi için öncelikle 1NF’nin tüm kurallarına uyması şarttır. Bunun üzerine eklenen kural şudur: Birincil anahtara (Primary Key) hiçbir kısmi bağımlılık (partial dependence) olmamalıdır.

Örnek Senaryo: Bir e-ticaret veritabanında müşteri ve sipariş bilgilerinin birlikte tutulduğu, birincil anahtarın CUST_ID (Müşteri ID) ve ORDER_ID (Sipariş ID) birleşimiyle (composite key) oluşturulduğu tek bir tablo düşünelim. Bu tabloda CUST_NAME (Müşteri Adı), ORDER_DETAIL (Sipariş Detayı) ve SALE_DATE (Satış Tarihi) gibi sütunlar yer almaktadır. Tablo 1NF’dir ancak 2NF değildir. Neden mi? Çünkü bir müşterinin adı (CUST_NAME) yalnızca CUST_ID‘ye bağımlıdır, sipariş numarasıyla (ORDER_ID) hiçbir doğrudan mantıksal bağı yoktur. Aynı şekilde siparişin detayı veya tarihi de müşterinin kimliğine değil, doğrudan siparişin kendisine (ORDER_ID) bağımlıdır.

Çözüm: Bu kısmi bağımlılıkları çözmek ve yapıyı 2NF’ye uyumlu hale getirmek için veritabanını üç bağımsız tabloya ayırmanız gerekir:

1. Yalnızca müşteri ID’si ve adının yer aldığı bir müşteri tablosu.
2. Yalnızca sipariş ID’si ve sipariş detaylarının yer aldığı bir sipariş tablosu.
3. Hangi müşterinin hangi siparişi verdiğini eşleştiren, sadece CUST_ID ve ORDER_ID bilgilerini barındıran bir takip (köprü) tablosu.

3. Üçüncü Normal Form (3NF – Third Normal Form)

Bir tablo, ancak 2NF kurallarını karşılıyorsa ve geçişli bağımlılıklar (transitive dependencies) tamamen ortadan kaldırılmışsa 3NF kabul edilir. Diğer bir deyişle, birincil anahtar (Primary Key) olmayan tüm alanlar, yalnızca ve doğrudan birincil anahtara bağımlı olmak zorundadır.

Örnek Senaryo: Sisteminize kayıtlı kişileri tuttuğunuz bir CUSTOMERS tablonuz olsun. Bu tabloda CUST_ID (Birincil Anahtar), İsim, Doğum Tarihi, Sokak, Şehir, Eyalet ve Posta Kodu (ZIP) alanları yer almaktadır. İlk bakışta her şey normal görünse de, Şehir, Eyalet ve Sokak isimleri aslında doğrudan müşteriye değil, Posta Koduna (ZIP) ayrılmaz bir şekilde bağlıdır. Birincil anahtar olmayan Eyalet ve Şehir bilgisinin, yine birincil anahtar olmayan Posta Koduna bağımlı olması bir “geçişli bağımlılıktır” (transitive dependency).

Çözüm: Sistemi 3NF kurallarına göre normalize etmek için, Posta Kodu, Sokak, Şehir ve Eyalet verilerini ana tablodan ayırarak kendi başlarına bağımsız bir ADDRESS (Adres veya Zip Kodu) tablosuna taşımalısınız. Kalan ana CUSTOMERS tablosunda ise lokasyon bilgisi olarak yalnızca Posta Kodu (ZIP) referansını bırakmanız yeterli olacaktır.

Normalizasyon Neden Bu Kadar Önemlidir?

Veritabanınızı Üçüncü Normal Form (3NF) seviyesine kadar optimize etmenin, yani geçişli ve kısmi bağımlılıkları kaldırmanın size sağlayacağı iki devasa avantaj bulunmaktadır:

1. Gereksiz Veri Tekrarının Önlenmesi ve Performans: Verilerin kopyalanması (duplication) önemli ölçüde azalır. Veritabanınız disk üzerinde çok daha az depolama alanı tüketerek küçülür, bu da sunucu maliyetlerinizi düşürürken sorgu performansınızı artırır.
2. Veri Bütünlüğü (Data Integrity) ve Güvenlik: Normalizasyonun getirdiği en kritik fayda veri bütünlüğüdür. Eğer adres ve posta kodu bilgileri normalizasyon yapılmadan 3-4 farklı tabloda tekrar tekrar saklansaydı, bir posta kodunun sınırı veya bağlı olduğu şehir değiştiğinde, sistemdeki o posta kodunu içeren her bir tabloyu bulup tek tek güncellemeniz gerekirdi. Bu manuel güncelleme işlemleri esnasında verilerin sadece bir kısmının güncellenmesi riski doğar, bu da sistemde büyük bir veri tutarsızlığı (corruption) yaratır. Oysa 3NF ile tasarlanmış bir mimaride adres verisi tek bir tabloda bulunur ve sadece oradan güncellenmesi tüm sistemdeki hataları engellemek için yeterlidir.

Özetle, web sitenizin veya yazılım projenizin sağlam bir altyapıya sahip olması, hata vermeden ölçeklenebilmesi ve yıllarca sorunsuz bir biçimde çalışabilmesi için SQL tablolarınızı oluştururken 1NF, 2NF ve 3NF normalizasyon kurallarını projenizin kalbine yerleştirmelisiniz. Normalizasyon, ilişkisel veritabanlarının veriyi kusursuz bir şekilde anlamlandırmasını sağlayan en büyük gücüdür.