Resmi Olmayan (Pratik) Yaklaşım, genellikle oldukça kullanışlı bir veritabanı tasarımı üretir. Bu, çoğu veritabanı tasarımcısının kullandığı yöntemdir. Bir sonraki yazımda anlatmaya çalışacağım “resmi yaklaşım”, sıfırdan veritabanı oluşturmaktan çok, “resmi olmayan” yaklaşımla oluşturulan veritabanı tasarımının sınanması ve doğrulanması için kullanılır.

Lafı fazla uzatmadan anlatıma geçiyorum.

Ana Varlıkların Belirlenmesi

Her uygulama bir takım varlıklar içerir. Bu varlıkların özellikleri ve birbiriyle ilişkileri uygulamanın temelini oluşturur.  Bu aşamada sadece uygulamanın üst düzey nesneleri ile ilgilenmek gerekir. İleriye dönük bazı fikirlerinizin olması mantıklı olsada, bu aşamada, her varlığın özniteliklerini düşünmek için fazla ısrarcı ve aceleci olmayın.

Örnekler;
Ders planlama sistemi: öğretmenler, öğrenciler ve dersler…
Havayolları bilet sistemi: müşteriler, uçuş personeli, seferler, uçaklar, koltuklar, havalimanları, kapılar…
Futbol ligi: oyuncular, takımlar, sahalar, oyunlar, çalıştırıcılar, hakemler…
Sipariş sistemi: müteriler, tedarikçiler, müşteri siparişleri, satın alım siparişleri, ürünler, müşteri faturaları, depolar…

Her Ana Varlık İçin Bir Tablo Oluşturulması

Bir önceki aşamada belirlenen her ana varlık için bir tablo oluşturulur. Her tabloya, açıklayıcı ama kısa ve kolay yazılıp hatırlanan bir isim verin.

Örnek;
Satılan ürünlerin tanındığı tabloya “urun” adı verilebilir.

Her Ana Varlık İçin Bir Anahtar Seçilmesi

Ana varlıkları benzersiz bir biçimde tanımlayacak bir alan belirleyin. Bu, tablonun birincil anahtarıdır (primary key). Birincil anahtar boş olamaz ve tablodaki her kaydın farklı bir birincil anahtarı olmalıdır. Yani birincil anahtara göre kayıt sorgulaması yapıldığında sadece bir kayıt döndürmelidir.

Birincil anahtar olarak ne kullandığınız bilgisayar açısından farketmese de, varlığın doğasında bulunan ve benzersiz, tekrarsız bir özellikle tanımlamanız daha doğru olur. Yani örneğin “kitap” tablosunda, sizin belirleyeceğiniz uydurma bir alanı birincil anahtar olarak belirlemek yerine,  (eğer mümkünse) her kitabı kendilinden ve doğal olarak tanımlayan ve benzersiz olan “ISBN” ‘i (uluslararası standart kitap numarası) birincil olarak tanımlamak daha uygun olur.

Diğer taraftan kimi doğal anahtarlar, yukarıdaki kitap örneğinde olduğu gibi, birincil anahtar olarak kullanmaya pek uygun olmayabilir. Çok uzun, büyük-küçük harf duyarlı, türkçe karakterler içeren, boşluk ve noktalama içeren anahtarlar genellikle kötü veritabanı anahtarı olarak algılanır. Bu tür durumlarda, 1,2,3 gibi ya da otomatik artan bir alanı birincil anahtar olarak belirlemek daha mantıklı olur.

Her Ana Varlık Tablosuna, Varlık Özniteliklerinin Eklenmesi

Uygulamanızda tanımladığınız ana varlıkların (tabloların)özniteliklerinin belirlenmesidir. Örneğin “musteri” tablosunda, ad, adres, sehir, ulke, telefon, faks vb özellikler tabloda bir alan (saha ya da sutun da denir) olarak tanımlanır.

Bu aşamada, basılı formlar, dokümanlar, uygulamayı kullanacak olanların görüşleri vs bu konuda önemli ipuçları verir. Ancak her uygulamada farklılık göstereceğini unutmamak lazımdır. Yani bir uygulamada “musteri” tablosu, farklı özniteliklerden (alanlardan) oluşmakta iken, başka bir uygulamada daha farklı özniteliklerden oluşabilir.

Tekrarlanan Öznitelikler için Ek Tablolar Oluşturulması

Tablo özniteliklerini belirlerken, bazı alanların tekrarlanan veriler içerebildiğini göreceksiniz.
Örneğin; “kitap” tablosunu tanımlarken, “yazar” özniteliğinin (alanının) içeriğinin, bazı kayıtlarda (satırlarda) tekrarlanan bir yapıda olabileceğini görürsünüz. Bu durumda, “kitap” tablosundaki tekrarlanan “yazar” alanını, “kitap” tablosunun dışına alarak “yazar” adında ayrı bir tablo tanımlamanız gerekir.

Her Alanın (özniteliğin), Birincil Anahtarın Özniteliği Olduğundan Emin Olun

Birincil anahtarıni tablodaki her alan için mantıklı bir arama sağladığından emin olunması gerekir.

