İlişkisel veritabanı teorisinde geçen ve ilişkisel bir veri tabanının hafızayı daha verimli kullanması için geliştirilen normal şekillerden ikincisidir. Bir veri tabanı tasarlanırken veya daha sonradan normalleştirilebilir yani normal form kurallarına uyması sağlanabilir. Bu sayede veritabanının daha az yer kaplaması sağlanmış olur. Ancak bazı durumlarda yerden fedakarlık yapılarak hız ön plana çıkar. Bu durumda normalleştirilmiş bir veritabanının bozulması (denormalization) gerekir. Veritabanımızın ikinci normal şekle uyması için iki temel kural vardır;
- Birinci normal şekle uymalıdır.
- Bir satırı tek başına tanımlayabilecek bir candidate key olmalıdır.
Örnek:
Çalışanlar Tablosu
İsim Soyisim Yaş Departman Dahili Tel
Berkay Demirel 24 Bilgi İşlem 144
Ali Veli 33 Bilgi İşlem 144
Mehmet Ahmet 25 Muhasebe 145
Bu tabloya baktığımızda birinci normal şekle uymadığını görürüz çünkü kişi departman ve dahili tel bilgisi farklı kişiler için tekrar ediyor. İlk önce birinci normal şekle uygun hale getirmek için departman bilgilerini ayrı bir tabloda tutabiliriz.
Çalışanlar Tablosu
İsim Soyisim Yaş Departman
Berkay Demirel 24 144
Ali Veli 33 144
Mehmet Ahmet 25 145
Departman Tablosu
Departman Dahili Tel
Bilgi İşlem 144
Muhasebe 145
Yukarda görüldüğü üzere tasarım birinci normal şekle uygun hale getirildi. Departman talosuna bir id (anahtar) bilgisini eklememizin nedeni dahili tel numarasının zaten her bir satır için farklı olacağıdır. Burada dikkat edilmesi gereken şey her bilgi bir satırı tek başına ifade edebiliyor olsa bile o bilginin anahtar olarak kullanılamayacağıdır. Örneğin kişinin e-posta adreside herkes için farklıdır ancak bu bilgi anahtar olarak kullanılmamalıdır. Çünkü bu bilgi bir sayıya göre hafıza daha fazla yer kaplar ve ilişki kuralacak her iki tabloda da bulunması gerektiğinden gereksiz olacaktır. Bu yüzden genelde anahtarlar sayısal değer olarak tutulurlar. Ayrıca anahtarlar üzerinde indeks oluşturulduğundan sayısal değerler kullanılması çok daha uygun olacaktır. Burada dahili tel vereceğimiz id bilgisi gibi hem sayısal bir değer olduğundan hem de id bilgisi gibi çok büyük bir sayısal değerden oluşmadığından dolayı (örnek olarak 30 haneli bir sayısal değerin de anahtar olarak kullanılması çok uygun değildir) id bilgisi olarak kullanılabilir.
Bu tasarımın ikinci normal şekle uyması için ikinci şart olan bir candidate key belirlenmesi gerekir. Yukarıdaki tasarımda çalışanlar tablosundaki her satırı tanımlayan bir anahtar yoktur.
Çalışanlar Tablosu
id İsim Soyisim Yaş Departman
1 Berkay Demirel 24 144
2 Ali Veli 33 144
3 Mehmet Ahmet 25 145
Departman Tablosu
Departman Dahili Tel
Bilgi İşlem 144
Muhasebe 145
Yukarıdaki tasarımı incelediğimizde ikinci normal şekle uygun halde olduğunu görebiliriz. Çalışanlar tablosu için id, departman tablosu içi dahili tel bilgisini anahtar olarak belirledik ve bu bilgiler bulundukları satırı tek başına tanımlayabiliyorlar. Ayrıca bu tasarım birinci normal şekle de uyduğu için ikinci normal şekle uyduğunu söyleyebiliriz.
No comments:
Post a Comment