Datenbanken speichern nicht die Wirklichkeit selbst, sondern einen geordneten Ausschnitt davon. Das Entity-Relationship-Modell hilft, diesen Ausschnitt fachlich zu strukturieren.
Daten sind formale Darstellungen; Information entsteht, wenn diese Daten fachlich gedeutet werden. Ein Modell wählt die relevanten Aspekte eines fachlichen Ausschnitts aus. Q2.1 zeigt, wie solche fachlichen Bedeutungen in ER- und Relationenmodelle überführt werden.
Anschließend wird das Modell in eine relationale Darstellung mit Tabellen überführt. Diese Seite legt damit die Grundlage für das Folgekapitel Q2.2 SQL.
Q2.1 bildet den Einstieg in den Datenbankentwurf und gilt als gemeinsames Fundament für Grund- und Leistungskurs. Lernende strukturieren einen fachlichen Kontext mit dem ER-Modell und überführen ihn in ein relationales Schema.
Komplexere Organisationen müssen fortlaufend Daten erfassen und auswerten: Unternehmen verwalten Kunden, Bestellungen und Produkte; Schulen verwalten Lernende, Kurse und Leistungen; Verwaltungen verwalten Personen, Anträge und Bescheide; Bibliotheken verwalten Medien, Exemplare und Ausleihen. Häufig beginnt diese Datenerfassung mit Tabellen: Sie sind unmittelbar verständlich, schnell veränderbar und für erste Übersichten gut geeignet.
Genau dieser naheliegende Einstieg wird in der Praxis aber schnell problematisch. Tabellen wachsen oft historisch und zweckgetrieben: Daten werden ergänzt, kopiert, gruppiert und zusammengeführt, ohne dass vorher bewusst entschieden wurde, welche fachlichen Dinge, Eigenschaften und Vorgänge eigentlich getrennt modelliert werden müssten.
Eine Tabelle ist deshalb ein sinnvoller Anfang, aber noch kein reflektiertes Datenmodell. Probleme entstehen besonders dann, wenn verschiedene fachliche Dinge in einer gemeinsamen Liste vermischt werden. Dann ist nicht mehr klar, ob eine Zeile ein Buch, ein Exemplar, eine Person, eine Ausleihe oder eine Bestellung beschreibt.
Die Liste wirkt zunächst praktisch, weil alle Informationen an einem Ort stehen. Prüfe aber genauer, welche Informationen mehrfach vorkommen, welche Einträge uneindeutig sind und welche Fragen mit dieser Liste nur schwer zuverlässig beantwortet werden können.
Die Schulbibliothek ist dafür ein typisches Einstiegsbeispiel. Sie hat das praktische Bedürfnis, Bücher, konkrete Exemplare, Personen, Ausleihen, Rückgaben und Bestellungen zu verwalten. Eine gewachsene Liste wirkt zunächst wie eine pragmatische Lösung: Alles steht an einem Ort und kann schnell ergänzt werden.
Gleichzeitig macht diese Liste sichtbar, dass mehrere fachliche Dinge vermischt werden. Buchdaten, Exemplardaten, Ausleihvorgänge, Bestellungen und Personenangaben stehen nebeneinander, obwohl sie unterschiedliche Bedeutungen und unterschiedliche Änderungsregeln haben.
In der gewachsenen Liste treten typische Probleme auf:
"Informatik heute"; "Müller, Anna"; Exemplar B-001; ausgeliehen an Lena Weber; fällig 12.09.
"Informatik heute"; "A. Müller"; Exemplar B-002; Status verfügbar
"Informatik heute"; "Anna Müller"; Bestellung 1 Stück; Status bestellt
"Datenbanken verstehen"; "Schmidt"; Exemplar D-014; ausgeliehen an Max Klein; Rückgabe leer
"Datenbanken verstehen"; "Thomas Schmidt"; Exemplar D-015; Status beschädigt
"Datenbanken verstehen"; "Th. Schmidt"; Bestellung 2 Stück; Status bestellt
"Webentwicklung kompakt"; "Nguyen"; Kategorie Web; Exemplar W-003; verfügbar
"Webentwicklung kompakt"; "Nguyen, T."; Kategorie Internet; Exemplar W-004; ausgeliehen an Sara Yilmaz; fällig 03.10.
"Algorithmen spielerisch"; Autor fehlt; Exemplar A-007; Ausleihe eingetragen; Nutzer unbekannt
"Algorithmen spielerisch"; "Keller"; Exemplar fehlt; Bestellung 3 Stück; Status offen
"Python im Unterricht"; "Neumann"; Kategorie Programmierung; Exemplar P-011; Standort Regal 4
"Python im Unterricht"; "Neumann"; Kategorie Coding; ausgeliehen an Tim Braun; Exemplar P-011; Rückgabe 20.09.Ziel des Einstiegs ist nicht sofort ein vollständiges ER-Diagramm. Zunächst geht es um Problemdiagnose: Lernende sollen erkennen, welche Unklarheiten, Doppelungen und Auswertungsprobleme eine strukturierte Datenhaltung nötig machen.
Für die fachliche Einordnung reicht zunächst eine Leitfrage: Welche Informationen sind doppelt, uneindeutig, vermischt oder schwer auswertbar? Der Vergleich von Sammelliste und stärker getrennter Struktur zeigt, warum Ändern, Löschen, Einfügen und Abfragen Hinweise auf Modellierungsbedarf geben.
Die Liste ist nicht falsch, weil sie als Tabelle beginnt. Problematisch wird sie, weil sie keine tragfähige Trennung der fachlichen Dinge enthält: Buch, Exemplar, Person, Bestellung und Ausleihe werden in gemeinsamen Zeilen vermischt, obwohl sie unterschiedliche Eigenschaften und Änderungsregeln haben. Die folgenden Begriffe sind deshalb zunächst Diagnosesprache. Sie helfen, ein Tabellenproblem fachlich zu beschreiben, ohne hier schon die vollständige Normalisierung zu behandeln.
Redundanz liegt vor, wenn dieselbe Information mehrfach gespeichert wird. Das kostet nicht nur Speicherplatz, sondern macht spätere Änderungen fehleranfällig. Aus Redundanz können Inkonsistenzen entstehen: mehrfach gespeicherte Informationen passen dann nicht mehr zusammen oder widersprechen sich.
Erkennungsfrage: Wird dieselbe Information mehrfach gespeichert?
Beispieltyp: Achte auf Angaben, die in mehreren Zeilen erneut auftauchen, obwohl sie eigentlich zu demselben fachlichen Gegenstand gehören könnten.
Modellierungsproblem: Je häufiger dieselbe Information wiederholt wird, desto größer ist die Gefahr, dass spätere Änderungen nicht überall gleich durchgeführt werden.
Erkennungsfrage: Steht dieselbe Information an mehreren Stellen unterschiedlich?
Beispieltyp: Achte auf unterschiedliche Schreibweisen, Kategorien, Statusangaben oder Bezeichnungen, die möglicherweise denselben Sachverhalt meinen.
Modellierungsproblem: Uneinheitliche Daten erschweren Suche, Auswertung und eindeutige Zuordnung.
Erkennungsfrage: Müsste eine Änderung an mehreren Stellen vorgenommen werden?
Beispieltyp: Achte auf Informationen, die bei einer Korrektur oder Umbenennung mehrfach angepasst werden müssten.
Modellierungsproblem: Wird eine Stelle vergessen, entstehen widersprüchliche Daten.
Erkennungsfrage: Kann eine neue Information nur eingetragen werden, wenn zugleich andere noch fehlende oder unpassende Informationen eingetragen werden?
Beispieltyp: Achte auf Einträge, bei denen etwas bestellt, angekündigt oder erfasst werden soll, obwohl noch kein konkretes Exemplar, kein vollständiger Vorgang oder keine eindeutige Person vorhanden ist.
Modellierungsproblem: Wenn verschiedene fachliche Dinge an dieselbe Tabellenzeile gebunden sind, lassen sich neue Sachverhalte nicht unabhängig eintragen.
Erkennungsfrage: Gehen beim Löschen eines Eintrags unbeabsichtigt andere Informationen verloren?
Beispieltyp: Achte auf Zeilen, in denen ein Vorgang zugleich der einzige Speicherort für Buch-, Exemplar- oder Personendaten sein könnte.
Modellierungsproblem: Wenn Stammdaten nur in Vorgangszeilen stehen, können sie beim Löschen eines Vorgangs verloren gehen.
Für die spätere Modellierung ist entscheidend, zwischen fachlichen Dingen, Eigenschaften und Vorgängen zu unterscheiden. In der Schulbibliothek sind zum Beispiel Buch, Exemplar und Nutzer eher fachliche Dinge; Titel, Autorname, Kategorie, Status oder Fälligkeitsdatum sind Eigenschaften; Ausleihe, Rückgabe und Bestellung sind Vorgänge.
Diese Begriffe bereiten die spätere Normalisierung vor, ersetzen sie aber noch nicht. Die Normalformen werden später systematischer behandelt. Im Einstieg geht es zunächst darum, Datenprobleme sicher zu erkennen und fachlich zu beschreiben.
Wenn Redundanzen, Inkonsistenzen oder Anomalien auftreten, ist das häufig kein bloßer Eingabefehler. Es ist ein Hinweis darauf, dass fachliche Rollen noch nicht sauber getrennt sind. Datenbankmodellierung setzt genau hier an: Sie trennt fachliche Dinge, Eigenschaften und Vorgänge so, dass Informationen konsistent gespeichert und zuverlässig ausgewertet werden können.
Die Lösung besteht nicht darin, die Tabelle nur schöner zu formatieren. Zuerst werden die Datenprobleme sichtbar: Welche Angaben sind mehrfach vorhanden, uneindeutig, schwer auswertbar oder von Anomalien betroffen?
Die folgenden Aufgaben passen zu dieser Diagnosebewegung. Die Strukturierungs- und Modellierungsaufgaben folgen erst nach der Einführung der ER-Grundnotation.
Redundanzen, Uneindeutigkeiten, Vermischungen und Auswertungsprobleme erkennen.
Redundanz, Inkonsistenz, Änderungs-, Einfüge- und Löschanomalien fachsprachlich zuordnen.
Dieser Abschnitt erklärt die Bausteine des ersten Modellkerns. Im reduzierten Schulbibliotheksmodell sind das Entität, Entitätstyp, Attribut und Beziehungstyp. Kardinalität und Optionalität präzisieren Beziehungen im nächsten Schritt.
Eine Entität ist ein einzelnes konkretes Objekt im modellierten Ausschnitt, also ein bestimmter Fall und kein Sammelbegriff. Im Editor entsteht eine Entität nicht als eigenes Symbol, sondern als Datensatz eines Entitätstyps.
Ein Entitätstyp fasst gleichartige Entitäten mit derselben Struktur zusammen und legt damit die Datenform fest. Die Schaltfläche „Entitätstyp hinzufügen“ erzeugt genau diese fachliche Klasse.
Ein Attribut beschreibt eine Eigenschaft eines Entitätstyps oder eines Beziehungstyps. Der konkrete Inhalt eines Feldes ist dann der Attributwert (z. B. Titel = „Informatik heute“). Damit werden fachlich relevante Informationen präzise benannt.
Ein Beziehungstyp beschreibt die Art der Verbindung zwischen Entitätstypen und damit auch ihre fachliche Bedeutung (z. B. „löst“, „bewertet“, „gehört zu“). In diesem Kapitel wird bewusst mit „Beziehung/Beziehungstyp“ gearbeitet, um den späteren Begriff „Relation“ im Relationenmodell klar abzugrenzen.
Für die Modellqualität ist die Unterscheidung zentral: Entitätstyp und Attribut benennen die Struktur, Entität und Attributwert stehen für konkrete Einzelfälle. Schwache Entitätstypen, mehrwertige Attribute und is-a-Beziehungen sind spätere Erweiterungen und werden im Abschnitt zu Sonderfällen wieder aufgegriffen.
Nach der Diagnose wird die ER-Sprache produktiv: Fachliche Dinge werden als Entitätstypen, Eigenschaften als Attribute und zentrale Vorgänge oder Zusammenhänge als Beziehungstypen beschrieben. So entsteht aus dem Listenproblem ein erster Modellkern.
An dieser Stelle geht es noch nicht um ein fertiges Zielbild. Die Aufgaben unterstützen den Übergang von der Problemdiagnose zur eigenen Modellierung, ohne die Musterstruktur vorwegzunehmen.
Aus der Problemdiagnose erste Entitätstypen, Attribute und Beziehungsideen ableiten.
Den ersten Modellkern aus Entitätstypen, Attributen und Beziehungstypen aufbauen.
Ein Beziehungstyp benennt zunächst nur, dass zwei fachliche Rollen zusammenhängen. Kardinalität und Optionalität machen diese Beziehung genauer: Kardinalität fragt nach der Anzahl, Optionalität nach der Teilnahmebedingung.
Die Kardinalität legt fest, wie viele Entitäten an einer Beziehung beteiligt sein können. Für den Unterricht wird hier mit 1:1, 1:n und n:m gearbeitet.
Optionalität beschreibt, ob die Teilnahme an einer Beziehung freiwillig oder verpflichtend ist. In der hessischen Darstellung wird das mit „kann“ beziehungsweise „muss“ unter der Beziehungskante gekennzeichnet, während die Kardinalität darüber angibt, wie viele Entitäten beteiligt sein können.
Bei 1:1 existiert pro Seite höchstens eine Gegeninstanz. Welche Teilnahme verpflichtend ist, klärt erst die Optionalität.
Bei 1:n kann eine Entität der 1-Seite mit mehreren Entitäten der n-Seite verbunden sein.
Bei n:m können auf beiden Seiten mehrere Gegeninstanzen beteiligt sein.
Ein ER-Modell ist nicht schon dadurch tragfähig, dass alle Kästchen, Rauten und Kanten vorhanden sind. Modellqualität zeigt sich daran, ob die fachlichen Entscheidungen begründet werden können: Welche Dinge müssen getrennt werden? Welche Beziehungen sind nötig? Welche Kardinalität und Optionalität passen zum Realitätsausschnitt?
Im reduzierten Schulbibliotheksmodell ist die Prüfung überschaubar. Sie richtet den Blick auf typische Fehlmodellierungen, ohne schon das vollständige Schulbibliothekssystem mit Bestellung, Kategorie, Verlag und weiteren Sonderfällen vorwegzunehmen.
Die konkrete Prüfung liegt im Werkzeug: Schulbibliothek · reduziertes ER-Modell prüfen und überarbeiten.
Der rote Faden bleibt damit überschaubar: Listenchaos analysieren, reduziertes Modell aufbauen, reduziertes Modell präzisieren und prüfen, den kleinen Modellkern zuerst relational darstellen, das Modell zum Schulbibliotheks-Zielmodell erweitern und diese Struktur anschließend vollständig relational verstehen.
Nach Strukturierung, erster Modellierung und Modellprüfung dient das reduzierte Modell als Vergleichs- und Orientierungsmodell. Es ist keine vorweggenommene Arbeitsanleitung, sondern eine fachliche Verdichtung des erreichten Modellstands.
Das Modell bleibt bewusst reduziert. Es zeigt nicht die vollständige Schulbibliothek, sondern eine tragfähige Grundstruktur mit Buch, Exemplar, Nutzer, Ausleihe und Autor. Bestellung, Kategorie, Verlag und weitere fachliche Rollen werden im Zielmodell ergänzt.
Das vollständige Schulbibliotheksmodell wäre für den Einstieg zu umfangreich. Deshalb werden zunächst nur fünf zentrale Entitätstypen betrachtet. So bleibt sichtbar, worum es beim Modellieren geht: Informationen werden nicht kopiert, sondern fachlich geordnet. Darauf aufbauend lässt sich das Modell um weitere Rollen, Vorgänge und Attribute erweitern.
Aus dem reduzierten ER-Modell entstehen zuerst überschaubare Relationen. Entitätstypen werden
Relationen, Attribute werden Spalten, 1:n-Beziehungen werden über Fremdschlüssel abgebildet und
n:m-Beziehungen werden über Zwischentabellen dargestellt. Am reduzierten Modell ist besonders
BUCH_AUTOR als Zwischentabelle wichtig.
BUCH(BuchID, Titel)
EXEMPLAR(ExemplarID, Signatur, Status, BuchID)
NUTZER(NutzerID, Name)
AUSLEIHE(AusleiheID, Fälligkeitsdatum, Rückgabedatum, NutzerID, ExemplarID)
AUTOR(AutorID, Name)
BUCH_AUTOR(BuchID, AutorID)Diese Struktur ist noch nicht der Endzustand der Schulbibliotheksdatenbank. Sie ist der erste Transformationsschritt am überschaubaren Modellkern. Danach folgt der Ausbau zum Zielmodell.
Das geprüfte reduzierte Modell wird in Relationen, Schlüssel und Verweise überführt.
Jetzt wird sichtbar, welche fachlichen Rollen im reduzierten Modell noch fehlen. Verlag, Kategorie, Bestellung und Bestellposition ergänzen das Modell, weil sie Verwaltungsfragen beschreiben, die der kleine Modellkern noch nicht abbildet.
Die spätere vollständige relationale Zielstruktur baut auf dem kleinen Transformationsschritt auf: Die bereits geübten Regeln gelten weiter, werden aber auf das ausgebaute Schulbibliotheksmodell übertragen.
Das reduzierte Modell wird um Verlag, Kategorie, Bestellung, Bestellposition und die Zielattribute ergänzt.
Neben dem Schulbibliotheks-Zielmodell gibt es weitere Modellierungssituationen, in denen die Grundnotation erweitert werden muss. Diese Sonderfälle sind Vertiefungen der ER-Notation und nicht der Kern des konkreten Schulbibliotheks-Zielschemas.
EXEMPLAR kann als schwacher Entitätstyp zu BUCH modelliert werden, wenn eine Exemplarnummer nur innerhalb eines Buches eindeutig ist. Ein stark modelliertes Exemplar besitzt eine eigene globale ExemplarID. Ein schwach modelliertes Exemplar ist dagegen nur zusammen mit dem zugehörigen Buch eindeutig identifizierbar. Beide Varianten sind Modellierungsentscheidungen; entscheidend ist die fachliche Identifikationsregel des Systems.
Ein Attribut ist mehrwertig, wenn zu einer Entität mehrere Werte derselben Art gehören können. Bei einem Buch können das mehrere Schlagwörter oder Themen sein. Im ER-Modell wird das als mehrwertiges Attribut sichtbar. Die relationale Umsetzung wird später gesondert betrachtet.
Eine is-a-Beziehung beschreibt Spezialisierung. Schüler und Lehrkräfte sind Nutzer, können aber zusätzliche Eigenschaften oder Regeln besitzen. Dadurch wird nicht einfach ein neues unabhängiges Objekt eingeführt, sondern eine Unterart eines allgemeinen Entitätstyps modelliert.
Beziehungen mit eigenen Attributen und zusammengesetzte Primärschlüssel bleiben als weitere Erweiterungen sichtbar. Sie werden vor allem wichtig, wenn Modellierungsvarianten in eine relationale Darstellung überführt und dort mit Schlüsseln beschrieben werden.
Nicht nur Entitäten, auch Beziehungen können eigene Attribute tragen. Das ist eine mögliche Vertiefung, wenn eine Information zur Verbindung zweier fachlicher Rollen gehört.
Zusammengesetzte Primärschlüssel werden vor allem beim Darstellungswechsel wichtig, wenn die Identität einer Relation aus mehreren Fremdschlüsseln entsteht.
Eine Identifikationsabhängigkeit zwischen BUCH und EXEMPLAR modellieren.
Mehrere Schlagwörter oder Themen zu einem Buch modellieren.
NUTZER in SCHUELER und LEHRKRAFT spezialisieren.
Die drei Erweiterungen am reduzierten Schulbibliotheksmodell begründet kombinieren.
Nach Aufbau, Präzisierung und fachlichem Ausbau des ER-Modells folgt der Darstellungswechsel. Für den Einsatz in einem DBMS überführt die relationale Darstellung das ER-Modell in Relationen. Dabei gilt als Grundregel: Entitätstypen werden zu Relationen beziehungsweise Tabellen, Attribute zu benannten Spalten oder Merkmalen, konkrete Datensätze beziehungsweise Zeilen sind Tupel. Im ER-Diagramm-Editor wird diese Überführung bewusst vorgenommen und schrittweise begründet.
Dabei werden Primärschlüssel so gewählt, dass jede Zeile eindeutig identifizierbar ist: Sie sichern Identität. Fremdschlüssel übernehmen anschließend die Verknüpfung zwischen Tabellen und sichern Referenzen. So wird die Semantik der Beziehungstypen aus dem ER-Modell technisch überprüfbar.
Als erster Transformationsschritt wird die reduzierte Schulbibliothek relational dargestellt: BUCH, EXEMPLAR, NUTZER, AUSLEIHE und AUTOR bilden den Kern. Das ER-Diagramm beschreibt fachliche Dinge und Beziehungen; die relationale Darstellung beschreibt Tabellenstruktur, Schlüssel und Verweise. Danach lässt sich dieselbe Leselogik auf das vollständige Zielmodell übertragen.
BUCH(BuchID, Titel)
EXEMPLAR(ExemplarID, Signatur, Status, ↑BuchID)
NUTZER(NutzerID, Name)
AUSLEIHE(AusleiheID, Fälligkeitsdatum, Rückgabedatum, ↑NutzerID, ↑ExemplarID)
AUTOR(AutorID, Name)
BUCH_AUTOR(↑BuchID, ↑AutorID)↑BuchID: Ein Buch kann mehrere Exemplare haben; jedes konkrete Exemplar gehört zu einem Buch. Der Fremdschlüssel steht deshalb auf der n-Seite.↑NutzerID und ↑ExemplarID: Eine Ausleihe verbindet einen Nutzer mit einem konkreten Exemplar. Sie verweist nicht nur auf einen Buchtitel.BUCH_AUTOR: Autorinnen und Autoren können mehrere Bücher schreiben, und ein Buch kann mehrere Autorinnen und Autoren haben. Diese n:m-Beziehung braucht eine Zwischentabelle.Die passende Werkzeugaufgabe prüft genau diesen reduzierten Darstellungswechsel: Schulbibliothek · reduziertes ER-Modell → relationale Darstellung. Bestellung, Bestellposition mit Menge, Kategorie und Verlag gehören zum Zielmodell.
Die vollständige Zielstruktur ist die relationale Darstellung des ausgebauten Schulbibliotheksmodells. Sie knüpft an die vorher geübten Regeln an und erweitert sie um VERLAG, KATEGORIE, BESTELLUNG und BESTELLPOSITION.
AUSLEIHE(AusleiheID, ↑NutzerID, ↑ExemplarID, Ausleihdatum, FaelligAm, Rueckgabedatum)
AUTOR(AutorID, Vorname, Nachname)
BESTELLPOSITION(↑BestellID, ↑BuchID, Menge)
BESTELLUNG(BestellID, ↑NutzerID, Bestelldatum, Status)
BUCH(BuchID, Titel, ISBN, Erscheinungsjahr, ↑VerlagID, ↑KategorieID, Preis)
BUCH_AUTOR(↑BuchID, ↑AutorID)
EXEMPLAR(ExemplarID, ↑BuchID, Signatur, Anschaffungsdatum, Zustand, Status)
KATEGORIE(KategorieID, Bezeichnung, Beschreibung)
NUTZER(NutzerID, Vorname, Nachname, EMail, Rolle, KlasseOderFachbereich)
VERLAG(VerlagID, Name, Ort)VERLAG und KATEGORIE.BUCH.NUTZER und EXEMPLAR.NUTZER.BESTELLUNG und BUCH und trägt Menge.BUCH und AUTOR.Die relationale Darstellung zeigt nicht nur welche Tabellen entstehen, sondern auch wie sie fachlich miteinander verknüpft sind. Auf Q2.1 nutzen wir dieselbe Notationslogik wie im SQL-Werkzeug: Relationenschreibweise, Schlüsselmarkierungen und Transformationshinweise sind dort und hier konsistent.
Eine Relation ist hier eine tabellenartige Struktur mit Attributen und Tupeln. Attribute beschreiben das Schema, also die benannten Spalten oder Merkmale. Tupel sind die konkreten Zeilen beziehungsweise Datensätze dieser Relation.
Relation(Attribut1, Attribut2, ...) beschreibt ein Relationsschema in Kurzschreibweise.Das folgende Schema zeigt eine zusätzliche Buchhandel-Perspektive. Es dient als Notations- und Erweiterungsbeispiel, um Fremdschlüssel, Zwischentabellen, Beziehungsattribute und ausgelagerte mehrwertige Attribute noch einmal außerhalb der Schulbibliothek zu lesen.
Verlag(VerlagID, Name, Ort)
Buch(ISBN, Titel, Preis, ↑VerlagID)
Autor(AutorID, Name)
Kunde(KundenID, Name, EMail)
Bestellung(BestellID, Datum, ↑KundenID)
Buch_Autor(↑ISBN, ↑AutorID, Rolle)
Bestellposition(↑BestellID, ↑ISBN, Menge)
Kunde_Telefon(↑KundenID, Telefonnummer)↑VerlagID in Buch, ↑KundenID in Bestellung) – keine eigene Beziehungstabelle nötig.Buch_Autor) mit beiden Fremdschlüsseln als gemeinsamem Primärschlüssel.Rolle in Buch_Autor, Menge in Bestellposition).Kunde_Telefon für mehrere Telefonnummern pro Kunde).Genau diese Leselogik wird im SQL-Werkzeug bei „Relationale Darstellung“ verwendet: Das ER-Modell liefert die fachliche Struktur, die Überführung zeigt sie als Relationsnotation mit Primär- und Fremdschlüsseln. Dadurch lässt sich direkt prüfen, ob Kardinalitäten, Beziehungen und Integritätsbedingungen technisch korrekt umgesetzt wurden.
Integritätsbedingungen beschreiben, was in gültigen Datenbeständen gelten muss: Datensätze müssen eindeutig identifizierbar sein, und Beziehungen dürfen nicht ins Leere zeigen.
Vorbereitend dazu werden Primärschlüssel und Fremdschlüssel festgelegt. So kann das DBMS Eindeutigkeit und Referenzen prüfen, noch bevor später mit SQL detailliert gearbeitet wird. Die Optionalität aus dem ER-Modell wirkt dabei weiter: „muss“ führt zu verpflichtenden Referenzen, „kann“ erlaubt fehlende Zuordnungen (z. B. leere Fremdschlüsselfelder).
Die Transformation erzeugt Relationen. Danach prüft die Normalisierung, ob diese Relationen redundantarm, konsistent und updatefähig strukturiert sind: Sind die Daten widerspruchsfrei und ohne unnötige Wiederholungen gespeichert?
Redundante Daten führen leicht zu Einfüge-, Änderungs- und Löschanomalien: Informationen müssen an mehreren Stellen gepflegt werden, können sich widersprechen und machen die Datenbank inkonsistent. Ziel der Normalisierung ist deshalb eine Tabellenstruktur ohne überflüssige Redundanz, bei der der Informationsgehalt erhalten bleibt.
Eine gute ER-Modellierung reduziert viele Probleme bereits im Vorfeld. Im Werkzeug entspricht eine saubere ER-Modellierung bereits weitgehend einer normalisierten Datenbank. Fehler in der Modellierung führen im relationalen Schema dagegen häufig zu Redundanzen.
In der 1NF enthält jedes Attribut nur atomare Werte: keine Listen, keine Mehrfachwerte in einer Zelle. Ein typisches Gegenbeispiel ist ein Attribut „Sportgruppen“ mit mehreren Einträgen in einem Feld.
Lösung: Die Liste wird auf mehrere Tupel aufgeteilt, und zusammengesetzte Attribute werden in Einzelfelder zerlegt (z. B. Name in Vorname/Nachname). Mehrfachwerte aus mehrwertigen Attributen werden in der Regel in eine eigene Tabelle ausgelagert.
Die 2NF setzt die 1NF voraus. Jetzt geht es um partielle Abhängigkeiten bei zusammengesetzten Schlüsseln: Jedes Nichtschlüsselattribut muss vom gesamten Primärschlüssel abhängen.
Funktionale Abhängigkeit bedeutet: A → B, also A bestimmt B eindeutig. Für die 2NF reicht nicht „ein Teil des Schlüssels bestimmt B“, sondern nur die volle Abhängigkeit vom gesamten Schlüssel. Wenn das nicht gilt, wird die Tabelle in mehrere Tabellen aufgespalten.
Die 3NF setzt die 2NF voraus und entfernt transitive Abhängigkeiten. Problemfall: A → B → C. Dann hängt C nur indirekt vom Schlüssel über B ab.
Lösung: Der transitiv abhängige Teil wird in eine eigene Tabelle ausgelagert. So bleiben Änderungen lokal und verursachen keine widersprüchlichen Datenstände.
Normalisierung erklärt, warum bei der Transformation zusätzliche Tabellen entstehen: n:m-Beziehungen werden als eigene Tabellen umgesetzt, Entitäten werden klar getrennt und Schlüsselbezüge sauber modelliert. Damit werden die späteren SQL-Abfragen robuster und Integritätsbedingungen leichter einhaltbar.
Q2.2 nutzt die entstandenen Relationen als Grundlage für SQL-Abfragen. Q2.5 beschreibt Operationen auf Relationen formal mit Relationenalgebra. Q2.1 bleibt dabei das Modellierungsfundament, nicht das Zentrum für SQL oder Relationenalgebra.
Passende Aufgaben findest du auf der Seite Übungen in der Kategorie „Erstellung von ER-Diagrammen“.
Das ER-Modell kannst du zusätzlich direkt im ER-Diagramm-Editor konstruieren. Für die Schulbibliothek arbeitest du vor allem mit konkreten Aufgaben und Startmodellen; die Überführung in Relationen folgt im Transformationsabschnitt.