Örneğin;
uye_kodu (birincil anahtar)
uye_adi
uye_adresi
uye_grup_kodu
uye_grup_adi
şeklindeki bir “uye” tablosunda, tabloya ait olmayan alan, “uye_grup_adi” alandır. Bu alan “uye_grup” tablosunun bir alanıdır. Bir başka deyişle “uye_grup_adi” ‘nı bulmak, “uye_kodu” alanını sağlamayı gerektirmez. “uye_grup_adi” ‘nı bulmak için “uye_grup_kodu” alanını sağlamak gerekir ve dolayısı ile “uye_grup_adi” alanı, “uye_grup” tablosuna aittir. “uye_grup” tablosunun birincil anahtarı, “uye_grup_kodu” dur.

Peki belirli bir üye için üye grubu adını nasıl belirleriz? Bu durumda, “uye” tablosundaki “uye_grup_kodu” alanına bağlı olarak, “uye_grup” tablosuna bağlanarak üye kodu bilinen kaydın “uye_grup_adi” ‘nı alırız.

Tablolar Arasındaki İlişkilerin Gözden Geçirilmesi

Her bir varlığa karşılık gelecek ayrı bir tablo oluşturduk. Şimdi ise tıpkı gerçek hayatta olduğu gibi, veritabanında  da, varlıkların (yani tabloların) birbiri ile olan ilişkileri belirlenmelidir.
Bu işlem kısaca, birbiri arasında ilişki olan tabloların, ilişki tanımlaması amacıyla, ortak alanlarının belirlenmesi anlamına gelir.

Bir önceki adımdaki örnekte, “uye” tablosu ile “uye_grup” tablosu arasındaki ilişki, ortak alan olarak kullanılan “uye_grup_kodu” alanı ile sağlanır.

İki farklı tablodaki (ilişki kurmakta kullanılacak ortak) iki alan, aynı anlama sahipse, ikisine de aynı adı vermek tavsiye edilir. Yani grup kodu ile iki tablo arasında ilişki belirlerken, “grup_kodu” tablosunda “uye_grup_kodu” adını kullanırken, “uye” tablosunda “kullanıcı_grup_kodu” adını kullanmak, veritabanının çalışmasını engellemez ancak kullanımı güçleştirerek karmaşaya neden olur.

Çok genel olarak yukarıdaki şekilde özetlenbilecek “resmi olmayan (pratik) yaklaşımı” kullanarak, düzgün tasarlanmış bir veritabanı tasarımına ulaşabilirsiniz. Ancak belirmem gerekir ki, burada maddeler halinde kısaca belirttiğim husuları biraz daha ayrıntılı olarak incelemek ve iyice sindirmek gerekir. Çünkü bu adımlar, uygulanmaya kalkıldığında, her adımda belirtilen husuların sağlandığını sanıp gözünüzden kaçan noktalar olduğunun farkına varamayabilirsiniz. Örneğin “Tekrarlanan Öznitelikler için Ek Tablolar Oluşturulması” adımını, veritabanındaki tüm tablolara eksiksiz olarak uyguladığınızı düşünebilirsiniz ancak gözünüzden kaçanlar olabilir. Özellikle bir sürü tablodan oluşan büyükçe uygulamaların veritabanlarını tasarlarken her bir adım uzun uzun ve dikkatle veritabanı üzerinde çalışmayı gerektirir.

Konuya uzak olan kişilere, yukarıdaki bazı anlatımlar kafa karıştırıcı gelebilir. Ancak aslında öyle olmadığını unutmayın. Karmaşık gelen anlatımları, kavrayabilmek için kendinize zaman verin, araştırın, sorun… Kısa süre içinde kafanızda canlanacak ve tam olarak ne anlama geldiğini anlayacaksınız. Önemli olan adımların ne anlama geldiğini kavramaktan ziyade, fiili olarak veritabanı üzerinde çalışırken bu adımları tam olarak gerçekleştirebilecek konsantrasonu gösterebilmektir.

Bir sonraki yazımda “resmi yaklaşım” dan bahsedeceğim. Bu konu, yukarıda anlattıklarımdan çok farklı şeyler olmayıp, yukarıdaki adımlarla pratik bir şekilde üretilen veritabanı tasarımınızın sağlamasını yapmanızı sağlayan bir araç olarak kullanacaksınız.

Sevgilerimle

Programlamaya yeni başlayan amatör programcılar, uygulama geliştirirken  genellikle kodlar (php vs.) üzerinde dururlar. Oysa ki kod kısmı işin en son kısmı olup, öncesinde  yapılan bir takım analiz ve hazırlıklar sonucunda üretilen uygulama gereklerini, gerçekleştirmek üzere yazılır ve hangi programlama dilini kullanırsanız kullanın çok fazla farklılık göstermezler. Programlama dili değiştiğinde temel olarak değişen, yazım kurallarıdır. Yine aynı döngüleri, aynı mantıksal sınamaları, aynı karşılaştırmaları yaparsınız. Sadece yazım şekli değişir ancak temelde hangi dili kullanırsanız kullanın kodunuz aynı işleri yapar ve aynı sonuçları üretir. Tabi ki istisnaları da olmakla birlikte genel olarak durum böyledir.

