Datenbanken - Theorie

Question:
# Prüfungskern
Welche Denkkette solltest du bei Datenbank-Theorieaufgaben anwenden?

Answer:
Fachliche Aufgaben werden schrittweise übersetzt:

1. **Fachanforderung verstehen**
2. **Miniwelt abgrenzen**
3. **Entitytypen, Relationshiptypen, Attribute und Schlüssel bestimmen**
4. **Kardinalitäten in beide Richtungen prüfen**
5. **Relationales Schema ableiten**
6. **Normalisierung und Integrität prüfen**
7. **Fachfrage als Relationenalgebra oder SQL-Grundstruktur formulieren**

Prüfungsfalle: Nicht direkt vom Fachtext zu Tabellen springen.


Datenbanken - Theorie

Question:
# Daten, Information, Wissen
Wie unterscheiden sich Daten, Information und Wissen?

Answer:
- **Daten:** formalisierte Rohwerte ohne zwingenden Kontext, z. B. `37`.
- **Information:** Daten mit Bedeutung/Kontext, z. B. `37 °C Temperatur`.
- **Wissen:** vernetzte Informationen plus Handlungsregel, z. B. `Bei 37 °C muss der Server gekühlt werden`.

Kernidee: Bedeutung entsteht durch Kontext, nicht durch Speicherung allein.


Datenbanken - Theorie

Question:
# Datenbank vs. Datenbanksystem
Was ist der Unterschied zwischen Datenbank und Datenbanksystem?

Answer:
- **Datenbank:** organisierte Sammlung logisch zusammenhängender Daten inklusive Beschreibung/Metadaten.
- **Datenbanksystem:** Software zur applikationsunabhängigen Beschreibung, Speicherung, Verwaltung und Abfrage dieser Daten.

Ein Datenbanksystem enthält eine Speicherungs- und eine Verwaltungskomponente. Die Verwaltungskomponente stellt Abfrage-/Manipulationssprache sowie Zugriffs- und Rechteverwaltung bereit.


Datenbanken - Theorie

Question:
# Eigenschaften von Information
Welche Eigenschaften unterscheiden Information von materiellen Gütern?

Answer:
Information ist:

- durch Daten darstellbar
- algorithmisch verarbeitbar
- beliebig kombinierbar
- kopierbar ohne echtes Original
- nicht an einen fixen Träger gebunden
- potenziell vage oder qualitätsabhängig
- fachlich alternd, aber nicht physikalisch alternd

Prüfungsbezug: Datenqualität, Integrität, Kontext und Zugriffsschutz sind genauso wichtig wie Speicherung.


Datenbanken - Theorie

Question:
# Datenarten
Wie unterscheiden sich strukturierte, halbstrukturierte und unstrukturierte Daten?

Answer:
| Datenart | Beschreibung | Beispiel |
|---|---|---|
| Strukturiert | Explizites Schema mit Attributen und Datentypen | Kundentabelle, Excel |
| Halbstrukturiert | Erkennbare Struktur, aber nicht streng tabellarisch | JSON, XML |
| Unstrukturiert | Kein festes fachliches Schema | Bilder, Videos, E-Mails |

Prüfungsfalle: Halbstrukturierte Daten bedeuten nicht automatisch NoSQL.


Datenbanken - Theorie

Question:
# Relationale Datenbanken
Welche Kerneigenschaften haben relationale Datenbanken?

Answer:
Relationale Datenbanken haben typischerweise:

- Tabellenmodell: Daten und Beziehungen werden als Relationen dargestellt
- fixes Schema mit Tabellen, Attributen, Datentypen und Schlüsseln
- SQL für Definition, Abfrage und Manipulation
- hohe Datenunabhängigkeit zwischen Daten und Anwendungen
- Mehrbenutzerbetrieb, Datenschutz und Datensicherheit
- Integritäts- und Konsistenzmechanismen

NoSQL-Systeme erfüllen diese Eigenschaften bewusst nur teilweise.


Datenbanken - Theorie

Question:
# Relation, Tupel, Attribut
Was bedeuten Relation, Tupel und Attribut?

Answer:
- **Relation:** Tabelle mit eindeutigem Namen.
- **Tupel:** Zeile einer Relation; zwei Tupel dürfen nicht vollständig identisch sein.
- **Attribut:** Spalte einer Relation; beschreibt eine Eigenschaft der Tupel.

Wichtig: Die Reihenfolge von Tupeln und Attributen ist im Relationenmodell grundsätzlich irrelevant.


Datenbanken - Theorie

Question:
# Domäne
Was ist eine Domäne im relationalen Modell?

Answer:
Eine **Domäne** ist der zulässige Wertebereich eines Attributs. Sie umfasst typischerweise:

- Datentyp
- minimale und maximale Werte
- Formatierung
- Zulässigkeit von `NULL`
- Integritätsregeln

Beispiel Temperatur: Datentyp Zahl, Wertebereich `-50 °C` bis `+60 °C`, Format `0,1 °C`, ggf. `NULL` erlaubt.


Datenbanken - Theorie

Question:
# Identifikationsschlüssel
Welche zwei Eigenschaften muss ein Schlüssel erfüllen?

Answer:
Ein Identifikationsschlüssel muss erfüllen:

1. **Eindeutigkeit:** Jeder Schlüsselwert identifiziert genau ein Tupel.
2. **Minimalität:** Bei zusammengesetzten Schlüsseln darf kein Attribut entfernbar sein, ohne Eindeutigkeit zu verlieren.

Prüfungsfalle: Eindeutig ist nicht automatisch minimal.


Datenbanken - Theorie

Question:
# Schlüsselattribute
Was sind Schlüsselattribute und Nichtschlüsselattribute?

Answer:
- **Schlüsselattribute:** Attribute, die Bestandteil eines Schlüssels sind.
- **Nichtschlüsselattribute:** alle anderen Attribute einer Relation.

Diese Unterscheidung ist besonders wichtig bei der Normalisierung:

- 2NF prüft Abhängigkeiten von Nichtschlüsselattributen vom gesamten Schlüssel.
- 3NF prüft Abhängigkeiten zwischen Nichtschlüsselattributen.

Zusammenfassung §3.3 und §8.3; Skript Folien 19, 79-82


Datenbanken - Theorie

Question:
# SQL als Sprache
Warum gilt SQL als deklarative und mengenorientierte Sprache?

Answer:
SQL ist **deklarativ**, weil die Abfrage beschreibt, **was** geliefert werden soll, nicht **wie** das DBMS intern suchen muss.

SQL ist **mengenorientiert**, weil Abfragen auf Mengen von Datensätzen wirken und wieder Mengen bzw. Tabellen zurückgeben.

Prüfungsfalle: Nicht prozedurale Einzelschritte formulieren, wenn eine deskriptive Anfrage gefragt ist.

Zusammenfassung §3.1 und §12.3; Skript Folien 20, 151-152


Datenbanken - Theorie

Question:
# Big Data 6 V
Welche 6 V motivieren NoSQL- und Big-Data-Architekturen?

Answer:
Die Folien nennen:

- **Volume:** Menge an Daten
- **Velocity:** Geschwindigkeit der Erzeugung und Verarbeitung
- **Variety:** unterschiedliche Datentypen und Quellen
- **Veracity:** Richtigkeit/Echtheit
- **Validity:** Aussagekraft und Qualität
- **Value:** wirtschaftlicher Wert

Kernidee: Nicht nur Datenmenge, sondern auch Struktur, Geschwindigkeit und Qualität treiben Datenbankentscheidungen.


Datenbanken - Theorie

Question:
# NoSQL
Was bedeutet NoSQL im Skript?

Answer:
NoSQL bezeichnet nicht-relationale Ansätze, bei denen mindestens eine Bedingung erfüllt ist:

- Speicherung erfolgt nicht in Tabellen.
- Datenbanksprache ist nicht SQL.

Typische Eigenschaften: flexibles Schema, horizontale Skalierung, Replikation, Unterstützung großer und heterogener Datenbestände.

Prüfungsfalle: NoSQL heißt nicht automatisch besser, sondern anders priorisiert.


