Sql & Veritabanı İle Uygulamalar İçin Veri İskeleti Modellemesi Nasıl Yapılır?

Sql & Veritabanı İle Uygulamalar İçin Veri İskeleti Modellemesi Nasıl Yapılır?
Sql & Veritabanı İle Uygulamalar İçin Veri İskeleti Modellemesi Nasıl Yapılır?

Gereksinimler ve Ön Hazırlık

Veri modelleme sürecine başlamadan önce, projenizin ihtiyaç duyduğu araçları ve ortamı hazırlamanız gerekir. 2026 yılı itibarıyla PostgreSQL veya MySQL 9.0+ sürümleri, yüksek performans ve veri güvenliği açısından endüstri standardıdır.

  • Veritabanı Yönetim Sistemi (DBMS): PostgreSQL 17 veya MySQL 9.0 kurulu olmalıdır.
  • Modelleme Aracı: dbdiagram.io veya MySQL Workbench gibi bir ER (Entity-Relationship) diyagram aracı kullanmanız önerilir.
  • Temel Bilgi: SQL (Structured Query Language) sözdizimine ve temel normalizasyon formlarına (1NF, 2NF, 3NF) hakim olmanız gerekir.

Çalışma ortamınızı kurarken, her zaman yerel bir sunucu (Docker konteyneri üzerinden) kullanmanız, üretim ortamındaki verilerinizin güvenliğini riske atmamanız için kritiktir.

Adım 1: Varlık-İlişki (ER) Diyagramı Oluşturma

Veri iskeleti modellemesinin ilk adımı, uygulamanızdaki "varlıkları" (entities) belirlemektir. Örneğin bir e-ticaret uygulaması yapıyorsanız; Kullanıcılar, Ürünler ve Siparişler ana varlıklardır. Bu varlıkların birbirleriyle olan ilişkilerini (Bire-Çok, Çok-Çoka) kağıt üzerinde veya bir modelleme aracıyla çizmek, karmaşık hataları önceden görmenizi sağlar.

Aşağıdaki örnekte, kullanıcılar ve siparişler arasındaki "bire-çok" ilişkiyi SQL üzerinde nasıl kurgulayacağımızı görüyoruz:

