Database Reference
In-Depth Information
Datenbanksystem: ORACLE 12c
Benutzeroberfläche: MS-ACCESS 2010
Kommunikation: ORACLE ODBC-Treiber + SQL*Net
Die Applikation soll als Client/Server-Lösung aufgebaut sein,
bei der möglichst alle Abfragen vom Datenbankserver ausge-
führt werden. Der Client (hier ACCESS 2010) soll nur die Be-
nutzereingaben entgegen nehmen, aufarbeiten, an den Daten-
bankserver weiterleiten und das Ergebnis des Servers anzeigen.
Mit diesem Konzept ist eine Lastenverteilung zwischen Client-
PC und Datenbank-Server möglich, und zudem wird das Netz-
werk weniger belastet.
4.13.5.1
Datentypen, Beziehungen oder Wunschtraum Standardisierung
Nach der Entwicklung des Datenmodells kommt irgendwann
der Punkt, wo man dieses Modell umsetzen möchte (Tabellen,
Views und Beziehungen erstellen, Zugriffsberechtigungen ver-
geben, Trigger und Prozeduren programmieren usw.).
Dies kann folgendermassen geschehen:
F)
Die Tabellen und Beziehungen werden direkt auf dem Da-
tenbankserver (ORACLE) erstellt.
G)
Die Tabellen und Beziehungen werden mit ACCESS erstellt
und anschließend auf den Datenbankserver migriert.
Es sei hier schon verraten, dass man mit Variante B nicht
glücklich wird. Obwohl ORACLE und ACCESS auf der relatio-
nalen Datenbanktechnologie aufbauen, gibt es doch diverse
Unterschiede:
Datentypen sind unterschiedlich. Ein ORACLE-Datentyp
NUMBER(4,0) wird von ACCESS als Integer-Typ interpretiert,
weil der Wertebereich von -9999 bis +9999 im Integer-Wer-
tebereich (-32768 bis 32767) von ACCESS Platz findet. Ver-
sucht man aber, den Wert 10000 via ACCESS ins ORACLE-
Feld abzuspeichern, bekommt man eine Fehlermeldung,
weil dieser Wert den ORACLE-Wertebereich für
NUMBER(4,0) sprengt. Ein ORACLE-Datentyp NUMBER
(12,0) wird von MS-ACCESS hingegen als Zeichenkette in-
terpretiert, weil MS-ACCESS nur ganze Zahlen bis
2147483647 verarbeiten kann.
Aktualisierungsweitergabe von ID-Schlüsselwerten (wenn
sich ein ID-Schlüsselwert ändert, werden die entsprechen-
