93kB - Praktische Informatik

Architektur von DBMS 18
Satzes gespeichert, die Menge der Tupel einer Relation in den Sätzen
eines Segments.
Die Details (mögliche Attributtypen usw.) hängen vom Datenbankmodell
ab. In navigierenden Datenbankmodellen wird insb. die
Navigation zwischen Objekten auf dieser Ebene realisiert, in relationalen
Systemen die Behandlung von Cursors.
4.6 Ebene 4: Mengen-Schnittstelle
Diese Ebene entfällt weitgehend bei rein navigierenden Datenbankmodellen.
Bei textuellen Schnittstellen muß hier zunächst die textuelle Formulierung
einer Anweisung in eine interne Darstellung übersetzt werden.
Dies beinhaltet diverse Prüfungen, u.a. der Syntax, des Vorhandenseins
von referenzierten Relationen oder Typen, der Zugriffsrechte
usw. Im Erfolgsfall wird danach im Rahmen der Optimierung
ein möglichst effizient ausführbarer Plan erstellt, der den Auftrag
realisiert; entgegen der Bezeichnung “Optimierung” wird allerdings
aus Aufwandsgründen nicht versucht, wirklich einen optimalen
Ausführungsplan zu finden, sondern nur anhand von Heuristiken einen
wahrscheinlich recht guten. Der erstellte Plan wird schließlich ausgeführt.
Nach Abarbeitung müssen die Ergebnisse entweder in geeigneten
Datenstrukturen bereitgestellt werden (bei einem API) oder für
eine externe Darstellung aufbereitet werden.
4.7 Beziehung zur 3-Ebenen-Schema-Architektur
In Abschnitt 5.2 in [DVS] wurde die 3-Ebenen-Schema-Architektur
für DBMS eingeführt. Diese korreliert lose mit der hier in Abschnitt
4 eingeführten Abstraktionshierarchie von Datenbankobjekten.
Bei der Abstraktionshierarchie von Datenbankobjekten hatten wir
unterstellt, daß es sich primär um Nutzdaten handelt. Schemadaten
müssen natürlich auch persistent verwaltet werden, und die Speicherungsoperationen
können hierfür im Prinzip auch ausgenutzt werden
(z.B. auf der Ebene von Speichersätzen); auf dieses Thema wollen wir
aber hier nicht eingehen.
c○2013 Udo Kelter Stand: 26.11.2013