Başlangıç > BİLGİSAYAR MÜHENDİSLİĞİ, DATABASE, NEDİR? > NORMALIZE UNTIL IT HURTS DE-NORMALIZE UNTIL IT WORKS

NORMALIZE UNTIL IT HURTS DE-NORMALIZE UNTIL IT WORKS

database.gifBu 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…  

Reklamlar
  1. Mart 28, 2007, 12:22 pm

    Selam İbrahim,

    Yazı için teşekkürler. Günlük hayatta çok sık karşılaştığımız bir konuya değinmişsin. Başlık ayrı bir güzelmiş, ben de hemen not ettim bi kenara:)

    Küçük ve orta ölçekli yazılımlarda dediğin gibi veritabanı konusunda gerçekten öyle çok inceden inceye düşünülmüyor. Genel tecrübeye dayanarak ve yapılacak sorgu miktarı göz önünde bulundurularak bir seviyeye kadar normalization yapılıyor. Ama mümkün olan heryerde de yapılmıyor çünkü zamanla normalization, anormalization’a dönüşüyor:)

    Söz konusu olan veri miktarı fazla olunca da bir field’ın yerinin değiştirilmesi dahi sistem performansını gözle görülebilir şekilde değiştirebiliyor. Sorgu işleri hızlandırılmak istendiğinde insert, update, delete gibi “data manipulation” işlemleri yavaşlıyor, bunlar hızlandırıldığında ise sorgu işlemleri yavaşlıyor.

    Bahsettiğin gibi sırf bu yüzden data warehouse sistemleri aracılığıyla raporlama ünitesi ile veri işleme (data manipulation) ünitesi birbirinden ayrılıyor. Geçenlerde katıldığım bir Sybase seminerinde IQ adlı data warehouse sistemi tanıtıldı. Temel mantık var olan verilerin bir kopyasını alıp onları içinde daha hızlı aranabilir hale getirmek. Bu arada tabi asıl tablo yapılarını koruduklarını sanmıyorum. Mutlaka bir miktar de-normalization yapılıyordur ama bu konuda detaylı bilgi öğrenemedim:) Ayrıca IQ’yu benzer sistemlerden ayıran çok temel bir özelliği daha varmış. Veriler row-based değil column-based tutuluyormuş. Böylece sorgu yapılırken sorguda ihtiyaç duyulmayan sütunlar hiç işin içine karışmadan JOIN’lerden arındırılıyor, bu da raporlama işlemlerinin (veri büyüklüğüne bağlı olarak) yüzlerce kat daha hızlanmasını sağlayabiliyor (günlerce süren bir rapor üretilmesi işleminin 1 saatten kısa sürede oluşturulabilmesi gibi).

    Sybase, veriyi colum-based tutma ile ilgili patentleri elinde bulundurduğu için şu an pek bir rekabet ortamı yok piyasada. Ancak duyduğuma göre Oracle ve bir iki şirket daha şu an column-based veri tutulması üzerine çalışmalar yapmaya başladıklarını duyurmuş.

    Demek istediğim o ki, verinin nasıl işleneceği ve nasıl raporlanacağı konusundaki teknoloji ilerledikçe normalization ve de-normalization işlemlerinin sınırları da biraz netlik kazanacaktır. O yüzden şimdilik sadece sağ duyumuz ile hareket etmemiz yeterli gibi görünüyor:) Allah DBA’lerin yardımcısı olsun:)

    Görüşmek üzere..

  2. Mart 28, 2007, 12:51 pm

    AMİNNN diyerek başlayayım 🙂 DBA olmak gerçekten zor iş hele de developer ekibi işten çakmıyorsa , canınızdan çok sevdiğiniz databaseiniz bir anda felç olabiliyor.

    Verilerin raporlama için ayrı bir alana alınması durumu artık çoğu şirkette önümüze çıkıyor. Production ortamındaki bir veritabanından joinler ile veri çekmek ölümcül sonuçlar doğurabilir. O nedenle belirli aralıklarla veriler veri amabarlarına aktarılıp ileriki zamanlarda kullanılmak üzere saklanıyorlar. Düşünsene bir müşteri kaydı yaptı bir şirket sence bu adamın bilgisi ne sıklıkla güncellenir?? Genelde müşteri bilgisi sorgulama amaçlı saklanır ve bu gibi durumlarda normalizasyonu abartmak sıkıntı doğurabilir

    Daima sorgulama ve güncelleme arasında bir seçim yapmak daha doğrusu bir denge kurmak durumundayız. Hatta bu denge db dosyalarındaki FILL FACTOR değerini ayarlarken de göz önünde bulundurulmalıdır.

    Sybase ürününü de hemen icnledim. Mutalaka Oracle buna bir cevap vercektir olmadı parayı bastırıp alır çünkü artık deli gibi yazılım almaya başladılar.

    İlgin ve değerli bilgilerin için teşekkür ediyorum.
    Görüşmek dileğiyle..

  3. Mart 28, 2007, 3:53 pm

    Muhtemelen Sybase kendini satar ama IQ’yu satmaz:) Çünkü IQ, Sybase’i nirvanaya ulaştıracak proje gibi görünüyor. Birkaç senedir bu işin içindeler, dünyada pek çok müşterileri var. Türkiye’de de 15-20 civarı müşteri ile en büyük pazar payına sahiplermiş:) (Türkiye’de data warehouse olayı yeni yeni duyuluyor ama gelecekten ümitliler:) )

    3 sene kadar önce (tam hatırlamıyorum yalan olmasın) “business intelligence projects” yada benzeri bir alanda dünya birinciliği ve ikinciliğini Sybase IQ sayesinde aldı. O sene dünya birincisi olan, yani bir anlamda “business intelligence” oscar ödülünü alan proje Yapı Kredi’nin data warehouse sisteminin Sybase IQ’ya geçirilmesiymiş. Dünya ikincisi olan proje de Amerika’da medya sektöründe raporlamalar vs. yapan çok ünlü bir şirkete (o kadar ünlü ki adını hatırlayamadım:) ) Sybase IQ’nun kurulması projesi olmuş.

    Kısacası amcalar data warehouse konusunda rakip tanımıyorlar (en azından şimdilik:)). O yüzden IQ’yu satmazlar gibi geliyor bana. Ama şüphesiz, Oracle piyasaya basit bir sistemle çıkmayacaktır. İyi bir hamle ile Sybase’i de IQ’yu da alaşağı edebilir:)

    Bakalım yakında data warehouse piyasasında heyecanlı bir çatışma çıkacak gibi:) Patlamış mısırları alıp zevkle izleyebiliriz. (Tabii “neden izleyelim, biz de işin içine girelim” diyosan onu da ayrı bir başlık altında tartışabiliriz:) )

  4. Mart 28, 2007, 5:16 pm

    Yapı Kredi deyince aklıma JDBC_TR grubundan Dr Kemal Ünaltuna Bey geldi kendisi yapı kredide datawarehousing yapısını kuran isim diye biliyorum. itellica diye de bir şirketi var. Zaten bu özelliklerinden ötürü kendisini hemen gruba çağırmuıştım.
    Sybase daha çok bankacılık sektöründe tercih edilen bir DBMS. Mesela takas bank da sybase kullanıyor. IQ ile iyi bir silah elde etmişler ama pazar olarak kendilerine ne gibi bir getiri olur tartışılır. Eğer bu ürün SYBASE DBMS üzerinde çalışıyorsa kimse IQ için DBMS değiştirmez ama farklı DBMSleri de destekleyn bir çözümse iyi para kandırabilir.

    Onlar yapıyor biz izliyoruz. Allah sonumuzu hayır etsin.

  5. Mart 29, 2007, 12:18 pm

    Olayın güzelliği orada zaten. DBMS ile Data warehouse’u tamamen birbirinden ayırmışlar. Oracle, MSSQL, Sybase, MySQL hiç farketmiyor, hepsi üzerinde kullanılabiliyor.

    Tam bilmiyorum ama Oracle’ın data warehouse’u sadece Oracle üzerinde çalışıyordu diye bir izlenimim var. Emin de değilim günahlarını almayayım:)

  6. Mart 29, 2007, 5:08 pm

    DBMS ile Datawarehouse’ un birinden ayrılması gerçekten akıllıca olmuş. Yoksa kimse IQ için DBMS değiştirmez çünkü şirketler neredeyse imkansız bir durum DBMS değişitrmek. DBMS’den bağımsız olarak her türlü DBMS ile çalışabilecek uygulama neredeyse yok. Hatta artık database developer dediğimiz ,database spesific dilleri iyi kullanan kişilere olan talep gitgide artıyor.

    Bakalım IQ nerelere gelecek göreceğiz. Belki kısa bir süre sonra JDBC_TR grubunda bu konuyu konuşabiliriz. Başka bilen dduyan var mı merak ettim açıkcası

  1. No trackbacks yet.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s

%d blogcu bunu beğendi: