SQL Server 2016 (eBook)

2.2    Relationale Datenbanken

Das Modell einer relationalen Datenbank wurde erstmals 1970 von Dr. Edgar Frank Codd (1923–2003) in seinem Artikel »A Relational Model of Data for Large Shared Data Banks« veröffentlicht.

Mit diesem Artikel löste Codd eine der tiefstgreifenden Veränderungen in der Datenverarbeitung aus: den Übergang zu den relationalen Datenbanken.

Die ersten für Computer entwickelten Datenbanken unterschieden sich in ihrer Struktur grundlegend von der Struktur heutiger Datenbanksysteme. Eine der ersten Lösungen, Daten auf einem Computer zugänglich zu machen, beruhte auf der sequenziellen Speicherung der Daten in Textdateien. In der weiteren Entwicklung wurde der Ansatz verfolgt, die Daten in einer hierarchischen Struktur abzulegen. Abbildung 2.1 zeigt ein Beispiel für den Aufbau einer solchen Datenbank. Um einen Datensatz zu finden, musste eine Baumstruktur durchlaufen werden, an deren Ende der gesuchte Datensatz stand.

Abbildung 2.1    Prinzipieller Aufbau erster Datenbanklösungen

Codds Arbeit hingegen basiert auf einem wissenschaftlichen Ansatz, in dem er die Verwaltung von Daten durch mathematische Methoden der Mengenlehre beschreibt. Im Zusammenhang mit relationalen Datenbanken werden daher häufig die aus der Mengenlehre stammenden Fachbegriffe verwendet. Diese etwas »akademisch« klingenden Begriffe sind sicherlich ein Grund dafür, dass bei vielen Leuten immer noch eine hohe Hemmschwelle vor der Beschäftigung mit Datenbanken besteht. Einige dieser Fachbegriffe erwähnen und erklären wir weiter unten, da sie in anderen Publikationen verwendet werden. In diesem Buch verwenden wir – soweit es möglich ist – allgemein verständliche Bezeichnungen. Für manche Fachbegriffe gibt es jedoch kein Synonym, sodass diese dann im Buch Verwendung finden.

Was aber versteht man nun genau unter einer relationalen Datenbank?

Relationale Datenbanken arbeiten nach einem völlig anderen Prinzip als die oben beschriebenen Ansätze. Das wesentlichste Merkmal einer relationalen Datenbank besteht darin, dass die Daten in zueinander in Beziehung stehenden Tabellen (den sogenannten Relationen) abgelegt werden (siehe Abbildung 2.2). Auf welche Weise die Tabellen einer relationalen Datenbank zueinander in Beziehung gesetzt werden, behandeln wir in Abschnitt 2.2.3, »Schlüssel«.

Abbildung 2.2    Schematischer Aufbau einer relationalen Datenbank

Die Aufteilung von Daten in zueinander in Beziehung stehende Tabellen ermöglicht eine sehr strukturierte Speicherung von Daten, da in eine Tabelle immer nur Informationen über eine Art von Objekten abgelegt werden sollten, wobei es sich bei diesen Objekten sowohl um reale Dinge wie z. B. Personen oder Fahrzeuge als auch um abstrakte Dinge wie beispielsweise Verleihvorgänge handeln kann.

Diese Art der Speicherung erfüllt einen weiteren wesentlichen Zweck: die Vermeidung von Redundanz. Dieser Begriff bezeichnet im Kontext von Datenbanken die mehrfache Speicherung der gleichen Information. Redundanz bedeutet nicht nur den unnötigen Verbrauch von Speicherplatz, sondern kann bei ihrem Vorhandensein innerhalb einer Datenbank ernsthafte Probleme verursachen, wie das folgende Beispiel aus der Praxis deutlich machen soll.

In vielen Firmen werden die Daten der Mitarbeiter an mehreren Stellen erfasst. Die Buchhaltung verfügt über ein eigenes Programm zur Gehaltsabrechnung mit den Daten der Mitarbeiter, die Abteilungsleiter haben die Daten der Mitarbeiter ihrer Abteilung ebenfalls erfasst, und der Betriebsrat pflegt eine eigene Excel-Tabelle dieser Daten. Bereits bei dieser Speicherung von Daten an nur drei verschiedenen Stellen stellt man bei einer Überprüfung schnell fest, dass die Daten in den seltensten Fällen untereinander abgeglichen sind: Die neue Adresse eines Mitarbeiters wurde nach seinem Umzug nicht in allen drei Datenbeständen geändert, schon lange ausgeschiedene Mitarbeiter wurden nicht gelöscht und so weiter.