Datenbanken - Theorie

Question:
# CAP-Bezug bei NoSQL
Warum ist Konsistenz bei NoSQL-Systemen oft anders gewichtet?

Answer:
In verteilten Systemen stehen Konsistenz, Verfügbarkeit und Partitionstoleranz in Spannung. Wenn hohe Verfügbarkeit und Ausfalltoleranz wichtiger sind, wird Konsistenz häufig nur verzögert erreicht.

Im Skript wird das als **weak consistency** bzw. später im Kontext verteilter Systeme als eventual-consistency-Denken erwähnt.

Prüfungsfalle: Verteilte Skalierung ist nicht kostenlos.


Datenbanken - Theorie

Question:
# Key-Value Store
Wie funktioniert ein Key-Value Store?

Answer:
Ein Key-Value Store speichert Daten als **Schlüssel-Wert-Paare**.

Stark bei:

- sehr schnellen einfachen Lookups
- Sessions
- Warenkörben
- Caches

Schwach bei:

- komplexen Beziehungen
- Joins
- ausdrucksstarken fachlichen Abfragen


Datenbanken - Theorie

Question:
# Document Store
Was ist die Grundidee einer Dokumentendatenbank?

Answer:
Document Stores speichern zusammengehörige Informationen als geschlossene Dokumente, häufig in JSON oder BSON.

Eigenschaften:

- flexible Dokumentstruktur
- verschachtelte Objekte möglich
- Dokument als fachliche Einheit
- Abfragen z. B. über MongoDB Query Language

Prüfungsfalle: Dokumente ersetzen nicht automatisch saubere Modellierung; Beziehungen und Integrität bleiben zu prüfen.


Datenbanken - Theorie

Question:
# Graphdatenbank
Wofür sind Graphdatenbanken besonders geeignet?

Answer:
Graphdatenbanken modellieren Daten als **Knoten**, **Kanten** und **Eigenschaften**.

Sie sind stark bei:

- sozialen Netzwerken
- Empfehlungen
- Wissensgraphen
- komplexen Beziehungsgeflechten

Unterschied zu relationalen DB: Beziehungen sind eigenständige, indexierte Datensätze und nicht nur Fremdschlüsselreferenzen.


Datenbanken - Theorie

Question:
# SQL vs. NoSQL
Wann passt relational, wann NoSQL?

Answer:
- **Relational:** strukturierte Daten, klares Schema, Integrität, Joins, Transaktionen, konsistente Geschäftsprozesse.
- **Key-Value:** einfache schnelle Schlüsselzugriffe.
- **Document Store:** flexible semi-strukturierte Dokumente.
- **Graphdatenbank:** stark vernetzte Daten und Beziehungsauswertung.

Prüfungstechnik: Entscheidung immer mit Datenform, Zugriffsmuster, Beziehungen, Integritätsbedarf und Skalierung begründen.


Datenbanken - Theorie

Question:
# Datenbankentwurf
Welche Phasen durchläuft der Datenbankentwurf?

Answer:
Typische Kette:

1. **Anforderungsanalyse**
2. **Konzeptioneller Entwurf**
3. **Logischer Entwurf**
4. **Physischer Entwurf**
5. **Implementierung/Betrieb**

Klausurpunkt: Im konzeptionellen Entwurf werden Fachanforderungen modelliert, noch keine konkreten Tabellen optimiert.


Datenbanken - Theorie

Question:
# Konzeptueller Entwurf
Was wird im konzeptuellen Datenbankentwurf erfasst?

Answer:
Im konzeptuellen Entwurf werden funktionale und informationelle Anforderungen aus Use Cases analysiert.

Wichtig:

- Fachdomäne verstehen
- relevante Miniwelt abgrenzen
- Daten und Beziehungen modellieren
- Implementierungsdetails ausblenden
- aktuelle und vorhersehbare zukünftige Use Cases berücksichtigen

Das ERM ist dafür ein zentrales Werkzeug.


Datenbanken - Theorie

Question:
# Datenmodell vs. Datenbankschema
Wie unterscheiden sich Datenmodell und Datenbankschema?

Answer:
- **Datenmodell:** formale Art, Daten und Beziehungen zu beschreiben, z. B. relationales Modell oder ERM.
- **Datenbankschema:** konkrete Struktur einer bestimmten Datenbasis, z. B. Tabellen, Attribute, Schlüssel und Constraints.

Merksatz: Modell ist die Sprache, Schema ist der konkrete Satz in dieser Sprache.


Datenbanken - Theorie

Question:
# ERM
Warum wird das Entity-Relationship-Modell verwendet?

Answer:
Das ERM ist ein semantisches Datenmodell zur abstrakten Modellierung konzeptueller Schemata.

Vorteile:

- weit verbreitet
- grafische Repräsentation als visuelle Sprache
- für Fachabteilungen verständlich
- erleichtert Diskussion über die Miniwelt
- kann in relationale, Graph- oder Dokumentmodelle überführt werden

Prüfungsfalle: ERM ist konzeptionell, nicht schon physische Datenbankstruktur.


Datenbanken - Theorie

Question:
# Miniwelt
Was bedeutet Miniwelt in der ER-Modellierung?

Answer:
Die Miniwelt ist der für die Aufgabe relevante Ausschnitt der Realität.

Sie begrenzt:

- welche Objekte betrachtet werden
- welche Beziehungen relevant sind
- welche Attribute modelliert werden
- welche fachlichen Regeln gelten

Klausurhinweis: Nicht die ganze Realität modellieren, sondern den fachlich geforderten Ausschnitt.

Zusammenfassung §5.2-5.3; Skript Folien 35-37


Datenbanken - Theorie

Question:
# Entity und Entitytyp
Was ist der Unterschied zwischen Entity und Entitytyp?

Answer:
- **Entity:** konkretes abgrenzbares Objekt der Miniwelt, z. B. ein konkreter Lieferant.
- **Entitytyp:** Abstraktion gleichartiger Entities, z. B. `Lieferant`, `Artikel`, `Bestellung`.

Prüfungstechnik: Konkrete Beispiele sind Entities; Klassen gleichartiger Objekte sind Entitytypen.


Datenbanken - Theorie

Question:
# Attribute und Attributwerte
Was beschreiben Attribute im ERM?

Answer:
Attribute beschreiben Eigenschaften eines Entitytyps oder Relationshiptyps.

Beispiel `Lieferant`:

- `LieferantenNr`
- `Name`
- `Adresse`

Ein **Attributwert** ist die konkrete Ausprägung, z. B. `LSG Sky Chefs` als Wert des Attributs `Name`.


Datenbanken - Theorie

Question:
# Relationship und Relationshiptyp
Wie unterscheiden sich Relationship und Relationshiptyp?

Answer:
- **Relationship:** konkrete Beziehung zwischen konkreten Entities, z. B. `LSG Sky Chefs liefert Cola Dose 0,33l`.
- **Relationshiptyp:** Abstraktion gleichartiger Beziehungen, z. B. `Lieferant liefert Artikel`.

Wichtig: Auch Relationshiptypen können eigene Attribute besitzen, z. B. `Liefermenge`.


Datenbanken - Theorie

Question:
# Spezielle Attribute
Was sind zusammengesetzte Attribute und Mehrfachattribute?

Answer:
- **Zusammengesetztes Attribut:** kann sinnvoll in Folgeattribute zerlegt werden, z. B. Adresse in Straße, PLZ und Ort.
- **Mehrfachattribut:** kann mehrere Werte für ein Entity haben, z. B. mehrere Telefonnummern.

Relationaler Bezug: Mehrfachattribute führen oft zu eigenen Tabellen, weil Felder atomar sein müssen.


Datenbanken - Theorie

Question:
# Schlüssel im ERM
Wie wird ein Schlüssel im ERM verstanden?

Answer:
Ein Schlüssel ist eine minimale Attributmenge, deren Werte ein Entity eindeutig innerhalb seines Entitytyps identifizieren.

Gibt es mehrere mögliche Schlüssel, heißen sie **Schlüsselkandidaten**. Einer davon wird ausgewählt.

