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.

27.02.1981

SQLDS- und was darunter zu verstehen ist

Geradezu begeistert spricht IBM-Fellow Dr. Edgar F. Codd über die Benutzerfreundlichkeit von SQL/DS, des ersten, voll unterstützten relationalen Programmprodukts der IBM (CW Nr. 8 vom 20. Februar 1981, Seite 1). Der Vater des Relationenmodells für Datenbanken erläutert, welche Bedeutung der SQL/DS-Ankündigung zukommt. Wegen des Codd-Beitrags erscheint das "Thema der Woche" erst wieder in der nächsten CW-Ausgabe.

1. Ein neuartiges Datenbanksystem

Am 30. Januar 1981 kündigte die IBM in den USA ein Programmprodukt mit der Bezeichnung SQL/DS an, wobei SQL für Structured Query Language und DS für Data System steht. Das Produkt ist ein relationales Datenbanksystem und das erste, voll unterstützte relationale Programmprodukt der IBM. Es ist für die mittel großen Rechner der IBM bestimmt, das heißt für die Modelle 138, 145, 148 und 158 des Systems /370 und die Rechner 3031, 3033 S, 4331 und 4341 oder kompatible Prozessoren, die durch das Betriebssystem DOS/VSE mit Advanced Functions Release 3 unterstützt werden.

Für die Benutzer einer SQL/DS-Datenbank scheinen die Daten in der Form von Tabellen strukturiert zu sein. Das einfache Tabellenformat bewahrt den Benutzer vor dem Zwang, die weit kompliziertere Darstellung der relationalen Datenbank im Speicher kennen und mit ihr umgehen zu müssen.

2. Bahnbrechende Innovationen

Das Datenbanksystem SQL/DS ist das Ergebnis vieler Forschungs- und Entwicklungsjahre und verkörpert einige bahnbrechende Entwicklungen, von denen die meisten auf eine drastische Vereinfachung der Installation und Verwaltung von Datenbanken und des Zugriffs auf diese abzielen.

2.1 Automatische Navigation

Das vielleicht am meisten herausragende Merkmal von SQL/DS ist die Unterstützung einer automatischen Navigation zu den Zieldaten. Unter "automatischer Navigation" verstehen wir, daß die Benutzer die von ihnen gewünschten Daten ansteuern können, indem sie angeben, WAS sie haben wollen und nicht, WIE sie es haben wollen. Die Benutzer brauchen nicht zu wissen, wie die Daten im Speicher dargestellt sind. Diese Einrichtung macht den Zugriff zu den nach SQL/DS organisierten Datenbanken auch für solche Endbenutzer leicht, die nur wenige oder sehr geringe Programmierkenntnisse haben. Eben diese Einrichtung steigert aber auch die Produktivität der Anwendungsprogrammierer, da diese sich auf die wesentlichen logischen und datentechnischen Zusammenhänge ihrer Anwendungen konzentrieren können, anstatt sich mit Einzelheiten der Datendarstellung befassen zu müssen.

2.2 Datensatz-Manipulation auf sehr hoher Sprachebene

Zur Unterstützung der automatischen Navigation bedarf es einer "höheren" Programmiersprache, bei der mit einer einzigen Anweisung Mengen von Datensätzen manipuliert werden und nicht nur einzelne Sätze. Die Quellensprachen Cobol und PL/1 können in Verbindung mit den meisten Datenbanksprachen bestehender Datenbanken lediglich jeweils einen Satz zu einer Zeiteinheit behandeln.

SQL dagegen kann mit einer einzigen Anweisung Mengen von Datensätzen manipulieren und kombinieren. Nebenbei: für SQL ist im Prinzip jeder Datensatz die Zeile einer Tabelle. Sehr wichtig dabei ist, daß man ohne weiteres zur vollständigen Definition einer vollständigen Anwendung SQL-Anweisungen mit Cobol-, PL/1 oder Assembler-Anweisungen mischen kann.

