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

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
 
(5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
[[en:Category:Software Engineering]]
{{Qualität
|correctness        = 4
|extent              = 4
|numberOfReferences  = 4
|qualityOfReferences = 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 ==
[[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:
 
<div class="formula">
<math>id: R \rightarrow R</math><br />
<math>id(r) = r</math>
</div>
 
Diese Funtion ist ''idempotent'':
 
<div class="formula">
<math>id(id(r)) = id(r) = r</math>
</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,
indem man einfach den Namen der Tabelle angibt. Folgendes ist also keine korrekte
SQL-Anfrage:
<source lang="sql">
haendler
</source>
 
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">
TABLE haendler
</source>
 
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:
 
<source lang="sql">
SELECT * FROM haendler
</source>
 
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:
 
<source lang="sql">
SELECT * FROM (SELECT * FROM haendler)
=   
SELECT * FROM haendler
=
TABLE haendler /* SQL-92, aber nicht SQL-99 */
=
haendler /* kein SQL*/
</source>
 
'''Anmerkung 1'''<br/>
In PostgreSQL läuft – im Gegensatz zu SQLite – die erste der drei obigen Anfrage auf einen Fehler, da hier
[[Unterabfrage]]n stets benannt werden müssen.
In PostgreSQL muss man die erste Select-Anweisung daher folgendermaßen schreiben:
 
<source lang="sql">
SELECT * FROM (SELECT * FROM haendler) AS dummy
</source>
 
'''Anmerkung 2'''<br/>
Die Kurzschreibweise <code>*</code> 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
 
<source lang="sql">
SELECT * FROM haendler
</source>
 
sollte man
 
<source lang="sql">
SELECT h_id, h_name, h_ortschaft FROM haendler
</source>
 
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
<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,
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>-<code>*</code>-Anfragen nicht
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==
<references/>
<ol start="3">
<li>{{Quelle|Kowarschick, W. (MMDB-Skript): Skriptum zur Vorlesung Multimedia-Datenbanksysteme}}</li>
<li>{{Quelle|Kowarschick, W.: Multimedia-Datenbanksysteme}}, http://mmdb.hs-augsburg.de/beispiel/haendler/</li>
</ol>
[[Kategorie:PostgreSQL-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