ANSI-SPARC-Architektur
thumb|300px|Drei-Ebenen-Schema-ArchitekturDie ANSI-SPARC-Architektur, auch Drei-Ebenen-Architektur, beschreibt den grundlegenden Aufbau eines relationalen Datenbanksystems.
Die Architektur wurde 1975 vom Standards Planning and Requirements Committee (SPARC) des American National Standards Institute (ANSI) entwickelt.
Die drei Ebenen sind:
#Die externe Ebene, die den Benutzern und Anwendungen individuelle Benutzersichten bereitstellt. Beispiele: Formulare, Maskenlayouts, Listen, Schnittstellen.
#Die konzeptionelle Ebene, in der beschrieben wird, welche Daten in der Datenbank gespeichert sind sowie deren Beziehungen untereinander. Designziel ist hier eine vollständige und redundanzfreie Darstellung aller zu speichernden Informationen. Die konzeptionelle Ebene kann als normalisierte Relationen dargestellt werden.
#Die interne Ebene (auch physische Ebene), die die physische Sicht der Datenbank im Computer darstellt. In ihr wird beschrieben, wie und wo die Daten in der Datenbank gespeichert werden. Designziel ist hier ein performanter Zugriff auf die gespeicherten Informationen. Das wird meistens nur durch eine bewusst in Kauf genommene Redundanz erreicht (z.B. im Index werden die selben Daten gespeichert, die auch schon in der Tabelle gespeichert sind).
Die Vorteile des 3-Ebenen-Modells liegen in der
*physischen Datenunabhängigkeit, da die interne von der konzeptionellen und externen Ebene getrennt ist. Physische Änderungen, z.B. des Speichermediums, wirken sich nicht auf die konzeptionelle oder externe Ebene, also die Benutzer und Anwendungen aus.
*logischen Datenunabhängigkeit, da die konzeptionelle und die externe Ebene getrennt sind. Dies bedeutet, dass Änderungen an der Datenbankstruktur keine Auswirkungen auf die externe Ebene, also die Benutzer und Anwendungen haben.
Das 3-Ebenen-Modell ist in aktuellen Datenbankmanagementsystemen (DBMS) zwar durch Sichten implementiert, wird jedoch durch die Anwendung selbst meistens nicht verwendet. Üblicherweise benutzen Anwendungen direkt das konzeptuelle Schema, also Operationen auf den eigentlichen Tabellen, und nicht auf Sichten. Man handelt sich dadurch natürlich die zu erwartenden Nachteile (z.B. Verlust der logischen Datenunabhängigkeit) ein.
Hinweis: Im Deutschen wird sowohl "konzeptuell" als auch "konzeptionell" verwendet. Die Begriffe bedeuten dasselbe.
Beispiel Data-Warehouse
Die Unterschiede zwischen der konzeptuellen und der internen Ebene und auch die Abhängigkeiten zwischen der externen und der internen Ebene können gut anhand der Data-Warehouse-Architektur erläutert werden. Hier sind in der externen Ebene umfangreiche Aggregationen definiert, deren Berechnung sehr zeitaufwändig ist. Um aus einem OLAP die geforderten Aggregationen trotzdem schnell abrufen zu können, werden in der Nacht alle performance-intensiven Aggregationen berechnet. Die Ergebnisse der nächtlichen Berechnungen werden in sog. Aggregations-Tabellen abgelegt. Wenn ein Anwender während des Tages eine Aggregation aufruft, dann kann das System die Ergebnisse sekundenschnell aus den Aggregations-Tabellen auslesen. Die Aggregations-Tabellen blähen das Datenvolumen der internen Ebene enorm auf. Es ist im Durchschnitt 6 mal größer als das Volumen der redundanzfreien Basis-Tabellen, die weitgehend der konzeptionellen Ebene entsprechen.
Literatur
* R. Elmasri et al: Grundlagen von Datenbanksystemen, Pearson Studium, 2002, 3ed, ISBN 3-8273-7021-3, S. 49 ff
* T. Härder, E. Rahm: Datenbanksysteme Konzepte und Techniken der Implementierung, Springer, 2001, 2. Auflage, ISBN 3-540-42133-5, S. 8-11
