Drei-Ebenen-Architektur

Drei-Ebenen-Schema-Architektur

Die ANSI-SPARC-Architektur, auch Drei-Schema-Architektur, beschreibt die grundlegende Trennung verschiedener Beschreibungsebenen für Datenbankschemata.

Die Architektur wurde 1975 vom Standards Planning and Requirements Committee (SPARC) des American National Standards Institute (ANSI) entwickelt und hat zum Ziel den Benutzer einer Datenbank vor nachteiligen Auswirkungen von Änderungen in der Datenbankstruktur zu schützen.

Die drei Ebenen sind:

1. Die externe Ebene, die den Benutzern und Anwendungen individuelle Benutzersichten bereitstellt. Beispiele: Formulare, Masken-Layouts, Listen, Schnittstellen.
2. 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. Hier findet die Normalisierung des relationalen Datenbankschemas statt.
3. 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 dieselben 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 oder des Datenbankprodukts, wirken sich nicht auf die konzeptionelle oder externe Ebene aus.
• logischen Datenunabhängigkeit, da die konzeptionelle und die externe Ebene getrennt sind. Dies bedeutet, dass Änderungen an der Datenbankstruktur (konzeptuelle Ebene) keine Auswirkungen auf die externe Ebene, also die Masken-Layouts, Listen und Schnittstellen haben.

Im Deutschen ist die Bezeichnung "konzeptuell" zwar veraltet, wird jedoch immer noch genutzt. Das Wort "konzeptionell" ist ebenfalls richtig. Die Begriffe sind bedeutungsgleich.

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. Sie ergänzen die Datenspeicherung in der internen Ebene. 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