Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

10.10.1986

"Relational Pretenders" bringen die seriöse RDBMS-Welt in Verruf

Im DBMS-Bereich ist der Begriff "relational" inzwischen zum Schlagwort geworden. Allerdings schmücken sich gerne auch solche Anbieter mit diesem Prädikat, die gar nicht über ein entsprechendes Produkt verfügen. Der Dumme ist wieder einmal der Anwender, der von diesen unrealistischen Versprechungen geblendet wird. CW sprach mit Ted Codd, dem "Vater des relationalen Modells", Chris Date, der an der technischen Planung der IBM-Produkte SQL/DS und DB2 beteiligt war, sowie Sharon Weinberg, Präsidentin der Codd and Date- Unternehmensberatung.

- Welche generellen Trends sind in den nächsten Jahren im DBMS-Bereich zu erwarten?

Codd: Meiner Ansicht nach wird es vor allem Entwicklungen geben, die über ein Interface "oberhalb" der relationalen Systeme aufsetzen. Ein Paradebeispiel hierfür sind die Expertensyteme. Der Grund hierfür ist meiner Ansicht nach, daß es für die Anbieter leichter ist, Schnittstellen zu relationalen Systemen anzubieten als zu nicht-relationalen.

- Warum ist dies der Fall?

Codd: Schon in einer meiner frühen Veröffentlichungen zum relationalen Modell aus dem Jahre 1970 habe ich geschrieben, daß es sehr wichtig ist, den informationsverarbeitenden und den kognitiven Bereich zusammenzuführen. Aufgabe des DBMS ist dabei natürlich das Speichern von Informationen, beispielsweise über ein Unternehmen, und das Handling der Transaktionen. Damit ist aber die Notwendigkeit noch nicht abgedeckt, in bestimmten Fällen auch logische Schlußfolgerungen ziehen zu müssen. Mir erschien es bereits damals wichtig, diese beiden Welten, die bis dato ja ein vollständiges Eigenleben geführt hatten, einander anzunähern. Deshalb habe ich mich auch schon sehr früh dafür ausgesprochen, daß die Prädikatenlogik auch in die Bereiche Sprach-Interfaces und Benutzerebene einfließen sollte. Unter dieser Voraussetzung ist es nämlich auch relativ einfach, Schnittstellen zu Inferenzsystemen zu entwickeln.

- Wird es also zu einer Koexistenz von relationalen Systemen und wissensbasierten Systemen kommen?

Date: Ja, das ist zumindest ein Aspekt dieser Entwicklung. Es zeichnet sich aber auch ab, daß die relationalen Systeme die älteren Produkte mit hierarchischem oder netzwerkorientiertem Aufbau ins Abseits stellen werden. Natürlich bedeutet das nicht, daß all diese DBMS von heute auf morgen eingestampft werden; dazu haben die Anwender viel zu viel in solche Erzeugnisse investiert.

- Ist damit zu rechnen, daß die relationalen Systeme eines Tages genauso von einer neuen Technik überholt werden?

Date: Ich glaube, daß es auch in Zukunft keine Entwicklung geben wird, die die relationalen Systeme von der Bildfläche verdrängen könnte. Natürlich gibt es momentan keinen schlüssigen Beweis für diese These. Fest steht aber, daß den relationalen Systemen eine sehr solide Basis zugrunde liegt und die wird sich auch in Zukunft nicht anfechten lassen.

- Warum sind dann aber viele Anwender unzufrieden mit ihren relationalen DBMS-Produkten?

Date: Einige Anbieter spiegeln ihren Kunden in dieser Hinsicht falsche Tatsachen vor. Ich möchte nicht beurteilen, ob das vorsätzlich oder ohne bösen Willen geschieht, aber es ist auf alle Fälle eine sehr verbreitete Unsitte. Dem User wird erzählt, ein bestimmtes Produkt sei relational - und der Anwender glaubt das natürlich. Dabei entsprechen viele der derart angepriesenen Erzeugnisse dem relationalen Modell in keinster Weise.

- Herr Codd, Sie sind bekannt als Kritiker der vorgeschlagenen ANSI-Standards für relationale Datenbankmanagementsysteme. Dementsprechend fordern Sie eine Modifikation dieser Richtlinie entsprechend dem relationalen Modell. Wie sollte ein solcher Ansatz Ihrer Ansicht nach aussehen?

