• ilişkisel veritabanlarında 'yerden' kazanma olayı. 'zaman'dan kazanmak için biraz denormalize olmak lazım. (bkz: storage complexity) (bkz: running complexity)
  • (bkz: normalize)
  • pek güzel, pek leziz, dbms'lerden keyif alma metodu.
    çeşit çeşittir bu. temelinde aynı verinin tekrarlanmamasını ve scalable bir yapı oluşturmayı hedefler.
    örneklerle gidelim isterim hemen:
    şöyle bir kullanıcılar tablosu olsun elimizde:

    kullanıcılar:
    userid | isim | telefon1 | telefon2 | şehir |
    1 mengus 1234567 7654321 istanbul
    2 barbie 3579512 berlin
    3 ahmet 4316528 7962452 istanbul

    şimdi efendim böyle bir tabloyu kim ister? ben istemem şahsen. neden? misal üçüncü bir telefon numarası olan bir yuzır gelebilir, ya da bakınız barbie'nin tek bir telefon numarası var, neden bir field'ımız boş kalsın? değil mi ama? hem bakınız bir çok istanbul'da yaşayan yuzırımız olabilir, her seferinde istanbul, istanbul diyerek 8 bayt heba mı edeceğiz? olmaz. çok hatalı. hemen ne yapıyoruz? database'imizi birinci normal form ya da first normal form olarak bilinen forma getiriyoruz. hemen görelim neler yapacağımızı:
    önce her tablodaki tekrarlanan öğeleri ayıracağız yapalım hemen:

    önce ayıralım:
    userid | isim | telefon | şehir |
    1 mengus 1234567 istanbul
    1 mengus 7654321 istanbul
    2 barbie 3579512 berlin
    3 ahmet 4316528 istanbul
    3 ahmet 7962452 istanbul
    bakınız ne yaptık? aynı kategoriye giren (telefon) veriler için farklı kolonlar yaratmaktansa, bunları row'lara yaydık. niye böyle yaptık? misal şimdi barbie bey 'yeni telefonum var' dese hemen kendisine yeni bir row ekleyeceğiz, böylece bir miktar scalability elde etmiş olduk.
    şimdi birinci normal form'un kurallarını uygulamış oluyoruz efendim. ve fakat bakınız esasen ne kadar dallama bir konumdayız, her yeni telefon eklemek istediğimizde, bütün datayı tekrar girmek durumunda kalıyoruz. o vakit, ne oluyor? ikinci normal form'a bakmak durumunda kalıyoruz:
    şimdi bağlantılı veriler için ayrı tablolar oluşturacağız, sonra da bu tablolardaki bağlantılı verilerimizi primary keyler ile identify edeceğiz.

    kullanıcılar tablomuzu şu şekle sokuyoruz:
    userid | isim | şehir |
    1 mengus istanbul
    2 barbie berlin
    3 ahmet istanbul

    bakınız telefon numaraları gitti. nereye gitti? hemen bakıyoruz, 'telefonlar' isimli yeni tablomuza:

    telefonlar:
    telefonid | userid | telefonno |
    1 1 1234567
    2 1 7654321
    3 2 3579512
    4 3 4316528
    5 3 7962452

    burada kullanıcılar tablosundaki userid kolonunu primary key, telefonlar tablosundaki userid kolonunu da foreign key yaparak güzelinden relation'umuzu kuruyoruz, constraint'imizi yerleştiriyoruz.
    efendim şimdi elimizdeki sorunlar bitti mi? biter mi? ömür biter sorun bitmez elbette ki, dolayısıyla bakıyoruz kullanıcılar tablomuza. misal bu tablomuza izmirli erkekler'den 100 tanesi gelse, ya da istanbul'dan 50 kullanıcı daha eklense ne olacak? istanbul istanbul diye yaza yaza ömür bitmeyecek mi? bitecek, demek ki daha kolay bir yolunu bulmak lazım. dolayısıyla burada üçüncü normal formumuz ortaya çıkıyor. şöyle ki:

    key'imizle bir bağlantısı olmayan field'ları ayrıştıracağız. ki burada 'şehir' kolonu, gayet de key'den bağımsız bir kolon olarak örnek teşkil ediyor bize. öyleyse tablolarımız ne hale geliyor?

    kullanıcılar:
    userid | isim | şehirid |
    1 mengus 1
    2 barbie 2
    3 ahmet 1

    sehirler:
    sehirid | sehiradi |
    1 istanbul
    2 berlin

    telefonlar:
    telefonid | userid | telefonno |
    1 1 1234567
    2 1 7654321
    3 2 3579512
    4 3 4316528
    5 3 7962452

    elimizdeki relationlar da şu şekilde oldu:

    kullanıcılar.userid (primary)- telefonlar.userid (foreign)
    şehirler.şehirid (primary) - kullanıcılar.şehirid (foreign)

    normalization buraya kadar geldikten sonra, kendinizi şahane hissetmeye başlayabilirsiniz elbette ve fakat bunun dördüncü ve beşinci normal formları da var. ilk üç normal form 1972'de codd denen bir amcamın "further normalisation of data base relational model" diye bir yayınında ortaya atılmış. diğer ikisi ise ilerleyen yıllarda birtakım kendinibilmez teorisyenlerce üretilmiş. öyleyse bakalım bu öbür ikisine de:

    dördüncü normal formumuz diyor ki, bir many to many relationship'te, bağımsız alanlar aynı tabloda bulunamaz. yani, şöyle bir tablo olmaz, olamaz:

    user | uyelik | sevdigi_sarkilar |
    mengus sozluk daha dün annemizin
    mengus soursummitz aman ormancı
    rotten disguast aman bre deryalar

    şimdi bu tablodaki hiç bir veri, bir diğeriyle aynı tabloda bulunmak durumunda değil. öyleyse ne yapıyoruz?
    user'ları zaten kullanıcı tablosunda define etmişiz. orada bir primary key'imiz de var userid kolonunda. o zaman hemen

    uyelikler:
    uyelikid | uyelikadi
    1 sozluk
    2 soursummitz
    3 disguast
    (uyelikid primary key)

    sarkilar:
    sarkiid | sarkiadi
    1 daha dün annemizin
    2 aman ormancı
    3 aman bre deryalar
    (sarkiid primary key)

    relation_sarki_user
    relationid | sarkiid | userid
    1 1 1
    2 2 1
    (sarkiid foreign key)

    relation_uyelik_user
    relationid | uyelikid | userid
    1 1 1
    2 2 1
    (uyelikid foreign key)

    şeklinde bir sürü tablo elde ediyoruz buradan. niçin? her şey normalization için, mutlu yarınlar için.
    buradan sonra da geliyoruz, daha ilginç bir şeye, beşinci normal form:

    burada, her field'ı birbirine bağlı ve fakat yine de tekrar eden birtakım veriler barındıran tablolardan kurtulmak icap ediyor. misal şöyle olabilir:

    user | sevdigi_mekan | mekanda_sevdigi_insan |
    mengus pano hede
    mengus arka bahçe hippi
    rotten barbaros çay bahçesi kappi
    rotten pano toppi

    şimdi bunu nasıl ayıracağız?
    sadece user-mekan, user-semt gibi ayıramayız demek ki şöyle yapıyoruz:

    mekanlar:
    mekanid | mekanadı |
    1 pano
    2 arka bahçe
    3 gizli bahçe

    insanlar:
    insanid | adı |
    1 hede
    2 hippi
    3 topppi

    relation_insan_mekan
    relationid | insanid | mekanid |
    1 1 1
    2 2 2
    3 3 1

    relation_user_mekan
    relationid | userid | mekanid
    1 1 1
    2 1 2
    3 2 1

    relation_user_insan
    relationid | userid |insanid
    1 1 1
    2 1 2
    3 2 3

    bu şekilde üç farklı relation define ederek beşinci normal forma ve aynı zamanda nirvanaya varmış oluyoruz.

    elbette her zaman için en ucuna kadar normalize etmek doğru olmayabilir, kullanılan joinlerin sayısı ne kadar fazla ise o kadar ağırlaşacaktır işlem. relation'lardan kazanılan scan zamanını joinlerle kaybetmek vardır işin ucunda. dolayısıyla önceden denemek, görmek, sık kullanılacak query'leri belirlemek, gerekirse bazı yerleri denormalize etmek, rdbms'inizden mümkün mertebe köküne kadar faydalanmak gereklidir.

    bir yerlerde gudik hatalar yapmış olabilirim saatin sabahın sekizi olmasının bunda etkisi olacaktır elbet.
  • (bkz: nötralizasyon)
  • bir vektoru, uzunlugunu bire donusturecek sekilde sabit bir sayiyla carpma faliyeti.
    (veya bir fonksiyonu, integrali bir ciksin diye sabit bir sayiyla carpma faliyeti)
  • database de tablolardaki veri tekrarini azaltmak icin ve silme guncelleme eklemede cıkan zorluklari en aza indirmek icin yapilan operasyonlar toplamidir amac database etkinlik kazandirmaktir. birinci normal form (1 nf) ikinci normal form (2. nf) ucuncu normal form (3. nf), bcnf (boyce codd normal form) 4. nf, 5. nf operasyonun kademeleridir. genelde database bcnf düzeyinde istenir.
  • makulleştirmedir.
  • temel amacı veritabanındaki güncelleme bozukluklarını engellemek olan veritabanı dizayn konusu.
  • hakkındaki detaylı bilgiye asagıdaki adresten ulasilabilecek hodo.

    http://databases.about.com/…cts/a/normalization.htm

    ayrica (bkz: 1nf) (bkz: 2nf) (bkz: 3nf)
  • http://www.sqlservercentral.com/…ramlization/64428/

    adresinde de bişiler var.
hesabın var mı? giriş yap