Teil 1:Grundlagen des Datenbankentwurfs, ER-Modell, Normalisierung

Datenbanken: Grundlagen und Entwurf
Kommentare

Ein Datenbanksystem ist Bestandteil fast jeder betriebswirtschaftlichen Anwendung. Für die Konzeption dieser Anwendungen ist es notwendig, über ausreichende Kenntnisse im Entwurf von Datenbanken zu verfügen. Die Vermittlung der Grundlagen erfolgte meist im Studium oder in der Ausbildung und wurde vielleicht durch Seminare und Kurse aufgefrischt. Der Gesamtzusammenhang kann dabei leicht verloren gehen. Stichworte sind: relationale Datenbank, Normalisierung, ER-Modell und SQL.

Bei der Entwicklung von Software ist meist auch ein Datenbanksystem zu integrieren. Dabei kann im Idealfall auf eine bestehende Datenbank zurückgegriffen werden und es ist nur die Anbindung zu dieser zu realisieren. Anderseits kann es auch zum Auftragsumfang gehören, die Datenbank vom ersten Schritt an aufzubauen. In beiden Fällen sind Kenntnisse im Datenbankdesign notwendig. Wie so oft lautet das Motto, nicht unmittelbar mit dem Anlegen der Tabellen zu beginnen, sondern erst mal in Ruhe mit Bleistift und Papier ein Konzept zu entwerfen (wer es lieber am Rechner machen will, das geht natürlich auch). Wir versuchen, Ihnen in einer vierteiligen Artikelserie das notwendige Handwerkszeug zu vermitteln. Für den Neueinsteiger ist es ein guter Leitfaden, um sich das Wissen anzueignen, für den erfahrenen Entwickler die Chance, die eine oder andere Lücke zu schließen. Beginnen wir mit einem Überblick über die Phasen der Datenbankentwicklung.

Überblick über die Artikelserie
Teil 1: Theorie des Datenbankentwurfs: relationales Datenmodell, ER-Modell, und Normalisierung.
Teil 2: Kompakte Übersicht zu den Grundoperationen: Datenbankdefinition, Datensätze einfügen/ändern/löschen
Teil 3: Erweiterte Techniken: Definition von Datensichten, Transaktion, Benutzer- und Sicherheitsaspekte umsetzen
Teil 4: Ein praxisorientierter Beitrag, der gängige Datenbanksysteme genauer beleuchtet

Phasen der Datenbankentwicklung

Der Aufbau einer Datenbank gelingt nicht in einem Schritt. Dazu müssen mehrere Phasen durchlaufen werden (Abb. 1):

  • Externe Phase: Ermittlung der Informationsstruktur: Die Datenbank soll einen Ausschnitt aus der realen Welt (auch als „Miniwelt“ bezeichnet) im Rechner abbilden. Diese Abbildung erfolgt durch die Beschreibung der Daten. Dazu ist der Informationsbedarf der Benutzer zu ermitteln und zu strukturieren. Das Ergebnis dieses ersten Schrittes – auch als Spezifikations- und Anforderungsanalyse bezeichnet – ist eine informelle Beschreibung des Fachproblems.
  • Konzeptionelle Phase: Aufstellung des semantischen Modells: Ziel des konzeptionellen Entwurfs ist die formalisierte Beschreibung des betrachteten Sachverhalts. Es existieren verschiedene Ansätze zur Erzeugung einer solchen Gesamtsicht. Das bekannteste Modell ist das so genannte Entity Relationship Model (ER-Modell). Eine Erläuterung dieses ER-Modells folgt später. Das Ergebnis dieses Schrittes ist das Fachkonzept der Datenbank.
  • Logische Phase: Erstellung des logischen Datenmodells: Ziel ist die Übertragung des semantischen Datenmodells in ein logisches Datenmodell, z. B. in ein relationales Datenmodell (Tabellenform). Diese Phase umfasst zwei Schritte: Im ersten Schritt muss eine Transformation des konzeptionellen Schemas (ER-Modell) in das Datenbankschema erfolgen. Dieser Schritt ist mithilfe von Software automatisierbar. Im zweiten Schritt erfolgt eine Optimierung des relationalen Schemas, z. B. die Durchführung einer Normalisierung der Tabellenstruktur (Abschnitt: „Optimierung: Normalisierung des Datenmodells“).
  • Physische Phase: Implementierung der Datenbank: Am Ende dieser Phase sollte die leere Datenbank existieren. Dazu sollte das logische Modell unter Verwendung einer Datendefinitionssprache (z. B. SQL) in ein konkretes Datenbankschema übersetzt werden. Es müssen Datentypen, Wertebereiche, Relationen und Sichten festgelegt werden. 