Codd: Dieser Standard ist zunächst einmal unzureichend hinsichtlich der Tatsache, wie er mit der Datenbeschreibung umgeht. Der hier verwendete Codasyl-Ansatz ist ausgesprochen altmodisch. Die Datenbeschreibung empfinde ich als sehr statisch und damit wird ein sehr wichtiger Bestandteil des relationalen Ansatzes nicht eingefangen: die Möglichkeit, die Datenbeschreibung dynamisch zu verändern, genauso wie Daten verändert werden. Das System sollte außerdem über ein ausgefeiltes Locking verfügen. Die Kommunikation mit dem Server kann "unter der Oberfläche" ablaufen, wenn dies theoretisch machbar ist. Der Anwender muß auch darüber informiert werden, wenn ein im Applikationsprogramm unbedingt benötigter Part der Datenbeschreibung gelöscht wird. Denn diese Information ist ja nicht mehr in der Datenbank verfügbar.

Weinberg: Das ist nur eines der Probleme, speziell bei SQL. Zunächst verfügt diese Query Language über keine umfassende Datenuntersprache, wie das für das relationale Modell charakteristisch ist. Nicht nur die Datendefinition wurde vollständig ignoriert, sondern auch die tatsächliche Zugangskontrolle. Die Arbeit läuft hauptsächlich mit Autorisierungssprachen ab. Dabei haben die Anbieter vollständige Sprachen implementiert. Mit anderen Worten: Hersteller wie IBM oder Oracle haben nicht nur die Manipulation, sondern auch die Definition und Datenkontrolle implementiert. Daher machte der Normungsausschuß einen Rückschritt, indem er an der alten Codasyl-Verbindung festhielt. Das ändert aber nichts an den bekannten Problemen mit SQL und das Komitee hat auch keinen Versuch unternommen, sie bei der Standardisierung in den Griff zu bekommen.

- Woran liegt dann diese Rückständigkeit des Normungsausschusses?

Date: Man muß einmal verstehen, wie diese Organisationen arbeiten. Die Repräsentanten in diesem Komitee kommen fast ausschließlich aus dem Lager der Hersteller, hinzu gesellen sich einige Vertreter der Regierung in Washington. Die User stellen in diesen erlauchten Reihen nur eine Minorität dar. Und dieses Gremium definiert dann einen Standard, der von den Anwendern benutzt werden soll. Natürlich müssen die Hersteller ihre eigenen Interessen schützen. Folglich wurde der Standard als "Kreuzung" zwischen verschiedenen bereits verfügbaren Implementierungen festgeschrieben. Dabei gibt es heute keine zwei Implementierungen, die einander vollständig entsprechen würden - nicht einmal bei der IBM.

Weinberg: Diesem Problem unterliegen viele Standardisierungsbemühungen. Bei den Anwendern scheint ein Motivationsmangel zu herrschen, wirklich aktiv in einem solchen Ausschuß mitzuwirken. Eine Ausnahme bilden höchstens einige Regierungsstellen.

- Ist das nicht auch ein finanzielles Problem?

Weinberg: Nicht ausschließlich. Ich glaube, daß es vor allem eine Inflexibilität und ein Mangel an Interesse ausgerechnet bei den Leuten ist, die eigentlich am meisten davon betroffen sind. Wenn man sich einmal die historische Entwicklung der DV anschaut, so haben die Anwender den Herstellern nie gesagt, welche Aufgaben sie mit einem Rechner lösen wollten und welche Funktionen sie dazu benötigten. Immer haben die Vertreter der Industrie eine neue Technik erfunden und dann einen Einsatzbereich für diese Errungenschaft beim User gesucht. Damit sich an dieser Situation etwas ändert, müssen die Anwender viel aktiver werden und sich ihrer Mitverantwortung stellen.

Date: Eine große Gefahr des ANSI-Standards sehe ich übrigens auch darin, daß viele Anbieter, die nicht wirklich über ein relationales System verfügen, lediglich diese Norm implementieren werden und dann behaupten wollen, ein relationales System zu haben. Dabei wird hier nur ein verschwindend kleiner Teil dessen abgedeckt, was eigentlich vorhanden sein sollte.

