Database Reference
In-Depth Information
„Kurse“ existiert. Hier muss aber vorgängig abgeklärt werden,
ob es überhaupt zulässig ist, einen Kurs zu löschen, wenn es
Personen gibt, die diesen Kurs schon besucht haben. Wir neh-
men an, dies sei zulässig und verwenden für diese Transaktion
einen „Post-Delete“-Trigger. Dieser Trigger wird aktiv,
nach-
dem
ein Datensatz gelöscht worden ist. Der SQL-Befehl sieht
dann aus, wie in Bild 4.23 dargestellt.
Bild 4.23:
Löschen aller
Datensätze mit
einem bestim-
mten Attribut-
wert
DELETE FROM Kursbesuche
WHERE KNr={Feld „KNr“};
Es muss jetzt dem Trigger aber noch mitgeteilt werden, dass
kein Fehler vorliegt, wenn in der Tabelle „Kursbesuche“ kein
Datensatz gelöscht werden konnte (mc-Assoziation). Bei der
Kurskontrolle hingegen müsste dies wegen der m-Assoziation
zu einer Fehlermeldung führen.
Bei
Beispiel C
muss sichergestellt werden, dass nur Funktions-
nummern eingegeben werden können, welche in der Tabelle
„Funktionen“ auch existieren. Dies erreicht man, indem man
den Benutzer zwingt, einen Funktionswert einzugeben und
diesen dann mit einem Trigger wie in Beispiel A überprüft.
Dieser Eingabezwang erfolgt automatisch, wenn man dies beim
Feld „FNr“ in der Benutzermaske so definiert (Nullwerte nicht
erlaubt).
4.7.3
Programmieraufwand
Wie schon im Theorieteil erklärt, kann es eine 100%ige Daten-
konsistenz gar nicht geben. Es stellt sich also die Frage, wie
groß der Programmieraufwand für die Konsistenzerhaltung sein
sollte. Diese Frage kann natürlich nur qualitativ beantwortet
werden und hängt in erster Linie von der Problemstellung ab.
Die Kurve aus Bild 4.24 zeigt aber, wie der Programmierauf-
wand mit dem Konsistenzgrad generell zusammenhängt.
