Klausurzusammenfassung: Datenbanken Theorie

Relationale Datenbanken, ER-Modellierung, Normalisierung, Integrität, Relationenalgebra und SQL-Grundlogik

Grundlage: vollständige Analyse des bereitgestellten Skripts Datenbanken - Teil: Relationale Datenbanken mit 156 PDF-Seiten.

Druckhinweis: Im Browser über Drucken > Als PDF speichern exportieren. Sinnvolle Einstellungen: Papierformat A4, Skalierung 100 %, Browser-Kopf- und Fußzeilen deaktivieren, Hintergrundgrafiken aktivieren.

1. Stoffkarte und Prüfungskern

Das Skript behandelt Datenbanken aus zwei Perspektiven: erstens den sauberen Entwurf einer relationalen Datenbank aus fachlichen Anforderungen, zweitens die formale Abfragesprache der relationalen Algebra als Grundlage für SQL. Klausurrelevant ist deshalb nicht das Auswendiglernen einzelner Folien, sondern die Fähigkeit, Fachtext in Modell, Tabellen, Schlüssel, Integritätsregeln und formale Abfragen zu übersetzen.

Prüfungskern: Eine gute Antwort folgt einer Kette: Fachanforderung → relevante Miniwelt → Entitytypen und Relationshiptypen → Kardinalitäten → relationales Schema → Normalisierung und Integrität → Relationenalgebra oder SQL Wer an einer Stelle falsch modelliert, bekommt später falsche Tabellen, falsche Schlüssel oder fehlerhafte Abfragen.

Gliederung

  1. Grundbegriffe und Datenbankarten
  2. Relationenmodell, Domänen und Schlüssel
  3. NoSQL-Abgrenzung
  4. Datenbankentwurf und ERM
  5. Assoziationen, Kardinalitäten und ternäre Beziehungen
  6. Generalisierung und Spezialisierung
  7. Normalisierung und Anomalien
  8. Relationales Schema und Abbildungsregeln
  9. Integrität, Konsistenz und Constraints
  10. Relationenalgebra
  11. Rechenregeln und SQL-Sneak-Preview
  12. Lerncheckliste, Klausurfragen und Abdeckung

2. Grundbegriffe und Datenbankarten

2.1 Daten, Information und Wissen

Begriff Kernidee Beispiel Klausurhinweis
Daten Formalisierte, maschinell verarbeitbare Repräsentationen von Fakten, Ereignissen oder Konzepten. 37, 2025-08-27, ein Messwert. Ohne Kontext sind Daten noch nicht entscheidungsfähig.
Information Daten, die interpretiert und in einen Kontext gesetzt werden. 37 °C Temperatur. Information entsteht durch Bedeutung, nicht durch Speicherung allein.
Wissen Vernetzte Informationen, die für Entscheidungen genutzt werden können. Bei 37 °C muss ein Server gekühlt werden. Wissen verbindet Daten, Kontext und Handlungsregel.
Datenbank: Eine organisierte Sammlung logisch zusammenhängender Daten und ihrer Beschreibung, damit Informationen effizient gespeichert, verwaltet und abgerufen werden können.
Datenbanksystem: Software zur applikationsunabhängigen Beschreibung, Speicherung und Abfrage von Daten. Es besteht aus einer Speicherungskomponente und einer Verwaltungskomponente. Die Verwaltungskomponente enthält Abfrage- und Manipulationssprache sowie Rechte- und Zugriffskontrolle.

2.2 Daten nach Struktur

Datenart Beschreibung Beispiele Typische Datenbanknähe
Strukturiert Explizites Schema mit klaren Attributen, Datentypen und Regeln. Kundentabelle, Excel-Tabelle, Buchungsdaten. Relationale Datenbanken.
Halbstrukturiert Keine streng tabellarische Struktur, aber erkennbare innere Ordnung. XML, JSON, Events. Dokumentendatenbanken, auch relationale JSON-Spalten.
Unstrukturiert Kein fachlich festes Schema jenseits der Rohdatenfolge. Bilder, Videos, E-Mails, PDFs. Objektablagen, Suchsysteme, ergänzende Metadatenbanken.
Prüfungsfalle: "JSON" bedeutet nicht automatisch "NoSQL". JSON beschreibt nur eine Repräsentationsform. Die Datenbankentscheidung hängt von Schema, Zugriffsmuster, Beziehungen, Integritätsbedarf, Skalierung und Konsistenzanforderung ab.

2.3 Eigenschaften von Information

Information ist im Gegensatz zu materiellen Gütern leicht kopierbar, kombinierbar, manipulierbar und nicht an einen festen Träger gebunden. Außerdem altert sie nicht physikalisch, kann aber fachlich veralten oder vage sein. Für Datenbanken bedeutet das: Qualität, Integrität, Zugriffsschutz und Kontext sind genauso wichtig wie die reine Speicherung.

3. Relationenmodell, Domänen und Schlüssel

3.1 Eigenschaften relationaler Datenbanken

Relationale Datenbanken drücken Daten und Beziehungen in Tabellen aus. Sie besitzen ein definiertes Schema, nutzen SQL als deklarative Sprache, trennen Datenhaltung und Anwendung weitgehend und stellen Mechanismen für Mehrbenutzerbetrieb, Datenschutz, Datensicherheit, Konsistenz und Integrität bereit.

