13.1.4 Datenbanktheorie


Computerprogramme/Apps erzeugen Daten und stellen auf der Basis von Daten Informationen dar. Diese Daten werden oft im Computersystem gespeichert. Für die Speicherung gibt es verschiedene Möglichkeiten:

  • die Daten werden in binären Dateien gespeichert, die zu einem bestimmten Programm gehören und nur von diesem gelesen werden können (proprietäre dokumentbasierte Datenspeicherung)
  • die Daten werden in Textdateien gespeichert, die von vielen verschiedenen Programmen gelesen werden können (offene dokumentbasierte Datenspeicherung)
  • die Daten werden in einer relationalen Datenbank gespeichert, wobei die Datenbank von einem speziellen Datanbankmanagementsystem verwaltet wird (Access, Mysql, SQLite,...)
  • die Daten werden in einer objektorientierten Datenbank gespeichert, in welcher Daten und Operationen zur Bearbeitung der Daten gleichzeitig in einem Objekt gespeichert werden. Die Objekte werden von einem objektorientierten Datenbank-Managementsystem verwaltet (z.B. Realm, ZODB, ...)
  • die Daten werden in einem objektrelationalen Datenbanksystem gespeichert, bei dem eine relationale Datenbank um Konzepte der Objektorientierung erweitert wird (z.B. IBM Db2, Oracle Database, Microsoft SQL Server,...).

Bei der Datenspeicherung von Daten für Internetseiten werden heute vorallem:

  • für kleinere Projekte die offene dokumentbasierte Datenspeicherung
  • für größere Projekte die relationalen Datenbanken verwendet

Content-Management-Systeme (CMS) für Webseiten mit dokumentbasierter Datenspeicherung sind z.B.:

Content-Management-System (CMS) für Webseiten mit relationaler Datenbank sind z.B.:

In diesem Kurs beschäftigen wir uns mit dem relationalen Datenbankmodell. Zu den anderen Modellen finden Sie umfassendes Material im Internet.

Bei einem relationalen Datenbankmodell werden Daten in Tabellen (z.B. Kunden) gespeichert. Eine Tabelle besteht aus Attributen (z.B. Kundennummer, Vorname, Nachname, Email). Ein mit Daten befüllter Eintrag in der Tabelle wird als Datensatz bezeichnet. Ein mit Daten befülltes Attribut ist eine Tabellen-Spalte.

Ein Attribut einer Tabelle wird Schlüssel genannt, wenn dieses Attribut für jeden eingetragenen Datensatz eindeutig ist. Ein Schlüsselattribut kann als Primärschlüssel festgelegt werden, wenn eine Relation mit Hilfe dieses Schlüssels zu einer anderen Tabelle festgelegt werden soll.

Eine relationale Datenbank wird mit Hilfe der Datenbanksprache SQL (Structured Query Language) eingerichtet. Mit SQL werden Daten eingetragen und gelöscht oder Daten abgefragt. Eine einfache Abfrage von Daten erfolgt mit SQL z.B. nach folgendem Schema:

    SELECT attribut01 FROM tabelle01 WHERE attribut01 = wert01;

Auf deutsch: Wähle alle Datensätze aus der tabelle01 für die gelten, dass das attribut01 den Wert wert01 hat.

Daten aus mehreren Tabellen, die über einen Primärschlüssel verbunden sind, können wie folgt abgefragt werden:

SELECT tabelle01.attribut01, tabelle01.attribut02, tabelle02.attribut01
FROM tabelle01 JOIN tabelle02 
ON tabelle01.primaerschluessel = tabelle02.fremdschluessel
WHERE tabelle01.attribut02 = wert01

Solche Verbundabfragen haben Sie bereits in den letzten Kapiteln geübt.

Eine Datenbank kann auf unterschiedliche Weisen entworfen werden:

  • Man erstellt möglichst wenige große Tabellen, in denen jeweils möglichst viele Informationen enthalten sind
  • Man erstellt viele Tabellen, in denen jeweils nur solche Informationen enthalten sind, die untrennbar verbunden sind und verbindet die Tabellen über Primärschlüssel und Fremdschlüssel

Beide Ansätze haben Vor- und Nachteile:

  • Bei großen Tabellen mit vielen Informationen kann man mit relativ einfachen SQL-Abfragen die gewünschten Informationen herausfiltern. Das Einfügen, Verändern und Löschen von Daten kann aber viele Probleme erzeugen: unvollständige Datensätze, widersprüchliche Daten, unerwünschter Datenverlust.
  • Bei einer Vielzahl kleiner Tabellen ist die Datenpflege leichter, aber der Entwurf der Datenbank komplizierter und die SQL-Abfragen gewünschter Daten deutlich komplexer.

In der Praxis wird eine gesunde Mischung zwischen Anzahl von Tabellen und Umfang der Tabellen gesucht.

Bei der Bearbeitung von Datenbanken kann es zu Datenbank-Anomalien kommen. Datenbank-Anomalien sind Zustände in Datenbanken, bei denen Daten verlorengegangen sind, Daten widersprüchlich sind oder Daten unvollständig sind.

Bei einer Einfüge-Anomalie wird ein unvollständiger Datensatz in eine Tabelle eingefügt. Bei zukünftigen Abfragen kann es Probleme geben, da nicht alle Attribute Daten bereithalten. Ein Beispiel:

In der Datenbank eines Onlineshops gibt es eine Tabelle "VerkaufsVorgaenge":

Datum KundenNr Name Wohnort ProduktNr Produkt Menge
01.05.20 KN012 Hans Muster Berlin PN002 Bio-Karotten 2 kg
01.07.20 KN014 Doris Musterine Potsdam PN005 Bio-Rettich 2 Stück
02.07.20 KN003 Peter Biofan Berlin PN003 Bio-Nudeln 3 Packungen

Gerade ist viel los und am Verkaufs-PC wird von Paul Bioman in der Kassensoftware ein neuer Datensatz eingefügt, ohne dass er die Kundendaten angibt. Die Kassensoftware generiert dazu folgenden SQL-Befehl:

INSERT INTO VerkaufsVorgaenge(ProduktNr, Produkt, Menge) VALUES ('PN102', 'Bio-Reis', '4 Packungen');

Die Datenbank sieht dann wie folgt aus:

Datum KundenNr Name Wohnort ProduktNr Produkt Menge
01.05.20 KN012 Hans Muster Berlin PN002 Bio-Karotten 2 kg
01.07.20 KN014 Doris Musterine Potsdam PN005 Bio-Rettich 2 Stück
02.07.20 KN003 Peter Biofan Berlin PN003 Bio-Nudeln 3 Packungen
02.07.20 PN102 Bio-Reis 4 Packungen

In der Tabelle "VerkaufsVorgaenge" gibt es jetzt einen Datensatz der leere Attribute enthält. Bei zukünftigen Abfragen kann man den Verkauf keinem Kunden zuordnen. Eine solche Anomalie kann verhindert werden, indem in der Datenbank allen Attributen, die bei jedem Verkaufsvorgang eingegeben werden müssen, die Eigenschaft "NN = Not Null" zugeordnet wird. Damit weigert sich die Kassensoftware einen Verkaufsvorgang anzunehmen, wenn Daten fehlen.

Die Stammkundin "Doris Musterine" hat geheiratet und ihren Namen geändert. Von ihr gibt es folgende Datensätze in der Tabelle "VerkaufsVorgaenge":

Datum KundenNr Name Wohnort ProduktNr Produkt Menge
01.07.20 KN014 Doris Musterine Potsdam PN005 Bio-Rettich 2 Stück
02.07.20 KN014 Doris Musterine Potsdam PN002 Bio-Karotten 1 kg
03.07.20 KN014 Doris Musterine Potsdam PN003 Bio-Nudeln 1 Packung

