Für die engere Datenbanktechnologie bietet die Mathematik seit zwanzig Jahren einen festen Bezugspunkt. Eine inzwischen stürmische und schwer überschaubare Entwicklung nimmt dagegen das Zusammenwirken der "Schicksalsgemeinschaft" Datenbanken und Internet.

Die Grundlagen von relationalen und von objektorientierten Datenbanken haben Mathematiker erarbeitet. Bei relationalen Datenbanken hat Codd folgendes Ziel verfolgt: "a relational model of data for large shared data banks". Er konzentrierte sich auf große Datenmengen und auf den parallelen Zugriff vieler Anwender. Relationale Datenbanken können durch diese Struktur eine große Verantwortung für ihren Inhalt übernehmen und gelten als sehr sicher.

Andere Interessen hatte man bei Xerox mit der Entwicklung der Objektorientierung: Jeder Anwender, der sich Computerunterstützung wünscht, soll flexibel formulieren und strukturieren. Anschließend speichern dann objektorientiere Datenbanken dauerhaft die dabei aufgetretenen abstrakten Objekte. Eine hohe Flexibilität steht dabei im Vordergrund. Die Mathematiker verwenden für all diese Datenbanken dieselben Bausteine der Mengenlehre. Sie stellen je eine Variante für die Sicherheit und die Flexibilität zusammen.

Die große Ellipse in Abbildung 1 umfaßt alle möglichen objektorientierten Systeme. Als Sonderfall grenzt darin ein gelber Kreis die mit SQL programmierten Anwendungen relationaler Datenbanken mit normalisierten Tabellen ab. Bei ihnen ging es vorrangig um Sicherheit.

Relationale Datenbanken sind Sonderfälle von objektorientierten Systemen, weil ein wirklich flexibles System auch auf Sicherheit getrimmt werden kann. In der Praxis führt dieser Umweg über das allgemeine System aber zu großen Leistungseinbußen.

Auch in die andere Richtung ist die Grenze durchlässig. Denn alle Objekte der großen Ellipse lassen sich auch in relationalen Tabellen speichern. Sie werden in einem eigenen Designschritt festgelegt und sind meist nicht normalisiert. Der Aufwand für diese Umsetzung entspricht dem, der bei Klassen für Sicherheit und Effizienz aufzubringen ist.

Der Anwender muß entscheiden, ob ihm Sicherheit oder Flexibilität wichtiger sind. Es überrascht demnach nicht, daß bei kaufmännischen Anwendungen relationale Datenbanken bevorzugt werden. Vergleichbare Entscheidungen werden tagtäglich getroffen: Werden in einem IT-System Zugriffe zum Beispiel über Paßwörter geschützt, geht dabei Flexibilität verloren. Auch beim Verschließen der Haustür steht man vor der gleichen Frage.

In den letzten Jahren haben die Hersteller von relationalen Datenbanken gelernt, ihr Produkt flexibler zu machen, ohne die gewohnte Sicherheit aufzugeben. Das bedeutet mehr Befehle, als SQL heute bietet. Jetzt fordern auch viele Anwender von objektorientierten Datenbanken mehr Sicherheit, und ihre Lieferanten wollen das bei Software-Entwicklern weitverbreitete SQL-Know-how nutzen.

Das Schlagwort für diese Entwicklungen ist "objektrelational". Es fällt sowohl bei neuen Versionen objektorientierter als auch relationaler Datenbanken. Daraus ergeben sich zwei interessante Fragen: Handelt es sich jeweils um das gleiche, und bewegen sie sich dabei aufeinander zu?

Noch wurde keine Alternative zu der von Codd entdeckten Architektur für sichere Datenbanken gefunden. Wenn heute die Sicherheit von objektorientierten Systemen erhöht wird, erzwingt die Mathematik eine Annäherung an die bekannten relationalen Strukturen. Erst wenn eines Tages ein Technikgenie einer zweiten sicheren Struktur auf die Spur kommt, wird diese Aussage hinfällig. Bis dahin müssen beide Fragen eindeutig bejaht werden. In Abbildung 2 erscheint nur eine einzige Ellipse für objektrelationale Datenbanken.

