Normalizasyonun ne olduğuna örnek üzerinden bakalım.
Diyelim ki bir Customer tablomuz var. İçerisinde Müşteri Numarası, Adı - Soyadı ve Adres alanları var.
Customer Tablosu
Customer ID | FirstName | LastName | Address |
1 | Ali | Veli | Deneme Mah. Deneme Sk. No:5/6 Kadıköy / İstanbul |
2 | Can | Demir | Test Mah. Deneme Sk. No:5/6 Lüleburgaz / Kırklareli |
3 | Birsen | Tunç | 1825 Sk. No:5/6 Konak / İzmir |
4 | Erdem | Yazar | Test Sk. No:5/6 Şişli / İstanbul |
Eğer bir müşterinin siparişi için bir tablomuz varsa, sipariş özeti için bize gerekli olan bilgiler Müşterinin Adı, Soyadı, Adresi, Sipariş Tarihi ve Sipariş Tutarı.
Müşteri bilgilerini "Sipariş " bilgilerini tuttuğumuz Order tablosuna da kopyalayacak mıyız o zaman? Müşteri bilgilerini Order tablosunda da taşınırsa ne olur peki? Bir müşterinin her bir siparişi için, Order tablosunda müşterinin tüm bilgileri tekrarlanır. Bu Order tablosunun gereksiz yere fazla bilgi ile dolmasına ve verilen diskte gerektiğinden fazla yer kaplamasına neden olacaktır. Tabii bu bilgiler sadece tabloda değil, aynı zamanda index tablolarında da tekrarlanacaktır. Ancak daha da önemlisi, müşterinin bilgilerinde bir değişiklik olduğunda sadece Customer tablosunu güncellememiz yeterli olmayacak, Order tablosunda da o müşteriye ait tüm sipariş kayıtlarını bulmamız ve onları da güncellememiz gerekecektir. Bunu unutmamız durumunda ve update işlemi sırasında bir hata ile karşılaşırsak ve bu da kayıtların bir kısmını güncelleyip, bir kısmını da güncellemez ise ortaya çıkacak karmaşayı düşünebiliyor musunuz?
İşte tüm bu karmaşadan ve sorunlardan kaçınmak için tablolar normalize olarak tutulur. Normalizasyon, bir grup tablo tanımlama kuralıdır. Normalizasyon kurallarına göre, tablolar tasarlanırken, bağlantılı oldukları tabloların her birinden sadece tek bir alan içerirler. Tabii bu alan tek olunca, bağlantılı oldukları tablodaki doğru kaydı bulabilecek bir bilgi tutmalıdırılar. Örneğin sipariş tablosundan, müşteri bilgisi olarak müşterinin sadece adını tutmamız, aynı isimde birden fazla müşteri olacağı için bir işe yaramaz. Bunun için Müşteri numarası gibi, her bir müşteri için tek olan ve değişmeyecek bir alan seçilmelidir.
İşte normalize edilmiş Sipariş tablosu :
OrderID | CustomerID | OrderDate | OrderAmount |
1001 | 1 | 15.02.2010 | 150 |
1002 | 3 | 15.02.2010 | 250 |
1003 | 1 | 16.02.2010 | 500 |
1004 | 2 | 17.02.2010 | 100 |
1005 | 4 | 18.02.2010 | 1250 |
1006 | 2 | 19.02.2010 | 85 |
1007 | 2 | 20.02.2010 | 950 |
1008 | 1 | 21.02.2010 | 120 |
Normalizasyonun da çeşitleri vardır. 3rd Normal Form, 4th Normal Form gibi.
Bu detaylara daha sonra gireceğiz. Ancak akılda tutulması gereken şey, normalizasyon, veri tekrarının önlemek için konulan bir veri tabanı tasarım kuralı olmasıdır. .
Normalizasyonun tam tersine, yani bir tabloda, diğer tablolardaki birçok bilginin tekrarlandığı, kayıt tekrarına izin verilen tablolara denormalize edilmiş tablolar denir.
Veri güncellemesi yapılmayan, daha çok raporlama için kullanılan veri tabanlarında, hızlı sorgulama yapılmak için tablolar denormalize edilebilir.
Bu da denormalize edilmiş bir sipariş tablosu
OrderID | CustomerID | OrderDate | OrderAmount | FirstName | LastName | Address |
1001 | 1 | 15.02.2010 | 150 | Ali | Veli | Deneme Mah. Deneme Sk. No:5/6 Kadıköy / İstanbul |
1002 | 3 | 15.02.2010 | 250 | Birsen | Tunç | 1825 Sk. No:5/6 Konak / İzmir |
1003 | 1 | 16.02.2010 | 500 | Ali | Veli | Deneme Mah. Deneme Sk. No:5/6 Kadıköy / İstanbul |
1004 | 2 | 17.02.2010 | 100 | Can | Demir | Test Mah. Deneme Sk. No:5/6 Lüleburgaz / Kırklareli |
1005 | 4 | 18.02.2010 | 1250 | Erdem | Yazar | Test Sk. No:5/6 Şişli / İstanbul |
1006 | 2 | 19.02.2010 | 85 | Can | Demir | Test Mah. Deneme Sk. No:5/6 Lüleburgaz / Kırklareli |
1007 | 2 | 20.02.2010 | 950 | Can | Demir | Test Mah. Deneme Sk. No:5/6 Lüleburgaz / Kırklareli |
1008 | 1 | 21.02.2010 | 120 | Ali | Veli | Deneme Mah. Deneme Sk. No:5/6 Kadıköy / İstanbul |
Normalizasyon ile ilgili daha detaylı bilgiler yakında burada olacak.
Hiç yorum yok:
Yorum Gönder