Abb. 1: Phasen des Datenbankentwurfs

Exkurs: Auf den Typ kommt es an – (Standard-)Datentypen
Für jedes Attribut einer Tabelle ist der Datentyp zu spezifizieren. Die verfügbaren Datentypen unterscheiden sich zwischen den einzelnen Datenbanken. Daher kann eine vollständige Kompatibilität nicht gewährleistet werden. Dieses ist insbesondere bei einem Wechsel der Datenbank zu beachten. Es ist sicherzustellen, dass der Import von externen Daten nicht zu Datenverlust bzw. Fehlern in den Daten führt. Besonders aufmerksam ist der Datentransfer bei „nicht standardisierten“ Datentypen, um z. B. Datumswerten nachzuvollziehen. Tabelle 1 gibt einen Überblick über wichtige Datentypen, die eigentlich in jeder Datenbank verfügbar sind.

Tabelle 1: Wichtige Standarddatentypen, die in fast allen Datenbanken zur Verfügung stehen sollten

Aufmacherbild: database concept. vintage cabinet. library card or file catalog. von Shutterstock / Urheberrecht: Andrey_Kuzmin

[ header = Relationales Datenmodell ]

Relationales Datenmodell

Es exstieren verschiedene Datenmodelle (Abb. 2). Ausgangspunkt war das hierarchische Datenmodell, das heute wegen seiner beschränkten Anwendbarkeit kaum noch in Datenbankmanagementsystemen (DBMS) verwendet wird. Das Netzwerkmodell findet für umfangreiche Datenmengen im Großrechnerbereich seine Anwendung. Das am meisten verwendete Modell ist das relationale Datenmodell. Das relationale Modell basiert auf folgenden Elementen:

  • Tabellen (Relationen)
  • Operatoren, d. h. Rechenoperationen für Tabellen 
  • Regeln, d. h. Bedingungen für die Werte bestimmter Spalten

Abb. 2: Entwicklung der Datenbankmodelle [1]

Der Aufbau einer Tabelle für eine relationale Datenbank kann Abbildung 3 entnommen werden. Folgende Eigenschaften gelten für eine Relation [1]:

  1. Es tritt kein Tupel doppelt auf, d. h. zu keinem Zeitpunkt gibt es zwei Tupel, die den gleichen Wert haben.
  2. Die Tupel-Reihenfolge ist nicht definiert, d. h. man darf sich nicht auf eine bestimmte Reihenfolge der Zeilen der Tabelle verlassen.
  3. Die Attributreihenfolge ist nicht definiert (Reihenfolge der Spalten).
  4. Attributwerte sind atomar. Die Werte eines Attributs unterliegen einer Domäne, d. h. sie entstammen einem Wertebereich. Da alle Elemente einer Domäne atomar sind, gilt das auch für Attribute.

Abb. 3: Aufbau einer Datenbanktabelle (Relation) [2]

Die wichtigsten Operationen mit Relationen (relationale Algebra), die ein Datenbankmanagementsystem zur Verfügung stellen muss, sind Folgende:

  • Auswahl von Zeilen
  • Auswahl von Spalten
  • Aneinanderfügen von Tabellen 
  • Verbund von Tabellen

Beispielhaft wird das in Abbildung 4 erläutert. Regeln bzw. Integritätsbedingungen sorgen dafür, dass die Datenbank keine widersprüchlichen Daten enthält. Lokale Integritätsbedingungen gelten jeweils für eine Tabelle. Zum Beispiel gilt für den Primärschlüssel: Jeder Wert in dieser Spalte darf nur einmal vorkommen. Dagegen gelten globale Integritätsbedingungen (referenzielle Integrität) für mehrere Tabellen. Ein Beispiel für eine globale Integrität: Zu jedem Wert, der ein Fremdschlüssel in einer Tabelle ist, existiert genau ein Wert in einer weiteren Tabelle und ist dort Primärschlüssel (Abb. 5).

