Einführung in SQL: Druckversion: Einführung

Einführung in SQL

Datenbanken bearbeiten

Jürgen Thomas

Wikibooks

Dieses Buch richtet sich an:	Schüler, Studenten und Andere, die sich mit relationalen Datenbanken beschäftigen wollen bzw. müssen
Was dieses Buch erreichen will:	Einführung in SQL anhand einer Beispieldatenbank. Der Leser soll die Beispiele anhand von Übungen auf seinem eigenen Datenbankmanagementsystem nachvollziehen können. Die Schwerpunkte liegen hierbei auf folgenden Themen: Abfragen von Daten Manipulieren von Daten Einfaches Ändern der Datenbankstruktur
Was dieses Buch nicht sein soll:	Keine Einführung in die Grundkonzepte relationaler Datenbankmodelle. Keine Einführung in die Modellierung von relationalen Datenbanken. Keine Einführung in die Administration von Datenbankmanagementsystemen. Keine Einführung in das Performance-Tuning von relationalen Datenbanken. Keine Einführung in prozedurale (z.B. PL/SQL) oder objektorientierte Sprachen, die innerhalb der Datenbank gespeichert und genutzt werden können.

Inhaltsverzeichnis

Wegen des Umfangs und der Komplexität der einzelnen Kapitel besteht die Druckversion aus mehreren Teilen.

Einführung

Dieser Teil informiert über dieses Buch und allgemein über Datenbanken sowie SQL.

• Ein Einstieg zeigt, wozu SQL gut ist.
• Einleitung enthält Inhalt und Ziele dieses Buches.
• Relationale Datenbanken sind die Objekte, mit denen in SQL gearbeitet wird.
• Normalisierung bespricht Regeln, die bei der Erstellung einer Datenbank zu beachten sind.
• Mit der Beispieldatenbank werden die meisten Aufgaben und Befehle in diesem Buch erläutert.

Die anderen Teile

Über das Inhaltsverzeichnis des Buches sind die anderen Teile der Druckversion zu erreichen:

• Grundlagen
• Mehr zu Abfragen
• Erweiterungen
• Anhang

Sonstiges

• Lizenz

Ein Einstieg

Nehmen wir einmal an, dass ein Versicherungsunternehmen einen neuen Geschäftsführer bekommt. Dieser sammelt zunächst Informationen, um sich mit dem Unternehmen vertraut zu machen.

Datenbanken enthalten Informationen

Der Geschäftsführer findet in seinem Büro keine Akten, sondern nur einen PC. Nach dem Einschalten und Anmelden bekommt er folgende Begrüßung:

Wikibooks-Beispieldatenbank
(C) Wiki-SQL
Bitte geben Sie einen SQL-Befehl ein:
sql >

Damit wird der Geschäftsführer auf mehrere Punkte der Organisation in seinem Unternehmen hingewiesen.

• Die Daten sind in einer Datenbank zusammengefasst mit dem Namen Beispieldatenbank.
• Diese Datenbank (DB) stammt von der Firma Wikibooks.
• Um etwas mit dieser DB zu machen, soll er hinter "sql >" einen SQL-Befehl eingeben.

Die Inhalte dieser Datenbank sind in Beispieldatenbank beschrieben, Einzelheiten in Tabellenstruktur der Beispieldatenbank erläutert.

Das Datenbanksystem (DBMS) der Firma Wikibooks wird als Wiki-SQL bezeichnet. Dies bedeutet, dass die Beispieldatenbank zu Wiki-SQL passen muss – in Bezug auf das Dateiformat, die interne Struktur und den Aufbau der Befehle.

SQL ist die Abkürzung für Structured Query Language, also strukturierte Abfragesprache. Der Geschäftsführer hat schon einmal davon gehört, dass dies eine standardisierte Form ist, um mit Datenbanken zu arbeiten, und probiert es aus.

Abfrage nach den Mitarbeitern

Als erstes möchte er eine Liste seiner Mitarbeiter haben. Er überlegt, wie die Abfrage lauten könnte:

Hole Name und Vorname von den Mitarbeitern

Da die Abfrage lediglich eine Fehlermeldung erzeugt, probiert er, seine Abfrage in unterschiedlicher Form auf Englisch durchzuführen (leider auch ohne Erfolg); diese könnten etwa so aussehen:

Get Name, Vorname From Mitarbeiter
Fetch Name, Vorname From Mitarbeiter
Find Name, Vorname From Mitarbeiter
Search Name, Vorname From Mitarbeiter

Und schließlich bekommt er mit der folgenden Eingabe keine Fehlermeldung, sondern ein Ergebnis:

Select Name, Vorname From Mitarbeiter

Die Liste ist ihm zu lang und unübersichtlich. Er will sie zunächst einmal sortieren und probiert Sortierung, Reihenfolge aus, bis es passt:

Select Name, Vorname From Mitarbeiter order by Name

Dann möchte er die Auswahl einschränken, nämlich auf die Mitarbeiter mit Anfangsbuchstaben 'A'. Wieder nach ein paar Versuchen weiß er, dass nicht WITH, sondern WHERE die Lösung liefert.

Select Name, Vorname From Mitarbeiter where Name < 'B'

Jetzt möchte er beide Abfragen verbinden:

 Gleichzeitig Sortierung und Einschränkung

Select Name, Vorname From Mitarbeiter order by Name where Name < 'B'

Ausgabe

SQL error code = -104. Token unknown - line 1, column 53. WHERE.

Das kann doch nicht sein?! WHERE ist doch das richtige Verfahren für eine solche Einschränkung?! Kommt es etwa auf die Reihenfolge der Zusätze an?

 Zuerst Einschränkung, dann Sortierung

Select Name, Vorname From Mitarbeiter where Name < 'B' order by Name

Ausgabe

NAME     VORNAME
Aagenau  Karolin
Aliman   Zafer

Welche Informationen sind denn sonst gespeichert? Er weiß auch (z. B. vom DIR-Befehl des Betriebssystems), dass ein Sternchen anstelle von alles gesetzt werden kann. Und siehe da, es klappt:

Select * From Mitarbeiter where Name < 'B' order by Name

Ausgabe

ID  PERSONALNUMMER  NAME      VORNAME  GEBURTSDATUM  TELEFON         (und noch mehr)
13      60001       Aagenau   Karolin  02.01.1950    0234/66006001    usw.
18      80002       Aliman    Zafer    12.11.1965    0201/4012161     usw.

Prima, damit ist klar, wie Informationen aus der Datenbank geholt werden:

SELECT <Liste von Teilinformationen>
  FROM <Teil der Datenbank>
 WHERE <Bedingung>
 ORDER BY <Sortierung>

Neuaufnahme bei den Mitarbeitern

Als nächstes möchte der Geschäftsführer sich selbst als Mitarbeiter speichern. Schnell kommt er auf das „Grundgerüst“ des Befehls:

INSERT INTO Mitarbeiter VALUES

Wenn er danach seinen Namen schreibt, bekommt er wieder eine Fehlermeldung mit "token unknown". Er hat aber schon von der Benutzung von Klammern in der EDV gehört.

 Fehler

Insert into Mitarbeiter VALUES ('Webern', 'Anton')

Ausgabe

SQL error code = -804.<br />
 Count of read-write columns does not equal count of values.

Na gut, dann wird eben ausdrücklich angegeben, dass erstmal nur Name und Vorname einzutragen sind.

 Fehler

Insert into Mitarbeiter (Name, Vorname) VALUES ('Webern', 'Anton')

Ausgabe

validation error for column PERSONALNUMMER, value "*** null ***".

Ach so, die Personalnummer muss angegeben werden, und vermutlich alles andere auch. Aber die ID ist doch gar nicht bekannt? Nun, immerhin sind wir auf diese Grundstruktur des Befehls gekommen:

INSERT INTO <Teil der Datenbank>
       [ ( <Liste von Teilinformationen> ) ]
  VALUES ( <Liste von Werten> )

SQL und natürliche Sprache

Offensichtlich sind die Befehle von SQL der natürlichen englischen Sprache nachempfunden. (Die englische Sprache hat wegen der klaren Satzstruktur und Grammatik insofern natürlich Vorteile gegenüber der komplizierten deutschen Syntax.)

