2

Okuduğum bazı yazılarda ve yorumlarda veritabanı normalizasyonu hakkında pekte işe yaramadığı ile ilgili bilgiler yer alıyordu. Açıkçası bu düşünceleri bilgisizlikten başka birşey olarak görmüyorum.

Günümüzde en çok kullanılan veritabanı yapısı ilişkisel olan. Bu tasarıma göre, veritabanı belirli parçalardan oluşur (tablolar) ve bu parçalar arasında belirli bağlar vardır. Bu bağlar ilişkileri temsil eder. Peki bu ilişkiler bize ne sağlar? Açıkçası veri bütünlüğü ve temizliğinden öte pek birşey sağlamazlar. Veri temizliğinden kastım çöp verilerin bulunmamasıdır. Örneğin bir tabloda kişilerin temel kayıtlarını (ad soyad doğum tarihi gibi), bir diğer tabloda ise kişilerin nüfus cüzdanı bilgilerini tuttuğunuzu düşünelim. Bu durumda karşımıza iki seçenek çıkar :

1)

KiÅŸi Tablosu

* Ad
* Soyad
* Tc Kimlik No

Nufus Tablosu

* Ad
* Soyad
* Tc Kimlik No
* NufusCuzdaniNo
* AileSiraNo … vs

şimdi bu durumda şuna dikkat edin, burada Ad soyad ve Tc Kimlik No alanları diğer tabloda tekrar girilmiş. Bu durumda veri tekrarı doğuyor. Oysa yapı şu şekilde olsaydı :

2)

KiÅŸi Tablosu

* KisiNo
* Ad
* Soyad
* TcKimlikNo

Nufus Tablosu

* NufusID
* KisiNo
* NufusCuzdaniNo
* AileSiraNo … vs

Yukarıda, Nüfus tablosuna kişi no kolonunu koyarak veri tekrarını engelledik. Bu alana kişi tablosundaki kayıtlı kişinin numarasını gireceğiz. Gördüğünüz gibi basit bir ilişki kurguladık. Peki bu ilişkinin tutarlılığını nasıl sağlayacağız? Yani Nufus tablosuna Kişi tablosunda olmayan bir kayıt numarası girilmesini veya Nufus tablosunda ilişkili verisi bulunduğu halde Kişi tablosundan kayıt silinmemesini nasıl engelleyeceğiz? Bu saydığım şeyler her halükarda aynı kapıya çıkarlar, sahipsiz (abondon) verilere.

BahsettiÄŸimiz bütünlüğü saÄŸlarken FK (Foreign Key) denilen anahtarları kullanmalıyız. Bu yapıyı Nüfus tablosundaki KisiNo kolonuyla Kisi tablosundaki KisiNo kolonları arasında kurmalıyız. Bu iki alan arasında iliÅŸki kurduÄŸumuz zaman, veritabanı yukarıdaki sahipsiz veri oluÅŸmasını engelleyecek, gerektiÄŸinde hata üretecektir. Bu ÅŸekilde bizde veri bütünlüğümüzü garanti altına almış olacağız. Buradaki NufusID kolonu ise verilerin index’lenmesi için kullanılacak anahtar kolonumuz yani PK (Primary Key). Normalizasyon kurallarına göre iliÅŸkilerde PK’lar üzerinden kurulur bunu unutmamak lazım.

İlişkisel veritabanlarında veri bütünlüğünü korumak için sadece ilişkiler kullanılmaz. Bunun yanında kısıtlamalar (constraints) da kullanılır. Bunun anlamı şudur, verilerinizin doğruluğunu korumak için belirli kısıtlamalara gidebilirsiniz. Mesela TC Kimlik numarası gibi verilerin yanlış girilmemesi için böyle bir uygulamadan faydalanabilirsiniz. TC Kimlik numarası bilindiği gibi 11 hanedir, başı sıfırla başlayamaz ve sonu çift sayı olmak zorundadır. Veritabanınızda Tc Kimlik numarasını tuttuğunuz alanları kolaylıkla bu gibi kriterlere uygunluk için kilitleyebilirsiniz.

Bir diÄŸer kilitleme yöntemi ise, uniqe constraint’tir. Yani bir veya birkaç alanda tutulan verilerinize mükerrerlik kısıtlaması getirebilirsiniz. Örnek olarak, tuttuÄŸunuz kayıtlarda ad, soyad ve doÄŸum tarihi aynı olan sadece bir kayıt olmasını istediÄŸinizi düşünelim. Bu durumda uniqe constraintler tam aradığınız kısıtlamalardır.

Peki ben bunları neden anlatıyorum? Konumuz normalizasyon değil miydi? Aslında yukarıda anlattığım normalizasyonun ta kendisi. Normalizasyon denilen şey aslında veritabanını düzgün kurgulamaktan başka birşey değildir. Normalizasyon kurallarıda tamamen bunu işaret eder. Bu noktada dönüp önce veritabanında olabilecek ilişki çeşitlerine göz atalım.

Veritabanı İlişki Türleri

I) 1′e 1 iliÅŸki

Bire bir iliÅŸki demek, bir tablodaki kaydın iliÅŸkili olduÄŸu tabloda sadece bir karşılığı olması demektir. ÖrneÄŸin yukarıdaki örnekte, KiÅŸi tablosunda varolan bir kiÅŸi kaydının sadece bir tek Nüfus bilgisi olacağına göre, Nufus tablosunda da iliÅŸkili tek kaydı olacaktır. Bu duruma 1′e 1 iliÅŸki denir.

II) 1′e n iliÅŸki