Baustein Bedeutung Prüfungsrelevanz
Relation Tabelle mit eindeutigem Namen, Attributen und Tupeln. Das Ergebnis jeder relationalen Operation ist wieder eine Relation.
Tupel Eine Zeile der Relation. Zwei Tupel dürfen nicht vollständig identisch sein. Die Reihenfolge der Tupel ist irrelevant.
Attribut Spalte einer Relation, beschreibt eine Eigenschaft der Tupel. Die Reihenfolge der Attribute ist irrelevant, Namen müssen eindeutig sein.
Domäne Wertebereich eines Attributs inklusive Typ, Format, Grenzen, NULL-Zulässigkeit und Regeln. Domänenverstöße werden durch DBMS-Regeln verhindert.
Atomarität In jedem Schnittpunkt aus Tupel und Attribut steht genau ein Wert. Grundlage der 1. Normalform.

3.2 Mathematische Sicht

Relation und Tupel R ⊆ D1 × D2 × ... × Dn r = (d1, d2, ... , dn)
R
Relation, also eine Tabelle als Menge von Tupeln.
D1 ... Dn
Domänen der Attribute 1 bis n.
r
Ein konkretes Tupel, also eine Zeile der Relation.
di
Konkreter Wert aus der Domäne Di.

3.3 Schlüssel

Ein Identifikationsschlüssel ist ein Attribut oder eine Attributkombination, die ein Tupel eindeutig identifiziert. Besteht ein Schlüssel aus mehreren Attributen, muss die Kombination minimal sein: Kein Attribut darf entfernt werden können, ohne die Eindeutigkeit zu verlieren.

Schlüsselbegriff Definition Typischer Fehler
Schlüsselkandidat Möglicher minimaler eindeutiger Identifikator. Nur Eindeutigkeit prüfen, Minimalität vergessen.
Primärschlüssel Ausgewählter Schlüsselkandidat einer Tabelle. NULL oder Duplikate zulassen. Beides verletzt Entity-Integrität.
Fremdschlüssel Attribut, dessen Werte auf Primärschlüsselwerte einer anderen oder derselben Tabelle verweisen. Gleiche Spaltennamen erzwingen. Wichtig ist derselbe Wertebereich, nicht derselbe Name.
Künstlicher Schlüssel Zusätzlich eingeführter technischer Identifikator, etwa KundNr oder ArtikelNr. Künstliche Schlüssel lösen nicht automatisch fachliche Eindeutigkeit.

4. NoSQL-Abgrenzung und Big-Data-Motivation

NoSQL-Systeme entstehen aus Anforderungen, die mit klassischen relationalen Systemen schwer oder nur mit hohem Aufwand abbildbar sind: große Datenmengen, hohe Geschwindigkeit, flexible Strukturen, horizontale Skalierung und verteilte Speicherung. Im Skript wird das über die 6 V von Big Data motiviert.

Big-Data-Charakteristika Volume, Velocity, Variety, Veracity, Validity und Value
Die 6 V erklären, warum Datenbankarchitekturen nicht nur nach Tabellenfähigkeit, sondern auch nach Menge, Geschwindigkeit, Vielfalt, Qualität und Wertbeitrag bewertet werden.
NoSQL-Typ Datenmodell Stark bei Nicht ideal bei
Key-Value Store Schlüssel → Wert. Schnelle Lookups, Sessions, Warenkörbe, Caches. Komplexe Beziehungen, Joins, ausdrucksstarke Abfragen.
Document Store Geschlossene Dokumente, häufig JSON oder BSON. Semi-strukturierte, zusammengehörige Objekte mit flexiblen Feldern. Strenge referentielle Integrität über viele Dokumente.
Graphdatenbank Knoten, Kanten und Eigenschaften. Beziehungsgeflechte, Empfehlungen, soziale Netze, Wissensgraphen. Reine Massenscans ohne Beziehungslogik.
Visualisierung von Key-Value Store, Document Store und Graphdatenbank
Die NoSQL-Familien unterscheiden sich nicht nur technisch, sondern im Denkmodell: Schlüsselzugriff, Dokumenteinheit oder explizit gespeicherte Beziehung.
JSON-Beispiel eines verschachtelten Dokuments
Document Store: Zusammengehörige Daten werden als Dokument gespeichert. Verschachtelung ersetzt häufig Joins.
Property-Graph mit Employees, Departments, Locations und Beziehungen
Graphdatenbank: Beziehungen sind eigenständige, indexierte Datensätze und nicht nur Fremdschlüssel.
Prüfungsfalle: NoSQL heißt nicht "besser als SQL". Es heißt: andere Prioritäten. Häufig werden Schemaflexibilität, horizontale Skalierung und Verfügbarkeit gegen stärkere Konsistenz- und Integritätsmechanismen getauscht.

5. Datenbankentwurf und ERM

5.1 Entwurfsphasen

Der Datenbankentwurf beginnt nicht mit Tabellen. Zuerst wird die fachliche Realität eingegrenzt, anschließend abstrakt modelliert und erst danach in ein konkretes Datenbankschema überführt.

Phasen des Datenbankentwurfs Anforderungsanalyse, konzeptioneller Entwurf, logischer Entwurf, physischer Entwurf und Implementierung bauen aufeinander auf. Anforderungs- analyse Konzeptioneller Entwurf Logischer Entwurf Physischer Entwurf Betrieb Klausur: Die meisten Fehler entstehen durch zu frühes Springen von Fachtext zu Tabellen.
Die Folien betonen den Weg von der Fachanforderung über Miniwelt und ERM zum relationalen Schema.

