İLERİ ACCESS VERİ MODELLEME

Bir satış kaydını tek bir geniş tabloya mı yazmalı, yoksa müşteri, ürün ve sipariş satırlarını ayrı tablolara bölüp ilişkilerle mi birleştirmeli? Access ile çalışan çoğu kullanıcı bu çatalda takılır: flat tablo başta hızlı görünür, normalize yapı ise ilk kurulumda zahmetlidir. Ama veri büyüdükçe ve raporlar çeşitlendikçe tablo seçimi, bakım maliyetinden sorgu hızına kadar her şeyi belirler.

1. İki Yaklaşımın Temel Farkı

Denormalize (flat) tasarımda tüm bilgiler tek bir tabloda toplanır. Bir sipariş satırının yanında müşteri adı, adresi, ürün adı, kategorisi, birim fiyatı aynı satıra yazılır. Normalize tasarımda ise her varlık (müşteri, ürün, sipariş) ayrı tabloda durur ve tablolar yabancı anahtarlarla bağlanır. Aradaki seçim ilk bakışta "kolaylık" gibi görünse de aslında veri bütünlüğü ile yazma kolaylığı arasındaki dengeyi belirler.

İlk fark, aynı bilginin kaç yerde yaşadığında ortaya çıkar:

• Flat tablo: Aynı müşteri adı, her sipariş satırında tekrar yazılır. 1000 sipariş = 1000 kopya müşteri adı.
• Normalize tablo: Müşteri adı yalnızca tblMusteri tablosunda bir kez bulunur. Sipariş tablosu sadece MusteriID tutar.

2. Bakım Açısından Karşılaştırma

Müşterinin telefonu değişti diyelim. Normalize modelde tek bir UPDATE cümlesi yeterlidir:

UPDATE tblMusteri SET Telefon = '0532...' WHERE MusteriID = 47;

Flat tabloda ise aynı müşteriye ait tüm sipariş satırlarını güncellemeniz gerekir. Eğer WHERE koşulunda bir tipo yaparsanız bazı satırlar eski, bazıları yeni telefonla kalır ve veri tutarsızlığı doğar. Bu durum özellikle uzun süre kullanılan Access dosyalarında, yıllar sonra raporlarda açıklanamayan ikilikler olarak karşınıza çıkar.

Normalize yapının bakım avantajları:

1. Tek noktadan güncelleme: bir alan, bir satır, bir UPDATE.
2. Yazım hatası riski azalır; aynı müşteri adı 3 farklı şekilde yazılamaz.
3. Yeni alan eklemek (örn. müşteri vergi numarası) tüm geçmiş satırları şişirmeden mümkündür.
4. Referans bütünlüğü ile silinmiş bir müşterinin sipariş satırlarında "hayalet kayıt" kalmasının önüne geçilir.

3. Performans: Hangi Senaryoda Kim Önde?

Performans tartışması burada ilginçleşir. "Normalize yapı yavaştır çünkü JOIN yapar" yaygın bir inanıştır ama Access'te durum nüanslıdır. Küçük ve orta ölçekli dosyalarda (yaklaşık 100 bin satıra kadar) iyi indekslenmiş normalize tablolar, dev flat tablolardan genellikle daha hızlı sorgulanır. Bunun nedeni basittir: flat tablo her satırda fazladan onlarca byte taşır, disk okuması artar ve Jet/ACE motoru daha çok sayfa getirmek zorunda kalır.

Tipik karşılaştırma:

• Tek bir müşterinin son siparişi: Normalize + indeks → milisaniyeler. Flat → tüm tabloyu tarama riski.
• Tüm satışların toplamı: Flat tabloda tek tarama yeterli, normalize yapıda hafif JOIN maliyeti var; ama doğru indekslerle fark çoğu zaman fark edilmez.
• Karmaşık raporlar (kategori × bölge × ay): Normalize yapı çapraz tablolarda çok daha esnek; flat tabloda her yeni boyut tabloya yeni sütun ekletir.

Burada kritik nokta indekslerdir. Birincil anahtarların yanı sıra yabancı anahtar sütunlarına da indeks koymadığınızda JOIN gerçekten yavaşlar; bu durumda flat tablo haksız bir avantaj kazanır. Access'te ilişkiler ekranında "Referans bütünlüğünü zorla" seçeneğini işaretlemek hem indeks hem de doğrulama getirir; ilişki türleri ve bütünlük seçeneklerinin davranışını derinlemesine incelemek için ürünün resmi dokümantasyonu kapsamlı bir başvuru kaynağı sunar.

4. Ne Zaman Denormalize Etmek Mantıklı?

Normalize yapı her şartta üstün değildir. Bilinçli denormalize edilmesi gereken durumlar:

1. Salt-okunur raporlama tabloları: Aylık özetleri tutan tablolar bilerek flat olabilir — yazma yapılmadığı için tutarsızlık riski yok.
2. Tarihsel snapshot: Fatura kesildiğinde müşterinin o anki adresi faturada saklanmalı; sonradan müşteri taşınınca eski faturanın değişmesi istenmez.
3. Çok büyük JOIN zincirleri: 6-7 tablonun her seferinde birleştirildiği bir rapor için bir "denormalize görünüm" sorgusu önbellek gibi davranabilir.

Yaygın yanılgı şudur: "Access küçük ölçekli olduğu için normalize gereksiz." Aksine, Access dosyaları zamanla şişer ve 2 GB sınırına yaklaşır. Aynı müşteri adını 500.000 satırda tekrarlamak bu sınırı çok daha hızlı doldurur. Normalize yapı, dosya boyutunu da disiplinli tutar.

5. Pratik Bir Modelleme Çerçevesi

Access'te tabloları tasarlarken şu sırayla ilerlemek hem temiz bir yapı verir hem de sonradan geri dönüşü en aza indirir:

1. Varlıkları listele: Müşteri, ürün, sipariş, çalışan — gerçek dünyadaki nesneler.
2. Her varlığa benzersiz bir kimlik ata: Otomatik Sayı (AutoNumber) tipinde birincil anahtar.
3. İlişkileri belirle: Bir müşterinin çok siparişi olabilir (1-N), bir sipariş çok ürün içerebilir (N-N → ara tablo).
4. Tekrar eden grupları ayır: Aynı alan başlığı 3 kez (Telefon1, Telefon2, Telefon3) varsa ayrı bir alt tablo gerektirir.
5. Hesaplanabilir alanları yazma: Yaş alanı tutmayın; doğum tarihinden hesaplatın. Toplam alanı tutmayın; satır × fiyattan üretin.

Bu çerçeveyi Access'te uçtan uca uygulamalı görmek isterseniz, ileri Access eğitimi içeriklerinden yararlanabilirsiniz; tablo bölme, ilişki kurma ve indeksleme konularını örnek bir veri tabanı üzerinde adım adım inceleme imkânı bulursunuz.

6. Karar Matrisi: Hangi Durumda Hangisi?

Pratik bir özet:

• İşlem (OLTP) yoğun, sık güncelleme var: Normalize. Veri bütünlüğü kritik.
• Salt rapor amaçlı, dondurulmuş geçmiş veri: Denormalize görünüm makul.
• Birden fazla kullanıcı aynı kaydı düzenliyor: Normalize. Çakışma yönetimi kolaylaşır.
• Tek seferlik veri içe aktarımı, analiz amaçlı: Flat tablo + sorgu yeterli olabilir.

Sonuçta seçim ideolojik değil pragmatiktir: yazılan veriler için normalize, okunan özetler için denormalize görünümler. Access'te bu ikisini bir arada tutmak — ana tablolar normalize, raporlama sorguları denormalize çıktı verecek şekilde — hem bakım disiplinini hem de raporlama hızını korur. Tablolarınızı kurarken "5 yıl sonra bu dosyayı kim açacak ve hangi alanı güncellemek isteyecek?" sorusuna verdiğiniz yanıt, doğru modelin yönünü gösterir.