In ER-Diagrammen werden Schlüsselattribute häufig unterstrichen. In der Praxis werden oft künstliche Schlüssel wie `KundenNr` oder `ArtikelNr` eingeführt.


Datenbanken - Theorie

Question:
# Assoziation
Warum muss eine Beziehung im ERM in beide Richtungen gelesen werden?

Answer:
Ein Beziehungstyp enthält zwei gerichtete Teilfragen.

Beispiel `Lieferant liefert Artikel`:

- Wie viele Artikel kann ein Lieferant liefern?
- Von wie vielen Lieferanten kann ein Artikel geliefert werden?

Nur beide Richtungen zusammen ergeben die korrekte Kardinalität.

Zusammenfassung §6.1; Skript Folien 45-46


Datenbanken - Theorie

Question:
# Kardinalitäten
Was bedeuten 1:1, 1:n und n:m?

Answer:
| Kardinalität | Bedeutung | Beispiel |
|---|---|---|
| 1:1 | Ein Entity steht höchstens mit einem Entity des anderen Typs in Beziehung | Ehepartner bezogen auf einen Zeitpunkt |
| 1:n | Ein Entity der 1-Seite kann viele der n-Seite haben | Schulklasse hat Schüler |
| n:m | Viele Entities auf beiden Seiten können verbunden sein | Lieferant liefert Artikel |

Prüfung: Immer beide Richtungen fachlich begründen.

Zusammenfassung §6.1; Skript Folien 47-50


Datenbanken - Theorie

Question:
# MC-Kardinalität
Was präzisiert die MC-Kardinalität?

Answer:
MC-Kardinalitäten ergänzen die Frage, ob Beziehungen optional oder verpflichtend sind:

- **1:** genau eine Entität
- **c:** keine oder eine Entität
- **m:** eine oder mehrere Entitäten
- **mc:** keine, eine oder mehrere Entitäten

Klausurpunkt: Klassische 1/n-Notation zeigt Maximalitäten, MC-Notation zeigt zusätzlich Optionalität und Pflicht.


Datenbanken - Theorie

Question:
# Parallele und rekursive Beziehungen
Was sind parallele und rekursive Beziehungen?

Answer:
- **Parallele Beziehungen:** Zwischen denselben Entitytypen bestehen mehrere fachlich verschiedene Relationshiptypen, z. B. `arbeitet an` und `leitet`.
- **Rekursive Beziehung:** Ein Entitytyp steht mit sich selbst in Beziehung, oft mit Rollen, z. B. Mitarbeiter führt Mitarbeiter.

Prüfungsfrage: Sind die Rollen und Bedeutungen sauber benannt?


Datenbanken - Theorie

Question:
# ERM aus Fachtext
Wie gehst du vor, wenn du aus einer Anforderung ein ERM erstellen sollst?

Answer:
1. Nomen als mögliche Entitytypen markieren.
2. Verben als mögliche Relationshiptypen markieren.
3. Attribute und Schlüssel ergänzen.
4. Kardinalitäten in beide Richtungen fragen.
5. Fehlende Informationen als Annahmen kennzeichnen.
6. Prüfen, ob Beziehungen binär, rekursiv, parallel oder ternär sind.

Prüfungsfalle: Nomen/Verben sind Heuristiken, keine Garantie.

Zusammenfassung §6.3; Skript Folien 53-57


Datenbanken - Theorie

Question:
# Ternäre Beziehung
Wann brauchst du eine ternäre Beziehung?

Answer:
Eine ternäre Beziehung verbindet genau drei Entitytypen gleichzeitig.

Sie ist nötig, wenn die fachliche Aussage nur durch die gleichzeitige Betrachtung aller drei Entitäten vollständig ist.

Beispiel: `Pilot fliegt mit Flugzeug auf Flugroute`. Die Information besteht aus Pilot, Flugzeug und Flugroute zusammen.

Zusammenfassung §6.4; Skript Folien 58-62


Datenbanken - Theorie

Question:
# Connection Trap
Was ist eine Connection Trap bei ternären Beziehungen?

Answer:
Eine Connection Trap entsteht, wenn eine eigentlich ternäre Beziehung fälschlich in mehrere binäre Beziehungen zerlegt wird.

Folge: Semantische Information geht verloren.

Beispiel:

- Pilot - Flugzeug sagt nicht, auf welcher Flugroute.
- Pilot - Flugroute sagt nicht, mit welchem Flugzeug.
- Flugroute - Flugzeug sagt nicht, welcher Pilot.

Nur die ternäre Beziehung beantwortet alles zusammen.

Zusammenfassung §6.4; Skript Folien 58-60


Datenbanken - Theorie

Question:
# Kardinalitäten ternärer Beziehungen
Wie ermittelst du Kardinalitäten bei ternären Beziehungen?

Answer:
Man fixiert jeweils zwei Entities und fragt, wie viele Entities des dritten Typs dazu gehören können.

Beispiel `Pilot`, `Flugzeug`, `Flugroute`:

- Fixiere Pilot + Flugzeug: Wie viele Flugrouten?
- Fixiere Flugzeug + Flugroute: Wie viele Piloten?
- Fixiere Pilot + Flugroute: Wie viele Flugzeuge?

So entsteht z. B. eine Notation wie `n:m:1`.

Zusammenfassung §6.4; Skript Folien 61-62


Datenbanken - Theorie

Question:
# Generalisierung
Was bedeuten Generalisierung und Spezialisierung?

Answer:
- **Generalisierung:** Mehrere Subentitytypen werden zu einem Superentitytyp zusammengefasst.
- **Spezialisierung:** Ein Superentitytyp wird in Subentitytypen unterteilt.

Beispiel: Oberstufenschüler und Mittelstufenschüler sind Spezialisierungen von Schüler.

Subtypen erben Attribute des Supertyps und können eigene Attribute ergänzen.


Datenbanken - Theorie

Question:
# Generalisierungsfälle
Wie unterscheiden sich überlappend, vollständig und disjunkt?

Answer:
- **Überlappend:** Eine Entität kann mehreren Subtypen angehören.
- **Vollständig:** Jede Entität des Supertyps gehört mindestens einem Subtyp an.
- **Disjunkt:** Eine Entität darf höchstens einem Subtyp angehören.
- **Disjunkt-vollständig:** Jede Entität gehört genau einem Subtyp an.

Prüfungsfalle: Disjunktheit und Vollständigkeit sind zwei verschiedene Fragen.


Datenbanken - Theorie

Question:
# Logischer Entwurf
Welche zwei Punkte sind beim Übergang vom ERM zur relationalen Datenbank zentral?

Answer:
Beim logischen Entwurf sind zwei Punkte besonders wichtig:

1. **Normalisierung:** Redundanz und Anomalien vermeiden.
2. **Abbildungsregeln:** Entitytypen und Relationshiptypen korrekt als Tabellen darstellen.

Prüfungsfalle: Ein gutes ERM ist noch kein fertiges relationales Schema.


Datenbanken - Theorie

Question:
# Relation formal
Wie wird eine Relation formal beschrieben?

Answer:
Eine Relation `R` ist eine Teilmenge aus dem kartesischen Produkt der Domänen:

`R ⊆ D1 × D2 × ... × Dn`

Ein Tupel ist eine konkrete Ausprägung:

`r = (d1, d2, ..., dn)`

Bedeutung: Jedes Tupel enthält für jedes Attribut einen Wert aus der passenden Domäne.


Datenbanken - Theorie

Question:
# Normalisierung
Was ist das Ziel der Normalisierung?

Answer:
Normalisierung strukturiert Tabellen so, dass:

- Redundanzen reduziert werden
- Einfüge-, Lösch- und Änderungsanomalien vermieden werden
- Daten logisch zusammenhängend in kleinere Relationen zerlegt werden
- funktionale Abhängigkeiten klar abgebildet werden

Merksatz: Redundanz → Anomaliegefahr → Normalisierung.


Datenbanken - Theorie

Question:
# Redundanz
Wann ist Information in einer Tabelle redundant?