Übertragen auf eine Datenbank, entspräche dieses Beispiel der Tatsache, dass die Mitarbeiterinformationen dreimal innerhalb einer Datenbank abgespeichert worden wären, beispielsweise in verschiedenen Tabellen. Als Konsequenz daraus ergäbe sich die Tatsache, dass je nachdem, welche Tabelle zur Abfrage herangezogen wird, unterschiedliche Informationen zu einem Mitarbeiter zurückgeliefert würden, eben in Abhängigkeit davon, ob ein aktueller oder veralteter Datensatz als Quelle der Information diente. Mit anderen Worten: Die Korrektheit und Verlässlichkeit der Daten, die auch als Datenintegrität bezeichnet wird, wäre nicht mehr gewährleistet. Eine Datenbank, die nur zufällig korrekte Informationen ausgibt, ist aber praktisch wertlos.

Natürlich ist mit der Datenintegrität nicht die absolute Fehlerfreiheit von Daten gemeint: Zwar können Daten während der Eingabe von modernen Datenbanksystemen auf bestimmte Fehler hin überprüft werden, einen Schutz vor Schreibfehlern bei der Eingabe z. B. eines Vor- oder Nachnamens kann auch das beste Datenbanksystem nicht bieten.

Das Beispiel der dreifach erfassten Datensätze macht deutlich, welche Bedeutung die Vermeidung von Redundanz in Bezug auf die Datenintegrität hat: Wird Redundanz vermieden, also eine Information immer nur einmal an einer Stelle innerhalb der Datenbank gespeichert, entspricht diese Information immer dem letzten, aktuellsten Stand. Die Vermeidung von Redundanz sollte daher bei einem Datenbankentwurf – wie wir ihn in Kapitel 3, »Logischer Datenbankentwurf«, beschreiben – immer einen wichtigen Gesichtspunkt darstellen. Die Datenbanktheorie stellt Methoden und Hilfsmittel zur Verfügung, um dieses Ziel zu erreichen.

Nachdem wir den Zusammenhang zwischen dem Vorhandensein von Redundanz und der möglichen Auswirkung auf die Datenintegrität beschrieben haben, soll nun noch eine – in der praktischen Arbeit mit Datenbanken häufig gestellte – Frage beantwortet werden: Wann genau liegt Redundanz innerhalb einer Datenbank vor? Gerade bei der ersten Beschäftigung mit Datenbanken sorgt dieser Begriff immer wieder für Irritationen. Stellt schon die mehrfache Nennung eines Eintrags – des Wohnorts, der Steuerklasse und so weiter – bei den verschiedenen Datensätzen einer Tabelle schon Redundanz dar oder nicht? Die folgende Anmerkung soll diesen Aspekt erläutern:

Auch wenn die Vermeidung von Redundanz ein Hauptmerkmal des Entwurfs von relationalen Datenbanken darstellt, so ist das Auftreten von Redundanzen nicht immer zu vermeiden. Innerhalb einer Firma könnten z. B. zwei oder mehrere Datenbanken Verwendung finden, deren Datenbestand sich teilweise überschneidet.

In diesem Fall muss sichergestellt sein, dass Änderungen von Datensätzen in der einen Datenbank auch auf die anderen redundanten Datensätze anderer Datenbanken übertragen werden. Man bezeichnet diesen Sachverhalt als die Wahrung der Datenkonsistenz.

2.2.1    Struktureller Aufbau von Tabellen

Da Tabellen die elementaren Bestandteile von relationalen Datenbanken darstellen, sollen anhand von Abbildung 2.3 einige mit Tabellen in Zusammenhang stehende Begriffe erklärt werden.

Abbildung 2.3    Ausschnitt aus der Tabelle »Product«

Dargestellt ist der Auszug einer Tabelle aus der Beispieldatenbank AdventureWorks2016CTP3. Diese Beispieldatenbank bildet die Vorgänge innerhalb einer Firma ab, die sich mit der Herstellung von Fahrrädern beschäftigt. Die abgebildete Tabelle enthält Informationen über Produkte, die von dem Fahrradhersteller eingekauft und verkauft werden.

Wie Sie erkennen, besteht eine Tabelle innerhalb einer relationalen Datenbank aus einer zweidimensionalen Struktur von Spalten und Zeilen, wobei jede Zeile innerhalb einer Tabelle einen Datensatz darstellt. Der grundsätzliche strukturelle Aufbau von Tabellen innerhalb einer relationalen Datenbank kann – vereinfacht – durch die folgenden Punkte beschrieben werden:

• Tabellenname
  Jede Tabelle muss über einen eindeutigen Namen verfügen, unter dem sie anzusprechen ist. Dieser Name wird im Datenbankkontext auch Bezeichner genannt.
• Spaltenname
  Die Spalten einer Tabelle müssen ebenfalls über eine...