- Wie steht es um die Konsistenzproblematik in verteilten Datenbanksystemen und was ist mit den schlechten Antwortzeiten, die von den Anwendern moniert werden?

Date: Die verteilten Systeme sind jetzt groß im Kommen. Es wurden bereits Performance-Tests durchgeführt, und einige Produkte schnitten dabei sehr gut ab.

Weinberg: Meiner Ansicht nach, wird in der gesamten DB-Diskussion die Performance gerne als Sündenbock abgestempelt, weil die Leute die Technologie gar nicht verstehen, über die sie reden. In diesem Bereich gibt es viele selbsternannte Experten, die sich allein durch ihre Fähigkeit, sich selbst zu vermarkten, einen Namen gemacht haben. Aber wenn die Oberfläche angekratzt wird, haben sie keine Ahnung davon, was eigentlich Sache ist. Also reden sie nur darüber oder sie kritisieren. Das trifft speziell für die verteilten Datenbanken zu. Außerdem: Die heutige Diskussion um die verteilten DBs entspricht exakt den Debatten aus den Anfangstagen des relationalen Konzepts. Vieles davon hat sich bis in die Gegenwart hinein fortgesetzt. Dabei sind noch gar nicht alle Fähigkeiten dieser Systeme implementiert. Und ein Konzept nur danach zu beurteilen, was bereits implementiert ist, halte ich für sehr kurzsichtig, weil sich leicht irreführende Schlußfolgerungen ergeben.

- Das führt eigentlich wieder zu dem Problem zurück, daß die Anwender mit neuen Technologien regelrecht überschüttet werden. Ihr eigentliches Problem liegt aber in der Praxis oft darin, daß sie mit ihrem "Datenfriedhöfen" nicht mehr klarkommen. Was sollte hier in Zukunft getan werden?

Codd: Diese "verlorenen" Daten sind ein Problem, das mir schon oft begegnet ist. Nicht einmal IBM-Datenbanken sind dagegen gefeit. Ich bin schon mehrmals zu den Datenbankverwaltern gegangen und habe sie gefragt: "Okay, was ist in eurer Datenbank?" Darauf erhielt ich zur Antwort, das Thema sei zu umfangreich, um es in einer Konversation abhandeln zu können. Die zweite Antwort war: "Ich muß in der Dokumentation nachschauen und werde Sie früher oder später zu diesem Thema anrufen." Etwa eine Woche später klingelte sich dann mein Telefon heiß. Manche Gesprächspartner hatten die Informationen gefunden. Das finde ich dann ganz in Ordnung, denn so jemand wußte zumindest, daß entsprechende Informationen existieren und hatten sich um die Frage gekümmert. Eine andere Reaktion war: "Ich kann es nicht finden, aber ich weiß, daß es vorhanden sein muß, weil sonst bestimmte Applikationen nicht laufen könnten." Ich glaube, der Grund für diese Probleme mit den "begrabenen" Daten ist die Tatsache, daß es den betreffenden Anwendern erlaubt war, Informationen auf ihre eigene Art einzutragen. Ich bin nicht gegen eine Verschlüsselung der Daten zu Kompressionszwecken, aber ich habe etwas gegen individuelle Programme, die entscheiden, wie es gemacht wird. Meiner Ansicht nach sollte das Aufgabe des Systems sein, denn anderenfalls gibt der Datenbankverwalter die Verantwortung ab, die Integrität des Systems zu bewahren.

- Manche Anwender behaupten ja, daß sie für ihre individuellen Applikationen gar kein relationales System benötigen. Als Grund führen sie auf, sie könnten die Vorteile eines solchen Produkts sowieso nicht ausreizen. Außerdem würden zu viele Ressourcen gebunden und die Performance leide. Wie können es die Anbieter rechtfertigen, solche User zum Kauf eines RDBMS zu überreden?