Answer:
Information ist redundant, wenn einzelne Werte mehrfach gespeichert sind und ohne Informationsverlust aus anderen Daten ableitbar oder wiederholbar wären.

Beispiel: Derselbe Studiengangname steht bei mehreren Studierenden mehrfach in der Tabelle.

Problem: Redundanz erhöht die Gefahr von Inkonsistenzen und Anomalien.


Datenbanken - Theorie

Question:
# Einfügeanomalie
Was ist eine Einfügeanomalie?

Answer:
Eine Einfügeanomalie liegt vor, wenn Daten nicht eingefügt werden können, weil andere eigentlich unabhängige Informationen fehlen.

Beispiel: Ein neuer Studiengang kann nicht eingefügt werden, ohne sofort einen Studierenden mit MatNr zuzuordnen.

Ursache: Mehrere Sachverhalte wurden in einer Tabelle vermischt.


Datenbanken - Theorie

Question:
# Löschanomalie
Was ist eine Löschanomalie?

Answer:
Eine Löschanomalie entsteht, wenn beim Löschen eines Datensatzes mehr Information verloren geht als beabsichtigt.

Beispiel: Werden alle Studierenden eines Studiengangs gelöscht, gehen auch die Informationen über den Studiengang verloren.

Prüfungsfalle: Löschen betrifft nicht nur die Zeile, sondern alle darin vermischten Sachverhalte.


Datenbanken - Theorie

Question:
# Änderungsanomalie
Was ist eine Änderungsanomalie?

Answer:
Eine Änderungsanomalie liegt vor, wenn dieselbe Information redundant an mehreren Stellen geändert werden muss.

Beispiel: Der Studiengangname `Data Science und KI` steht in mehreren Zeilen. Wird er umbenannt, muss jede Vorkommensstelle angepasst werden.

Risiko: Wird eine Stelle vergessen, wird die Datenbank inkonsistent.


Datenbanken - Theorie

Question:
# Unnormalisierte Form
Wann ist eine Relation unnormalisiert?

Answer:
Eine Relation ist unnormalisiert, wenn an einem Schnittpunkt von Zeile und Spalte mehrere Werte stehen oder Wiederholungsgruppen vorkommen.

Beispiel aus dem Mietwagenfall: Ein Mieter hat in einer Zeile mehrere Mietwagen mit mehreren Werten.

Prüfungsfalle: Listen in einer Zelle verletzen die Atomarität.


Datenbanken - Theorie

Question:
# 1. Normalform
Wann ist eine Relation in 1NF?

Answer:
Eine Relation ist in der **1. Normalform**, wenn alle Attribute atomare Werte enthalten.

Vorgehen:

- Wiederholungsgruppen auflösen
- eigene Tupel für wiederholte Werte erzeugen
- Schlüssel ggf. erweitern

Im Mietwagenbeispiel identifizieren danach `MNR` und `WNR` gemeinsam einen Mietvorgang.

Prüfungsfalle: 1NF kann Redundanz zunächst erhöhen.


Datenbanken - Theorie

Question:
# 2. Normalform
Wann ist eine Relation in 2NF?

Answer:
Eine Relation ist in der **2. Normalform**, wenn sie in 1NF ist und jedes Nichtschlüsselattribut vom gesamten Schlüssel voll funktional abhängt.

Relevant ist das vor allem bei zusammengesetzten Schlüsseln.

Prüfungsfalle: Hat der Primärschlüssel nur ein Attribut, ist eine 1NF-Relation automatisch in 2NF.

Zusammenfassung §8.3; Skript Folien 79-80


Datenbanken - Theorie

Question:
# 2NF-Zerlegung
Wie zerlegst du eine Relation, die nicht in 2NF ist?

Answer:
Wenn Nichtschlüsselattribute nur von einem Teil eines zusammengesetzten Schlüssels abhängen:

1. Attribute mit ihrem Teilschlüssel in eigene Tabelle auslagern.
2. Beziehungstabelle mit zusammengesetztem Schlüssel behalten.
3. Primärschlüssel und Fremdschlüssel definieren.

Beispiel: `MNR → MNA, BR` und `WNR → FT, BJ, VS, MS` werden ausgelagert.

Zusammenfassung §8.4; Skript Folien 80-81


Datenbanken - Theorie

Question:
# 3. Normalform
Wann ist eine Relation in 3NF?

Answer:
Eine Relation ist in der **3. Normalform**, wenn sie in 2NF ist und keine transitiven Abhängigkeiten zwischen Nichtschlüsselattributen bestehen.

Anders gesagt: Aus keinem Nichtschlüsselattribut darf ein anderes Nichtschlüsselattribut folgen.

Beispiel: Wenn `FT → MS`, dann gehört der Mietsatz in eine eigene Tabelle mit `FT` als Schlüssel.

Zusammenfassung §8.3-8.4; Skript Folien 82-83


Datenbanken - Theorie

Question:
# Transitive Abhängigkeit
Was ist eine transitive Abhängigkeit?

Answer:
Eine transitive Abhängigkeit liegt vor, wenn ein Nichtschlüsselattribut von einem anderen Nichtschlüsselattribut abhängt, das wiederum vom Primärschlüssel abhängt.

Schema:

`Schlüssel → Nichtschlüsselattribut A → Nichtschlüsselattribut B`

Für 3NF müssen solche Abhängigkeiten in eigene Tabellen ausgelagert werden.


Datenbanken - Theorie

Question:
# Normalisierung: Vorteile
Welche Vorteile hat Normalisierung?

Answer:
Normalisierung bietet:

- weniger Redundanz
- geringere Inkonsistenzgefahr
- bessere Datenintegrität
- einfachere Pflege einzelner Sachverhalte
- weniger Einfüge-, Lösch- und Änderungsanomalien

Besonders geeignet für transaktionsorientierte Systeme wie Buchungssysteme, Online-Shops oder Banking.

Zusammenfassung §8.5; Skript Folien 84-86


Datenbanken - Theorie

Question:
# Normalisierung: Nachteile
Welche Nachteile kann starke Normalisierung haben?

Answer:
Nachteile:

- mehr Tabellen
- komplexere SQL-Abfragen
- mehr Joins
- mögliche Performancekosten bei großen Datenmengen
- höherer Design- und Administrationsaufwand

Für Analyse, Reporting, Data Warehouses und Big Data kann teilweise Denormalisierung sinnvoll sein.

Zusammenfassung §8.5; Skript Folien 85-86


Datenbanken - Theorie

Question:
# Relationales Datenbankschema
Was enthält ein relationales Datenbankschema?

Answer:
Ein relationales Datenbankschema enthält die Datenbankbeschreibung:

- Tabellen
- Attribute
- Datentypen
- Primärschlüssel
- Fremdschlüssel
- Integritätsbedingungen/Constraints

Es entsteht im logischen Entwurf durch Überführung des ERM in relationale Strukturen.

Zusammenfassung §9.1; Skript Folien 88-90


Datenbanken - Theorie

Question:
# Fremdschlüssel
Was ist ein Fremdschlüssel?

Answer:
Ein Fremdschlüssel ist ein Attribut in einer Detailtabelle, dessen Werte auf Primärschlüsselwerte einer Mastertabelle verweisen.

Wichtig:

- Name muss nicht identisch sein.
- Wertebereich/Domäne muss passen.
- Eine Tabelle kann mehrere Fremdschlüssel haben.
- Bei rekursiven Beziehungen kann eine Tabelle Master und Detail zugleich sein.


Datenbanken - Theorie

Question:
# Abbildungsregel Entitytyp
Wie wird ein Entitytyp in das relationale Modell überführt?

Answer:
Jeder Entitytyp wird zu einer Tabelle.

Regeln:

- Attribute des Entitytyps werden zu Spalten.
- Schlüssel des Entitytyps wird Primärschlüssel.
- Tabellenname entspricht meist dem Entitytyp.

Beispiel: `Lieferant(LNr, Name, Adresse)` und `Artikel(ANr, Bezeichnung, Preis)`.


Datenbanken - Theorie

Question:
# Abbildungsregel 1:1
Wie wird eine 1:1-Beziehung relational abgebildet?

