Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 2/2005.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Validierung von Daten

André Minhorst, Duisburg

Die Konsistenz einer Datenbank lässt sich nur durch eine entsprechende Validierung beim Anlegen und Ändern von Daten erhalten. Dazu stellt Access einiges an eingebauter Funktionalität zur Verfügung: zum Beispiel die Gültigkeitsregeln und Gültigkeitsmeldungen von Tabellenfeldern, Tabellen und Formularfeldern, mit denen sich eine Menge Fehleingaben ausschließen lässt. Wer aber den Benutzern seiner Anwendung in jeder Situation zur Seite stehen möchte, kommt um einige Handarbeit nicht herum. Wie Sie Ihre Datenbankanwendung mit einer professionellen Validierung versehen, erfahren Sie in diesem Beitrag.

Validierung - was ist das?

Der freien Enzyklopädie unter http://www.wikipedia.de ist folgender Kernsatz zu entnehmen: "In der Softwaretechnik bezeichnet Validierung oder Plausibilisierung (auch Sanity Check genannt) die Kontrolle eines konkreten Wertes darauf, ob er zu einem bestimmten Datentyp gehört oder in einem vorgegebenen Wertebereich oder einer Wertemenge liegt."

Weiterhin findet man dort noch eine "Goldene Regel". Diese lautet "Never trust the user" (deutsch: Traue dem Benutzer niemals). Beides zusammen definiert den einen Teil des hier behandelten Themas: Überprüfen Sie jede Eingabe der Benutzer, selbst wenn diese noch so trivial erscheint. Aber es gibt noch einen Punkt, dem dieser Beitrag besondere Beachtung schenkt: Wenn der Benutzer die "Goldenen Regel" durch Fehleingaben rechtfertigt, dann gehen Sie auch noch einen Schritt weiter und weisen ihn in angemessener Weise darauf hin: mit einer aussagekräftigen Meldung.

Dem einleitenden Kapitel des vorliegenden Beitrags bleibt nur noch die Aufgabe, ein wenig Appetit auf die folgenden Kapitel zu machen: Sie erfahren, wie Sie Gültigkeitsprüfungen auf Tabellenebene festlegen können, welche Möglichkeiten es dazu in Formularen gibt und welche Vor- und Nachteile die unterschiedlichen Varianten mit sich bringen.

Validieren auf Tabellenebene

Die einfachste und grundlegendste Validierung lässt sich über den Entwurf einer Tabelle festlegen.