-- Kullanıcılar tablosu
CREATE TABLE kullanicilar (
    id SERIAL PRIMARY KEY,
    ad VARCHAR(100) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    olusturulma_tarihi TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Siparişler tablosu
CREATE TABLE siparisler (
    id SERIAL PRIMARY KEY,
    kullanici_id INT REFERENCES kullanicilar(id) ON DELETE CASCADE,
    toplam_tutar DECIMAL(10, 2) NOT NULL,
    siparis_tarihi TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Bu kodda, kullanici_id sütunu bir "Foreign Key" (Yabancı Anahtar) olarak tanımlanmıştır. ON DELETE CASCADE kullanımı, bir kullanıcı silindiğinde ona ait siparişlerin de otomatik olarak temizlenmesini sağlar; bu, veri bütünlüğü için hayati öneme sahiptir.

Adım 2: Normalizasyon ile Veri Tekrarını Önleme

Normalizasyon, veritabanındaki gereksiz tekrarı (redundancy) azaltma işlemidir. 3. Normal Form (3NF) seviyesine ulaşmak, veritabanı performansını artırır. Örneğin, bir kullanıcının adresini her siparişe yazmak yerine, adresleri ayrı bir tabloda tutmak ve ilişkilendirmek en sağlıklı yöntemdir.

Aşağıdaki örnek, adres verisini normalleştirerek nasıl saklayacağımızı gösterir:

-- Adresler tablosu (Normalizasyon için)
CREATE TABLE adresler (
    id SERIAL PRIMARY KEY,
    kullanici_id INT REFERENCES kullanicilar(id),
    adres_metni TEXT NOT NULL,
    sehir VARCHAR(50) NOT NULL
);

Bu yapı, veritabanınızda aynı verinin defalarca saklanmasını engelleyerek hem depolama alanından tasarruf sağlar hem de güncelleme işlemlerini (update) tek bir noktadan yapmanıza olanak tanır.

Adım 3: İndeksleme Stratejileri ile Sorgu Performansı

Veri iskeleti büyüdükçe, veritabanı sorguları yavaşlayabilir. İndeksler (indexes), veritabanının bir kitabı ararken "içindekiler" kısmını kullanması gibidir. Hangi sütunlarda sık arama yapıyorsanız (örneğin email veya sipariş tarihi), o sütunlara indeks eklemelisiniz.

-- Performans için indeks oluşturma
CREATE INDEX idx_kullanici_email ON kullanicilar(email);
CREATE INDEX idx_siparis_tarihi ON siparisler(siparis_tarihi);

İndeksler okuma işlemlerini hızlandırsa da, çok fazla indeks eklemek veri ekleme (insert) ve güncelleme işlemlerini yavaşlatabilir. Bu nedenle, sadece ihtiyaç duyulan sütunlara indeks eklenmelidir.

Adım 4: Veri Tipi Seçimi ve Optimizasyon

Veri iskeleti modellemesinde kullanılan veri tipleri, uygulamanın bellek tüketimini doğrudan etkiler. Gereksiz yere TEXT kullanmak yerine, içeriği belli olan alanlar için VARCHAR(n) veya sabit uzunluklu alanlar için CHAR(n) tercih edilmelidir.

Veri Tipi Kullanım Alanı Avantajı
INT ID ve Sayısal değerler Hızlı işlem, az bellek
VARCHAR(n) İsim, Email, Başlık Esnek, yer tasarrufu
DECIMAL Para birimleri Hassas hesaplama
TIMESTAMP Tarih ve zaman Zaman dilimi desteği

Para birimleri için asla FLOAT veya DOUBLE kullanmayın; bu türler yuvarlama hatalarına neden olabilir. Her zaman DECIMAL veya NUMERIC tercih edilmelidir.

Adım 5: Güvenlik ve Veri Bütünlüğü

Veri iskeleti oluştururken güvenlik, tasarımın ayrılmaz bir parçasıdır. Kullanıcı girişleri asla doğrudan sorguya eklenmemelidir. SQL Injection saldırılarını önlemek için her zaman "Prepared Statements" (Hazırlanmış İfadeler) kullanılmalıdır.

-- Güvenli sorgu örneği (Pseudo-code)
-- Yanlış: "SELECT * FROM users WHERE email = '" + email + "';"
-- Doğru (Hazırlanmış İfade):
PREPARE get_user (text) AS SELECT * FROM kullanicilar WHERE email = $1;
EXECUTE get_user('kullanici@example.com');

Kritik Uyarı: Veritabanı şifrelerini asla kod içinde düz metin olarak saklamayın. Çevresel değişkenler (Environment Variables) kullanın. Ayrıca, üretim ortamına geçmeden önce veritabanı kullanıcı yetkilerini en düşük seviyede tutun (Principle of Least Privilege).

Adım 6: Veritabanı Migrasyonları (Sürüm Kontrolü)

2026 yılında profesyonel bir yazılım projesinde veritabanı şeması değişikliklerini manuel yapmak büyük bir hatadır. Bunun yerine Migration (Göç) araçları kullanılmalıdır. Bu araçlar, veritabanı yapınızdaki değişiklikleri kod gibi versiyonlamanızı sağlar.

-- Örnek bir migrasyon dosyası mantığı (Laravel veya benzeri frameworkler için)
ALTER TABLE kullanicilar ADD COLUMN telefon_no VARCHAR(20);

Bu yöntem, ekibinizdeki diğer geliştiricilerin veritabanı yapısını kolayca senkronize etmesine olanak tanır.

Sıkça Sorulan Sorular

Veritabanı tasarımında "Primary Key" olarak ne kullanmalıyım?

Modern uygulamalarda genellikle BIGSERIAL veya UUID (Universally Unique Identifier) tercih edilir. UUID, dağıtık sistemlerde çakışma riskini sıfıra indirdiği için 2026 standartlarında oldukça popülerdir.

İlişkisel veritabanı (SQL) mı yoksa NoSQL mi seçmeliyim?

Eğer verileriniz arasında karmaşık ilişkiler varsa ve veri tutarlılığı (ACID prensipleri) kritikse, kesinlikle SQL tabanlı bir veritabanı seçmelisiniz. NoSQL, daha çok esnek şema gerektiren büyük veri (Big Data) projeleri için uygundur.

Normalizasyon her zaman iyi midir?

Genellikle evet, ancak çok derin normalizasyon tabloları birleştirmek (JOIN) için performansı düşürebilir. Bazen performans için "denormalizasyon" (veriyi bilerek tekrar etmek) gerekebilir, ancak bu sadece çok ileri düzey performans sorunlarında başvurulması gereken bir yöntemdir.

SQL Injection nasıl kesin olarak engellenir?

Kullanıcıdan gelen hiçbir veriyi doğrudan sorgu metnine eklemeyerek. Her zaman ORM (Object-Relational Mapping) araçlarını veya Prepared Statements kullanın.

Veritabanı yedeği nasıl alınmalıdır?

Otomatik, şifreli ve farklı bir coğrafi bölgede saklanan yedekleme sistemleri (Point-in-time recovery) kullanılmalıdır. Yedeklerin düzenli olarak geri yüklenip yüklenmediği test edilmelidir.

İleri Seviye Veritabanı Performans İzleme ve Hata Ayıklama

Veritabanı iskeletiniz kurulduktan sonra, sistemin zamanla nasıl tepki verdiğini gözlemlemek kritik bir süreçtir. "Yavaş sorgu" (slow query) analizi, veritabanı darboğazlarını tespit etmek için en etkili yöntemdir. Çoğu modern veritabanı sistemi, belirli bir sürenin üzerinde çalışan sorguları log dosyalarına kaydetme yeteneğine sahiptir.

Sorgu Analizi İçin EXPLAIN Kullanımı

Bir sorgunun veritabanı motoru tarafından nasıl işlendiğini anlamak için EXPLAIN komutunu kullanmalısınız. Bu komut, veritabanının veriye ulaşmak için hangi indeksleri kullandığını ve hangi tabloları taradığını (full table scan) gösterir.

-- Sorgunun çalışma planını inceleme
EXPLAIN ANALYZE 
SELECT users.username, orders.total_amount 
FROM users 
JOIN orders ON users.id = orders.user_id 
WHERE users.created_at > '2023-01-01';

Bu komut çıktısında Seq Scan (Sıralı Tarama) ifadesini görüyorsanız, bu durum ilgili sütunlarda indeks eksikliği olduğunu ve veritabanının tüm tabloyu okumak zorunda kaldığını gösterir. Bu noktada, CREATE INDEX komutu ile performans iyileştirmesi yapmanız gerekir.

Veritabanı Deployment ve Sürekli Entegrasyon (CI/CD) Süreçleri

Veritabanı şemasını manuel olarak güncellemek, özellikle ekip çalışması yapılan projelerde veri tutarsızlıklarına yol açar. Veritabanı değişikliklerini kod gibi yönetmek (Database as Code) için migrasyon araçlarını bir CI/CD hattına entegre etmelisiniz.

Otomatik Migrasyon Stratejisi

Deployment sırasında veritabanı şemasını güncellemek için kullanılan temel prensip, her değişikliğin küçük, geri alınabilir ve versiyonlanmış scriptlerden oluşmasıdır. Aşağıdaki örnek, bir veritabanı migrasyonunun temel çalışma mantığını göstermektedir:

-- 001_create_users_table.sql
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 002_add_index_to_email.sql
CREATE INDEX idx_users_email ON users(email);

Deployment sürecinde bu scriptler, veritabanı üzerinde bir "migration_history" tablosu kontrol edilerek sırayla çalıştırılır. Eğer bir script hata verirse, sistemin otomatik olarak bir önceki kararlı duruma (rollback) dönmesi sağlanmalıdır. Bu yaklaşım, üretim ortamındaki (production) veri kaybı riskini minimize eder.

Performans Testleri İçin İpuçları

  • Sentetik Veri Oluşturma: Uygulamanızı canlıya almadan önce, veritabanını milyonlarca satır sahte veri ile doldurarak sorgu sürelerini test edin.
  • Connection Pooling: Uygulamanızın veritabanına her istekte yeni bir bağlantı açmasını engelleyin; bağlantı havuzlama (connection pooling) kullanarak mevcut bağlantıları yeniden kullanın.
  • Read-Only Replicas: Okuma ağırlıklı uygulamalarda, yazma işlemlerini ana veritabanında (master), okuma işlemlerini ise ikincil kopyalarda (replica) yaparak yükü dağıtın.

Sonuç

Sql & Veritabanı ile uygulamalar için veri iskeleti modellemesi, sağlam bir yazılımın temel taşıdır. Doğru varlık ilişkilerini kurmak, veriyi normalleştirmek ve indeksleme stratejilerini uygulamak, uygulamanızın gelecekteki büyüme potansiyelini belirler. Bu rehberde öğrendiğiniz adımları takip ederek, sürdürülebilir ve güvenli veritabanı mimarileri oluşturabilirsiniz.

Yasal Sorumluluk Reddi: Bu makalede yer alan kod örnekleri ve veritabanı stratejileri eğitim amaçlıdır. Üretim ortamında (production) herhangi bir değişiklik yapmadan önce veritabanı yedeği almanız ve güvenlik testlerini gerçekleştirmeniz zorunludur. Yazılım güvenliği, sürekli güncellenen bir süreçtir; veritabanı yazılımınızın (PostgreSQL, MySQL vb.) resmi güvenlik bültenlerini takip ediniz.

Bir sonraki adımınız, oluşturduğunuz bu veri iskeletini bir ORM (Object-Relational Mapping) aracı ile uygulamanıza entegre etmek ve veritabanı işlemlerini nesne tabanlı bir yapıda yönetmeyi öğrenmek olmalıdır.

Bu yazıya tepkinizi paylaşın:
Selin Demir

Sürdürülebilir yaşam ve kişisel verimlilik üzerine odaklanan bir içerik üreticisiyim. Zaman yönetimi ve organizasyonel ipuçları konusunda okuyuculara yol gösteriyorum.

Yorumlar (0)

Yorum Yaz