VERİTABANI TASARIMI

Aynı şirkete iki farklı veritabanı kurmak gerekir mi, yoksa tek bir şema her şeyi taşıyabilir mi? Sipariş alan bir sistemde milisaniyelik yanıt süreleri istersiniz; aynı şirketin yöneticisi ise üç yıllık satış trendini tek sorguda görmek ister. Bu iki ihtiyaç aynı tabloda buluşmaz. Veritabanı tasarımı tam da bu noktada başlar: normalize 3NF modeli mi, yoksa denormalize OLAP yıldız şeması mı kuracağınız sorusu, projenin geri kalanını şekillendirir.

Veritabanı Tasarımı Neyi Karara Bağlar?

Veritabanı tasarımı, verinin hangi tablolarda, hangi ilişkilerle ve hangi tekrar düzeyinde saklanacağını belirleyen mühendislik kararıdır. Yalnızca tablo çizmek değil; okuma/yazma oranını, sorgu desenlerini, tutarlılık gereksinimini ve büyüme eğilimini önceden değerlendirmektir. Yanlış kurulan bir şema, sonradan indeks eklemekle düzeltilmez. Konuyu daha derinlemesine incelemek isteyenler için konuya dair temel başvuru faydalı bir başlangıç noktasıdır.

Tasarımın temelinde iki büyük iş yükü tipi vardır:

• OLTP (Online Transaction Processing): Çok sayıda küçük, anlık işlem. Sipariş ekleme, stok güncelleme, kullanıcı kaydı.
• OLAP (Online Analytical Processing): Az sayıda büyük analitik sorgu. Çeyreklik satış raporu, kohort analizi, trend hesaplama.

Bu iki dünya, aynı veri üzerinde çalışsa da farklı şema felsefelerine yaslanır.

3NF: Normalize OLTP Modelinin Mantığı

Üçüncü normal form (3NF), her bilgi parçasının yalnızca tek bir yerde tutulması ilkesidir. Müşteri adresi Musteriler tablosunda bir kez yazılır; siparişler bu müşteriye musteri_id üzerinden bağlanır. Adres değiştiğinde tek satır güncellenir, kopya kalmaz.

3NF'nin somut faydaları:

1. Tutarlılık: Aynı bilgi iki farklı yerde çelişemez çünkü iki yerde değildir.
2. Hızlı yazma: Bir INSERT veya UPDATE az sayıda satıra dokunur.
3. Disk verimliliği: Tekrar eden değerler yok, depolama küçük kalır.
4. Bütünlük kuralları: Foreign key kısıtları ilişkileri zorunlu kılar.

Maliyet tarafı da var: Bir satış raporu için 6-8 tabloyu JOIN etmek gerekebilir. OLTP için bu kabul edilebilirdir, çünkü tek bir sipariş kaydı 4-5 tabloyu okur; ama milyonlarca satır üzerinde toplama yapacak bir analitik sorgu için JOIN sayısı yıkıcı hale gelir.

Yıldız Şeması: Denormalize OLAP Modelinin Mantığı

OLAP tarafında öncelik analiz hızıdır, yazma sıklığı düşüktür. Bu yüzden veri ambarlarında yıldız şeması (star schema) kullanılır: ortada bir fact (olgu) tablosu, etrafında dimension (boyut) tabloları.

Tipik bir satış yıldızı şöyle görünür:

• FactSatis: tarih_key, urun_key, magaza_key, musteri_key, miktar, tutar
• DimTarih: tarih_key, yil, ceyrek, ay, gun, haftanin_gunu
• DimUrun: urun_key, urun_adi, kategori, marka, tedarikci
• DimMagaza: magaza_key, sehir, bolge, ulke

Kategori bilgisi, ürün adıyla birlikte DimUrun içinde tekrar tutulur. 3NF'ye göre "yanlış" sayılır; OLAP için bu kasıtlı bir tercihtir. Tek bir JOIN ile boyuta inilir, agregalar GROUP BY ile saniyeler içinde döner.

İki Model Yan Yana: Hangisi Ne Zaman?

Karar üç soruya cevap verince netleşir: Veri ne sıklıkla yazılıyor? Sorgular tek satır mı, milyon satırın toplamı mı? Tutarlılık anlık mı, gecikmeli mi olabilir?

Pratik bir kıyas:

• Okuma/yazma oranı 1:1 civarında, satır bazlı işlem: 3NF. E-ticaret sipariş motoru, banka hesap hareketi, rezervasyon sistemi.
• Okuma ağırlıklı, milyon satır agregasyonu: Yıldız şeması. Yönetim panosu, satış analitiği, pazarlama segmentasyonu.
• Karma ihtiyaç: İki ayrı veritabanı. OLTP üretim verisi gece ETL ile OLAP ambarına aktarılır.

Çoğu kurumsal sistemde son seçenek doğru olandır. OLTP'yi raporlarla yormak hem üretimi yavaşlatır hem de analistleri kısıtlı şemaya mahkûm eder. SQL tarafında JOIN, GROUP BY ve indeks davranışlarını derinleştirmek isterseniz kapsamlı SQL eğitimi içeriğinden yararlanabilirsiniz.

Tasarım Sürecinde Sırayla Yapılacaklar

Hangi modele gidilecek olursa olsun, adımlar benzerdir; fark, normalizasyon derinliğindedir.

1. İş gereksinimi çıkar: Hangi sorular soruluyor, hangi işlemler yapılıyor?
2. Kavramsal model (ER diyagramı): Varlıklar ve ilişkiler kâğıt üzerinde.
3. Mantıksal model: Tablolar, kolonlar, anahtarlar. OLTP için 3NF, OLAP için yıldız.
4. Fiziksel model: Veri tipleri, indeksler, bölümleme (partitioning), saklama parametreleri.
5. Sorgu profili doğrulaması: Beklenen sorgular örnek veri üzerinde çalıştırılır, plan incelenir.

İndeks sayısının artırılması her zaman çözüm değildir; WHERE musteri_id = ? AND tarih > ? gibi bir koşul için kompozit indeks tek bir tarih indeksinden çok daha etkili olabilir. Tasarımın doğru yapıldığı sistemlerde indeks ihtiyacı zaten azalır.

Sık Yapılan Tasarım Hataları

Veritabanı tasarımında en pahalı hatalar erken yapılır:

• Tek tabloya her şeyi koymak: "Sonra ayırırız" cümlesi, üç yıl sonra 200 kolonlu bir tablo bırakır.
• Surrogate key yokluğu: İş anahtarı (örn. TC kimlik) birincil anahtar yapılırsa, kural değiştiğinde tüm foreign key'ler kırılır.
• OLTP'de erken denormalizasyon: "JOIN yavaşmış" diye veriyi kopyalamak, güncellemelerde tutarsızlık üretir.
• OLAP'ta gereksiz normalizasyon: Yıldızı snowflake yapmak okumayı yavaşlatır, kazancı yok denecek kadar azdır.
• Boyutlarda SCD ihmali: Müşterinin şehri değiştiğinde eski raporların yanlış göstermemesi için Slowly Changing Dimension stratejisi şart.

Doğru tasarım, sistemin ömrü boyunca alınacak tek en kritik karardır. Yazılım kodu yeniden yazılır; veritabanı şeması, üzerinde milyonlarca satır biriktikten sonra zor değişir. Bu yüzden 3NF mi yıldız mı sorusunun cevabı, kod yazmaya başlamadan önce verilmelidir. SQL ve modelleme detayları için SQL öğrenme kaynağı iyi bir başlangıç noktası olabilir.