10 Haziran 2015 Çarşamba

Key Terminolojisi İle Birlikte Surrogate Key ve Natural Key Karşılaştırılması


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önderme