2. Datenbankentwurf

Phasen des Datenbankentwurfs

Sichten und Datenunabhängigkeit

Ein zentrales Ziel eines Datenbanksystems (DBS) ist die Datenunabhängigkeit. Sie entsteht durch die Trennung von physischer Datenspeicherung und -verwaltung einerseits und den Anwendungsprogrammen andererseits.

Dabei unterscheidet man:

• Physische Datenunabhängigkeit: Die interne Organisation der Daten bleibt für Programme und Nutzer transparent. Änderungen an der physischen Speicherung oder Struktur erfordern keine Anpassungen der Anwendungen.

• Logische Datenunabhängigkeit: Die logische Gesamtstruktur der Datenbank ist getrennt von den benutzerspezifischen Sichten. Dadurch lassen sich zusätzliche Anwendungen und Views auf eine bestehende Datenbank einrichten, ohne bestehende Anwendungen zu beeinträchtigen.

Sicht (View): Ein aufgaben- bzw. anwendungsspezifischer Teilbereich der Datenbank, der genau die dafür relevanten Daten umfasst.

Eine Sicht ist ein fachlicher Ausschnitt der gesamten Datenbank - zugeschnitten auf eine bestimmte Aufgabe oder Nutzergruppe. Sie zeigt nur die benötigten Informationen in passender Struktur, ohne technische Details der Speicherung offenzulegen.

Eine Sicht ist ein ausgewählter Ausschnitt der Datenbank, der für eine bestimmte Aufgabe oder Rolle relevant ist. Oft hat eine Sicht auch eigene Darstellung. Bei Sichten konzentriert man sich auf Relevantes und blendet Überflüssiges aus. Damit sind Sichten eine wichtige Grundlage für die logische Datenunabhängigkeit. Änderungen der technischen Speicherung betreffen die Sicht nicht. Mehrere Sichten auf dieselbe Datenbasis stören einander nicht.

Beispiele (konzeptionell):

• Lehrkraft-Sicht: Schüler und Schülerin, Klasse, Notenübersicht; keine Adress- oder Zahlungsdaten.
• Sekretariat-Sicht: Stammdaten (Adresse, Kontakt, Schulzugehörigkeit); keine detaillierten Leistungsdaten.
• Schulverwaltung/Kostenstelle: Klassen, Budget, Ausgaben je Projekt; keine personenbezogenen Noten.
• Schüler und Schülerinnen-Sicht: Eigene Noten und Fehlzeiten; keine Daten anderer Personen.

Abb. 2.1: Beispiel von verschiedenen Sichten auf die gleiche Schul-Datenbank. Die Lehrkraft sieht nur die für sie relevanten Daten, ebenso das Sekretariat, die Schulverwaltung und die Schüler und Schülerinnen.

Sicht

Eine Sicht ist die “passende Brille” auf das gemeinsame Datenmodell - je nach Aufgabe werden nur die wirklich benötigten Informationen gezeigt.

3-Ebenen-Modell (ANSI-SPARC, 1978)

Das 3-Ebenen-Modell zeigt, dass ein und derselbe Datenbestand aus verschiedenen Blickwinkeln betrachtet werden kann. Dabei wird auch das Prinzip der Datenunabhängigkeit deutlich:

• Physische Datenunabhängigkeit: Anwendungen und Nutzer und Nutzerinnen müssen nicht wissen, wie und wo die Daten technisch gespeichert sind (Dateiformate, Indizes, Speicherorte).

• Logische Datenunabhängigkeit: Anwendungen und Nutzer und Nutzerinnen arbeiten mit einer fachlich sinnvollen Darstellung der Daten (Sichten), ohne die gesamte Gesamtstruktur kennen zu müssen.

Kurz: Programme und Menschen können auf Daten zugreifen und damit arbeiten, ohne Details der technischen Umsetzung (Speicherung, interne Abläufe) zu kennen. Das Modell trennt bewusst zwischen Darstellung, Gesamtstruktur und technischer Speicherung.

Abb. 2.2: Das 3-Ebenen-Modell (ANSI-SPARC, 1978).

Quelle: [1, p. 16]

Externe Ebene (Benutzersichten - fachliche Ausschnitte)

