Zusammenfassung
SQL hat sich als Standardabfragesprache für relationale Datenbanken etabliert. SQL steht ursprünglich für „Structured Query Language“. Die ersten Versuche dazu wurden in den IBM-Labors vorgenommen und daraus ist die Vorläufersprache SEQUEL entstanden. SQL stellt die Schnittstelle zwischen der relationalen Datenbank und dem Anwendungsprogramm dar. Die Sprache ist in erster Linie nicht für Endanwender gedacht, sondern für Systementwickler. Mit SQL lassen sich alle Operationen der Relationenalgebra realisieren, die in Kap. 3 eingeführt worden sind.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Bei einigen Datenbanksystemen erfolgt eine Umsetzung in Kleinbuchstaben.
- 2.
Das beispielsweise bei Oracle vorhandene Cluster-Konzept sieht die Speicherung von Tupeln verschiedener Tabellen, die häufig miteinander verbunden werden, physikalisch benachbart auf den Plattensektoren vor, um damit die Anzahl der Zugriffe zu reduzieren.
- 3.
Wir empfehlen dieses Beispiel hier nicht als Übung.
- 4.
Zur Unterscheidung der Begriffe Tupel, Zeile, Attribut, Spalte, Relation und Tabelle vgl. Abschn. 3.1.
- 5.
Näheres findet sich in Abschn. 7.2.
- 6.
Unter einem Benutzer verstehen wir einen in der Datenbank namentlich eingetragenen, mit bestimmten Zugriffsrechten ausgestatteten Anwender der Datenbank. Benutzer und Person sind nicht unbedingt identisch. Einer Person können je nach Anwendungszusammenhang verschiedene Benutzernamen zugeordnet sein, beispielsweise einer für die Rolle als Datenbankadministrator und ein anderer für die normale Nutzung der Datenbank. Umgekehrt kann es manchmal organisatorisch sinnvoll sein, einen Benutzernamen (z. B. GAST) einzurichten, unter dem sich verschiedene Personen anmelden können, um allgemein zugängliche Informationen abzufragen (Auskunftssysteme).
- 7.
Der Begriff „Datenbankobjekt“ darf nicht mit dem Objektbegriff der objektorientierten Datenbankmodelle verwechselt werden (Dazu Näheres im zweiten Band dieses Buchs: „Anwendungsentwicklung mit Datenbanken“).
- 8.
Sie erfüllen aber nur einen Teil des im Abschn. 3.1.2 eingeführten Domänenkonzeptes.
- 9.
Wird in Abschn. 4.4.4 kurz behandelt.
- 10.
Die formale Syntaxbeschreibung ist im Anhang B beschrieben.
- 11.
Wir erläutern dieses Konzept im zweiten Band dieses Werks: „Anwendungsentwicklung mit Datenbanken“.
- 12.
In der SQL-Norm ist nicht geregelt, ob SQL-Anweisungen durch ein Satzzeichen abgeschlossen werden müssen. In den verschiedenen interaktiven SQL-Systemen (ISQL) hat sich das Semikolon als abschließendes oder als trennendes Satzzeichen etabliert. Wir werden im Folgenden SQL-Anweisungen jeweils durch ein Semikolon abschließen.
- 13.
Benutzerdefinierte Funktionen behandeln wir im zweiten Band dieses Buchs: „Anwendungsentwicklung mit Datenbanken“.
- 14.
Zwei senkrechte Striche, im ASCII-Code durch den Wert 124 wiedergegeben.
- 15.
Vgl. [DaDa93 Kap. 19].
- 16.
Im Gegensatz dazu stellen Zeichenketten, die in doppelte Apostrophs eingeschlossen sind quotierte Bezeichner dar, vgl. hierzu Abschn. 2.2.
- 17.
Das ist einer der Wert e INITIALLY IMMEDIATE oder INITIALLY DEFERRED.
- 18.
Wir haben hier der Deutlichkeit halber den Befehl ohne Rückgriff auf Domänen formuliert. Sonst würden in diesem Befehl keine CHECK-Klauseln auftreten, da diese in den Domänendefinitionen enthalten sind.
- 19.
Bei Relationen wäre dies ohnehin gegeben, bei Tabellen sind aber mehrere gleiche Tupel möglich (vgl. Abschn. 7.2).
- 20.
Der hier vorgestellte Befehl CREATE ASSERTION konnte bisher nicht getestet werden, da kein den Autoren zugängliches DBMS ihn unterstützt.
- 21.
In diesem Buch nicht weiter behandelt.
- 22.
Von Transaktionen wird in Abschn. 6.2 die Rede sein.
- 23.
Das ändert nichts daran, dass erfahrene Anwendungsentwickler unter Umständen eine von mehreren äquivalenten Formulierungen einer Abfrage bevorzugen, um den Optimierer „auszutricksen“. Sie riskieren aber, dass beim nächsten Versionswechsel des DBMS der erwünschte Effekt nicht mehr eintritt.
- 24.
Allerdings können die Antwortzeiten in den beiden Fällen erheblich voneinander abweichen.
Author information
Authors and Affiliations
Corresponding authors
Rights and permissions
Copyright information
© 2012 Springer-Verlag Berlin Heidelberg
About this chapter
Cite this chapter
Unterstein, M., Matthiessen, G. (2012). Datendefinition in SQL. In: Relationale Datenbanken und SQL in Theorie und Praxis. eXamen.press. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-28986-6_4
Download citation
DOI: https://doi.org/10.1007/978-3-642-28986-6_4
Published:
Publisher Name: Springer, Berlin, Heidelberg
Print ISBN: 978-3-642-28985-9
Online ISBN: 978-3-642-28986-6
eBook Packages: Computer Science and Engineering (German Language)