• Interactive SQL (ISQL),
• BatchSQL (BSQL),
• EmbeddedSQL (ESQL).

Die einzelnen Statements (Anweisungsfolgen) werden in der Regel wie folgt dargestellt: Name des Statements, Bedeutung, Syntax, Beschreibung, Beschränkungen, Hinweise, Beispiele.
Grundsätzlich kann festgestellt werden, dass die optimistischen Termine aus den Jahren 1989/1990 für die folgenden Jahre nicht durchweg eingehalten werden konnten, was in der Schwierigkeit der Problematik zu suchen ist. U. a. sind folgende Fragen zu beantworten: Was ist von dem theoretisch Fundierten für die Praxis allgemein relevant? Was lässt sich von den aktuellen Forderungen heute effektiv oder überhaupt implementieren? Und alle Fragen müssen bei unterschiedlicher Interessenlage konkurrierender Entwicklerfirmen einheitlich beantwortet werden!
Date Boyce und Codd, sind die bedeutensten Theoretiker auf dem Gebiet der relationalen Datenbanken und SQL89 steht zwischenzeitlich schlechthin für Datenbanksysteme.

• Lehr- und Übungsbuch Informatik Band 1 - 5 Seite ???
• Technische und Theoretische Informatik  Seite ???

Von ALPHA zu SQL

1970 veröffentlichte E.F. Codd /1/, ein Mitarbeiter von IBM, sein relationales Datenmodell. Dieses Datenmodell sollte durch seine theoretische Grundlage einige Nachteile der anderen beiden Datenmodelle, des hierarchischen und des Netzwerk-Datenmodells, beseitigen. Zum einen ging es um eine konsequentere Trennung von logischer und physischer Ebene einer Datenbank und zum anderen um die Entwicklung einer Datenbanksprache, die das "Was" und nicht das "Wie" in den Vordergrund stellt. Mit anderen Worten: Es ging nicht so sehr um die Formulierung von Algorithmen, sondern um eine deskriptive Notation von Datenbeziehungen und Anfragen. Auf dem Gebiet der höheren Programmiersprachen lagen Erfahrungen in der Formulierung von Algorithmen vor. Eine Entwicklung im evolutionären Sinne führte zu Erweiterungen von Sprachen der dritten Generation für die dauerhafte (persistente) Datenhaltung und schließlich zu Datenmanipulationssprachen, beispielsweise DL/1 (DL-data language) im hierarchischen Datenverwaltungssystem IMS von IBM. (Man beachte die Ähnlichkeit in der Namensgebung zu PUI, programming language, von IBM). zu viele Angaben in diesen Spra-chen beschrieben, wie ein Datensatz aufgebaut ist, wie er gespeichert wird, wie seine Verbindung zu Sätzen anderer Typen ist, wie Indexstrukturen organisiert sind usw. Diese Angaben haben mit dem logischen Schema einer Datenbank nur wenig zu tun. Allerdings, und das muß man diesen Kalten DBMSS lassen, wird dadurch die Verarbeitungsgeschwindigkeit wesentlich gesteigert (DBMS - database Management System). Standardisie-rungsbestrebungen gab es auch für das Netzwerk-Datenmodell, die letztlich in CODASYL-Vorschlägen (CODASYL - conference on data Systems languages) der DBTG(databasetaskgroup)von 1971 bis 1978 zusammengefaSt sind. Um die Semantik klarer zu fassen, ging das Bemü-hen dahin, eine möglichst deskriptive Sprache zu finden, also das Swasi zu modellieren und die konkrete Implementation auf der physischen Ebene weitgehend dem Datenbankverwaltungssystem zu überlassen.
Nach der mathematischen Formulierung des relationalen Modells, der Beschreibung der gültigen Operationen in der Relationenalgebra und der Formulierung des gleichen Sachverhalts innerhalb anderer mathematischer Theorien (Relationen-Tupel-Kalkül, Prädikatenkalkül), wurde eine Sprache benötigt, die die mathematischen Sachverhalte wiedergibt, leicht erlernbar und verständlich und auf dem Rechner realisierbar ist. Den ersten Versuch einer Relationenkalkül-Sprache für den rechentechnischen Gebrauch nannte Codd 1971 ALPHA. In ALPHA wird versucht, durch Umsetzung des Prädikatenkalküls der ersten Stufe (PK1) Anfragen und Restriktionen (Sonstrains) für die Attribute zu formulieren. Die eigentlichen Lese- und Schreiboperationen treten hinter den PK1 Konstrukten zurück. ALPHA war aber noch zu unhandlich. Im nächsten Schritt wurde versucht, eine abbildungsorientierte Sprache zu definieren, die zu penetrante mathematische Notationen, wie die Quantoren, für den Nicht-Mathematiker günstiger formuliert. Es entstand 1976 die Sprache SEQUEL, die später zu SQL wurde.

Standard-Sprache-Datenmodell

SQL wurde also primär für relationale DBMS entworfen. Der erste Versuch einer ernsthaften Implementation wurde von IBM im DBMS System R unternommen. System R stellt mehr einen Prototyp dar, da ernsthafte Anwendungen im kommerziellen Bereich in der Literatur kaum zitiert werden. Aus dem System R entstanden zwei wesentliche relationale Datenbankverwaltungssysteme, DB2 von IBM für große Mainframes und Oracle von der Firma Oraele GmbH. So verwundert die in Oracle ausgewiesene Kompatibilität zu DB2 auch nicht. Selbstverständlich gibt es weitere bedeutende relationale DBMS (Informix, Sybase, Ingres, DDB4, ...), die hier weder alle erwähnt noch besprochen werden sollen.
Entscheidend ist, dass es, eingeleitet durch das American National Standard Institute (ANSI), gelang, einen internationalen Standard für SQL bei der International Standard Organisation (ISO) im Jahr 1986 festzuschreiben (ISO 9075). Dieser SQL-Standard wurde 1987 durch ein Addendum ISO 9075 ergänzt, das Erweiterungen hinsichtlich der Integritätssicherung (Integrity Enhancements) beschreibt /2/. Bedeutend ist ferner, dass die meisten Hersteller großer DBMS diesen Standard als Kern ihrer Datenbanksprache implementiert haben. Dadurch wird der Standard mit Leben erfüllt. Der Wettlauf zwischen der Standardisierung, ihrer praktischen Berücksichtigung in Implementationen und den aktuellen Anforderungen der Anwender ist damit keineswegs entschieden. Ein SQL2-Standard ist bei der ISO seit 1986 in Entwicklung. Er sollte 1990 fertiggestellt sein. Schon vor der Fertigstellung zeigen sich aber zumindest zwei Nachteile:

1. Er ist zu umfangreich und schwer verständlich und
2. er genügt nicht den aktuellen Anforderungen moderner Anwendungen.

Kennern der Softwareszene drängt sich in diesem Zusammenhang die Erinnerung an das Schicksal des Pascal-Standards auf, der durch Turbo-Pascal aufgeweicht wurde. Auf dem Gebiet der Datenbanken ist die Notwendigkeit eines Standards nach meiner Auffassung noch dringlicher. Denken wir nur an den Datenaustausch zwischen Datenbanken, an die kooperative Arbeit unterschiedlicher Datenbanken in einem Netz usw. (vgl. dazu 13). Bezieht sich eine Anfrage gleichzeitig auf mehrere Datenbanken, so kann diese Anfrage nur in einer Sprache formuliert sein und muss von allen angesprochenen Datenbanken verstanden werden. Hier liegt sicher ein erheblicher Qualitätsunterschied zur Portabilität von Quellprogrammen, etwa in Pascal oder C. Hersteller und Nutzer sind gleichermaßen gezwungen, einen Standard zu formulieren und ihn einzuhalten. Welche Stellung hat SQL, als Sprache für das relationale Datenmodell (RDM), im Verhältnis zu anderen Datenmodellen? Drei Dinge sind zu berücksichtigen:

1. Die Stellung zum DBMS-unabhängigen Entity-Relationship-Modell (ER-Modell).
2. Das Verhältnis zu den anderen Standard-Datenmodellen, dem hierarchischen Datenmodell (HDM), repräsentiert durch das IMS, und dem Netzwerkdatenmodell (auch Codasyl-Modell genannt), repräsentiert durch UDS von Siemens.
3. Die Einpassung in weiterentwickelte Datenmodelle, die mehr Semantik widerspiegeln (semantische Datenmodelle). Repräsentanten sind das NFNF oder NF2 (non first normal form) und das Molekül-Atom-Datenmodell (MAD).

Ein Datenbankentwurf nach dem ER-Modell lässt sich relativ leicht ins relationale Modell überführen. CASE-Toolsfürdiesen Schritt sind im Angebot.
Für die Kooperation mit IMS- oder UDS-Datenbanken hat man ebenfalls die SQL-Schnittstelle gewählt, das heißt, es gibt Shells, die eine SQL-Anfrage an diese Datenbanken gestatten. Beispiele dafür find UDS-D (UDS/SQL) und IMS/DB2.
Das Bestreben, mehr Semantik in die frühen Phasen des Datenbankentwurfs zu bringen und in der Datenbanksprache deskriptiv zu formulieren, führte zu Erweiterungen des relationalen Datenmodells. Xn SQL wurden Erweiterungen vorgenommen, die zwar nicht konform zum geplanten SQL2-Standard, aber dringend erforderlich sind. Forschungsimplementationen sind in der Erprobung. Als Prototyp eines DBMS, das ein NF2-Modell favorisiert, ist AIM-P (advanced Information management-Prototype) von IBM zu nennen /5/.
Natürlich gibt es sehr viele offene Probleme in der Konstruktion von Datenbanksprachen für die Verwaltung komplexer oder multimedialer Objekte. Eine noch bessere hierarchische Trennung der Konstrukte sowie die Anreicherung durch Elemente der Wissensverarbeitung (regelbasiert) scheint der Weg in die richtige Richtung zu sein. Existierende Softwarepakete zur Verwaltung komplexer Objekte zeigen, dass eine bildliche Anfragesprache reichere Formulierungsmöglichkeiten bietet. Sie entspricht mehr den Bedürfnis-sen des Endnutzers. Der Nachteil besteht allerdings darin, dass sie für die Formulierung in Programmen, also für den Batch-Betrieb, nicht geeignet ist.
Nach der Beleuchtung des Umfelds von SQL wenden wir uns nun der Sprache direkt zu. Jede Datenbanksprache lässt sich in zwei große Gruppen von Sprachkonstrukten unterteilen: die Datenmanipulationssprache (DML) und die Datendefinitionssprache (DDL). Feinere Unterteilungen sind aus der Literatur bekannt, werden aber in der Praxis kaum verwendet. So spricht man gelegentlich von einer Constraint Definition Language (CDL), einer Event Definition Language (EDL), einer Data Control Language (DCL) usw.

Die Datenmanipulationssprache

Wir verschieben zunächst die Definition von Relationen auf einen späteren Abschnitt und beschäftigen uns mit der zentralen Anweisung der DML von SQL: der SELECT-Anweisung. Sie hat, stark vereinfacht, die Grundstruktur

SELECT ...
FROM ...
WHERE . . .

Als Ergebnis der Abarbeitung einer SE-LECT-Anweisung entsteht wieder eine Relation. Damit liefern Projektion, Selektion und Join wieder Relationen, so dass die relationale Algebra bezüglich dieser Operationen abgeschlossen ist.
Bis auf Feinheiten folgen nach dem Schlüsselwort SELECT Angaben über die Projektion, das heißt, es werden die Attribute (Spalten) der Ergebnisrelation festgelegt (<auswahlliste>). Die aufgeführten Attributbezeichner können dabei aus verschiedenen Relationen oder Views kommen. Nach FROM folgt eine Aufzählung der Relationen oder Views (<tabellenreferenz>), auf die die SELECT-Anweisung angewendet wird. Schließlich dient die WHERE-Klausel zur Angabe einer Selektionsbedingung (<suchbedingung>).