Abb. 4: Beispiele zur relationale Algebra [1]

Abb. 5: Ein Beispiel für referenzielle Integrität [1]

[ header = Das Entity Relationship Model (ER-Modell) ]

Das Entity Relationship Model (ER-Modell)

Das Schema, in dem man eine Datenbankstruktur konzipiert, nennt sich Entity Relationship Model (ER). In einem ER-Modell wird die grundlegende Tabellen- und Beziehungsstruktur einer Datenbank entworfen und abgebildet. Die Darstellung im ER-Modell (grafisch) und die Abbildung der Datenbankstruktur mithilfe von Tabellen sind einander äquivalent, d. h. eine gegenseitige Überführung ist möglich (und wird von Entwicklungsumgebungen auch automatisch durchgeführt). Um mit dem ER-Modell arbeiten zu können, sind einige Begriffe zu definieren:

  • Attribute (Eigenschaften): Dabei handelt es sich um die Felder eines Datensatzes. Im grafischen Modell werden die Eigenschaften als Rechtecke mit abgerundeten Ecken abgebildet.
  • Entität: Sehr einfach ausgedrückt, handelt es sich um ein Objekt der jeweiligen Tabelle, also um einen Datensatz. Die Entitäten unterscheiden sich untereinander durch unterschiedliche Werte der Eigenschaften. Die Abbildung erfolgt durch ein Rechteck. 
  • Entitätsmengen: Mehrere Entitäten mit gleichen Attributen (nicht Attributwerten) werden zu einer Entitätsmenge zusammengefasst. Eine Entitätsmenge entspricht einer Tabelle in der Datenbank.
  • Beziehungen: Die einzelnen Tabellen sind nicht losgelöst voneinander. Zwischen den Entitäten werden Verknüpfungen hergestellt. Eine Beziehung kann einem so genannten Beziehungstyp zugeordnet werden. Mittels Rauten, die mit den zugehörigen Entitäten verbunden werden, erfolgt die grafische Visualisierung im ER-Modell.

Die wichtigsten Beziehungstypen lauten: 1:1, 1:n und n:m-Beziehung:

  • 1:1-Beziehung: Es existiert für jeden Datensatz in Tabelle 1 genau ein Datensatz in Tabelle 2. Theoretisch weist diese Art von Beziehung darauf hin, dass die Tabellen zusammengeführt werden können. Dennoch können Gründe existieren, die eine 1:1-Beziehung rechtfertigen, beispielsweise Sicherheit und Performance. Sollen bestimmte Daten besonders vor dem Zugriff geschützt werden, können diese in eine eigene Tabelle ausgelagert werden. Ganze Tabellen lassen sich bezüglich der Benutzerrechte besser schützen als einzelne Tabellenspalten. Bei sehr großen Datenbanken kann es sinnvoll sein, weniger benutzte Daten auszulagern. Dieses steigert die Zugriffsgeschwindigkeit auf die restlichen Daten.
  • 1:n-Beziehung: Diese sind dadurch gekennzeichnet, dass zu einem Datensatz in der einen Tabelle beliebig viele (0…n) Datensätze in der anderen Tabelle existieren. Ein Beispiel: Die Beziehung zwischen den Tabellen Hörsaal und Studenten. In einem Hörsaal können kein (0), ein (1) oder mehrere (n) Studenten sein.
  • n:m-Beziehung: Jedem Datensatz aus Tabelle 1 sind 0..m Datensätze in der Tabelle 2 zugeordnet. Anderseits sind auch jedem Datensatz aus Tabelle 2 0..n Datensätze in Tabelle 1 zugeordnet. Wiederum ein Beispiel: Tabelle 1 umfasst die Angaben zu den Studenten und Tabelle 2 die Angaben zu den verfügbaren Kursen der Universität. Jeder Student kann seinerseits keinen, einen oder mehrere Kurse belegen. Anderseits können einem Kurs kein, ein oder mehrere Studenten zugeordnet sein. Derartige Beziehungen gilt es, unter Inanspruchnahme einer Hilfstabelle aufzulösen. 

