Veritabanı Tasarımı: Yazılımın Görünmeyen Temeli

Bir yazılımı değerlendirirken genellikle ekranlara bakarız: Menü nerede, butonlar nasıl, raporlar ne kadar şık. Oysa iki yıl sonra “Bu raporu neden alamıyoruz?” ya da “Sistem neden bu kadar yavaşladı?” sorularının cevabı çoğu zaman ekranlarda değil, kimsenin görmediği veritabanı katmanındadır. Veritabanı tasarımı, verilerinizin hangi tablolarda, hangi kurallarla ve birbirine nasıl bağlı olarak saklanacağının planlanmasıdır. Bu yazıda iyi bir tasarımın neden önemli olduğunu, temel kavramları ve sık yapılan hataları teknik olmayan bir dille anlatıyorum.

Veritabanı tasarımı neden bu kadar önemli?

Bir binada tesisat ve taşıyıcı sistem nasıl sonradan kolayca değiştirilemiyorsa, veritabanı yapısı da yazılım çalışmaya başladıktan sonra değiştirilmesi en zor katmandır. Ekranlar yeniden tasarlanabilir, kod yeniden düzenlenebilir; ama binlerce kaydın bulunduğu bir yapıyı değiştirmek dikkat, zaman ve risk gerektirir.

İyi bir veritabanı tasarımı size şunları kazandırır:

• Tutarlı veri: Aynı müşteri iki farklı isimle kaydedilmez, silinen bir ürün eski siparişleri bozmaz.
• Esnek raporlama: Bugün aklınıza gelmeyen bir soruya yarın kolayca cevap verebilirsiniz.
• Hız: Kayıt sayısı arttığında da ekranlar ve raporlar hızlı açılır.
• Kolay büyüme: Yeni bir şube, yeni bir ürün tipi ya da yeni bir kullanıcı rolü eklemek yapıyı bozmaz.

Temel kavramlar: tablo, ilişki ve anahtar

Veritabanını birbirine bağlı Excel sayfaları gibi düşünebilirsiniz; ama bu sayfalar katı kurallarla birbirine bağlanır. Basit bir sipariş sistemi örneğinde yapı şöyle olabilir:

Tablo	Ne tutar?	Bağlantısı
musteriler	Ad, telefon, e-posta, adres	Bir müşterinin birden çok siparişi olur
urunler	Ürün adı, stok kodu, güncel fiyat	Bir ürün birçok siparişte yer alır
siparisler	Tarih, durum, müşteri numarası	Her sipariş bir müşteriye bağlıdır
siparis_kalemleri	Sipariş, ürün, adet, satış anındaki fiyat	Siparişle ürünü birbirine bağlar

Her tablodaki kaydın benzersiz bir kimlik numarası vardır; buna birincil anahtar denir. Başka bir tablodaki kayda verilen referansa ise yabancı anahtar denir. Örneğin siparisler tablosu müşterinin adını değil, yalnızca numarasını tutar. Müşteri telefonunu değiştirdiğinde bu bilgi tek yerde güncellenir ve tüm siparişlere yansır.

Tablodaki küçük bir ayrıntıya dikkat edin: Sipariş kalemi, ürünün satış anındaki fiyatını ayrıca saklar. Ürün fiyatı yarın değişse bile geçmiş siparişlerin tutarı bozulmaz. İyi tasarım, bu tür iş kurallarını baştan yakalamakla ilgilidir.

Normalizasyon ve indeksler

Normalizasyon: her bilgi tek yerde

Normalizasyon, aynı bilginin birden fazla yerde tekrar edilmemesi için tabloların düzenlenmesidir. Excel’den gelen işletmelerde sık gördüğüm durum, her satış satırında müşterinin adının, adresinin ve telefonunun tekrar yazılmasıdır. Bir müşteri adres değiştirdiğinde yüzlerce satırı düzeltmek gerekir ve bir kısmı mutlaka gözden kaçar. Bu geçişin pratik tarafını Excel yerine yazılım yazısında ele aldım.

Bununla birlikte normalizasyonun da bir dengesi vardır. Raporlama hızının kritik olduğu bazı durumlarda bilinçli olarak özet tablolar tutulabilir. Önemli olan bunun bilinçli bir karar olmasıdır.

İndeksler: kitabın fihristi

