Relationale Datenbanken
Um mit SQL auf relationalen Datenbanken arbeiten zu können, muss der Anwender ein Grundverständnis für relationale Datenbanken haben. Dieses soll in diesem Kapitel vermittelt werden.
Grundstruktur von relationalen Datenbanken
[Bearbeiten]Bevor man mit der Sprache SQL beginnt, muss das Grundprinzip von relationalen Datenbanken geklärt werden. Relationale Datenbanken versuchen einen Bestandteil der Realität in einem Datenmodell abzubilden.
Für diese Datenmodelle gibt es verschiedene Abstraktionsebenen. In der Regel unterscheidet man zwischen Entitätenmodell und Tabellenmodell. Da es sich hier um eine Einführung handelt, beschränken wir uns auf das Tabellenmodell, das weniger Theorie voraussetzt.
Grundsätzlich sollen dabei Objekte der Realität betrachtet werden, welche zueinander in Beziehung stehen. Zum einen werden die Objekte mit ihren Eigenschaften untersucht: Objekte mit gleichen Eigenschaften werden zusammengefasst; Objekte mit verschiedenen Eigenschaften werden getrennt. Zum anderen werden die Beziehungen zwischen unterschiedlichen Objekten behandelt. Außerdem geht es darum, möglichst keine Informationen unnötigerweise doppelt zu speichern.
Beispielhafte Struktur
[Bearbeiten]In unserer Beispieldatenbank simulieren wir dazu eine Versicherungsgesellschaft. Unter anderem werden die Verträge mit den dazugehörigen Kunden betrachtet:
- Ein Versicherungsvertrag ist durch die Vertragsnummer, das Datum des Abschlusses, den Versicherungsnehmer, die Art und die Höhe der Police gekennzeichnet.
- Ein Versicherungsnehmer kann bei der Versicherung einen oder mehrere Verträge haben. Es kann Kunden geben, die aktuell keinen Vertrag haben; aber es kann keinen Vertrag ohne zugehörigen Kunden geben.
- Ein Versicherungsnehmer ist gekennzeichnet durch seinen Namen und Anschrift und bei Personen einen Vornamen und ein Geburtsdatum. Außerdem verfügt er „üblicherweise“ über eine Kundennummer, die ihn eindeutig kennzeichnet.
Nun könnte man alle Verträge wie folgt in einer einzigen Datei, z. B. einem Arbeitsblatt einer Tabellenkalkulation, speichern:
NUMMER ABSCHLUSSDATUM ART NAME ANSCHRIFT BETREUER TELEFON DG-01 03.05.1974 TK Heckel Obsthandel GmbH 46282 Dorsten Pohl, Helmut 0201/4014186 Mobil (0171) 4123456 DG-02 11.06.1975 TK Heckel Obsthandel GmbH 46282 Dorsten Pohl, Helmut 0201/4014186 Mobil (0171) 4123456 DG-03 25.02.1977 TK Heckel Obsthandel GmbH 46282 Dorsten Pohl, Helmut 0201/4014186 Mobil (0171) 4123456 XC-01 07.08.1974 HP Antonius, Bernhard 45892 Gelsenkirchen Braun, Christian 0201/4014726 Mobil (0170) 8351647 RH-01 11.12.1976 VK Cornelsen, Dorothea 44577 Castrop-Rauxel Braun, Christian 0201/4014726 Mobil (0170) 8351647
Dadurch wird die Darstellung viel zu breit und damit unübersichtlich. Offensichtlich werden auch die persönlichen Daten eines Versicherungsnehmers und seines Betreuers „zu oft“ gespeichert. Es ist also sinnvoll, dies zu trennen – zum einen die Verträge:
NUMMER ABSCHLUSSDATUM ART KUNDE BETREUER DG-01 03.05.1974 TK 1 9 DG-02 11.06.1975 TK 1 9 DG-03 25.02.1977 TK 1 9 XC-01 07.08.1974 HP 2 10 RH-01 11.12.1976 VK 3 10
Zum anderen die Kunden:
NUMMER NAME ANSCHRIFT
1 Heckel Obsthandel GmbH 46282 Dorsten
2 Antonius, Bernhard 45892 Gelsenkirchen
3 Cornelsen, Dorothea 44577 Castrop-Rauxel
Und schließlich die zuständigen Sachbearbeiter (Betreuer):
NUMMER NAME TELEFON MOBIL
9 Pohl, Helmut 0201/4014186 (0171) 4123456
10 Braun, Christian 0201/4014726 (0170) 8351647
Durch die Angabe der Nummer (Kunde bzw. Betreuer) in den Aufstellungen ist eine klare Verbindung hergestellt. Außerdem zeigt die Wiederholung des Wortes „Mobil“ an, dass dieser Wert in einer eigenen Spalte eingetragen werden sollte.
Diese Trennung von Informationen sind Schritte bei der Normalisierung einer Datenbank.
Eigenschaften der Objekte
[Bearbeiten]Vor allem müssen wir uns Gedanken über die Eigenschaften der verschiedene Objekte machen. Dabei gibt es solche, die ein Objekt eindeutig kennzeichnen, andere, die immer anzugeben sind, und weitere, die nur unter manchen Umständen von Bedeutung sind.
Für einen Versicherungsnehmer gibt es u. a. folgende Eigenschaften:
- NUMMER ist eindeutig und eine Pflichtangabe.
- NAME, PLZ, ORT sind Pflichtangaben, ihre Inhalte können aber bei mehreren Versicherungsnehmern vorkommen.
- VORNAME und GEBURTSDATUM sind bei natürlichen Personen Pflicht, aber bei juristischen Personen (Firmen) irrelevant.
Für einen Versicherungsvertrag gibt es u. a. folgende Eigenschaften:
- NUMMER ist eindeutig und eine Pflichtangabe.
- Auch die anderen bisher genannten Eigenschaften sind Pflicht, aber sie sind nicht eindeutig.
Die verschiedenen Objekte stehen über die Kundennummer miteinander in Beziehung. Im Beispiel geht es um die Verknüpfung: „Ein Kunde kann einen oder mehrere Verträge oder auch keinen haben.“ Der letzte Fall „keinen Vertrag“ kommt erst am Schluss des Buches vor, wenn wir weitere Testdaten erzeugen.
In den relationalen Datenbanksystemen (DBMS) werden die Objekte als Tabellen dargestellt. Die Eigenschaften werden über die Spalten der Tabelle abgebildet. Eine Zeile (wahlweise als Datensatz bezeichnet) in der Tabelle entspricht genau einem Objekt in der Realität. Die Beziehungen zwischen Tabellen werden über Fremdschlüssel abgebildet.
Tabellen
[Bearbeiten]Tabellen sind zweidimensional gegliederte Informationen. Anzahl, Bezeichnung und Typ der Spalten (auch Felder oder Attribute genannt) werden durch die Definition der Tabelle festgelegt. Die Zeilen (Anzahl und Inhalte) sind variabel und entsprechen jeweils einem wirklichen Objekt des Typs, der in der Tabelle gesammelt wird.
So sieht ein Ausschnitt aus der Tabelle Abteilung der Beispieldatenbank aus:
Spaltenname ID KURZBEZEICHNUNG BEZEICHNUNG ORT
Datentyp integer varchar(10) varchar(30) varchar(30)
Zeilen 1 Fibu Finanzbuchhaltung Dortmund
2 Albu Anlagenbuchhaltung Dortmund
5 Vert Vertrieb Essen
6 Lagh Lagerhaltung Bochum
Diese Tabelle enthält also 4 Spalten und 12 Zeilen, von denen hier 4 angezeigt werden.
Dabei handelt es sich um eine Basistabelle (TABLE), die tatsächlich Informationen speichert. Daneben gibt es „virtuelle“ Arten von Tabellen, nämlich die VIEW als Sichttabelle und die Ergebnismenge (Resultset) als Ergebnis einer SELECT-Abfrage.
Eine View enthält eine fest vordefinierte Abfrage, die sich auf eine oder mehrere Tabellen bezieht. Aus Sicht des Anwenders sieht sie wie eine Basistabelle aus, ist aber nur eine Abbildung realer Tabellen. Ein Beispiel wäre ein Ausschnitt aus einer View Mitarbeiter_Bochum, nämlich der Mitarbeiter, die zu einer der Abteilungen in Bochum gehören:
PERSNR NAME VORNAME BEZEICHNUNG 60001 Aagenau Karolin Lagerhaltung 60002 Pinkart Petra Lagerhaltung 70001 Olschewski Pjotr Produktion 70002 Nordmann Jörg Produktion 120001 Carlsen Zacharias Forschung und Entwicklung 120002 Baber Yvonne Forschung und Entwicklung
Näheres zu Sichttabellen steht im Kapitel Erstellen von Views.
Jede Ergebnismenge hat zwangsläufig die Struktur einer Tabelle.
Ergänzend sei darauf hingewiesen, dass auch das DBMS selbst sämtliche Schemata in Systemtabellen speichert. Beispielsweise stehen bei Interbase und Firebird die Definition von TABLEs und VIEWs in der Tabelle RDB$RELATIONS und die dazugehörigen Felder (Spalten) in RDB$RELATION_FIELDS.
Spalten
[Bearbeiten]Spalten bezeichnen die Elemente einer Tabellenstruktur. Sie werden eindeutig gekennzeichnet durch ihren Namen; diese Eindeutigkeit gilt innerhalb einer Tabelle, verschiedene Tabellen dürfen Spalten mit gleichem Namen (z. B. ID) haben. Außerdem gehört zur Definition einer Spalte der Datentyp; dies wird im Kapitel Datentypen behandelt.
Die Spalten (innerhalb einer Tabelle) werden intern nach Position geordnet. Spalten an verschiedenen Positionen können denselben Datentyp haben, aber niemals denselben Namen. Auf eine bestimmte Spalte wird fast immer über den Namen zugegriffen, nur äußerst selten über die Position.
Eine Spalte hat also einen Namen und einen Datentyp. Jede Zeile in einer Tabelle hat genau einen Wert für jede Spalte; wenn mehrere gleichartige Werte eingetragen werden sollen, werden mehrere Spalten benötigt. Jeder Wert in einer Zeile entspricht dem Datentyp der Spalte.
- Hinweis: In dieser Hinsicht unterscheiden sich Datenbank-Tabellen ganz wesentlich von denjenigen einer Tabellenkalkulation, bei der der Datentyp einzelner Zellen abweichen kann von der Spaltendefinition und einzelne Zellen zusammengezogen werden können.
Die Eigenschaft NULL für einen Wert ist eine Besonderheit, die vor allem Einsteiger gerne verwirrt. Dies bedeutet, dass einer Zelle (noch) kein Wert zugeordnet worden ist. Eine bessere Bezeichnung wäre etwas wie UNKNOWN; aber es heißt nun leider NULL. Bitte beachten Sie deshalb:
- Für ein Textfeld werden folgende Werte unterschieden:
- Der Wert ’’ ist ein leerer Text.
- Der Wert ’ ’ ist ein Text, der genau ein Leerzeichen enthält.
- Der Wert NULL enthält nichts.
- Für ein logisches Feld (Datentyp boolean) wird dies unterschieden:
- Der Wert TRUE bedeutet „wahr“.
- Der Wert FALSE bedeutet „falsch“.
- Der Wert NULL bedeutet „unbekannt“.
- Für ein Zahlenfeld wird dies unterschieden:
- Der Wert 0 ist eine bestimmte Zahl, genauso gut wie jede andere.
- Der Wert NULL bedeutet „unbekannt“.
|
|
Merke Der Wert NULL steht nicht für einen bestimmten Wert, sondern kann immer als „unbekannt“ interpretiert werden. |
|---|
Dies kann bei jeder Spalte allgemein festgelegt werden: Die Eigenschaft „NOT NULL“ bestimmt, dass in dieser Spalte der NULL-Wert nicht zulässig ist; wenn Daten gespeichert werden, muss immer ein Wert eingetragen werden (und sei es ein leerer Text). Wenn dies nicht festgelegt wurde, muss kein Wert eingetragen werden; der Feldinhalt ist dann NULL.
Bei SELECT-Abfragen (vor allem auch bei Verknüpfungen mehrerer Tabellen) gibt es unterschiedliche Ergebnisse je nachdem, ob NULL-Werte vorhanden sind und ob sie berücksichtigt oder ausgeschlossen werden sollen.
Verknüpfungen und Schlüssel
[Bearbeiten]Mit diesen Verfahren werden die Tabellen in Beziehung zueinander gebracht. Auch dies folgt der Vorstellung, dass die Wirklichkeit abgebildet werden soll.
Verknüpfungen
[Bearbeiten]Diese, nämlich die Beziehungen zwischen den Tabellen, sind ein Kern eines relationalen Datenbanksystems. In der Beispieldatenbank bestehen unter anderem folgende Beziehungen:
- Die Tabelle Mitarbeiter verweist auf folgende Tabelle:
- Jeder Mitarbeiter gehört zu einem Eintrag der Tabelle Abteilung.
- Die Tabelle Zuordnung_SF_FZ verbindet Schadensfälle und Fahrzeuge und verweist auf folgende Tabellen:
- Jedes beteiligte Fahrzeug gehört zu einem Eintrag der Tabelle Fahrzeug.
- Jeder Schadensfall muss in der Tabelle Schadensfall registriert sein.
- Die Tabelle Versicherungsvertrag verweist auf folgende Tabellen:
- Jeder Vertrag wird von einer Person aus der Tabelle Mitarbeiter bearbeitet.
- Zu jedem Vertrag gehört ein Eintrag der Tabelle Fahrzeug.
- Zu jedem Vertrag gehört ein Eintrag der Tabelle Versicherungsnehmer.
Durch diese Verknüpfungen werden mehrere Vorteile erreicht:
- Informationen werden nur einmal gespeichert.
Beispiel: Der Name und Sitz einer Abteilung muss nicht bei jedem Mitarbeiter notiert werden. - Änderungen werden nur einmal vorgenommen.
Beispiel: Wenn die Abteilung umzieht, muss nur der Eintrag in der Tabelle Abteilung geändert werden und nicht die einzelnen Angaben bei jedem Mitarbeiter. - Der Zusammenhang der Daten wird gewährleistet.
Beispiel: Ein Versicherungsnehmer kann nicht gelöscht werden, solange er noch mit einem Vertrag registriert ist.
Damit dies verwirklicht werden kann, werden geeignete Maßnahmen benötigt:
- Jeder Datensatz muss durch einen Schlüssel eindeutig identifiziert werden können.
- Die Schlüssel der verschiedenen miteinander verknüpften Datensätze müssen sich zuordnen lassen.
Schlüssel
[Bearbeiten]PrimaryKey (PK): Der Primärschlüssel ist eine Spalte in der Tabelle, durch die eindeutig jede Zeile identifiziert wird (gerne mit dem Namen ID). Es kann auch eine Kombination von Spalten als eindeutig festgelegt werden; das ist aber selten sinnvoll. In der Regel sollte diese Spalte auch keine andere „inhaltliche“ Bedeutung haben als die ID.
- Beispiele: Die Kombination Name/Vorname kann bei kleinen Datenmengen zwar praktisch eindeutig sein, aber niemals theoretisch; irgendwann kommt ein zweiter „Hans Müller“, und dann? Bei einem Mehrbenutzersystem werden häufig mehrere Einträge „gleichzeitig“ gespeichert; es ist besser, wenn das DBMS die Vergabe der ID selbst steuert, als dass die Benutzer sich absprechen müssen. In der Beispieldatenbank wird deshalb in der Tabelle Mitarbeiter zwischen der automatisch vergebenen ID und der ebenfalls eindeutigen Personalnummer unterschieden.
ForeignKey (FK): Über Fremdschlüssel werden die Tabellen miteinander verknüpft. Einem Feld in der einen Tabelle wird ein Datensatz in einer anderen Tabelle zugeordnet; dieser wird über den Primärschlüssel bereitgestellt. Es kann auch eine Kombination von Spalten verwendet werden; da sich der Fremdschlüssel aber auf einen Primärschlüssel der anderen Tabelle beziehen muss, ist dies ebenso selten sinnvoll. Die „Datenbank-Theorie“ geht sogar soweit, dass die Schlüsselfelder dem Anwender gar nicht bekannt sein müssen.
- Beispiele stehen in der obigen Aufstellung. Nähere Erläuterungen sind im Kapitel Fremdschlüssel-Beziehungen zu finden.
Index: Ein Suchbegriff dient zum schnellen Zugriff auf Datensätze innerhalb einer Tabelle. Die Mehrzahl lautet nach Duden ‚Indizes‘, auch ‚Indexe‘ ist möglich; in der EDV wird oft auch der englische Plural 'Indexes' verwendet. Dies gehört zwar nicht zum „Kernbereich“ eines relationalen DBMS, passt aber (auch wegen der umgangssprachlichen Bedeutung des Wortes „Schlüssel“) durchaus hierher.
- Der Primärschlüssel ist ein Suchbegriff, mit dem eindeutig ein Datensatz gefunden werden kann.
- Mit einem Index kann die Suche nach einem bestimmten Datensatz oder einer Datenmenge beschleunigt werden.
Beispiel: die Suche nach PLZ - Die Werte einer Spalte oder einer Kombination von Spalten sollen eindeutig sein.
Beispiel: die Personalnummer
Nähere Erläuterungen sind in den Kapiteln im Teil Erweiterungen ab DDL – Einzelheiten zu finden.
Siehe auch
[Bearbeiten]Über Wikipedia sind weitere Informationen zu finden:
- Relationale Datenbank
- Entitätenmodell und Entity-Relationship-Modell
- Normalisierung
- Tabellenkalkulation im Gegensatz zu Datenbank-Tabellen
- Nullwert