Answer:
Bei einer 1:1-Beziehung gibt es zwei typische Möglichkeiten:

1. Primärschlüssel der einen Tabelle als Fremdschlüssel in die andere aufnehmen.
2. Tabellen zusammenführen, wenn fachlich sinnvoll.

Prüfungsfalle: Optionalität beachten. Der Fremdschlüssel liegt oft auf der optionalen oder abhängigen Seite.


Datenbanken - Theorie

Question:
# Abbildungsregel 1:n
Wie wird eine 1:n-Beziehung relational abgebildet?

Answer:
Der Primärschlüssel der 1-Seite wird als Fremdschlüssel in die Tabelle der n-Seite übernommen.

Beispiel:

- `Klasse(KlasseNr, Klassenlehrer, Raum)`
- `Schueler(SchuelerNr, Name, KlasseNr)`

`KlasseNr` in `Schueler` verweist auf `Klasse.KlasseNr`.


Datenbanken - Theorie

Question:
# Abbildungsregel n:m
Wie wird eine n:m-Beziehung relational abgebildet?

Answer:
Eine n:m-Beziehung wird zu einer neuen Beziehungstabelle.

Diese enthält:

- Primärschlüssel der ersten Entität als Fremdschlüssel
- Primärschlüssel der zweiten Entität als Fremdschlüssel
- ggf. Attribute der Beziehung

Beispiel: `Lieferung(LNr, ANr, Liefermenge)`.

Prüfungsfalle: n:m nicht direkt als Fremdschlüssel in einer der beiden Entitytabellen abbilden.


Datenbanken - Theorie

Question:
# Integritätsregeln
Welche Integritätsarten behandelt das Skript?

Answer:
Wichtige Integritätsarten:

- **Domain-Integrität:** gültige Werte in Attributen
- **Entity-Integrität:** eindeutige Identifikation jeder Zeile
- **Referentielle Integrität:** gültige Beziehungen zwischen Tabellen
- **Benutzerdefinierte Integrität:** zusätzliche fachliche Regeln

Constraints sichern zulässige Datenzustände.


Datenbanken - Theorie

Question:
# Domain-Integrität
Was stellt Domain-Integrität sicher?

Answer:
Domain-Integrität stellt sicher, dass Attributwerte gültig, konsistent und sinnvoll sind.

Typische Mittel:

- Datentypen, z. B. `INT`, `VARCHAR`, `DATE`
- Wertebereiche über `CHECK`
- Pflichtfelder über `NOT NULL`
- Standardwerte über `DEFAULT`
- Formatregeln

Beispiel: `CHECK (Alter >= 18)`.

Zusammenfassung §10.1; Skript Folien 99-101


Datenbanken - Theorie

Question:
# Entity-Integrität
Was besagt Entity-Integrität?

Answer:
Entity-Integrität besagt, dass jede Zeile eindeutig identifizierbar sein muss.

Regeln:

- Jede Relation besitzt einen Primärschlüssel.
- Primärschlüsselwerte sind eindeutig.
- Primärschlüsselattribute dürfen nicht `NULL` sein.

Prüfungsfalle: `NULL` im Primärschlüssel verletzt Entity-Integrität.


Datenbanken - Theorie

Question:
# Referentielle Integrität
Was stellt referentielle Integrität sicher?

Answer:
Referentielle Integrität stellt sicher, dass Fremdschlüsselwerte auf existierende Primärschlüsselwerte verweisen oder `NULL` sind, wenn fachlich und domänenseitig erlaubt.

Beispiel: `Schueler.KlasseNr` muss in `Klasse.KlasseNr` existieren.

Sonst entstehen verwaiste Detaildatensätze.


Datenbanken - Theorie

Question:
# Referenzaktionen
Was bedeuten RESTRICT, CASCADE und SET NULL?

Answer:
- **RESTRICT / NO ACTION:** Änderung oder Löschung wird verhindert, wenn abhängige Datensätze existieren.
- **CASCADE:** Änderung oder Löschung wird auf abhängige Datensätze übertragen.
- **SET NULL:** Fremdschlüssel abhängiger Datensätze wird auf `NULL` gesetzt.

Prüfungsfalle: `SET NULL` passt nur, wenn die Fremdschlüsselspalte `NULL` erlauben darf.

Zusammenfassung §10.2; Skript Folien 104-106


Datenbanken - Theorie

Question:
# Benutzerdefinierte Integrität
Was ist benutzerdefinierte Integrität?

Answer:
Benutzerdefinierte Integrität umfasst fachliche Regeln, die nicht vollständig durch Standardconstraints abgedeckt sind.

Beispiele:

- Kunde muss für bestimmte Produkte mindestens 18 sein.
- Rabatt darf nur für bestimmte Kundengruppen gelten.

Umsetzung häufig in Anwendung, Triggern oder prozeduralen Constraints.

Risiko: Nur garantiert, wenn der betreffende Mechanismus wirklich verwendet wird.

Zusammenfassung §10.1; Skript Folien 97-98


Datenbanken - Theorie

Question:
# Konsistenz vs. Integrität
Wie unterscheiden sich Konsistenz und Integrität?

Answer:
- **Integrität:** Regeln und Mechanismen, die zulässige Datenzustände sichern.
- **Konsistenz:** Zustand der Datenbank, wenn diese Regeln eingehalten sind.

Merksatz: Integrität ist die Ursache, Konsistenz das Ergebnis.

Prüfungsfalle: Begriffe nicht synonym verwenden.

Zusammenfassung §10.3; Skript Folien 108-109


Datenbanken - Theorie

Question:
# ACID-Konsistenz
Was bedeutet Konsistenz im ACID-Modell?

Answer:
Im ACID-Modell bedeutet Konsistenz: Eine Transaktion muss die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand überführen.

Sie darf keine Integritätsbedingungen verletzen.

Bezug:

- **A** Atomicity
- **C** Consistency
- **I** Isolation
- **D** Durability


Datenbanken - Theorie

Question:
# Relationenalgebra
Warum ist Relationenalgebra wichtig?

Answer:
Relationenalgebra ist die formale Grundlage relationaler Abfragen.

Sie hilft, Fachfragen präzise in Datenbankabfragen zu übersetzen:

`Domänenwissen → Relationenalgebra → formale Struktur → SQL → Ergebnisrelation`

Wichtig: Jede Operation liefert wieder eine Relation und kann weiterverwendet werden.

Zusammenfassung §11.1; Skript Folien 111-112


Datenbanken - Theorie

Question:
# Operatorarten
Welche drei Operatorarten umfasst die Relationenalgebra im Skript?

Answer:
Die Folien unterscheiden:

1. **Relationenoperatoren:** Projektion, Selektion, Join, kartesisches Produkt
2. **Mengenoperatoren:** Vereinigung, Durchschnitt, Differenz, symmetrische Differenz
3. **Logische Operatoren:** AND, OR, NOT, XOR

Relationenoperatoren manipulieren Tabellenstruktur oder Tupelauswahl, Mengenoperatoren kombinieren Relationen, logische Operatoren formulieren Bedingungen.

Zusammenfassung §11.1; Skript Folien 112-114


Datenbanken - Theorie

Question:
# Projektion
Was macht die Projektion?

Answer:
Die Projektion `π` wählt bestimmte Attribute bzw. Spalten einer Relation aus.

Beispiel:

`π_Name, Stadt(Kunden)`

liefert nur die Attribute `Name` und `Stadt`.

Wichtig: Doppelte Tupel werden in der relationalen Algebra entfernt.

Prüfungsfalle: Projektion filtert Spalten, nicht Zeilen.


Datenbanken - Theorie

Question:
# Selektion
Was macht die Selektion?

Answer:
Die Selektion `σ` filtert Tupel bzw. Zeilen anhand einer Bedingung.

Beispiel:

`σ_Stadt='Berlin'(Kunden)`

liefert Kunden, deren Stadt Berlin ist.

Die Ergebnisrelation hat dasselbe Schema wie die Ausgangsrelation, aber weniger Tupel.

Prüfungsfalle: Selektion ist nicht dasselbe wie SQL-`SELECT`.

Zusammenfassung §11.2; Skript Folien 116-117


Datenbanken - Theorie

Question:
# Join
Was macht ein Join in der Relationenalgebra?

Answer:
Ein Join kombiniert zwei Relationen zu einer neuen Relation, indem Tupel anhand eines Join-Prädikats verbunden werden.

Beispiel:

`Kunden ⋈_Kunden.K_ID=Bestellungen.K_ID Bestellungen`

Ein Join ist konzeptionell ein kartesisches Produkt plus Selektion.

Häufig basiert das Join-Prädikat auf Primärschlüssel-Fremdschlüssel-Beziehungen.

Zusammenfassung §11.2; Skript Folien 118-119


Datenbanken - Theorie

Question:
# Kartesisches Produkt
Was ist das kartesische Produkt zweier Relationen?

Answer:
Das kartesische Produkt `A × B` kombiniert jedes Tupel aus `A` mit jedem Tupel aus `B`.

Hat `A` `n` Tupel und `B` `m` Tupel, enthält das Ergebnis `n × m` Tupel.

Prüfungsfalle: Ohne sinnvolle Selektionsbedingung entstehen schnell sehr große und fachlich unsinnige Ergebnismengen.


Datenbanken - Theorie

Question:
# Reihenfolge von Relationenoperatoren
Wie gehst du bei verschachtelten relationalen Ausdrücken vor?

Answer:
Es gibt keine universelle natürliche Lesereihenfolge wie bei einfachen Rechenregeln.

Klausurtechnik:

- Klammern beachten
- von innen nach außen arbeiten
- bei gleicher Ebene links nach rechts lesen
- Zwischenergebnisse als Relationen verstehen

Merksatz: Jede Operation erzeugt eine neue Relation, die weiterverarbeitet werden kann.


Datenbanken - Theorie

Question:
# Vereinigung
Was macht die Vereinigung zweier Relationen?

Answer:
Die Vereinigung `A ∪ B` enthält alle Tupel, die in `A` oder `B` vorkommen.

Voraussetzung: Relationen müssen schema-kompatibel sein.

Duplikate werden eliminiert.

Beispiel:

`π_Stadt(Kunden) ∪ π_Stadt(Lieferungen)`

Zusammenfassung §11.3; Skript Folien 123-125


Datenbanken - Theorie

Question:
# Durchschnitt
Was macht der Durchschnitt zweier Relationen?

Answer:
Der Durchschnitt `A ∩ B` enthält nur Tupel, die sowohl in `A` als auch in `B` vorkommen.

Voraussetzung: Relationen müssen schema-kompatibel sein.

Beispiel:

`π_Stadt(Kunden) ∩ π_Stadt(Lieferungen)`

Businessfrage: In welchen Städten haben wir sowohl Kunden als auch Lieferungen?

Zusammenfassung §11.3; Skript Folien 126-127


Datenbanken - Theorie

Question:
# Differenz
Was macht die Differenz zweier Relationen?

Answer:
Die Differenz `A \ B` enthält Tupel, die in `A`, aber nicht in `B` vorkommen.

Voraussetzung: Relationen müssen schema-kompatibel sein.

Beispiel:

`π_Stadt(Kunden) \ π_Stadt(Lieferungen)`

Businessfrage: In welchen Städten haben wir Kunden, aber keine Lieferungen?

Zusammenfassung §11.3; Skript Folien 128-129


Datenbanken - Theorie

Question:
# Symmetrische Differenz
Wie hängt XOR mit Mengen zusammen?

Answer:
Das logische XOR entspricht bei Mengen der symmetrischen Differenz:

`A ⊕ B = (A \ B) ∪ (B \ A) = (A ∪ B) \ (A ∩ B)`

Bedeutung: Elemente, die in genau einer der beiden Mengen liegen, aber nicht in beiden.


Datenbanken - Theorie

Question:
# Logische Operatoren
Was bedeuten AND, OR, NOT und XOR?

Answer:
- **AND / ∧:** alle Bedingungen müssen wahr sein.
- **OR / ∨:** mindestens eine Bedingung muss wahr sein.
- **NOT / ¬:** Bedingung wird negiert.
- **XOR / ⊕:** genau eine Bedingung ist wahr, aber nicht beide.

In der Relationenalgebra werden sie vor allem in Selektionsbedingungen verwendet.

Zusammenfassung §11.4; Skript Folien 133-137


Datenbanken - Theorie

Question:
# Prioritätsregel
Welche Priorität gilt für logische Operatoren im Skript?

Answer:
Die Priorität lautet:

1. Klammern
2. NOT
3. AND
4. OR
5. XOR

Prüfungsfalle: `A ∪ B ∩ C` wird ohne Klammern nicht wie `(A ∪ B) ∩ C` gelesen, sondern zuerst wird `B ∩ C` gebildet.

Zusammenfassung §12.1; Skript Folien 133, 144-145


Datenbanken - Theorie

Question:
# Drei-Mengen-XOR
Wie lautet die im Skript behandelte Idee von A XOR B XOR C?

Answer:
Für drei Mengen werden die Bereiche ausgewählt, in denen eine ungerade Anzahl von Bedingungen erfüllt ist:

`A ⊕ B ⊕ C = (A ∩ B^c ∩ C^c) ∪ (A^c ∩ B ∩ C^c) ∪ (A^c ∩ B^c ∩ C) ∪ (A ∩ B ∩ C)`

Im Marketingbeispiel entspricht das genau einer Eigenschaft oder allen drei Eigenschaften.

Zusammenfassung §11.5; Skript Folien 138-140


Datenbanken - Theorie

Question:
# Distributivgesetz
Welche Distributivgesetze sind wichtig?

Answer:
Wichtige Mengenformen:

- `A ∩ (B ∪ C) = (A ∩ B) ∪ (A ∩ C)`
- `A ∪ (B ∩ C) = (A ∪ B) ∩ (A ∪ C)`

Prüfungsbezug: Algebraisch äquivalente Ausdrücke können fachlich unterschiedlich formuliert werden. Klammern helfen, die Zielgruppe sauber zu beschreiben.

Zusammenfassung §12.2; Skript Folien 146-147


Datenbanken - Theorie

Question:
# De Morgan
Wie lauten die De-Morgan-Regeln?

Answer:
Für Mengen:

- `(A ∪ B)^c = A^c ∩ B^c`
- `(A ∩ B)^c = A^c ∪ B^c`

Logische Lesart:

- Nicht (A oder B) heißt: nicht A und nicht B.
- Nicht (A und B) heißt: nicht A oder nicht B.

Prüfungsfalle: Das Negieren von zusammengesetzten Bedingungen dreht OR und AND.

Zusammenfassung §12.2; Skript Folien 148-149


Datenbanken - Theorie

Question:
# SQL als deskriptive Sprache
Warum ist SQL deskriptiv?

Answer:
SQL beschreibt das gewünschte Ergebnis und die Bedingungen, nicht den technischen Suchweg.

Beispiel:

```sql
SELECT Name
FROM Mitarbeitende
WHERE Ort = 'Liestal';
```

Die Datenbank-Engine entscheidet, wie der Zugriff effizient ausgeführt wird.

Prüfungsfalle: SQL nicht wie eine Schleife oder prozedurales Programm erklären.

Zusammenfassung §12.3; Skript Folien 151-152


Datenbanken - Theorie

Question:
# Fachfrage in Relationenalgebra
Wie übersetzt du eine Fachfrage in relationale Algebra?

Answer:
Vorgehen:

1. Benötigte Relationen identifizieren.
2. Falls mehrere Tabellen nötig sind: Join-Bedingung formulieren.
3. Zeilenbedingungen als Selektion `σ` formulieren.
4. Gewünschte Attribute als Projektion `π` formulieren.
5. Klammern setzen.

Beispiel:

`π_Name(σ_Stadt='Berlin' ∧ Alter>30(Kunden ⋈_Kunden.K_ID=Bestellungen.K_ID Bestellungen))`

Zusammenfassung §12.3; Skript Folien 111, 151-155


Datenbanken - Theorie

Question:
# Häufige Prüfungsfallen
Welche typischen Fehler solltest du vermeiden?

Answer:
Typische Fehler:

- Daten, Information und Wissen vermischen.
- JSON automatisch als NoSQL begründen.
- Kardinalitäten nur in eine Richtung lesen.
- Ternäre Beziehungen in falsche binäre Beziehungen zerlegen.
- Minimalität von Schlüsseln vergessen.
- 1NF, 2NF und 3NF vermischen.
- Fremdschlüssel auf die falsche Seite setzen.
- Integrität und Konsistenz synonym verwenden.
- Projektion und Selektion verwechseln.
- Logische Ausdrücke ohne Klammern interpretieren.


Datenbanken - Theorie

Question:
# Fachtext prüfen
Welche Fragen stellst du, bevor du ein ERM zeichnest?

Answer:
Vor dem Zeichnen klärst du:

- Welche Objekte sind fachlich relevant?
- Welche Objekte sind nur Attribute anderer Objekte?
- Welche Beziehungen sind eigenständige Sachverhalte?
- Gibt es Beziehungsattribute?
- Sind Beziehungen optional oder verpflichtend?
- Müssen Kardinalitäten in beide Richtungen präzisiert werden?
- Fehlen Informationen, die als Annahme markiert werden müssen?

Prüfungspunkt: Erst Fachlogik sichern, dann Diagramm zeichnen.

Zusammenfassung §5-6; Skript Folien 31-57


Datenbanken - Theorie

Question:
# Entitytyp oder Attribut?
Wann modellierst du etwas als Entitytyp statt als Attribut?

Answer:
Als Entitytyp modellierst du einen Begriff eher, wenn er:

- eigene Attribute besitzt
- mehrfach referenziert wird
- eigene Beziehungen zu anderen Entitytypen hat
- unabhängig existieren kann
- im System gesucht, verwaltet oder historisiert wird

Als Attribut reicht er eher, wenn er nur eine einfache Eigenschaft eines anderen Objekts ist.

Beispiel: `Adresse` kann Attribut sein; bei mehreren Lieferadressen mit eigenen Regeln kann sie Entitytyp werden.

Zusammenfassung §5.3-5.4; Skript Folien 39-43


Datenbanken - Theorie

Question:
# Relationshipattribut
Wann bekommt eine Beziehung ein eigenes Attribut?

Answer:
Eine Beziehung bekommt ein Attribut, wenn die Eigenschaft nicht sinnvoll zu genau einem beteiligten Entity gehört, sondern zur Kombination der Entities.

Beispiel `Lieferant liefert Artikel`:

- `Liefermenge` beschreibt nicht nur den Lieferanten.
- `Liefermenge` beschreibt nicht nur den Artikel.
- Sie beschreibt die konkrete Beziehung Lieferant-Artikel.

Bei n:m-Abbildung landet dieses Attribut in der Beziehungstabelle.

Zusammenfassung §5.3 und §9.2; Skript Folien 41, 95


Datenbanken - Theorie

Question:
# Optionalität
Warum reicht 1:n oft nicht aus?

Answer:
`1:n` beschreibt primär die maximale Anzahl, nicht sauber die Pflichtteilnahme.

Offene Fragen:

- Muss jedes Entity der n-Seite genau einem Entity der 1-Seite zugeordnet sein?
- Darf ein Entity ohne Beziehung existieren?
- Muss auf der n-Seite mindestens ein Partner existieren?

Dafür ist die MC-Notation hilfreich: `1`, `c`, `m`, `mc`.

Zusammenfassung §6.1-6.2; Skript Folien 47-51


Datenbanken - Theorie

Question:
# Kardinalität begründen
Wie formulierst du eine gute Kardinalitätsbegründung?

Answer:
Eine gute Begründung nennt beide Richtungen.

Beispiel `Schulklasse - Schüler`:

- Ein Schüler gehört genau einer Schulklasse an.
- Einer Schulklasse können viele Schüler angehören.

Daraus folgt eine 1:n-Beziehung.

Prüfungsfalle: Nur `Klasse hat viele Schüler` reicht nicht, weil die Gegenrichtung fehlt.

Zusammenfassung §6.1; Skript Folien 45-50


Datenbanken - Theorie

Question:
# 1:1 kritisch prüfen
Warum sind 1:1-Beziehungen selten und prüfungsanfällig?

Answer:
1:1-Beziehungen sind selten, weil viele scheinbare 1:1-Beziehungen zeit-, rechts- oder fachkontextabhängig sind.

Prüfe:

- Gilt die Beziehung wirklich immer?
- Gilt sie nur zu einem Zeitpunkt?
- Ist eine Seite optional?
- Wäre Zusammenlegung sinnvoller?
- Gibt es historische Mehrfachzuordnungen?

Beispiel aus dem Skript: Ehemodellierung ist nicht für alle Länder und Zeiträume allgemein gültig.


Datenbanken - Theorie

Question:
# n:m erkennen
Woran erkennst du eine n:m-Beziehung?

Answer:
Eine n:m-Beziehung liegt vor, wenn auf beiden Seiten mehrere Zuordnungen möglich sind.

Diagnosefragen:

- Kann ein Lieferant viele Artikel liefern? Ja.
- Kann ein Artikel von vielen Lieferanten geliefert werden? Ja.

Dann entsteht n:m.

Relationale Folge: eigene Beziehungstabelle mit beiden Fremdschlüsseln und möglichen Beziehungsattributen.

Zusammenfassung §6.1 und §9.2; Skript Folien 48, 95


Datenbanken - Theorie

Question:
# Ternär vs. drei binäre Beziehungen
Welche Kontrollfrage verhindert eine Connection Trap?

Answer:
Frage: Kann ich aus den binären Beziehungen die ursprüngliche dreifache Aussage eindeutig rekonstruieren?

Wenn nein, brauche ich eine ternäre Beziehung.

Beispiel:

- Pilot-Flugzeug
- Pilot-Flugroute
- Flugroute-Flugzeug

Diese drei Beziehungen sagen nicht eindeutig, welcher Pilot mit welchem Flugzeug welche Flugroute fliegt.

Zusammenfassung §6.4; Skript Folien 58-60


Datenbanken - Theorie

Question:
# Generalisierung prüfen
Welche zwei unabhängigen Fragen stellst du bei Generalisierung?

Answer:
Bei einer Generalisierung prüfst du getrennt:

1. **Disjunktheit:** Darf eine Entität mehreren Subtypen angehören?
2. **Vollständigkeit:** Muss jede Entität des Supertyps mindestens einem Subtyp angehören?

Kombinationen:

- überlappend / nicht vollständig
- überlappend / vollständig
- disjunkt / nicht vollständig
- disjunkt / vollständig


Datenbanken - Theorie

Question:
# Normalisierung Diagnose
Welche Diagnosefragen führen dich durch 1NF, 2NF und 3NF?

Answer:
- **1NF:** Gibt es Wiederholungsgruppen oder mehrere Werte in einer Zelle?
- **2NF:** Gibt es einen zusammengesetzten Schlüssel und Attribute, die nur von einem Teil davon abhängen?
- **3NF:** Gibt es Nichtschlüsselattribute, die andere Nichtschlüsselattribute bestimmen?

Diese Reihenfolge ist wichtig. Du prüfst nicht 3NF, bevor 1NF und 2NF sauber sind.

Zusammenfassung §8.3-8.4; Skript Folien 77-83


Datenbanken - Theorie

Question:
# Funktionale Abhängigkeit
Was bedeutet funktionale Abhängigkeit praktisch?

Answer:
Eine funktionale Abhängigkeit `A → B` bedeutet: Der Wert von `A` bestimmt eindeutig den Wert von `B`.

Beispiel:

- `MNR → MNA, BR`: Mieter-Nr bestimmt Name und Branche.
- `WNR → FT, BJ, VS`: Wagen-Nr bestimmt Fahrzeugdaten.

Normalisierung nutzt solche Abhängigkeiten, um Tabellen korrekt zu zerlegen.

Zusammenfassung §8.4; Skript Folien 79-83


Datenbanken - Theorie

Question:
# Schlüssel erweitern bei 1NF
Warum muss nach dem Auflösen von Wiederholungsgruppen manchmal der Schlüssel erweitert werden?

Answer:
Wenn aus einer Zeile mehrere Tupel entstehen, identifiziert der alte Schlüssel oft nicht mehr eindeutig.

Im Mietwagenbeispiel:

- Vorher: `MNR` identifiziert den Mieter.
- Nach 1NF: Ein Mieter kann mehrere Wagen mieten.
- Eindeutig wird der Mietvorgang erst durch `MNR + WNR`.

Prüfungsfalle: Atomarität herstellen, aber neuen Schlüssel vergessen.

Zusammenfassung §8.3; Skript Folien 77-78


Datenbanken - Theorie

Question:
# Verlustfreie Zerlegung
Was muss bei einer Normalisierungszerlegung erhalten bleiben?

Answer:
Eine sinnvolle Zerlegung soll:

- Informationen nicht verlieren
- über Schlüssel/Fremdschlüssel rekonstruierbar sein
- Redundanzen reduzieren
- Anomalien vermeiden
- fachliche Abhängigkeiten korrekt abbilden

Im Skript wird die Rekonstruktion über Primärschlüssel-Fremdschlüssel-Beziehungen betont.

Zusammenfassung §8.4; Skript Folien 80-83


Datenbanken - Theorie

Question:
# Beziehungstabelle vs. Entitytabelle
Was gehört in eine Beziehungstabelle?

Answer:
Eine Beziehungstabelle enthält typischerweise:

- Fremdschlüssel auf die beteiligten Entitytabellen
- häufig zusammengesetzten Primärschlüssel aus diesen Fremdschlüsseln
- Attribute der Beziehung

Beispiel:

`Lieferung(LNr, ANr, Liefermenge)`

`Liefermenge` gehört zur Beziehung, nicht allein zu `Lieferant` oder `Artikel`.


Datenbanken - Theorie

Question:
# Fremdschlüsselrichtung
Wie merkst du dir die Richtung bei 1:n-Abbildungen?

Answer:
Merksatz: Der Fremdschlüssel wandert auf die **n-Seite**.

Warum?

Jedes Tupel auf der n-Seite verweist auf sein zugehöriges Tupel der 1-Seite.

Beispiel:

- Eine Klasse hat viele Schüler.
- Jeder Schüler gehört zu einer Klasse.
- Also steht `KlasseNr` in `Schueler`.

Prüfungsfalle: Fremdschlüssel in die 1-Seite setzen.


Datenbanken - Theorie

Question:
# Domain-Integrität vs. referentielle Integrität
Wie unterscheidest du beide am Beispiel `KlasseNr`?

Answer:
Bei `Schueler.KlasseNr`:

- **Domain-Integrität:** Der Wert hat den richtigen Typ und das richtige Format, z. B. Text wie `1a`.
- **Referentielle Integrität:** Der Wert existiert tatsächlich in `Klasse.KlasseNr`.

Ein Wert kann formal passend sein und trotzdem referentiell ungültig, z. B. `2a`, wenn es diese Klasse nicht gibt.

Zusammenfassung §10.1; Skript Folien 99-103


Datenbanken - Theorie

Question:
# CHECK vs. NOT NULL
Welche Integritätsprobleme lösen `CHECK` und `NOT NULL`?

Answer:
- **`NOT NULL`:** verhindert fehlende Werte in Pflichtfeldern.
- **`CHECK`:** beschränkt zulässige Werte durch eine Bedingung.

Beispiele:

- `Name NOT NULL`
- `CHECK (Alter >= 18)`

Prüfungsfalle: `NOT NULL` sagt nichts darüber, ob ein Wert fachlich plausibel ist. Dafür brauchst du zusätzliche Regeln wie `CHECK`.

Zusammenfassung §10.1; Skript Folien 99-101


Datenbanken - Theorie

Question:
# CASCADE Risiko
Warum ist `CASCADE` fachlich riskant?

Answer:
`CASCADE` überträgt Lösch- oder Änderungsoperationen automatisch auf abhängige Datensätze.

Das ist praktisch, kann aber fachlich gefährlich sein:

- Beim Löschen eines Masters verschwinden Detaildaten automatisch.
- Historische oder prüfungsrelevante Informationen können verloren gehen.
- Die Regel muss zur Fachdomäne passen.

Prüfung: Referenzaktionen immer begründen, nicht nur aufzählen.

Zusammenfassung §10.2; Skript Folien 104-106


Datenbanken - Theorie

Question:
# Projektionsfalle SQL
Warum führt SQL-`SELECT` leicht zu einer Begriffsverwechslung?

Answer:
In SQL heißt die Klausel `SELECT`, aber in der relationalen Algebra entspricht das Auswählen von Spalten der **Projektion** `π`.

Die **Selektion** `σ` filtert Zeilen anhand einer Bedingung und entspricht eher `WHERE`.

Merksatz:

- Projektion = Spalten
- Selektion = Zeilen

Zusammenfassung §11.2; Skript Folien 115-117


Datenbanken - Theorie

Question:
# Schema-Kompatibilität
Was bedeutet schema-kompatibel bei Mengenoperatoren?

Answer:
Mengenoperatoren wie `∪`, `∩` und `\` setzen voraus, dass die Relationen vergleichbar sind.

Das heißt:

- gleiche Anzahl von Attributen
- kompatible Datentypen bzw. Domänen
- fachlich gleiche Bedeutung der verglichenen Spalten

Beispiel: `π_Stadt(Kunden)` und `π_Stadt(Lieferungen)` sind kompatibel, weil beide Stadtwerte liefern.


Datenbanken - Theorie

Question:
# Join als Produkt plus Selektion
Warum kann ein Join als kartesisches Produkt plus Selektion verstanden werden?

Answer:
Zuerst bildet das kartesische Produkt alle möglichen Tupelkombinationen zweier Relationen.

Danach filtert eine Selektion nur die Kombinationen heraus, die die Join-Bedingung erfüllen.

Kurz:

`R ⋈_Bedingung S` entspricht `σ_Bedingung(R × S)`

Praktisch optimiert das DBMS diesen Ablauf, aber formal ist die Idee wichtig.


Datenbanken - Theorie

Question:
# Komplementnotation
Welche Zeichen können für NOT bzw. Komplement vorkommen?

Answer:
Im Skript kommen unterschiedliche Schreibweisen vor:

- Logik: `¬A`
- Mengen: `A^c`
- Mengen: `Ā`

Bedeutung jeweils: nicht A bzw. außerhalb von A.

Prüfungsfalle: Bei De Morgan genau auf Klammern und den Wechsel von `∪` zu `∩` achten.

Zusammenfassung §11.4 und §12.2; Skript Folien 136, 144, 148-149


Datenbanken - Theorie

Question:
# Fachanforderung zu Algebra
Wie liest du einen algebraischen Ausdruck als Fachanforderung?

Answer:
Arbeite von innen nach außen:

1. Welche Relationen werden verbunden?
2. Welche Tupel werden gefiltert?
3. Welche Attribute bleiben übrig?
4. Welche Mengenoperationen verändern die Zielgruppe?

Beispiel:

`π_Name(σ_Stadt='Berlin'(Kunden))`

liest sich als: Gib die Namen der Kunden aus, die in Berlin wohnen.

Zusammenfassung §11-12; Skript Folien 111-152


Datenbanken - Theorie

Question:
# Klammern in Zielgruppenlogik
Warum sind Klammern in Marketing-/Zielgruppenaufgaben wichtig?

Answer:
Klammern ändern die fachliche Bedeutung.

Beispiel:

- `A ∩ (B ∪ C)`: A und zusätzlich B oder C.
- `(A ∩ B) ∪ C`: entweder A und B oder unabhängig davon C.

Ohne Klammern gelten Prioritätsregeln, die oft nicht der natürlichsprachlichen Absicht entsprechen.

Prüfung: Bei Zielgruppen immer explizit klammern.

Zusammenfassung §12.1-12.2; Skript Folien 145-149