Dazu gibt es verschiedene Möglichkeiten:

  • Auswahl des Datentyps: Legt die Art des Inhalts fest
  • Die Tabelleneigenschaften Eingabe erforderlich/Leere Zeichenfolge: Legt fest, ob eine Eingabe erfolgen muss
  • Die Gültigkeitsregel: Legt differenzierte Anforderungen fest.
  • Datentyp

    Mit der Auswahl eines Datentyps für ein Feld haben Sie schon eine Vorauswahl für die einzugebenden Daten getroffen. Mit Text- und Memofeldern sind Sie noch am flexibelsten, da hier alle möglichen Zeichenketten unterkommen, aber mit Datums- oder den unterschiedlichen Zahlenformaten schränken Sie den Kreis der einzugebenden Daten schon stark ein.

    Wenn Sie nun beispielsweise den Datentyp "Datum/Zeit" für ein Tabellenfeld festlegen und eine Zeichenkette in dieses Feld eingeben, erscheint folgende Meldung: "Sie haben einen Wert eingegeben, der für dieses Feld nicht zulässig ist." Das ist im Rahmen, wenn der Benutzer aus Versehen einen falschen Wert eingegeben hat und weiß, wie das Datum aufgebaut sein muss. Vielleicht haben Sie es aber auch mit einem DAU zu tun und dieser lässt sich die denkbar wildeste Variante von Datumsformat einfallen und ist sich sicher, das er definitiv nicht schuld an diesem Eingabefehler sein kann. In dem Fall wäre ein Hinweis auf das korrekte Format der einzugebenden Daten sicher wertvoll.

    In Tabellen lässt sich bei einer nicht dem Datentyp entsprechenden Eingabe keine andere Eingabe herausholen, in Formularen aber - und hier findet die Bearbeitung der Daten normalerweise statt - lässt sich eine alternative Fehlermeldung präsentieren. Dazu jedoch später mehr.

    Erforderliche Eingaben und leere Zeichenfolgen

    Mit diesen beiden Eigenschaften lassen sich ebenfalls grundlegende Validierungsregeln festlegen. Wenn die Eigenschaft Eingabe erforderlich den Wert Ja hat, muss der Benutzer für dieses Feld auf jeden Fall einen Wert eingeben.

    Bei diesem Wert kann es sich, wenn die Eigenschaft Leere Zeichenfolge ebenfalls den Wert Ja hat, auch um eine leere Zeichenfolge handeln - ansonsten sonst muss man mindestens ein Zeichen mit Ausnahme des Leerzeichens dort eintragen.

    Hat die Eigenschaft Eingabe erforderlich den Wert Nein, muss der Benutzer keinen Wert für dieses Feld eingeben - der Wert des Feldes bleibt dann Null, soweit kein anderer Standardwert vorgegeben ist. Auch hier wirkt sich der Wert der Eigenschaft Leere Zeichenfolge wieder aus: Steht der auf Ja, können Sie hier Leerzeichen eingeben, sonst ist das nicht möglich.

    Gültigkeitsregeln auf Feldebene

    Flexibler als die beiden vorher genannten Möglichkeiten zum Validieren sind die Gültigkeitsregeln. Für die Festlegung der Vergleichsmuster können Sie beliebige Ausdrücke bestehend aus einem Vergleichoperator und einem Vergleichswert mit entsprechenden Verknüpfungsoperatoren zusammensetzen.

    Zur Festlegung einer Gültigkeitsregel wählen Sie einfach das Feld aus, dessen Inhalt einem bestimmten Muster entsprechen soll, und verwenden die Eigenschaft Gültigkeitsregel zum Festlegen des Musters (s. Abb. 1). Im Beispiel soll der Inhalt des Feldes einfach nicht Null sein. Das ließe sich auch mit der Eigenschaft Eingabe erforderlich erreichen, allerdings hat diese Variante einen entscheidenden Nachteil, der später zur Sprache kommen wird.

    Die Eigenschaft Gültigkeitsmeldung gibt an, welche Meldung Access anzeigen soll, wenn die Gültigkeitsregel beim Speichern eines Datensatzes nicht erfüllt ist.

    Abb. 1: Festlegen einer Validierung per Tabellenentwurf

    Das Verhalten können Sie ganz einfach testen, indem Sie einen neuen Datensatz für die Tabelle anlegen und diesen speichern, ohne einen Wert für das Feld Vorname eingegeben zu haben. Es erscheint ein Meldungsfenster mit der eingestellten Nachricht (s. Abb. 2).

    Für die Eigenschaft Gültigkeitsregel lassen sich beliebige Ausdrücke eingeben. Wenn Sie wie im vorliegenden Fall ein Textfeld verwenden, könnten Sie beispielsweise nach Ausdrücken eines bestimmten Formats verlangen, indem Sie den Like-Operator und einen Vergleichswert mit Platzhaltern wie Sternchen (*) und Fragezeichen (?) verwenden. Der folgende Ausdruck würde beispielsweise beliebige Namen akzeptieren, die mit A beginnen:

    Like 'a*'

    Sie könnten auch einen Bereich für ein einzugebendes Datum damit festlegen. Der folgende Ausdruck würde beispielsweise alle Datumsangaben akzeptieren, die im Jahr 2005 liegen:

    >= #1/1/2005# And <=#31/12/2005#

    Abb. 2: Gültigkeitsmeldung bei inkorrekter Eingabe

    Abb. 3: Validierung auf Datensatzebene

    Gültigkeitsregeln auf
    Datensatzebene

    Neben einzelnen Feldern können Sie auch komplette Datensätze einer Validierung per Gültigkeitsregel unterziehen. Damit lassen sich etwa voneinander abhängige Feldinhalte prüfen.

    Um eine Gültigkeitsprüfung auf Datensatzebene durchzuführen, zeigen Sie zunächst das Eigenschaftsfenster der Tabelle in der Entwurfsansicht an. Dort finden Sie ebenfalls die beiden Eigenschaften Gültigkeitsregel und Gültigkeitsmeldung. Eine sinnvolle Anwendung ist beispielsweise die Prüfung eines Benutzernamens und eines Kennworts aus einer Benutzertabelle auf Gleichheit. Um allzu risikobereite Benutzer zur Auswahl eines "richtigen" Kennworts zu veranlassen, vergleichen Sie einfach die Inhalte der Felder Benutzername und Kennwort miteinander und geben bei Gleichheit eine entsprechende Meldung aus (s. Abb. 3).

    Wichtig ist hier, dass die Gültigkeitsregel nicht bereits beim Verlassen eines der betroffenen Felder herangezogen wird, sondern erst beim Speichern des Datensatzes.

    Validierung auf Tabellenebene in Formularen behandeln

    Wenn der Benutzer eine Eingabe vornimmt, die nicht dem gültigen Datentyp entspricht, die Regeln Eingabe erforderlich und Leere Zeichenfolge übergeht oder die Gültigkeitsregel nicht berücksichtigt, erscheint direkt beim Verlassen des betreffenden Feldes der Tabelle eine entsprechende Meldung.

    Wenn Sie ein Formular verwenden, das über die Datenherkunft an eine Tabelle mit solchen Validierungen gebunden ist, werden Datentyp, Gültigkeits- und sonstige Regeln genau so durchgesetzt wie beim direkten Bearbeiten der Tabelle wie in den obigen Beispielen. Abb. 4 zeigt ein Beispiel: Die Übereinstimmung von Benutzername und Kennwort erkennt Access sofort und zeigt die entsprechende Gültigkeitsmeldung an.

    Vor- und Nachteile

    Aus der Verwendung der Validierung auf Tabellenebene ergeben sich Vor- und Nachteile, die nachfolgend aufgeführt sind.

    Abb. 4: Die Validierung per Gültigkeitsregel auf Tabellenebene greift auch in Formularen.

    Vorteile

    Der größte Vorteil dieser Validierungsmethode ist die globale Gültigkeit - egal, ob Sie die Daten per Formular, VBA oder Aktionsabfrage bearbeiten, die Gültigkeitsregeln greifen. Damit sichern Sie in jedem Fall die Konsistenz der in der Datenbank enthaltenen Daten.

    Abb. 5: Mit dieser Fehlermeldung können nur wenige Benutzer etwas anfangen.

    Nachteile

    Die Gültigkeitsprüfung funktioniert zwar auch per VBA, allerdings fällt die Gültigkeitsmeldung in manchen Fällen flach. Folgende Anweisung beispielsweise ruft nur eine allgemein gehaltene Fehlermeldung hervor (s. Abb. 5):

    DoCmd.RunSQL "INSERT INTO tblBenutzer(Benutzername, Kennwort) VALUES('minhorst', 'minhorst')

  • Der zweite Nachteil ist, dass eventuelle Änderungen immer auch im Tabellenentwurf nötig sind. Das bedeutet, dass Sie bei einer in Front- und Backend aufgeteilten Datenbank das Backend beim Kunden austauschen müssten, nur weil etwa eine Meldung anzupassen ist. Drittens ist die Fehlermeldung für die meisten Benutzer nicht aussagekräftig genug. Gerade ein gezielter Hinweis auf Fehleingaben trägt viel zur besseren Nutzbarkeit einer Anwendung bei.
  • Und schließlich kann die Aufteilung der die Datenhaltung betreffenden Funktionen auf mehrere Schichten (in diesem Fall auf die Benutzeroberfläche und die Datendefinition) immer zu Problemen führen. Spätestens wenn die enthaltenen Daten oder die Benutzerzahlen wachsen und den Wechsel auf ein anderes Backend wie die MSDE oder den Microsoft SQL Server notwendig machen, müssen Sie genauestens ermitteln, wo welche Businessregeln untergebracht sind, und diese anschließend entsprechend wieder aufbauen.
  • Validieren auf Formularebene

    Formulare bieten einige weitere Möglichkeiten zur Validierung von Daten. Damit lassen sich einerseits die Validierungstechniken auf Tabellenebene ergänzen, aber auch komplett ersetzen.

    Validieren bei der Eingabe oder beim Speichern?

    Die Geister scheiden sich bei der Frage, ob man den Inhalt der Steuerelemente direkt nach der Eingabe in ein Steuerelement prüfen sollte oder damit bis zum Speichern des Datensatzes wartet. Genau genommen lässt sich hier keine allgemeine Empfehlung geben.

    Ausschlaggebend für die Wahl der richtigen Validierungsstrategie ist die Berücksichtigung der Benutzerfreundlichkeit und der Performance. Die Performance könnte sich beispielsweise bemerkbar machen, wenn Sie zum Prüfen eines Wertes immer wieder auf ein über das Netzwerk verbundenes Datenbankbackend zugreifen müssten. Dabei kommt es natürlich auch auf die Art des Frontends an: Wenn Sie beispielsweise eine .asp-Seite im Intranet als Frontend verwenden und den Inhalt der Felder einzeln prüfen, ist die Netzlast schon relativ hoch. In dem Fall sollte man schon beim Abschicken der kompletten Seite validieren und dann gegebenenfalls den Benutzer zur Nachbesserung auffordern. Dabei lassen sich viele Inhalte natürlich schon per Skript (zum Beispiel JavaScript) direkt bei der Eingabe prüfen, aber manchmal sind Eingaben eben mit dem bestehenden Datenbankinhalt abzugleichen, was definitiv den Kontakt zum Server erfordert.

    Da die meisten Leser aber vermutlich mit Access als Frontend (wenn überhaupt mit aufgeteilter Datenbank) arbeiten, sollen die dortigen Möglichkeiten nun etwas genauer beleuchtet werden.

    Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

    Sind Sie Abonnent?Jetzt einloggen ...
     

    Kompletten Artikel lesen?

    Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

    E-Mail:

    Verwandte Beiträge:

    Formularposition speichern und wiederherstellen

    Transparenz und andere Effekte in Formularen

    Zugriff auf Daten in Formularen und Steuerelementen

    Modale Dialoge mal anders

    © 2003-2015 André Minhorst Alle Rechte vorbehalten.