Es gibt verschiedene Arten, wie Beziehungstypstypen in einem ER-Diagramm abgebildet werden. Die ursprüngliche Notation für ER-Modelle ist die Chen-Notation [3], sie wurde von der MIN-MAX-Notation abgelöst, weil diese nur eingeschränkte Aussagen zu einer Beziehung erlaubt. Bei der MIN-MAX-Notation wird für jeden an einer Beziehung beteiligten Entitätstyp ein geordnetes Paar mit einem Minimal- und einem Maximalwert angegeben. Auch die Verwendung der UML-Notation ist für ER-Modelle möglich. Abbildung 6 zeigt den gleichen Sachverhalt sowohl in der Chen- als auch in der MIN-MAX-Notation.

Abb. 6: Chen- und MIN-MAX-Notation im Vergleich, vgl. [1], [2]

Schlüsselfragen und weitere Grundbegriffe

Ebenfalls zur Theorie der Datenbanken gehört eine Erläuterung der folgenden Begriffe: Primärschlüssel, Sekundärschlüssel, Fremdschlüssel und Nullwerte. Mithilfe des Primärschlüssels (lat. primus: der Erste) kann eine Entität eindeutig identifiziert werden. Er kann sich aus mehreren Attributen zusammensetzen. In der grafischen Darstellung werden Primärschlüssel durch Unterstreichung der jeweiligen Eigenschaft angezeigt. Ein Sekundärschlüssel hilft, Datensätze in einer Tabelle schneller zu finden. Wird kein Sekundärindex angelegt und muss innerhalb einer Tabelle nach einem bestimmten Attributswert gesucht werden, so sind alle Datensätze sequenziell (der Reihe nach) zu durchsuchen. Bei großen Datenbeständen kann das sehr lange Antwortzeiten bedeuten. Wird ein Sekundärindex angelegt, so erstellt das Datenbanksystem dazu eine neue Indextabelle, die nach dem gewünschten Kriterium sortiert ist. Bei einer Suche genügt ein Zugriff auf diese Indextabelle, wo wiederum mit einem Querverweis auf den eigentlichen Datensatz in der Haupttabelle verwiesen wird. Nachteil ist, dass das Anlegen von vielen Sekundärindizes einen großen Mehrbedarf an Speicherplatz bedeutet. Hier gilt: Für häufig benutzte Suchanfragen sind Sekundärindizes anzulegen, für eher seltene Auswertungen ist im Sinne des Speicherplatzes darauf zu verzichten. Im Regelfall gestatten Datenbanksysteme auch das nachträgliche Anlegen von Sekundärindizes, sodass neue Suchanforderungen an die Datenbank auch später eingearbeitet werden können. 

Unter einem Fremdschlüssel versteht man einen Schlüssel, der in der aktuellen Tabelle gespeichert ist, aber auf einen Schlüssel einer „fremden“ Tabelle verweist (meist Primärschlüssel der fremden Tabelle). Ebenfalls von besonderer Bedeutung ist der Begriff des Nullwerts. Nullwerte sind (absichtlich) fehlende Werte bezüglich einer Eigenschaft in einer Tabelle. Es ist festzulegen, wie damit umgegangen wird. Insbesondere bei numerischen Datenfeldern ist zwischen einem Nullwert und einem Wert von 0 zu unterscheiden (Nix ist eben nicht Null!). Im Zusammenhang mit Nullwerten ist für die einzelnen Datenbankfelder festzulegen, ob eine Datenerfassung zwingend (Muss-Feld) oder ob die Eingabe optional ist (Kann-Feld).

[ header = Optimierung: Normalisierung des Datenmodells ]

Optimierung: Normalisierung des Datenmodells