Date: Es gibt einige relationale Systeme, die wirklich mit einer guten Leistung aufwarten. Der springende Punkt liegt darin, daß die Last, gute Performance zu bringen, bei einem RDBMS dem System übertragen ist und nicht dem Anwender. Hat der User ein relationales Produkt, das nur eine unzureichende Leistung bringt, so liegt die Schuld beim Anbieter, weil er kein gutes System entwickelt hat. Und genau diese Vertreter der DV-Industrie geraten immer stärker in Zugzwang, weil es inzwischen wirklich qualitativ hochwertige Produkte gibt. Natürlich ist die Technik noch relativ neu. Aber trotzdem können manche relationalen Systeme eine Performance aufweisen, die vielleicht noch nicht voll mit der von älteren Produkten mithalten kann, aber deren Leistungsfähigkeit doch schon sehr nahe kommt. Ähnlich war es ja auch vor einigen Jahren, als die Auseinandersetzung zwischen den höheren Programmiersprachen und dem Assembler ihren Gipfel erreicht hatte. Als Fortran auf den Markt kam, wollten die User bei Assembler bleiben, weil es hieß, Fortran könne nicht mit einer vergleichbaren Leistung aufwarten. Und heute programmiert fast niemand mehr in Assembler.

- Herr Codd, IBM hat Sie mehrmals beschuldigt, öffentlich das IMS kritisiert zu haben . . .

Codd: Das war folgendermaßen: Vor einigen Jahren bin ich einmal nach London geflogen, um vor der British Computer Society einen Vortrag zu halten. Ich wurde mit den für Großbritannien zuständigen Marketingleuten von IBM konfrontiert. Sie verlangten, daß ich mich bei meinem Referat an zehn Regeln halte. Ich wollte natürlich wissen, was diese zehn Vorschriften beinhalten sollten, denn ich äußere mich nicht zu etwas, was ich nicht gesehen habe. Also zeigte man mir diese Guidelines. Das zehnte Postulat war, daß ich etwas Positives über IMS zu sagen hätte. Ich antwortete, daß ich nicht 6000 Meilen zurückgelegt hätte, um IMS zu diskutieren und nicht daran dächte, dieses Produkt zu erwähnen. Also ließen sich die Marketingleute breitschlagen, daß ich mich nur an die übrigen Regeln zu halten hätte und das konnte ich akzeptieren. Am nächsten Morgen stellte mich ein Professor der Londoner Universität dem Auditorium als den Mann vor, der mit einem Federstrich in zwei oder drei Artikeln IMS demontiert hatte. Ich sollte noch ergänzen, daß dieser Herr ein Codasyl-Abhänger war und etwa 50 Prozent der hundert Zuhörer aus den Reihen der IBM kamen. Natürlich dachte ich, jetzt würde ich unheimliche Schwierigkeiten mit all diesen Leuten bekommen. Also habe ich in diesem Fall IMS sogar verteidigt, indem ich sagte, für ein gegenwärtig verfügbares Produkt sei IMS kein wirklich schlechtes System. Und damit beendete ich auch gleich diese Vorstellung. Nachher habe ich mir diesen Typ zur Brust genommen und ihn ziemlich fertiggemacht. Ich mußte IMS in diesem Fall einfach verteidigen. Aber ich habe stets öffentlich und privat die Meinung vertreten, daß IBM nicht plötzlich den Support für IMS stoppen, sondern die Wahl dem Anwender überlassen sollte. Ich habe genug Vertrauen in den relationalen Ansatz um zu glauben, daß die Anwender vernünftig genug sind, um sich für das relationale Konzept zu entscheiden.

Weinberg: In diesem Zusammenhang möchte ich noch auf einen weiteren wichtigen Punkt hinweisen User, die eine negative Meinung zu relationalen Systemen haben, sind normalerweise mit einem solchen Produkt schon einmal auf die Nase gefallen. Sie haben sich ein System angeschaut, von dem der Anbieter behauptet, es sei relational. Der Anwender erkennt irgendwann die Schwächen und Probleme dieses Produkts und kommt damit nicht zurecht. Dann ist er natürlich verprellt und will nichts mehr von der relationalen Idee wissen. So etwas passiert aber vor allem mit den Systemen, die nicht wirklich relational sind. Denn "relational" ist für die DV-Industrie heute zum Marketingartikel geworden, weil jedermann heute glaubt, auf dieser Welle mitschwimmen zu müssen...