SELECT für Abfragen

Um Daten abzufragen, gibt es den SELECT-Befehl mit folgenden Details:

SELECT                                        wähle aus
  [ DISTINCT | ALL ]                          verschiedene | alle
    <Liste von Teilinformationen>
    FROM <Teil der Datenbank>                 aus
  [ WHERE <Bedingungen> ]                     wobei
  [ GROUP BY <Liste von Spalten> ]            gruppiert durch
  [ HAVING <Bedingungen> ]                    wobei
  [ ORDER BY <Sortierung> ]                   sortiert durch

INSERT für Neuaufnahmen

Um Daten neu zu speichern, gibt es den INSERT-Befehl mit folgenden Details:

INSERT INTO <Teil der Datenbank>              einfügen in
  [ <Liste von Teilinformationen> ] 
     VALUES ( <Liste von Werten> )            Werte
/* oder */
INSERT INTO <Teil der Datenbank>              einfügen in
  [ <Liste von Teilinformationen> ] 
     SELECT <Ergebnis einer Abfrage>          durch eine Auswahl 

UPDATE für Änderungen

Um Daten zu ändern, gibt es den UPDATE-Befehl mit folgenden Details:

UPDATE <Teil der Datenbank>                   aktualisiere
   SET <spalte1> = <wert1> [ ,                setze fest
       <spalte2> = <wert2>   , usw. 
       <spalten> = <wertn> ]
  [ WHERE <bedingungsliste>  ];               wobei

DELETE für Löschungen

Um Daten zu löschen, gibt es den DELETE-Befehl mit folgenden Details:

DELETE FROM <Teil der Datenbank>              lösche aus
    [ WHERE <bedingungsliste>  ];             wobei

CREATE TABLE bei der Struktur einer Tabelle

Um eine neue Tabelle zu erstellen, gibt es den CREATE TABLE-Befehl mit folgenden Einzelheiten:

CREATE TABLE <Teil der Datenbank>             erzeuge Tabelle
    ( <Spaltenliste>,
      <weitere Angaben> )

So einfach kann es gehen? Dann kann man doch auch eigene Daten erzeugen, speichern, abfragen und auswerten.

Zusammenfassung

Die einzelnen Teile der SQL-Befehle sind leicht verständlich; und es scheint nur wenige Befehle zu geben, die man als „Anfänger“ wirklich lernen muss. Natürlich kann man nicht sofort alle Möglichkeiten erfassen. Aber angesichts des begrenzten Umfangs und der klaren Struktur lohnt es sich, sich näher damit zu befassen. Dies will dieses Buch erleichtern.

Siehe auch

Wikipedia hat einen Artikel zum Thema SQL.

Weitere Informationen gibt es in folgenden Kapiteln:

• Beispieldatenbank
• Tabellenstruktur der Beispieldatenbank

---

Einleitung

In diesem Kapitel erhalten Sie Informationen über Inhalt und Aufbau des Buches.

Einführung

Die Abfragesprache SQL ist die etablierte Sprache für die Arbeit mit relationalen Datenbankmanagementsystemen (DBMS). Es existieren verschiedene Standards, und jeder Hersteller von DBMS hat seine eigenen Erweiterungen und Besonderheiten zu den Standards.

Das Buch soll eine Einführung in die Sprache SQL bieten. Ziel ist es, dass der Leser nach dem Durcharbeiten folgende Aufgaben selbständig lösen kann:

• Eigene Abfragen für relationale Datenbanken erstellen
• Manipulieren von Daten (Einfügen, Ändern und Löschen)
• Eigene einfache relationale Datenbanken aufbauen
• Bestehende Datenbankstrukturen erweitern

Um die Ziele zu erreichen, wird SQL anhand praxisnaher Beispiele erläutert.

Die Beispiele im Buch wurden unter mindestens einem der folgenden DBMS getestet:

• Firebird
• MS-SQL Server 2005 oder 2008
• MySQL 4.1 oder 5
• Oracle 9, 10 oder 11

Vorzugsweise werden allgemeingültige Schreibweisen nach dem SQL-Standard (siehe unten) benutzt. Deshalb sollten die Befehle in aller Regel auf allen gängigen DBMS funktionieren und höchstens kleinere Änderungen benötigen. Dort, wo eine spezielle Schreibweise wesentlich abweicht, wird das ausdrücklich erwähnt.

	Achtung: Wegen der vielen unterschiedlichen Schreibweisen der SQL-Befehle ist eine vollständige Prüfung leider nicht möglich. Sie müssen in allen Zweifelsfällen in der Dokumentation Ihres DBMS die passende Schreibweise nachlesen.

Geschichte von SQL

SQL ist aus IBM's SEQUEL in den siebziger Jahren entstanden. Der Erfolg der Sprache SQL ist sicherlich auch darin begründet, dass die Sprache einfach aufgebaut ist und sich an der englischen Umgangssprache orientiert. Von SQL gibt es verschiedene Standards. Diese sind:

• Erster SQL-Standard (1986 ANSI)
• SQL2 bzw. SQL-92 (1992)
• SQL3 bzw. SQL:1999 (1999 ISO)
• SQL:2003 (2003)
• SQL:2008 (2008)

Hierbei ist zu beachten, dass die meisten Datenbankmanagementsysteme SQL2 unterstützen. Die neueren Versionen sind in der Regel nur teilweise oder gar nicht in den einzelnen Datenbankmanagementsystemen umgesetzt.

Alles, was in diesem Buch als SQL-Standard, also als „offizielle SQL-Feststellung“ angegeben wird, bezieht sich auf die SQL-Dokumente von 2003 .

Übersicht über Datenbankmanagementsysteme

Allgemein

Datenbanken sind Systeme (Daten und Programme) zur Verwaltung von Daten. Es gibt verschiedene Konzepte:

• Relationale DBMS
• Objektrelationale DBMS
• Objektorientierte DBMS

Bei Wikipedia gibt es eine Liste der Datenbankmanagementsysteme.

Da SQL die Abfragesprache für relationale Datenbanken ist, bezieht sich das Buch nur auf diese Art von Datenbanken. Das Konzept hinter den relationalen Datenbanken wird im nächsten Kapitel erläutert.

Kommerzielle Datenbankmanagementsysteme

• DB2
• Informix
• Interbase
• Microsoft SQL Server
• Oracle
• Sybase

Microsoft und Oracle bieten auch kostenlose Express-Versionen mit eingeschränkten Möglichkeiten oder Nutzungsrechten an.

Freie Datenbankmanagementsysteme

• Firebird
• MariaDB
• MySQL
• PostgreSQL
• SQLite

Bei MySQL ist das duale Lizenzsystem zu beachten: je nach Nutzungsbedingungen frei oder kostenpflichtig.

MariaDB ist 2009 als Abspaltung von MySQL entstanden. Seit MySQL 2010 von Oracle übernommen wurde, wurde in vielen Systemen MySQL durch MariaDB ersetzt. Soweit dieses Buch MySQL erwähnt, können Beispiele und Erläuterungen genauso gut auf MariaDB bezogen werden.

Die Unterscheidung zwischen „frei“ und „kommerziell“ ist nicht korrekt, sondern wird nur der Einfachheit halber gemacht. Bei den „freien“ DBMS steht die freie Verfügbarkeit im Vordergrund, auch wenn Kosten anfallen können oder das DBMS nicht als Open Source-Projekt entwickelt wird. Bei den „kommerziellen“ DBMS steht das gewerbliche Interesse des Anbieters im Vordergrund, auch wenn es kostenlose Lizenzen gibt.

Weitere Systeme zur Datenverwaltung

Die folgenden Dateisysteme enthalten keine Datenbanken im eigentlichen Sinne, sondern Dateien für strukturierte Daten. Auch diese können (je nach verwendetem Programm) in eingeschränktem Umfang mit SQL-Befehlen umgehen.

• dBASE und seine Varianten
• MS-Access
• das Datenbankmodul Base von LibreOffice
• Paradox

Auf diese Systeme gehen wir nicht ein. Sie müssen in der jeweiligen Programm-Dokumentation nachlesen, welche Befehle und Optionen möglich sind.

Regeln für die Beispiele

Das Buch ist grundsätzlich schrittweise aufgebaut. Aber nicht immer können in einem Beispiel nur bereits bekannte Begriffe verwendet werden. Wenn in seltenen Fällen Bestandteile erst in einem späteren Kapitel erläutert werden, dann gibt es ausdrückliche Hinweise, beispielsweise hier:

• Der INSERT-Befehl in DML (2) – Daten speichern muss korrekt mit Datentypen umgehen und benutzt dazu auch Funktionen.
• Auch für das Erstellen einer Tabelle in DDL – Struktur der Datenbank muss genau auf die Datentypen geachtet werden.

Wenn Sie die SQL-Begriffe aus dem Englischen ins Deutsche übersetzen, sollten Sie den Zusammenhang auch ohne Hin- und Herblättern verstehen.

Die Beispiele für SQL-Befehle werden nach den folgenden Regeln geschrieben.

1. Alle SQL-Befehle und Schlüsselwörter, wie z. B. SELECT, INSERT, DELETE, WHERE, ORDER BY, werden vorzugsweise groß geschrieben. SQL selbst verlangt das nicht, sondern arbeitet ohne Berücksichtigung von Groß- und Kleinschreibung (case insensitive); dort werden SELECT, select und sogar sElEcT gleich behandelt.
2. Eigentlich sollten Tabellen- und Spaltennamen vorzugsweise ebenfalls groß geschrieben werden, und zwar ohne Anführungszeichen. Aber in der Praxis werden solche Namen meistens „gemischt“ geschrieben.
3. String-Literale werden mit einfachen Anführungszeichen gekennzeichnet.
4. SQL-Befehle werden mit einem Semikolon abgeschlossen.
5. Optionale Argumente (d. h. solche, die nicht unbedingt erforderlich sind) werden in [ ] eingeschlossen.
6. Variable Argumente (d. h. solche, die mit unterschiedlichem Inhalt vorkommen) werden in < > eingeschlossen.
7. Wahlmöglichkeiten werden durch das Pipe-Zeichen | (den senkrechten Strich) getrennt.
8. Listen werden gekennzeichnet durch <inhaltliste>, wobei dies eine Kurzform ist für <inhalt1, inhalt2, ... inhaltn>.
9. Sofern das Ergebnis einer Abfrage im Ausgabefenster aufgeführt wird, handelt es sich überwiegend nur um einen Teil des Ergebnisses, gleichgültig ob darauf hingewiesen wird oder nicht.

Die Struktur eines Befehls steht in einem Rahmen mit Courier-Schrift:

 SELECT <spaltenliste>
   FROM <tabellenname>
[ WHERE <bedingungsliste> ]
 ;

Aufgabe

So wird eine Aufgabenstellung angezeigt, die mit dem danach folgenden Beispiel erledigt werden soll.

Ein konkretes Beispiel wird mit einem komplexen Rahmen und unterschiedlichen Inhalten (farblicher Hinweis bei Fehlern, mit oder ohne Kopf- und Fußzeile, mit oder ohne Ausgabefenster) dargestellt:

select * from Beispieltabelle
 where Spalte1 = 'Abc';

Ausgabe

Hier steht ggf. eine Meldung.

Siehe auch

Unter Weblinks stehen viele zusätzliche Hinweise.

XAMPP bietet eine relativ einfache Installation für eine Arbeitsumgebung mit Webserver Apache, Datenbank MariaDB und PHP-Skriptsprache. MariaDB ist sehr ähnlich zu MySQL und eignet sich gut, SQL zu lernen und zu testen.

---

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

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

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

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

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

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:
  1. Der Wert ’’ ist ein leerer Text.
  2. Der Wert ’ ’ ist ein Text, der genau ein Leerzeichen enthält.
  3. Der Wert NULL enthält nichts.
• Für ein logisches Feld (Datentyp boolean) wird dies unterschieden:
  1. Der Wert TRUE bedeutet „wahr“.
  2. Der Wert FALSE bedeutet „falsch“.
  3. Der Wert NULL bedeutet „unbekannt“.
• Für ein Zahlenfeld wird dies unterschieden:
  1. Der Wert 0 ist eine bestimmte Zahl, genauso gut wie jede andere.
  2. 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

Mit diesen Verfahren werden die Tabellen in Beziehung zueinander gebracht. Auch dies folgt der Vorstellung, dass die Wirklichkeit abgebildet werden soll.

Verknüpfungen

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:
  1. 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:
  1. Jedes beteiligte Fahrzeug gehört zu einem Eintrag der Tabelle Fahrzeug.
  2. Jeder Schadensfall muss in der Tabelle Schadensfall registriert sein.
• Die Tabelle Versicherungsvertrag verweist auf folgende Tabellen:
  1. Jeder Vertrag wird von einer Person aus der Tabelle Mitarbeiter bearbeitet.
  2. Zu jedem Vertrag gehört ein Eintrag der Tabelle Fahrzeug.
  3. 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:

1. Jeder Datensatz muss durch einen Schlüssel eindeutig identifiziert werden können.
2. Die Schlüssel der verschiedenen miteinander verknüpften Datensätze müssen sich zuordnen lassen.

Schlüssel

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

Über Wikipedia sind weitere Informationen zu finden:

• Relationale Datenbank
• Entitätenmodell und Entity-Relationship-Modell
• Normalisierung
• Tabellenkalkulation im Gegensatz zu Datenbank-Tabellen
• Nullwert

---

Normalisierung

In diesem Kapitel werden einige Überlegungen angestellt, wie eine Datenbank konzipiert werden soll.

Dieses Kapitel geht über die Anforderungen einer Einführung hinaus; denn es richtet sich weniger an „einfache“ Anwender, die eine vorhandene Datenbank benutzen wollen, sondern an (künftige) Programmentwickler, die eine Datenbank entwerfen und erstellen. Aber wann soll man darüber sprechen, wenn nicht am Anfang?

Grundgedanken

Schon das einfache Muster einer unzureichenden Tabelle wie im vorigen Kapitel weist auf ein paar Forderungen hin, die offensichtlich an eine sinnvolle Struktur gestellt werden sollten:

Redundanz vermeiden

Eine Information, die an mehreren Stellen benötigt wird, soll nur einmal gespeichert werden. Dadurch müssen auch sämtliche Änderungen, die solche Informationen betreffen, nur an einer Stelle erledigt werden.

Im Beispiel waren das u. a. die Angaben zum Fahrzeughalter und zum Sachbearbeiter (mit seinen Telefonnummern), die bei jedem Vertrag angegeben werden.

Wiederholungen trennen

Die Zusammenfassung gleichartiger Informationen ist nicht sehr übersichtlich. Im vorigen Kapitel waren zunächst Festnetz- und Mobil-Rufnummer in einer Spalte untergebracht. Das ist praktisch, wenn man sich keine Gedanken darüber machen will, welche und wie viele Kontaktnummern es gibt. Es ist ziemlich unpraktisch, wenn man gezielt einzelne Nummern suchen will oder von einer Nummer auf den Sachbearbeiter schließen will. Sinnvoller ist es, Festnetz- und Mobilnummer in getrennten Spalten zu speichern.

Primärschlüssel verwenden

Jeder Datensatz muss eindeutig identifiziert werden, damit die Informationen verwendet werden können.

In der ungenügenden Tabelle wurde wegen der Zeilennummern darauf verzichtet. Aber selbst wenn man die Suche in zigtausend Zeilen für machbar hielte, spätestens bei der Aufteilung in mehrere Tabellen braucht man Werte, um die Zusammenhänge eindeutig darzustellen.

Bei diesen Überlegungen handelt es sich nur um ein paar Gedanken, die sich einem aufdrängen. Das wollen wir nun besser strukturieren.

Tabellenkalkulation als Ausgangspunkt

Überlegen wir uns zunächst, welche Informationen benötigt werden.

Grundlegende Daten

Für die Verträge müssen die folgenden Angaben gespeichert werden.

• die Vertragsdaten selbst, also Nummer, Abschlussdatum und Art des Vertrags (HP = Haftpflicht, TK = Teilkasko, VK = Vollkasko) und der Prämienberechnung
• der Vertragspartner mit Name, Anschrift, Telefonnummern, dazu bei natürlichen Personen Geschlecht und Geburtsdatum sowie bei juristischen Personen der Eintrag im Handelsregister o. ä.
• das versicherte Fahrzeug mit Kennzeichen, Hersteller und Typ (die Farbe ist eine Zusatzinformation, die bei manchen Suchvorgängen hilfreich sein kann)
• der zuständige Sachbearbeiter mit Name, Abteilung und Telefonnummern

Ein Teil der Angaben muss immer vorhanden sein, ein anderer Teil je nach Situation (Geschlecht bei Personen) und ein weiterer Teil nur bei Bedarf (Mobiltelefon).

Schnell stellen wir fest, dass ein Versicherungsnehmer auch mehrere Fahrzeuge versichern kann. Andererseits kann ein Fahrzeug zu mehreren Verträgen gehören, wenn Haftpflicht und Vollkasko getrennt abgeschlossen werden oder wenn zur Haftpflicht vorübergehend Vollkasko fürs Ausland hinzukommt. Jeder Vertrag ist ein eigener Datensatz; also stehen bei jedem Datensatz die Angaben des Vertragspartners und des Fahrzeugs. Um alle Verträge eines Kunden gemeinsam anzuzeigen, brauchen wir folglich ein paar Angaben zur Organisation:

• Kundennummer und laufende Nummer seiner Verträge als eindeutiger Suchbegriff (vielleicht als Primärschlüssel)
• Vertragsnummer als eindeutiger Wert
• Fahrzeug-Kennzeichen als Wert, der meistens (aber nicht immer) nur einmal vorkommt

Schadensfälle

Nun sollen zu einem Vertrag auch die Schadensfälle gespeichert werden. Wir benötigen also eine oder mehrere Spalten mit den erforderlichen Angaben (Datum und Art des Schadens, Sachbearbeiter der Schadensabwicklung, andere beteiligte Fahrzeuge); aber wie wird das am besten gespeichert?

• eine gemeinsame Spalte für alle diese Angaben für alle Schadensfälle (denn die Mehrzahl der Fahrzeuge fährt schadensfrei)
• je eine Spalte für alle Angaben eines Schadensfalls (werden dann zwei oder drei Spalten benötigt, oder muss man für „Mehrfach-Sünder“ gleich zehn Spalten vorsehen?)
• oder einzelne Datensätze für jeden Schaden eines Fahrzeugs (sodass sich alle Fahrzeug- und Vertragsdaten in diesen Datensätzen wiederholen und nur die Schadensangaben unterscheiden)

Ungeklärt bleibt dabei noch dieses Problem: Wie viele versicherte Schadensgegner gibt es denn – keine (wenn ein Reh angefahren wird), einen (z. B. beim Parken) oder viele (bei einem Auffahrunfall auf der Autobahn)?

Entscheiden wir uns deshalb provisorisch für ein eigenes Arbeitsblatt Schadensfälle mit folgender Struktur:

• je eine Spalte für die Angaben, die direkt zum Schadensfall gehören
• vorläufig 5 Gruppen für maximal 5 beteiligte Fahrzeuge
• jede dieser Gruppen enthält in einzelnen Spalten Fahrzeug-Kennzeichen und die Halter-Angaben (Name, Anschrift)

Damit stehen die Fahrzeugdaten in beiden Arbeitsblättern. Als praktisches Problem kommt hinzu: Für die Schadenshäufigkeit eines bestimmten Fahrzeugs muss man es in fünf Spalten heraussuchen. Die Beschränkung auf fünf beteiligte Fahrzeuge wird im nächsten Schritt aufgelöst, machen wir uns dazu keine weiteren Gedanken.

Auf diesem Weg kann jedenfalls keine sinnvolle Struktur erreicht werden.

„Update-Anomalien“

Mit diesem Begriff werden die folgenden Unklarheiten bezeichnet. Dabei handelt es sich um weitere Probleme bei einer ungenügenden Struktur.

Einfügen-Anomalie

In der ersten Tabelle sind u. a. die Sachbearbeiter enthalten. Es wäre sinnvoll, auch alle anderen Mitarbeiter der Gesellschaft hier einzutragen. Aber bei einem Vertrag werden zwingend Vertragsnummer und Abschlussdatum benötigt; dieser Zwang verhindert das Speichern der Teilinformation Sachbearbeiter ohne Bezug auf einen Vertrag.

Löschen-Anomalie

Wenn ein Vertrag gekündigt und abgelaufen ist und deshalb gelöscht wird, dann sind in der ersten Tabelle auch alle Angaben zum Vertragspartner verloren. Wenn er drei Tage später einen neuen Vertrag abschließt, müssen alle seine Angaben neu aufgenommen werden. Und was soll mit den Schadensfällen geschehen, die zu diesem Vertrag gespeichert sind?

Ändern-Anomalie

Wenn der Sachbearbeiter wechselt, muss sein Name bei allen von ihm betreuten Verträgen geändert werden, obwohl eine einzige Änderung ausreichend sein sollte. (Dies ist auf die Datenredundanz zurückzuführen, dass nämlich dieser Hinweis vielfach gespeichert ist statt einmalig.)

All diesen Problemen wollen wir nun durch eine deutlich verbesserte Datenstruktur begegnen. Nehmen wir dazu zunächst an, dass alle benötigten Informationen in den beiden Arbeitsblättern Verträge und Schadensfälle der Tabellenkalkulation stehen, und beginnen wir, dies sinnvoll zu strukturieren.

Die 1. Normalform

Am „grausamsten“ für den Aufbau der Tabelle und die praktische Arbeit ist die vielfache Wiederholung gleicher Informationen.

Sowohl beim Namen des Fahrzeughalters als auch bei den Mitarbeitern steht der Name bisher in einer Spalte in der Form „Nachname, Vorname“, was als Suchbegriff geeignet ist. Nun benötigen wir aber auch eine persönliche Anrede (Name mit Titel) und eine Briefanschrift (Vorname, Name). Soll dies in weiteren Spalten gespeichert werden? Nein, denn all dies kann aus den Einzelangaben „Name“ und „Vorname“ zusammengesetzt werden.

Ein Schadensfall ist bisher auf fünf beteiligte Fahrzeuge beschränkt, auch wenn selten mehr als zwei Beteiligungen benötigt werden. Wenn nun ein sechstes, zehntes oder zwanzigstes Fahrzeug beteiligt ist, muss dann jedesmal die Tabellenstruktur (und jedes Makro, das auf diese Spalten zugreift) geändert werden?!

Damit haben wir bereits zwei Regeln, die als Definition der ersten Normalform gelten. Hinzu kommt eine dritte Regel, die zwar formal nicht erforderlich ist; aber aus praktischen Gründen gibt es keine sinnvolle Lösung ohne diese Regel.

	Die 1. Normalform 1. Jede Spalte enthält nur unteilbare (atomare, atomische) Werte. 2. Spalten, die gleiche oder gleichartige Informationen enthalten, sind in eigene Tabellen (Relationen) auszulagern. 3. Jede Tabelle enthält einen Primärschlüssel.

Verletzung der 1. Normalform

Unsere Ausgangstabelle verstößt an vielen Stellen gegen diese Regeln:

• Zusammengesetzte Werte befinden sich z. B. an folgenden Stellen:
  • Fahrzeughalter: Name und Vorname, PLZ und Ort, ggf. Straße und Hausnummer
  • Sachbearbeiter: Name und Vorname, Festnetz- und Mobilnummer
• Wiederholungen finden sich vor allem hier:
  • mehrere Fahrzeuge bei einem Schadensfall

Vorgehen zur Herstellung der 1. Normalform

Es werden also zwei Schritte benötigt:

1. Zusammengesetzte Werte werden in Einzelinformationen aufgeteilt: je eine Spalte für jeden unteilbaren Wert.
2. Wiederholungen werden in getrennte Tabellen ausgelagert; welche Daten zusammengehören, wird durch eine laufende Nummer angegeben.

Eine erste Verbesserung

An jeder Stelle, die Namen oder Anschrift enthält, werden getrennte Spalten verwendet, beispielsweise im Arbeitsblatt Verträge:

Kundennummer  Vertrag  Abschluss   Halter_Name             Halter_PLZ  Halter_Ort   Sachbearbeiter_N  Sachbearbeiter_V  Telefon
    1          DG-01   03.05.1974  Heckel Obsthandel GmbH  46282       Dorsten      Pohl              Helmut            0201/4014186
    1          DG-02   04.07.1974  Heckel Obsthandel GmbH  46282       Dorsten      Pohl              Helmut            0201/4014186    

Die Tabelle Schadensfälle wird auf die eigentlichen Daten beschränkt; die beteiligten Fahrzeuge stehen in einer eigenen Tabelle Zuordnungen.

Nummer  Datum       Schadensort                           Beschreibung              Sachbearbeiter_N  Sachbearbeiter_V  Telefon
   1    02.03.2007  Recklinghausen, Bergknappenstr. 144   Gartenzaun gestreift      Schindler         Christina         0201/4012151
   2    11.07.2007  Haltern, Hauptstr. 46                 beim Ausparken hat ...    Aliman            Zafer             0201/4012161

Die Anzahl der beteiligten Fahrzeuge an einem Schadensfall wird durch eine eigene Tabelle Zuordnungen berücksichtigt:

Nummer  Fahrzeug    Hersteller  Typ     Halter_Name  Halter_Vorname  Halter_PLZ  Halter_Ort      Halter_Straße
   1    RE-LM 902   Opel        Corsa   Heckel Obsthandel GmbH       46282       Dorsten         Gahlener Str. 40  
   2    BO-GH 102   Volvo       C30     Geissler     Helga           44809       Bochum          Steinbankstr. 15
   2    RE-CD 456   Renault     Twingo  Cornelsen    Dorothea        44577       Castrop-Rauxel  Kiefernweg 9

Die Zusatzbedingung eines Primärschlüssels wurde gleichzeitig erfüllt; die betreffenden Spalten wurden unterstrichen.

Die 2. Normalform

Eine weitere Wiederholung in den „Monster-Tabellen“ sind die Angaben zum Halter bei den Verträgen und den Zuordnungen oder die Fahrzeugdaten sowohl bei den Verträgen als auch bei den Zuordnungen. Auch diese werden in eigene Tabellen ausgelagert; das ergibt sich als Definition aus der folgenden Regel:

	Die 2. Normalform 1. Die Tabelle erfüllt die 1. Normalform. 2. Alle Informationen in den Spalten, die nicht Teil des Primärschlüssels sind, müssen sich auf den gesamten Primärschlüssel beziehen.

Man sagt dazu auch, dass die Informationen funktional abhängig sind von der Gesamtheit der Schlüsselwerte. Umgekehrt formuliert bedeutet es: Wenn eine Spalte nur zu einem einzelnen Schlüsselfeld gehört, ist die 2. Normalform nicht erfüllt.

Während sich die 1. Normalform auf die einzelnen Spalten und Wiederholungen innerhalb eines Datensatzes bezieht, befasst sich die 2. Normalform mit Wiederholungen bei verschiedenen Datensätzen.

Verletzung der 2. Normalform

Unsere derzeitigen Tabellen verstoßen mehrfach gegen diese Regel:

• Bei den Verträgen beziehen sich Name und Anschrift des Vertragspartners nur auf die Kundennummer, aber nicht auf die Vertragsnummer.
• Bei den Verträgen stehen auch die Fahrzeugdaten. (Dies wurde bei der Beschreibung der grundlegenden Daten erwähnt, fehlt aber in den bisherigen Beispielen.) Diese beziehen sich auf die Vertragsnummer, haben aber nur indirekt etwas mit Name und Anschrift des Vertragspartners zu tun.
• Bei den Zuordnungen der Schadensfälle gehören sowohl die Fahrzeug- als auch die Halterdaten nur zu einem Fahrzeug (also dem Kennzeichen), aber nicht zu einem Schadensfall.

Vorgehen zur Herstellung der 2. Normalform

Es müssen alle „unpassenden“ Informationen in eigene Tabellen ausgelagert werden. Der Primärschlüssel wird vereinfacht, sodass er sich nur auf die „eigentlichen“ Informationen einer Tabelle bezieht.

• Aus den Verträgen werden alle Angaben des Vertragspartners entfernt und in eine Tabelle Versicherungsnehmer übertragen. Der Primärschlüssel besteht nur noch aus der Spalte Vertrag. Die Spalte Kundennummer ist nur noch ein Fremdschlüssel als Verweis auf die neue Tabelle Versicherungsnehmer.

• Aus den Verträgen werden alle Angaben des Fahrzeugs entfernt und in eine neue Tabelle Fahrzeuge übertragen. Das Fahrzeug-Kennzeichen ist hier nur noch ein Fremdschlüssel als Verweis auf die Tabelle Fahrzeuge.

• Aus den Zuordnungen werden alle Angaben der Fahrzeuge entfernt und in eine Tabelle Fahrzeuge übertragen. Die Tabelle Zuordnungen besteht nur noch aus den Spalten des Primärschlüssels.

Damit stehen die Fahrzeugdaten nur noch in einer Tabelle – sowohl für die Verträge als auch für die Schadensfälle (genauer: die Zuordnungen).

Eine zweite Verbesserung

Die ursprüngliche Tabelle Verträge beschränkt sich jetzt auf diese Angaben:

Vertrag  Abschluss   Typ   Kundennummer  Fahrzeug   Sachbearbeiter_N  Sachbearbeiter_V  Telefon
 DG-01   03.05.1974  HP          1       RE-LM 901  Pohl              Helmut            0201/4014186
 DG-02   04.07.1974  HP          1       RE-LM 902  Pohl              Helmut            0201/4014186

Die neue Tabelle Versicherungsnehmer umfasst die Daten, die sich auf den Vertragspartner beziehen:

Kundennummer  Name         Vorname    Geburtsdatum  PLZ    Ort        Straße       Hausnummer
    1         Heckel Obsthandel GmbH                46282  Dorsten    Gahlener Str.    40   
    5         Geissler     Helga      13.01.1953    44809  Bochum     Steinbankstr.    15

Die neue Tabelle Fahrzeuge umfasst nur noch die Daten, die sich auf das Fahrzeug selbst beziehen. Name und Anschrift des Fahrzeughalters werden durch die Kundennummer, also den Verweis auf die Tabelle Versicherungsnehmer ersetzt.

Fahrzeug    Hersteller  Typ     Farbe   Halter
RE-LM 902   Opel        Corsa   ocker      1
BO-GH 102   Volvo       C30     rot        5
RE-CD 456   Renault     Twingo  ocker      3

Die Tabelle Schadensfälle muss nicht angepasst werden. Die Tabelle Zuordnungen vereinfacht sich radikal:

Nummer  Fahrzeug
   1    RE-LM 902 
   2    BO-GH 102   
   2    RE-CD 456   

Die 2. Normalform kann ganz einfach dadurch gewährleistet werden, dass sich der Primärschlüssel nur auf eine Spalte bezieht.

Die 3. Normalform

Beseitigen wir noch die übrigen Wiederholungen, nämlich die Sachbearbeiter bei den Verträgen und den Schadensfällen sowie die Hersteller bei den Fahrzeugen. Diese werden ebenfalls in eigene Tabellen ausgelagert gemäß der Definition nach der folgenden Regel:

	Die 3. Normalform 1. Die Tabelle erfüllt die 2. Normalform. 2. Informationen in den Spalten, die nicht Teil des Primärschlüssels sind, dürfen funktional nicht voneinander abhängen.

Die 3. Normalform befasst sich also mit Wiederholungen bei verschiedenen Datensätzen, die nur zusätzliche Informationen bereitstellen.

Verletzung der 3. Normalform

Unsere derzeitigen Tabellen verstoßen in folgender Hinsicht gegen diese Regel:

• Name, Vorname und Telefonnummer eines Sachbearbeiters hängen voneinander ab. Sie haben aber nur insgesamt etwas mit dem Vertrag bzw. dem Schadensfall zu tun, nicht als einzelne Information.
• Hersteller und Typ eines Fahrzeugs hängen voneinander ab. Sie haben aber nur insgesamt etwas mit dem Fahrzeug zu tun, nicht als einzelne Information.

Eine andere Erklärung dafür ist, dass die Zusatzinformation auch ohne Bezug zum eigentlichen Datensatz gültig bleibt. Der Sachbearbeiter gehört zum Unternehmen unabhängig von einem bestimmten Vertrag. Der Fahrzeughersteller existiert unabhängig davon, ob ein bestimmtes Fahrzeug noch fährt oder inzwischen verschrottet worden ist.

Vorgehen zur Herstellung der 3. Normalform

Alle „unpassenden“ Informationen kommen wieder in eigene Tabellen. Ihre Spalten werden ersetzt durch einen Fremdschlüssel als Verweis auf die neue Tabelle.

• Aus den Verträgen und den Schadensfällen werden alle Angaben zum Sachbearbeiter entfernt und in eine Tabelle Mitarbeiter übertragen. Die Spalte Sachbearbeiter verweist nur noch als Fremdschlüssel auf die neue Tabelle Mitarbeiter.

  Dies löst automatisch auch das oben erwähnte Problem: Wir können nun alle Mitarbeiter in einer gemeinsamen Tabelle speichern.

• Aus den Fahrzeugen werden alle Angaben zu Hersteller und Typ entfernt und in eine neue Tabelle Fahrzeugtypen übertragen. Die Spalten Hersteller und Typ werden ersetzt durch einen Fremdschlüssel als Verweis auf die Tabelle Fahrzeugtypen.

  Um es korrekt zu machen, gehört der Hersteller in eine weitere Tabelle Fahrzeughersteller; in der Tabelle Fahrzeugtypen verweist er als Fremdschlüssel auf diese weitere Tabelle.

Eine weitere Verbesserung

Die Tabellen Verträge und Schadensfälle werden also nochmals vereinfacht:

Vertrag  Abschluss   Typ   Kundennummer  Fahrzeug   Sachbearbeiter
 DG-01   03.05.1974  HP          1       RE-LM 901      9
 DG-02   04.07.1974  HP          1       RE-LM 902      9

Nummer   Datum       Schadensort                    Beschreibung      Sachbearb
   1     02.03.2007  Recklinghausen, Bergknappe...  Gartenzaun gestreift        14 
   2     11.07.2007  Haltern, Hauptstr. 46          beim Ausparken hat ...      15 

Hinzu kommt die neue Tabelle Mitarbeiter:

Nummer   Nachname    Vorname       Telefon
   9     Pohl        Helmut        0201/4014186
  14     Schindler   Christina     0201/4012151
  15     Aliman      Zafer         0201/4012161

In gleicher Weise wird die Tabelle Fahrzeuge gekürzt; die Angaben werden in die neuen Tabellen Fahrzeugtypen und Fahrzeughersteller ausgelagert.

Zusätzliche Maßnahmen

In der Theorie gibt es noch eine 4. und eine 5. Normalform (und eine Alternative zur 3. Normalform). Dazu sei auf den Wikipedia-Artikel und die dortigen Hinweise (Quellen, Literatur, Weblinks) verwiesen. In der Praxis ist aber eine Datenbank, die den Bedingungen der 3. Normalform entspricht, sehr gut konzipiert. Weitere Normalisierungen bringen kaum noch Vorteile; stattdessen können sie die Übersichtlichkeit und die Geschwindigkeit beim Datenzugriff beeinträchtigen.

Verzicht auf Zusatztabellen

Beispielsweise wiederholen sich in der Tabelle Versicherungsnehmer die Ortsangaben. Dabei gehören die Kombinationen PLZ/Ort immer zusammen; auch wenn der Kunde umzieht, ist eine solche Kombination unverändert gültig. Also könnte man in der Tabelle die Adresse wie folgt speichern:

Kd-Nr  Name         Vorname    Geburtsdatum  PLZ    Alort     Straße       Hausnummer
   1   Heckel Obsthandel GmbH                46282  10884500  Gahlener Str.    40  
   5   Geissler     Helga      13.01.1953    44809  05902500  Steinbankstr.    15

Der Ortsname ist dann zu finden über die PL-Datei der Deutschen Post AG (mit PLZ/Alort als Primärschlüssel):

Dateiversion  Geltung   PLZ    Alort     PLZ-Arten  Ortsname
PL 0509 244   20010101  44809  05902500  06 2 2     Bochum
PL 0509 244   20050329  46282  10884500  06 2 2     Dorsten

Das gleiche Verfahren ist möglich für die Straßennamen. Es sorgt dafür, dass nur gültige Anschriften gespeichert sind und auch bei Eingemeindungen die neuen Angaben eindeutig übernommen werden. Aber selbst wenn man wegen der Datensicherheit mit Alort arbeiten will, wird man für die praktische Arbeit den Ortsnamen in der Adressendatei behalten wollen.

Primärschlüssel nur zur Identifizierung

Im vorigen Kapitel hatten wir kurz darauf hingewiesen, dass der Primärschlüssel nur die Bedeutung als ID haben sollte.

Eine Begründung liefert die obige Tabelle Fahrzeuge, bei der das Kennzeichen zur Identifizierung benutzt wurde. Wenn der Fahrzeughalter in einen anderen Kreis umzieht, bekommt er ein neues Kennzeichen. Dann müsste es an allen Stellen geändert werden, an denen es gespeichert ist. Nun darf die Vertragsabteilung nur die Verträge ändern, die Schadensabwicklung die Schadensfälle (und wer weiß, wo noch darauf Bezug genommen wird). Jede Ummeldung verursacht also erheblichen Mehraufwand.

Sorgen wir also für mehr Datensicherheit und Arbeitsvereinfachung:

• Der Primärschlüssel ist eine automatisch zugewiesene ID. Diese ID wird niemals geändert.
• Die Identifizierung, die der Benutzer kennt, ist eine einzelne Spalte in einer einzigen Tabelle.

Beispiele: Vertragsnummer, Fahrzeug-Kennzeichen, Personalnummer

• Die Verknüpfungen mit anderen Tabellen regelt die Datenbank mit Hilfe der ID selbständig.

Änderungsdaten

In vielen Fällen ist es sinnvoll, wenn in einer Tabelle nicht nur der aktuelle Zustand gespeichert ist, sondern der Verlauf.

• Beispiel mit Änderung des Kennzeichens: Wenn die Polizei nach einem Unfallverursacher sucht, der inzwischen umgezogen ist, wird für das alte (nicht mehr gültige) Kennzeichen kein Fahrzeug gefunden.
• Adressenänderungen auf Termin legen: Es wäre viel zu aufwändig, wenn alle Änderungen gleichzeitig an dem Stichtag, an dem sie gelten sollen, eingegeben werden müssten. Besser ist es, sie sofort zu speichern mit Angabe des Geltungsdatums; die Datenbank holt abhängig vom aktuellen und dem Geltungsdatum immer die richtige Version.
• Aktueller Steuersatz: Die Abrechnung einer Versandfirma muss immer mit dem richtigen Steuersatz rechnen, auch wenn er mitten im Jahr geändert wird. Als Steuersatz 1 für die Mehrwertsteuer wird dann bei einer „älteren“ Rechnung mit 16 % und bei einer Rechnung neueren Datums mit 19 % gerechnet.

Für alle solche Fälle erhalten Tabellen gerne zusätzliche Spalten gültig von und gültig bis. Anstelle einer Änderung werden Datensätze verdoppelt; die neuen Informationen ersetzen dabei die bisher gültigen.

Selbstverständlich erfordert eine solche Datenbankstruktur höheren Aufwand sowohl beim Entwickler der Datenbank als auch beim Programmierer der Anwendung. Der zusätzliche Nutzen rechtfertigt diesen Aufwand.

Reihenfolge ohne Bedeutung

Beim Aufbau einer Datenbank darf es nicht relevant sein, in welcher Reihenfolge die Zeilen und Spalten vorkommen: Die Funktionalität der Datenbank darf nicht davon abhängen, dass zwei Spalten in einer bestimmten Folge nacheinander kommen oder dass nach einem Datensatz ein bestimmter zweiter folgt.

• Ein Datensatz (also eine Zeile) steht nur über den Primärschlüssel bereit.
• Eine Spalte steht nur über den Spaltennamen zur Verfügung.

Nur ausnahmsweise wird mit der Nummer einer Zeile oder Spalte gearbeitet, z. B. wenn ein „Programmierer-Werkzeug“ nur indizierte Spalten kennt.

Zusammenfassung

Fassen wir diese Erkenntnisse zusammen zu einigen Regeln, die bei der Entwicklung einer Datenbank-Struktur zu beachten sind.

Allgemeine Regeln

Von der Realität ausgehen

Erstellen Sie Tabellen danach, mit welchen Dingen (Objekten) Sie arbeiten. Benutzen Sie aussagekräftige Namen für Tabellen und Spalten.

Einzelne Informationen klar trennen

Alle Informationen werden in einzelne Spalten mit unteilbaren Werten aufgeteilt.

Vollständigkeit

Alle möglichen Informationen sollten von vornherein berücksichtigt werden. Nachträgliche Änderungen sind zu vermeiden.

Keine berechneten Werte speichern

Eine Information, die aus vorhandenen Angaben zusammengestellt werden kann, wird nicht als eigene Spalte gespeichert.

Kleine Tabellen bevorzugen

Wenn eine Tabelle sehr viele Informationen umfasst, ist es besser, sie zu unterteilen und über einen einheitlichen Primärschlüssel zu verbinden.

Keine doppelten Speicherungen

Es darf weder ganze doppelte Datensätze geben noch wiederholte Speicherungen gleicher Werte (Redundanz von Daten). Doppelte Datensätze werden durch Primärschlüssel und Regeln zur Eindeutigkeit in Felder vermieden; Datenredundanz wird durch getrennte Tabellen ersetzt, sodass es nur die Fremdschlüssel mehrfach gibt.

Wichtig ist auch, dass der Aufbau der Datenbank beschrieben und ggf. begründet wird. Hilfreich sind dabei graphische Darstellungen, wie sie von vielen Datenbank-Programmen angeboten werden.

Abweichungen

Die vorstehenden Überlegungen werden nicht immer beachtet. Für fast jede Regel gibt es begründete Ausnahmen

Beispielsweise enthält eine Datenbank mit Adressen in der Regel die Adressen im Klartext und nicht nur als Verweise auf die Nummern von Orten, Ortsteilen, Straßen und Straßenabschnitten der Deutschen Post.

Entscheiden Sie erst nach bewusster Abwägung von Vor- und Nachteilen, wenn Sie von einer der Regeln abweichen wollen.

Siehe auch

Über Wikipedia sind weitere Informationen zu finden:

• Normalisierung
• Relationale Datenbank
• Edgar F. Codd und seine 12 Regeln für relationale Datenbanken
• Update-Anomalien
• Redundanz von Daten

Für eine sorgfältige Planung einer Adressen-Datenbank hilft die Datenstruktur der Deutschen Post:

• Datafactory als Überblick (PLZ, Orte / Ortsteile und Straßen)
• Datafactory Streetcode Handbuch mit Aufbau und Inhalt (PDF, 600 kB)

---

Beispieldatenbank

Dieses Kapitel bespricht die Grundlagen der Beispieldatenbank. Alle Einzelheiten der Tabellen stehen im Anhang unter Tabellenstruktur der Beispieldatenbank.

	Hinweis Alle Beispiele, Erläuterungen und Aufgaben beziehen sich auf diese Datenstruktur. Bitte schlagen Sie (soweit erforderlich) immer dort nach.

Sachverhalt

Die Beispieldatenbank in diesem Buch versucht, eine Versicherungsgesellschaft für Kfz-Versicherungen abzubilden. Das Beispiel ist eine starke Vereinfachung der Realität; zum Beispiel fehlen alle Teile der laufenden Abrechnung der Prämien und Schadensfälle.

Die relevanten Begriffe sind für eine bessere Übersichtlichkeit fett gekennzeichnet. Folgender Sachverhalt wird in der Datenbank abgebildet:

Die Versicherungsgesellschaft UnsereFirma verwaltet mit dieser Datenbank ihre Kundendaten und die Schadensfälle. Wegen der Schadensfälle müssen auch Daten „fremder“ Kunden und Versicherungen gespeichert werden.

Jeder Versicherungsvertrag wird mit einem Versicherungsnehmer über genau ein Fahrzeug abgeschlossen. Der Versicherungsvertrag wird durch folgende Eigenschaften gekennzeichnet; zu jeder Eigenschaft gehört eine Spalte:

• Vertragsnummer (Pflicht, eindeutig)
• Datum des Abschlusses, Art des Vertrages (Pflicht); dabei gibt es die Arten Haftpflicht (HP), Haftpflicht mit Teilkasko (TK), Vollkasko (VK).
• Verweis auf den Versicherungsnehmer (Pflicht)
• Verweis auf das Fahrzeug (Pflicht, eindeutig)
• Verweis auf den Mitarbeiter, der den Vertrag bearbeitet (Pflicht)

Der Versicherungsnehmer ist gekennzeichnet durch diese Eigenschaften:

• Kundennummer (Pflicht, eindeutig)
• Name und Anschrift: PLZ, Ort, Straße, Hausnummer (Pflicht)
• bei natürlichen Personen zusätzlich durch Vorname, Geburtsdatum, Datum des Führerscheins (optional)
• Verweis auf eine „Fremdversicherung“, wenn ein (fremdes) Fahrzeug an einem Unfall beteiligt ist (optional)

Das Fahrzeug ist gekennzeichnet durch diese Eigenschaften:

• polizeiliches Kennzeichen (Pflicht, eindeutig)
• Farbe (optional)
• Fahrzeugtyp und damit indirekt auch den Fahrzeughersteller (Pflicht)

Ein Mitarbeiter ist gekennzeichnet durch diese Eigenschaften:

• Name, Vorname, Geburtsdatum (Pflicht)
• Personalnummer (Pflicht, eindeutig)
• Verweis auf Abteilung, Vermerk, ob es sich um den Leiter der Abteilung handelt (Pflicht)
• Kontaktdaten wie Telefon, Mobiltelefon, Email, Raum (optional)

Die Abteilung ist gekennzeichnet durch diese Eigenschaften:

• Nummer (Pflicht, eindeutig)
• Kurzbezeichnung, Bezeichnung (Pflicht, eindeutig)
• Ort (optional)

Zusätzlich gibt es Dienstwagen. Dabei handelt es sich um eine Tabelle mit den gleichen Eigenschaften wie bei Fahrzeug und zusätzlich:

• Verweis auf den Mitarbeiter, zu dem ein Dienstwagen gehört (optional)
• denn es gibt auch Firmenwagen, die keinem Mitarbeiter persönlich zugeordnet sind

Ein Schadensfall ist gekennzeichnet durch diese Eigenschaften:

• Datum, Ort und Umstände des Unfalls (Pflicht)
• Vermerk, ob es Verletzte gab, sowie Höhe des Gesamtschadens (optional, denn die Angaben könnten erst später bekannt werden)
• Verweis auf den Mitarbeiter, der den Schadensfall bearbeitet (Pflicht)

An einem Schadensfall können mehrere Fahrzeuge unterschiedlicher Versicherungen beteiligt sein. (Unfälle mit Radfahrern und Fußgängern werden nicht betrachtet.) Deshalb gibt es eine weitere Tabelle Zuordnung_SF_FZ:

• Liste aller Schadensfälle und aller beteiligten Fahrzeuge (Pflicht)
• anteilige Schadenshöhe eines Fahrzeugs an dem betreffenden Unfall (optional)

Über die Verbindung Schadensfall → Fahrzeug → Versicherungsvertrag → Versicherungsnehmer → Versicherungsgesellschaft können alle beteiligten Gesellschaften festgestellt und in die Schadensabwicklung eingebunden werden.

Bitte beachten Sie auch die unten stehenden Hinweise über Fehlende Spalten und Einschränkungen.

Schematische Darstellung

Die vorstehende Struktur kann in folgendem Diagramm dargestellt werden. Die Verweise, nämlich die Verknüpfungen zwischen den Tabellen sind daraus so abzulesen:

• Von jeder Tabelle gibt es einen Verweis auf einen Eintrag in der direkt darunter stehenden Tabelle.
• Zu jedem Vertrag gehört ein Sachbearbeiter; das wird durch den Pfeil nach links außen angedeutet, der in der Tabelle Mitarbeiter von rechts hereinkommt.
• Zu jedem Vertrag gehört genau ein Fahrzeug; zu jedem Fahrzeug gehört ein Vertrag.
• Jeder Eintrag in der Liste der Zuordnungen Schadensfall, Fahrzeug bezieht sich auf einen Schadensfall und ein Fahrzeug; dabei gilt:
  • Zu jedem Schadensfall gehören ein oder mehrere Fahrzeuge.
  • Nicht jedes Fahrzeug hat einen Schadensfall.
• Ein Dienstwagen kann einem Mitarbeiter zugeordnet sein, muss es aber nicht.

Tabellen und ihre Zusammenhänge

Doppelte Pfeile zeigen eine Muss-Verknüpfung, einfache eine Kann-Verknüpfung.

Die Kürzel bei den Tabellennamen werden künftig immer wieder als „Alias“ anstelle des „Langnamens“ verwendet. In dieser Übersicht wurden sie wegen der Deutlichkeit großgeschrieben; künftig werden sie kleingeschrieben.

Tabellenstruktur und Datenbank

Im Anhang ist die Tabellenstruktur der Beispieldatenbank beschrieben, nämlich die Liste der Tabellen und aller ihrer Spalten. Innerhalb des Buches wird die Datenbankstruktur erweitert werden; dabei werden einige der nachstehenden Anmerkungen beachtet.

Im Anhang stehen auch Wege, wie Sie die Beispieldatenbank erhalten.

• Entweder Sie holen sich eine fertige Version der Datenbank:
  • Laden Sie die komprimierte Datei herunter.
  • Benennen Sie die Datei um, soweit erforderlich.
  • Extrahieren Sie die Daten und speichern Sie das Ergebnis an einer passenden Stelle.
• Oder Sie erzeugen die Datenbank mit einem Hilfsprogramm des von Ihnen verwendeten DBMS:
  • Erstellen Sie zunächst eine leere Datenbank, soweit erforderlich.
  • Laden bzw. kopieren Sie das passende Skript zum Erzeugen der Datenbank-Tabellen und Daten.
  • Führen Sie das Skript mit einem Hilfsprogramm des von Ihnen verwendeten DBMS aus.

Eine kurze Beschreibung für die Installation steht bei den Hinweisen zu den Downloads. Für Details nutzen Sie bitte die Dokumentation des jeweiligen Datenbankmanagementsystems; Links dazu stehen in der Einleitung sowie unter Weblinks.

Zum Abschluss werden auch ein paar Verfahren behandelt, schnell viele Datensätze als Testdaten zu erzeugen. Für das Verständnis der Inhalte des Buchs sind diese Verfahren nicht wichtig. Sie sind aber äußerst nützlich, wenn Sie weitere Möglichkeiten der SQL-Befehle ausprobieren wollen.

Anmerkungen

Die Beispieldatenbank wurde erstellt und eingefügt, als sich das Buch noch ziemlich am Anfang befand. Im Laufe der Zeit wurden bei der Konzeption und der Umsetzung in Beispielen Unstimmigkeiten und Mängel festgestellt. Auf diese soll hier hingewiesen werden; teilweise wurden sie beseitigt, teilweise werden wir die Datenstruktur in späteren Kapiteln ändern, teilweise belassen wir es dabei.

Namen von Tabellen und Spalten

Es ist üblicher, eine Tabelle im Singular zu bezeichnen.

• Es ist einfacher zu sagen: Ein Versicherungsvertrag hat diese Eigenschaften… Umständlicher wäre: Ein Datensatz der Tabelle Versicherungsverträge hat diese Eigenschaften…
• Vor allem beim Programmieren werden die Namen mit anderen Begriffen verknüpft; es käme dann etwas wie VertraegePositionenRow zustande – also die Positionen von Verträgen –, wo nur eine einzelne Zeile, nämlich eine Position eines Vertrags gemeint ist.

➤ Aus diesem Grund wurden die o. g. SQL-Skripte nochmals vollständig überarbeitet; alle Tabellennamen benutzen jetzt den Singular.

In einem Programmiererforum gab es einmal eine Diskussion über „Singular oder Plural“. Dort wurde das als uraltes Streitthema bezeichnet, das zu heftigsten Auseinandersetzungen führen kann. Im Ergebnis sollte es eher als Geschmackssache angesehen werden. Also hat der Autor in diesem Buch seinen Geschmack durchgesetzt. Wer mag, kann für sich alle Tabellennamen (im Skript für die Beispieldatenbank und in allen Beispielen und Übungen) ändern.

Die Spalten von Tabellen sollen den Inhalt klar angeben; das ist durchgehend berücksichtigt worden. Es ist nicht üblich, ein Tabellenkürzel als Teil des Spaltennamens zu verwenden; denn ein Spaltenname wird immer in Zusammenhang mit einer bestimmten Tabelle benutzt.

➤ Aus einer früheren Version der Beispieldatenbank wurden diese Kürzel entfernt.

Es ist häufig praktischer, englische Begriffe für Tabellen und Spalten zu verwenden. Programmierer müssen die Namen weiterverarbeiten; weil sowohl Datenbanken als auch Programmiersprachen mit Englisch arbeiten, entstehen ständig komplexe Namen. Dabei ist ein Begriff wie CustomerNumberChanged (also reines Englisch) immer noch besser als etwas wie KundeNummerChanged, also denglischer Mischmasch.

➤ Auf diese Änderung wird verzichtet, weil es ziemlich umständlich gewesen wäre. Außerdem spielt die Weiterverwendung durch Programmierer in diesem Buch eigentlich keine Rolle.

Aufteilung der Tabellen

Die Aufgaben der Versicherungsgesellschaft können nur eingeschränkt behandelt werden. Es fehlen Tabellen für Abrechnung und Zahlung der Prämien sowie Abrechnung der Kosten für Schadensfälle.

➤ Auf diese Aufgaben wird hier verzichtet.

Die Tarife und damit die Höhe der Basisprämie gehören in eine eigene Tabelle; ein Versicherungsvertrag müsste darauf verweisen.

➤ Auf diese Aufteilung wird wegen der Vereinfachung verzichtet.

Sowohl Mitarbeiter als auch Versicherungsnehmer sind Personen: Auch zu einem Versicherungsnehmer passen Kontaktdaten; auch bei einem Mitarbeiter ist die Privatanschrift von Bedeutung. Es wäre deshalb vernünftig, eine gemeinsame Tabelle Person einzurichten; die Tabelle Mitarbeiter würde Verweise auf diese Tabelle erhalten.

➤ Auf diese Änderung wird wegen der Vereinfachung verzichtet.

Man kann darüber streiten, ob der optionale Verweis auf eine fremde Versicherungsgesellschaft besser zum Versicherungsvertrag oder zum Versicherungsnehmer gehört.

➤ Wegen dieser Unklarheit wird auf eine Änderung verzichtet.

Die Verknüpfungen zwischen den Tabellen fehlten in der Ursprungsversion der Beispieldatenbank vollständig. Sie werden in den Kapiteln Fremdschlüssel-Beziehungen besprochen und in Änderung der Datenbankstruktur eingebaut.

Fehlende Spalten und Einschränkungen

Neben den bereits genannten Punkten sind weitere Spalten sinnvoll bzw. notwendig:

• Tabelle Versicherungsvertrag: Basisprämie, Prämiensatz, letzte Änderung des Prämiensatzes
• Tabelle Zuordnung_SC_FZ: Anteil am Verschulden
• Tabellen Versicherungsnehmer und Mitarbeiter: Geschlecht m/w wegen der Anrede in Briefen

Viele Einschränkungen fehlen in der ursprünglichen Version:

• Spalten, deren Werte eindeutig sein müssen
• Spalten, deren Werte nur bestimmte Werte annehmen dürfen
• Tabellen, bei denen Spaltenwerte in gewisser Beziehung stehen müssen

Diese Änderungen werden in DDL - Einzelheiten besprochen und in Änderung der Datenbankstruktur eingebaut.

---

Lizenz

---