İndeks, veritabanının aradığı kaydı tüm tabloyu taramadan bulmasını sağlayan yapıdır; bir kitabın sonundaki fihrist gibi çalışır. Telefon numarasıyla müşteri arama ya da tarihe göre sipariş listeleme gibi sık yapılan sorgular için doğru indeksler tanımlanmazsa, kayıt sayısı arttıkça sistem fark edilir şekilde yavaşlar. Gereksiz indeks ise kayıt eklemeyi yavaşlatır; bu yüzden indeksler gerçek kullanım senaryolarına göre belirlenmelidir.

Veritabanı tasarımında sık yapılan hatalar

İnceleme yaptığım projelerde en sık karşılaştığım sorunlar şunlar:

1. Para tutarlarını yanlış veri tipinde saklamak: Ondalıklı sayılar için kayan noktalı tip kullanmak kuruş farkları yaratır; tutarlar kesin ondalık tiplerle tutulmalıdır.
2. Kayıtları gerçekten silmek: Silinen bir müşteri ya da ürün, geçmiş raporları bozabilir. Çoğu zaman kaydı pasife almak daha doğrudur.
3. Değişiklik geçmişi tutmamak: Kimin hangi kaydı ne zaman değiştirdiği bilinmezse hataların kaynağı bulunamaz.
4. Tutarsız isimlendirme: Aynı kavram bir tabloda “musteri_id”, diğerinde “cari_no” olarak geçerse bakım zorlaşır.
5. Kişisel verileri gereğinden fazla saklamak: KVKK açısından yalnızca gerekli verilerin tutulması ve hassas alanların korunması önemlidir. Hukuki ayrıntılar için bir uzmana danışmanızı öneririm.

Bu hataların çoğu zamanla teknik borca dönüşür ve her yeni geliştirmenin maliyetini artırır. Konuyu yazılım teknik borç yazısında ayrıca anlattım. Hangi veritabanı sisteminin seçileceği de tasarımın bir parçasıdır; bu kararın ayrıntıları için MySQL mi PostgreSQL mi yazısına göz atabilirsiniz.

Bu işi nasıl birlikte yaparız?

Yeni bir yazılımda ya da mevcut bir sistemin iyileştirilmesinde veritabanı tarafını şöyle ele alıyorum:

1. İş süreçlerini dinleme: Hangi bilgileri tuttuğunuzu, hangi raporlara ihtiyaç duyduğunuzu ve iş kurallarınızı örnek belgeler üzerinden birlikte çıkarıyoruz.
2. Veri modeli ve teklif: Tabloları ve ilişkileri gösteren bir şema hazırlıyor, kapsamı ve varsa veri aktarımını teklife yazıyorum.
3. Geliştirme ve test: Yapıyı gerçekçi miktarda örnek veriyle test ediyor, sık kullanılan sorguların hızını ölçüyorum.
4. Teslim ve destek: Mevcut verilerinizi yeni yapıya taşıyor, yedekleme düzenini kuruyor ve şema belgesini size teslim ediyorum.

Verilerinizi sağlam bir yapıya kavuşturmak isterseniz iletişim sayfasından bana ulaşabilirsiniz.

Sık sorulan sorular

Veritabanı tasarımı ne kadar sürer?

Projenin büyüklüğüne ve iş kurallarının karmaşıklığına bağlıdır. Küçük bir sistemde birkaç günlük analiz yeterli olurken çok modüllü yazılımlarda tasarım, geliştirmeyle birlikte aşamalı olarak ilerler.

Mevcut verilerimi yeni sisteme taşıyabilir miyim?

Evet. Excel dosyaları ya da eski bir yazılımdaki veriler temizlenip eşleştirildikten sonra yeni yapıya aktarılabilir. Bu süreçte tekrar eden ve hatalı kayıtlar da düzeltilir.

Kötü tasarlanmış bir veritabanı sonradan düzeltilebilir mi?

Düzeltilebilir, ancak canlı veri üzerinde çalışıldığı için dikkatli planlama ve kademeli geçiş gerekir. Bu yüzden tasarımı baştan doğru yapmak her zaman daha ekonomiktir.

Veritabanı tasarımı bulut ya da yerel sunucu seçimini etkiler mi?

Doğrudan etkilemez; iyi tasarlanmış bir yapı her iki ortamda da çalışır. Sunucu seçimi daha çok erişim, yedekleme ve maliyet ihtiyaçlarına göre yapılır.

Sonuç

Veritabanı tasarımı göze görünmez ama yazılımınızın hızını, raporlarını ve büyüme kapasitesini belirleyen temeldir; bu temele baştan biraz zaman ayırmak, ileride çok daha büyük maliyetlerin önüne geçer. Projenizin veri yapısını birlikte planlamak isterseniz bana yazabilirsiniz.