Microsoft Access validieren: vom Datenmodell zum verlässlichen Ergebnis

1. Den konkreten Access-Einsatz und seine Grenzen beschreiben

Dieser Artikel behandelt Access-Desktop-Anwendungen. Die ausgewerteten Microsoft-Supportseiten nennen unter anderem Access für Microsoft 365 sowie Access 2024 und 2021. Sie sind keine Aussage, dass jeder ältere, ebenfalls aufgeführte Produktstand noch unterstützt wird. Erfassen Sie deshalb die tatsächlich installierte Version, den Updatekanal, 32- oder 64-Bit-Ausführung und verwendete Bibliotheken. Das Dateiformat allein beschreibt die Anwendung nicht ausreichend.

Bei einer geteilten Datenbank liegen Tabellen im Backend; das lokale Frontend enthält beispielsweise Abfragen, Formulare und Berichte. Alternativ kann Access auf SQL Server zugreifen. Microsoft unterscheidet dabei Verknüpfung und Import: Eine Verknüpfung verbindet die Datenbestände, ein Import erstellt eine einmalige Kopie. Für Ihre Prüfung ist entscheidend, welchen Stand ein Ergebnis tatsächlich verwendet.

Benennen Sie den Prozess konkret, etwa die Zusammenstellung freigegebener Prüfergebnisse für eine Qualitätsbewertung. Grenzen Sie Excel-Dateien und eigenständige VBA-Lösungen als angebundene Komponenten ab. Gemeinsame Programmiersprache bedeutet keine identische Architektur. Eine Excel-Validierung deckt das Access-Datenmodell und dessen Zugriffswege nicht automatisch mit ab.

Quellen: [1] [2] [3]

2. GxP-Relevanz aus der Verwendung ableiten

Nicht jede Access-Datenbank benötigt denselben Validierungsumfang. Untersuchen Sie, welche fachliche Entscheidung von ihren Daten abhängt, ob sie vorgeschriebene Aufzeichnungen führt und wo Fehler entdeckt würden. Eine unverbindliche Kontaktliste hat einen anderen Einfluss als ein Bericht, der ungeklärte Prüfergebnisse aus einer Chargenbewertung ausblenden könnte. Auch eine kleine Anwendung kann einen kritischen Prozessschritt unterstützen.

Die regulatorischen Beispiele beziehen sich auf Humanarzneimittel-GMP. Annex 11 ist hier die GMP-Leitlinie für computergestützte Systeme; die Kommission führt im einschlägigen Verzeichnis weiterhin die Revision Januar 2011. Andere Branchen und Regelbereiche sind gesondert zu bestimmen. Für FDA Part 11 prüfen Sie zusätzlich die zugrunde liegenden FDA-Aufzeichnungspflichten und die tatsächliche elektronische Verwendung. Weder Access noch das Wort Datenbank löst pauschal jede Anforderung aus.

Als Arbeitsgrundlage genügen zunächst ein klarer Verwendungszweck, die betroffenen Daten und eine Beschreibung möglicher Fehlentscheidungen. Daraus entstehen prüfbare Anforderungen. Herstellerdokumentation hilft beim Verständnis technischer Funktionen; die Eignung Ihrer eigenen Tabellen, Abfragen und Arbeitsabläufe muss davon getrennt nachgewiesen werden. Eine feste GAMP-Kategorie lässt sich aus dem Produktnamen nicht ableiten.

Quellen: [11] [12] [13]

3. Schlüssel, Beziehungen und Datenverantwortung festlegen

Beginnen Sie mit den fachlichen Objekten: Probe, Prüfung, Ergebnis und freigegebener Bewertungsstand dürfen nicht unbemerkt ineinander übergehen. Legen Sie fest, welcher Schlüssel einen Datensatz eindeutig bezeichnet, welche Felder Pflicht sind und wie Korrekturen zugeordnet werden. Ein zusätzliches Ergebnis kann eine zulässige Wiederholungsprüfung oder eine unerlaubte Dublette sein. Diese Unterscheidung muss die Anwendung fachlich abbilden.

