Datenbank

Interview

Von Datenbank- und anderen Päpsten
Interview mit Hartmut Wedekind

Nach Peter C. Lockemann kommt heute mit Hartmut Wedekind ein weiterer Vertreter der "Gründerväter" der deutschen Datenbankszene zu Wort. Geboren 1935 in Bochum, studierte er Wirtschaftsingenieurwesen (Fachrichtung Maschinenbau) in Darmstadt und anschließend Operations Research und Angewandte Mathematik in Berkeley. Nach 7 Jahren Industrietätigkeit kehrte er 1969 als ordentlicher Professor an die TH Darmstadt zurück, wo er Mitbegründer der Fakultät für Informatik und ab 1972 deren erster Dekan war. 1979 zog es ihn an die Universität Erlangen-Nürnberg, wo er bis zu seiner Emeritierung im Jahr 2000 blieb. Noch heute hält er regelmäßig Vorlesungen – und das nicht nur in Erlangen, sondern auch in Darmstadt und Jena (wo er auch Ehrendoktor ist). HW (Hartmut Wedekind) wurde befragt von KRD (Klaus R. Dittrich, Universität Zürich).

KRD: Lieber Herr Wedekind, seit mehr als 3 Jahrzehnten gehören Sie zu den führenden Wissenschaftlern im Bereich der Datenbanken. Ich habe in meinem Bücherregal gekramt und Ihr Werk "Datenorganisation" gefunden, das ich mir als junger Student 1975 gekauft hatte und das damals bereits in der 3. Auflage erschienen war. Dort findet sich vieles, was heute unter "Algorithmen und Datenstrukturen firmiert", und Ihr letztes Kapitel (Zitat) "stellt einen Versuch dar, die neueren Vorstellungen zu großen und komplexen Datenorganisationen zu skizzieren" und spricht von "vielversprechenden Ansätzen ... die hoffen lassen, dass schon in der nicht mehr allzu fern liegenden Zukunft größere Datenbankorganisationen vorzufinden sind".

Wie recht Sie damit hatten! Fast gleichzeitig mit dieser Neuauflage erschien auch bereits Ihr BI-Taschenbuch (was waren Bücher damals handlich!) "Datenbanksysteme I", wohl mit das erste deutschsprachige Lehrbuch zu diesem Thema überhaupt.

Doch von Ihrem Studium (Wirtschaftsingenieurwesen, Fachrichtung Maschinenbau) her war nicht unbedingt vorgezeichnet, dass Datenbanken einmal Ihr Hauptthema werden würde. Wie ist es dazu gekommen?

(Größere Version durch Anklicken) HW: Das Samenkorn hat bei mir während meines Studiums an der TH Darmstadt (1955-60) der Rechnerpionier und -papst Prof. Alwin Walther gelegt. Walther baute nicht nur Rechner (DERA), er schaffte auch Rechner an. Damals war es die IBM 650, ein Trommelrechner, auf dem wir "herumprogrammieren" durften. Für Aufgabenstellungen vom Typ "Mittelwert und Streuung berechnen" brauchten wir drei Wochen, bis das Programm lief.

Es folgte dann 1961/62 ein für mich sehr fruchtbarer Studienaufenthalt im Rahmen eines NATO-Stipendiums an der University of California Berkeley, wieder bei einem Papst, diesmal war es G. B. Dantzig, der sich mit linearer Programmierung befasste und der erst vor kurzem gestorben ist. Es stand uns eine IBM 7090 zur Verfügung, damals ein kapitaler Rechner der Spitzenklasse.

Bei dieser IBM-Orientierung war es dann kein Wunder, dass ich 1962 direkt bei der IBM landete. Ich hab's bis zum leitenden Systemingenieur geschafft. Die Basis war dort die "kaufmännische" IBM 1401, eine sagenumwobene Maschine mit ungeheuren, für einen Rechner noch nie da gewesenen Absatzzahlen. IBM 1401, das war der VW-Käfer unter den Rechnern und für die IBM eine einzige Erfolgsstory, die erst mit der IBM /360 beendet wurde. Ich habe nur noch in 360-Kursen gesessen. Gemacht habe ich nichts mehr auf dieser riesigen Rechnerfamilie (von klein bis groß). Denn ich wurde 1969 an die TH Darmstadt berufen, auf den Lehrstuhl für Betriebswirtschaftslehre. Damals schrieb ich dann auf meiner IBM-Basis das Buch "Datenorganisation". Es war schon bei der IBM klar, dass ich ein "Data-Cruncher" würde, kein "Number-Cruncher", wie man damals die vornehmeren Herren vom wissenschaftlichen Rechnen nannte.