Ungeachtet der Tatsache, daß das "Q" in SQL für "Query" (Abfrage) steht, ist SQL weit mehr als eine Abfragesprache. Diese Sprache, umfaßt zusätzlich auch eine Datendefinition, das Laden von Massendaten, das Fortschreiben (einschließlich Änderungsverpflichtung), die Gewährung und Aufhebung einer Berechtigung sowie Anweisungen, mit denen die Datenbank-Wiederherstellung unterstützt wird. SQL bietet im wesentlichen dieselben Einrichtungen und dieselbe Syntax, ob sie nun als unabhängige interaktive Sprache genutzt oder von einem PL/1 -, Cobol- oder Assembler-Programm aufgerufen wird. Ihre umfassende Natur, ihre Einfachheit und Einheitlichkeit ermöglichen eine bessere Kommunikation unter den Anwendungsanalytikern, Programmierern und Endbenutzern als bisher übliche Datenbanksysteme.

2.3 Automatische Optimierung

Mit einer höheren Programmiersprache wie SQL fällt dem System die Verantwortung zu, die am besten geeigneten Zugriffspfade zum Auffinden der Daten zu selektieren. Die Selektion erfolgt aufgrund einer Menge von "schnellen" Zugriffspfaden, die zuvor von einem oder mehreren Benutzern in der Rolle von Datenbankverwaltern eingerichtet wurden und aufgrund von "langsameren" Zugriffspfaden, die durch sequentielle Durchmusterung dargestellt werden. Das System ist auch dafür zuständig, in welcher Reihenfolge die verschiedenen kombinierenden Operationen für Datensatzbestände zu verarbeiten sind. Diese Aufgabe ist überaus lohnend, wenn eine gute Leistung erzielt werden soll und daher Gegenstand umfangreicher Forschungsarbeiten bei der IBM und an Universitäten. Das Programmprodukt SQL/DS verwendet die als Teil des Prototyps "System R" am IBM-Forschungslaboratorium San Jose entwickelte Optimierungstechnik. SQL/DS verfügt über eine dynamische Optimierungseinrichtung, die von großer Bedeutung für eine weitere Reduzierung des Aufwands an Programmwartung ist, wie sie bei Installationen mit früheren Datenbankverwaltungsystemen entstehen konnte.

Wenn zum Beispiel ein entsprechend berechtigter Benutzer (möglicherweise, aber nicht notwendigerweise ein Datenbankverwalter) den gesamten. Datenverkehr analysiert und daraus folgert, daß ein gewisser Index X nicht mehr gerechtfertigt ist und entfallen sollte, so kann er mit einem Befehl diesen Index eliminieren - sogar, wenn währenddessen andere Transaktionen weiterlaufen. Die zuvor durch das System auf eine Verwendung des Index X optimierten Transaktionen werden nun stattdessen automatisch und dynamisch auf die Nutzung anderer Zugriffspfade reoptimiert. Die Logik der Anwendungsprogramme wird davon nicht berührt, und es ist im Zusammenhang mit dieser leistungsorientierten Änderung auch keine Programmwartung erforderlich.

Wenn der Urheber einer Tabelle - oder jemand mit entsprechender Berechtigung - aus Performance-Gründen die Einführung eines neuen Index beschließt, kann er auch dies mit einem Befehl veranlassen, selbst, während andere Transaktionen ausgeführt werden. In diesem Fall reoptimiert SQL/DS die Transaktionen innerhalb eines bestimmen Anwendungsprogrammes dynamisch, wenn auch nicht völlig automatisch: Der Datenbankverwalter oder ein anderer berechtigter Benutzer muß eine solche Reoptimierung anfordern.

2.4 Dynamische Änderung der Datenbankbeschreibung