Microsoft beschreibt referenzielle Integrität als Schutz vor verwaisten Beziehungen. Sie ist an Voraussetzungen gebunden und lässt sich im Access-Frontend nicht einfach für beliebige verknüpfte Tabellen erzwingen. Bei einem Access-Backend wird sie dort eingerichtet; bei anderer Datenhaltung sind deren Kontrollen zu prüfen. Kaskadierende Löschungen oder Aktualisierungen sind bewusst zu bewerten, weil sie abhängige Datensätze verändern können.

Die folgende eigene Arbeitshilfe verbindet Architekturentscheidungen mit Prüfnachweisen. Sie ersetzt keine Spezifikation. Ergänzen Sie für jede Zeile den Verantwortlichen und die Stelle, an der die Kontrolle tatsächlich wirksam ist. So vermeiden Sie, dass eine Formularprüfung als Schutz für alle anderen Schreibwege vorausgesetzt wird.

Quellen: [6]

4. Abfragen, Berechnungen und VBA fachlich prüfen

Access-Joins bestimmen, welche Datensätze zusammengeführt werden. Ein innerer Join liefert nur passende Kombinationen; ein äußerer Join kann auch Datensätze ohne Partner erhalten. Bei mehreren passenden Zeilen kann ein fachlicher Ausgangsdatensatz mehrfach im Ergebnis erscheinen. Eine formal erfolgreiche Abfrage beweist deshalb weder Vollständigkeit noch korrekte Gewichtung einer Kennzahl.

Erstellen Sie einen überschaubaren Referenzdatensatz, dessen Ergebnis unabhängig berechnet wurde. Prüfen Sie Filter, Zeitraumgrenzen, Nullwerte, Rundung, Einheiten und den Unterschied zwischen fehlendem Wert und Null. Kontrollieren Sie zusätzlich den ausgegebenen Bericht: Werden dieselben Filter verwendet? Sind ausgeschlossene Datensätze erkennbar? Bleibt der zugrunde liegende Datenstand auffindbar, wenn später korrigiert wird?

Bei VBA verfolgen Sie den tatsächlich durchlaufenen Pfad vom Formularereignis bis zur Datenänderung. Beziehen Sie Fehlerbehandlung, abgebrochene Importe und wiederholte Ausführung ein. Dokumentieren Sie den getesteten Code- und Frontendstand. Die fachliche Sollrechnung muss unabhängig vom gleichen Code entstehen; zwei Ausgaben derselben fehlerhaften Funktion sind kein unabhängiger Vergleich. Reine Oberflächenprüfungen reichen für eine versteckte Berechnungsregel nicht aus.

Quellen: [7] [11]

5. Rechte, Runtime und Makrovertrauen auseinanderhalten

Die früheren benutzerbezogenen Access-Sicherheitsfunktionen stehen für .accdb und .accde nicht zur Verfügung. Microsoft verweist unter anderem auf Datenbankserver mit eigener Benutzerverwaltung. Prüfen Sie daher Datei- und Ordnerrechte sowie gegebenenfalls SQL-Server-Berechtigungen. Eine selbst gebaute Anmeldemaske ist nur dann wirksam, wenn die relevanten Datenzugriffe tatsächlich durch die vorgesehenen Kontrollen begrenzt bleiben.

Eine .accde schränkt Entwurfs- und Codeänderungen ein. Runtime-Modus erleichtert eine geführte Bedienung, ist laut Microsoft aber kein Verfahren zur Absicherung der Anwendung. Beides sollte nicht als Ersatz für Zugriffsschutz bewertet werden. Versuchen Sie im Test auch den Zugriff außerhalb des vorgesehenen Startformulars und beurteilen Sie ihn anhand der eingerichteten Datenhaltung.

Das Trust Center behandelt die Ausführung potenziell unsicherer Inhalte. Als vertrauenswürdig eingestufte Speicherorte erlauben deren Ausführung; blockierter Code schützt umgekehrt nicht automatisch die Daten vor Einsicht. Legen Sie fest, wer freigegebene Dateien austauschen darf und wie deren Herkunft kontrolliert wird. Makrosicherheit ersetzt weder ein Berechtigungskonzept noch die Bewertung personenbezogener Daten und ihrer zulässigen Verarbeitung.

Quellen: [4] [3] [5]

6. Gleichzeitige Bearbeitung und Schnittstellen realistisch testen