5.2 Konzeptueller Entwurf

Im konzeptuellen Entwurf werden funktionale und informationelle Anforderungen der Use Cases erfasst. Implementierungsdetails spielen noch keine Rolle. Das Modell soll die betriebswirtschaftlich relevante Miniwelt so weit abstrahieren, dass die wesentlichen Strukturen erhalten bleiben, aber irrelevante Realität ausgeblendet wird.

Datenmodell: Formale Beschreibung der Daten, Beziehungen und Konstrukte, mit denen ein DBMS einen Ausschnitt der Realität abbilden kann.
Datenbankschema: Konkrete Struktur der Datenbasis für ein bestimmtes Datenbanksystem, inklusive Tabellen, Attribute, Schlüssel und Integritätsbedingungen.

5.3 Entity-Relationship-Modell

Das Entity-Relationship-Modell nach Chen ist ein semantisches Modell für konzeptuelle Schemata. Es ist als grafische Sprache geeignet, weil Fachabteilungen, Endanwender und Entwickler dieselbe Miniwelt diskutieren können.

ERM-Begriff Bedeutung Beispiel aus dem Skript
Entity Ein konkretes, abgrenzbares Objekt der Miniwelt. Ein bestimmter Lieferant oder ein bestimmter Artikel.
Entitytyp Abstraktion gleichartiger Entities. Lieferant, Artikel, Bestellung.
Attribut Eigenschaft eines Entitytyps oder Relationshiptyps. LieferantenNr, Name, Adresse, ArtikelNr, Preis, Liefermenge.
Relationship Konkrete Beziehung zwischen Entities. LSG Sky Chefs liefert Cola Dose 0,33l.
Relationshiptyp Abstraktion gleichartiger Beziehungen. Lieferant liefert Artikel.
ERM-Beispiel Lieferant liefert Artikel mit Attributen
ERM-Beispiel aus der Miniwelt Cateringsystem: Lieferant und Artikel sind Entitytypen, liefert ist Relationshiptyp, Liefermenge ist ein Beziehungsattribut.

5.4 Spezielle Attribute

Attributtyp Beschreibung Modellierungsfolge
Zusammengesetztes Attribut Wird in Folgeattribute zerlegt, etwa Adresse in Straße, PLZ und Ort. Nur so weit zerlegen, wie es fachlich gebraucht wird.
Mehrfachattribut Ein Entity kann mehrere Werte besitzen, etwa mehrere Telefonnummern. Im relationalen Modell meist eigene Tabelle, da ein Feld atomar sein muss.

6. Assoziationen, Kardinalitäten und ternäre Beziehungen

6.1 Assoziation und Standardkardinalität

Ein Beziehungstyp muss immer in beide Richtungen gelesen werden. Bei "Lieferant liefert Artikel" ist ebenso zu fragen: Von wie vielen Lieferanten kann ein Artikel geliefert werden? Und wie viele Artikel kann ein Lieferant liefern?

Kardinalität Lesart Beispiel Relationale Folge
1:1 Ein Entity steht höchstens mit einem Entity des anderen Typs in Beziehung. Mann - verheiratet - Frau, bezogen auf einen Zeitpunkt und ein passendes Rechtssystem. Fremdschlüssel in eine der Tabellen oder Zusammenlegung.
1:n Ein Entity auf der 1-Seite kann mit vielen Entities auf der n-Seite verbunden sein. Schulklasse - hat - Schüler. Primärschlüssel der 1-Seite als Fremdschlüssel in die n-Seite.
n:m Viele Entities auf beiden Seiten können miteinander verbunden sein. Lieferant - liefert - Artikel. Neue Beziehungstabelle mit beiden Fremdschlüsseln und Beziehungsattributen.
Prüfungsfalle: Die klassische Chen-Notation fragt vor allem nach Maximalitäten. Sie sagt nicht sauber, ob eine Beziehung optional oder verpflichtend ist. Genau dafür wird die MC-Notation präziser.

6.2 MC-Kardinalität

MC-Wert Bedeutung Beispielhafte Lesart
1 Genau eine Entität ist zugeordnet. Ein Mitarbeitender ist genau einer Abteilung unterstellt.
c Keine oder eine Entität ist zugeordnet. Nicht jeder Mitarbeitende leitet eine Abteilung.
m Eine oder mehrere Entitäten sind zugeordnet. Jedes Projekt muss mindestens einen Mitarbeitenden haben.
mc Keine, eine oder mehrere Entitäten sind zugeordnet. Mitarbeitende können an mehreren Projekten mitwirken, müssen aber nicht.

6.3 Spezielle Beziehungen

Fall Beschreibung Prüfungsfrage
Parallele Beziehungen Zwischen denselben Entitytypen bestehen mehrere Beziehungstypen. Sind die Beziehungen fachlich verschieden, etwa arbeitet an und leitet?
Rekursive Beziehung Ein Entitytyp steht mit sich selbst in Beziehung. Welche Rollen haben die beteiligten Entities?
Ternäre Beziehung Ein Relationshiptyp verbindet genau drei Entitytypen gleichzeitig. Geht Information verloren, wenn ich sie in binäre Beziehungen zerlege?

