Einführung Datenbanken

Grundlegende Begriffe

 

Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte (Zahlen, Text, Datümer, …) eintragen kann. Diese Zellen sind in Spalten und Zeilen organisiert.

Wenn man sich jetzt in Excel eine einfache Adressverwaltung aufbauen möchte, würde man vermutlich in verschiedene Spalten diverse Daten schreiben, z.B.:

  • Vorname
  • Nachname
  • Strasse
  • PLZ
  • Ort

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

Vorname Nachname Strasse PLZ Ort
Hugo Schmidt Sylter Weg 15 24145 Kiel
Bert Meier Schanzenstraße 1 20357 Hamburg
Egon Müller Exerzierplatz 3 24103 Kiel
Ivonne Müller Oldendorfer Weg 22 25524 Itzehoe

Damit haben wir eine Adresstabelle erstellt. Im Bereich der Datenbanken gibt es auch Tabellen, sog. Datenbanktabellen. Jede Tabelle besteht aus mehreren Spalten, die verschiedene Daten speichern. In den Zeilen sind dann die Datensätze. Ein Datensatz beinhaltet alle Spalten, die zusammen gehören. Im obigen Beispiel also alle Daten zu einer Adresse. In Tabellen werden je nach Anwendungszweck unterschiedlichste Daten gespeichert.

In der Praxis benötigt man dann auch in der Regel mehr als eine Tabelle (in Excel ja auch), z.B. eine für Kunden, eine für verkaufte Produkte und eine für die Rechnungen.  Alle drei Tabellen zusammen werden vielleicht benötigt, um die Auftragsabrechnung eines Pizzalieferdienstes durchzuführen, aber sie beinhalten unterschiedliche Daten. Wenn man mehrere Tabellen zusammenfasst, spricht man von einer Datenbank. Diverse Datenbanken für unterschiedliche Anwendungsgebiete werden dann in einem Datenbankmanagementsystem (DBMS) verwaltet. Bekannte Vertreter sind hier z.B. Oracle, Microsoft SQL Server, IBM DB2.

Um die Daten in den Tabellen auslesen zu können, gibt es eine sogenannte Abfragesprache. Mit Hilfe diese Sprache kann man der Datenbank mitteilen, welche Datensätze man benötigt. Im Falle der Adresse möchte man vielleicht nur die Adresse von Hugo Schmidt wissen, um ihm eine Rechnung zu schreiben. Das kann man dann mit Hilfe der Structured Query Language (SQL) machen. Ein einfaches Beispiel sähe so aus:

SELECT *
FROM TBL_ADRESSEN
WHERE Nachname=‘Schmidt‘

Dadurch würde man alle Spalten der Datensätze, bei denen der Nachname ‚Schmidt‘ ist zurück geliefert bekommen. Der Vorteil einer solchen Sprache ergibt sich vor allem bei Tabellen mit mehreren Millionen Datensätzen oder wenn man mehrere Tabellen zusammen abfragt (dazu in späteren Kapiteln mehr). Damit haben wir in diesem Kurs unser allererstes SQL verwendet. Viele weitere werden noch folgen. 😉

Neben SQL als Abfragesprache gibt es noch die Data Definition Language (DDL) und die Data Manipulation Language (DML). Mit Hilfe der DDL wird die Struktur der Datenbank erstellt, d.h. die Tabellen und ihre Strukturen. Darüber hinaus gibt es noch zahlreiche weitere Objekte in einer Datenbank (Views, Indizes, …), auf die in diesem Kurs aber nur am Rande eingegangen werden kann. Die DML dient dazu, die Tabellen mit Daten zu füllen bzw. diese zu ändern oder zu löschen.

 

Beziehungen zwischen Tabellen

 

In den meisten Datenbanken gibt es diverse Tabellen, um die Daten zu strukturieren und Redundanzen zu vermeiden (siehe auch Kapitel über Normalisierung).

Die verschiedenen Tabellen stehen dabei in Beziehung zueinander. Wenn man z.B. die Kunden in einer Tabelle hat und die Bestellungen in einer anderen, dann würde man in der Bestellungen-Tabelle nur noch die Kunden-Nr. ablegen und nicht die gesamten Informationen zu einem Kunden. Dadurch dass man diese Kunden-Nr. auch in der Kunden-Tabelle hat, kann man beide Tabellen in Beziehung setzen. Alle Daten zu einem Kunden (z.B. seine Adresse und Telefon-Nr.) werden nur in der Kunden-Tabelle gepflegt und nicht mehrfach in der Datenbank abgelegt. Mittels SQL kann man dann z.B. ermitteln, wie viele Bestellungen ich mit Kunden aus eine bestimmten Ort gemacht habe, einfach indem man die Kunden-Tabelle (mit dem Wohnort) und die Bestellungs-Tabelle miteinander verknüpft. Wenn sich jetzt die Adresse ändert, muss diese nur an einer einzigen Stelle angepasst werden.

In einem ER-Modell (ER = Entity Relationship) werden die Tabellen mit ihren Spalten und Beziehungen untereinander dargestellt. Ein solches Modell sieht z.B. wie folgende aus:

 ABB_01_Einfaches_ER_Modell

 

 

Abb.1: Einfaches ER – Modell

 

Die Beziehungen oder Verknüpfungen zwischen Tabellen erfolgen über sog. Schlüssel. Man unterscheidet dabei zwischen Primär- und Fremd-Schlüsseln. Primärschlüssel identifizieren einen Datensatz einer Tabelle eindeutig. Im Falle der Kunden-Tabelle wäre das z.B. die Kunden-Nr. Dort sieht man in der Abbildung auch ein „P“, was den Primärschlüssel kennzeichnet. Ein Fremdschlüssel stellt einen Verweis auf den Primärschlüssel einer anderen Tabelle dar (gekennzeichnet durch „F“ in der obigen Abbildung), d.h. welcher Datensatz aus der anderen Tabelle mit dem der aktuellen verknüpft wird. Oder in unserem Beispiel: Welcher Kunden-Datensatz (Primär-Schlüssel) mit welcher Bestellung verknüpft (über den Fremd-Schlüssel) wird. Beziehungen werden also immer über die Kombination eines Fremd-Schlüssels mit einem Primär-Schlüssel definiert.

Je nachdem wie die Verhältnisse zwischen den Tabellen sind, unterscheidet man verschiedene Arten von Beziehungen:

  1. 1:1 – Beziehung
  2. 1:n – Beziehung
  3. N:m – Beziehung
  4. Rekursive Beziehungen

Bei der 1:1 Beziehung existiert genau ein Datensatz in der Fremd-Tabelle zu jedem Datensatz in der Haupt-Tabelle und umgekehrt. Bei der 1:n Beziehung existiert zu jedem Datensatz in der Fremd-Tabelle 1 bis n Datensätze in der Haupttabelle. Und zu jedem Datensatz in der Haupttabelle existiert genau 1 Datensatz in der Fremdtabelle. Diesen Fall trifft man in der Praxis am häufigsten an. In unserem Beispiel existiert eine 1:n Beziehung zwischen Kunden und Bestellungen. Jeder Kunde kann mehrfach in den Bestellungen auftauchen. Zu jeder Bestellung existiert genau 1 Kunde. N:m Beziehungen bedeuten dann, dass zu jedem Datensatz in der einen Tabelle n Datensätze in der anderen Tabelle gehören. In relationalen Datenbanken kann dieser Umstand nur durch eine Zwischentabelle modelliert werden.

Man kann in den meisten DBMS einstellen, dass die referentielle Integrität vom System sichergestellt wird. Das bedeutet, dass zu einem Fremdschlüssel immer der entsprechende Datensatz in der referenzierten Tabelle existieren muss. Es wäre dann z.B. nicht möglich diesen Datensatz in der Fremd-Tabelle zu löschen, solange auf diesen in irgendeinem anderen Datensatz referenziert wird. Wenn man natürlich alle diese Datensätze zuerst löscht, dann kann auch der Satz in der Fremdtabelle gelöscht werden. Umgekehrt gilt das Gleiche. Man müsste erst diesen Satz in der Fremdtabelle erzeugen, damit man von anderen Tabellen auf diesen Datensatz referenzieren kann.

Um die referentielle Integrität vom DBMS ständig prüfen zu lassen, muss man sog. Foreign Key Constraints einrichten. Das ist nichts anderes als die Definition der Fremd-Schlüssel-Beziehung zwischen zwei Tabellen auf Datenbank Ebene. Es gibt noch sog. Check-Constraints. Mit diesen kann sichergestellt werden, dass nur bestimmte Werte in bestimmte Spalten eingegeben werden können. Z.B. nur die Anreden ‚Herr‘ und ‚Frau‘ in die Spalte Anrede.

 

Normalformen

 

Damit Daten einfach und korrekt ausgewertet werden können, sollten diese immer folgende Eigenschaften haben:

  • redundanzfrei
  • eindeutig
  • in sich konsistent

Um diese Eigenschaften der Daten dauerhaft sicherzustellen, gibt es bestimmte Regeln, die in Datenmodellen eingehalten werden sollen. Das sind die sog. Normalformen. Es gibt 5 Normalformen, die jeweils bestimmte Redundanzen, die in den Daten durch das Datenmodell entstehen können, beseitigen. In der Praxis sind vor allem die ersten drei Normalformen relevant. Diese werden im Folgenden detailliert beschrieben.

Als Beispiel dient uns folgende Tabelle mit Kontakt-Informationen:ABB_02_Bsp_Kunde_Ausgangslage

 

 

 

 

 

Abb.2: Bsp. Kundendaten – Ausgangslage

Eine Tabelle befindet sich in der 1. Normalform, wenn es keine Wiederholungsgruppen innerhalb der Tabelle gibt und jedes Attribut atomar (nicht in weitere Attribute aufteilbar) ist.

Auf unser Beispiel angewendet bedeutet das, dass es z.B. kein Attribut „Adresse“ geben kann, da dieses in Strasse, PLZ und Ort aufgeteilt werden kann (Atomarität). Wenn es dann noch mehrere Telefonnummern zu einem Kontakt geben kann, dann dürfen diese nicht in einem Feld Telefonnummer gespeichert werden (Wiederholungsgruppe) und auch nicht in Feldern Telefonnummer1 … TelefonnummerX (Wiederholungsgruppe), sondern es könnte ein Attribut TELEFONNUMMER ergänzt werden und dieses ist Teil des Schlüssels (Zusammengesetzt aus KONTAKT_NR und TELEFONNUMMER).

ABB_03_Bsp_Kunde_1_NF

 

 

 

 

 

 

 

Abb.3: Bsp. Kundendaten – 1. Normalform

Durch Sicherstellung der 1. NF werden Daten überhaupt erst auswertbar. Wenn man z.B. die Adresse komplett in einem Attribut ablegt, wäre es schwierig bis unmöglich z.B. nach Ort zu sortieren und zu filtern.

Die 2. Normalform ist gegeben, wenn die Tabelle in 1. NF vorliegt und jedes Nicht-Schlüsselfeld vom gesamten Schlüssel abhängt und nicht nur von Teilen des Schlüssels. Dadurch ist sichergestellt, dass nur zusammengehörige Daten in einer Tabelle vorliegen. Außerdem werden Inkonsistenten vermieden, da Attribute nur einmalig vorkommen können.

Für unser Beispiel bedeutet das, dass NAME, STRASSE, ORT, GESCHLECHT und ANREDE nur von der KONTAKT_NR abhängen, jedoch nicht von der TELEFONNUMMER. Bei Anlage mehrere Telefonnummern zu einem Kontakt, würden die Kontakt-Informationen redundant in der Tabelle vorkommen, was 1. Speicherplatz verbraucht (heute nicht mehr das große Problem) und 2. Zu Inkonsistenzen führen kann. Man würde jetzt eine zusätzliche Tabelle mit den Telefonnummern erstellen. ABB_04_Bsp_Kunde_2_NF

Abb.4: Bsp. Kundendaten – 2. Normalform

Zur Einhaltung der 3. Normalform, muss eine Tabelle in 2. NF vorliegen und Nicht-Schlüsselfelder dürfen nicht von anderen Nicht-Schlüsselfeldern abhängen. Durch die 3.NF werden weitere Redundanzen vermieden.

Das würde in unserem Beispiel bedeuten, dass man die Felder Ort und Anrede auslagern würde, weil der Ort von der PLZ abhängig ist und die Anrede vom Geschlecht. Auch dieses dient der Minimierung von Redundanzen, da diese zu Inkonsistenzen führen können. ABB_05_Bsp_Kunde_3_NF

 

Abb.5: Bsp. Kundendaten – 3. Normalform

Durch die Normalisierung erhöht sich die Anzahl der Tabelle in einem Datenmodell. Das führt u.U. dazu, dass Abfragen länger laufen, da die Tabellen miteinander verknüpft werden müssen. Wenn die Antwortzeiten zu lang werden, kann man Datenmodelle auch wieder denormalisieren. Dieses ist z.B. in Datawarehouse Umgebungen der Normalfall. Dort liegen die Tabellen im sog. Star-Schema vor.

 

Datenbanktransaktionen

 

Wenn Daten in Tabellen eingefügt oder verändert werden, muss sichergestellt werden, dass der Datenbestand hinterher auch noch in einer konsistenten Form vorliegt. Dazu existiert ein Paradigma im Datenbankbereich, welches ACID heißt:

  • Atomicity
  • Consistancy
  • Isolation
  • Durability

 

Dieses bedeutet, dass Datenänderungen so durchgeführt werden, dass sie atomar ausgeführt werden, d.h. dass ein Satz von Operationen ganz oder gar nicht ausgeführt wird. Weiterhin muss gewährleistet sein, dass nach der Ausführung, der Datenbestand weiterhin in sich konsistent ist (so lange er es vorher auch schon war). Die Änderungen sollen isoliert durchgeführt werden, so dass sich verschiedene Operationen nicht gegenseitig beeinfluss (z.B. gleichzeitiges löschen und lesen eines Datensatzes). Die geänderten Daten müssen dauerhaft gespeichert werden zum Abschluss.

Damit all dieses sichergestellt ist, gibt es sogenannte Transaktionen in modernen DBMS. Eine Transaktion stellt eine Klammer um eine oder mehrere DML (Insert, Update, Delete) – Anweisungen dar und wir als Block behandelt. Erst wenn alle Einzelanweisungen erfolgreich durchgeführt werden, wird das Ergebnis physisch festgeschrieben. Am Ende einer Transaktion kann diese entweder festgeschrieben werden mittels COMMIT oder zurückabgewickelt werden mittels ROLLBACK. Die Datenänderungen werden erst nach erfolgtem COMMIT sichtbar.

 

Falls Sie nun Interesse haben, Grundlagen der Datenbanken und der SQL Abfragen in einer Schulung zu vertiefen, sollten Sie sich mal meine SQL Grundlagen Schulung anschauen!