Von Zeit zu Zeit wollen die Benutzer Änderungen an den gespeicherten Informationen durchfahren. Ursprüngliche Vorstellungen hinsichtlich der Datenbankbeschreibung werden vielleicht einer Überarbeitung bedürfen. In bestimmten Installationsumgebungen ist dann die ungestörte Weiterverarbeitung von Transaktionen an den nicht betroffenen Teilen der Datenbank von äußerster Wichtigkeit.

SQL/DS unterstützt solche Erweiterungen oder Verkürzungen, ohne Programme oder Transaktionen zu stoppen, ausgenommen in solchen Fällen, in denen die von einer Transaktion benötigten Daten eliminiert worden sind. Andere Anweisungen in SQL können zur Erweiterung der Datenbankbeschreibung verwendet werden, wie zum Beispiel zur Beschreibung einer neuen Tabelle oder aber zur Erweiterung der Beschreibung einer bestehenden Tabelle. Im ersterben Fall entsteht eine leere Tabelle; im letzteren Fall wird eine neue, aber ebenfalls leere Spalte einer bestehenden Tabelle hinzugefügt.

Die Datenbankbeschreibung kann verkürzt werden, indem man die Eliminierung eines Tabelleninhaltes verlangt. Natürlich verschwindet in einem solchen Fall auch die Tabelle selbst.

Diese Einrichtung gestattet eine allmähliche Entwicklung der Datenbankbeschreibung und somit der Datenbank selbst, ohne die fortlaufende Verarbeitung und Daten, die relativ stabil sind, zu stören.

2.5 Benutzersichten (Views)

Mit Hilfe von SQL/DS ist es möglich, Programme und Terminalaktivitäten nicht nur von der Datendarstellung im Speicher zu isolieren, sondern auch - in ungewöhnlichem Ausmaß - von Änderungen der logischen Beschreibung der Daten. Dies geschieht zum Beispiel durch die Definition anwendungsspezifischer "Benutzersichten" (Views), die zu virtuellen Tabellen führen.

Dies sind Tabellen, deren Daten erst dann materialisiert werden, wenn dies im Ablauf der Transaktion erforderlich wird. An diesem Punkt werden die für die virtuellen Tabellen erforderlichen Daten mit Hilfe einer zur speziellen Benutzersicht gehörenden SQL-Spezifikation aus anderen nichtvirtuellen (oder Basis-)Tabellen entnommen. Die am meisten verwendeten Benutzersichten werden wohl solche sein, die ihre Daten bei Bedarf aus einigen wenigen Spalten oder denjenigen Zeilen einer Basis-Tabelle entnehmen, die einem einfachen Kriterium genügen. Benutzersichten sollten aber nicht mit statischen Kopien verwechselt werden. Wann immer eine Benutzersicht materialisiert wird, verwendet sie die allerneuesten Daten. Benutzersichten werden daher immer automatisch auf dem neuesten Stand gehalten, wenn die Basistabellen fortgeschrieben werden.

2.6 Datenschutz

Die Öffnung von Datenbanken zur unmittelbaren Benutzung und Änderung durch den Endbenutzer mit einer alles sondierenden Sprache wie SQL macht es unabdingbar, einen wirkungsvollen Mechanismus einzuführen, wonach nur entsprechend berechtigte Benutzer zuvor festgelegte Operationen an den Daten durchführen dürfen. SQL/DS unterstützt eine strenge Kontrolle des Benutzerzugriffs zu Programmen, die wiederum zu Daten zugreifen. Die Strenge der Kontrolle wird ergänzt durch eine große Flexibilität bei der Definition des Umfangs der zu schätzenden Daten. Anweisungen in SQL erlauben es den Benutzern, ihre Berechtigungsanforderungen SQL/DS mitzuteilen, und zwar einerseits durch Definition von Benutzersichten und zum anderen durch eine Festlegung der Operationen (EINFÜGEN, LÖSCHEN etc.), die ein Benutzer auf Tabellen oder Teilen von Tabellen durchführen darf. Zugriffsberechtigung kann auf Tabellen, Sätze und/oder Felder erteil werden. Ein Benutzer kann in seinem Zugriff auf solche Datensätze in einer Tabelle beschränkt werden, die in bestimmten Spalten Werte enthalten, die wiederum innerhalb eines bestimmten Bereichs liegen. So kann beispielsweise der Leiter der Abteilung D auf den Zugriff zu ausschließlich solchen Daten in der Tabelle MITARBEITER beschränkt werden, die in der Spalte "Abteilungsbezeichnung" das Kennzeichen D enthalten.

Darüber hinaus unterstützt das System Paßworte und gestattet eine Kontrolle des gesamten Datenschutzes durch eine oder mehrere Beauftragte - abhängig davon, was bei der jeweiligen Installation am zweckmäßigsten ist.

2.7 Unterstützung des mehrfachen, gleichzeitigen Zugriffs

SQL/DS unterstützt den gleichzeitigen Zugriff mehrerer Benutzer im Rahmen eines multiplen Betriebsgeschehens (Stapel-, Dialog- und Transaktionsverarbeitung). Alle Sperren zur Vermeidung der gegenseitigen Beeinflussung von Transaktionen werden automatisch durch das System gesetzt, wodurch die Benutzer spürbar entlastet werden.

2.8 Wiederherstellung

Die SQL/DS-Einrichtungen zur Datenwiederherstellung schützen die Daten vor drei Fehlerquellen: Benutzer, System und Datenträger. Jede Wiederherstellung beruht auf dem Konzept der Rückführung der Daten auf einen konsistenten Zustand, wie er nach einer erfolgreich durchgeführten logischen Aufgabe erreicht wird.

Bei einem Benutzerfehler isoliert SQL/DS die der fehlerhaften Anwendung zugeordneten Arbeitseinheiten und nimmt die nicht ordnungsgemäß freigegebenen Datenänderungen zurück. Das erfolgt dynamisch ohne Berücksichtigung anderer Aktivitäten im System.

Der Benutzer selbst verfügt außerdem über die Möglichkeit, bei Bedarf nicht freigegebene (uncommitted) Änderungen rückgängig zu machen. Das gestattet einem interaktiven Benutzer, während eines Dialogs eine Reihe hypothetischer Fortschreibungen an der Datenbank vorzunehmen, ihre Auswirkungen auf die Datenbank mit Hilfe von Abfragen zu überprüfen und anschließend den ursprünglichen Zustand der Datenbank wiederherzustellen.

Bei einem Systemfehler führt ein Wiederanlauf von SQL/DS die Daten in einen konsistenten Zustand zurück, indem nicht freigegebene Änderungen (uncommitted changes) rückgängig gemacht und die freigegebenen Änderungen (committed changes) vollständig verarbeitet werden.

SQL/DS unterstützt die Wiederherstellung der Datenbank bei fehlerhaftem Datenträger über eine Datenbankarchiv-Einrichtung, aus der die Datenbank mit einem vorgegebenen Wiederherstellungsverfahren wiedergewonnen werden kann.

2.9 Katalogunterstützung

Die Steuerinformationen in SQL/DS umfassen Daten, die

- die Datenbank beschreiben,

- Benutzer und Programme identifizieren,

- Zugriffs- und Manipulations-Berechtigung von Benutzern festlegen und

- Daten zur Definition von Benutzersichten.

Bei SQL/DS können auf diese Steuerdaten mit derselben tabellarischen Struktur und denselben Befehlen wie für andere Daten zugegriffen werden. Das System stellt automatisch sicher, daß der Katalog jederzeit eine genaue Beschreibung der Datenbank enthält.

Katalogabfragen (von jedem berechtigten Benutzer) und Katalogfortschreibungen (nur durch das System) können gleichzeitig mit Transaktionen auf gewöhnliche Daten durchgeführt werden.

2.10 Leistung (Performance)

