Databases Reference
In-Depth Information
ist. Da jeder Anwender - auch der Anwendungsentwickler - nur einen bestimm-
ten Teilbereich der Datenbank kennen muss, ist eine vollständige Sicht auf die
logische Ebene weder notwendig noch wünschenswert. Die externe Ebene des
ANSI SPARC-Modells stellt
Sichten
(dt. für views) zur Verfügung, die einzelnen
Anwendern oder ganzen Anwendergruppen diejenigen Ausschnitte aus der lo-
gischen Ebene geben, die sie benötigen. Diese Sichten können dabei das logische
Modell weiter abstrahieren. Neben dieser Anpassung an individuelle Erforder-
nisse kann so auch die logische Ebene gekapselt werden. Die Sichten sind damit
die Schnittstellen der externen Ebene zur logischen Ebene. Bei Änderungen auf
logischer Ebene müssen nur die Sichten angepasst werden. Diejenigen Teile der
Anwendungslogik, die die Sichten nutzen, bleiben unverändert. Diese Art der
Datenunabhängigkeit wird als
logische Datenunabhängigkeit
bezeichnet.
Das ANSI SPARC-Modell gilt noch heute weitgehend als die ideale Software-
Architektur für ein DBMS. Die klare Trennung der Schichten, die nur sehr kon-
trolliert miteinander kommunizieren können, ist Grundlage für die logische und
physikalische Datenunabhängigkeit. Sie wird aber in dieser Form selten erreicht,
insbesondere gibt es mit Sichten einige sehr fundamentale Probleme, mit denen
wir uns noch in Kapitel 15 beschäftigen werden. Dennoch findet man bei moder-
nen Datenbanksystemen die Trennung der drei Ebenen, auch wenn sie nicht voll-
ständig gegeneinander gekapselt sind. Wer sich zum ersten Mal mit Datenbanken
beschäftigt, kann die mehrschichtige Architektur des ANSI SPARC-Modells viel-
leicht nicht ganz einfach nachvollziehen. Vieles wird sich aber in den folgenden
Kapiteln ergeben, wenn wir die einzelnen Ebenen eingehender diskutieren und
anhand von Beispielen illustrieren.
Da es heutzutage eine Vielzahl von leistungsstarken DBMS gibt, die teilweise auch
kostenfrei genutzt werden können, gibt es auch keinen Grund mehr, eigene Soft-
warekomponenten für die Verwaltung von Daten zu entwickeln. Jedes Mal, wenn
wir in unserer Software Daten in Dateien eintragen oder aus Dateien lesen, sollten
wir den Einsatz einer Standardsoftware in Form eines DBMS erwägen. Tatsächlich
können wir sogar den Einsatz von In-Memory-Datenbanken erwägen, wenn wir
speicherresidente Daten intensiv nutzen. Dabei wird der Zugriff auf langsame
Speichermedien, wie Festplatten, vermieden. Die Geschwindigkeit steht mögli-
cherweise nur wenig hinter einer selbstentwickelten Lösung zurück; in jedem Fall
ist die Standardsoftware aber ausgereifter als unsere selbstgestrickte Datenver-
waltung.
1.11
Wie alles anfing
Die Idee, Programme zu entwickeln, mit deren Hilfe die Datenhaltung einer Soft-
ware nicht jedes Mal aufs Neue erfunden werden muss, begann mit der zuneh-
menden Verbreitung der entsprechenden Hardware in Form von Festplatten in
den 1960er-Jahren.
