VERİTABANI TASARIMI EĞİTİMİ

Üç yıl önce hızla yazılmış bir kullanicilar tablosu vardı: ad, soyad, adres, telefon, sipariş_listesi hepsi tek satırda. Proje büyüdü, müşteri başına ortalama 12 adres tutulmaya başlandı, telefonlar virgülle ayrıldı, raporlar yavaşladı. Bugün ekip o tabloyu refactor etmeye çalışıyor ama her dokunuş üç servisi birden kırıyor. Sorun kodda değil — kurgu daha ilk gün hatalıydı. Veritabanı tasarımı, projenin gelecekte taşıyabileceği yükün ilk gün çizilen şemada gizli olduğunu anlatan disiplindir.

Tasarımsız Başlayan Projenin Tipik Sonu

Tablo tasarımı yapmadan başlayan ekipler genelde aynı yolu izler: önce her şeyi tek tabloda toplarlar, sonra "şimdilik şu kolonu daha ekleyelim" derler, derken kolon sayısı 80'i geçer. Aynı veriyi farklı yerlerde tutmak (telefonu hem kullanıcı tablosunda hem sipariş tablosunda saklamak gibi) tutarsızlığa yol açar. Bir müşterinin numarası değişince hangi tabloyu güncelleyeceğini kimse bilmez.

Bu noktada karşılaşılan tipik belirtiler şunlardır:

• Aynı kayıt birden fazla yerde tutulduğu için güncelleme anomalileri oluşur.
• Bir kayıt silinince ilişkili veri de yanlışlıkla yok olur — silme anomalisi.
• Yeni alan eklemek için tabloya ALTER atmak prod ortamında dakikalar süren kilitlere yol açar.
• Raporlar JOIN yerine içiçe LIKE sorgularıyla yazılır; indeks işe yaramaz.
• Yeni geliştirici şemayı anlamak için üç gün harcar, sonra yanlış kolonu kullanır.

ER Model: Çözümün Başladığı Yer

Entity-Relationship (Varlık-İlişki) modeli, kod yazmadan önce dünyayı kağıt üzerinde modellemenin yoludur. Bir e-ticaret projesinde "müşteri", "sipariş", "ürün", "adres" birer varlıktır (entity). Bunlar arasındaki bağlantılar ise ilişkilerdir: bir müşterinin birden çok adresi olabilir (1-N), bir siparişte birden çok ürün, bir üründe birden çok siparişte yer alabilir (N-M). Daha fazla bilgi için kapsamlı referansı başvurulabilir.

ER diyagramı çizmenin pratik faydası şudur: tabloya bir kolon eklemeden önce o verinin kime ait olduğunu sorgularsınız. Telefon kullanıcıya mı ait, adrese mi? Eğer "ev telefonu", "iş telefonu", "acil durum telefonu" gibi çoklayacaksa zaten ayrı bir iletisim tablosu doğmuştur.

Normalizasyon: Üç Adımda Temiz Şema

Normalizasyon, tabloları belirli kurallara göre parçalama tekniğidir. İlk üç normal form çoğu proje için yeterlidir:

1. 1NF — Her hücrede tek değer olur. "0532..., 0212..." gibi virgüllü kolon yasaktır.
2. 2NF — Tablodaki tüm sütunlar birincil anahtarın tamamına bağlı olmalıdır.
3. 3NF — Birincil anahtar dışındaki sütunlar birbirine bağlı olmamalı. Şehir adı il_id üzerinden gelmeli, müşteri tablosunda tekrar etmemelidir.

Normalize edilmiş şema disk üzerinde daha az yer kaplar, güncelleme tek noktadan yapılır, JOIN ile raporlanır. Bazı raporlama senaryolarında bilinçli olarak denormalizasyon yapılır — ama bu istisnadır, başlangıç noktası değil.

Anahtarlar, İndeksler ve İlişkisel Bütünlük

İyi tasarım sadece tablo bölmek değil, ilişkileri veritabanına anlatmaktır. Foreign key tanımlamak, "bu sipariş kaydı geçersiz bir müşteri_id ile var olamaz" demektir. ON DELETE CASCADE, ON UPDATE RESTRICT gibi kurallar, uygulamada unutulan kontrolleri veritabanı seviyesinde garanti altına alır.

Birincil anahtar seçiminde tartışmalı konu doğal anahtar mı, vekil anahtar (surrogate key) mi kullanılacağıdır. T.C. kimlik numarasını birincil anahtar yapmak ilk bakışta mantıklı görünür ama kişi kimlik değiştirirse veya KVKK kapsamında veri maskelenirse şema kilitlenir. Çoğu modern projede BIGINT id vekil anahtarı tercih edilir, doğal anahtarlar UNIQUE indeksle korunur.

Tasarım Kararlarını Belgelemek

Şema dosyası kadar önemli olan diğer şey kararların yazılı olmasıdır. Üç yıl sonra "neden bu tabloyu ayrı tutmuşuz?" sorusuna cevap verecek tek şey iyi yazılmış bir tasarım dokümanıdır. Migration dosyaları kronolojik kararı tutar ama niyesini değil.

SQL sorgularıyla bu tasarımı hayata geçirmek isteyenler uygulamalı SQL eğitimi içeriğinden yararlanabilir. Şemayı doğru kurmak kadar üzerinde verimli sorgu yazmak da en az o kadar önemlidir.

Tasarımın Performansa Etkisi

Yanlış tasarlanmış bir tabloda her sorgu full table scan'e dönüşür. Doğru parçalanmış şemada ise sorgu planlayıcısı indeksleri kullanır, JOIN'ler optimize olur. Bir e-ticaret projesinde 50 milyon satırlık tek bir siparisler tablosu yerine, doğru parçalanmış ve indekslenmiş şema, aynı sorguyu 3 saniyeden 30 milisaniyeye indirebilir.

Tasarım hatalarının bedeli zamanla katlanır: ilk ay fark edilmez, ilk yıl gıcırdamaya başlar, üçüncü yıl tüm ekip refactor toplantısında oturur. Doğru tasarım pahalı değildir — pahalı olan tasarımsız başlamaktır.

Tasarıma Nereden Başlamalı?

Yeni bir projede izlenecek pratik sıra şudur: önce iş gereksinimlerini cümlelerle yazın, bu cümlelerdeki isimleri çıkarın (varlık adayları), aralarındaki fiilleri inceleyin (ilişki adayları), her varlığın özelliklerini listeleyin (öznitelikler). Sonra ER diyagramına dökün, normalize edin, ancak en son SQL'e çevirin.

Bu yaklaşım yavaş gibi görünür ama üç yıl sonra refactor toplantısı yapmamak en hızlı yöntemdir. Veritabanı tasarımı ezberle değil, pratikle öğrenilen bir disiplindir — küçük projelerde dahi ER çizmek alışkanlık haline gelmelidir.