Die von SQL/DS bei der Verarbeitung einer Transaktion in Anspruch genommenen Betriebsmittel hängen von vielen Faktoren ab, beispielsweise von der Zahl der abgesuchten Sätze, von der logischen Komplexität der Transaktion, vom Vorhandensein von Indizes und vom verfügbaren Speicherraum. Bei der Diskussion der Performance von SQL/DS muß man zwischen zwei Anwendungsarten unterscheiden:

1. Anwendungen, die sowohl für ein Datenbanksystem mit automatischer Navigation als auch für ein Datenbanksystem mit manueller Navigation implementiert werden und

2. Anwendungen, die nur auf einem Datenbanksystem mit automatischer Navigation (wie SQL/DS), nicht aber für ein Datenbanksystem mit manueller Navigation implementiert werden.

Werden Anwendungen vom Typ 1 unter SQL/DS entwickelt, so können sie in manchen Fällen mehr Systembetriebsmittel (CPU-Zyklen, realer Speicherraum, E/A-Aktivität, DASD-Speicher) in Anspruch nehmen, als wenn sie unter einem Datenbanksystem mit manueller Navigation laufen, obwohl der zusätzliche Aufwand für die Selektion des Zugriffspfades normalerweise nur zum Zeitpunkt der Umwandlung (Abfrage-Übersetzung) in Erscheinung tritt. In solchen Fällen dürften die vom "automatischen Navigationssystem" in Anspruch genommenen zusätzlichen Betriebsmittel durch den stark reduzierten Entwicklungsaufwand, um das Programm erstmalig zum Laufen zu bringen, und durch den verringerten späteren Wartungsaufwand gerechtfertigt sein.

Anwendungen vom Typ 2 verlangen hinsichtlich der Leistungsdiskussion eine ganz andere Betrachtungsweise.

Mit einer relationalen Sprache auf hoher Ebene wie SQL kann man überaus leicht Abfragen und andere Transaktionen definieren, die außerordentlich umfangreiche Systembetriebsmittel verlangen. Vor allem im Dialogbetrieb testende Benutzer werden leicht versucht sein, Abfragen loszuschicken, ohne sich dessen bewußt zu werden, wieviel CPU-Zeit dadurch verbraucht werden wird. So zum Beispiel bei einer Abfrage, die einen "EQUI-JOIN" von zwei sehr großen, Tabellen beinhaltet, für die die abzugleichenden Spalten nicht durch Indizes unterstützt werden. Das darf aber nicht zu einer Mächtigkeitsbegrenzung der SQL-Sprache führen. Vielmehr meldet SQL/DS dem Terminal Benutzer die aus seiner Transaktion ungefähr zu erwartende Systembelastung. Es bleibt jeder Installation überlassen, Regeln für die Betriebsmittelbelegung einzuführen, die ihren Bedürfnissen entspricht.

3. SQL/DS und andere IBM-Software-Produkte

Es hat in der Vergangenheit viele Spekulationen über den möglichen Einfluß eines voll unterstützten relationalen Datenbanksystems der IBM auf die weitverbreiteten Produkte IMS und DOS DL/1 gegeben. Da SQL/ DS für die mittelgroßen, mit dem Betriebssystem DOS/VSE arbeitenden Rechner bestimmt ist, kann die Betrachtung hier auf den Zusammenhang zwischen SQL/DS und DOS DL/I beschränkt werden.

SQL/DS und DL/I DOS/VS sind sich ergänzende Produkte, die abhängig von den Benutzerbedürfnissen entweder einzeln oder zusammen verwendet werden können. DL/I eignet sich besonders für Umgebungen mit hohem Performance-Anspruch, großen, relativ stabilen Datenbeständen und vorausgeplanten Anwendungen. Andererseits eignet sich SQL/DS vor allem für Bereiche, wo eine Vorausplanung schwierig oder unmöglich ist; beispielsweise bei rasch wechselnden Anforderungen, sondierenden Recherchen, unvermuteten Abfragen und Fragen mit simulierendem "Was-ist-wenn. . ."-Charakter.