Ein wesentlicher Schritt bei der Festlegung der Datenbankstruktur wird als Normalisierung bezeichnet, damit sollen u. a. Redundanzen in den Daten beseitigt werden. Nachfolgend wird dieser Prozess anhand eines Beispiels beschrieben. Bei der Entwicklung einer Datenbank ist eines der ersten Schritte die Festlegung der grundlegenden Tabellen- und Beziehungsstrukturen. Hier ist besonders sorgfältig vorzugehen, da Fehler in dieser Phase später nur mit sehr viel Aufwand (und Kosten) beseitigt werden können. Schlimmstenfalls kann es zu Dateninkonsistenzen oder zu Datenverlust kommen. Meist liegen Datensammlungen vor bzw. es existieren erste Entwürfe, welche Daten zu verwalten sind. Diese sind jedoch im Regelfall nicht in der Form, wie sie für eine Datenbank benötigt werden. Bei der Festlegung der Datenbankstruktur ist einer der wichtigsten Schritte die so genannte Normalisierung. Diese dient dazu, Redundanzen zu vermeiden. Unter Redundanzen versteht man, dass gleiche Informationen mehrfach vorhanden sind. Das kann zu so genannten Anomalien, d. h. einander widersprechenden Datenbankinhalten, führen. Ein einfaches Beispiel: Eine Datenbank speichert zu einem Auftrag nicht nur die Kundennummer, sondern auch die Adressdaten des Kunden. Hat der Kunde mehrere Bestellungen geordert, liegen diese Informationen mehrfach (redundant) vor. Das Problem entsteht, wenn eine Änderung der Kundendaten durchgeführt wird. Dann müssen die Adressdaten aller Datensätze des Kunden angepasst werden. Dass dabei etwas vergessen werden kann, liegt auf der Hand. Besser wäre es, die Datenstruktur aufzuteilen und die Kundendaten losgelöst von den Bestellinformationen zu verwalten. Um derartige Beziehungen bei der Erstellung der Datenbankstruktur aufzulösen, führt man eine Normalisierung der Tabellenstruktur durch. Der Prozess der Normalisierung dient dazu, die Wartung einer Datenbank zu vereinfachen sowie die Konsistenz der Daten zu gewährleisten.

Mithilfe eines einfachen Beispiels soll der Prozess der Normalisierung demonstriert werden. Der Vorgang ist jedoch auf komplexere Zusammenhänge übertragbar. Lediglich die Zahl der Attribute steigt. Nach der Datenerhebung liegt der Datenbestand in der „Rohform“ vor (Abb. 7). Typisch ist, dass Attribute mehrere Werte enthalten – KursNr und Bezeichnung enthalten jeweils mehrere Werte. Als Erstes gilt es, dieses zu beseitigen. Zur Bildung der ersten Normalform sind die so genannten nicht atomaren Attribute aufzulösen. Dazu werden neue Zeilen (Spalten) in die Tabelle eingefügt (Abb. 8). Es gilt Folgendes: Die erste Normalform (1NF) liegt vor, wenn nur atomare (einfache) Merkmalswerte vorhanden sind.

Ein erstes Problem in der Datenbankstruktur wurde beseitigt, dennoch sind noch einige Nachteile vorhanden: Die Redundanz hat zugenommen, beispielsweise weist die Tabelle zu Student Nummer 1 jetzt 3 Datensätze auf, die sich nur in wenigen Eigenschaften unterscheiden. Bei einer notwendigen Änderung müssen alle Datensätze angepasst werden. Weiterhin genügt der bisherige Primärschlüssel (StudentNr) nicht mehr zur eindeutigen Identifizierung. Der neue Primärschlüssel lautet StudentNr und KursNr. Es handelt sich um einen zusammengesetzten Primärschlüssel. Ein neues Ziel ist das Erreichen der zweiten Normalform. 

Eine Relation befindet sich in der zweiten Normalform (2NF), wenn sie in der ersten Normalform ist und jedes Nichtschlüsselattribut vom Primärschlüssel voll funktional abhängig ist

Wie kann man nun feststellen, ob diese Bedingung verletzt wurde? Wenn ein Attribut, das nicht zum Schlüssel gehört, eindeutig durch einen Teil des Schlüssels identifiziert wird, dann liegt keine 2NF vor. In unserem Beispiel sind die Attribute der Spalte Bezeichnung eindeutig durch das Teilschlüsselattribut KursNr definiert, d. h. die Angabe einer KursNr genügt, um die Bezeichnung zu erhalten. Besteht der Primärschlüssel aus nur einem Attribut, so liegt bereits die 2NF vor. Ist die Bedingung (noch) verletzt, ist eine neue Relation zu bilden. Diese enthält das betreffende Teilschlüsselattribut und alle von diesem Teilschlüssel abhängigen Nichtschlüsselattribute. In der neuen Relation wird das betreffende Teilschlüsselattribut Primärschlüssel, und die ausgelagerten Nichtschlüsselattribute werden in der Ausgangsrelation gelöscht. Es klingt komplizierter als es ist. Für unser Beispiel wurden die erwähnten Schritte umgesetzt (Abb. 9). Die 2NF weist nun mehrere Relationen (Tabellen) auf. Aus der Relation Student sind die Attribute KursNr und Bezeichnung in eine eigene Relation Kurse ausgelagert. Primärschlüssel in dieser Relation ist das Attribut KursNr. Die Verbindung zwischen den beiden Relationen Student und Kurse wird mittels der Relation Belegung hergestellt.