Ganz zentral für mich war dann meine Sabbat-Zeit 1973 bei IBM Research in San Jose. Jetzt war ich gleich unter mehreren Päpsten: Ted Codd, Jim Gray, Vincent Lum, Don Chamberlin, Raymund Lorie etc. Codd hatte gerade seine berühmten Aufsätze zum Relationenmodell geschrieben, und man ging daran, ganz ohne Ted Codd, das Projekt "System R" in Angriff zu nehmen. Leider habe ich diese Entwicklung dann nur noch aus der Ferne verfolgen können, denn ich musste wieder nach Hause. Aber es war eine herrliche Zeit. Was mich damals aber auch tief beeindruckt hat, war die Entwicklung der DBMS-Schichtenarchitektur unter Ed Altman, meinem damaligen Gruppenleiter. Das Paper "Data Independent Accessing Model" erschien damals (bei SIGFIDET, Vorgänger von SIGMOD) und zeigte erstmals Abstraktionsschichten im Datenbereich auf. Bekannt waren damals nämlich nur die Abstraktionsschichten Dijkstras im Ansatz des Betriebssystems THE.

Es war eine rasante Zeit, eine Zeit des Aufbruchs, und ich war mittendrin. War es Glück oder eigenes Handeln? Beides. Aber wie viel Prozent Glück und wie viel Prozent eigenes Handeln, das darf man mich nicht fragen.

Ich wurde 1972 Gründungsdekan der ersten deutschen Fakultät für Informatik in Darmstadt. "Erste Fakultät für Informatik gewesen zu sein", das behaupten wenigstens die Darmstädter. Ich weiß, dass die Karlsruher anderer Auffassung sind. Aber das sind bloß Spielereien, die zur Sache nichts beitragen.

Zur Sache beigetragen hat aber das ÜRF des Bundes (Überregionale Forschungsprogramm), dem die Informatik-Fakultäten in Deutschland ihr Lebenslicht verdanken. Nicht nur die Fakultäten auch die GI ist bei genauem Betrachten ein Kind dieses Programms. Da ich ÜRF-Vertreter der TH Darmstadt in Bonn war, wurde ich 1969 Gründungsmitglied der GI. Das ergab sich einfach so.

Um mit dem Moore'schen Gesetz zu sprechen, wonach alle 15 Jahre drei Zehnerpotenzen in Sachen Leistung und Kapazität durchmessen werden:

Ich komme mit meinen 71 Jahren aus der Kilozeit (10³) 1960, aus dem "Mittelalter", und war "1401-Kiloprogrammierer". Dann ging's richtig los. Megazeit (10⁶): 1975 mit den ersten DB-Systemen. Dann die verteilten DB-Systeme in der Gigazeit (10⁹): 1990. Und heute – 2005 in der Terazeit (10¹²) – ist alles mobil.

Aber über diesen "Wahnsinn", der sich zu meinen Lebzeiten ereignete, können wir ja noch weiterreden. Aber besser Wahnsinn als wissenschaftliche Langeweile. Die gab's definitiv nicht.

KRD: Ihr Sabbatical im Umfeld von System R erklärt sicher auch, warum Sie als einer der Ersten in unseren geografischen Breitengraden auf das relationale Datenmodell gesetzt haben. Was hat Sie damals so sicher gemacht, dass dies das "richtige Pferd" sein würde?

