Sayılar ve Kuramlar: Veri Modelini Normâlleştirmek
Bu konu daha genis kapsamli olarak Kurumsal Java kitabinda isleniyor.
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.
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.
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.
EYALET KISALTMA EYALET_NÜFUSU SEHIR GEÇEN_YILIN_NÜFUSU BU_YILIN_NÜFUSU YUZDE_ARTIS
North Carolina NC 5M Burlington, Raligh 40k, 200k 44k, 222k 10%, 11%
Vermont VT 4M Burlington 60k 67.2k 12%
New York NY 17M Albany, New York City, White Plains 500k, 14M, 100k 570k, 14.7M, 106k 8%, 5%, 6%
Ş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.
North Coralina NC 5M Burlington 40k 44k 10%
North Coralina NC 5M Raleigh 200k 222k 11%
New York NY 17M Albany 500k 540k 8%
New York NY 17M New York City 14M 14.7M 5%
New York NY 17M White Plains 100k 106k 6%
EYALET KISALTMA EYALET_NÜFUSU
North Carolina NC 5M
Vermont VT 4M
New York NY 17M
EYALET KISALTMA SEHIR GEÇEN_YILIN_NÜFUSU BU_YILIN_NÜFUSU YUZDE_ARTIS
North Coralina NC Burlington 40k 44k 10%
North Coralina NC Raleigh 200k 222k 11%
Vermont VT Burlington 60k 67.2k 12%
New York NY Albany 500k 540k 8%
New York NY New York City 14M 14.7M 5%
New York NY White Plains 100k 106k 6%
Üçü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.
North Carolina 5M
SEHIR KISALTMA GEÇEN_YILIN_NÜFUSU BU_YILIN_NÜFUSU YUZDE_ARTIS
Burlington NC 40k 44k 10%
Raleigh NC 200k 222k 11%
Burlington VT 60k 67.2k 12%
Albany NY 500k 540k 8%
New York City NY 14M 14.7M 5%
White Plains NY 100k 106k 6%
Gönderen Burak Bayramli zaman: 1:40 PM