Microsoft beschreibt für Access-Formulare unterschiedliche Sperrverfahren. Bei optimistischer Bearbeitung können Benutzer denselben Datensatz ändern; beim späteren Speichern entsteht ein Konflikt. Für ODBC-Daten nennt die RecordLocks-Dokumentation abweichendes Verhalten: Die Einstellung ist dort nicht wie eine Access-Dateisperre zu behandeln. Übertragen Sie deshalb einen erfolgreichen Test des Dateibackends nicht ungeprüft auf SQL Server.

Ein aussagekräftiger Prüffall lässt zwei Testbenutzer denselben fachlichen Vorgang öffnen. Einer korrigiert einen Wert, während der andere den alten Stand weiterbearbeitet. Prüfen Sie Meldung, gespeicherten Endzustand und die Reaktion des Benutzers. Ergänzen Sie einen Verbindungsabbruch während eines Imports: Welche Daten sind angekommen, welche fehlen, und was geschieht beim erneuten Start?

Bei SQL-Anbindung erfassen Sie Treiber, Authentifizierung, Tabellenverknüpfungen und Zielserver. Die Microsoft-Hilfe warnt, dass die Option zum Speichern eines SQL-Kennworts dieses unverschlüsselt in der Access-Datenbank ablegt. Lassen Sie den vorgesehenen Verbindungsweg durch die IT bewerten. Ein funktionierender Zugang mit Administratorrechten ist kein brauchbarer Nachweis für den späteren Betrieb mit begrenzten Benutzerrechten.

Quellen: [8] [2]

7. Änderungshistorie und fachliche Freigabe gesondert nachweisen

Ein Feld „zuletzt geändert“ zeigt zunächst nur den Inhalt dieses Feldes. Daraus folgt kein Nachweis einer vollständigen, geschützten Änderungshistorie. Beschreiben Sie für relevante Aufzeichnungen, welche Änderungen nachvollziehbar sein müssen, wie direkte Tabellenzugriffe behandelt werden und wer Historieneinträge verändern oder löschen könnte. Eine selbst entwickelte Protokollierung ist Bestandteil der Anwendung und benötigt eigene Prüfnachweise.

Annex 11 behandelt risikobasiert Audit Trails für GMP-relevante Änderungen und Löschungen. Ob und wie eine konkrete Access-Lösung die anwendbaren Anforderungen erfüllt, ist anhand ihres Aufzeichnungsprozesses zu beurteilen. Weder ein Dateibackup noch ein regelmäßig erzeugtes PDF ist pauschal ein Ersatz für notwendige Nachvollziehbarkeit. Prüfen Sie auch, ob der fachliche Zusammenhang nach einer Korrektur lesbar bleibt.

Microsoft beschreibt digitale Signaturen für ausführbare Datenbankbestandteile als Herkunfts- und Integritätsnachweis; für .accdb und .accde nennt die Hilfe Access für Microsoft 365 ab Version 2211. Das belegt keine elektronische Unterschrift eines Prüfers unter einem fachlichen Datensatz. Falls eine solche Unterschrift vorgesehen ist, sind Bedeutung, Identität und dauerhafte Zuordnung separat zu spezifizieren und nachzuweisen.

Quellen: [9] [11] [14]

8. Illustratives Beispiel: Eine Dublette verändert den Bericht

Dieses konstruierte Beispiel ist eine eigene Prüfhilfe, kein Kundenfall und kein ausgeführter Produkttest. Eine Access-Anwendung berechnet den Mittelwert gültiger Ergebnisse aus zwei Proben. Die festgelegten Testwerte betragen 10 und 20 in derselben Einheit; das fachliche Soll ist 15. Eine zweite Tabelle enthält Bewertungsvermerke. Wird deren Eins-zu-viele-Beziehung unpassend eingebunden, kann das erste Ergebnis doppelt in die Berechnung eingehen: Aus 10, 10 und 20 wird ungefähr 13,33.

Das Problem liegt dann nicht zwingend in der Rechenfunktion, sondern in der verwendeten Datensatzmenge. Halten Sie deshalb Tabelleninhalt, Beziehungen, Abfrage und Bericht gemeinsam fest. Ein bloßes DISTINCT ist keine allgemeine Reparatur: Zwei fachlich unterschiedliche Ergebnisse können denselben Zahlenwert besitzen. Die gewünschte Eindeutigkeit muss über die fachlichen Schlüssel bestimmt werden.

