Database Reference
In-Depth Information
den, damit das Zusammenspiel von Front-End und Server op-
timal funktioniert:
Server-Seite:
Tabellen mit Zugriffsberechtigungen
Beziehungen
Views (Gespeicherte Abfragen auf Tabellen, Sichten)
Geschäftslogik (Trigger, Stored Procedures)
Client-Seite
:
Formulare
Berichte
Menüverwaltung (steuert den Zugriff auf Formulare und Be-
richte)
Programmlogik (Benutzerführung)
Zusammengefasst gehören die Daten, Beziehungen und Zu-
griffsberechtigungen auf den Server, der Rest auf den Client-
PC.
Bei der Geschäftslogik muss abgewogen werden zwischen Da-
tenschutz/Stabilität und Programmieraufwand. Da VBA einen
höheren Programmierkomfort und eine größere Funktionalität
bietet als PL/SQL, werden Teile der Geschäftslogik gerne auf
dem Client-PC implementiert. Wenn aber hohe Anforderungen
an die Datenkonsistenz und den Datenschutz gestellt werden,
kann es sogar sein, dass der Datenbankzugriff (schreibend) nur
über Stored Procedures erfolgt, während der Lesezugriff über
Views oder ebenfalls über Stored Procedures abgehandelt wird.
4.13.5.3
Zugriff verweigert oder Administrieren ohne Ende
Sowohl ACCESS als auch ORACLE stellen umfangreiche Mög-
lichkeiten für den Datenschutz zur Verfügung. Es ist aber gar
nicht so einfach, alle Löcher zu stopfen und somit zu verhin-
dern, dass ein Benutzer Daten sichten kann, die ihn nichts an-
gehen, oder am Programmkode herumbastelt. Außerdem
möchte man nicht jeden Benutzer sowohl unter ORACLE als
auch unter ACCESS separat administrieren müssen (Benutzer-
konto eröffnen, Rollen zuweisen). Daher sind gewisse Regeln
zu beachten:
Neue Benutzer werden nur auf dem Datenbankserver eröff-
net.
