Händler-Datenbank (SQL-Beispiel)/Identität: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
 
(45 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{{In Bearbeitung}}
{{Qualität
{{Qualität
|correctness        = 3
|correctness        = 4
|extent              = 4
|extent              = 4
|numberOfReferences  = 1
|numberOfReferences  = 4
|qualityOfReferences = 5
|qualityOfReferences = 5
|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 22: 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>→&nbsp;&nbsp;</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>→&nbsp;&nbsp;</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,
indem man einfach den Namen der Tabelle angibt. Folgendes ist als kein korrektes
indem man einfach den Namen der Tabelle angibt. Folgendes ist also keine korrekte
SQL:
SQL-Anfrage:
<source lang="sql">
<source lang="sql">
haendler  
haendler  
</source>
</source>


Um den Inhalt einer Tabelle auszugeben, benötigt man also eine Identitätsfunktion.
Um den Inhalt einer Tabelle auszugeben, benötigt man daher in SQL auf jeden Fall eine Identitätsfunktion.
Diese gab es noch in SQL-92:<ref>[[Date, C.; Darwen, H. (1993): A Guide to the SQL Standard]], S. 126</ref>
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 37: Zeile 66:
</source>
</source>


In SQL-99 (und in den meisten SQL-[[Datenbank-Management-System]]en) gibt es diese Funktion nicht mehr.<ref>[[Gulutzan, P.; Pelzer, T. (1999): SQL-99 complete]]</ref> Als Identitätsfunktion kommt hier
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 44: Zeile 74:
</source>
</source>


Das zuvor formulierte Idempozenz-Gesetz gilt auch in SQL, wenn auch mit der zuvor genannten Einschränkung, dass
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:  


<source lang="sql">
<source lang="sql">
SELECT * FROM (SELECT * FROM haendler) -- Fehlermeldung in PostgreSQL
SELECT * FROM (SELECT * FROM haendler)
=     
=     
SELECT * FROM haendler
SELECT * FROM haendler
=  
=  
haendler /* kein SQL*/ = TABLE haendler /* nur SQL-92 */
TABLE haendler /* SQL-92, aber nicht SQL-99 */
=  
haendler /* kein SQL*/  
</source>
</source>


==Anmerkung 1==
'''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.
[[Händler-Datenbank (SQL-Beispiel, PostgreSQL)/Unterabfrage|Unterabfragen]] stets benannt werden müssen.
In PostgreSQL muss man die erste Select-Anweisung daher folgendermaßen schreiben:
In PostgreSQL muss man die erste Select-Anweisung daher folgenrdemaßen schreiben:


<source lang="sql">
<source lang="sql">
SELECT * FROM (SELECT * FROM haendler) AS h
SELECT * FROM (SELECT * FROM haendler) AS dummy
</source>
</source>


==Anmerkung 2==
'''Anmerkung 2'''<br/>
Die Selektion <code>SELECT * FROM</code> sollte man i. Allg. nur für Ad-hoc-Anfragen  
Die Kurzschreibweise <code>*</code> sollte man i. Allg. nur für Ad-hoc-Anfragen  
in Tools wie [[phpPgAdmin]] oder [[pgAdmin III]] verwenden. In Programmcode sollte
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 78: Zeile 109:


<source lang="sql">
<source lang="sql">
SELECT hnr, name, adresse FROM haendler
SELECT h_id, h_name, h_ortschaft FROM haendler
</source>
</source>


schreiben. Der Grund ist, dass die <code>SELECT-*-</code>Anfrage ihre Bedeutung ändert,
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. Das heißt, aufgrund einer Schema-Änderung  
<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-*-</code>Anfragen nicht  
Darüber hinaus ist die Attribut-Reihenfolge bei <code>SELECT</code>-<code>*</code>-Anfragen nicht  
festgelegt. Auch diese könnte sich – zum Beispiel nach einem Upgrade der zugehörigen Datenbank
festgelegt. Auch diese kann sich plötzlich unerwartet ändern – zum Beispiel nach einer Modifikation der [[Domäne]] eines der [[Attribut]]e,
– plötzlich unerwartet ändern.
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="4">
<ol start="3">
<li>{{Quelle|Kowarschick, W.: Multimedia-Datenbanksysteme}}</li>
<li>{{Quelle|Kowarschick, W. (MMDB-Skript): Skriptum zur Vorlesung Multimedia-Datenbanksysteme}}</li>
<li>{{Quelle|Kowarschick, W. (2012): Skriptum zur Vorlesung Multimedia-Datenbanksysteme}}</li>
<li>{{Quelle|Kowarschick, W.: Multimedia-Datenbanksysteme}}, http://mmdb.hs-augsburg.de/beispiel/haendler/</li>
</ol>
</ol>
[[Kategorie:PostgreSQL-Beispiel]]
[[Kategorie:PostgreSQL-Beispiel]]
[[Kategorie:SQL-Beispiel]]
[[Kategorie:Praktikum:MMDB]]
 
==Siehe auch==
* [[Händler-Datenbank (SQL-Beispiel)]]
* [[Händler-Datenbank (SQL-Beispiel)/Projektion]]
* [[Händler-Datenbank (SQL-Beispiel)/Selektion]]

Aktuelle Version vom 10. Oktober 2019, 11: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 verändert eine Tabelle nicht

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}) $
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
3 Maier Augsburg
4 Huber NULL
5 Schmidt Hamburg
→  
h_idh_nameh_ortschaft
1 Maier Königsbrunn
2 Müller Königsbrunn
3 Maier Augsburg
4 Huber NULL
5 Schmidt Hamburg

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

  1. 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
  2. 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)
  1. Kowarschick (MMDB-Skript): Wolfgang Kowarschick; Vorlesung Multimedia-Datenbanksysteme – Sommersemester 2018; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 4 (Skript)
  2. 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/

Siehe auch