• Beschreibt aufgabenbezogene Ausschnitte aus dem gesamten Datenbestand für bestimmte Rollen oder Anwendungen (z. B. Rechnungswesen, Produktion, Sekretariat).
• Enthält nur die jeweils benötigten Informationen in einer zweckmäßigen fachlichen Struktur.
• Kann Attribute und Beziehungen anders anordnen oder benennen als im Gesamtschema - solange der fachliche Sinn gewahrt bleibt.
• Beispielhaft (rein konzeptionell): Die Rechnungslegung verwendet “Kunde”, “Rechnung”, “Zahlungsstatus”; der Lagerbestand von “Artikel” ist dort kein Teil der externen Sicht.

Konzeptionelle Ebene (logische Gesamtsicht)

• Enthält das unternehmensweite, einheitliche Fachmodell: alle relevanten Objekte/Entitäten, ihre Attribute, Beziehungen und fachlichen Regeln.
• Wird als konsistentes Gesamtbild der realen Welt formuliert - anwendungsneutral, also nicht auf einzelne Abteilungen zugeschnitten.
• Dient als Bezugspunkt für alle externen Sichten: Jede Benutzersicht ist ein Ausschnitt bzw. eine Projektion aus dieser Gesamtsicht.

Interne Ebene (physische Organisation)

• Beschreibt die technische Speicherung und Zugriffswege: Dateien, Seiten, Indizes, Partitionen, Kompression, Sicherung/Wiederherstellung usw.
• Ziel ist ein effizienter und sicherer Zugriff auf die Daten - unabhängig davon, wie externe Sichten formuliert sind.
• Wird aus der konzeptionellen Ebene abgeleitet und im Datenbanksystem physisch umgesetzt.

3-Ebenen-Modell

• Externe Ebene = fachlicher Ausschnitt,
• Konzeptionelle Ebene = einheitliches Fachmodell,
• Interne Ebene = technische Speicherung.

Die Ebenen sind getrennt, damit Fachlichkeit und Technik sich unabhängig weiterentwickeln können.

Zwischen den Ebenen gibt es Transformationsregeln, welche die Daten der einen Sicht in Strukturen der anderen Sicht überführen.

Der Datenbankentwurf

Wenn bei der Planung einer Software klar wird, dass zur Verwaltung der Informationen eine Datenbank nötig ist, beginnt der Datenbankentwurf. Dabei wird Schritt für Schritt festgelegt,

• welche Daten überhaupt gebraucht werden,
• ob weitere Anwendungen mit denselben oder zusätzlichen Daten arbeiten sollen,
• und wie das alles sinnvoll organisiert wird.

Dabei sind drei Fragen besonders wichtig:

1. Logische Struktur (fachliche Sichtweisen):

   Welche Sichten auf den Datenbestand werden benötigt (z. B. für Rechnungswesen, Verwaltung, Auswertung) und wie lassen sich diese Sichten in einem gemeinsamen Schema zusammenführen?

2. Physische Struktur (technische Umsetzung):

   In welcher Form werden die Daten gespeichert (Dateien, Seiten, Indizes usw.) und wie erfolgt der Zugriff darauf, damit alles zuverlässig und schnell funktioniert?

3. Zusätzliche Anforderungen:

   Welche Regeln, Einschränkungen oder Vorgaben gibt es seitens der Anwendungen (z. B. Pflichtfelder, Berechtigungen, Konsistenzregeln, Datenschutz)?

Der Entwurf orientiert sich am 3-Ebenen-Modell (ANSI/SPARC). Dafür werden Schemata für

• die externe Ebene (aufgabenbezogene fachliche Ausschnitte, “Sichten”),
• die konzeptionelle Ebene (einheitliche, anwendungsneutrale Gesamtsicht),
• und die interne Ebene (technische Speicherung und Zugriffswege) aufgestellt.

Für den Entwurfsprozess kommen spezielle Methoden zum Einsatz. Die grafische Darstellung der Modelle erfolgt in der Praxis meist mit dem Entity-Relationship-Modell (ER-Modell), das sich für den Datenbankentwurf bewährt hat.

Abb. 2.3: Der Datenbank-Lebenszyklus, von der Planung bis zur Implementierung und zum Betrieb.

Quelle: [1, p. 29]