Kodlama ve programlama dili konusunu çok basite indirgemek için değil, kodlamaya başlamadan önceki analiz ve planlamalara özel bir vurgulama yapmak için yazdım bunları. Yoksa tabi ki programlama dili çok önemlidir. Fakat yine de programlama dili seçimi, öncesindeki analiz çalışmalarının sonucunda yapılmalıdır.

Uygulama geliştirmenin ilk ve en önemli aşaması olan analiz ve planlama ‘nın pratikte üç önemli ayağı vardır;
* Durum tespiti ve ihtiyaç belirleme (iş analizi),
* Veritabanı tasarımı,
* Algoritma geliştirme,

Bunların herbiri, üzerinde uzun uzun ve ayrıntılı olarak çalışılması gereken ve her programcı (ya da proje yöneticisi) tarafından iyice öğrenilip uygulanılıyor olması gereken çok önemli konulardır. Bu konulardan teorik olarak bahseden ve bir takım yöntem ve kuralları vurgulayan bir sürü yazılı kaynak olmasına rağmen, asıl beceri ve bilgi, programcının zaman içinde edindiği tecrübeleri sayesinde oluşur. Yani uygulama geliştirdikçe ve özellikle kaliteli bir proje ekibi içinde  mesai yaptıkça, programcı, pratik olarak bu becerileri kazanır. Programcılık işinin literatürden ziyade usta çırak ilişkisi ile öğrenilen taraflarından birisi de budur.

Üzerinde düşünmeden hazırlanan bir veritabanı üzerinde çalışmak (sorgulama vb), zaman geçtikçe çok zorlaşabilmektedir. Örnek vermek gerekirse; gelecekte programcıdan istenen basit bir rapor, sırf veritabanı düzgün tasarlanmadığı için imkansız ya da çok zorlayıcı bir iş haline gelebilir. Bunun yanında, düzgün tasarlanmayan veritabanı, uygulamanın genişletilebilir olmasını büyük ölçüde baltalar. Örneğin ileride programcıdan istenen bir ek modül, yine sadece veritabanı düzgün tasarlanmadığı için imkansız ya da çok zorlayıcı bir iş haline gelebilir. Hepsinden önemlisi düzgün tasarlanmayan veritabanı, veri tutarsızlığı, tekrarlanan veriler gibi bir sürü çarpıklıktan oluşan bir çorbaya döner. Böyle bir veritabanı, zaman içinde, yukarıda bahsettiğim sorunların birbirini tetiklediği ve büyüttüğü bir kabus haline gelir. Programcı kendini, bitip tükenmek bilmeyen bir sürü anlamsız sorunlardan oluşan kısır bir döngü içinde bulur kendini.

İşte bu nedenle, uygulamayı kodlamaya başlamadan önce, üzerinde çalışacağınız veritabanını çok iyi tasarladığınızdan emin olmalısınız.

Bu yazımda ve devam eden birkaç yazımda, en önemli ayaklardan birisi olan “veritabanı tasarımı” konusunu ele almaya çalışacağım. Bunu yaparken teorik ve genel kabul görmüş kuralların yanında, pratik ve konununun özüne yönelik kısımlarından da bahsedeceğim.

Veritabanı tasarımı konusunda temelde iki yaklaşım mevcuttur;

Resmi Yaklaşım;

İlişkisel veritabanı oluşturulması/tasarlanması sürecinde, bir takım normalleştirme kurallarını(derecelerini) ifade eder. İlk olarak E.F.Codd tarafından kullanılan bu yaklaşım günümüzde çok geniş bir sorun yelpazesine uygulanabilir bir veritabanı modelini ortaya çıkarmıştır. Uzmanlar tarafından bir çok normalleştirme derecesinden bahsedilsede ilk beşi genel kabul görmüş ve resmileşmiştir. Ancak şahsen belirtmek isterim ki “resmi yaklaşım” olarak bahsedilen bu yöntem pratikte veritabanı tasarımı yaparken kullanmaktan ziyade, aşağıda bahsettiğim “resmi olmayan tasarımın” sınanması ve doğrulanması için kullanılır.

Resmi olmayan (pratik) yaklaşım;

Programcının zaman içinde edindiği bilgi ve deneyimleri sonucunda geliştirdiği veritabanı tasarımı yaklaşımını ifade eder. Programcıdan programcıya ufak tefek farklılıklar gösterse de, veritabanı genel olarak belli başlı adımlarla tasarlanır. Bunlar “resmi yaklaşım”dan daha pratik ve somut adımlardır.

Özetlemek gerekirse;

Resmi olmayan yaklaşımla somut olarak ortaya konan veritabanı, resmi yaklaşımla sınanarak doğrulanır. Uygulamanının veritabanı tasarımı ayağındaki genel süreç bu şekildedir.

Devam eden yazılarımda, yukarıda bahsettiğim “resmi olmayan” ve “resmi yaklaşım” bahsetmeye çalışacağım.

Sevgilerimle,

NOT: Yazının ikinci bölümü için:
Veritabanı Tasarımı-2: Resmi Olmayan (Pratik) Yaklaşım