Dies gibt den Herstellern relationaler Datenbanken einen Heimvorteil in puncto Sicherheit. Sie darf jedoch nicht mit Qualität verwechselt werden. Denn hier kommt es nicht auf den Aufwand für die Qualitätssicherung an, sondern darauf, wieviel Verantwortung eine Klasse automatisch für ihre Exemplare übernimmt.

Will ein Hersteller seine Datenbank objektrelational erweitern, muß er wichtige Entscheidungen treffen. Zunächst werden ihm seine anspruchsvollen Kunden ihre Forderungen ins Pflichtenheft der nächsten Datenbank-Version schreiben. Sie erwarten eine einfache und sichere Verwaltung extrem großer und verstreuter Daten: in einigen Mengengerüsten taucht jetzt die Größenordnung Peta (das Billiardenfache einer Einheit = 10 hoch 15) statt Tera auf (das Billionenfache einer Einheit = 10 hoch 12). Auch darf der Aufwand für das Sichern und Zurückspielen von Datenbeständen nicht mehr proportional zur Gesamtgröße sein, sondern nur noch von den Änderungen abhängen, die seit der letzten Sicherung anfielen. Der laufende Betrieb sollte bei diesen Aktivitäten auf keinen Fall unterbrochen werden.

Bei einem Hersteller, der schon vorher ein objektorientiertes Sicherheitsventil eingebaut hat, gibt es überraschend wenig Druck bei Erweiterungen dieser Art. Vor Jahren bereits wurde systematisch untersucht, wo SQL mitunter unangenehm komplexe Programme und lange Laufzeiten erzwingt. Als Problemgebiete identifizierte man Fließtexte, mehrdimensionale Abstände für geografische Informationssysteme und Zeitreihen sowie digitale Videoaufzeichnungen.

Dafür gab es bald Zusatzprodukte beziehungsweise Optionen, die den fertigen Klassen entsprechen, welche von objektorientierten Umgebungen bekannt sind. Denn hier werden zusätzliche Datenstrukturen mit Methoden geliefert, die sie nach außen abkapseln. Im Unterschied zu den SQL-Anwendungen greifen sie direkt auf den Datenbankkern (Kernel) zu. In Abbildung 3 sind diese Optionen zu sehen. Sie haben inzwischen einige Versionswechsel der Standard-Datenbank hinter sich.

Das hat zwei Erkenntnisse deutlich gemacht:

- Es gibt einige Kernelbefehle, die sich, ohne die Sicherheit, Verteilbarkeit und Versionsstabilität zu gefährden allgemein nutzen lassen.

- Einige Module in den Optionen müssen aus genau denselben Gründen weitere Regressionstests mit sämtlichen neuen Datenbankversionen durchlaufen.

Der erste Punkt führt zu neuen Datenbankbefehlen, die die Leistungsfähigkeit vieler Datenbankanwendungen erhöht. Ein Teil des Kernels liegt auf der äußeren Kapsel (Abbildung 4), für die nun eine geeignete Programmiersprache gesucht wird. Ein Zusammenspiel von Web und Datenbank füllt diese Lücke. Zwei Forderungen werden dabei gestellt:

- Die Sprache muß auf einem verabschiedeten Standard beruhen.

- Es soll Homogenität für alle Web-Anwendungen bestehen.

Diesen Standards entspricht derzeit nur Corba (Common Object Request Broker Architecture) von der OMG (Object Management Group). Damit lassen sich sowohl die zusätzlichen Datenbankbefehle als auch alle Schnittstellen der Softwarekomponenten im Internet definieren. Die Alternativen sind SQL3, eine Weiterentwicklung von ANSI-SQL92, und DCOM von Microsoft. SQL3 ist aber offiziell noch nicht verabschiedet und DCOM noch zuwenig verbreitet. Die nachträgliche Integration dieser Alternativen muß aber offengehalten werden.

Abbildung 5 zeigt eine tragfähige Basis für die Integration von Datenbank und Web. Sie arbeitet mit Softwarekomponenten, sogenannten Cartridges. Siedelt man eine von ihnen auf dem Datenbankserver an, um die neuen Datenbankbefehle zu nutzen, wird sie zur Data-Cartridge.

Isolierte Datenbanken sind out

Die IT-Abteilungen haben zunächst das isoliert gewachsene Web mit den vorhandenen Datenbanken verbunden: Der Server bekam ein Internet-Front-end, über das Browser auf bestehende Datenbanken zugreifen konnten. Diese Browser waren Zusatzsoftware auf den vorhandenen Clients, also PCs und Workstations. Verblüffend daran war, welch vielfältige Zugriffe auch bei völlig gemischter Hardware und Systemsoftware möglich wurden.

