Händler-Datenbank (SQL-Beispiel)/Identität
Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen:
| Korrektheit: 4 (großteils überprüft) |
Umfang: 4 (unwichtige Fakten fehlen) |
Quellenangaben: 4 (fast vollständig vorhanden) |
Quellenarten: 5 (ausgezeichnet) |
Konformität: 5 (ausgezeichnet) |
Die nachfolgenden Beispiele können beispielsweise mit SQLite oder PostgreSQL getestet werden. Installieren Sie dazu die zugehörige Händler-Datenbank.
Die Identität
Die Identitätsfunktion der Relationalen Algebra ist eine triviale Funktion: Sie bildet eine Relation (Tabelle) auf sich selbst ab:
$ id: R \rightarrow R $
$ id(r) = r $
Diese Funtion ist idempotent:
$ id(id(r)) = id(r) = r $
Beispiele bezüglich der Händler-Datenbank
(Diese Beispiele wurden mit PostgreSQL und SQLite getestet.)
In SQL ist es nicht möglich, auf den Inhalt einer benannten Tabelle zuzugreifen, indem man einfach den Namen der Tabelle angibt. Folgendes ist also keine korrekte SQL-Anfrage:
haendler
Um den Inhalt einer Tabelle auszugeben, benötigt man also eine Identitätsfunktion. Diese gab es noch in SQL-92:[1]
TABLE haendler
Dieser Befehl wird beispielsweise von PostgreSQL unterstützt (nicht aber von SQLite).
In SQL-99 (und in den meisten SQL-Datenbank-Management-Systemen) gibt es diese Funktion allerdings nicht mehr.[2] Als Identitätsfunktion kommt hier
SELECT * FROM zum Einsatz:
SELECT * FROM haendler
Das zuvor formulierte Idempozenz-Gesetz gilt auch in SQL, wenn auch mit der zuvor genannten Einschränkung, dass es sich bei der direkten Angabe eines Tabellennamens um keinen korrekten SQL-Befehl handelt:
SELECT * FROM (SELECT * FROM haendler)
=
SELECT * FROM haendler
=
TABLE haendler /* SQL-92, aber nicht SQL-99 */
=
haendler /* kein SQL*/
Anmerkung 1
In PostgreSQL läuft – im Gegensatz zu SQLite – die erste der drei obigen Anfrage auf einen Fehler, da hier
Unterabfragen stets benannt werden müssen.
In PostgreSQL muss man die erste Select-Anweisung daher folgendermaßen schreiben:
SELECT * FROM (SELECT * FROM haendler) AS dummy
Anmerkung 2
Die Selektion SELECT * FROM sollte man i. Allg. nur für Ad-hoc-Anfragen
in Tools wie phpPgAdmin oder pgAdmin III verwenden. In Programmcode sollte
man darauf verzichten und besser alle Attribute explizit aufführen. Das heißt,
an Stelle von
SELECT * FROM haendler
sollte man
SELECT h_id, h_name, h_adresse FROM haendler
schreiben. Der Grund ist, dass die SELECT-*-Anfrage ihre Bedeutung ändert,
wenn sich das Schema der Datenbank ändert, wenn also z.B. ein weiteres Attribut zur Tabelle
haendler hinzugefügt wird (vgl. die Tabelle haendler in
Händler-Datenbank). Das heißt, aufgrund einer Schema-Änderung
könnte sich ungewollt das Verhalten eines Programms ändern. Zum Beispiel könnte eine Tabelle,
die das Ergbnis einer Select-Anfrage ausgibt, plötzlich mehr Spalten als geplant enthalten.
Darüber hinaus ist die Attribut-Reihenfolge bei SELECT-*-Anfragen nicht
festgelegt. Auch diese kann sich plötzlich unerwartet ändern – zum Beispiel nach einer Modifikation der Domäne eines der Attribute,
wie z. B. der Änderung der Anzahl der erlaubten Zeichen der Domäne des
Attributs h_adresse (beispielsweise VARCHAR(50) → VARCHAR(100)).
Quellen
- ↑ Date, Darwen (1993): Christopher J. Date und Hugh Darwen; A Guide to the SQL Standard – A user's guid to the standard relational language SQL; Auflage: 3; Verlag: Addison-Wesley; Adresse: Reading, Massachusetts, USA; 1993; Quellengüte: 5 (Buch), S. 126
- ↑ Gulutzan, Pelzer (1999): Peter Gulutzan und Trudy Pelzer; SQL-99 complete, Really – An Example-Based Reference Manual of the New Standard; Verlag: R&D Books; ISBN: 0-87930-568-1; 1999; Quellengüte: 5 (Buch)
- Kowarschick (MMDB-Skript): Wolfgang Kowarschick; Vorlesung Multimedia-Datenbanksysteme – Sommersemester 2018; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 4 (Skript)
- Kowarschick (MMDB): Wolfgang Kowarschick; Vorlesung „Multimedia-Datenbanksysteme“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2016; Quellengüte: 3 (Vorlesung), http://mmdb.hs-augsburg.de/beispiel/haendler/