Führen Sie den Test in einer getrennten, repräsentativen Umgebung aus. Legen Sie Sollwerte vorab fest und erklären Sie jeden ausgeschlossenen Datensatz. Bei einem Fehler wird zunächst die Ursache eingegrenzt, anschließend die Änderung kontrolliert und der betroffene Umfang erneut geprüft. Die nachfolgende Matrix ist auf dieses Beispiel zugeschnitten und keine behördlich vorgegebene Testliste.

Quellen: [7] [6]

9. Sicherung, Migration und Versionswechsel beherrschen

Bei einer geteilten Access-Anwendung müssen Frontend und Datenbackend zusammen wieder betriebsfähig werden. Microsoft beschreibt hierfür getrennte Sicherungen; die vorgesehene Access-Backendsicherung benötigt exklusiven Zugriff. Bei verknüpften Daten liegt die Sicherung im jeweiligen Quellsystem. Eine Kopie des Frontends enthält deshalb nicht automatisch die Daten in SQL Server.

Prüfen Sie eine Wiederherstellung in einer geeigneten Testumgebung: Stimmen Verknüpfungen, Benutzerzugriffe, Datenstand und kritischer Bericht? Halten Sie fest, wie zwischen Sicherungszeitpunkt und Ausfall entstandene Aufzeichnungen behandelt werden. Ein erfolgreich abgeschlossener Sicherungsauftrag allein beantwortet diese fachlichen Fragen nicht. Archivierung erfordert zusätzlich die Lesbarkeit und Auffindbarkeit der benötigten Aufzeichnungen über die bestimmte Aufbewahrungsdauer.

Bei Migration oder Frontendwechsel vergleichen Sie Schlüssel, Datensatzanzahl, Beziehungen und repräsentative fachliche Ergebnisse. Eine Umstellung auf SQL Server ändert gegebenenfalls Abfrageausführung, Sperrverhalten und Rechte. Auch 32-/64-Bit-Wechsel können Bibliotheken und API-Aufrufe betreffen. Bewerten Sie Auswirkungen und wählen Sie passende Regressionstests. Der getestete Frontendstand muss anschließend kontrolliert verteilt werden; alte lokale Kopien benötigen eine geregelte Behandlung.

Quellen: [10] [3] [8] [14]

10. Den Start mit QA, IT und Prozessverantwortlichen vorbereiten

Für einen belastbaren Start benötigen Sie mehr als die zuletzt verwendete Datenbankdatei. Stellen Sie Quellstand, produktives Frontend, Backend, Verknüpfungen und bekannte Arbeitsanweisungen bereit. Der Prozessverantwortliche erklärt die fachliche Entscheidung und Sonderfälle; Entwicklung oder Betreuung erläutert die Logik. IT verantwortet technische Zugriffe und Betrieb, QA bewertet den regulierten Einsatz und die vorgesehene Nachweisführung.

Der Aufwand wächst insbesondere durch unbekannte Dateikopien, fehlenden Quellcode, unklare Datenverantwortung, viele Importvarianten und schwer reproduzierbare Berechnungen. Gute Bestandsunterlagen reduzieren Sucharbeit, ersetzen aber keinen gezielten Nachweis. Besprechen Sie zunächst einen kleinen, entscheidungsrelevanten Ablauf und dessen Fehlerfolgen. Danach lässt sich der verbleibende Umfang begründet planen, ohne eine pauschale Dauer oder einen festen Preis aus dem Produktnamen abzuleiten.

• Verwendungszweck, Regelbereich und fachliche Entscheidung sind benannt.
• Frontend, Backend, Versionen, Treiber und produktive Dateipfade sind bekannt.
• Schlüssel, Beziehungen, führende Datenquellen und Korrekturwege sind beschrieben.
• Referenzdaten decken Dubletten, fehlende Werte und relevante Grenzen ab.
• Benutzerrechte und alternative Schreibwege sind bewertet.
• Gleichzeitige Bearbeitung und unterbrochene Übertragungen sind berücksichtigt.
• Historie und gegebenenfalls fachliche Unterschriften sind separat abgegrenzt.
• Wiederherstellung, Änderungen und Verantwortliche sind geregelt.

Quellen: [11] [3] [10]