Virtabs: Positionierung

Virtabs implementieren die “externe Ebene” nach ANSI-SPARC

Statt langer Worte hier der Wikipedia-Eintrag. Mit Virtabs können Anwendungen endlich vollständig auf Sichten aufgebaut werden. Die logische Datenunabhängigkeit ist so gewährleistet..

Eine Motivation: Integration verschiedener DV-Arbeitsplätze

Historisch gewachsene Datenbestände zeichnen sich häufig dadurch aus, dass für verschiedene arbeitsorganisatorische Teilbereiche verschiedene Teildatenbanken entstanden sind. Trotzdem stehen diese Teildatenbestände inhaltlich zueinander in Beziehung, sind aber in der Regel nicht direkt miteinander verknüpfbar. Dieses Nebeneinander ist meistens durch die allmähliche und unkoordinierte Einführung von dezentralen EDV-Lösungen bedingt. Jede Teildatenbank entspricht dabei den Anforderungen eines spezifischen EDV-Arbeitsplatzes und stellt von daher vor allem eine wichtige arbeitsorganisatorische Einheit dar (und nicht nur ein historisches Relikt).

Im Bild sind die fiktiven, EDV-technisch getrennten Arbeitsplätze “Abteilungs-Verwaltung” (ohne EDV), “Personalverwaltung” (auf einem Arbeitsplatzrechner) und “Auftragsverwaltung” (auf RDBMS) dargestellt.

Anwendungsnahe Datenmodelle werden durch Views simuliert

Um die verschiedenen Teildatenbestände miteinander verknüpfen zu können, bietet sich die Einführung eines RDBMS als Teil eines integrierenden Client-Server-Konzeptes an. Das Datenmodell der zentralen SQL-Datenbank muss alle hausinternen Teilprozesse abbilden. Es darf, um handhabbar zu werden, nicht einfach die Summe der bisherigen Datenmodelle darstellen , sondern muss diese auf einer neuen Abstraktionsebene integrieren. Die Datenmodelle der Teildatenbanken lassen sich dann durch Benutzersichten (Views) auf das zentrale Datenmodell darstellen. Die Funktionalität der Teildatenbanken wird in der Regel in spezifische Client -Anwendungsprogramme verlagert, die gegenüber den Benutzern die eingeschränkten Datensichten des jeweiligen EDV-Arbeitsplatzes nachbilden. Auch die teilaufgabenspezifischen historischen Input- und/oder Output-Wege müssen oft weiter bereitgestellt werden, entsprechend der meist unveränderten Arbeitsorganisation.

 

Virtabs sind schreibbare Views

Datenbanktechnisch ergibt sich dabei das Problem, dass das Konzept der View nur für lesende Zugriffe definiert ist, an den verschiedenen Arbeitsplätzen aber auch schreibende bzw. verändernde Zugriffe im jeweiligen, reduzierten Datenmodell möglich sein müssen. In den Entwicklungsumgebungen, die verschiedene Hersteller für Datenbankoberflächen anbieten (z.B. Oracle Forms oder Borland Delphi), ist es in der Regel zwar möglich, verknüpfte Tabellen (Master-Detail-Paare) in entsprechenden Oberflächenelementen darzustellen. Dieser Ansatz ist jedoch problematisch, da er das zentrale Server-Datenmodell direkt an den Endbenutzer weiterleitet (da für jede Tabelle ein Oberflächenelement dargestellt wird). Auch werden nicht -visuelle Operationen, die traditionell per embedded SQL-Code durchgeführt werden, von diesen Konzepten nicht unterstützt. Daher muss ein Client-Anwendungsprogramm häufig manuell erstellte SQL-Prozeduren enthalten, um bei schreibenden Zugriffen die Bezüge zwischen den Tabellen in der Server-Datenbank aufzulösen.

Aus der Beobachtung, dass dieser Prozedur-Code recht schematisch aufgebaut ist (Analyse der Master-Detail-Strukturen der zugehörigen View, Lokalisieren von allen Master-Datensätzen, Gewinnung von neuen Schlüsseln aus Nummerngeneratoren (Sequenzen) und Durchführen von Änderungen an den Detail-Tabellen bzw. allen betroffenen Master-Datensätzen) und aufgrund der Tatsache, dass bei einer Datenbank-Strukuränderung der Prozedur-Code an sämtlichen Stellen überprüft bzw. aktualisiert werden muss, entstanden Überlegungen, die Prozeduren zum Einfügen, Aktualisieren und Löschen von in einer Datenstruktur verteilt vorliegenden Datensätzen automatisch durch einen Codegenerator erzeugen zu lassen.

