Merhabalar; bu yazımda sizlere öncelikle genel olarak key (anahtar)
terminolojisinden biraz bahsettikten sonra esas üzerinde durmak istediğim nokta
Surrogate Key ile Natural Key'in karşılaştırılması ve bunların kullanım
şekilleri olacak.
Key: Anahtar bir ya da birden fazla verinin benzersiz olarak kimliğinin
tanımlanmasıdır. Fiziksel veri tabanlarında key'ler bir ya da birden fazla
tablo kolonlarının biçimlendirilmesi ve onların ilişkisel tablolardaki
satırların birbirinden benzersiz olarak tanımlanmasına olanak verir.
Composite Key: İki ya da daha fazla özelliklerin key ile
birleştirilmesine verilen isimdir.
Natural Key: Gerçek yaşamda var olan bir özelliğin anahtar özellik
olarak kullanılması denilebilir. Biraz daha açıklayıcı olması açısından tam da
natural key'e örnek olarak Türkiye Cumhuriyetin'de yaşayan her Türk
vatandaşının sahip olduğu ve benzersiz olan TC Kimlik numarası buna örnek
verilebilir.
Surrogate Key: Bu key natural key gibi herhangi bir anlamı
yoktur ve sistem tarafında otomatik olarak tanımlanabilirler.
Candidate Key: Logical Data modelinde
hiç anahtar bulunmadığı gibi aynı zamanda birden fazla candidate anahtar
bulunabilir. Ayrıca temel olarak benzersiz tanımlayıcı da olabilir. Daha
açıklayıcı olması açısından örnek vermek gerekirse bir banka veritabanı
düşünelim. Bankada her bir müşterinin benzersiz hesap ID'sinin yanı sıra aynı
zamanda müşterilerinin TC Kimlik Numaraları da kullanılır. Şimdi küçük bir
senaryo oluşturalım. Farz edelim ki devlet TC Kimlik Numarasını bireylere
atarken yanlışlıkla iki kişiye aynı numarayı atadığını varsayalım. Eğer ki
banka benzersiz numara olarak bir tek TC Kimlik numarasını kullanmış olsaydı bu
iki TC No su aynı olan kişiyi veri tabanına kayıt ederken problem yaşanacaktı.
Oysaki bu durumda en azından primary key alanı olan HesapID üzerinden işlemler
sorunsuz bir şekilde devam edecektir.
Primary Key: Primary key etkili ve önemli bir ilişkisel veri tabanı konseptidir
diyebiliriz. Benzersizliği sağlar ve primary-froign key ilişkisi sağlanmadan
ilişkisel veritabanı düzgün şekilde çalışmayacaktır.
Alternate Key: İkincil anahtar da
denilebilir, tablodaki bir satırın ikinci benzersiz tanımlayıcı alanıdır.
Foreign Key: Birincil ya da ikincil
anahtarın başka bir tabloda temsil edilmesi denilebilir.
İlişkisel veri tabanlarını teorilerine göre, tabloların tam olarak
normalize edilmesi için primary key'in tanımlı olması gerekmektedir. Fakat DB
developer'ların üzerinde tartıştığı önemli bir konu ise surrogate mı yoksa
natural primary key'in en iyi olduğu konusudur.
İlişkisel veri tabanı teorilerine göre, tabloların tam anlamıyla normalize
olması için primary key olmak durumundadır. Fakat database developer'ların
üzerinde tam olarak uzlaşamadığı bir nokta var ki surrogate kullanımı mı? Yoksa
natural primary key kullanımı mı aralarında en iyisidir. Datalar aslında
naturel key içerirler. Surrogate key’ler ise gerçek bir anlam içermezler. Hatta
genellikle bu değerleri sistem tarafında üretilirler. Bazı DB developer'lar
bunlardan ikisini de tercih edebilirler.
Primary Key Benzersiz Olmalı: Tablolarda saklanan
veriler diğer alakalı tablolarda saklanan veriler ile bağlı olabilir ve her bir
data, primary key vasıtasıyla benzersiz olarak tanımlanırlar. Naturel Key’e çeşitli
alanlarda ihtiyaç duyulabilir ve naturel key her bir kayıt için benzersiz
kimlik özelliğini sağlar. Surrogate key de kendi içerisinde de bu benzersizliği
sağlamaktadır.
Primary Key Mümkün Olduğunca Kompakt Olmalı: Peki bu ifadenin bize
anlatmak istediği şey nedir? Başlıktaki kompakt ifadesi bize tablolardaki
benzersiz kimliğe sahip olması gereken alanların sayısını ifade etmektedir. DB
developer'lardan bazıları naturel keys için çoklu alanlarda primary key
kullanımı daha performanslı olduğu üzerinde dururlar. Primary key kompakt
olmalı ve olabildiğince az field içinde kullanılmalıdır. Naturel key
kullanımında birden fazla alan gerekmektedir. Surrogate key ise sadece bir alan
gerektirir.
Primary Key Değeleri Stabil Olmalı: Primary Key alanlarına
gelecek olan data'lar stabil yani değişmez olmasına dikkat edilmelidir. Fakat
bunu engellemenin bir yolu da yok, daima istisnai durumlar bu konu ile ilgili
yaşanmaktadır. Ayrıca Naturel data'lar öznel olma özelliğine sahiptir ve bu
veriler dış dünyadaki durumlardan etkilenirler ve bunları kontrol edemeyiz. Db
developer'lar bu durumu göz önünde bulundurup kabullenmekten başka seçenekleri
de bulunmamaktadır.
Surrogate key'de kullanılan değerler dış dünyadan değer almazlar yani
anlamsız değerlerdir diyebiliriz. Bu durumda herhangi bir data’nın değişikliğe
uğramak durumunda kalacağı istisnai bir durumda yaşanmaz. Eğer surrogate key
değerlerinde bir data’da değişiklik yapmak zorunda kaldıysanız başlarda yapmış
olduğunuz bir hata var demektir.
Primary Key Değerleri, Kayıt Oluşturmaktadır: Şunu unutmamak gererkir
ki, primary key'in kullanıldığı alanlar null geçilemez. Başka bir deyişle
primary key'ler aslında kayıt oluştururlar. Peki, bu durumda siz primary key
değerini herhangi bir kayıt oluşturmadan önce bilmeli misiniz? Teorik olarak
buna cevabımız hayır, ama gerçekte bazen bilmek zorunda kalabilirsiniz? Siz
yeni bir kayıt oluşturduğunuzda surrogate key de değerler sistem tarafından
atanır. Bundan dolayı primary key değerleri kayıt oluşturlduğu anda otomatik
olarak yaratılırlar.
Kopya Verilere İzin Verilmez: Normalize edilmiş bir
tabloda verilerin kopyalanmasına izin verilmez. İşlevsel olarak, evet doğru.
İlişkisel teori açısından, hayır diyebiliriz. Unique index'lerde ve primary
key'lerde verilerin tekrar edilmesi engellenir. Bu iki durumda da biri bir
diğerini tamamlıyor ve sıklıkla bu görüş naturel key içindir. Naturel key'i
savunanlar bu noktada surrogate key için veri tekrarına sebep olabileceğini
idda ederler. Eğer surrogate primary key kullanmak istiyorsanız, uygun alanları
index'lemeniz veri tekrarını önleyip bu problemi de çözecektir.
Kullanıcılar Primary Key Görmek İster: Genelde böyle yanlış bir
anlayış vardır. Primary key değerleri olmadan genelde kullanıcılarda bir
eksiklik varmış gibi bir algı oluşur. Bunun için geçerli bir sebep yok oysaki.
Gerçekte kullanıcıların böle bir değeri bilmesine de ihtiyaç yoktur. Arka
planda tutulması yeterlidir. Primary key kullanıcı tarafında bir anlam ifade de
etmemelidir zaten. Kullanıcı veri girer, mevcut veriyi günceller, rapor alır ya
da bunun gibi şeyler. Kullanıcı işlem yaptığı tarafta primary key kullanımına
ihtiyaç duyma düşüncesi terk edilmelidir. Bunu da surrogate key ile arka planda
çalıştırarak da daha kolay sağlayabiliriz.
Gereksiz Alana Surrogate Ekleme: Surrogate kullanımı bize
extra bir alan gerektirmektedir ki bu da boş alanların israf edilmesine sebep
olacaktır. Sonuçta gereken her şey kayıt için benzersiz bir kimlik tanımlamak
ki bu işlemde aslında diğer tablolardaki verilerle ilgilidir. Otomatik değer
üreten bir alan hem disk maliyetini düşürecektir hem de bu konu ile alakalı
bakım durumunu minimal düzeyde tutacaktır. Bu, natural key kadar
önerilmemektedir. Fakat geçerli bir yöntem de denilebilir.
Sistem Hata Yapmaz: Herkes sistem tarafından
üretilen değerlere yeteri kadar güvenmeyebilir. Sistem tarafında bir hata
oluşabilir. Fakat diğer taraftan, Naturel value kullanımında da problem çıkması
muhtemeldir. Veri tabanını korumanın en iyi yolu düzenli olarak uygulanan bir
back up stratejinizdir. Naturel veriler sistem tarafından oluşturulanlardan
daha fazla güvenilir değildir.
Koşullar Natural Key Kullnımını Gerektirir: Entegre olmuş
sistemlerde natural key kullanımı gerekebilir. Bazen benzer tablolar paylaşan
uygulamaların birbirinden bağımsız yeni kayıtlar oluşturur. İki farklı
veritabanı muhtemelen birbirine benzer değerler üretecektir. Bu koşullar
altında primary key'in tekrarlanmaması için bütün olasılıklar elimine edilmelidir.
Surrogate key kullanımı bu durumda bize çözüm sunar. Her bir sisteme faklı
bir seed değeri tanımlanabilir ama bu hala tam net çözümü sunmayabilir. GUID
kullanımı ise sizin performansınızı etkileyecektir. Bu durumda en mantıklı
seçenek naturel key kullanımı olacaktır.
0 yorum :
Yorum Gönder