Veritabanı Sistemleri, Tasarım, Uygulama ve Yönetim

Ana Sayfa| İçindekiler | Testler| Hakkında| Yardım

4.BÖLÜM

Veritabanı Tablolarının Normalizasyonu

Ön Bakış

İyi veritabanı tasarımı iyi tablo yapılarına eşleştirilmeli. Bu bölümde veri fazlalıklarını kontrol etmek(bu suretle veri anormalliklerinden kaçınıyoruz) için iyi tablo yapıları tasarlamayı öğreneceğiz. Böyle istenen sonucu üreten sonuçları üreten işlem, normalizasyon(normalization= normalleştirme) diye bilinir.

İyi bir tablo yapısının karakteristiklerini tanımak ve anlamak için kötü bir tabloyu incelemek yararlıdır. Bu yüzden kütü bir tablo yapısının karakteristiklerini ve onun oluşturduğu problemleri inceleyerek başlayacağız. Daha sonra kötü bir tablo yapısının nasıl tespit edilebileceğini göstereceğiz. Bu metodla iyi bir tablo yapısı tasarlamayı ve varolan kötü olan bir tablo yapısını onarmayı bileceksiniz.

Normalleştirme vasıtasıyla veri anormalliklerini(data anomalies) yok etmekten başka, uygun şekilde normalleştirilmiş tablo yapısı kümelerinin, normalleştirilmemiş kümelerden gerçekten daha az karmaşık olduğunu keşfedeceksiniz. Ek olarak normalleştirilmiş tablo yapısı kümelerinin bir organizasyonun gerçek işlemlerini daha sadakatle yansıttığını göreceksiniz.

VERİTABANI TABLOLARI VE NORMALİZASYON

İyi ilişkisel veritabanı yazılımı 1. bölümde tartıştığımız veri fazlalıklarının tuzaklarından kaçınmak için yeterli değildir. Eğer veritabanı tablolarına dosya sistemlerindeki dosyalar gibi muamele edilirse, RDBMS(İVTYS=İlişkisel Veritabanı Yönetim Sistemi) hiç bir zaman olağanüstü veri kullanma yeteneklerini gösterme şansına sahip olamaz.

Veritabanı tasarım sürecinde tablo temel yapı bloğudur. Dolayısıyla tablonun yapısı bizi ilgilendirir.İdeal olarak 3.bölümde keşfettiğimiz veritabanı tasarım işlemi iyi tablo yapıları üretir. İyi veritabanı tasarımında bile kötü tablo yapıları oluşturmak mümkündür. Kötü tablo yapılarını tanımak ve iyi tablo yapıları üretmek normalizasyon(normalization=normelleştirme) işlemine dayanır. Normalizasyon varlıklara tahsis edilen özellikler(nitelikler) için bir işlemdir. Normalleştirme(normalizasyon) veri fazlalıklarını azaltır ve bu veri fazlalıklarının sonucu olan veri anormalliklerinin yok edilmesine yardım eder. Normalleştirme veri fazlalıklarını yok etmez. Bunun yerine fazlalıkları kontrol ederek tabloları bağlamamıza izin verir.

