Normâlleştirme (normalization), ilişkisel bir veri tabanı modelinin daha arı hale getirilmesidir. Normâlleştirme, aynı zamanda "ilk taslak" veri tabanı tasarımının üzerinde revizyonlar yapmanının yolu, taslağı son haline yaklaştırmanın yöntemlerden birisidir. Normâlleştirmenin altyapısı matematikseldir, aynen ilişkisel modelin kendisinin matematiksel olması gibi. Temel alınan kavram, işlevsel bağlılık (functional dependency) denen bir kavramdır.
Normalleştirmenin amaçları şunlardır.
Amaçlar
Veri bütünlüğünü sağlamak
Sadece bu öğe bile normalleştirme ile uğraşmak için yeterli bir sebeptir. Veri, bütünlüğü bozulmamış bir şekilde kalır, çünkü her çeşit bilgi, sadece bir kere tek bir yerde saklanır. Yani, bir veri çeşidinin kopyasının veri tabanının değişik çizelgeleri üzerinde saklanması gerekmez. Eğer veri gereksiz şekilde kopyalanmış ise, bu değişik kopyalar, kopyalardan habersiz olan uygulama kodları yüzünden bir süre sonra birbirinden farklı değerleri taşımaya başlayabilirler. Bu, doğruluk ve tutarlılık açısından çok kötü bir sonuçtur. Bu gibi durumlarda ilişkisel veri taban paketinizin otomatik bütünlük (automatic integrity) mekanizmaları bile işe yaramaz. Tedavinin, uygulama seviyesinde yapılması gerekir. Fakat bu da uygulama programlarını daha çetrefilli hâle getirecek, dolayısıyla onların bakımını zorlaştıracaktir.
Uygulamadan bağımsız bir veri modeli yaratmak
Normalleştirme, genelde bilinen ve takip edilen "ilişkisel model, verinin içeriğine göre kurulmalı, uygulama göre değil" kavramını bir adım daha öne alır. Bu sayede veri modeli, üzerinde onu kullanan uygulama değişse bile daha tutarlı, sabit ve değişmez olarak kalacaktır. Uygulama programının gereksinimlerinin veri tabanı mantıksal (logical) model üzerindeki etkisi sıfır olmalıdır. Daha ileride göreceğimiz gibi, uygulama, mantıksal model üzerinde değil, fiziksel (physical) model üzerinde etki yapar.
Depolama ihtiyaçlarını en aza indirgeme (ve arama kabiliyetini arttırma)
Yabancı/göstergeç anahtarların haricinde, tamamiyle normâlleştirilmiş bir veri tabanı gereksiz (kopyalanmış) veri miktarını en aza indirecektir. Kopyalanma miktarı azaldığı için, depo yerine olan ihtiyaçta azalır. Ve gene bu sayede, veri tabanı motorunun arama yapması da daha rahatlaşacaktır.
Normâlleştirme Örnekleri
Birinci Normal Formu
Bu form, tekrar eden hiç bir gurup taşımaz. Bir başka deyişle, bir hücre üzerinde taşınan değer tek ve basit olmalıdır. Aşağıdaki örnek veride, son sene nüfusu %5'den fazla artmış olan şehirlerden bazılarını görüyoruz.
Bu yeni veri modelinde, eyalet kolonu asal anahtar (primary key) olarak adledildi. Fakat bu son tabloda da bazı problemler var. Güncellemek ve silmek için, hala birçok veriye teker teker uğrayıp, verinin bütünlüğünü kod yazarak birarada tutmamız gerekiyor. Mesela eğer yeni bir şehir satırı ekleyecek olsak, beraberinde eyalet verisi de eklememiz lazım. Ya da bir eyaletin son şehrini veri tabanından silsek, bu eyaletin verisini veri tabanından tamamen kaybetmiş oluyoruz, vs. Problem nerede o zaman? Birazdan göreceğiz.
İkinci Normal Formu
2NF'de, daha önce 1NF örneğinde gördüğümüz gibi yarım bağımlılık bulunmaz. Anahtar olmayan her kolon, asal anahtara tamamen bağlı olmalıdır. Anahtar kolon, birden fazla kolonu kapsıyorsa, anahtar olmayan kolonlar anahtar kolonların hepsine tamamen bağlı olmalıdır. 2. Tablo bu kritere hâla uymuyor. Şehir bilgileri eyalet bilgisine bağlı değil. Daha detaylı olarak, bütün şehir kolonları (SEHIR, GEÇEN_YILIN_NÜFUSU, BU_YILIN_NÜFUSU, YUZDE_ARTIS) asal anahtar eyalet kolonuna (EYALET) tamamen bağlı değil.
Bu yüzden, birbirine tam bağlı olmayan bilgileri ayrı tablolara parçalamamız gerekiyor.


Şehir bilgilerinin bazılarının aynı hücre içerisinde guruplandığını görüyoruz. Bu yüzden bu tablo, normal değildir, 1NF bile değildir.
Bu tablodaki bilgiye bakarak, şehir bilgilerinden mesela BU_YILIN_NUFUSU kolonundaki nüfuslardan hangisinin hangi şehre ait olduğunu nereden bilebiliriz? Bir kolon içinde bile birçok nüfus ve birçok şehir var. Sorumluluğu veri modelinden uygulama programına atarak, sıraya göre bir eşleme düşünülebilir, fakat bu da en temel ilişkisel veri tabanı kuralı olan 'kolon içinde sıra olmaz' kuralının ihlalidir.
Bu veriyi 1NF (birinci normal formu) hâline getirmek için, tekrar eden gurupları (verileri) tek kolondan çıkarıp, değişik satırlara yaymak gerekir. Alttaki tabloda, üstteki verinin 1NF'e getirilmiş halini görebilirsiniz.


Üçüncü Normal Formu
| 3NF veri modelinde, anahtar olmayan hiçbir kolon, başka anahtar olmayan kolona bağlı olamaz. 2NF'de bütün kolonların asal anahtara bağlı olduğunu söylemiştik. 3NF'e göre, bu bağlantı dolaylı bile olamaz. Mesela, YUZDE_ARTIS kolonuna bakalım. Bu kolon, aslında GECEN_YILIN_NUFUSU ve BU_YILIN_NUFUSU kolonlarına bağlıdır, çünkü bu iki kolondaki değerlerden hesaplanır. Bu şekilde hesaplan kolonların öteki bir ismi de türetilen (derived) kolonlardır. Asal anahtara bağlılardır ama, bu bağlılık dolaylıdır, yani bağlı oldukları esas iki kolon asal anahtara bağlı olduğu için bağlılardır. |
Üçüncü normal formunda böyle kolonlara izin verilmez. YUZDE_ARTIS kolonu 3NF'de kaldırıp atılır. Bu değerin uygulama programı tarafından anlık hesaplaması beklenir. Bu değer sık erişiliyor ise, Oracle görüntü kavramı kullanılarak bu hesabın hayali bir tablo çerçevesinde servis edilmesi performans açısından yararlı olabilir.
Veri tabanının 3NF (en son) halini aşağıda görüyoruz.