HW: Es ging Ted Codd (1923-2003) um ein elementares, leicht überschaubares Datenmodell mit Minimaleigenschaften, auf das dann logisch beliebig komplexe Anfragen abgesetzt werden können. Er schrieb an die Tafel der Interessierten auf dieser Welt: R (N, A₁, A₂, ..., A_n) und nannte R den Relationennamen, N den Primärschlüssel und die Ai Sekundärschlüssel oder Attribute. Ted stand in der britischen Logiktradition des großen Vorbilds Bertrand Russell und machte daraus auch keinen Hehl. Ted war Brite und blieb Brite. Über die mathematische Deutung einer Relation als Untermenge eines kartesischen Produktes war er nicht besonders glücklich. Verhindern konnte er die Lesart aber nicht. Es gab nun noch einen anderen Papst zu der Zeit in meinem Leben und der hieß Paul Lorenzen (1915-1994) und war Professor für Logik in Erlangen. Etwa zur gleichen Zeit (so um 1970) schrieb Lorenzen an die Tafel: N ε (A₁, A₂, ..., A_n) R und nannte das, ganz in der Tradition eines Gottlob Frege, einen Elementarsatz. N war für ihn ein benennender Ausdruck und hieß Nominator. ε war die Kopula, die einen nominativen Ausdruck mit dem rechtsstehenden prädikativen Ausdruck verband. Die A_i nannte er Apprädikatoren (Zusatzprädiktoren), die erst vergeben werden können, wenn zuvor der Prädikator R einem mit N eindeutig benannten Objekt zugesprochen war. Beide, Codd wie Lorenzen, überwanden damit den logischen Atomismus eines Frege und Russell, der nur einen Typ von Prädikator kannte. Das war eine wissenschaftliche Großtat ersten Ranges. Frege und Russell hatten halt nur Mathematik und Physik als Anwendungen im Sinn. Ich habe mit Ted diese Deutung des Relationenmodells diskutiert. Er war sehr angetan, hielt aber diese Deutung in der Welt des "business", in der er lebte, für nicht durchsetzbar. Jim Gray, der Star-Implementierer von System R, wollte überhaupt nichts von Sprachlogik wissen. Codd und er, beide Turing-Preisträger 1981 bzw. 1998, standen sich sehr reserviert gegenüber. Und doch war Jim nach Ted für die Genesis des Relationenmodells der entscheidende Mann. Mit seiner Truppe implementierte er das "Data Independent Accessing Model" als System R. Das wusste ich, als ich ging. Als ich dann noch erfuhr, dass eine Sub-Language (wie Codd Query-Languages nannte) in gängige Progammiersprachen eingebettet werden konnte, war mir klar, dass hier die Zukunft liegt. Das heiß diskutierte Performance-Problem mengenorientierter Zugriffe war für mich lösbar, das "impedance mismatch"-Problem hingegen ein Pseudoproblem.

Es ist aber eine Ironie des Schicksals: Ohne einen Larry Ellison von Oracle, der im Umfeld von San Jose saß, der die publizierten Aufsätze zum System R im Gegensatz zum IBM-Management ernst nahm und der das erste DB-System der neuen Art auf den Markt brachte, wäre das Relationenmodell nicht so berühmt geworden. Ted Codd, Paul Lorenzen und Jim Gray sind Päpste für mich. Larry Ellison ist kein Papst. Mit Larry Ellison kommen wir ja auch schon nach der bekannten Biografie von Mike Wilson ins Göttliche (Mike Wilson: "The Difference between God and Larry Ellison: God Doesn't Think He's Larry Ellison").

KRD: Während gegen Ende der 80er-Jahre relationale DBMS langsam ihren Siegeszug in der Praxis antraten, kamen in der Forschung die verschiedensten Ansätze in Richtung "Non-Standard-Datenbanken" auf. Ich nenne nur Begriffe wie postrelationale, objektorientierte oder NF2-Datenbanksysteme. SQL, gewissermaßen der sichtbarste Repräsentant des relationalen Modells, ist mittlerweile ein Riesenkonglomerat von Konzepten geworden. Wie schätzen Sie diese Entwicklung ein, wo soll sie hinführen, braucht man das wirklich alles?

HW: Was die Weiterentwicklung anbetrifft, so ist es sehr lehrreich, einmal bei Jim Gray, unserem Turing Award-Winner, reinzuschauen ("The Revolution in Database Architecture" in: SIGMOD 2004). Das Pikante ist, um es vorwegzunehmen: Jim irrt sich gewaltig in seinem systematischen Teil am Ende des Zitates:

"The object-oriented language community has been refining its ideas since Simula 67. There are now several good OO languages with excellent implementations and development environment (Java and C# for example). There is a common language runtime that supports nearly all languages with good performance.

The big news now is the marriage of databases and these languages. The runtimes are being added to the database engine so that now one can write database stored-procedures (modules) in these languages and can define database objects as classes in these languages. Database data can be encapsulated in classes and the language development environment allows you to program and debug SQL seamless mixing Java or C++ with SQL, doing version control on the programs, and generally providing a very productive programming environment. SQLJ is a very nice integration of SQL and Java, but there are even better ideas in the pipeline.

The integration of languages with databases eliminates the inside-the-database/outside-the-database dichotomy that we have lived with for the last 40 years."