Codd: . . . Solche Leute nenne ich "relational pretenders". . .

Weinberg: . . . Und diese Anbieter haben in entscheidendem Maße zum schlechten Ruf der RDBMS beigetragen. Produkte, die in diese Sparte fallen, sind unter anderem IDMS/R, DatacomDB, Adabas, Model 204 der Computer Corporation of America. Wahrscheinlich habe ich jetzt das eine oder andere Produkt nicht genannt, aber das sind die wichtigsten.

Codd: Eine Sache muß man der IBM lassen: Sie hat nie behauptet, IMS sei relational. Ich bin dankbar dafür.

- Gibt es denn heute überhaupt ein Produkt im Markt, das alle Anforderungen des relationalen Modells voll erfüllt?

Codd: Ich kenne keines. Kürzlich habe ich Anrufe von Anbietern bekommen, die wissen wollten, wie es in dieser Hinsicht um ihre Produkte steht. Ich habe ihnen gesagt, sie sollten mir die entsprechenden Manuals schicken und ich würde ihnen dann Bescheid geben. Wenn ich dann Handbücher bekam - von manchen Anfragern habe ich nie wieder etwas gehört - zeigte sich sehr schnell, daß keines der Systeme vollständig relational war. Einige Anbieter glauben, sie könnten schnell in den Markt der relationalen Systeme einsteigen, indem sie einfach ein DBMS herausbringen, das einige der Eigenschaften unterstützt. Sie bilden sich ein, das sei einfach über das Marketing zu machen. Aber was mich betrifft, soll ihnen das nicht gelingen.

Weinberg: Meiner Erfahrung nach gilt das für alle Hersteller, die diese älteren Systeme haben und den SQL-Standard implementieren wollen. Wenn solche Anbieter diesen Minimalstandard implementiert haben, werden sie behaupten, relational zu sein. Diese Methode ist sehr offensichtlich.

- Wie müssen die Anwendungsprogramme strukturiert sein, um von allen Vorteilen künftiger DB-Entwicklungen profitieren zu können?

Date: Da gibt es ein ganz einfaches Kriterium: Um relationale Systeme wirklich auszureizen, muß der User anders denken, als er es bisher gewohnt war. Es ist erforderlich, auf dem Niveau zu denken, ganze Sets von Records in einer Operation zu verarbeiten. Ich habe Programme gesehen, die von Programmierern der alten Schule erstellt waren. Diese Leute schreiben immer noch Sequel-Statements, indem sie Eintrag für Eintrag einlesen. Dabei gehen viele Vorteile des relationalen Modells verloren. Das Programm wird zwar laufen, aber keine gute Performance bringen. Es sind also nicht die jüngeren DV-Mitarbeiter, die umlernen müssen, sondern die älteren . . .

Codd: . . . Und das Problem ist, daß genau diese Leute, an denen wir arbeiten müssen, in die höheren Managementpositionen aufsteigen.

- Es gibt Analysten, die behaupten, daß einige Produkte der Mitbewerber Erweiterungen früher verfügbar machen als das IBM-Produkt DB2. Was bedeutet das für die künftige Stellung von DB2 im Markt und gibt es für den Anwender überhaupt eine echte Alternative zu DB2?

Codd: Ich denke, daß DB2 hinsichtlich der Performance führend ist. Zwar hat es einige der Merkmale nicht, die zum Beispiel "Supra" von Cincom aufweist. Aber auch "Supra" wiederum fehlen einige Kriterien, die eigentlich notwendig sind. Trotzdem glaube ich, daß Cincom einer der vielversprechendsten Hersteller im DBMS-Bereich ist. Dieser Anbieter hat nämlich erkannt, daß sein altes System nicht relational war. Und Cincom hat nicht versucht, das System mit einer relationalen Tünche zu überziehen. Das ist sehr ehrlich und dafür möchte ich ein großes Lob aussprechen. Und dieses Unternehmen hat auch versucht, über das hinauszugehen, was beispielsweise bei DB2 Integritätsunterstützung heißt. Natürlich ist es schwer zu prognostizieren, ob Cincom mit diesem Produkt Erfolg haben wird. Das hängt von den Marketingfähigkeiten ab und davon, ob sie mit diesem System eine sehr gute Performance erzielen können.

