Databases Reference
In-Depth Information
In der nicht sehr fernen Vergangenheit konnten diese und weitere Arten von Inte-
gritätsbedingungen nur dadurch gewährleistet werden, dass sie in
Anwendungspro-
grammen
implementiert wurden. Damit wurden natürlich viele Regeln mehrfach im
Programmcode repräsentiert. Die Folge waren unter Umständen Widersprüche in
verschiedenen Programmen und auf jeden Fall verschlechterte Wartbarkeit. Schlim-
mer noch: Das Problem der Integritätskontrolle ist sehr schwer in den Griff zu
bekommen, wenn es jedem einzelnen Anwender überlassen bleibt. Dem sind
bestimmte Regeln entweder gar nicht bekannt, oder sie werden nicht immer konse-
quent befolgt und möglicherweise in ihrer Auswirkung auf die gesamte Datenbank
nicht überschaut. Dieses Problem wächst noch mit zunehmender Verfügbarkeit an
Client-Software aller Art, die den direkten Zugriff von Anwendern auf Datenban-
ken gestattet.
Die Forderung lautet daher: Alle Integritätsbedingungen, die die Daten unabhän-
gig von etwaigen Abläufen betreffen, müssen als Eigenschaften der Daten selbst
behandelt werden. Folglich müssen sie in der Datenbank selbst niedergelegt wer-
den, also: »Integrität in die Datenbank!«
Konsistenzüberprüfungen in den
Anwendungsprogrammen
(z.B. in Datenerfassungs-
formularen) sind zwar ein wichtiges Hilfsmittel, um die Konsistenz sicherzustellen;
die Anwendungsprogramme sind aber in den externen Schemata angesiedelt. Der
Endanwender oder der Entwickler für ein Endanwenderprogramm ist dann dafür
verantwortlich, dass die Unternehmensregeln eingehalten werden. In einer unter-
nehmensweiten Datenbank kann die Konsistenz damit nicht sichergestellt werden,
so lange ein Benutzer die Möglichkeit hat, (absichtlich oder unabsichtlich) Anwen-
dungen zu entwickeln, in denen Konsistenzbedingungen verletzt werden.
Datenbank
zentrale
Integritäts-
regeln
App 1
App 2
App 3
App 4
App 5
verschiedene Anwendungen
Abbildung 1.3:
Zentral verwaltete Integritätsbedingungen