SQL/DS kann sich mit DL/I und CICS in dieselbe CPU teilen. Wenn erforderlich, können Daten aus einer DL/I-Datenbank extrahiert und in zuvor definierte Tabellen einer SQL/DS-Datenbank kopiert werden. Solche Datenextraktionen können entweder in einer DL/I-Online-Umgebung durchgeführt werden oder aber auf einen Zeitpunkt geringerer DL/I-Benutzung verschoben werden. Der Zugriff auf die kopierten Daten mit SQL/DS erfolgt unabhängig von schnellen DL/I-Operationen.

SQL/DS kann zusammen mit CICS/ DOS/VS betrieben werden. Tatsächlich sind die Online-Einrichtungen von SQL/DS in einer CICS/DOS/VS-Transaktion implementiert die "Interaktives SQL" (ISQL) genannt wird.

Ursprünge von SOL/DS

Gegen Ende des Jahres 1968 begannen im IBM-Forschungslaboratorium San Jose, Kalifornien, Arbeiten an einem abstrakten Modell für die Art von Informationen, wie man sie gewöhnlich in den Datenbanken von Wirtschaft, Verwaltung und Industrie findet. Das Hauptziel dieser Arbeiten war es, eine theoretische Grundlage zur Behandlung logischer Aspekte von Datenbanken und Datenbankverwaltungssystemen zu finden, die gänzlich von Performance-Überlegungen frei sein sollte. Das Ergebnis dieser Forschungsarbeiten war das "Relationenmodell".

Da die Begriffe des Relationenmodells (im besonderen) und des Datenmodells (im allgemeinen) für die Datenbankverwaltung völlig neuartig waren - und dies mit Sicherheit auf einer Abstraktionsebene, die dem damaligen Datenbankdenken fremd war - hat es viele Jahre gedauert, bis dieses Modell sich auch in der Welt der kommerziellen Datenverarbeitung verbreiten konnte. Selbst heute noch machen bekannte Redner und Autoren den Fehler, über ein Datenmodell zu sprechen, als ob es nur eine Datenstruktur wäre. Ein häufiger Irrtum ist beispielsweise die Verwechslung von "flat file data model" mit "flat file structure".

Ein Datenmodell ist vielmehr mindestens eine Kombination der folgenden "drei" Komponenten:

1. einer Sammlung von Datenstrukturtypen (die Bausteine jeder Datenbank, die auf diesem Modell beruht);

2. einer Sammlung von Operatoren oder Folgeregeln, die auf jedes gültige Vorkommen der unter 1. aufgeführten Datentypen angewandt werden können, um Daten aus beliebigen Teilen dieser Strukturen in jeder gewünschten Kombination auslesen oder ableiten zu können;

3. einer Sammlung allgemeiner Integritätsregeln, die implizit oder explizit die Menge der konsistenten Datenbankzustände oder Zustandsübergänge oder auch beides definieren. Diese Regeln können manchmal als Einfüge-, Update-, Löschregeln (Insert-, Update-, Delete-Rules) ausgedrückt werden.

Viele Datenbanksysteme verfügen über, für den Benutzer erkennbare strukturelle Verbindungen, die von den Anwendungsprogrammen auf direktem Weg zu durchmessen sind. Ein wesentlicher Teil des Relationenmodells ist der Ersatz der strukturellen Verbindungen durch höhere Operatoren (wie in der relationalen Algebra) oder Befehle (wie in der Datensprache "Alpha" und ihren Nachfolgern, etwa SQL). Diese Operatoren und Befehle sind leistungsfähiger als die Verbindungen, die sie ersetzen. Es ist daher abwegig, vom Relationenmodell lediglich als von einer Sammlung von Tabellen oder Dateien in fester Satzlänge ("flat files") zu sprechen.

Kurz nach Veröffentlichung der ersten Arbeiten über das Relationenmodell wurde die Planung und Entwicklung mehrerer Prototypen-Systeme auf der Grundlage dieses Modells in mindestens vier verschiedenen IBM-Forschungs- und Entwicklungszentren in Angriff genommen.

Der erste dieser Prototypen mit der Bezeichnung PRTV wurde am IBM United Kingdom Scientific Centre entwickelt; das damals in Peterlee, England, beheimatet war. Es wurde als analytisches Werkzeug in den Bereichen der Kommunalverwaltung und der Gesundheitsstatistik besonders erfolgreich eingesetzt.

Als zweiter Prototyp wurde das Extended Relational Memory (XRM) des IBM Scientific Centers in Cambridge, Massachusetts, entwickelt. XRM experimentierte mit neuen Techniken der Datendarstellung und des Datenzugriffs bei relationalen Datenbanken. Die Ergebnisse dieser Arbeiten gingen später in die Prototyp-Entwicklungen in San Jose, Kalifornien, ein.

Ein späterer Prototyp mit dein Namen Query-By-Example (QBE) wurde im Thomas J. Watson Research Center, Yorktown Heights, New York, entwickelt und 1978 als " Installed User Program" freigegeben, das nach wie vor für Systeme unter VM/CMS verfügbar ist: QBE hat eine Terminalschnittstelle, die speziell für Bildschirmgeräte entwickelt wurde. Es bildet auf dem Bildschirm Tabellen ab, in die der Benutzer die Elements seiner Abfrage einträgt (in der vom jeweiligen Benutzer gewünschten Ordnung).

Der ehrgeizigste IBM-Prototyp, das System R, wurde im Forschungslaboratorium San Jose entwickelt. Es wurde 1977 in Betrieb genommen und hat seitdem eine äußerst umfangreiche Prüfung durchlaufen und viele Verbesserungen erfahren.

Von diesen Prototypen und besonders vom System R-Projekt in San Jose hat die IBM viel Erfahrung über die Art der Zugriffsmethoden, der Speicherzuordnungsverfahren, der Sperrverfahren und der Wiederherstellungsverfahren gesammelt, die zur wirksamen Unterstützung des Relationenmodells erforderlich sind.

Als Folge dieser Forschungsarbeiten läuft SQL/DS effizient auf konventioneller IBM-Hardware, ohne daß irgendwelche speziellen Hardware-Hilfen benötigt werden. Die Testinstallationen haben den Entwicklungsingenieuren sehr positive Rückäußerungen von ganz unterschiedlichen Benutzern eingebracht. Diese Rückäußerungen wurden sorgfältig geprüft und, wo immer möglich, durch das Produktentwicklungsteam im IBM-Laboratorium Endicott im endgültigen Entwurf von SQL/DS berücksichtigt.

Abschließend möchten wir betonen, daß SQL/DS ein relationales Datenbanksystem ist, das nicht nur auf der soliden theoretischen Begründung des Relationenmodells beruht, sondern gleichermaßen auf einer intensiven und extensiven Erprobung von Prototypen.

Wir haben allen Grund, hinsichtlich seiner weiteren Entwicklung optimistisch zu sein.

Dr. Edgar F. (Ted) Codd

Ist der Urheber des Relationenmodells für Datenbanken. Seine relationale Algebra, relationale höhere Mathematik und Normalisierung von Relationen üben eine tiefgreifende Wirkung auf das Gebiet der Datenbankverwaltung aus. In den Jahren 1959 bis 1961 leitete Dr. Codd die Entwicklung eines der ersten Betriebssysteme mit allgemeinen Multiprogramming-Einrichtungen. Er ist Autor des Buches "Cellular Automata". Dr. Codd erhielt seinen B.A. und M.A. in Mathematik an der Oxford University in England und die Titel M.Sc. und Ph.D. in Informatik und Kommunikationstheorie an der University of Michigan. Er ist Fellow der IBM und der British Computer Society und gegenwärtig in der Forschung am IBM San Jose Research Laboratory, California, tätig.