Weinberg: Hier wäre es sicher interessant, mit Benchmarks zu arbeiten. Und das ist etwas, was wir irgendwann einmal sicher tun müssen. Doch zurück zu DB2: Meiner Ansicht nach hat IBM hier eine signifikante Führungsposition übernommen, indem ein rudimentäres Set elementarer Funktionen durch ein Produkt mit guter Performance ausbalanciert wurde. Diese Sache ist jedoch noch nicht beendet und ich glaube, daß IBM - ob man das in Armonk erkennt oder nicht - einen sehr schweren Weg vor sich hat.

- Was werden für Big Blue die Hauptprobleme Sein?

Weinberg: Da gibt es mehrere. Zum einen ist nicht vollkommen klar, ob sich das gesamte Unternehmen dem relationalen Gedanken verschrieben hat, auch wenn die "General Products Division" diesen Anschein erwecken möchte. Zweitens dauert der Entwicklungszyklus bei der IBM sehr lange und es braucht sehr viel Zeit, bis Funktionen verfügbar sind. Schließlich scheint es bei IBM Interessengruppierungen zu geben, die andere Technologien verfolgen und sich mit B2 ein Kopf-an-Kopf-Rennen um mehr Ressourcen liefern. Alles in allem könnte es durchaus passieren, daß IBM seine Führungsposition im Datenbankbereich verliert.

Codd: Ich persönlich glaube kaum, daß die IBM ihre Spitzenreiterposition räumen muß. Vielmehr befürchte ich, daß DB2 innerhalb der IBM durch Irreleitung korrumpiert wird. Man kennt ja den Spruch: IBM trifft zwar nicht immer die richtige Entscheidung, tut aber alles, um eine Entscheidung richtig zu machen.

- Die Anwender versprechen sich viel von den sogenannten Sprachen der vierten Generation. In welchem Ausmaß werden die 4GL-Konzepte die DB-Technik beeinflussen und was kann sich der Benutzer davon erhoffen?

Codd: Die 4GLs sind Labels, die noch nach einer Definition suchen. Mit anderen Worten: Soweit ich weiß, gibt es noch keine brauchbare Definition dessen, was eine Sprache der vierten Generation ist. Deshalb kann auch jeder beliebige Anbieter behaupten, ein 4GL-Produkt in der Angebotspalette zu haben und man kann nichts dagegen tun. Bei den relationalen Systemen hingegen sieht es ganz anders aus. Es gibt eine exakte Definition und wir können uns Hersteller zur Brust nehmen, die unberechtigt behaupten, relationale Produkte zu besitzen. Natürlich werden die Sprachen der vierten Generation nicht plötzlich von der DV-Szene verschwinden, auch wenn sie als Klasse noch nicht definiert sind. Was jedoch geschehen wird - Ansätze dafür lassen sich bereits heute feststellen - ist, daß die 4GLs den Benutzern als Sprache aufgedrängt werden, die gemeinsam mit einem relationalen Produkt verfügbar ist. Ein relationales System ist aber nur als Instrument zu verstehen, mit dem Daten in einer Datenbank gehandhabt werden. Und dieser Aspekt fehlt den Sprachen der vierten Generation völlig.

Date: Natürlich ist abzusehen, daß man nicht auf alle Zeiten mit Sprachen wie Cobol arbeiten wird, auch wenn man ihnen relationale Funktionen hinzugefügt hat. Sie sind einfach nicht mehr ausreichend für höhere Ansprüche. Die Hersteller haben dann angefangen, für diesen Anforderungsbereich verschiedene Applikationsgeneratoren zu entwickeln. Eigentlich sind all diese Interfaces eigene Sprachen. Und irgendein dummer Mensch brachte dann plötzlich den Begriff "Sprachen der vierten Generation" auf. So kam es zu dieser Bezeichnung. Schließlich lieben die Menschen ja Schlagworte und große Namen, darauf springt eigentlich fast jeder an. Sobald ein Hersteller bekannt gibt, daß da irgendetwas im Busch ist, will es die Majorität der Leute sofort haben - und schon blüht das Geschäft.