6.4 Ternäre Beziehungen und Connection Trap

Die Folien nutzen das Beispiel "Pilot fliegt ein spezifisches Flugzeug auf einer Flugroute". Drei getrennte binäre Beziehungen erfassen jeweils nur zwei Aspekte und verlieren den dritten. Dadurch entsteht eine Connection Trap: Aus den Daten ist nicht mehr rekonstruierbar, welcher Pilot mit welchem Flugzeug welche Flugroute fliegt.

Ternäre Beziehung fliegt Pilot, Flugzeug und Flugroute sind gleichzeitig an der Beziehung fliegt beteiligt. Pilot Flugzeug Flugroute fliegt Kardinalitäten werden ermittelt, indem jeweils zwei Entitys fixiert und das dritte Entity abgefragt wird.
Ternäre Beziehungen sind nötig, wenn die fachliche Aussage nur durch die gleichzeitige Betrachtung aller drei Entitytypen vollständig ist. Beispiel: Bei fixiertem Paar Pilot und Flugzeug wird gefragt, auf wie vielen Flugrouten dieses Paar fliegen kann.
Typische Klausuraufgabe: Aus einem Fachtext Entitytypen und Beziehungstypen bestimmen. Nomen sind häufig Entitytypen, Verben häufig Relationshiptypen. Das ist nur eine Heuristik: Fachliche Bedeutung entscheidet.

7. Generalisierung und Spezialisierung

Generalisierung fasst mehrere Subentitytypen zu einem Superentitytyp zusammen. Spezialisierung betrachtet die Gegenrichtung. Die Folien verwenden die IS-A-Struktur: Ein Oberstufenschüler ist ein Schüler. Subtypen erben Attribute des Supertyps und können eigene Attribute ergänzen.

Generalisierung und Spezialisierung am Beispiel Schüler, Oberstufenschüler und Mittelstufenschüler
IS-A-Struktur: Subentitytypen erben gemeinsame Eigenschaften des Superentitytyps.
Fall Bedeutung Beispiel aus dem Skript
Überlappend Eine Entität kann mehreren Subentitytypen angehören. Mitarbeiter kann Entwickler und Projektleiter sein.
Überlappend-vollständig Mehrfachzugehörigkeit möglich, aber jede Entität gehört mindestens einem Subtyp an. Fahrzeug als PKW und/oder Transporter.
Disjunkt Eine Entität darf höchstens einem Subtyp angehören. Konto ist Girokonto oder Sparkonto, nicht beides.
Disjunkt-vollständig Eine Entität gehört genau einem Subtyp an. Mitarbeiter ist Festangestellter oder Freelancer.

8. Normalisierung und Anomalien

8.1 Ziel der Normalisierung

Normalisierung strukturiert Relationen so, dass Redundanzen minimiert und Datenanomalien vermieden werden. Dafür werden Tabellen anhand von Normalformen in kleinere, logisch zusammenhängende Tabellen zerlegt. Im Skript werden vor allem unnormalisierte Form, 1NF, 2NF und 3NF prüfungsrelevant ausgearbeitet.

Merksatz Redundanz → Anomaliegefahr → Normalisierung → kleinere Relationen mit klaren Abhängigkeiten

8.2 Anomalien

Anomalie Beschreibung Beispiel aus dem Studiengangfall
Einfügeanomalie Information kann nicht eingefügt werden, weil ein anderer, unabhängiger Schlüsselteil fehlt. Ein neuer Studiengang kann nicht ohne Studierenden eingefügt werden, wenn MatNr Primärschlüssel ist.
Löschanomalie Beim Löschen eines Datensatzes gehen mehr Informationen verloren als beabsichtigt. Werden alle Studierenden gelöscht, verschwinden auch Studienganginformationen.
Änderungsanomalie Redundante Werte müssen an mehreren Stellen geändert werden. Studiengangname muss bei mehreren Studierenden geändert werden.

8.3 Normalformen

Normalform Bedingung Vorgehen Prüfungsfalle
Unnormalisierte Form Mindestens ein Feld enthält mehrere Werte oder Wiederholungsgruppen. Wiederholungsgruppen erkennen, etwa mehrere Mietwagen in einer Mieterzeile. Mehrere Werte in einer Zelle übersehen.
1. Normalform (1NF) Alle Attribute sind atomar: Jeder Schnittpunkt aus Zeile und Spalte enthält genau einen Wert. Für Wiederholungsgruppen eigene Tupel erzeugen. Im Mietwagenbeispiel wird der Schlüssel zu MNR plus WNR erweitert. 1NF kann Redundanz zunächst erhöhen. Das ist normal und wird in späteren Normalformen bereinigt.
2. Normalform (2NF) Relation ist in 1NF und jedes Nichtschlüsselattribut hängt voll funktional vom gesamten zusammengesetzten Schlüssel ab. Attribute, die nur von einem Teilschlüssel abhängen, in eigene Tabellen auslagern. Beziehungstabelle behält den zusammengesetzten Schlüssel. Bei einfachem Primärschlüssel ist eine Relation in 1NF automatisch in 2NF. 2NF-Probleme entstehen bei zusammengesetzten Schlüsseln.
3. Normalform (3NF) Relation ist in 2NF und kein Nichtschlüsselattribut hängt transitiv von einem anderen Nichtschlüsselattribut ab. Transitv abhängige Attribute und ihr bestimmendes Nichtschlüsselattribut in eigene Tabelle verschieben. Nichtschlüsselattribut → Nichtschlüsselattribut übersehen, etwa Fahrzeugtyp bestimmt Mietsatz.