Ein nur flüchtiger Blick in das exzellente Buch von Monson- Haefel ("Enterprise JavaBeans 3.0", 2006) langt schon, um zu zeigen, dass die Dichotomie noch längst nicht vorbei ist, und – nach meiner Einschätzung – auch aus systematischen Gründen gar nicht zu überwinden ist. Das ist der Punkt, den ich machen will. Eine funktional begründete, vierschichtige Architektur (Client, Web Server, Application Server, DB Server) weist den Komponenten (beans) des Application Server das zu, was man im Jargon business logic nennt. Darunter versteht man alles, von einer punktuellen Anwendung bis hin zum komplizierten Workflow. Schauen wir uns z.B. den Vorgang "Einlagern Teil" an. Der Operator "Einlagern" kann so hochkomplex aufgefasst werden, mit diversen technischen, rechtlichen und kaufmännischen Kontrollverfahren, dass einem die Lust auf eine Formulierung im Rahmen des Konzepts "Stored-Procedure" schnell vergeht. Man kann ja schließlich nicht den Schwanz (Datenbank) mit dem Hund (Einlagerungslogik) wackeln lassen. Umgekehrt: Der Hund wackelt mit dem Schwanze und ruft in seiner application logic den Schwanz auf, um sich mit Daten versorgen zu lassen oder Ergebnisse mitzuteilen. Er hat z.B. EJB QL (mit SQL inkorporiert) verfügbar, um SQL-fähig zu sein. Jims Koautor beim TP-Monitorbuch, Andreas Reuter, hat im letzten Jahr in Dagstuhl das Menetekel "DB-people as plumbers" an die Wand gemalt. Plumbers sind Klempner, die im Reparaturfall in den Keller der vierten Ebene hinabsteigen müssen, um den Kahn von unten her wieder flottzumachen. SAP lebt von business logic mit unterfüttertem DBBetrieb. Von "Stored-Procedures" könnte SAP nicht leben. Jeder weiß, dass Microsoft sich um SAP intensiv bemüht. Das ist sehr pikant. Jeder kann sich seinen Reim darauf machen. Wir freuen uns auf die Zukunft.

"Stored-Procedures" sind ein beachtlicher Fortschritt im Sinne fokussierter DB-Anwendung. Vom Performance-Standpunkt sind sie "lite" und haben in einem eingeschränkten Rahmen ihre Berechtigung. Ansonsten gilt der Ausspruch "Schuster bleib bei deinen Leisten". Frage an die mitlesende Community: Warum wohl sind "Stored- Procedures" aus EJB QL nicht aufrufbar? Naiv gedacht müsste das doch eigentlich gehen. SQL ist auch mit seinen kaum noch zu übersehenden Erweiterungen – es sollen Hunderte sein – für alle denkbaren Applikationen ungeeignet. Das heißt: SQL taugt nicht als eine allgemeine Sprache zur AP-Entwicklung. Es geht nicht an, x-beliebige DB-Anwendungen im Kopf zu haben, um dann bei der Normung mit Erweiterungsvorschlägen aufzuwarten. Das ist unsystematisch, freundlich ausgedrückt. Sie sehen: Päpste wie Jim Gray sind zwar unfehlbar (Vaticanum I), aber nur in Fragen der Glaubens- und Sittenlehre. Ansonsten gilt: Die Verwendung von "Stored-Procedures" hat ihre Berechtigung, wenn es um Performanzfragen geht. Wenn wir Performanz aus der Gleichung entfernen, bleibt als Lösung die Aufteilung in business logic und plumbers. Klempner ist ein ehrenwerter Beruf, insbesondere, wenn er die Komponenten kennt, mit denen er arbeitet.

KRD: Sie waren während Ihrer Karriere sowohl in der industriellen Praxis als auch in der akademischen Lehre und Forschung tätig. Wie sehen Sie das Spannungsfeld zwischen den beiden Welten, welchen Rat geben Sie unseren jungen Nachwuchskräften, wenn Sie am Ende von Studium oder Promotion nach Wegweisung fragen?