Auch jetzt haben wir noch nicht alle Redundanzen beseitigt. Ein Blick in die Relation Student bestätigt das: Die Merkmale Fachrichtung – AnzahlSemester kommen in der Kombination mit den gleichen Merkmalsausprägungen mehrfach vor. Ist beispielsweise die Zahl der Semester für das BWL-Studium zu ändern, so sind weiterhin mehrere Datensätze anzupassen. Um das zu verhindern, ist der Übergang zur dritten Normalform durchzuführen. Diese ist wie folgt definiert: Die Relation befindet sich in der dritten Normalform (3NF), wenn sie sich in der 2NF befindet und jedes Nichtschlüsselattribut nicht transitiv vom Primärschlüssel abhängig ist, d. h. aus keinem Nichtschlüsselattribut folgt kein anderes Nichtschlüsselattribut. In Bezug auf unser Beispiel und die Relation Student gilt:

StudentNr → Name

StudentNr → Vorname

StudentNr → Geburtsdatum

StudentNr → Fachrichtung

StudentNr → AnzahlSemster

Das heißt aus dem Primärschlüssel folgen sämtliche anderen Attribute. Jedoch gilt auch: Fachrichtung → AnzahlSemester.

Die Zahl der Semester folgt jedoch bereits aus dem Nichtschlüsselattribut Fachrichtung. Es liegt eine so genannte transitive Abhängigkeit vor, die es zu beseitigen gilt. Dazu wird eine weitere Relation erzeugt. Diese enthält die Attribute Fachrichtung und AnzahlSemester. Das Attribut Fachrichtung wird in dieser Relation Primärschlüssel. Abbildung 10 zeigt das Erreichen der 3NF.

Nach diesem Schritt haben alle Tabellen der Datenbank (Student, Studium, Kurse und Belegung) die 3NF. Man sagt auch, die Datenbasis ist normalisiert. In der Theorie existieren noch Definitionen für Normalformen höherer Ordnung, für die meisten praktischen Einsatzfälle dürfte jedoch das Erreichen der 3NF als ausreichend angesehen werden. Wird der Vorgang der Normalisierung zu weit fortgesetzt (Übernormalisierung), so steigt die Komplexität unnötigerweise. Auch das Antwortverhalten verschlechtert sich, da bei Abfragen erst eine Vielzahl von Schlüsselverweisen (Fremdschlüssel) ausgewertet werden muss und die eigentlichen Informationen auf zu viele Tabellen zerstreut sind. Daher gilt: Mithilfe der Normalisierung sollte ein guter Kompromiss zwischen Systemleistung und Redundanzfreiheit angestrebt werden. Der Einsatz von Werkzeugen aus Datenbanksystemen führt gelegentlich auch zu der beschriebenen Übernormalisierung. Es ist Aufgabe des Datenbankdesigners, dieses zu erkennen und die Arbeit dieser Tools „zu bremsen“!

Abb. 7: Normalisierung: die Daten in Rohform

Abb. 8: Normalisierung: die erste Normalform (1NF)

Abb. 9: Normalisierung: die zweite Normalform (2NF)

Abb. 10: Normalisierung: die dritte Normalform (3NF)

Fazit und Ausblick

Der  Beitrag hat eine Einführung in die Grundlagen der Datenbankentwicklung gegeben. Damit sind wir noch lange nicht am Ende. Bei der Arbeit mit Datenbanken spielt die Abfragesprache Structured Query Language (SQL) eine wesentliche Rolle. Damit können alle Operationen – vom Anlegen der Datenbankstruktur bis zur gezielten Suche im Datenbestand – erledigt werden. Teil 2 wird einen Überblick zu SQL geben und die Arbeit damit anhand praktischer Beispiele aufzeigen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -