Veritabanında Normalizasyon Kuralları Bölüm 5

Önceki yazılarda anlatılanlar gerçekten önemli bilgilerdi ancak yeterli mi hayır! Bu yüzden normalizasyon yaparak veritabanını daha da optimize daha efektif bir hale getirmemiz gerekiyor.  İşte veritabanını daha iyi hale getiren 3 tane kural var bunlara normalizasyon kuralları deniyor. Veritabanınız bu kurallara uyuyorsa iyi bir veritabanı tasarlamış olursunuz aksi halde güzel bir veritabanınız olmayacak , çünkü bu konuda bir sürü tecrübe yaşanmış ve bu kurallar tecrübelerin sonucunda ortaya konmuş kurallar. 

Bu formları oluşturduğunuz veritabanına uygulayın yada bu formlara göre veritabanınızı tasarlamalısınız yoksa iş bir süre sonra çıkmaza girecektir.

Özetle veritabanını genel veritabanı presiplerine uygun hale getirme işine normalizasyon denir.

  1. Normalizasyon Kuralı

Normalizasyonun 1. kuralı derki tablonuzdaki alanlarda atomik veri olsun birbiri ile ilişkili iki veri aynı alan içinde olmasın . 

buna bakalım musteriAdi adlı alanda bu kurala uymayan bir durum var ad soyad aynı alan içinde, halbuki bu musteriAdi alanına ek olarak birde musteriSoyadı alanı oluşturulmalı ve Soyad bilgisi musteriSoyadı alanına aktarılmalı.

 

 

o zaman şöyle olmalı

böyle olursa 1. normal forma uygun bir durum gerçekleşmiş olur.

 

 

 

 

Yine 1. Normal Form derki ; Alan adlarını çoğaltmayın mesela adamın 2 veya 3 adet adresi var adres1 ,adres2 , adres3 diye alanlar mı yapmalı. Hayır tabiki bunu başka bir tabloya aktarıp ilişki kurmak lazım

bu örnekte olduğu gibi.  musteriID si 5 olanın adreslerini getir dersek hepsi gelecektir.

2. Normalizasyon Kuralı

Key olmayan herhangi bir alan primary key olan alana bağlı olmalıdır. Yani tablodaki key olmayanlar key olan anahtar ile alakasız olmamalı şimdi şurada bulunan bir örneği inceleyelim resim linki :http://www.gitta.info/LogicModelin/en/html/DataConsiten_Norm2NF.html

bu örneğe baktığımızda IDSt ile IDProf birbiri ile farklı şeylere hizmet etmekte . Eğer bu tablodaki primary key IDSt ise IDProf bu key’e bağlı bir alan değil. Biraz daha açalım. IDSt öğrenci ile ilgili bir kaydı temsil ediyor ancak IDProf tamamen profesörleri gösteren bir parametre o yüzden bunu ayırmak gerekiyor. 

Burada sınıf kavramı da başlı başına ayrı bir konu olduğundan onu da ayrı bir tabloda göstermek uygun olacaktır.

 

 

3. Normalizasyon Kuralı

Hiçbir key olmayan alan diğer key olmayan alana bağımlı olmamalıdır. Vayy be ne cümle ama değil mi hiç bir şey anlamadım bu cümleden diyeniniz olabilir . 

Temel mantıkta şu var ; Kardeşim bir kayıtta (Satır’ı kastediyorum) herkes primary key kimse ona biat edecek , ona hizmet edecek ve tüm ilişkileri onunla alakalı olacak diğer alanlar kendi aralarında bir bağımlılık oluşturmayacak.  yine yukarıda linkini verdiğim sitede bulunan bir resme bakalım .

 Vendor satıcı demek bu arada. Satıcılar tablomuz var değil mi o zaman buradaki ID satıcı id’si dir . o zaman herşey satıcı ile ilgili olmalı diğer alanlar kendi aralarında ilişki kurmamalı.  Ancak burada Bank_Code_No , Bank birbiri ile bir ilişki kurmuş gözüküyor . o halde bu şu tanıma giriyor. Herhangi key olmayan bir alan diğer key olmayan alanlarla ilişkili olmamalıdır. 

Eğer aralarında böyle bir ilişki oluşacaksa bunu başka bir tabloya aktarmak en doğru yöntem olacaktır. nitekim örnek bu şekilde yapılmış . 

Evet normalizasyon da bu şekilde idi anlaşılmayan bir yer olursa yorum yazabilirsiniz. 

 

 

 

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir