Katalog zur professionellen Access-Anwendung
Version 1.01 (2014-05-24) von Karl Donaubauer             Direktlink: http://www.donkarl.com/?katalog        versione italiana English version

 

Was macht die professionelle Access-Anwendung aus? Durch die Vielfalt der Anforderungen und Stile gibt es keine eindeutigen Beweise, aber Indizien bzw. Best Practices. Formal geht es nicht um ein weiteres Lehrbuch sondern um einen Stichwortkatalog mit Verweisen, der Grundwissen voraussetzt.

Er soll zum einen als Referenz dienen zur Selbsteinschätzung der eigenen Projekte sowie zur Fremdeinschätzung durch technisch informierte Dritte (Kollegen, Kunden, Gutachter). Zum anderen bietet er Richtlinien für die Arbeit von Einzelentwicklern und die Zusammenarbeit im Team.

Bei der AEK15 habe ich einen Entwurf mit 200 Kollegen diskutiert und ihre Meinung in einem Fragebogen eingeholt, s.a. die Vortragsfolien Die professionelle Access-Anwendung und Status von Access. Ich arbeite weiter an der Ausformulierung und bin offen für Feedback. Am besten im Feedback-Forum zwecks öffentlicher Diskussion.

 
1. Datenbank 2. Anwendung 3. Programmierung
1.1 Normalisierung 2.1 Frontend und Backend 3.1 VBA vor Makros
1.2 Primärschlüssel 2.2 Benennung 3.2 Benennung
1.3 Indizierung 2.3 Versionierung 3.3 Variablendeklaration
1.4 Beziehungen und RI 2.4 Ergonomie 3.4 Verweise
1.5 Benennung 2.5 Eigene Benutzeroberfläche 3.5 SQL vor DAO/ADO
1.6 Abfragen optimiert 2.6 Performance-Maßnahmen 3.6 Fehlerbehandlung
1.7 Arbeit mit ODBC-Backend optimiert 2.7 Komprimierung 3.7 Kommentare
  2.8 Tote Objekte 3.8 Formatierung
 
1. Datenbank
 
1.1 Normalisierung

Es werden mindestens die 0. bis 3. Normalform eingehalten.

0. = keine Berechnungen speichern
1. = atomarer Wert pro Feld
2. = Nichtschlüsselfelder abhängig vom kompletten Schlüssel
3. = Nichtschlüsselfelder direkt abhängig vom Schlüssel

Grund: Datenkonsistenz
Ausnahme: Performance-Optimierung
Info: AEK 7, Normalisierung, Michael Zimmermann, Wikipedia - Normalisierung

 

rauf

1.2 Primärschlüssel

Jede Tabelle hat einen Primärschlüssel.

Grund: Identifizierung bei allen Gelegenheiten, Aktualisierbarkeit

 

rauf

1.3 Indizierung

Jede Tabelle ist adäquat indiziert.

- Indizes für alle Felder und Feldkombinationen, über die verknüpft, gefiltert, sortiert wird
- Indizes sind so streng wie möglich ("Ohne Duplikate")

Grund: Performance
zulässige Ausnahmen: Performance-Optimierung, v.a. bei massenhaft INSERT, UPDATE, DELETE

 

rauf

1.4 Beziehungen und RI

- Beziehungen für Tabellen sind gesetzt.
- Referentielle Integrität ist aktiviert.
- Aktualisierungs- und Löschweitergabe ist aktiviert, wenn inhaltlich möglich/sinnvoll.

Grund: Datenkonsistenz, Überblick, Tabellendesign-Kontrolle

 

rauf

1.5 Benennung

Bezogen auf Tabellen, Abfragen, Felder, Spalten, Aliase:

- Keine SQL/VBA/Access–Schlüsselworte in benutzerdefinierten Benennungen
- Keine Leer- oder Sonderzeichen (inkl.Umlaute) in benutzerdefinierten Benennungen
- Durchgängige Benennungsregeln (Namenskonvention oder eigenes System)

Positivliste, d.h. zulässig/sinnvoll: A bis Z, a bis z, 0 bis 9, Unterstrich

Grund: Wartbarkeit, Fehlerprävention,
bei Schlüsselworten sind Probleme möglich - trotz eckiger Klammern, bei Leer- und Sonderzeichen v.a. in fremdsprachigen Umgebungen

Info: Schlüsselwortliste von Allen Browne, FAQ 1.5

 

rauf

1.6 Abfragen sind optimiert

- Indexnutzung wo immer möglich
  - Vermeidung von Table Scans
  - Nutzung der optimalen Indexvariante
  - JOINs/Filter/Sortierung über indizierte Felder
- nur benötigte Datensätze (WHERE)
- nur benötigte Spalten im SELECT
- nur notwendige Sortierungen
- D-Funktionen durch Tabelleneinbindung vermeiden

Grund: Performance

Info: AEK8, Performance in Abfragen, Michael Zimmermann

 

rauf

1.7 Arbeit mit ODBC-Backend ist optimiert

- Performancekritische Abfragen sind auf den Server verlagert
  - Pass Through-Abfragen
  - Server-Objekte nutzen Stored Procedures, Views...

 - bei ODBC-Abfragen wird lokale Verarbeitung durch JET/ACE vermieden
   - keine Access-spezifischen Funktionen
   - keine Bezüge auf Access-Objekte (Formularfelder)

Grund: Performance

Info: AEK11, Migration auf SQL Server, Bernd Jungbluth

 

rauf

 
2. Anwendung
 
2.1 Frontend und Backend

Die Anwendung ist in Frontend und Backend aufgeteilt.

- Tabellen liegen im Backend (evtl. in mehreren), alles andere im Frontend
- Jeder Nutzer erhält ein eigenes, lokales Frontend (bei Terminal Server in einem Serverordner)
- In Mehrbenutzerumgebungen wird ein Mechanismus zum Verteilen neuer Frontends verwendet
   d.h. nicht manuell auf jeden Arbeitsplatz verteilt sondern per Tool, Skript, Batch etc.

Grund: Vermeidung von Datei- und Datenkorruption, Effiziente Wartung des Frontends, weniger Netzverkehr

Info: FAQ 1.35

 

rauf

2.2 Benennung

Bezogen auf Access-Objekte, Steuerelemente:

- Keine Access/VBA/SQL–Schlüsselworte in benutzerdefinierten Benennungen
- Keine Leer- oder Sonderzeichen (inkl.Umlaute) in benutzerdefinierten Benennungen
- Durchgängige Benennungsregeln
  - Namenskonvention oder eigenes System
  - Objekt/Steuerelement-Typen sind durch Präfixe erkennbar

Positivliste, d.h. zulässig/sinnvoll: A bis Z, a bis z, 0 bis 9, Unterstrich

Grund: Wartbarkeit, Fehlerprävention
bei Schlüsselworten sind Probleme möglich - trotz eckiger Klammern, bei Leer- und Sonderzeichen v.a. in fremdsprachigen Umgebungen

Info: Schlüsselwortliste von Allen Browne, FAQ 1.5 

 

rauf

2.3 Versionierung

Es gibt ein Versionierungssystem für die Anwendung, an dem unterschiedliche Programmstände für Entwickler und Benutzer erkennbar sind.

- Mindestanforderung: Haupt- und Nebenversionsnummer für das Frontend
- Je nach Art der Anwendung Versionsnummern für alle beteiligten Dateien

Grund: Wartbarkeit

Info: Wikipedia - Versionsnummer

 

rauf

2.4 Ergonomie

ISO 9241 zur Software-Ergonomie ist grundlegend erfüllt
  - Aufgabenangemessenheit
  - Selbstbeschreibungsfähigkeit
  - Steuerbarkeit
  - Erwartungskonformität
  - Fehlertoleranz
  - Individualisierbarkeit
  - Lernförderlichkeit

Info: Wikipedia - ISO 9241AEK3, Design, Karl Donaubauer

 

rauf

2.5 Eigene Benutzeroberfläche

Der Anwender arbeitet nur in der für ihn gestalteten Benutzeroberfläche
  - sieht nur Formulare, Berichte, Menüs, Ribbons etc.
  - sieht keine Tabellen, Abfragen, Codes, Entwurfsansichten

Grund: Benutzerfreundlichkeit, Stabilität

 

rauf

2.6 Performance-Maßnahmen

Wichtige und bekannte Performance-Maßnahmen sind berücksichtigt:
  - Objektnamenautokorrektur deaktiviert
  - Unterdatenblätter deaktiviert
  - Permanentes Recordset bei JET/ACE-Backends
  - Keine D-Funktionen auf eingebundene Tabellen

Info: Performance-Webseiten von FMS und Tony Toews

 

rauf

2.7 Komprimierung

JET/ACE-Backends werden regelmäßig komprimiert, Frontends werden zumindest ab und zu komprimiert oder getauscht

Grund: Objekt- und Datenmüll wird gelöscht, Tabellen defragmentiert, Abfragestatistiken erneuert

Info: Microsoft Jet Database Engine Programmer's Guide - Chapter 4

 

rauf

2.8 Tote Objekte

- Nicht mehr in Verwendung stehende Objekte sind entfernt
- bzw. für kurze Zeit durch die Benennung klar erkennbar (z.B. zzz...) und werden so bald wie möglich gelöscht

Grund: Wartbarkeit

 

rauf

 
3. Programmierung
 
3.1 VBA vor Makros

- VBA hat Vorrang
- Makros nur in Spezialfällen
  - Autoexec
  - Autokeys
  - Datenmakros
  - Webdatenbanken

Grund: Leistungsumfang, Flexibität, Effizienz von VBA größer

 

rauf

3.2 Benennung

Bezogen auf Prozeduren, Variablen, Konstanten:

- Keine VBA/Access/SQL–Schlüsselworte in benutzerdefinierten Benennungen
- Keine Umlaute in benutzerdefinierten Benennungen
- Durchgängige Benennungsregeln
  - Namenskonvention oder eigenes System
  - Datentypen sind durch Präfix erkennbar

Positivliste, d.h. zulässig/sinnvoll: A bis Z, a bis z, 0 bis 9, Unterstrich

Grund: Wartbarkeit, Fehlerprävention

Info: Schlüsselwortliste von Allen Browne, Reddick Namenskonventionen

 

rauf

3.3 Variablendeklaration

Alle Variablen sind mit Datentypen deklariert
- Option "Variablendeklaration erforderlich"
- "Option Explicit" in jedem Modul

Grund: Wartbarkeit, Fehlerprävention

 

rauf

3.4 Verweise

Die Verweise sind auf die tatsächlich im Programm verwendeten reduziert.

Grund: Fehlerprävention, Performance

Info: FAQ 7.1

 

rauf

3.5 SQL vor DAO/ADO

Für Datenoperationen werden Abfragen/SQL verwendet, außer Programmierung per DAO/ADO ist nötig, z.B. bei Schleifen mit Zwischenspeicherung oder Berechnungen

Grund: Performance bei Massenoperationen, Sperrung durch Recordsets, Fehlerprävention – Code ist potentiell fehlerträchtig

 

rauf

3.6 Fehlerbehandlung

Ausreichende Fehlerbehandlung ist vorhanden
- in der Runtime in jeder Prozedur

Grund: Stabilität, Benutzerfreundlichkeit

Info: MZ-Tools, vbWatchdog

 

rauf

3.7 Kommentare

Code ist ausreichend kommentiert
- zu Beginn nicht trivialer Prozeduren ist ihr Zweck erläutert
- alle nicht trivialen Codestellen soweit, dass sie ein sachkundiger Entwickler versteht

Grund: Wartbarkeit

 

rauf

3.8 Formatierung

Code ist lesefreundlich formatiert
- Einrückungen zur horizontalen Gliederung bei Schleifen, Kontrollstrukturen etc.
- Leerzeilen zur vertikalen Gliederung nach inhaltlichen Kriterien
- Zeilenumbrüche bei überlangen Zeilen

Grund: Wartbarkeit

rauf