Yukarıdaki tablolara birde kişinin okuduğu okulların bilgilerinin tutulduğu bir tablo ekleyelim. Bu tabloda aşağı yukarı şöyle birşey olsun :

Okul Tablosu

* KisiNo
* OkulAdi
* MezunOlmaTarihi … vs

Bir kiÅŸinin birden fazla okulda okuduÄŸunu varsayarsak, bu tabloda bir KisiNo’ya ait (veya aynı KisiNo’ya sahip diyelim) birden fazla kayıt olacaktır. İşte bu duruma 1′e çok iliÅŸki denir.

III) n’e n iliÅŸki

Çok’a çok iliÅŸki demek, bir tablodaki bir kaydın, iliÅŸkili olduÄŸu tabloda birden fazla karşılığı olması demektir. Bu yapılar geçiÅŸ tablosu denilen tablolar kullanılarak tasarlanırlar. Örnek vermek gerekirse, kiÅŸilerin bazı bilgilerinin birden fazla dilde olan karşılıklarının tutulması gerektiÄŸini düşünün. Bir dil tablomuz olsun :

Dil tablosu

* DilNo
* DilAdi

ve bu dillere çevrilecek kayıtların olduğu tablomuz olmalı,

KisiCevrilecek tablosu

* KisiCeviriNo
* KisiNo
* OrinalKisiAd
* OrjinalKisiAdres

son olarak çevirilerin tutulduğu tablomuz,

KisiCeviri

* KisiCeviriNo
* DilNo
* CeviriKisiAd
* CeviriKisiAdres

Burada KisiCeviri tablosu geçiÅŸ tablosudur. DilNo alanı çevirilen dili, KisiCeviriNo alanı ise çevrilecek verileri temsil etmektedir. Burada Dil tablosuyla KisiCevrilecek tabloları arasında N’e N’lik bir iliÅŸki vardır.

Normalizasyon

Bu kadar ilişki bilgisinden sonra normalizasyona geçebiliriz. Normalizasyon dediğim gibi, veritabanını kurallara uygun dizayn etmektir. Normalizasyonunda belirli kuralları vardır. Ama bunlar sadece uyulması kesinlikle zorunlu kurallar değildir onu belirteyim. Sadece bu yapıya tam uygunluk sağlarlar. Peki nedir bu kurallar :

  1. Bir satırda yalnızca bir tek benzer bilgi bulunur. Örneğin, kişinin okul bilgileri Okul1, Okul2, Okul3 diye tutulmaz. Bunlar ayrı bir tabloda (aynı bizim Okul tablomuz gibi) tutulmalıdır.
  2. Bir tablodaki tüm alanlar o tablonun PK alanına baÄŸlı olmak zorundadır. Yani Kisi tablosu için konuÅŸursak, Kisi tablosunun PK’sı yani indekslendiÄŸi alan, KisiNo alanıdır. ÖrneÄŸin KisiNo’su 1 olan bir kayıtta KisiNo’su 2 olan birisinin bilgileri bulunamaz. O zaman karışıklık olmuÅŸ olur. Veya Kisi tablosunda Kisi’ye ait olmayn veriler tutulamaz. Tabii bu kural doÄŸal olarak iliÅŸkide bulunulacak her tablonun PK alanının bulunması gerekliliÄŸini de getirir. Zaten Primary Key alanı olmazsa performanslı bir yapıda olmaz.
  3. Tabloları tutarlı bir şekilde mümkün olan en ufak boyutta (alan sayısı olarak) tutmak gereklidir. Tablodaki diğer alanları başka tablolara koyarak onlar arasında ilişkiler kurmalıyız.
  4. Bir PK ile PK olmayan alanlar arasında bire çok ilişki olmamalıdır. Örneğin kişimizin çalıştığı yerlerin tutulduğu bir tablo daha olsun. Aynı zamanda bizim için önemli olan kişilerin çalıştığı işlerin sektörleri olsun. Bu durumda Sektor diye bir tablo yapıp CalistigiIs tablosuyla ilişkilendirmemiz gerekir.

Bu kurallar sizin veritabanınızı düzgün kurmanızı sağlar. Bir sonraki yazıda, bir örnek üzerinden bu kuralları Ms Sql Server ve MySql veritabanı sistemlerinde nasıl uygulayacağımıza değineceğim. Ondan bir sonraki yazıda da veritabanı tasarımı ve normalizasyonunun performans üzerindeki etkilerinden bahsedeceğim. Aklımda birde veritabanı uygulamalarının nasıl yazılmasıyla ilgili bir yazı var. Sanırım böyle seriyi noktalayabilirim.

Görüşmek üzere.

Ek Bilgiler

Bu yazı istenilen yerde istenilen şekilde yayınlanabilir (değişikliklerden yazının orjinalini yazan yazar kesinlikle sorumlu değildir). Sadece yazdığınız yazının altında veya üstünde orjinal yazıya link verirseniz sevinirim. Vermezsenizde sorun değil. İlginiz için teşekkürler.

Eğer girdiyi beğendiyseniz, başkalarıyla da paylaşın!
Tusul | Habberci | Haber.gen.tr | Oyyla | Bağcık | 100 Puan | Linkibol | Teknikim

2 Yorum

  1. Osman diyor ki:

    Fazla soze ne hacet derler ya, cok guzel anlatmissin tebrik ederim eline saglik.

  2. remart09 diyor ki:

    Bir yazılımcı olmayan ben bile anladım :) Açık ve net olmuş. Anlatımınız için teşekkürler

Yorum Bırakın