Enginær projesi için daha önceden geliştirmelere başlamıştım. Bununla ilgili olarak bazı yazılar yazmanın zamanı geldi. İlk yazı tabloların arasındaki ilişkilerin sınıflara nasıl dönüştürüleceği ile ilgili…

Temel olarak veri tabanı mantığını biliyor olmanız yazıdaki bazı kavramları çok daha iyi anlamanıza olanak sağlayacaktır. Ancak yine de elimden geldiğince açıklayıcı olarak yazmaya çalışacağım.

Veri tabanları üzerinden tabloların arasındaki ilişkiler söz konusu olduğunda ilk aklımıza Key dediğimiz kavramın gelmesi lazım. Key; bir tablonun tekil ve boş olamayan tanımlayıcısı olarak düşünebiliriz. Bir tablodaki Key bir alan veya birden fazla alandan oluşabilir. Tekil olduğunda Primary Key, birden fazla alandan oluştuğunda adına Composite Key denir. Bu keylerin dışında olan ve bir Primary Key veya Composite Key ‘ın hedef olduğu tablodaki tek bir alan olarak tarif edilen Foreign Key dir. Çok temel olarak bilgileri vermeye çalıştım.

Tablolara arasındaki ilişkiler tablodaki alanların Key olup olmadığıyla ilgili olarak değişir.

Bire Bir İlişki

One to One Relation

One to One Relation

Bir tablodaki Primary Key ile başka bir tablodaki Primary Key arasında kurulan ilişkiye Bire bir ilişki veya One-to-One ilişki denir. Bu tarzda olan bir tabloların sınıfa dönüştürülmesi için iki yöntem vardır. Bir tanesi sınıflar arasında katılım kullanarak sanki tek bir varlık varmış gibi kullanmaktır. Bunun dezavantajı CRUD (Create – Retrieve – Update – Delete) işlemlerinde kullanılacak mantığı karmaşık olması ve obje memorye yüklendiği zaman daha fazla yer kaplayacak olmasıdır.

Bunu dışındaki seçenek – Enginær projesi içinde de kullanılan şekliyle – iki farklı sınıf tanımlayıp aralarında istendiği zaman yüklenebilecek bir özellik olarak eklenmesi daha efektif olacaktır.

One to One Class Diagram

One to One Class Diagram

Bire bir ilişkinin snıflara dönüştürülmüş hali görselde gösterilmiştir. Tablo anının sonuna Child eklenmesi yazılımı geliştirecek kişiler için daha anlaşılır olabilir.

Kod geliştirirken bu şekilde yapılması AccountEntity objesi üzerinden tek adımla AccountPreferenceEntity üzerine ulaşılmasını sağlayacaktır. Burada iki alanında Primary Key olması performans için bir düzenleme ihtiyacı gerektirmeyecektir.

Buna ek olarak bir AccountPreferenceEntity üzerine eklenecek bir AccountParent özelliği ile karşılıklı ve döngüsel bir ilişki kurulabilir. Bu tabi ki yazılımcının seçeneğine göre değişebilir.

Bire Çok İlişki

Bunun dışında tabloların arasındaki ilişki bir Primary Key ve Foreign Key üzerinden olabilir. Buna Bire Çok veya One-to-Many ilişki denir. Bunun kod tarafına yansıması bir sınıf içinde liste olarak gösterilmesi olabilir.

One to Many Relation

One to Many Relation

One-to-Many ilişkilerde gösterim yukarıdaki gibidir. Görselde gösterilen * değeri bir çoklu olduğunu gösterir. Sözlü olarak söylenişi de; bir account kaydı için birden çok message olabilir şeklindedir. Bunun tam tersinden gösterildiğinde buna Çoka Bir veya Many-to-One ilişki denir. Bu ilişkinin One-to-Many olarak düşünülmesi koda dönüşmesi sırasında çok daha kolay anlaşılmasını sağlayacaktır.

Tablolar arasındaki ilişki direk gözükmemiş olabilir. account tablosundaki id alanı ile message tablosundaki recipientId alanı eşleştirilmiştir. Yani istediğimiz aslında bir hesaba ait olan mesajların listesi dir.

One to Many Class Diagram

One to Many Class Diagram

Bire Çok ilişkilerin sınıf üzerinde gösterimi, bir sınıf üzerinde Collection ile tanımlanmaktadır. Buradaki collection kelimesi birden çok kayıt geleceğini göstermektedir. Burada çözülmesi gereken noktalardan bir tanesi yüklenmesinin isteğe bağlı olması ve yüklenirken tamamının yüklenmesi olabilir. Bunun için verileri getirirken kullanılacak bir limit sorunu çözebilir.

Kod geliştirirken tek bir bağlantıyla AccountEntity objesi üzerinden hesaba ait olan mesajlar çekilebilir. Bu noktada dikkat edilmesi gereken en önemli nokta çok az veya çok kullanılmasına göre değişebileceği gibi mutlaka bir Index eklenmesi gerekmektedir. Yapılacak Index çalışmasının message tablosu üzerindeki Foreign Key alanında yapılması doğru olacaktır.

Tablolar arasında daha farklı, karmaşık ve sınıflara dönüştürülmesi zor olan ilişkiler vardır. Bunları burada anlatmak yerine ayrı bir yazıda anlatacağım. Hem kavram karmaşası olmaması hem de arkadaşlarımın bana çok uzun yazdığım için serzenişte bulunmalarını dikkate alarak bir sonraki yazıda devam edeceğim. 🙂

Yorumlayın