Daraufhin nahm die Zahl der Web-Teilnehmer explosionsartig zu. Das hat nicht nur die Belastung erhöht, sondern auch die Anwender selbstsicher und anspruchsvoll gemacht. Mit derselben Leichtigkeit, mit der sie im Web Informationen sammeln, wollen sie auch ihre komplexen Geschäftstransaktionen abwickeln. Mit dieser Forderung rennen sie in den meisten IT-Abteilungen offene Türen ein, denn dort verursacht die Betreuung der vielen Hard- und Softwareprodukte, die sich verstreut auf viele PCs verteilen, inzwischen einige Kosten. Die IT-Profis hegen aber den Verdacht, daß sich die bisher unabhängig gewachsenen Technologien von Web und Datenbank bald gegenseitig behindern, da deren technologische Grenzen erreicht sind. Dagegen hilft nur, die beteiligten Basisarchitekturen besser aufeinander abzustimmen.

Aus diesem Grunde wurde die Entwicklung der verschiedenen Softwaretechnologien auf ein gemeinsames Ziel ausgerichtet: Datenbank, Werkzeug, Repository, Einsatzumgebung. Dafür steht zum Beispiel das Schlagwort Network Computing Architecture (NCA). Die Zusammenarbeit mit Alt- und proprietären Systemen ist dabei zwingend vorgeschrieben, denn die wichtigste Fragestellung ist heute: Wo lassen sich mit vorhandenen Daten kurzfristig zusätzliche Geschäftschancen via Intra- oder Internet nutzen?

Abbildung 6 stellt die wichtigsten Bausteine einer Network Computing Architecture vor. Rechts befindet sich der Datenbankserver, auf dem Data-Cartridges angesiedelt werden. In der Mitte liegen ein oder mehrere Anwendungsserver, auf denen die Komponenten der Anwendungssoftware ihre Arbeit verrichten. Links sind die Clients als Einstiegspunkte für die Anwender im Bild. Verbindungen zwischen Cartridges stellt ICX, der Softwarebus Inter-Cartridge-Exchange, her.

Middleware täuscht Programme vor

Natürlich darf Java in keiner Trendanalyse fehlen. Interessante Aspekte ergeben sich immer dann, wenn etwas weiter ausgeholt wird. Datenbanken arbeiten schon länger mit Request Brokern zusammen. Diese Middleware (etwa SQL-Net) täuscht den Anwendungsprogrammen vor, auf demselben System angesiedelt zu sein.

Produktivität und Qualität werden weiter gesteigert, wenn sich Softwarekomponenten ohne Neuprogrammierung zwischen allen marktgängigen Clients (Microsoft, Apple, IBM, Unix) und Servern herumschieben lassen. Das ist seit Jahren zum Beispiel mit PL/SQL möglich.

Entwickler können mit Komponenten arbeiten

Mit Java und den gängigen Standards für Schnittstellen können nun alle Entwickler mit Komponenten arbeiten. Dazu müssen sie folgende Voraussetzungen erfüllen:

- Saubere Trennung von Datenbank, Komponenten und Präsentation,

- Entwicklung der Komponenten in einer portablen Sprache wie Java oder PL/SQL,

- Online-Repository für alle Projektinformationen und Komponenten,

- Umfassende Qualitätssicherung: Schnittstellen, Dokumentation etc.

Dieser Paradigmenwechsel hat positive Auswirkungen auf die Produktivität der Entwickler. Steigerungen lassen sich bereits objektiv wie qualitativ nachweisen. Das von Broy geleitete Informatikinstitut an der Technischen Universität in München hat entsprechende Wartungsprojekte deutscher Behörden und Firmen untersucht.

Noch darf sich die Industrie nicht auf diesen Lorbeeren ausruhen; noch muß die Verbindung zwischen Java und Datenbanken bedeutend verbessert werden. Um dieses Ziel zu erreichen, arbeiten die Großen der Branche unter den Kürzeln JDBC und J/SQL bereits eng und konstruktiv zusammen.

*Dr. Wolf Nagl arbeitet im strategischen Marketing der Oracle Deutschland GmbH in München.