Beim nächsten Einkauf in Ihrem Lieblingsbioladen teilt Sie die Namensänderung Paul Bioman mit. Der ändert daraufhin Ihren Namen und erinnert sich an den Einkauf von letzter Woche und ändert auch dort den Namen. Da er davor aber Urlaub hatte, vergisst er, die Einkäufe davor zu ändern:

INSERT INTO VerkaufsVorgaenge(Datum, KundenNr, Name, Wohnort, ProduktNr, Produkt, Menge) 
VALUES ('12.07.20', 'KN014', 'Doris Frischverheiratet', 'Potsdam', 'PN102', 'Bio-Honig', '1 Glas');
UPDATE VerkaufsVorgaenge SET Name='Doris Frischverheiratet' WHERE KundenNr='KN014' AND Datum='03.07.20';

Die Datensätze in der Tabelle "VerkaufsVorgaenge" von Doris sehen dann wie folgt aus:

Datum KundenNr Name Wohnort ProduktNr Produkt Menge
01.07.20 KN014 Doris Musterine Potsdam PN005 Bio-Rettich 2 Stück
02.07.20 KN014 Doris Musterine Potsdam PN002 Bio-Karotten 1 kg
03.07.20 KN014 Doris Frischverheiratet Potsdam PN003 Bio-Nudeln 1 Packung
12.07.20 KN014 Doris Frischverheiratet Potsdam PN102 Bio-Honig 1 Glas

In der Tabelle "VerkaufsVorgaenge" gibt es jetzt Datensätze mit gleicher Kundennummer aber unterschiedlichem Namen. Die Datenbank ist inkonsistent, enthält also widersprüchliche Datensätze. Um solche Inkonsistenzen zu verhindern, müssten die ProgrammiererInnen die Kassensoftware so geschrieben haben, dass bei jeder Änderung die gesamte Datenbank durchsucht wird, um alle zu ändernden Datensätze zu finden.

In der Tabelle "VerkaufsVorgaenge" sollen alte Verkaufsvorgänge gelöscht werden, um die Datenbank schlank zu halten:

Datum KundenNr Name Wohnort ProduktNr Produkt Menge
01.05.20 KN012 Hans Muster Berlin PN002 Bio-Karotten 2 kg
01.07.20 KN014 Doris Musterine Potsdam PN005 Bio-Rettich 2 Stück
02.07.20 KN003 Peter Biofan Berlin PN003 Bio-Nudeln 3 Packungen

Mit folgenden Befehl werden alle Datensätze vor Juni gelöscht:

DELETE FROM VerkaufsVorgaenge WHERE Datum < DATE '01.06.2020'

Die Tabelle "VerkaufsVorgaenge" sieht dann wie folgt aus:

Datum KundenNr Name Wohnort ProduktNr Produkt Menge
01.07.20 KN014 Doris Musterine Potsdam PN005 Bio-Rettich 2 Stück
02.07.20 KN003 Peter Biofan Berlin PN003 Bio-Nudeln 3 Packungen

Da "Hans Muster" nur ein einziges Mal eingekauft hat, sind seine Kundendaten verloren gegangen. Die nächste Werbepost wird ihn daher nicht erreichen.

Das Löschproblem kann man verhindern, indem man die Datenbank so aufbaut, dass die Kundendaten in einer eigenen Tabelle stehen und über einen Fremdschlüssel mit den Verkaufsvorgängen verknüpft werden. Löscht man alle Verkaufsvorgänge, würden die Kundendaten immer noch in der Kundentabelle stehen.

Viele Datenbankprobleme lassen sich vermeiden, wenn eine Datenbank eine sinnvolle Anzahl von Tabellen enthält, die über Fremdschlüssel miteinander verbunden werden. Die Normalisierung von Datenbank beschäftigt sich mit der Frage, was eine sinnvolle Anzahl von Tabellen ist, wie die Daten einer Datenbank also sinnvoll auf Tabellen verteilt werden sollen. Das wird im nächsten Kapitel behandelt.