1. Anforderungsanalyse

   In der Anforderungsanalyse werden die Bedürfnisse aller künftigen Nutzerinnen und Nutzer einer Datenbank systematisch gesammelt. Üblich ist eine Gliederung nach Kriterien wie Abteilungen oder Benutzergruppen.

   Zentrale Punkte:

   • Welche Daten sollen gespeichert werden? (z. B. Stammdaten, Bewegungsdaten, historische Daten)
   • Wie sollen die Daten verarbeitet werden? (z. B. erfassen, ändern, löschen, suchen, auswerten, Berichte erstellen)
   • Welche Regeln gelten dabei? (z. B. Berechtigungen, Pflichtfelder, Validierungen, Datenschutz)

   Ziel ist ein klarer, vollständiger Katalog aller fachlichen Anforderungen als Grundlage für den weiteren Datenbankentwurf.

   Achten Sie dabei auf Homonyme und Synonyme, also gleiche Begriffe mit unterschiedlicher Bedeutung bzw. unterschiedliche Begriffe für dasselbe Objekt. Klären Sie solche Begriffsprobleme frühzeitig, um Missverständnisse zu vermeiden (siehe unten).

2. Konzeptioneller Entwurf

   Das Ziel des konzeptionellen Entwurfs ist es, ein umfassendes und konsistentes Datenmodell für das Gesamtsystem zu erstellen, ein konzeptionelles Modell. Am Ende des konzeptionellen Entwurfs liegen zwei Dinge vor:

   • die externen Sichten (fachliche Ausschnitte für bestimmte Aufgaben/Gruppen) und
   • das konzeptionelle Gesamtschema, meist als Entity-Relationship-Diagramm (ER-Diagramm).

   Vorgehensweisen im Entwurf

   • Top-down (schrittweise Verfeinerung): Zuerst werden die benötigten Sichten festgelegt und anschließend zu einem gemeinsamen konzeptionellen Schema zusammengeführt.
   • Bottom-up (schrittweise Verallgemeinerung): Zunächst werden einzelne Datenobjekte und Zusammenhänge aus der Praxis gesammelt und danach zu einer einheitlichen Gesamtsicht zusammengefügt.

   Inhalte des Ergebnisses (im ER-Diagramm eindeutig beschrieben)

   • Datenobjekte (Entitäten) und ihre Eigenschaften (Attribute)
   • Beziehungen zwischen den Datenobjekten (z. B. “Kunde gibt Bestellung auf”)
   • Abhängigkeiten und Integritätsbedingungen (z. B. Pflichtattribute, Schlüssel, Referenzen, Kardinalitäten, Geschäftsregeln)

   Wichtiger Schritt vor dem logischen Entwurf

   Bevor der logische Entwurf (Überführung in ein konkretes Datenmodell wie das relationale Modell) startet, wird festgelegt, für welches Datenbanksystem (DBS) die Datenbank aufgebaut werden soll. Diese Entscheidung beeinflusst anschließend die genaue Ausprägung der Tabellen/Typen, Schlüssel und Constraints im logischen Modell.

3. Logischer Entwurf

   Das konzeptionelle Schema wird in das Datenmodell des gewählten Datenbanksystems übertragen (z. B. in das relationale Modell). Dafür gibt es Transformationsregeln, die festlegen, wie Entitäten, Attribute und Beziehungen fachgerecht abgebildet werden.

   Im Anschluss wird das entstehende Datenbankschema normalisiert. Ziel der Normalisierung ist es, Redundanzen zu verringern und Anomalien bei Einfügen, Ändern und Löschen zu vermeiden. Ergebnis ist eine klar strukturierte und konsistente logische Datenbasis.

4. Verfeinerung des logischen Entwurfs

   Im nächsten Schritt wird das logische Schema anhand der in den Anforderungen beschriebenen häufigen bzw. wichtigen Abfragen gezielt optimiert. Dazu können Erweiterungen oder Anpassungen am relationalen Schema vorgenommen werden - etwa das Anlegen von Indizes, um Such- und Join-Operationen zu beschleunigen. Ziel ist ein Schema, das die typischen Zugriffe effizient unterstützt, ohne die fachliche Korrektheit zu verändern.

5. Physischer Entwurf

   In der letzten Entwurfsphase wird das interne Schema festgelegt. Dazu gehören die Auswahl geeigneter Speicherstrukturen und Zugriffsmechanismen. Ein Schwerpunkt liegt auf dem Laufzeitverhalten: Durch effiziente Zugriffe auf relevante Daten sollen Abfragen und Transaktionen schnell ausgeführt werden.

   Mit der Datendefinitionssprache (DDL) des gewählten Systems werden anschließend das interne, konzeptionelle und externe Schema implementiert. In relationalen Systemen werden dabei u. a. Tabellen (Relationen) sowie ggf. Views definiert.

   Views in relationalen Systemen

   Hinweis: “Views” in relationalen Systemen sind Datenbankobjekte. Sie sind nicht identisch mit den externen Sichten des ANSI/SPARC-Modells.

   In dieser Phase werden außerdem die Zugriffsrechte (Rollen, Berechtigungen) festgelegt. Ziel ist eine sichere und performante technische Umsetzung der zuvor erarbeiteten Modelle.

