ACCESS VERİTABANI TASARIMI

Aynı sipariş verisi, aynı dosyada iki kez duruyor: bir kez herkesin ilk aklına gelen biçimde — her şey tek tabloda; bir kez de olması gereken biçimde — müşteri, ürün ve sipariş ayrı tablolarda, numaralarla bağlı. Bu yazının örnek veritabanı bilinçli olarak böyle kuruldu, çünkü veritabanı tasarımını anlatmanın en kısa yolu iki yapıyı yan yana koymaktır: neyin neden yanlış olduğunu, düzeltilmiş hâlinin yanında görürsünüz.

Tasarım, Access'in en az "Access'e benzeyen" konusudur — menü ezberi değil, düşünme biçimidir. Ama bir kez oturduğunda sorgular kolaylaşır, formlar kendiliğinden şekillenir, raporlar doğru rakam verir. Ters kurulmuş tabanın üstünde ise hiçbir sorgu güzelleşmez.

1. Tek Tablonun Bedeli

Örnek dosyadaki KotuOrnek_TekTablo, Excel alışkanlığının Access'e taşınmış hâli: müşteri ünvanı, şehri, telefonu, ürün adı, fiyatı, adedi ve tarihi — hepsi aynı satırda:

Üç kayda bakın: Demir Elektronik, Ankara ve aynı telefon numarası üç satırda da tekrar ediyor; değişen yalnızca ürün — klavye (450 TL, 20 adet), toner (950 TL, 12 adet), monitör (5.200 TL, 3 adet). Bu tekrarın üç somut bedeli var:

• Güncelleme sorunu: Müşterinin telefonu değişti; kaç satırı düzelteceksiniz? Birini atlarsanız aynı müşteri iki farklı numarayla yaşamaya başlar.
• Yazım kayması: Üç satırın birinde "Demir Elektronik", diğerinde "Demir Elk." yazıldığında filtre ve sorgular bunları iki ayrı müşteri sayar.
• Silme kazası: Müşterinin tüm siparişlerini silerseniz, müşterinin kendisi de veritabanından yok olur — çünkü ayrı bir varlığı hiç olmadı.

2. Varlıkları Ayırmak: Tasarımın İlk Sorusu

İyi tasarım, alan listesiyle değil bir soruyla başlar: bu işte hangi varlıklar var? Sipariş senaryosunda cevap üç: müşteriler, ürünler, siparişler. Kural basittir — kendi başına var olabilen ve birden çok kayıtta tekrar eden her şey kendi tablosunu hak eder.

Müşteri, siparişten bağımsız yaşar (henüz sipariş vermemiş müşteri olabilir); ürün de öyle. Sipariş ise ikisini buluşturan olaydır: "kim, neyi, ne zaman, kaç adet." Tablolar bu cümleyi yansıtır: Musteriler ve Urunler bilgiyi bir kez tutar, Siparisler yalnızca buluşmayı kaydeder. Bu yaklaşımın kuramsal zemini için veritabanı maddesi ilişkisel modelin tarihçesiyle birlikte iyi bir başlangıçtır.

3. Anahtar Çifti: Birincil ve Yabancı

Ayrılan tabloları birbirine bağlayan mekanizma anahtar çiftidir. Her tablonun kayıtlarını tek tek kimlikleyen alanı birincil anahtardır (MusteriID, UrunID, SiparisID). Başka tablonun birincil anahtarına işaret eden alan ise yabancı anahtardır: Siparisler tablosundaki MusteriID ve UrunID kolonları.

Yabancı anahtar sayesinde sipariş kaydı "Demir Elektronik" yazmaz; müşterinin numarasını taşır. Ünvan, şehir, telefon tek yerde durur — telefon değişince tek kayıt güncellenir, bütün siparişler otomatik olarak doğru bilgiye işaret etmeye devam eder. Birinci bölümdeki üç bedelin üçü de bu tek mekanizmayla ortadan kalkar.

4. Kötüden İyiye: Dönüşüm Adımları

Elinizde hâlihazırda tek tablolu bir yapı varsa, dönüşüm — literatürdeki adıyla normalizasyon — dört adımda yürür:

1. Tekrarı tespit edin: Hangi kolonlar satırdan satıra aynı değerleri taşıyor? (Örnekte: ünvan, şehir, telefon.)
2. Varlık tablolarını kurun: Tekrarlayan kolon gruplarını kendi tablolarına taşıyın; her birine Otomatik Sayı birincil anahtar verin.
3. Tekilleştirin: Var olan verideki kopyaları tek kayda indirin — "Demir Elektronik" ile "Demir Elk." aynı müşteriyse tek satır olur.
4. Bağlantıyı kurun: Ana tabloda tekrarlayan kolonların yerine yabancı anahtar kolonunu koyun ve ilişkiyi tanımlayın.

Örnek dosya bu dönüşümün "öncesi"ni ve "sonrası"nı aynı anda içerir: KotuOrnek_TekTablo öylece durur, yanında normalize Musteriler/Urunler/Siparisler üçlüsü çalışır. İki yapıda aynı soruyu deneyin — "Demir Elektronik'in toplam sipariş tutarı nedir?" — farkı sorgu kurarken hissedersiniz.

5. İlişki Şeması

Normalize yapının haritası, İlişkiler penceresinde tek bakışta okunur:

Çizgilerin uçlarındaki 1 ve sonsuz işaretleri ilişkinin yönünü söyler: bir müşteri çok sipariş verebilir, bir ürün çok siparişte geçebilir. Şema aynı zamanda canlı bir dokümantasyondur — veritabanını ilk kez açan biri, tek pencereden iş modelinin tamamını okur. Tasarımınızı birine anlatamıyorsanız, genellikle sorun anlatımda değil tasarımdadır.

6. Klasik Tasarım Hataları

Saha deneyiminin sık gösterdiği dört hata, kontrol listesi olarak:

• Anlamlı birincil anahtar: Telefon veya vergi numarasını anahtar yapmak — değişebilen hiçbir değer anahtar olmamalı.
• Kolon olarak tekrar: Urun1, Urun2, Urun3 kolonları açmak — dördüncü ürün gelince tasarım çöker; tekrar satırla çözülür, kolonla değil.
• Her şeyi metin yapmak: Tarihi ve tutarı Kısa Metin'de tutmak — sıralama, filtre ve hesap yeteneği baştan kaybedilir.
• Bilgi tutarlılığını atlamak: İlişkiyi çizip zorlamayı işaretlememek — sahipsiz sipariş kayıtları sessizce birikir.

7. Örneği İndirin

Dosyayı açın (ilk açılışta sarı güvenlik bandı çıkarsa İçeriği Etkinleştir deyin) ve iki yapıyı bilinçli olarak kıyaslayın: KotuOrnek_TekTablo'da müşteri telefonunu değiştirmeyi deneyin — kaç satıra dokunmanız gerektiğini sayın; sonra aynı işi Musteriler tablosunda tek kayıtla yapın. Ders, dosyanın kendisinde.

Tablo kurma adımlarının uygulamalı anlatımı için Access tablo oluşturma yazısı bu makalenin devamı gibi okunabilir. Tasarımdan sorguya, formdan rapora bütün zinciri sistemli kurmak isteyenler için Access eğitimi gerçek senaryolar üzerinden ilerliyor.