Das American National Standard Institute (ANSI) bildete Ende der 70er Jahre eine Gruppe zur Entwicklung eines Standards für relationale Datenbanksprachen. Am Anfang standen Untersuchungen der bis dahin voneinander isoliert entwickelten und implementierten Sprachen von DBMS mit dem Ziel, gemeinsame Funktionen zu erkennen, die sich einer Vereinheitlichung besonders anboten. Die Arbeit verlief zunächst analytisch, wurde aber bald zunehmend von theoretischen Vorstellungen getragen.
1981 begann die Entwicklung des Standards auf der Grundlage einer Datenbanksprache, die durch die Fa. IBM im System/R bereits implementiert worden war.
Seit 1982 wurden die Standardisierungsbestrebungen durch die International Standards Organisation (ISO) (Westeuropa) und verschiedene nationale Standardisierungsorganisationen, die mit der ISO assoziiert waren, übernommen.
Es entstand die ISO-Gruppe für Database Languages, um den ANSI-Standard zu analysieren und als Grundlage für die Entwicklung eines ISO-Standards zu nutzen.
ISO und ANSI veröffentlichten 1986 gemeinsam den ersten Standard für SQL, heute im allgemeinen SQL86 genannt.
Im Standard SQL86 wurden grundlegende Sprachkonstrukte zur Datendefinition und -manipulation definiert. Aufgrund der bis dahin sehr differenzierten Datenbanksprachen umfasste dieser Standard nur die wichtigsten Funktionen, zu denen einheitliche Auffassung zu erzielen war.
Interessant sind die Angaben von 1989 zu vergleichbaren DBMS

• DB2 (IBM) Rel. 3
• INFORMIX V 2.10
• INGRES V 5.0,
• ORACLE V 5.1,
• SQL/DS Rel. 3
• SYBASE V 3.4

Erstaunlich ist, dass zur damaligen Zeit wichtige Forderungen des Standards bezüglich der Integritätssicherung nicht erfüllt wurden.:

• TABLE: Spalte NOT NULL bei allen genannten DBMS möglich;
• INDEX UNIAUE mit Ausnahme von INGRES möglich Damit war die Möglichkeit gegeben, einen Primärschlüssel wenigstens indirekt nutzergesteuert zu erzeugen. Bei keinem der genannten DBMS war es jedoch möglich, eine Spalte als PRIMARY KEY bzw. FOREIGN KEY2 direkt zu definieren. (Das DBMS MIMER in der Version 5.1 erfüllte dagegen diese Funktionen bereits 1988!)
• den UNION-Operator (sowie auch die Operatoren INTERSECT und MINUS) zur Verbindung von mehreren Select-Abfragen in einem einzigen Statement gab es nur bei ORACLE

Standard SQL86 formulierte die grundsätzlichen Forderungen an die Datendefinition und Datenmanipulation.

• einzelne Spalte in der Tabelle (Feld von einem bestimmten Datenfeldtyp) einschließlich seinem Namen
• das Attribut entspricht einem Merkmal eines Tupels und beschreibt somit eine spezifische Eigenschaft einer Entitätsmenge. Bsp. Name, Adresse, Alter etc.

AND-Logik mit NULL-Werten

OR-Logik mit NULL-Werten

NOT-Logik mit NULL-Werten

Die Auswirkung der NULL-Werte sei am Beispiel der Berechnung des durchschnittlichen Monatseinkommen (AVG (averange)) illustriert:

Bruttoverdiensttabelle mit NULL-Werten - das Durchschnittsgehalt ermittelt sich Summe : 4 und nicht Summe : 5

• Bestandsrelation: bildet eine Objektklasse mit identischen Merkmalen (Feldern) ab
• Beziehungsrelation: schafft eine Beziehung zwischen zwei verschiedenen Bestandsrelationen

... dieser Text wurde nach den Regeln irgendeiner Rechtschreibreform verfasst - ich hab' irgendwann einmal beschlossen, an diesem Zirkus (das haben wir schon den Salat - und von dem weiß ich!) nicht mehr teilzunehemn ;-)

„Dieses Land braucht eine Steuerreform, dieses Land braucht eine Rentenreform - wir schreiben Schiffahrt mit drei „f“!“

Diddi Hallervorden, dt. Komiker und Kabarettist

Diese Seite wurde ohne Zusatz irgendwelcher Konversationsstoffe erstellt ;-)