Homonyme und Synonyme

Achten Sie bei der Anforderungsanalyse auf Homonyme und Synonyme, also gleiche Begriffe mit unterschiedlicher Bedeutung bzw. unterschiedliche Begriffe für dasselbe Objekt. Da diese Begriffe in verschiedenen Abteilungen oder Kontexten unterschiedlich verwendet werden, können sie zu Missverständnissen führen. Klären Sie solche Begriffsprobleme frühzeitig, um Missverständnisse zu vermeiden.

Allerdings ist es oft schwierig, alle Begriffsprobleme zu erkennen und zu lösen. Oft ist es den Beteiligten gar nicht bewusst, dass sie denselben Begriff unterschiedlich verwenden. Ein gemeinsames Verständnis der Fachbegriffe ist entscheidend für den Erfolg des Datenbanksystems.

Homonyme

Homonyme: Gleiche Begriffe mit unterschiedlicher Bedeutung.

• Ein klassisches Homonym im Deutschen ist “Schloss” - es kann “Burg/Gebäude” oder “Türschloss” bedeuten.

  • Das Schloss Schönbrunn ist ein Touristenmagnet.
  • Ich habe den Schlüssel fürs Schloss vergessen.

• Beispiel: “Kunde” kann in verschiedenen Abteilungen unterschiedliche Dinge bedeuten (Endkunde, Geschäftskunde, Lieferant).

• Lösung: Klare Definitionen und ggf. unterschiedliche Bezeichnungen verwenden (z. B. “Endkunde”, “Geschäftskunde”).

Synonyme

Synonyme: Unterschiedliche Begriffe für dasselbe Objekt.

• Beispiel: “Blatt”:

  • Pflanzenblatt: “Das Blatt der Eiche ist gezackt.”
  • Papierseite: “Gib mir bitte ein Blatt Papier.”
  • Zeitungsblatt: “In welchem Blatt hast du das gelesen?”
  • Spielkarte: “Er zog ein rotes Blatt.”
  • Klingenblatt: “Das Blatt des Messers ist stumpf.”

• Beispiel: “Artikel” in der Produktion und “Produkt” im Vertrieb meinen dasselbe.

• Lösung: Einheitliche Terminologie festlegen (z. B. immer “Produkt” verwenden).

Wichtig: Klären Sie solche Begriffsprobleme frühzeitig, um Missverständnisse zu vermeiden. Ein gemeinsames Verständnis der Fachbegriffe ist entscheidend für den Erfolg des Datenbanksystems.

Sagen Sie nicht einfach “Kunde” oder “Artikel”, sondern definieren Sie genau, was damit gemeint ist! Verwenden Sie eindeutige Begriffe oder fügen Sie erläuternde Zusätze hinzu (z. B. “Endkunde”, “Geschäftskunde”, “Produktionsartikel”, “Vertriebsprodukt”). Das mag zwar umständlich erscheinen, verhindert aber spätere Missverständnisse und Fehler im Datenmodell.

Tipp

Haben Sie Mut zum Detail! Lassen Sie sich nicht von einer scheinbaren Einfachheit eines Begriffs täuschen. Je klarer und präziser die Begriffe definiert sind, desto besser wird das Datenbanksystem den tatsächlichen Anforderungen gerecht.

Fragen Sie nach!

Bohren Sie nach!

Lassen Sie sich nicht mit vagen Antworten abspeisen. Je tiefer Sie nachbohren, desto klarer wird das Verständnis für die Anforderungen.

Lernergebnisse: Was Sie nach diesem Kapitel können sollten

Nach Abschluss dieses Kapitels sollten Schülerinnen und Schüler in der Lage sein:

• Nennen: die drei Ebenen des ANSI-SPARC-Modells sowie die Phasen des Datenbankentwurfs nennen.
• Beschreiben: die externe, konzeptuelle und interne Ebene sowie die logische und physische Datenunabhängigkeit beschreiben.
• Erklären: erklären, wie das 3-Ebenen-Modell Datenunabhängigkeit ermöglicht.
• Anwenden: Homonyme und Synonyme in einer Anforderungsbeschreibung erkennen und auflösen.
• Beurteilen: die Bedeutung einer sauberen Trennung der Ebenen für Wartbarkeit und Erweiterbarkeit beurteilen.