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:
-
Ü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.
-
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.
-
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.
|