Normalleştirme normal formlar(normal forms) olarak isimlendirilen bir dizi aşama vasıtasıyla işler. İlk üç aşama birinci normal form(first normal form(1NF),ikinci normal form (second normal form(2NF)) ve üçüncü normal form(third normal form(3NF)) olarak tanımlanır. Yapısal bakımdan 2NF 1NF den , 3NF de 2NF den daha iyidir. Birçok iş veritabanı için ihtiyaç duyacağımız normalleştirme işlemi 3NF dir. Bununla birlikte bazı çok özelleştirilmiş uygulamalar daha yüksek düzeyde normalleştirme gerektirebilir.

Normalleştirme çok önemli bir veritabanı tasarım malzemesi olmasına rağmen, en yüksek seviyede normalleştirme daima istenmeyebilir. Daha yüksek normal form ,belirli bir çıkış üretmek için daha fazla işaretçi(pointer) hareketi gerektirir ve son kullanıcı isteklerine daha yavaş veritabanı cevapları oluşturur. Başarılı tasarım aynı zamanda hızlı performans için son kullanıcı isteklerinide hesaba katmalı. Bu yüzden arasıra veritabanı tasarımının bazı parçalarının denormalize edilmesi beklenilecektir.(Denormalization daha düşük bir normal form üretir. Yani denormalizasyon vasıtasıyla üçün normal form ikinci normal forma çevrilecektir.) Bununla birlikte denormalizasyonla ödenen fiyat daha büyük veri fazlalıkları miktarıdır.

Normalizasyon Gereksinimi

Normalizasyon işlemlerini sırayla göstermek için basit bir iş uygulamasını inceleyeceğiz. Bu durumda bir inşaat şirketinin basitleştirilmiş bir veritabanı faaliyetlerini keşfedeceğiz. Bu veritabanı birkaç inşaat projesini yönetir. Her proje kendi proje numarası,ismi,projeye tahsis edilen işçiler vs. ye sahiptir. Her işçi bir işçi numarasına, isme, mühendis ve bilgisayar teknisyeni vs gibi iş sınıfına vs' ye sahiptir.

Tablo 4.1 Örnek bir rapor planı

Tablo 4.2 Raporlama formatına uyan bir tablonun formatı

Şirket her anlaşmada harcanan saatlerin faturalarını hesaplayarak müşterilerinin hesabına geçirir. Saat başına ücret faturası çıkarmak işçinin durumuna bağlıdır.(Örneğin bir bilgisayar teknisyenin zamanının bir saatlik değeri, bir mühendisin vaktinin bir saatlik değerinden farklı değerdedir.)Tablo 4.1 de gösterilen bilgiyi içeren bir rapor belirli aralıklarla üretilir.

İhtiyaç duyulan raporu üretmek için en kısa vadeli yol, içeriği raporlama ihtiyaçlarına uyan bir tablo olarak görülebilir.(Tablo 4.2 ye bak). Toplam masraf(total charge), faturası çıkarılan saatler(hours billed) ve saat başı masrafın çarpımı olduğu için toplam masraf tablo 4.2 de eksiktir. Ne yazık ki tablo 4.2 deki yapı ikinci bölümde tartıştığımız ihtiyaçlara dönüştürülmez, ve de veri iyi tutulmaz:

1. Proje numarası(P_NO) nın görünüşe bakılırsa bir birincil anahtar olması veya en azından birincil anahtarın bir parçasıl olması düşünülür. Fakat P_NO null değerler içerir.
2. Tablo aşağıda ayrıntılı olarak tartışacağımız veri fazlalıklarını sergiler.
3. Tablo girişleri veri çelişkilerine yol açar. Örneğin Electrical Engineer sınıflandırması "Elect.Eng" ," El.Eng" ve "EE" ve daha başka şekillerde girilebilir.
4. Veri fazlalıkları aşağıdaki anormallikleri meydana getirir:
   1. Güncelleştirme anormallikleri(update anomalies):Employee number(E_NO) 101 için JOB_CLASS ı değiştirmek potansiyel olarak E_NO=101 lerin herbiri için birçok değişiklikler gerektirir.
   2. Ekleme Anormallikleri(Addition anomalies):Bir satır tanımlandıktan hemen sonra, yeni bir çalışan projeye atanmalı. Eğer bir çalışan(işçi) henüz projeye atanmamışsa, çalışan veri girişini tamamlamak için hayalet bir proje oluşturulmuş olacak.
   3. Silme Anormallikleri(Deletion anomalies):Eğer çalışan 101 ayrılırsa, her E_NO=101 için silme yapılmalı. Böyle silmeler yapılırker diğer hayati veride kaybedilir.

Tablo yapıları çalışmak için görünür.Rapor kolaylıkla üretilir. Fakat varsayalım ki başka bir işçi COAST projesine atanır ve aşağıdaki giriş kullanılarak veri giriş sekreteri klasörü günceller.

Coast 104 Anne Ramoras Comm.Tech. 60 19

Bazı tekrarlanan bilgilerde her defasında bir projeye başka bir çalışan atanır. İki veya üçyüz giriş yapılmak zorunda olduğunda veri girişinin zor ve tatsız bir iş olur. Anne Ramoras'ı ,onun iş tanımlamasını ve onun saat başı hesabını tanımlamak için çalışan numararası girişi yeterli olmalı. 104 numara ile tanımlanan bir kişi olduğu için, bu kişinin karakteristikleri (adı, iş sınıflandırması vs) her defada ana tabloda güncelleştirilmek zorunda olmamalı. Ne yazık ki tablo 4.2 de gösterilen yapı böyle bir imkanı hesaba katmaz. Tekrarlanan gereksiz bilginin depolanması veri fazlalığı(data redundancy) olarak isimlendirilir.

Fazlalık gereksiz disk alanı israfına yol açar. Daha kötüsü veri fazlalığı veri anormallikleri üretir. Başka bir veri girişinin yapıldığını varsayalım. Bu defa veri girişi sekreteri aşağıdaki satırı daktilo etsin.

0001 Huricane 105 Steve Malthus Comp.Tech. 60 6

Girişin uygun olduğu görünür. Fakat Huricane projesi Hurricane projesi ile aynı mı? Ve Comp. Tech gerçekten Comm.Tech. olarak varsayılır mı? Bir insan yeteneği böyle mantıksal atlamaları yapıyor, ama bilgisayarlar yapmıyor. Bunun yerine bilgisayarlar Hurricane ve Huricane varlıklarına ayrı varlıklar olarak bakarlar. Böyle bir karışıklık veri bütünlüğü(data integrity) problemidir. Bu problem fazla verilerin bütün kopyalarının aynı olması kuralına, veri girişi sırasında uyamama başarısızlığından meydana gelir.

Bir veritabanı tasarlandığı zaman, veri fazlalığı tarafından sebep olduğu ileri sürülen veri bütünlüğü problemleri göz önüne alınmalı. Bu problemlerin üstesinden gelmeye yardım etmek için ilişkisel veritabanı ortamı özellikle iyidir.

Birinci Normal Forma Değiştirme

İlişkisel model veriyi bir tablonun veya tablo topluluğunun bir parçası olarak gördüğü için, bu tablo ya da tablolarda bütün anahtar değerleri tanımlanmalı. Tablo 4.2 deki veri gösterildiği gibi depolanamaz. Tablo 4.2 nin tekrarlanan gruplar içerdiğine dikkat et. Çünkü proje numarası(project number) birkaç veri girişinden oluşan bir gruba sahiptir.

 
     P_NO     P_NAME      E_NO    E_NAME         JOB_CLASS    CHG_HOUR   HOURS

 
      1       Hurricane   101     John News      Elect.Eng.     65         13
                          102     David Senior   Comm.Tech.     60         16
                          103     Anne Ramoras   Comm.Tech      60         19  

İlişkisel bir tablo tekrarlanan gruplar içermemeli. Eğer tekrarlanan gruplar varsa, her satırın bir tek varlığı tanımladığından emin olunarak bu gruplar tespit edilmeli. İşlem yeterince basittir. En azından grubun birincil anahtar sütununa uygun girişi eklemek. Diğer bir değişle tablo 4.2 deki gösterim tablo 4.3 de gösterildiği gibi değiştirilmeli. Bu değişiklik tekrarlanan grupları yok ederek birinci normal formda(firs normal form=1NF) bir tablo oluşturur.

Şekil 4.3 de gösterilen düzen katkısız bir kozmetik değişikliğinden daha fazlasını temsil eder. Dikkatsiz bir gözlemci bile dikkat edecek ki P_NO yeterli bir(birincil) anahtar değildir. Çünkü proje numarası öbür bütün varlık(satır) özelliklerini tek(unique) olarak tanımlayamaz. Örneğin P_NO'nun 1 değeri üç çalışanın herhangi biri için tanımlanabilir. Uygun bir birincil anahtarı devam ettirmek için herhangi bir özelliği tanımlayacağız. Bu yeni anahtar P_NO ve E_NO nun bileşiminden oluşmalı.(Gerekirse çeşitli anahtarların tanımı ve bağımlılık için 2. bölümü yeniden inceleyin).

Tablo 4.3 Veri Organizasyonu:Birinci Normal Form

Şekil 4.1 Bir bağımlılık(dependency) diyagramı

Bağımlılıklar şekil 4.1 de gösterilen bağımlılık diyagramı(dependency diagram) yardımıyla teşhis edilmeli. Birincil anahtar bileşenlerinin altı çizilir. Bağımlılık diyagramını incelerken aşağıdaki özelliklere dikkat edin:

1. Varlık özelliklerine yukarı doğru işaret eden oklar P_NO ve E_NO 'nun bileşimine bağlıdır. Diğer bir değişle herhangi bir varlık için P_NO ve E_NO yu biliyorsanız, kalan bütün satırları teşhis edebilirsiniz. Örneğin tablo 4.3 de gösterilen veriyi kullanarak eğer P_NO=1 ve E_NO=102 olduğunu biliyorsanız sırasıyla P_NAME,E_NAME,JOB_CLASS,CHG_HOUR ve HOURS Hurricane,David Senior,Comm.Tech.,60, ve 16 olmalıdır.
2. Bağımlılık diyagramında aşağı doğru olan oklar birincil anahtarın sadece bir parçasına dayanan daha az istenen bağımlılıkları gösterir.

Örneğin P_NAME yi belirlemek için sadece P_NO yu bilmeye ihtiyacınız olur. Yani P_NAME birincil anahtarın sadece bir parçasına bağlıdır.Ve E_NAME, JOB_CLASS ve CHG_HOUR bulmak için sadece E_NO yu bilmeye ihtiyacınız olur.(Sadece birincil anahtarın bir bir parçasına dayanan bağımlılıklar kısmi bağımlılıklar(partial dependencies) olarak isimlendirilir.)

Diğer bir deyişle şekil 4.1 deki bağımlılıklar aşağıdaki gibi yazılabilir:

P_NO,E_NO--->P_NAME,E_NAME,JOB_CLASS,CHG_HOUR,HOURS
P_NO--->P_NAME
E_NO--->E_NAME,JOB_CLASS,CHG_HOUR   

Üçüncü bölümden tablo yapılarının aşağıdaki formatta gösterilebileceğini hatırlayın:

TABLE NAME(PRIMAR KEY COMPONENT(S),DEPENDENT ATTRIBUTES)

Örneğin önceki tablo CHARGES olarak isimlendirilirse aşağıdaki yapı ile temsil edilir:

CHARGES(P-NO,E-NO,P_NAME,E_NAME,JOB_CLASS,CHG_HOURS,HOURS)

CHARGE tablosunun P_NO ve E_NO özelliklerinden oluşan bir birincil anahtar içerdiğine dikkat edin. Herhangi bir özellik bir anahtarın parçasıysa, bu özellik esas özellik(prime attribute) veya anahtar özellik(key attribute) olarak tanınır. Diğer taraftan esas olmayan (nonprime attribute) ve anahtar olmayan özellik(nonkey attribute) bir anahtarın parçası değildir.

1NF'i Tanımlama Birinci normal form(first normal form) içinde aşağıdaki maddeleri bulunduran tablo formatını tanımlar. Bütün anahtar özellikler tanımlanır. Tabloda tekrarlanan grup yoktur. Diğer bir deyişle her satır/sütun kesişimi değerlerin bir kümesinden ziyade bir ve sadece bir değer içerebilir. Bütün özellikleri birincil anahtara bağlıdır.

Bütün ilişkisel tablolar 1NF gereksinimlerini karşılar. Şekil 4.1 de gösterilen 1NF tablo yapısı ile birlikte problem,tablonun kısmı bağımlılıklar içermesidir. Yani bağımlılıklar birincil anahtarın sadece bir parçasına dayanır.

Kısmi bağımlılıklara müsaade edilmez. Çünkü böyle bağımlılıklar içeren bir tablo hala veri fazlalıklarına bağlıdır. Ve bu yüzden güncelleştirme anormallikleri olur. Veri fazlalıklarına, her satırın tekrarlanan veri gerektirmesi sebep olur. Örneğin eğer kullanıcı E_NO=105 durumu için gün boyunca 20 defa tablo girişi yaparsa, E_NAME,JOB_CLASS ve CHG_HOUR her defasında girilmeli, bu girişler E_NO=105 için aynı olmasına rağmen. Böyle tekrarlar çok verimsizdir. Daha kötüsü tekrarlamalar veri anormalliklerini oluşturur. Hiçbir şey kullanıcının girişleri yaparken az da olsa çalışan adı,durumu, saat başı ödemesi hakkından farklı girişleri yapmasını engelleyemez.Örneğin E_NO=105 için çalışan(employee) adı Dave Senior veya D.Senior olarak girilebilir. Benzer şekilde proje adı doğru olarak Hurricane veya yanlış olarak Huricane olarak girilebilir. Böyle veri anormallikleri ilişkisel veritabanı bütünlüğü ve tutarlılık kurallarını bozar.

İkinci Normal Forma Değiştirme

İlişkisel veritabanı tasarımı ikinci normal forma dönüştürülerek kolayca geliştirilebilir. 1NF i 2NF dönüştürme basittir. Şekil 4.1 de gösterilen 1NF formatıyla başlayarak,

1. Anahtar bileşenlerinin herbirinin ayrı satırlarda yaz, ve son satıra da orjinal anahtarı yaz:

        P_NO
        E_NO
        P_NO    E_NO 

   Bu bileşenlerin herbiri yeni bir tabloda anahtar olacak. Diğer bir değişle orjinal tablo üç farklı tabloya ayrılmaktadır.

2. Yeni anahtarlardan herbirinden sonra bağlı özellikleri yaz.(Başka özelleklere bağlı olan özellikleri belirlemek için şekil 4.1 i kullan). Orjinal anahtar bileşenleri için bağımlılıklar şekil 4.1 deki bağımlılık diyagramında aşağı doğru olan oklar incelenerek bulunur. Diğer bi deyişle üç yeni tablo, PROJECT, EMPLOYEE, ve ASSIGN isminde olup sırasıyla aşağıdaki gibi tanımlanır.

         PROJECT(P-NO,P_NAME)
         EMPLOYEE(E-NO,E_NAME,JOB_CLASS,CHG_HOUR)
         ASSIGN(P-NO,E-NO,HOURS)    

HOURS özelliği P_NO ve E_NO ya bağlı olduğu için HOURS'u ASSIGN tablosuna yerleştiririz.

Bu operasyonun sonuçları şekil 4.2 görülür. Şekil 4.2 yi incelerken CHG_HOUR'un JOB_CLASS'a bağlı olduğuna dikkat edin. Ne CHG_HOUR ne de JOB_CLASS esas özellik(prime attribute) olduğu için,yani ikiside anahtarın parçası değil, geçişli bağımlılık(transitive dependency) olarak tanımlanan bir duruma sahip oluruz. Ve geçişli bağımlılık hala veri anormallikleri meydana getirir.

Eğer bir tablonun birincil anahtarı birkaç özellikten oluşuyorsa, sadece kısmı bağımlılıklar var olabileceği için , birincil anahtarı tek bir özellikten oluşan bir tablo eğer 1NF de ise otomatik olarak 2NF de olmalıdır.

Şekil 4.2 İkinci normal forma değiştirmenin sonuçları

Üçüncü Normal Forma Değiştirme

Şekil 4.2 gösterilen veritabanı organizasyonu tarafından oluşturulan veri anormallikleri parçaların ilişiği kesilerek kolayca yok edilir. Bu parçalar bağımlılık diyagramında aşağı doğru geçişli bağımlılık okları tarafından tanımlanır ve ayrı tablolarda depolanıyor. Bununla birlikte JOB_CLASS anahtarın parçası değildir ve JOB_CLASS orjinal 2NF tabloda tutulmalı, orjinal tablo ve yeni oluşturulan tablo arasında bağ kurmak için. Diğer bir değişle değiştirmeyi yaptığımızda veritabanımız 4 tablo içerir:

     PROJECT(P-NO,P_NAME)
     ASSIGN(P-NO,E-NO,HOURS)
     EMPLOYEE(E-NO,E_NAME,JOB_CLASS)
     JOB(JOB-CLASS,CHG_HOUR)           

Değiştirmenin orjinal EMPLOYEE tablosundaki geçişli bağımlılığı yok ettiğine dikkat edin. Tabloların şimdi üçüncü normal formda oluduğu söylenir(3NF).

Şekil 4.3 Tamamlanmış veritabanı

Dört tablo da 3NF de olmasına rağmen, muhtemel bir probleme sahibiz. Çalışanların(employee) sayısı büyürken, EMPLOYEE tablosuna yeni bir çalışan(employe) girilirken her defasında JOB_CLASS girilir. Maalesef veri girişi buyunca Comm.Tech. den ziyade Comp.Tech.'i kazara girmek çok kolaydır. Bu problemi EMPLOYEE tablosunda yabancı anahtar olarak ve JOB tablosunda birincil anahtar olarak hizmet edecek bir JOB_CODE özelliği oluşturarak mümkün olduğu kadar azaltabiliriz. Şekil 4.3 de gösterilen sonuçlar,sırasıyla PROJECT,EMPLOYEE,ASSIGN ve JOB olarak adlandırılan dört tablodur.

Teknik olarak şekil 4.3 deki JOB tablosu geçişli bir duruma sahiptir. Çünkü

JOB_CLASS---->CHG_HOUR

Bununla birlikte muhtemel EMPLOYEE veri-giriş hatası probleminin yok edilmesi bu küçük geçişli bağımlılığı faydalı yapar.(Karşılaştırmada şekil 4.2 deki orjinal geçişli bağımlılıktaki

JOB_CLASS---->CHG_HOUR

Bundan dolayı değiştirmeden sonra, şekil 4.3 de gösterilen veritabanı 3NF'de üç ve 2NF' de de bir tablo içerir. Şekil 4.3 orjinal veritabanı üzerinde geniş bir ilerlermeyi temsil eder. Bu veritabanının veri anormallikleri meydana getirmediğine dikkat et. Her JOB_CODE tek JOB_CLASS ve CHG_HOUR girişine sahip olduğu için ,aynı nesne veya konuyu tanımlayan farklı değerler kullanmak için elverişli durum yok. Benzer şekilde EMPLOYEE özelliklerinin herbiri için sadece bir giriş yapılır. Veri fazlalığıda en aza indirilir. En aktif tablo sadece P_NO,E_NO ve HOURS'un girilmesini gerektirir.(ASSIGN en aktif tablodur,çünkü çalışanlar tarafından çalışılan saatler en sık girilir.)

Boyce-Codd Normal Form(BCNF)

Eğer bir tablodaki her belirleyici bir aday(candidate) anahtarsa, bu tablo Boyce-Codd normal form(BCNF) dadır.(Bir belirleyici herhangi bir özelliktir. Bu özelliğin değeri satır içindeki diğer değerleri tanımlar.) Açıkça eğer bir tablo sadecebir aday anahtar içerirse 3NF ve BCNF eşit olur. Eğer tablo birden fazla aday anahtar içerirse BCNF bozulabilir.

Çoğu tasarımcı Boyce-Codd normal form'u 3NF'in özel bir durumu olarak göz önünde tutar. Gerçekte eğer gösterdiğimiz teknikleri uyguluyorsanız, çoğu tablo BCNF gereksinimlerine uyar. Bu gereksinimlere 3NF de varılmıştı. Böylece bir tablo nasıl hem 3NF de olabilir ve BCNF de olamaz? Bu soruya cevap vermek için , esas(prime) olmayan bir özellik esas olmayan bir özelliğe bağlı olduğu zaman geçişli bir bağımlılığın var olduğunu aklında tutmalısın.

Fakat bu durumda esas olmayan bir özelliğe bağlı olan esas olmayan bir özelliğe ne dersiniz? Aşağıdaki senaryoyu göz önünde tut, bir aircraft parçaları toptantıcısı iki dağıtım merkezinde bakar,biri Seatle de,WA, ve biri Atlanta da GA. Her merkez airframe ve powerlent bileşenlerini idare eder. Bu bileşenler imalatçı tarafından aşağıdaki gibi sınıflandırılır:

     Power plant                    Airframe  
        Continental       (CO)         Cessna            (CE)
        Lycoming          (LY)         Beefchraft        (BE)
        Other Power Plant (OP)         Piper             (PI)	
                                       Other Airframe    (OA) 

Veritabanı ortamı şöyle özetlenebilir:

1. Her merkez birçok çalışana sahip,fakat her çalışan sadece bir merkezde çalışır. Bu yüzden EMPLOYEE ve CENTER arasında 1:M ilişkisi var olur.
2. Bir parça(powerplant veya airframe bileşeni) herhangi bir merkezdeki listede olabilir. Ve her merkez listedeki birçok parçaya sahip olabilir. Bu yüzden PART ve CENTER arasında bir M:N ilişkisi var olur.
3. Herbir merkezdeki çalışanlar imalatçı tarafından sınıflandırılan parçları yönetirler. Örneğin bir çalışan sadece Lycoming parçalarını yönetecek, biri sadece Beechcraft parçalarını idare edecek vs. Diğer bir değişle merkezdeki bir çalışan birçok parçayı yönetir. Fakat herbir parça sadece bir çalışan tarafından yönetilir. Bu yüzden EMPLOYEE ve PART arasında 1:M ilişkisi var olur.

Bu üç ilişki Tablo 4.4 de bulundurulur.

Tablo 4.4 deki veriyi incelerken 347 numaralı çalışanın Seattle deki bütün Beechcraftları, ve 555 numaralı çalışanın Atlanta'daki bütün parçaları yönettiğine dikkat edin. Bu yüzden her merkezdeki EP_NUM ve PART arasındaki ilişki 1:M ile gösteriliyor. Aynı zamanda EMP_NUM CENTER e tanımlar.Örneğin EMP_NUM=555 olduğunu bilirseniz, aynı zamanda merkezin yerinin Atlanta'da olması gerektiğini bilirsiniz.

Önceki tartışmaya dayanarak şekil 4.4 de gösterilen bağımlılıkları tanımlayabiliriz. Esas (prime) özellik CENTER in EMP_NUM a bağlı olduğuna dikkat edin. Çünkü her çalışan sadece bir merkezde çalışır. Bu yüzden eğer EMP_NUM u biliyorsak, CENTER'ıda biliriz.

   TABLO 4.4 Bir Aircraft Parçaları Toptancısı İçin  Veri Özeti

   CENTER       PART        EMP_NUM          IN_STOCK        STATUS

   SEA          BE12133     347              23              Ok
   SEA          LY32445     111             142              Overstock
   ATL          LY32445     330              26              Ok
   SEA          BE55519     347              19              30 on order, 08/12/92
   ATL          BE12133     555              26              Ok
   ATL          CE22140     123              43              Ok
   ATL          CE11118     123              51              Ok
   SEA          CO22140     216              67              Ok
   SEA          CO11118     216             121              Overstock
   ATL          BE55519     555              14              25 on order, 07/10/92
   SEA          BE34567     347              17              20 on order, 07/12/92
   ATL          BE34567     555              29              Ok
   SEA          LY89453     111              31              Ok
    .             .          .                .               .
    .             .          .                .               .                     

Şekil 4.4 BCNF de olmadan 3NF de olan bir tablo

Şekil 4.5 3NF de olup aynı zamanda BCNF deki tablolar

Teknik olarak Tablo 4.4 de gösterilen tablo 3NF içindedir. Çünkü o tablo 2NF içindedir ve geçişli bağımlılıklar içermiyor.(Esas(prime) olmayan bir özellik başka esas olmayan bir özelliğe bağlı olduğu zaman geçişli bir bağımlılık var olur.x) Fakat tablo BCNF içinde değildir. Çünkü EMP_NUM---->CENTER bağımlılığındaki, belirleyici EMP_NUM aday(candidate) bir anahtar değildir. Bu yüzden veri fazlalıkları oluşuyor.

Şekil 4.4 ün tablosundan EMP_NUM--->CENTER bağımlılığının yok edildiğinden emin olmak için, basit olarak yeni tabloyu oluşturmak için onu kaldır. Sonuçlar şekil 4.5 de gösterilir. Şekil 4.5 in ikinci tablosundaki PART özelliği kendi kendine yeterli bir birincil anahtar değildir. Çünkü bir parça her iki merkezde de stoklanabilir. Bununla birlikte eğer EMP_NUM da bilinirse geri kalan özelliklerin hepsi tanımlanır. Çünkü EMP_NUM PART'ın yerleştirildiği CENTER'ı tanımlar.

Şekil 4.5 i incelerken bu noktada her iki tablonunda 3NF de ve BCNF de olduğuna dikkat edin. Aynı zamanda daha önce şekil 4.3 de tanımladığımız veritabanı dört tablo içerir. Bu tabloların her biri 3NF ve BCNF içindedir. Bütün bağımlılıklar birincil anahtara dayandığı zaman BCNF ve 3NF daima eşit olur.

NORMALİZASYON VE VERİTABANI TASARIMI

Şekil 4.3 de gösterilen tablolar normalizasyon prosedürlerinin kötü bir tablodan iyi tabloların nasıl üretebileceğini göstermek için oluşturuldu. Eğer sıfırdan bir veritabanı oluşturuyorsanız herşeyden önce kötü tablolar meydana getirecek bir tasarım oluşturmamalısınız. Başka bir deyişle normalizasyon tasarım işleminin bir parçası olmalı. Bu yüzden tablo yapılarını oluşturmadan önce önerilen varlıkların gerekli normal formu karşıladığından emin olun.

E-R diyagramı bir organizasyonun veri gereksinimlerinin ve operasyonlarının büyük bir görünümünü sağlar. Bir E-R diyagramı tekrarlamalı işlemle oluşturulur. E-R diyagramını oluşturmaya ilgili varlıklar, bu varlıkların özellikleri ve ilişkilerini tanımlayarak başlarız. Sonra ek varlıkları ve özellikleri tanımlamak için sonuçları kullanırız.

Normalizasyon işlemleri belirli varlıkların karakteristikleri üzerine odaklanır. Yani normalizasyon E-R diyagramında var olan varlıkların küçük bir görünümünü temsil eder. Bu bölümün önceki kısımlarında öğrendiğiniz gibi normalizasyon işlemi E-R diyagramına birleştirmek için ek varlıklar ve özellikler meydana getirebilir. Bu yüzden normalizasyon işlemini E-R modelleme işleminden ayırmak zordur. İki teknik aynı anda uygulanmalı.

Normalizasyonun tasarım işleminde uygun rolünü örneklemek için önceki kısımlarda tabloları normalize edilen anlaşmalı şirketin işlemlerini yeniden inceleyeceğiz. Bu anlaşmalar şöyle özetlenebilir. Bu işlemler şu şekilde özetlenebilir:

1. Şirket birçok proje yönetir.
2. Her proje birçok çalışanın hizmetlerini gerektirir.
3. Bir çalışan birçok farklı projelere atanabilir.
4. Çalışan olarak göz önünde tutulan bir kişi en az bir projeye atanmalıdır.
5. Her çalışan tek bir birincil iş sınıfına sahip olmalıdır. Bu iş sınıfı saat başı hesaplanan ücreti belirler.
6. Birçok çalışan aynı iş sınıfına sahip olabilir.(Örneğin şirket birden fazla elektrik mühendisi çalıştırır.

Şirket işlemlerinin bu basit teşhisine dayanan iki varlık ve bu varlıkların özellikleri başlangıçta tanımlanır:

1. PROJECT(P-NO,P_NAME)
2. EMPLOYEE(E-NO,E_NAME,JOB_CLASS,CHG_HOUR)

Bu iki varlık şekil 4.6 da gösterilen ilk E-R diyagramını oluşturur. İlk E-R diyagramını oluşturduktan sonra normal formlar kontrol edilir:

1. PROJECT, 3NF dedir ve değişikliğe ihtiyac duymaz.
2. EMPLOYEE ek incelemeler gerektirir. "Electrical engineer","comminications technical representative" vs. gibi belirli bir iş sınıfı JOB_CLASS olarak adlandırılır. Ve iş sınıfı hesaplanan ücret faturasını tanımlar. Bu yüzden employee geçişli bir bağımlılık içerir.

is asigned to:atanır

Şekil 4.6 anlaşmalı şirket için ilk E-R diyagramı

Şekil 4.7 Anlaşmalı şirket için değiştirilmiş E-R diyagramı

EMPLOYEE'nin geçişli bağımlılığını çıkarma, üç varlık meydana getirir.

1. PROJECT(P-NO,P_NAME)
2. EMPLOYEE(E-NO,E_NAME,JOB_CLASS)
3. JOB(JOB-CLASS,CHG_HOUR)

Normalizasyon işlemi ek varlıklar meydana getirdiği için, ilk E-R diyagramını şekil 4.7'deki diyagrama uydurmak için değitiririz. EMPLOYEE ve PROJECT arasındaki M:N ilişkisi uygulanamadığı için, şekil 4.7 de gösterilen E-R diyagramı, PROJECT ve EMPLOYEE arasına köprü(bridge) veya bileşik(composite) varlık dahil etmek için değiştirilmeli. Böylece şekil 4.8 de E-R diyagramının üretilmesi gösterilmekte.(Şekil 4.8 de ASSIGN olarak isimlendirilen köprü varlık anahtarlarını bileşen varlıklar olan PROJECT ve EMPLOYEE den alır.)

Maalesef E-R diyagramı tarafından temsil edilen veritabanı, her çalışanın çalıştığı saatlerin faturasının hesaplanmasını dikkatle izlemeye elverişli değildir. HOURS özelliği bu yüzden ASSIGN köprü varlığına atanır. Bu son değişikliğe dayanan model böylece dört varlık ve özelliklerini içermeli:

1. PROJECT(P-NO,P_NAME)
2. EMPLOYEE(E-NO,E_NAME,JOB_CLASS)
3. JOB(JOB-CLASS,CHG_HOUR)
4. ASSIGN(P-NO,E_NO,HOURS)

Şekil 4.8 Anlaşmalı şirket için son diyagram

Tasarım işlemi şimdi doğru yolda: E-R diyagramı işlemleri tam olarak temsil eder ve varlıklar şimdi 3NF uyumlarını yansıtır. Normalizasyon ve E-R modellemenin birleşimi faydalı bir E-R diyagramı meydana getirdi. Bu diyagramın varlıkları şimdi uygun tablo yapılarına çevrilebilir.

DAHA YÜKSEK-SEVİYELİ NORMAL FORMLAR

3NF genellikle bir iş ortamında yeterli olmasına rağmen, daha yüksek seviyeli normal formların kullanılanılmasının gerekebileceği bazı durumlar var. Bir tabolonun satırlarının özelliklerinin belirli gereksinimlere uyması gerektiğini hatırlamalısınız. Bunlar:

1. Bütün özellikler birincil anahtara bağlı olmalıdır. Fakat bu özellikler birbirinden bağımsız olmalıdır.
2. Hiçbir satır bir varlık hakkından iki veya daha fazla çok-değerli(mutivalued) gerçekler içeremez.

Tablo 5.4 çok Değerli bağımlılıklar ile birlikte tablolar

Varsayalım ki belirli çalışan faaliyetlerini izlemekle ilgileniyoruz. Çalışan 10123 Red Cross ve United Way 'de gönüllü iş yapabilir. Ek olarak çalışan 10123, üç proje üzerinde çalışmak için atanabilir:1,5 ve 12. Tablo 4.5 gerçeklerin bu kümesinin nasıl farklı yollarla kayıt edilebileceğini örnekler.

Tablo 4.5 de gösterilen tablo versiyonlarının herbiri 3NF de olmasına rağmen, burada bir probleme sahip gözükürüz. E_SERVICE ve E_ASSIGN özelliklerinden herbiri birçok farklı değere sahip olabilir. Yani tablolar çok değerli bağımlılıklarını iki kümesini içerir. Çok-değerli birçok kümenin varlığı, eğer versiyon 1 ve versiyon 2 uygulanıyorsa, tablolar muhtemel olarak tam birkaç null değer içerecektir demektir. Böyle bir durum arzu edilen bir durum değildir. Özellikle eğer binlerce çalışan varsa, ve onların çoğu birçok iş tayinlerine ve birçok hizmet faaliyetlerine sahip olabilir.

Çözüm tablo 4.6 da gösterilen iki tablo oluşturularak çok-değerli bağımlılıkların sebep olduğu problemleri yok etmektir. Tablo 4.6 yı incelereken her iki tablonunda çok değerli bağımlılıklar içermediğine dikkat ediniz. Böyle tabloların dördüncü normal form(fourth normal form(4NF)) olduğu söylenir. Bu yolla 4NF i tanımlayabiliriz.

Tablo 4.6 4NF deki tabloların bir kümesi

Daha yüksek seviyeli normal formlar bile var olur.Bununla birlikte 5NF ve domain-key normal form(DKNF) e muhtemel olarak bir iş ortamında rastlanmayacak. Bunlara teorik olarak rastlanılmayacak.Çünkü veritabanı tekniklerinin pratik uygulamaları üzerine odaklanıyoruz. Daha yüksek seviyeli normal formları bu bölümde işlemeyeceğiz.

DENORMALİZASYON

Normalize edilen ilişkileri oluşturma önemli bir veritabanı amacı olmasına rağmen, o böyle birçok amacın sadece biridir. İyi veritabanı tasarımı aynı zamanda işleme gereksinimlerini hesaba katar. Normalizasyon gereksinimlerine uymak için tablolar ayrıştırılırken veritabanı tablolarının sayısı genişler. Büyük sayıda tablo birleştirmek ek disk çıkış/giriş(input/output) işlemleri ve işleme mantığı gerektirir. Ve böylelikle sistem yavaşlıyor. Sonuç olarak, arasıra çok durumlar olabilir ki, işlem hızını arttırmak için denormalizasyonun bazı derecelerine izin vermek, için denormalizasyonu değerli yapar.

Daha yüksek işlem hızı avantajı, veri anormalliğinin dezavantajlarına karşı dikkatle ölçülüp tartılmalıdır. Diğer bir deyişle bazı anormallikler sadece teorik ile ilgilidir. Örneğin gerçek dünya veritabanı ortamlarındaki insanlar, bir ZIP_CODE, CUSTOMER tablosundaki CITY'yi tanımlar, bu CUSTOMER tablosundaki müşteri numarasının(customer number) birincil anahtar olmasından gerçekten kaygılanmalı mı? Customer tablosundan geçişli bir bağımlılığı gidermek için ayrı bir tablo üretmek gerçekten pratik midir.?

ZIP(ZIP-CODE,CITY) CUSTOMER
Bizim tavsiyemiz basittir: Normalizasyon işlemi boyunca biraz sağduyuyu kullanın.

Kısmi ve/veya geçişli bağımlılık içeren tablolarla çalışmanın problemini en aza indirmek demek istemiyoruz. Zahmetli veri anormallikleri oluşturma imkanı bir yana, tam normalize edilmeyen tablolar şu kusurların sıkıntısını çeker:

1. Veri güncelleştirmeleri daha az verimlidir. Çünkü tabloları okuyan ve güncelleştiren programlar daha büyük tablolarla ilgilenebilmeli.
2. İndeks kullanımı çok daha elverişsizdir. İndeks kullanımı basitçe bir tek normalize edilmeyen tabloda yerleştirilen birçok özellikler için gerekli olan bütün indeksleri oluşturmak için pratik değildir.
3. Normalize edilmeyen tablolar görünüm oluştumak için basit stretejiler üretmezler.

İyi tasarımlar uygulama programların da oluşturulamaz. Aynı zamanda normalize edilmeyen tabloların sık sık çeşitli veri fazlalığı yıkımlarına yol açabileceğini unutmayın. Diğer bir deyişle denormalizasyonu ihtiyatla kullanın.

ÖZET

Normalizasyon tablolardaki veri fazlalıklarının azaltılmasını tasarlamak için kullanılan bir tekniktir. İlk üç normal form(1NF,2NF ve 3NF) ençok karşı karşıya gelinen formlardır. Yapısal bir bakış açısından daha yüksek normal formlar daha düşük normal formlardan daha iyidir, çünkü daha yüksek normal formlar veritabanında nispeten daha az veri fazlalıkları meydana getirirler. Diğer bir değişle , 3NF 2NF2'den iyidir, 2NF de 1NF'den iyidir. Hemen hemen bütün iş tasarımları ideal olarak 3NF normal formunu kullanır.

Bütün anahtar özellikleri tanımlandığı zaman ve kalan bütün özellikler birincil anahtara bağlı olduğu zaman, bir tablo 1NF dedir. Bununla birlikte, 1NF deki bir tablo hala hem kısmı hemde geçişli bağımlılıklar içerebilir.(Bir özelliği fonksiyonel olarak çok özellikli birincil anahtarın sadece bir parçasına bağlı olan bağımlılık kısmı bağımlılıktır(partial dependency). Bir özelliği fonksiyonel olarak anahtar olmayan başka bir özelliğe bağımlı olan bağımlılık geçişli bağımlılıktır(transitive dependency)). Doğal olarak bir tablo bir tek özellikli birincil anahtarla kısmi bağımlılıklar sergileyemez.

Bir tablo 1NF de olduğu ve hiçbir kısmi bağımlılık içermediği zaman 2NF dedir. Bu yüzden 1NF deki tablonun birincil anahtarı sadece bir tek özelliğe dayanıyorsa, bu tablo otomatik olarak 2NF dedir. 2NF deki bir tablo hala geçişli bağımlılıklar içerebilir.

Eğer bir tablo 2NF de ve hiçbir geçişli bağımlılık içermiyorsa bu tablo 3NF 'dedir. Boyce -Codd normal form(BCNF) sadece 3NF in özel bir durumudur,BCNF deki bütün belirleyici anahtarlar aday anahtarlardır. Eğer bir tablo sadece bir tek aday(candidate) anahtara sahipse, 3NF deki tablo otomatik olarak BCNF dedir.

3NF de olmayan bir tablo 3NF gereksinimlerini karşılayıncaya kadar yeni tablolara bölünebilir. Bu işlem aşağıdaki şekillerle gösterilir:

2NF 'e çevirmek: Yeni tablolar oluşturarak bütün kısmi bağımlılıkları kaldırın. Birincil anahtar bileşenlerinin herbirini ayrı bir satırda yazın, orjinal birincil anahtarı(A,B) içeren bir satır takip edilir.Bu anahtarların herbiri potansiyel olarak yeni bir tablo başlatır.

Yeni anahtarların herbirinden sonra bağlı özellikleri yazın. Hiç bir özellik A'ya bağlı olmadığı için , bir tablo hiçbir zaman birincil anahtar(A) için gerçekleşmez ve o göz önünden düşürülür.

Normalizasyon tasarım işleminin bir parçasıdır. Varlıklar ve özellikler E-R modelleme işlemi esnasında tanımlanırken, her varlık(küme) normalizasyon için kontrol edilir ve yeni varlık gerektiği gibi biçimlendirilir. Normalize edilen varlıkları E-R diyagramı içine birleştirin ve E-R işlemini bütün varlıklar ve onların özellikleri tanımlanana ve bütün denk tablolar 3NF de olana kadar devam edin.

3NF deki bir tablo çokdeğerli bağımlılıklar içerebilir, bu bağımlılıklar ya çok sayıda null değerler yada veri fazlalığı meydana getirirler. Bu yüzden tablonun 3NF deki tablonun dördüncü normal forma çevrilmesi gerekli olabilir. Dördüncü normal forma(4NF) çevirmek için çok değerli bağımlılıklar tablo bölünürek kaldırılır. Bundan dolayı bir tablo 3NF de hiçbir çok değerli bağımlılık içermiyorsa bu tablo 4NF dedir.

Daha çok sayıda tablo, onları işlemek ve birleştirmek için daha fazla ek giriş/çıkış(I/O) işlemi gerektirir ve işlem mantığı miktarı daha büyüktür. Bu yüzden tablolar bazen işlem hızı için daha az giriş çıkışı meydana getirmek için denormalize edilir. Maalese büyük tablolar yaparak işlem hızını arttırmak için daha az verimli veri güncelleştirmeleri yaparak, daha hantal indeksler yaparak , veri fazlalıklarını ortaya koyarak bedel ödersiniz, bu veri fazlalıkları muhtemelen veri anormallikleri meydana getirecek. Eğer gerekirse denormalizasyonu daha tutumlu bir şekilde kullanın.