8.4 Funktionale Abhängigkeiten im Mietwagenbeispiel

Ausgangsidee: In der 1NF identifizieren MNR und WNR gemeinsam einen Mietvorgang. MNA und BR hängen aber nur von MNR ab. FT, BJ, VS und MS hängen nur von WNR ab. MD hängt vom Mietvorgang, also von MNR und WNR ab. MNR, WNR → MD MNR → MNA, BR WNR → FT, BJ, VS, MS

Für die 2NF wird deshalb zerlegt in Mieter, Wagen und Mietvorgang. Für die 3NF wird weiter geprüft, ob innerhalb der ausgelagerten Tabellen ein Nichtschlüsselattribut ein anderes Nichtschlüsselattribut bestimmt. Wenn etwa Fahrzeugtyp FT den Mietsatz MS bestimmt, wird eine eigene Tabelle für diese Abhängigkeit angelegt.

Mietvorgang MNR, WNR, MD
Mieter MNR, MNA, BR
Wagen WNR, FT, BJ, VS
Mietsatz FT, MS

8.5 Vor- und Nachteile

Vorteile Nachteile Einordnung
Weniger Redundanz, bessere Integrität, einfachere Wartung einzelner Sachverhalte. Mehr Tabellen, komplexere Joins, mögliche Performancekosten bei sehr großen Datenmengen. Gut für transaktionsorientierte Systeme. Teilweise Denormalisierung kann bei Analyse, Reporting und Big Data sinnvoll sein.

9. Relationales Schema und Abbildungsregeln

9.1 Schema, Primärschlüssel und Fremdschlüssel

Im logischen Entwurf wird das ERM in ein relationales Datenbankschema überführt. Das Schema enthält Datenstrukturen und Integritätsbedingungen: Tabellen, Attribute mit Datentypen, Primärschlüssel, Fremdschlüssel und Constraints.

Fremdschlüssel: Attribut in einer Detailtabelle, das auf den Primärschlüssel einer Mastertabelle verweist. Der Fremdschlüssel muss nicht gleich heißen, aber auf derselben Domäne basieren.

9.2 Abbildungsregeln

ERM-Fall Relationale Abbildung Beispiel Prüfungsfalle
Entitytyp Jeder Entitytyp wird eine Tabelle. Attribute werden Spalten. Schlüssel wird Primärschlüssel. Lieferant(LNr, Name, Adresse), Artikel(ANr, Bezeichnung, Preis). Relationship-Attribute fälschlich in eine Entitytabelle schreiben.
1:1-Beziehung Primärschlüssel einer Tabelle als Fremdschlüssel in die andere aufnehmen oder Tabellen zusammenführen. Bei starker fachlicher Einheit kann Zusammenlegung sinnvoll sein. Optionalität ignorieren. Der Fremdschlüssel gehört oft auf die Seite, die optional oder fachlich abhängig ist.
1:n-Beziehung Primärschlüssel der 1-Seite wird Fremdschlüssel in der n-Seite. Klasse(KlasseNr, Raum), Schüler(SchülerNr, Name, KlasseNr). Fremdschlüssel versehentlich in die 1-Seite setzen.
n:m-Beziehung Neue Assoziationstabelle. Sie enthält die Primärschlüssel beider Entitytypen als Fremdschlüssel. Zusammen bilden sie häufig den zusammengesetzten Primärschlüssel. Lieferung(LNr, ANr, Liefermenge). n:m direkt als Fremdschlüssel in einer der beiden Tabellen abbilden. Das erzeugt Wiederholungsgruppen oder Informationsverlust.
n:m-Abbildung Lieferant und Artikel werden über eine Beziehungstabelle Lieferung verbunden. Lieferant LNr (PK) Name Adresse Lieferung LNr (PK, FK) ANr (PK, FK) Liefermenge Artikel ANr (PK) Bezeichnung Preis 1:n n:1 Die ursprüngliche n:m-Beziehung wird in zwei 1:n-Beziehungen aufgelöst.
Die Beziehungstabelle enthält auch Attribute der Beziehung, zum Beispiel Liefermenge.

10. Integrität, Konsistenz und Constraints

10.1 Integritätsarten

Integritätsart Fokus Typische Umsetzung Beispiel
Domain-Integrität Gültigkeit einzelner Attributwerte. Datentyp, Wertebereich, Format, NOT NULL, DEFAULT, CHECK. Alter muss größer oder gleich 18 sein; Name darf nicht leer sein.
Entity-Integrität Eindeutige Identifikation jeder Zeile. Primärschlüssel eindeutig und nie NULL. Keine zwei Schüler mit derselben SchülerNr.
Referentielle Integrität Korrekte Beziehungen zwischen Tabellen. Fremdschlüssel verweist auf existierenden Primärschlüssel oder ist NULL, falls erlaubt. Schüler.KlasseNr muss in Klasse.KlasseNr existieren.
Benutzerdefinierte Integrität Fachliche Regeln, die nicht vollständig durch Standards abgedeckt sind. Anwendungslogik, Trigger, prozedurale Constraints. Ein Kunde darf erst ab 18 Jahren bestimmte Produkte bestellen.

10.2 Referentielle Integrität: Lösch-, Änderungs- und Einfügeregeln

Regel RESTRICT / NO ACTION CASCADE SET NULL
Löschen Masterdatensatz darf nicht gelöscht werden, solange Details existieren. Detaildatensätze werden automatisch mitgelöscht. Fremdschlüssel der Details wird NULL, wenn Domain-Integrität das erlaubt.
Ändern Änderung wird verhindert, wenn verwaiste Fremdschlüssel entstehen würden. Fremdschlüssel werden automatisch aktualisiert. Seltener Fall; nur möglich, wenn NULL fachlich erlaubt ist.
Einfügen Detaildatensatz darf nur mit existierendem Master eingefügt werden. Nicht passend als Einfügelogik. NULL nur bei optionaler Beziehung und erlaubtem NULL-Wert.

10.3 Konsistenz vs. Integrität

Merkmal Konsistenz Integrität
Fokus Zustand der Daten zu einem Zeitpunkt. Regeln und Mechanismen, die korrekte Zustände sichern.
Rolle Ergebnis der Einhaltung von Regeln. Voraussetzung für Konsistenz.
Zeitpunkt Laufzeitbetrieb und Transaktionen. Design des Schemas und laufende Prüfung durch DBMS oder Anwendung.
ACID-Bezug Eine Transaktion muss einen konsistenten Zustand in einen anderen konsistenten Zustand überführen. Constraints definieren, welche Zustände zulässig sind.
Prüfungsfalle: Integrität ist nicht dasselbe wie Konsistenz. Integritätsregeln sind die Ursache, Konsistenz ist der Zustand, der durch Einhaltung dieser Regeln entsteht.

11. Relationenalgebra

11.1 Warum die Mathematik wichtig ist

Die Relationenalgebra ist die formale Grundlage relationaler Abfragen. Sie übersetzt Fachfragen in eine präzise Struktur und bildet damit die Brücke zu SQL. Jede Operation erzeugt wieder eine Relation, die als Eingabe für weitere Operationen dienen kann.

Brücke zwischen Fachdomäne und SQL Domänenwissen → Relationenalgebra → formale Struktur → SQL → Ergebnisrelation

11.2 Relationenoperatoren

Operator Symbol Funktion Businessfrage Notation
Projektion π Wählt Attribute aus und entfernt Duplikate. Welche Namen und Städte haben unsere Kunden? πName, Stadt(Kunden)
Selektion σ Filtert Tupel nach einer Bedingung. Welche Kunden wohnen in Berlin? σStadt='Berlin'(Kunden)
(Equi-)Join ⋈ Verknüpft Relationen über ein Gleichheitsprädikat, häufig Primärschlüssel-Fremdschlüssel. Zeige Kunden mit ihren Bestellungen. Kunden ⋈Kunden.K_ID=Bestellungen.K_ID Bestellungen
Kartesisches Produkt × Kombiniert alle Tupel zweier Relationen. Prüfe alle Kombinationen von Kunden und Lieferungen. Kunden × Lieferungen
Zusammenfassung der Relationenoperatoren Projektion, Selektion, Join und kartesisches Produkt
Originalübersicht der Relationenoperatoren aus dem Skript. In der Klausur sind Funktion, Symbol und fachliche Lesart wichtig.
Prüfungsfalle: Projektion filtert Spalten, Selektion filtert Zeilen. In SQL wirkt SELECT sprachlich ähnlich wie Selektion, entspricht in der relationalen Algebra aber primär der Projektion.

11.3 Mengenoperatoren

Mengenoperatoren arbeiten auf ganzen Mengen von Tupeln und setzen schema-kompatible Relationen voraus: gleiche Anzahl von Attributen und kompatible Datentypen.

Operator Symbol Definition Beispiel
Vereinigung ∪ Alle Tupel aus A oder B, Duplikate werden eliminiert. πStadt(Kunden) ∪ πStadt(Lieferungen)
Durchschnitt ∩ Nur Tupel, die in A und B vorkommen. πStadt(Kunden) ∩ πStadt(Lieferungen)
Differenz \ Tupel aus A, die nicht in B vorkommen. πStadt(Kunden) \ πStadt(Lieferungen)
Symmetrische Differenz ⊕ In A oder B, aber nicht in beiden. (A \ B) ∪ (B \ A) = (A ∪ B) \ (A ∩ B)
Zusammenfassung Mengenoperatoren
Übersicht zu Vereinigung, Schnittmenge und Differenz.
Venn-Diagramm der symmetrischen Differenz
XOR als symmetrische Differenz: Bereiche in genau einer der beiden Mengen.

11.4 Logische Operatoren

Operator Symbol Bedeutung Beispiel in Selektion
AND ∧ Alle Bedingungen müssen wahr sein. σStadt='Berlin' ∧ Alter>30(Kunden)
OR ∨ Mindestens eine Bedingung muss wahr sein. σStadt='Berlin' ∨ Alter>30(Kunden)
NOT ¬ Bedingung wird negiert. σ¬(Stadt='Berlin')(Kunden)
XOR ⊕ Genau eine von zwei Bedingungen ist wahr, aber nicht beide. σ(A∨B)∧¬(A∧B)(Kunden)
Zusammenfassung logischer Operatoren AND OR NOT XOR
Logische Operatoren werden vor allem innerhalb von Selektionsbedingungen eingesetzt.

11.5 XOR mit drei Mengen

Für drei Mengen bedeutet XOR im Skript: ausgewählt werden die Bereiche mit genau einem erfüllten Merkmal plus der Bereich, in dem alle drei Merkmale erfüllt sind. Das folgt aus der Parität des exklusiven Oder.

Drei-Mengen-XOR aus dem Skript A ⊕ B ⊕ C = (A ∩ Bc ∩ Cc) ∪ (Ac ∩ B ∩ Cc) ∪ (Ac ∩ Bc ∩ C) ∪ (A ∩ B ∩ C)
A
Menge der Kunden mit Merkmal A, im Beispiel männliche Kunden.
B
Menge der Kunden mit Merkmal B, im Beispiel Wohnort Ravensburg.
C
Menge der Kunden mit Merkmal C, im Beispiel Alter unter 30.
Ac
Komplement von A, also alle Kunden außerhalb von A.
Venn-Diagramm fuer A XOR B XOR C
Die markierten Teilmengen zeigen die im Skript behandelte Drei-Mengen-XOR-Auswahl.

12. Rechenregeln und SQL-Sneak-Preview

12.1 Prioritäten

Für logische Ausdrücke gilt im Skript die Priorität: Klammer vor NOT vor AND vor OR vor XOR. Klammern sind in Klausurantworten kein Zeichen von Unsicherheit, sondern verhindern Mehrdeutigkeit.

Prüfungsfalle: A ∪ B ∩ C ist ohne Klammern nicht dasselbe wie (A ∪ B) ∩ C. Nach Priorität wird zuerst B ∩ C gebildet.

12.2 Distributivgesetz und De Morgan

Regel Mengenform Logische Lesart
Distributiv 1 A ∩ (B ∪ C) = (A ∩ B) ∪ (A ∩ C) A und mindestens eines aus B oder C.
Distributiv 2 A ∪ (B ∩ C) = (A ∪ B) ∩ (A ∪ C) A oder beide Bedingungen B und C.
De Morgan 1 (A ∪ B)c = Ac ∩ Bc Nicht A oder B heißt: nicht A und nicht B.
De Morgan 2 (A ∩ B)c = Ac ∪ Bc Nicht A und B heißt: nicht A oder nicht B.
Mengenregeln mit Idempotenz, Assoziativgesetz, Kommutativgesetz, Distributivgesetz und De Morgan
Die Rechenregeln gelten weitgehend in Mengen- und Logiknotation. In Aufgaben muss die fachliche Lesart erhalten bleiben.
Venn-Diagramm zum Distributivgesetz
Distributivgesetz: A ∩ (B ∪ C) als markierter Bereich.
Venn-Diagramm zu De Morgan
De Morgan: Komplement einer Vereinigung entspricht Schnitt der Komplemente.

12.3 SQL als deskriptive Sprache

SQL beschreibt, welche Daten benötigt werden und welche Bedingungen sie erfüllen müssen. Der genaue Suchweg wird nicht programmiert; diesen bestimmt die Datenbank-Engine. Genau darin liegt der Unterschied zu prozeduralen Ansätzen, bei denen Entwickler den Weg selbst festlegen.

Vergleich natuerliche Sprache, deskriptive SQL-Sprache und prozedurale Sprache
Deskriptive Sprache: Die Abfrage beschreibt das gewünschte Ergebnis, nicht die einzelnen Ausführungsschritte.
SELECT Name
FROM Mitarbeitende
WHERE Ort = 'Liestal';
Musterübersetzung: Fachfrage "Welche Kunden aus Berlin sind älter als 30 und haben Bestellungen?" wird formal zu einer Kombination aus Join, Selektion und Projektion: πName(σStadt='Berlin' ∧ Alter>30(Kunden ⋈Kunden.K_ID=Bestellungen.K_ID Bestellungen))

13. Lerncheckliste und mögliche Klausurfragen

13.1 Lerncheckliste

  • Ich kann Daten, Information, Wissen, Datenbank und Datenbanksystem sauber unterscheiden.
  • Ich kann relationale Datenbanken, Key-Value Stores, Document Stores und Graphdatenbanken anhand von Datenmodell, Abfragesprache, Beziehungen und Skalierung vergleichen.
  • Ich kann aus Fachtexten Entitytypen, Relationshiptypen, Attribute und Schlüssel ableiten.
  • Ich kann 1:1, 1:n, n:m, MC-Kardinalitäten, rekursive, parallele und ternäre Beziehungen begründen.
  • Ich erkenne Connection Traps bei falscher Zerlegung ternärer Beziehungen.
  • Ich kann Generalisierung nach überlappend, vollständig und disjunkt klassifizieren.
  • Ich kann Anomalien erklären und Tabellen bis zur 3NF zerlegen.
  • Ich kann ERM-Regeln in relationale Tabellen, Primärschlüssel, Fremdschlüssel und Beziehungstabellen überführen.
  • Ich kann Domain-, Entity-, referentielle und benutzerdefinierte Integrität unterscheiden.
  • Ich kann Projektion, Selektion, Join, kartesisches Produkt, Mengenoperatoren und logische Operatoren anwenden.
  • Ich kann Prioritäten, Distributivgesetz und De Morgan fachlich korrekt lesen.
  • Ich kann eine natürliche Fachfrage in relationale Algebra und eine SQL-Grundstruktur übersetzen.

13.2 Mögliche Klausurfragen

  1. Grenzen Sie Daten, Information und Wissen anhand eines eigenen Beispiels ab.
  2. Vergleichen Sie relationale Datenbanken mit Document Stores und Graphdatenbanken anhand eines Anwendungsszenarios.
  3. Erstellen Sie aus einer kurzen Fachanforderung ein ER-Diagramm mit Entitytypen, Relationshiptypen, Attributen und Schlüsseln.
  4. Bestimmen und begründen Sie Kardinalitäten in beide Richtungen.
  5. Erklären Sie, warum eine bestimmte Beziehung ternär modelliert werden muss.
  6. Wandeln Sie ein ERM mit n:m-Beziehung in ein relationales Schema um.
  7. Erkennen Sie Einfüge-, Lösch- und Änderungsanomalien in einer Tabelle.
  8. Normalisieren Sie eine Relation mit zusammengesetztem Schlüssel bis zur 3NF.
  9. Definieren Sie passende Domain-, Entity- und referentielle Integritätsregeln für ein Schema.
  10. Formulieren Sie eine Fachfrage als relationale Algebra mit Projektion, Selektion und Join.
  11. Zeichnen oder interpretieren Sie ein Venn-Diagramm für XOR, Distributivgesetz oder De Morgan.
  12. Erklären Sie, warum SQL als deskriptive Sprache gilt.

13.3 Abdeckungstabelle

Folie/Kapitel Inhalt In Zusammenfassung enthalten? Wo behandelt?
1Titel und Kontext: Datenbanken, Teil relationale DatenbankenJaHeader, Abschnitt 1
2-5Gliederung und BasisliteraturJaAbschnitt 1, Abdeckungstabelle
6Übergangs-/Bildfolie ohne eigenständigen TextinhaltJaAls nicht fachlich eigenständige Übergangsfolie berücksichtigt
7-12Daten, Datenarten, Information, Wissen, Datenbank, Datenbanksystem, Eigenschaften von InformationJaAbschnitt 2
13-20Datenbankarten, relationale Datenbanken, Relationenmodell, Domänen, Schlüssel, SQLJaAbschnitte 3 und 4
21-28Big Data, 6 V, NoSQL, Key-Value, Document Store, Graphdatenbank, VergleichJaAbschnitt 4 mit Originalgrafiken
29-32Phasen des Datenbankentwurfs, Use Cases, Datenmodelle, SchemaJaAbschnitt 5.1 bis 5.2
34-43ERM-Grundlagen, Cateringsystem, Entity, Entitytyp, Attribute, Relationships, Schlüssel, ERDJaAbschnitt 5.3 bis 5.4 mit Original-ERM-Grafik
45-52Assoziationen, Kardinalitäten, MC-Kardinalität, parallele und rekursive BeziehungenJaAbschnitt 6.1 bis 6.3
53-57Übungen zur Kardinalität und ER-ModellierungJaAbschnitt 6, typische Klausuraufgabe
58-62Ternäre Beziehungen, Connection Trap, ternäre KardinalitätenJaAbschnitt 6.4 mit Diagramm
64-68Generalisierung, Spezialisierung, überlappend, vollständig, disjunktJaAbschnitt 7 mit Originalgrafik
70-72Logischer Entwurf, Relationenmodell, NormalisierungsüberblickJaAbschnitte 3.2 und 8.1
73-76Redundanz, Einfüge-, Lösch- und ÄnderungsanomalieJaAbschnitt 8.2
77-83Unnormalisierte Form, 1NF, 2NF, 3NF, MietwagenbeispielJaAbschnitt 8.3 bis 8.4
84-86Vorteile, Nachteile und Fazit Normalisierung/DenormalisierungJaAbschnitt 8.5
88-90Relationales Schema, Datenstrukturen, Primär- und FremdschlüsselJaAbschnitt 9.1
92-95Abbildungsregeln für Entitytypen, 1:1, 1:n und n:mJaAbschnitt 9.2
97-109Integritätsregeln, Domain-, Entity-, referentielle und benutzerdefinierte Integrität, KonsistenzJaAbschnitt 10
111-114Warum Relationenalgebra, Operatorarten, Priorität der OperatorenJaAbschnitt 11.1 bis 11.2
115-121Projektion, Selektion, Join, kartesisches Produkt, ZusammenfassungJaAbschnitt 11.2 mit Originaltabelle
123-131Mengenoperatoren, Vereinigung, Durchschnitt, Differenz, XORJaAbschnitt 11.3 mit Originalgrafiken
133-142Logische Operatoren AND, OR, NOT, XOR, Drei-Mengen-XOR-AufgabeJaAbschnitt 11.4 bis 11.5
144-149Prioritätsregel, Distributivgesetz, De Morgan, Venn-DiagrammeJaAbschnitt 12.1 bis 12.2
151-152SQL als deskriptive Sprache, natürliche Sprache vs. SQL vs. prozedurale SpracheJaAbschnitt 12.3
153KontaktfolieJaNicht fachlich klausurrelevant, im Quellenumfang berücksichtigt
154-155Backup und Übung zu Relationenalgebra, Distributivgesetz und FachanforderungJaAbschnitte 11, 12 und 13.2
156Linksammlung zu Venn-DiagrammenJaAbschnitt 12 und Lerncheckliste