Norm Formlar ile Veritabanı tablolarının normalize edilmesi

Genellikle sürecin bir parçası olarak birkaç yeni tablo oluşturulur. Ancak, normalleştirmenin nihai sonucu, veritabanının daha kolay düzenlenmesini, bakımını ve işlemlerini önceden biçimlendirmesini, tekrar eden satırları kaldırmayı ve ayrılan diğer tablolar ile birlikte çalışmayı daha güvenilir hale getirmektir. Bu düzenlemeleri yaparken fonksiyonel bağımlılıklar üzerinden gideceğiz. Fonksiyonel Bağımlılık, veritabanındaki bir kolonun diğer bir kolonu tanımlayabiliyor olmasıdır. Bir vatandaşın tc kimlik numarası ile isminin bulunabiliyor olması bu duruma örnek olarak gösterilebilir. Bir kolona bakarak diğer kolonların bilgilerine ulaşabilme özelliğidir.

1NF form

Bütün niteliklerin aldığı değerler atomik olmak zorundadır. İlişkisel veri tabanı modelinin temel kısıtıdır ve her nitelik ancak atomik veriler alabilir. Atomiklikten kasıt 1 satır için her kolonda, yani her nitelikte sadece bir değer bulunabilir. Herhangi bir nitelik 2 değer saklamamalı. Yani diyelim bir öğrenci var ve onun kullandığı yazılım dillerini içeren kolonu var, kullandığı yazılım dilleri kolonunda 2–3 dil aynı anda bulunamaz. Her dil için ayrı bir satır tanımlanıp öğrenci duplicate edilmesi gerekiyor. Aşağıda görsel olarak görebilirsiniz.

2NF form

Bir ilişki tablosu 1NF ise ve anahtar olmayan her nitelik tamamen işlevsel olarak birincil anahtara bağlıysa 2NF biçimindedir. Primary key olmayan değerler ile bileşik anahtarlar(2 kolonun birleştirilip primary key yapılması) arasında kısmi bağımlılık durumu oluşmamalıdır. Kısmi bağımlılık durumu, anahtar olmayan herhangi bir değer bileşik bir anahtarın yalnızca bir kısmına bağıl ise oluşur. Aşağıda gördüğünüz gibi student_id, student_name, address sütunları subject sütununa bağlıdır. Burada student_id, student_name ve address sütunları bir tablo yapıp foreign key’i de student_id yaparsak, sonrasında ilk tabloda foreign key yaptığımız student_id sütununu ayrı bir tabloya bağlayıp subject sütunu ile birleştirirsek bu bağlılıkları kaldırmış ve duplicate satırlardan kurtulmuş oluruz. Ana tablo ile yeni tablolar arasında joinler gerçekleştirebilmek için foreign key tanımlamak zorundayız. Aksi halde birbirinden alakasız tablolar olacaktır.

3NF form

Eğer tablomuzdaki herhangi bir birincil olmayan (non-prime) nitelik A, tablonun hiçbir anahtar niteliğine geçişli (transitively) fonksiyonel bağımlı değil ve hali hazırda 2NF’da ise, bu ilişki şeması 3NF’dadır denir. Birincil anahtarla ilişkili olmayan herhangi bir sütun varsa, bunları kaldırın ve ayrı bir tabloya koyun, her iki tabloyu foreign key aracılığıyla ilişkilendirin; geçişli bağımlılık olmamalıdır.

Yukarda gördüğünüz gibi A sütunu B ve C sütununa bağımlı, B sütunu da D sütununa bağımlıdır. Bu şekilde bir geçişli bağımlılık olduğunu daha net şekilde görebilirsiniz. A’nın bağımlı olduğu B sütunu gidip D sütununa bağımlı oluyor bu duruma geçişli bağımlılık denir. 3NF’de bunu engellemeye çalışacağız.

Burada, STREET ve CITY’nin Öğrenci ile doğrudan ilişkisi yoktur. Tamamen posta koduna bağlıdırlar. Öğrenci o bölgede kaldığı için posta kodu ile cadde ve şehir onunla ilişkilidir. İkinci düzeyde bağımlı olduğu için bu detayların ÖĞRENCİ tablosunda saklanmasına gerek yoktur.

Boyce-Codd Normal Form (3.5NF)

Yukarıdaki 3NF örneğinde, STUDENT_ID, STUDENT tablosundaki Birincil anahtardır ve ZIP, ZIPCODE tablosundaki birincil anahtardır. Tabloların her birinde işlevsel bağımlılığı belirleyen başka bir anahtar sütun yoktur. Dolayısıyla BCNF formundadır. Ayrıca 3NF’nin tüm gereksinimlerini karşılamalıdır. Aynı veriler birden fazla tabloda saklanmadığında ve yalnızca ilgili veriler bir tabloda depolandığında bir veritabanı normalleştirilir. Bu da veritabanını normalize etmemizin temel amacıdır.