Bu yazıyı daha önce yazmayı düşünüyordum ama başlıktaki cümleyi tam olarak hatırlamam bir ayımı aldı . Sonunda cümleyi not aldığım yeri buldum ve konuyu buraya taşıyorum. Bu arada başlıktaki güzel sözün Jason Couhman ‘a ait olduğunu da öğrendim.

NORMALIZATION ve DE-NORMALIZATION kavramlarını bir buçuk ay önce moderatörü olduğum JDBC_TR  mail grubunda da tartışmaya açmıştım. Gerçekten de çok değişik cevaplar gelmişti. Bu yazıda normalization yada de-normalization nedir üzerinde durmayacağım. Merak edenler yada hiç bilgisi olmayanlar buradan birşeyler öğrenelebilirler.

Veritabanı yönetim sistemleri dersi alanlar yada az buçuk veritabanı kavramıyla işi olanlar normalization ve normal form terimlerini mutlaka duymuşlardır. Derslerde yada sınavlarda harıl harıl normalizasyon yapmaya çalıştığımızı hatırlıyorum. 1.NF(NORMAL FORM), 2.NF, 3.NF, 4.NF, 5.NF hatta 6. NF, BOYCE-CODD, DOMAIN/KEY olmak üzere benim bildiğim 8 adet normalizasyon kuralıvar. Bunlardan esas olanlar ilk 3 tanesidir. Yani ilk üç normal formu refleks olarak uygulayabilmeniz beklenir sizden.

Aslında bu normal form olayına öğrenme aşamasındayken dikkat ediyoruz , daha sonra tasarım yaparken zaten otomatik olarak normal yapmaya başlıyoruz herşeyi (Deneyime bağlı olarak değişebilir ). Bu cümle ile İLK HATAYI DA YAPMIŞ OLDUM çünkü normalizasyon tasarım (design) aşamasında değil analiz aşamasında yapılması gereken bir işlemdir. Yani oluşturulacak veritabanı üzerindeki işlemlerin , kullanıcı sayısının ve diğer kriterlerin iyi bir şekilde analiz edilmesinden sonra buna karar verilir. 

Peki normalizasyon bize neler kazandırır?

• Aynı veriden birden fazla olmasını engeller. (Avoids duplication)
• Veri girişini daha efektif hale getirir.
• Veri yönetimini kolayşlaştırır.
• Disk alanının daha efektif kullanılmasını sağlar.

Bunlar normalizasyonun güzel yanları ki hep derslerde bunlardan bahsedilir. Sürekli birşeyleri normalize ederiz ve sütten çıkma ak kaşık gibi görürüz normalizasyonu. Halbuki yan etkileri de vardır. Örneğin:

• Veri çekme  (Data Retrieval) işlemlerini zorlaştırır.
• Daha karmaşık SQL ifadeleri gerektirir. ( Joinler havalarda uçuşabilir )

İşte bu yan etkilerinden dolayı bazı sistemlerde veya senaryolarda normalizasyon yerine de-normalizasyon dediğimiz yöntem tercih edilir.

De-normalize bir yapıda çoğu bilgi aynı tabloda tutulur. Mesela veritabanımızda bir kullanıcya ait email adreslerini saklamak istiyoruz. Bunu normalize bir şekilde yapmak istersek ayrı bir e-mail tablosu yaratıp kullanıcıya ait unique (tekil) bir değerle birlikte mail adreslerini buraya kaydederiz ve bu tablolar arasında PK/FK ilişkisi kurarız. Ama de-normalize bir yapıda doğrudan kullanıcı bilgilerinin olduğu tabloya kolon ekleyerek (n adet e-mail kolonu) yada satır ekleyerek (tüm bilgiler aynı sadece e-mail alanı farklı bir satır) bu işi halledebiliriz. Eğer tüm bilgiler aynı tabloda olursa sorgulama ,raporlama gibi işlmeler daha hızlı ve kolayca halledilebilir.

Görülüyorki normalizasyon ve de-normalizasyon konusu ciddi bir analiz istiyor. Genel olarak OLTP (ONLINE TRANSACTION PROCESSING) ortamlarında Normalizasyon doğal bir yaklaşımken OLAP (ONLINE ANALYTICAL PROCESSING) ortamlarında da De-normalizasyon doğal bir yaklaşımdır. Verilerimizi normalize etmek uğruna yüzlerce tabloya bölerken ilerisini de düşünmekte fayda var diyorum. Özelikle Datawarehouse yada Data Mart ortamlarında daha az ve büyük boyutlu tablolarla çalışılarak sorgulardan daha hızlı sonuç alınması sağlanır. Milyonlarca kaydın bulunduğu tablolar arasında JOIN yapmaya kalkmak ciddi performans sorunları yaratabilir. Bu nedenle az değişen (rarely updated), daha çok listemele ve raporlama gibi amaçlarla kullanılan , çok fazla tablo arasında join işlemi gerektiren verilerde de-normlizasyon yapılabilir. Fakat güncellemenin çok olduğu veri gruplarında normalizasyon işlemi VERİ TUTARLILIĞI için şarttır.

Bu konu üzerinde araştırma yaparken özellikle analiz amaçlı kullanılacak veri grupları için kurumların normalize olan tablolardaki verileri de-normalize bir tablo yapısına kopyalayarak, analiz ,raporlama vb.  işlemleri bunlar üzerinde yaptıklarını öğrendim. Bu noktada kurumlar kararı ya danışman şirketlere bırakıyorlar yada DBA ‘lardan görüş alıyorlar. Bazıları da Allaha emanet yaşıyorlar .

Bir diğer nokta da aslında herşeyin böyle milimetrik hesaplanmadığı gerçeği . Yukarıda yazanlar neydi peki diye sorabilirsiniz ki haklısınız da ama biraz rahat olmakta fayda var. Tablolarımızı  normalize yada de-normalize etmek için günlük hayatta bu kadar da çok ince eleyip sık dokumuyoruz. Özellikle de donanımların ucuzlamasıyla sonra performans dar boğazlarını insanlar donanım yükseltmeleriyle aşar oldular. Her ne kadar bir yazılımcı olarak bu yaklaşımı kabul etmek istemesem de bazen yazılımsal çözümler ve bunların maliyetleri (iş gücü, zaman vs.) donanımsal çözümlerden kat kat fazla olabiliyor.

Veritabanı yönetim sistemleri dersinin projesinin ilk raporu verileceği zaman daha projeye başlamadığımız için bir saatlik yemek arasında 2 sayfalık senaryoyu 3 tablo ile halletmiştik (Nasıl becerdik hala inanamıyorum ) . Ama raporlar incelip düzeltilmek üzere geri dağıtılınca pek de birşey beceremediğimiz ortaya çıkmıştı. Biz de ikinci raporda herşeyi ayrı tablolara koymaya kalkışınca bu defa tablo sayımız 3 ‘ten 13 ‘e çıkmıştı ama iş tabloları sorgulamaya gelince ve insan JOIN özürlü olunca baya bir ecel teri dökmüştük.

İşte yukarıda okuduğunuz  yazı o günlerde yaşadığım perişanlığın bir yansımasıdır. Umarım keyif alarak ve birşeyler öğrenerek okumuşsunuzdur. Hepiniz sağlıcakla kalın ve beni okumaya devam edin…