Händler-Datenbank (SQL-Beispiel)/Identität: Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
(31 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 6: | Zeile 6: | ||
|conformance = 5 | |conformance = 5 | ||
}} | }} | ||
Die nachfolgenden Beispiele können beispielsweise mit [[SQLite]] oder [[PostgreSQL]] getestet werden. | |||
Installieren Sie dazu die zugehörige [[Händler-Datenbank (SQL-Beispiel)|Händler-Datenbank]]. | |||
= Die Identität = | == Die Identität == | ||
Die Identitätsfunktion der [[Relationale Algebra|Relationalen Algebra]] ist eine triviale Funktion: | [[File:Relational_Algebra_Single_Table_Identity.svg|mini|200px|Die Identitätsfunktion verändert eine Tabelle nicht]] | ||
Die Identitätsfunktion der [[Relationale Algebra#Identit.C3.A4t|Relationalen Algebra]] ist eine triviale Funktion: | |||
Sie bildet eine Relation (Tabelle) auf sich selbst ab: | Sie bildet eine Relation (Tabelle) auf sich selbst ab: | ||
Zeile 21: | Zeile 25: | ||
<math>id(id(r)) = id(r) = r</math> | <math>id(id(r)) = id(r) = r</math> | ||
</div> | </div> | ||
== Beispiele bezüglich der [[Händler-Datenbank (SQL-Beispiel)|Händler-Datenbank]]== | |||
Den nachfolgenden Beispielen liegt die [[Händler-Datenbank_(SQL-Beispiel)|Händler-Datenbank]] zugrunde. | |||
Alle Beispiele wurden mit [[PostgreSQL]] und [[SQLite]] getestet. | |||
In jedem Fall wird Händlertabelle auf sich selbst abgebildet: | |||
<table> | |||
<tr><td><math>\texttt{haendler}</math></td><td>→ </td><td><math>\textrm{id}(\texttt{haendler})</math></td></tr> | |||
<tr> | |||
<td><table class="datatable-sql"> | |||
<tr><th>h_id</th><th>h_name</th><th>h_ortschaft </th></tr> | |||
<tr><td> 1 </td><td> Maier </td><td> Königsbrunn </td></tr> | |||
<tr><td> 2 </td><td> Müller </td><td> Königsbrunn </th></tr> | |||
<tr><td> 3 </td><td> Maier </td><td> Augsburg </th></tr> | |||
<tr><td> 4 </td><td> Huber </td><td> NULL </th></tr> | |||
<tr><td> 5 </td><td> Schmidt </td><td> Hamburg </th></tr> | |||
</table></td> | |||
<td>→ </td> | |||
<td><table class="datatable-sql"> | |||
<tr><th>h_id</th><th>h_name</th><th>h_ortschaft </th></tr> | |||
<tr><td> 1 </td><td> Maier </td><td> Königsbrunn </td></tr> | |||
<tr><td> 2 </td><td> Müller </td><td> Königsbrunn </th></tr> | |||
<tr><td> 3 </td><td> Maier </td><td> Augsburg </th></tr> | |||
<tr><td> 4 </td><td> Huber </td><td> NULL </th></tr> | |||
<tr><td> 5 </td><td> Schmidt </td><td> Hamburg </th></tr> | |||
</table></td> | |||
</tr></table> | |||
In SQL ist es nicht möglich, auf den Inhalt einer benannten Tabelle zuzugreifen, | In SQL ist es nicht möglich, auf den Inhalt einer benannten Tabelle zuzugreifen, | ||
Zeile 29: | Zeile 59: | ||
</source> | </source> | ||
Um den Inhalt einer Tabelle auszugeben, benötigt man | Um den Inhalt einer Tabelle auszugeben, benötigt man daher in SQL auf jeden Fall eine Identitätsfunktion. | ||
In SQL-92 gab es noch eine dedizierte Identitäsfunktion: <code>TABLE</code><ref>{{Quelle|Date, Darwen (1993)}}, S. 126</ref> | |||
<source lang="sql"> | <source lang="sql"> | ||
Zeile 36: | Zeile 66: | ||
</source> | </source> | ||
In SQL-99 | Dieser Befehl wird beispielsweise von [[PostgreSQL]] unterstützt . | ||
In SQL-99 und in den meisten SQL-[[Datenbank-Management-System]]en, wie beispielsweise [[SQLite]], gibt es diese Funktion allerdings nicht mehr.<ref>{{Quelle|Gulutzan, P.; Pelzer, T. (1999): SQL-99 complete}}</ref> Als Identitätsfunktion kommt hier ersatzweise | |||
<code>SELECT * FROM</code> zum Einsatz: | <code>SELECT * FROM</code> zum Einsatz: | ||
Zeile 43: | Zeile 74: | ||
</source> | </source> | ||
Das zuvor formulierte Idempozenz-Gesetz gilt auch in SQL, wenn auch mit der | Das zuvor formulierte Idempozenz-Gesetz gilt auch in SQL, wenn auch mit der genannten Einschränkung, dass | ||
es sich bei der direkten Angabe eines Tabellennamens um keinen korrekten SQL-Befehl handelt: | es sich bei der direkten Angabe eines Tabellennamens um keinen korrekten SQL-Befehl handelt: | ||
Zeile 51: | Zeile 82: | ||
SELECT * FROM haendler | SELECT * FROM haendler | ||
= | = | ||
TABLE haendler /* SQL-92, aber nicht SQL-99 */ | |||
= | |||
haendler /* kein SQL*/ | |||
</source> | </source> | ||
'''Anmerkung 1'''<br/> | |||
In PostgreSQL läuft – im Gegensatz zu SQLite – die erste der drei obigen Anfrage auf einen Fehler, da hier | |||
In PostgreSQL läuft die erste der drei obigen Anfrage auf einen Fehler, da hier | |||
[[Unterabfrage]]n stets benannt werden müssen. | [[Unterabfrage]]n stets benannt werden müssen. | ||
In PostgreSQL muss man die erste Select-Anweisung daher | In PostgreSQL muss man die erste Select-Anweisung daher folgendermaßen schreiben: | ||
<source lang="sql"> | <source lang="sql"> | ||
SELECT * FROM (SELECT * FROM haendler) AS | SELECT * FROM (SELECT * FROM haendler) AS dummy | ||
</source> | </source> | ||
'''Anmerkung 2'''<br/> | |||
Die | Die Kurzschreibweise <code>*</code> sollte man i. Allg. nur für Ad-hoc-Anfragen | ||
in Tools wie [[phpPgAdmin]] oder [[pgAdmin | in Tools wie [[phpPgAdmin]] oder [[pgAdmin]] verwenden. In einem Programmcode sollte | ||
man darauf verzichten und besser alle Attribute explizit aufführen. Das heißt, | man darauf verzichten und besser alle Attribute explizit aufführen. Das heißt, | ||
an Stelle von | an Stelle von | ||
Zeile 77: | Zeile 109: | ||
<source lang="sql"> | <source lang="sql"> | ||
SELECT | SELECT h_id, h_name, h_ortschaft FROM haendler | ||
</source> | </source> | ||
schreiben. Der Grund ist, dass die <code>SELECT-* | schreiben. Der Grund ist, dass die <code>SELECT</code>-<code>*</code>-Anfrage ihre Bedeutung ändert, | ||
wenn sich das Schema der Datenbank ändert, wenn also z.B. ein weiteres Attribut zur Tabelle | wenn sich das Schema der Datenbank ändert, wenn also z.B. ein weiteres Attribut zur Tabelle | ||
<code>haendler</code> hinzugefügt wird (vgl. | <code>haendler</code> hinzugefügt wird (vgl. die Tabelle <code>haendler</code> in | ||
[[Händler-Datenbank (SQL-Beispiel)|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, | 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. | die das Ergbnis einer Select-Anfrage ausgibt, plötzlich mehr Spalten als geplant enthalten. | ||
Darüber hinaus ist die Attribut-Reihenfolge bei <code>SELECT-* | Darüber hinaus ist die Attribut-Reihenfolge bei <code>SELECT</code>-<code>*</code>-Anfragen nicht | ||
festgelegt. Auch diese | festgelegt. Auch diese kann sich plötzlich unerwartet ändern – zum Beispiel nach einer Modifikation der [[Domäne]] eines der [[Attribut]]e, | ||
wie {{zB}} der Änderung der Anzahl der erlaubten Zeichen der Domäne des | |||
Attributs <code>h_ortschaft</code> (beispielsweise <code>VARCHAR(50)</code> → <code>VARCHAR(100)</code>). | |||
=Quellen= | ==Quellen== | ||
<references/> | <references/> | ||
<ol start="3"> | <ol start="3"> | ||
Zeile 97: | Zeile 130: | ||
</ol> | </ol> | ||
[[Kategorie:PostgreSQL-Beispiel]] | [[Kategorie:PostgreSQL-Beispiel]] | ||
[[Kategorie: | [[Kategorie:Praktikum:MMDB]] | ||
=Siehe auch= | ==Siehe auch== | ||
* [[Händler-Datenbank (SQL-Beispiel)]] | * [[Händler-Datenbank (SQL-Beispiel)]] | ||
* [[ | * [[Händler-Datenbank (SQL-Beispiel)/Projektion]] | ||
* [[Händler-Datenbank (SQL-Beispiel)/Selektion]] |
Aktuelle Version vom 10. Oktober 2019, 10:23 Uhr
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
Den nachfolgenden Beispielen liegt die Händler-Datenbank zugrunde. Alle Beispiele wurden mit PostgreSQL und SQLite getestet. In jedem Fall wird Händlertabelle auf sich selbst abgebildet:
$ \texttt{haendler} $ | → | $ \textrm{id}(\texttt{haendler}) $ | ||||||||||||||||||||||||||||||||||||
|
→ |
|
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 daher in SQL auf jeden Fall eine Identitätsfunktion.
In SQL-92 gab es noch eine dedizierte Identitäsfunktion: TABLE
[1]
TABLE haendler
Dieser Befehl wird beispielsweise von PostgreSQL unterstützt .
In SQL-99 und in den meisten SQL-Datenbank-Management-Systemen, wie beispielsweise SQLite, gibt es diese Funktion allerdings nicht mehr.[2] Als Identitätsfunktion kommt hier ersatzweise
SELECT * FROM
zum Einsatz:
SELECT * FROM haendler
Das zuvor formulierte Idempozenz-Gesetz gilt auch in SQL, wenn auch mit der 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 Kurzschreibweise *
sollte man i. Allg. nur für Ad-hoc-Anfragen
in Tools wie phpPgAdmin oder pgAdmin verwenden. In einem 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_ortschaft 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_ortschaft
(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/