Der Einsatz relationaler Datenbanken stellt sich unter den heutigen Hardwarevoraussetzungen für den Benutzer noch relativ unwirtschaftlich dar. Die Systeme verursachen einen hohen Maschinenoverhead und haben sich somit bisher vor allem als Ressourcenfresser erwiesen. Für wirtschaftlich lukrative Anwendungen fehlt nach Ansicht von DB-Fachleuten der Rahmen aus neuer Betriebssoftware und modernen Rechnerkonzepten. Die volle Leistung relationaler Datenbanken wird denn auch erst mit der nächsten Maschinengeneration erwartet. Dennoch: Benutzer, die mit ihren hierarchischen Systemen insbesondere bei Online-Anwendungen auf "logische Grenzen" stoßen und sich zunehmend mit schlechten Antwortzeiten herumprügeln müssen, finden eine - wenn auch teure - Alternative.
Hans-Gerd Tühl
verantwortlich für den Bereich Systemtechnik, Applied Data Research (Deutschland) GmbH, Düsseldorf
Die Forderungen an ein Datenbanksystem stehen seit langem fest. Sie haben sich im mühsamen, zeitraubenden und öfters den Ansprüchen der Anwender nicht gerecht werdenden DV-Alltag ergeben.
Die wichtigsten sind Flexibilität, um neue Anforderungen einfach und schnell auf die bereits gespeicherten Daten projizieren zu können, Unabhängigkeit zwischen Datenstrukturen physischer beziehungsweise logischer Ebene und den DV-Anwendungen, um dadurch stabile Programme und gesicherte Investitionen zu erreichen und spontane Informationsbedürfnisse der Benutzer ohne Beschränkungen durch vordefinierte logische Pfade und ohne den gewöhnlich üblichen Anwendungsentwicklungsapparat.
Die - zumindest theoretische - Lösung dieser Problematik ist durch die Beschreibung des ANSI/SPARC-Architekturmodells für Datenbanksysteme und die Definition des relationalen Datenbankmodells bekannt.
Die DV-technische Lösung eines Systems, das diesen Forderungen entspricht, erfordert nicht notwendigerweise die Aufrüstung des vorhandenen Rechners um weitere Megabytes oder gar das Abwarten einer neuen Rechnergeneration, sondern ist bei wohlüberlegter Verwendung der vorhandenen Hardware durch das eingesetzte Softwaresystem DBMS durchaus möglich. Grundlage: Normalisierung der Daten.
Ziel des Datendesigns ist es, elementare, änderungsstabile logische Beziehungen, in denen die einzelnen Informationen zueinander stehen, zu erkennen und die Daten entsprechend zusammenzufassen. Speichermedium für die sich derart ergebenden Informationseinheiten sowie die für das schnelle Wiederauffinden der Informationen notwendigen Indices sind die üblichen DASD-Speicher. Bei der Beurteilung der praktischen Einsetzbarkeit und der zu erzielenden Performance derartiger DBMS innerhalb der heutigen Hardwareumgebung sind insbesondere folgende Aspekte von entscheidender Bedeutung:
Dynamik und Effizienz der Datenbankindices und deren Verwaltungsprozessoren sowie das ausgewogene Verhältnis von CPU-Belastung und notwendigen I-O-Operationen.
Natürlich haben weitere wichtige Einzelheiten wie zum Beispiel Unterstützung der Normalformen, Umfang, Güte und Einfachheit der Formulierung der angebotenen Sprachmittel zur Informationsgewinnung und -manipulation, Datensicherheit, Datenschutz etc. ihre wichtige Bedeutung.
In bezug auf das zu erwartende Verhalten des DB-Systems ist sicher generell die Orientierung der Systemarchitektur an den Forderungen nach möglichst geringer Belastung des Rechners bei guter Performance, auch und insbesondere bei gleichzeitiger Aktivität vieler Benutzer, entscheidend.
Derartige Software ist nicht nur denkbar und wünschenswert, sondern tatsächlich verfügbar.
Speziell in den Fällen, wo bei der Konzeption der DBMS durch die Softwareanbieter die eingangs erwähnten theoretischen Grundlagen berücksichtigt wurden, ist, da dies teilweise bereits mehrere Jahre zurückliegt, eine beachtliche Erfahrung im praktischen Einsatz solcher Systeme und natürlich eine an den genannten Grundlagen orientierte Evolution der DBMS zu verzeichnen.
Der interessierte DV-Verantwortliche ist sicher gut beraten, das Angebot des Softwaremarktes hinsichtlich derartiger Systeme sorgfältig zu prüfen und von den vorhandenen Erfahrungen der entsprechenden Benutzer zu profitieren.
Rolf-Dieter Witt
DV-Leiter, Paul Günther GmbH & Co., Hamburg
Sich die Frage zu stellen, warum Software-Produkte wie SQL und DB2 sich im Markt bisher nicht so durchgesetzt haben, wie vom Vertreiber dieser Produkte erhofft, erscheint mir zur Zeit nicht ganz logisch wenn dabei SQL und DB2 in einen Topf geworfen werden.
Die Ankündigung für DB2 liegt erst seit kurzem auf dem Tisch und wendet sich an einen begrenzten Nutzerkreis im Bereich der Großsysteme.
Für SQL ist die Fragestellung nach der Akzeptanz schon gültiger, da dieses Produkt schon seit circa 18 Monaten verfügbar ist.
Warum SQL vom potentiellen Anwenderkreis nur in beschränktem Umfang angenommen wurde, ist offensichtlich. Ein Hindernis liegt beim Anwender. Er befand sich in den vergangenen Jahren ständig in Systemumstellungen, um sein Batch-System auf Dialog umzustellen, machte Betriebssystemänderungen durch und wurde durch Datenfernübertragung mehr und mehr gefordert. Hierbei mag es zu Blickverstellungen gekommen sein, so daß, um unter Kostendruck gesetzte Unternehmensziele zu erfüllen, im ersten Schritt viele Lösungen durch Abänderung bestehender Anwendungen erfolgten, statt verbunden mit der entsprechenden Planungsphase, neue Konzepte zu überdenken. Die Systemprogrammierung war dementsprechend ausgelastet, Betriebssystemschwächen zu eliminieren und ein gutes Antwortszeitverhalten für die Dialoganwendungen, die sich ständig vermehren, sicherzustellen.
Darüber hinaus kann man davon ausgehen, daß der Einsatz von SQL eine erhebliche Performance-Verschlechterung bedeutet sowie einen zusätzlichen Kernspeicher erfordert. Die dafür notwendigen Reserven sind naturgemäß nicht im installierten System verfügbar, und damit setzt der Einsatz von SQL eine längerfristige Planung im Kosten-/Nutzen-Bereich voraus. Niemand wird also bereit sein, bestehende Anwendungen durch SQL abzulösen, sondern sich bei Neuanwendungen überlegen, ob aus dem Kosten-/Nutzenvergleich der Einsatz gerechtfertigt ist.
Die Anzahl der Anwendungen, bei denen der Endbenutzer mit Hilfe dieser Systeme selbständig Datenbearbeitung betreibt, ist zumindest auf dem kommerziellen Sektor noch sehr begrenzt, so daß auch von dieser Seite derzeit kaum Anforderungen gestellt werden. Die Initiative für die Einführung neuer Konzepte geht auch heute noch hauptsächlich vom Bereich Organisation/EDV aus.
Wenn man jedoch den Zeitraum bedenkt, der nötig war, hierarchische Datenbanken durchzusetzen, betrachte ich es als verfrüht, von einer Nicht-Akzeptanz zu sprechen Voraussetzung hierfür ist sicher, daß entweder ein Tuning im SQL erfolgt, welches zu weniger Kernspeicherbedarf und verbesserter Response-Zeit führen müßte oder Maschinen auf den Markt gebracht werden, die ohne Mehrkosten durch beschleunigte interne Geschwindigkeit die Mängel hardware-mäßig abstellen.
Grundsätzlich muß davon ausgegangen werden, daß sich relationale Datenbanksysteme in Zukunft abhängig von dem oben Gesagten durchsetzen werden. Begründung: Das Datenvolumen, welches bei Einführung eines solchen Systems vorhanden beziehungsweise bekannt sein muß, ist nur ein Bruchteil dessen, was in der Startphase eines hierarchischen Systems vorausgesetzt wird, um nicht ständig die Architektur ändern zu müssen. Dadurch wird der Einstieg wesentlich erleichtert.
Günter Srock
Leitung Systementwicklung Datenbanken, Geha-Werke, Hannover
Es besteht die Meinung, daß SQL nicht den Erfolg gebracht hat, den IBM sich versprach. Auch nach der Ankündigung von DB2 ist bei den Anwendern offenbar noch Zurückhaltung vorhanden.
Daraus ergibt sich die Frage, ob erst bei Einsatz einer neuen Rechnergeneration der Einsatz solcher Systeme sinnvoll wird. Zum anderen, ob relationale DB-Systeme unter Berücksichtigung der bereits angebotenen Hardware die Lösung der Probleme bringen.
Als Einführung zu diesem Thema erscheint es mir sinnvoll, kurz auf die Ursprünge von SQL/DS einzugehen.
Hauptziel des Ende 1968 seitens IBM an Edgar F.Codd und das Forschungszentrum San José vergebenen Forschungsauftrages war die Erarbeitung der theoretischen Grundlagen zur Behandlung logischer Aspekte von Datenbanken und DB -Verwaltungssystemen ohne Berücksichtigung jeglicher Performance-Überlegungen. Arbeitsergebnis war das Relationsmodell.
Bei der mit marketingtechnischer Brillanz 1981 erfolgten Ankündigung wurde darauf hingewiesen, daß in SQL/DS in DB-technischer Hinsicht viel Erfahrung (Zugriffsmethoden, Speicherzuordnung, Sperrung, Wiederanlauf) aus der Prototypenrealisierung, insbesondere des "Systems-R", enthalten ist. Gleiches gilt für die Query Language in bezug auf "QBE". Dennoch fiel auf, daß zu Performance-Fragen keine beziehungsweise unklare Statements abgegeben wurden.
Inwieweit die veröffentlichten Repliken mit Aussagen wie
- SQL/DS-Teile behindern sich gegenseitig,
- kein klares modulares Konzept und
- die alle Performance tötende "eierlegende Wollmilchsau" sind entstanden, bis hin zu "indiskutabel" zutreffen, entzieht sich meiner Beurteilung. Völlig aus der Luft gegriffen sind diese Aussagen jedoch nicht.
Fest steht aus heutiger Sicht, daß mit SQL/DS ein relationales DB-System entstanden ist, welches die Zielsetzung des Relationenmodells am weitesten verwirklicht (Strukturfreiheit, Navigation, relationale Kommandos) und mit "ISQL" eine mächtige, leicht anwendbare Online-Abfragesprache zur Verfügung steht.
Der wirklich gravierende Nachteil des Systems ist seine Gier nach Ressourcen (Zeit, Hauptspeicher, Plattenplatz).
Für Unternehmen mittlerer Größenordnung, das heißt, für den typischen Einsatzbereich der 4300-DOS/VSE gilt folgende grobe Rechnung:
- Virtueller Adressraum 16 MB, belegt durch Betriebssystem, Power, SVA rund 2 MB.
- CICS bei zufriedenstellenden Anwortzeiten rund 4 MB.
- VTAM rund 2 MB.
- SQL/DS minimal 1 bis 2 MB bei sinnvollem Durchsatz rund 6 MB.
Weitere Belegungsrechnungen erübrigen sich, da bereits zu diesem Zeitpunkt feststeht daß der verbleibende Rest für den Batch-Betrieb kaum ausreicht, insbesondere wenn DL/ und ICCF in die Rechnung aufgenommen werden.
Somit bedeutet zur Zeit die Einführung von SQL/DS im günstigsten Fall die Durchführung einer weiteren Sicht, im ungünstigsten Fall den Einsatz eines weiteren Rechners.
Daß es sich bei SQL/DS um ein ergänzendes Programmpaket zu DL/ handelt (beziehungsweise nur handeln kann), ergibt sich aus dem Ressourcenbedarf. Dies hat bei Einführung die Handhabung zweier DB-Systeme, deren Verschiedenheit aus DB-Sicht die größtmögliche ist, zur Folge. In bezug auf die Aktualität der Daten bedeutet die zwischen die DB-Systeme zu schaltende Extraktionseinrichtung in der Praxis häufig, daß man heute auf die Daten von gestern zugreifen kann.
Die marketingtechnische Argumentation der Vorteile, die sich aus dem Einsatz spezieller DB-Systeme für den unternehmensweiten EDV-Produktionsbereich sowie für Spezialaufgaben von Endbenutzern ergeben, sind zweifelhafte Rechtfertigungen und lassen sich ohne wesentliche Änderungen besser zum Beispiel für den Einsatz von PCs in den Fachabteilungen anwenden.
Fest steht weiterhin, daß bereits seit Jahren relationale DB-Systeme inklusive mächtiger Abfragesprachen im Einsatz sind und zur Zufriedenheit ihrer Benutzer laufen. Der Grund hierfür liegt darin, daß sie das zur Zeit vorherrschende Speichermedium - die Platte - stärker berücksichtigen, das heißt, erheblichen Aufwand in die Optimierung des Verwaltungs-, Speicherungs- und Zugriffsaufwandes von Indizes (invertierte Listen) investiert haben, über spezielle, schnelle Befehle zur Index beziehungsweise Datengewinnung und -manipulation für die Anwendungsentwicklung verfügen und die zeitaufwendigen "mächtigen" Befehle der Query Language vorbehalten.
Fazit: Bei der heute im Einsatz befindlichen Hardware bringt SQL/DS nicht die Lösung der Probleme. Dies gilt zumindest für Unternehmen mittlerer Größenordnung. Die Kosten der DB2-Version für MVS-Anwender sowie der Ressourcenverbrauch dürften jedoch auch Großunternehmen bei der Wirtschaftlichkeitsrechnung vor Probleme stellen.
Die Negativkriterien auf das Konto "Kinderschuhe" zu buchen, ist ein optimistischer Ansatz. Wahrscheinlicher ist, daß erst eine neue Rechnergeneration beziehungsweise der Assoziativspeicher als Ersatz für den Plattenspeicher den Durchbruch bringen, denn zum Erfolg ist SQL/DS als IBM-Produkt verurteilt.
Mario Zaleski
DB/DC-Vertriebsleiter der ADV/ORGA F. A. Meyer GmbH, Wilhelmshaven
Der IBM-Manager Robert H. Torgler schrieb unlängst in der IBM-Gazette "Information Processing": "Business Professionals (wie auch immer man dieses übersetzt) brauchen mehr als nur den bloßen Zugriff auf den Computer. Sie brauchen Hilfe, Ausbildung und fortwährende Unterstützung. Es liegt in der Verantwortlichkeit des DV-Managements, dieses zu liefern - als Anwendungssystem auf der Großrechenanlage, mit verteilter Datenverarbeitung, mit Personal Computern und/oder auf andere Art und Weise." Torgler schreibt weiter: "Ebenso muß gewährleistet sein, daß der Zugriff auf sensitive Informationen kontrolliert wird, die Computer-Ressourcen effizient genutzt werden und die Integrität der Datenbanken gewährleistet ist.
Diese Aussagen haben gerade jetzt, da Big Blue mit DB2 in den Bereich der Großanwender relationaler Datenbanken vorstößt, besondere Bedeutung. Warum?
Seit Jahren bemüht man sich in der Datenverarbeitung; dem Benutzer in der Fachabteilung Instrumente an die Hand zu geben, um aus den umfangreichen Datenbeständen Informationen zu erhalten. Man entwickelt Tools, lehrt Methoden, Hochsprachen, ja sogar Philosophien. Alles mit dem Ziel, die Endbenutzerbedürfnisse zu befriedigen. Aller Mühen zum Trotz ist das Zwischenergebnis: Ein Anwendungsentwicklungsstau, der bis an das Ende der 80er Jahre reicht, ein Wartungspotential, Kapazitäten bindet und ein Endbenutzer, der sich mehr und mehr von DV emanzipiert.
Sind relationale Datenbankensysteme die Zauberformel zur Lösung des Dilemmas? Eher scheint es, als beginne die Crux von neuem.
Denn es sei erwähnt, daß mehr als die Hälfte der bundesdeutschen Rechenzentren ihre eigenen, internen Informationsbedürfnisse teilweise gar nicht oder wenn, nur spärlich und mit viel Aufwand erfüllen können. Ein zusätzliches relationales Datenbanksystem hilft hier wohl kaum. Aber mit Sicherheit werden Hardwareressourcen gebunden und zusätzliche Administrationskapazitäten benötigt. Meist stellt sich auch die Frage: Was passiert mit der derzeitigen operativen Datenbank? Wenn keine vorhanden ist, scheint die Frage beantwortet. Wohlgemerkt scheint. Konvertieren? Niemals! Eine Koexistenz ist unvermeidbar, denn bis dato ist keine ausschließlich relationale Datenbank mit umfangreicher operativer Datenbasis auf Großrechnern im Einsatz, sofern diese nach kaufmännischen Gesichtspunkten arbeiten müssen. SQL/DS beweist diese Feststellungen: trotz sehr preiswerter Software nur eine geringe Akzeptanz.
Sicherlich kann mit relationalen Datenbanktechnologien eine ganze Menge Informationsdurst gestillt werden, jedoch sind die derzeit verfügbaren Systeme nicht die zukünftigen Allheilmittel. Dieses beweisen die Endbenutzer derzeit sehr nachhaltig. Viele Rechenzentren haben momentan mehr damit zu tun, ihre externe DV-Welt zu verstehen und für sich zu gewinnen, als die externen Informationswünsche zu befriedigen: Die sich rasend verbreitenden Personal Computer müssen in die technologischen Informationskonzepte einbezogen werden. Denn welchen Endbenutzer kann mit einer auf dem Großrechner laufenden relationalen Datenbank "hinter dem PC hervorlocken"? Für einen PC-Anwender sind Ausdrücke wie: Spreadsheet, Modelling und Graphics wohlgeläufige Begriffe. Vielleicht bietet man ihm ähnliches - jedoch für welchen Preis und mit welchem Komfort?
Im Hinblick auf die bereits sehr favorisierte Information Center-Technologie und die notwendige Einbindung von Personal Computern in das Informationsgefüge sind relationale Datenbanktechniken dagegen zwingend notwendig. Wobei der Begriff "relational" nicht allein die Datenspeicherung kennzeichnet, sondern zugleich die Benutzeroberfläche beschreibt, die so ausgeklügelt sein muß, daß vor allem der DV-Laie die "Informationsklaviatur" beherrscht.
Kommt man auf Torglers Äußerungen zurück, so erkennt man, daß die derzeitigen relationalen Datenbanksysteme durchaus in die richtige Richtung gehen. Jedoch müssen neben den Hardwareressourcen die DV-internen Administrationskapazitäten sinnvoll und optimaler genutzt werden. Dies bedeutet, Softwaresysteme mit verschiedenartigen Aufgaben müssen integrierbar sein, Redundanzen vermieden werden. Die Informationsintegrität muß gewährleistet sein. Gleichfalls ist es erforderlich den Blick in Richtung arbeitsplatzorientierter Informationsverarbeitung zu öffnen. Dem Personal Computer muß gebührender Respekt gezollt werden.
Fazit: Heute eingesetzte relationale Datenbanken müssen noch eine Menge mehr können, um auch in Zukunft einen Markt zu haben.