ACCESS UYGULAMALARINDA YÖNETİŞİM: DOSYA YAPISI, YETKİLER VE BAKIM PLANI

Access ile hızlıca değer üreten ekipler, zamanla aynı hızın “kontrolsüz büyüme” riskini de beraberinde getirdiğini fark eder: dosyalar çoğalır, kim hangi sürümü kullanıyor belirsizleşir, yetkiler dağılır ve bakım işleri kriz moduna döner. Oysa Access uygulamalarında yönetişim, yalnızca “kural koymak” değil; sürdürülebilirlik, güvenlik ve operasyonel istikrarı birlikte tasarlamaktır.

Bu makalede, kurumsal Access çözümleri için dosya yapısı, yetki yönetimi ve bakım planı ekseninde pratik bir çerçeve sunuyoruz. Hedef; geliştirici ekiplerin değişiklikleri güvenle devreye alabilmesi, kullanıcıların doğru sürümü çalıştırması ve karar vericilerin riskleri görünür şekilde yönetebilmesidir.

Öneriler, klasik Access “tek dosya” yaklaşımından başlayıp, front-end/back-end ayrımı, sürümleme, denetim izleri ve otomasyonla desteklenen operasyon süreçlerine kadar uzanır. Her bölümde, sahada sık görülen sorunların karşılığı olan net aksiyonlar bulacaksınız.

Primary Keyword: Access uygulama yönetişimi neden kritik?

Yönetişimin hedefi: hız ile kontrolü dengelemek

Access uygulamaları genellikle iş birimlerine yakın geliştirildiği için hızlı sonuç verir. Ancak büyüdükçe; veri modeli değişiklikleri, kullanıcı sayısı, entegrasyonlar ve uyumluluk ihtiyaçları artar. Yönetişim; bu büyümenin standartlarla yönetilmesini, değişikliklerin izlenmesini ve risklerin azaltılmasını sağlar.

Tipik risk haritası: sürüm karmaşası, yetki dağınıklığı, veri kaybı

En sık görülen problemler şunlardır: aynı uygulamanın farklı kopyalarının dolaşması, kullanıcıların yanlış dosyadan çalışması, “herkes her şeye erişiyor” yaklaşımı, düzenli yedek alınmaması ve sorun çıktığında kimin neyi değiştirdiğinin bilinmemesi. Bu risklerin çoğu, doğru dosya yapısı ve süreç tasarımı ile baştan engellenebilir.

Dosya yapısı standartları: front-end ve back-end ayrımı

Front-end/back-end ayrımıyla ölçeklenebilirlik

Kurumsal kullanımda önerilen temel yaklaşım; arayüz ve iş kuralları içeren front-end (FE) ile tabloların bulunduğu back-end (BE) dosyasını ayırmaktır. Böylece FE daha sık güncellenebilir, BE ise daha kontrollü değişir. Bu ayrım aynı zamanda performans, güvenlik ve bakım kolaylığı sağlar.

Klasör ve adlandırma şeması: tahmin edilebilir düzen

Dosyaların tek bir paylaşımlı dizinde gelişigüzel durması, operasyonel karmaşa yaratır. Basit ama etkili bir şema; sürüm, ortam ve dağıtım mantığını klasör seviyesinde görünür kılar. Örnek bir yapı:

• \paylasim\Uygulamalar\Access\Uretim\ (kullanıcıların çalıştığı FE dağıtımı)
• \paylasim\Uygulamalar\Access\Paketler\ (sürümlü FE paketleri: arşiv)
• \paylasim\Uygulamalar\Access\BackEnd\ (BE dosyaları: kısıtlı erişim)
• \paylasim\Uygulamalar\Access\Dokuman\ (sürüm notları, veri sözlüğü, runbook)
• \paylasim\Uygulamalar\Access\Logs\ (uygulama logları: yazma izni kontrollü)

Adlandırmada; uygulama kodu, ortam ve sürüm bilgisini standartlaştırın. Örn: CRM_FE_1.8.3.accde, CRM_BE_Prod.accdb. Bu tutarlılık; çağrı merkezi, saha ekipleri ve BT operasyonu için ciddi zaman kazandırır.

Yetkiler ve erişim modeli: dosya sistemi + uygulama içi kontrol

Dosya sistemi izinleri: en düşük ayrıcalık yaklaşımı

Yönetişimin ilk güvenlik katmanı, dosya seviyesindeki erişimdir. Kullanıcıların FE’yi çalıştırması için okuma izni yeterliyken; BE klasörüne erişim daha sıkı olmalıdır. Genel öneri: kullanıcılar BE dosyasını göremesin, kopyalayamasın; FE üzerinden bağlı tablo kullanımıyla erişsin.

Uygulama içi rol tabanlı yetkilendirme: ekran ve işlem bazlı kontrol

Dosya izinleri, “uygulamayı açma” kontrolünü sağlar; ancak ekranlar, raporlar ve kritik işlemler için uygulama içinde rol tabanlı kontrol gerekir. Basit bir model: Kullanıcı, Rol, Yetki tabloları ve başlangıçta oturum açan kullanıcıya göre menü/komut görünürlüğü.

-- Örnek tablo taslağı (Access SQL mantığıyla)
CREATE TABLE T_Kullanici (
  KullaniciAdi TEXT(255) NOT NULL,
  Aktif YESNO,
  PRIMARY KEY (KullaniciAdi)
);

CREATE TABLE T_Rol (
  RolKodu TEXT(50) NOT NULL,
  RolAdi  TEXT(255),
  PRIMARY KEY (RolKodu)
);

CREATE TABLE T_KullaniciRol (
  KullaniciAdi TEXT(255) NOT NULL,
  RolKodu TEXT(50) NOT NULL
);

CREATE TABLE T_Yetki (
  YetkiKodu TEXT(80) NOT NULL,
  Aciklama TEXT(255),
  PRIMARY KEY (YetkiKodu)
);

CREATE TABLE T_RolYetki (
  RolKodu TEXT(50) NOT NULL,
  YetkiKodu TEXT(80) NOT NULL
);

Bu modelde, ekran açılışlarında veya kritik buton tıklamalarında “yetki var mı?” kontrolü yapılır. Bu yaklaşım; denetlenebilirlik sağlar ve “kim hangi işlemi yapabilir?” sorusunu netleştirir.

Sürüm yönetimi ve dağıtım: tek doğru sürüm prensibi

ACCDE kullanımı ve kilitli dağıtım

Üretimde, mümkün olduğunda ACCDE dağıtımı tercih edin. Böylece VBA kodu derlenir, kullanıcı tarafında tasarım değişiklikleri sınırlanır ve “dosyayı kurcaladım bozuldu” vakaları azalır. Geliştirme ise ayrı bir kaynak dosyada sürdürülmelidir.

Otomatik güncelleyici yaklaşımı: kullanıcıya yük bindirmeden güncelleme

Kurumsal Access çözümlerinde en pratik yöntem; küçük bir “launcher” veya başlangıç kontrolü ile FE’nin sürümünü doğrulamak ve gerekirse paylaşımlı dizinden güncel paketi kullanıcı makinesine kopyalamaktır. Böylece ağ üzerinden tek bir FE ile çalışmanın neden olduğu kilitlenme ve performans sorunları azaltılır.

' VBA: Başlangıçta sürüm kontrolü ve kullanıcıya yerel kopya önerisi (örnek)
Option Compare Database
Option Explicit

Public Const APP_VERSION As String = "1.8.3"

Public Sub App_Startup()
    On Error GoTo EH

    Dim currentUser As String
    currentUser = Environ$("USERNAME")

    ' Basit sürüm doğrulama (isterseniz tabloda da tutabilirsiniz)
    If Nz(DLookup("Deger", "T_Ayar", "Anahtar='MinSurum'"), APP_VERSION) > APP_VERSION Then
        MsgBox "Uygulama sürümünüz eski. Lütfen güncel sürümü kullanın.", vbExclamation
        DoCmd.Quit
        Exit Sub
    End If

    ' Log örneği
    Call LogYaz("STARTUP", "User=" & currentUser & ", Version=" & APP_VERSION)

    Exit Sub
EH:
    Call LogYaz("ERROR_STARTUP", Err.Number & " - " & Err.Description)
    MsgBox "Başlatma sırasında hata oluştu. Destek ekibine iletin.", vbCritical
    DoCmd.Quit
End Sub

Public Sub LogYaz(ByVal eventCode As String, ByVal message As String)
    On Error Resume Next
    CurrentDb.Execute "INSERT INTO T_Log(EventKodu, Mesaj, Zaman) VALUES (" & _
                     "'" & Replace(eventCode, "'", "''") & "'," & _
                     "'" & Replace(message, "'", "''") & "'," & _
                     "Now())"
End Sub

Yukarıdaki örnek, minimum sürüm kontrolü ve log altyapısının nasıl konumlanabileceğini gösterir. Kurumsal seviyede; paketleme, sürüm notu üretimi, geri dönüş planı ve dağıtım raporlama adımları eklenmelidir.

Bakım planı: yedekleme, sıkıştırma-onarma, indeks ve performans

Düzenli yedekleme ve geri dönüş senaryoları

Bakım planının omurgası; düzenli ve test edilmiş yedeklemedir. BE dosyası paylaşımlı bir dizinde duruyorsa, dosya kilidi ve tutarlılık için yedekleme zamanını düşük kullanım saatlerine planlayın. Yedeklerin saklama politikası (ör. günlük 14 gün, haftalık 8 hafta, aylık 12 ay) karar verici seviyesinde netleşmelidir.

Compact & Repair ve veri bütünlüğü kontrolleri

Access veritabanlarında zamanla şişme, geçici alan birikimi ve indeks parçalanması görülebilir. Düzenli “compact & repair” rutini, performansı iyileştirir. Bunun yanında; kritik tablolar için satır sayısı sapması, boş anahtar alanı, referans tutarlılığı gibi kontrolleri bir “gece işi” olarak tasarlamak iyi sonuç verir.

Performans gözlemi: sorgu süreleri ve kilitlenme sinyalleri

Performans sorunlarını “kullanıcı şikâyeti” başlamadan yakalamak için, ağır sorguların çalışma süresini loglayın. Ayrıca ağ gecikmesi, aynı tabloda yoğun yazma ve yanlış kilit modu gibi durumlar “ara ara donuyor” şikâyetlerine neden olur. Bu tür sinyaller, loglarla görünür olduğunda çözüm süresi dramatik şekilde düşer.

Değişiklik yönetimi: test, onay ve kayıt izleri

Geliştirme-test-üretim ayrımı: küçük ekipler için bile mümkün

“Biz küçük ekibiz, ortama gerek yok” yaklaşımı, üretimde sürpriz riski doğurur. Minimum seviyede; geliştirme (DEV) ve üretim (PROD) ayrımı kurun. Test için ayrı BE kopyası veya maskeleme yapılmış veri seti kullanın. Değişikliklerin üretime çıkışı; sürüm notu, onay ve geri dönüş adımıyla birlikte standart hale gelsin.

Denetim izleri: kim, ne zaman, neyi değiştirdi?

Kurumsal yönetişimde en çok aranan cevaplardan biri budur. Access’te, kritik tablolarda değişiklik izini tutmak için; ekleme/güncelleme/silme olaylarında kullanıcı, zaman, eski değer-yeni değer bilgilerini bir audit tablosuna yazabilirsiniz. Bu hem iç denetim hem de operasyonel hata ayıklama açısından güçlü bir kaldıraçtır.

Dokümantasyon ve runbook: sürdürülebilir operasyon

Minimum dokümantasyon seti: veri sözlüğü, bağımlılıklar, acil durum adımları

Dokümantasyonun amacı, geliştiricinin “hafızası” olmak değil; ekibin büyümesi, devir teslim ve kriz yönetimi için net bir referans oluşturmaktır. Minimum set şunları içermelidir: tablo/alan açıklamaları (veri sözlüğü), kritik sorgular ve raporlar, entegrasyon noktaları, sürüm notları ve “sistem çalışmıyor” anında izlenecek adımlar.

Bu çerçeveyi daha ileri taşıyıp Access projelerini kurumsal geliştirme disiplinleriyle hizalamak isterseniz, İleri Access Eğitimi içeriği; mimari, performans, güvenlik ve bakım konularını uçtan uca ele alır.

Pratik kontrol listesi: ilk 30 günde uygulanacak adımlar

Hızlı kazanımlar: en çok etkileyen 10 madde

1. FE/BE ayrımını tamamlayın ve BE klasör izinlerini daraltın.
2. Üretimde ACCDE dağıtımına geçin; geliştirmeyi kaynak dosyada tutun.
3. Tek sürüm prensibi için sürüm numarası ve paket klasörü standardı belirleyin.
4. Başlangıçta minimum sürüm doğrulaması ve log altyapısını kurun.
5. Yedekleme takvimi ve geri dönüş senaryosunu yazılı hale getirin.
6. Compact & repair periyodunu belirleyin ve düşük kullanım saatlerine koyun.
7. Rol tabanlı yetkilendirme tablosunu çıkarın; kritik ekranları bağlayın.
8. Değişiklik onay adımı ve sürüm notu şablonu tanımlayın.
9. Audit ihtiyacı olan tabloları seçin ve temel izleme alanlarını ekleyin.
10. Runbook’u oluşturun: hata durumunda kimin, hangi adımları izleyeceği net olsun.

Bu adımlar, Access uygulamalarında yönetişimi “doküman” olmaktan çıkarıp, yaşayan bir işletim modeline dönüştürür. Sonuç; daha az kesinti, daha hızlı sorun çözümü ve büyüyen ihtiyaçlara karşı daha sağlam bir temel olur.