Das Prinzip der Sprache SQL geht von relationalen Datenbanken aus. Diese bestehen aus einer Sammlung von Tabellen. Die Daten der Tabellen werden erst bei der Abfrage mit SQL miteinander verbunden - diese Verbindung nennt man Join.
Eine Tabelle besteht aus Columns (Spalten), in denen die Fields (Felder) stehen und aus Rows (Zeilen), die die Records (Datensätze) darstellen.
Als Beispiel möchte ich ein Online-Shopping-System vorstellen. Die Aufträge könnten in einer Tabelle abgelegt sein:
Tabelle Auftrag| Kundennr | Kundenname | Auftragsnr | Auftragsdatum | Anzahl | Artikelnr | Artikelname | Artikelpreis |
|---|---|---|---|---|---|---|---|
| 10001 | Feuerstein,Fred | 12345 | 9.4.2001 | 1 | 246 | Bowlingkugel | 50.00 |
| 10001 | Feuerstein,Fred | 12345 | 9.4.2001 | 2 | 123 | Gluck-Gluck | 69.50 |
| 10002 | Geröllheimer, Barney | 12346 | 16.4.2001 | 2 | 246 | Bowlingkugel | 50.00 |
| 10001 | Feuerstein,Fred | 12347 | 10.5.2001 | 5 | 369 | Dino-Halsband | 12.80 |
Hier hat Fred Feuerstein am 9.4. zwei Gluck-Glucks und eine neue Bowlingkugel gekauft. Da man nicht nachstehen kann, hat Barney Geröllheimer eine Woche später natürlich auch eine neue Bowlingkugel gekauft. Am 10.5. hat Fred dann noch einen Vorrat Halsbänder für Dino bestellt.
Dabei fällt auf, dass hier viele Daten mehrfach abgelegt werden. So steht in jedem Datensatz wieder der Name und in einer realen Datenbank käme auch noch die Adresse dazu. Wenn also sich die Bezeichnung eines Artikels ändert,muss man alle Datensätze ändern, in denen sie steht. Deshalb gibt es die erste, zweite und dritte Normalform, die solche "redundanten" (mehrfach vorhandene) Daten vermeidet. Ich will hier nicht weiter in die Theorie gehen, sondern die gleichen Daten hier einfach sinnvoll auf mehrere Tabellen verteilen.
Tabelle Kunde| Kundennr | Kundenname |
|---|---|
| 10001 | Feuerstein,Fred |
| 10002 | Geröllheimer, Barney |
| Artikelnr | Artikelname | Artikelpreis |
|---|---|---|
| 123 | Gluck-Gluck | 69.50 |
| 246 | Bowlingkugel | 50.00 |
| 369 | Dino-Halsband | 12.80 |
| Kundennr | Auftragsnr | Auftragsdatum | Anzahl | Artikelnr |
|---|---|---|---|---|
| 10001 | 12345 | 9.4.2001 | 1 | 246 |
| 10001 | 12345 | 9.4.2001 | 2 | 123 |
| 10002 | 12347 | 16.4.2001 | 2 | 123 |
| 10003 | 12346 | 10.5.2001 | 5 | 369 |
Ich habe in diesem Beispiel absichtlich nicht vollständig die Redundanz beseitigt. So wird hier anstatt eine weitere Tabelle zu erzeugen zu jedem Teil des Auftrags wieder das Auftragsdatum gespeichert - das widerspricht der reinen Lehre der Normalformen. Aber die Bildung von Joins kostet natürlich Zeit und deshalb weicht man oft bewusst von den Normalformen ab.
In der Tabelle Kunde haben wir einen eindeutigen Key (Schlüssel), "Kundennr", der einen Record identifiziert. Diesen nennt man auch Primary Key (Primärschlüssel). In der Tabelle Artikel haben wir die Artikelnummer. Die Tabelle Auftrag hat dies nicht, denn für jeden Auftrags kann es mehrere Posten geben. Die Tabelle Auftrag enthält auch die "Kundennr" und die "Artikelnr".
Über diese Relations (Relationen) zwischen den Tabellen kann man zu einem Auftrag den Kundennamen und die Artikelbezeichnung und Artikelpreis bekommen. Aber durch die Datenbank ist dieser Weg nicht vorgegeben. Wir können auch zu jedem Artikel eine Liste bekommen, welche Kunden ihn bestellt haben und in welcher Menge insgesamt.
Hauptseite 2 Welche Datentypen gibt es?
© 2001 Mario Boller-Olfert - 123-Byte - Marios Welt - EMail: Kontaktformular