Dieser Ansatz führte schließlich zum Konzept der 'Virtuellen Tabelle' (im folgenden 'Virtab' genannt): Eine Virtab ist eine neuartiges Datenbankobjekt, das die Verknüpfungsfunktionalität von Views nicht nur bei Abfragen, sondern auch bei Einfüge-, Aktualisierungs- und Lösch -Operationen bietet. Eine Virtab präsentiert sich in der jeweiligen Anwendung funktional als Datenbanktabelle. Sie besteht aus einer View, die bestimmte Datenbankattribute aus der Verknüpfungsstruktur darstellt, und drei genau auf diese View abgestimmten 'stored procedures' (insert-, update- und delete-Prozedur). Die Parameter der Prozeduren entsprechen genau den Spalten der View. Zusätzliche Bedingungen (Constraints) zur Eingrenzung der Datensicht sind möglich, wobei Datenkonsistenz dadurch gewährleistet wird, dass die Prozeduren nur solche Datensätze als Eingaben akzeptieren, die von der View auch angezeigt werden können (Schreib- und Lesekonsistenz). Salopp formuliert:

"Virtabs sind Views über mehrere Tabellen, in die man schreiben kann".

Virtabs sind ein Teil der Datenbank und damit auf dem Server lokalisiert.
Konzeptuell bilden sie eine eigene Ebene zwischen den Middle-tier- und Client -Anwendungsschichten und dem physikalisch vorhandenen RDBMS, da sie die Anwendungen vom Datenmodell des Servers vollständig abschirmen (Abbildung).

Einsatzmöglichkeiten von Virtabs:

Es gibt mehrere Entwicklungs-Szenarien, in denen sich der Einsatz von Virtabs bewährt hat:

  1. Überbrückung der Kluft zwischen abstrakter DB und konkreten GUIs:
    Virtabs können dazu benutzt werden, ein stark abstrahierendes Datenmodell vor den darauf aufsetzenden Applikationen zu verbergen, in dem für die Anwendungen virtuelle (physikalisch nicht existierende) Teildatenmodelle zur Verfügung gestellt werden.
    In der Datenbankprogrammierung tritt oft das Problem auf, dass sehr spezifische Anwendungsprogramme auf Basis von stark normalisierten Datenstrukturen nur mit überproportionalen Aufwand herstellbar und pflegbar sind. Das führt in der Regel entweder zu Modifikationen des Datenmodells (Denormalisierung) unter Einbusse von Universalität oder zur Durchreichung abstrakter Begriffe aus dem Datenmodell in die dann nicht mehr nutzerfreundlichen Anwendungen.
    Durch den Einsatz von Virtuellen Tabellen als Schnittstelle zwischen der Datenstruktur und den Anwendungsprogrammen kann das Design dieser beiden Ebenen letztlich vollständig voneinander unabhängig erfolgen und damit den jeweiligen Ansprüchen optimal gerecht werden.
    Man kann dies als ein „top-down-Szenario“ bezeichnen: Erst erfolgt ein abstarkter Gesamtentwurf, dann die Gestaltung der Einzel-Arbeitsplätze.
  2. Der Einsatz zur Integration verschiedener Arbeitsplatz-Dbs zu einer Gesamtlösung wurde schon erwähnt. Zu allen Teildatenmodellen der vorhandenen Arbeitsplätze wird eine abstraktes Gesamtdatenmodell gebildet. Falls die Einzellösungen schon vorher einigermaßen stark inhaltlich auf einander bezogen waren, sollte sich auch ein implementierbares Gesamtmodell finden lassen. Virtabs werden dann dazu genutzt, die Teildatenmodelle wieder auf Basis des abstrakten Gesamtmodells zu emulieren.
    Das ist ein „bottom-up“-Entwurf: Anwendungen und Teildatenmodelle sind gegeben, daraus wird ein abstrakte integrierendes Gesamtdatenmodell gebildet.
  3. Im praktischen Entwicklungsbetrieb müssen häufig zu späten Zeitpunkten noch Änderungen am Datenmodell durchgeführt werden (geänderte Anforderungen eines Moduls, oder Optimierungen). Dies führt in der Regel zu einem “Auseinanderbrechen” des ursprünglichen Entwurfs, da die Änderungen mit anderen Bereichen des Datenmodells nicht abgeglichen werden können. Dies würde ja im herkömmlichen Entwicklungsbetrieb die Änderung von möglicherweise schon getesteten Anwendungen bedeuten, die von der Änderung gar nicht profitieren würden.
    Findet die Entwicklung auf einem Virtab-Datenmodell statt, kann die darunterliegende Tabellenstruktur noch zu sehr späten Zeitpunkten geändert werden, ohne die darauf aufsetzenden Anwendungen zu destabiliseren.
    Dies kann man als die „pragmatische“ Anwendung von Virtabs bezeichnen.

Im praktischen Einsatz (ECO, POLARIS) konnte die theoretisch vorhergesagte Eignung der Virtabs als Mittel zur Isolation von Datenbank bzw. ER-Diagramm und Anwendungsprogrammen bestätigt werden: Änderungen im ER-Diagramm bedingten zwar die Neudefinition und Rekompilation der benutzten Virtabs, an den (teilweise sehr aufwendigen) Anwendungsprogrammen wurden aber nur noch vereinzelte Anpassungen nötig. Der Routinebetrieb musste nicht unterbrochen werden.

 

[Virtabs] [Positionierung] [Schreibbare Views?] [Schreibbare Views!] [Feature-Überblick] [Virtabs entwickeln] [Unterstützte Datenbanken] [Referenz] [Konzepte] [Application-Interfaces] [Struktur der Demo-DB] [Guided tour] [Beispiel-Code]