HW: Das Spannungsfeld entsteht aus meiner Sicht vorwiegend, weil die Universitäten und Hochschulen nur berufsfähige Absolventen hervorbringen können, die Praxis aber Berufsfertigkeit vom Nachwuchs verlangt. Je kleiner das Unternehmen ist, umso größer ist dieses Verlangen. Deshalb mein Rat: Erst bei einem großen anfangen. Verschärfend kommt noch hinzu, dass die Dokumentationen, mit deren Hilfe sich der junge Mann oder die junge Frau einarbeiten müssen, sich im Allgemeinen nach Aufbau und "kruxiger" Firmen-Terminologie in einem grausigen Zustand befinden. Man muss vieles "erdeuten" und erfragen, was sehr zeitaufwendig ist. Die vielen fachlichen Trainee-Programme als Ersatz zeugen vom beklagenswerten Zustand der Dokumentation. Wenn dann auch noch die Kursunterlagen voller kruxiger Haus- Terminologie mangelhaft sind, wird das Geld nur so zum Fenster rausgeschmissen. Terminologie hat universell zu sein, wie das auf anderen Gebieten selbstverständlich ist. In der Informatik-Industrie wird jedoch ein urwüchsiger Haus-Jargon gepflegt. Zwischen Berufsfähigkeit und -fertigkeit liegt deshalb in der Regel ein ganzes Jahr. Dann erst ist man im Allgemeinen selbstständig. Wichtig für junge Leute ist, sich den Grundlagen während ihres Studiums verstärkt zuzuwenden, damit das "Erdeuten" leichter fällt. Wenn die Basis vorhanden ist, braucht man sich vor Aufbauten, die auch noch so schräg sein mögen, nicht zu fürchten. Die jungen Leute sollen sich nicht bange machen lassen. Wie beweist man, dass eine Basis verfügbar ist? Antwort: Man muss die gängige Fachliteratur ohne großen Aufwand verstehen und kritisieren können. "Verstehen heißt" nach einem alten Philosophenspruch aber auch "verstehen, wie es geworden ist". Nun ist die Informatik erschreckend unhistorisch. Wie kann es z.B. sein, dass im schönen Buch von Monson-Haefel, das im Kern "Component Transactions Monitors" (CTM) behandelt, der Gray/Reuter über "Transactions Monitors" (TM) – früher "die Bibel" genannt – noch nicht einmal erwähnt wird, obwohl das Werk nur zehn Jahre älter ist. Das ist ätzend, würden die jungen Leute von heute sagen. Was die Forschung im Spannungsfeld anbetrifft, so kann es sein, dass die Großindustrie sich bloß als Geldgeber versteht und ohne Interesse am Ergebnis ihr Engagement als Ausstattungsprojekt auffasst. Das ist universitätsseitig zu respektieren, man ist dankbar, aber es ist trotzdem bedauerlich. Unschön ist, wenn in Firmen ununterbrochen reorganisiert wird und man ständig anderen Leuten gegenüber sitzt. Die Interessenlage der Firmen ist halt anders, und so kann es beim Publizieren auch Ärger geben.

KRD: Lieber Herr Wedekind, mir würden noch so viele Fragen an Sie einfallen, zumal Sie auch zu vielen anderen wichtigen Themen wie etwa der Informatik als Grundbildung bekannt pointierte Meinungen vertreten. Doch der Platz für unser Interview ist leider beschränkt, ich kann unsere Leserschaft nur auf Ihr reiches Schriftenwerk verweisen, das ja erfreulicherweise auch immer noch wächst. So möchte ich mit einem Ausflug in Ihr Leben "jenseits der Informatik" schließen. Wenn Sie einmal nicht über unser Fachgebiet nachdenken, keinen Aufsatz lesen oder schreiben und nicht eine Ihrer Vorlesungen halten, was Sie ja immer noch mit Freude und großem Engagement (und das gleich an 3 Universitäten!) tun, womit vertreiben Sie sich dann die Zeit, woran haben Sie Freude, kurz: Was macht der Privatmann Hartmut Wedekind?

HW: Richard Wagner und seine Opern sind meine Leidenschaft. Ich bin aber kein "Wagnerianer", somit kein Sektierer, der regelmäßig nach Bayreuth pilgert.

Gute Western-Filme der gehobenen Klasse sind ebenfalls eine Passion von mir. Gerade hab ich mir die restaurierte DVD-Fassung von John Fords "Der schwarze Falke" (The Searchers, 1956) mit meinem Idol John Wayne besorgt und angesehen. Ich bin immer noch ganz benommen von der herrlichen Kulisse des Monument Valley, von John Fords brillanter Kameraführung in dieser herrlichen Gegend und natürlich von John Wayne. Dicke historische Wälzer und Joggen (zweimal wöchentlich 10 km) füllen aber auch noch meine Zeit aus. Beim Joggen werde ich immer schlechter. Wenn ich mit meinen 71 Jahren die 10 km auf flacher Strecke manchmal noch unter einer Stunde schaffe, bin ich mächtig stolz auf mich.

KRD: Das können Sie auch sein! Ganz herzlichen Dank für das Gespräch. Da ich Sie ja auch seit langem persönlich kenne, kann ich bestätigen: Das war ein Wedekind, wie er leibt und lebt! Sicher auch im Namen unserer Leserinnen und Leser wünsche ich Ihnen noch viele Jahre bei guter Gesundheit und Schaffenskraft ... und wir freuen uns auf weitere geschliffene (rhetorische) Pfeile von Ihnen in Wort und Schrift, die uns zum Nachdenken anregen.

Das Interview führte Prof. Dr. Klaus R. Dittrich (dittrich [at] ifi [dot] unizh [dot] ch), der für die Rubrik "Interview" verantwortlich ist.

Zum Inhaltsverzeichnis