# Datenbanken – Gesamtzusammenfassung
**Dozent:** Prof. Dr. Arthur Zimmermann | HWR Berlin | 2026 | Semester 6

---

## Inhaltsverzeichnis

- [1. Modellierung](#1-modellierung-b_modellierung)
  - [1.1 Einführung](#11-einführung)
  - [1.2 Codds 12 Regeln](#12-codds-12-regeln)
  - [1.3 Mengenlehre](#13-mengenlehre-b_mengenlehre)
  - [1.4 ANSI-SPARC-Modell](#14-ansi-sparc-modell-drei-schichten-architektur)
  - [1.5 Phasen des Datenbankentwurfs](#15-phasen-des-datenbankentwurfs)
  - [1.6 Anforderungsanalyse](#16-anforderungsanalyse)
  - [1.7 Konzeptueller Entwurf – ERM](#17-konzeptueller-entwurf--entity-relationship-modell-erm)
  - [1.8 Logischer Entwurf – ERM → Tabellen](#18-logischer-entwurf--konvertierung-erm--tabellen)
- [2. Modellierung – Fallbeispiel](#2-modellierung--fallbeispiel-b_modellierungfb)
  - [Mini-Welt 1 (M:N)](#mini-welt-1)
  - [Mini-Welt 2 (1:N)](#mini-welt-2)
  - [Vergleich der Mini-Welten](#vergleich-der-mini-welten)
- [3. Relationale Algebra](#3-relationale-algebra-c_algebra)
  - [Grundoperatoren (vollständiger Satz)](#grundoperatoren-vollständiger-satz)
  - [Operatoren im Detail](#operatoren-im-detail)
  - [Zusammenfassung Operatoren](#zusammenfassung-operatoren)
- [4. SQL](#4-sql-d_sql)
  - [4.1 SQL-Kategorien (DDL/DML/DCL/TCL)](#41-sql-kategorien)
  - [4.2 Datentypen (Oracle)](#42-datentypen)
  - [4.3 Einfache Befehle (CREATE, INSERT, UPDATE, DELETE)](#43-einfache-befehle)
  - [4.4 Erweiterungen (LIKE, IN, GROUP BY, HAVING, NULL)](#44-erweiterungen)
  - [4.5 Anfragen über mehrere Relationen](#45-anfragen-über-mehrere-relationen)
  - [4.6 JOINs (NATURAL, INNER, OUTER, SEMI)](#46-joins)
  - [4.7 Anfragebearbeitung (Parser, Optimizer, RBO/CBO)](#47-anfragebearbeitung)
  - [4.8 Indizes (Binärbaum, Hashing, Bitmap)](#48-indizes)
- [5. Normalformen](#5-normalformen-e_nfs)
  - [5.1 Einführung & Funktionale Abhängigkeit](#51-einführung)
  - [5.3 1NF – Atomare Werte](#53-erste-normalform--1nf)
  - [5.4 2NF – Volle PK-Abhängigkeit](#54-zweite-normalform--2nf)
  - [5.5 3NF – Keine transitive Abhängigkeit](#55-dritte-normalform--3nf)
  - [5.6 BCNF – Schlüsselkandidaten-Überlappung](#56-boyce-codd-normalform--bcnf)
  - [5.7 4NF – Semantische Trennung](#57-vierte-normalform--4nf)
  - [5.8 5NF – Irreducible Zerlegung](#58-fünfte-normalform--5nf)
  - [5.9 Anomalien ohne Normalisierung](#59-anomalien-ohne-normalisierung)
  - [Durchgängiges Beispiel: Bahnwagen](#durchgängiges-beispiel-bahnwagen)
- [6. Transaktionen](#6-transaktionen-f_transaktionen)
  - [6.4 ACID-Eigenschaften](#64-acid-eigenschaften)
  - [6.5 Zustände einer Transaktion](#65-zustände-einer-transaktion)
  - [6.7 Probleme bei paralleler Ausführung](#67-probleme-bei-paralleler-ausführung)
  - [6.9 Isolationsstufen nach ANSI/ISO SQL92](#69-isolationsstufen-nach-ansiiso-sql92)
  - [6.11 Synchronisationsverfahren (2PL, Zeitstempel)](#611-synchronisationsverfahren)
- [7. Speicherstrukturen (Oracle)](#7-speicherstrukturen-g_speicherstrukturen)
  - [7.2 Datenträger (Tablespace, Segmente, Redo-Log)](#72-datenträger)
  - [7.3 Arbeitsspeicher (SGA, PGA, UGA)](#73-arbeitsspeicher)
- [8. Sicherungskonzepte](#8-sicherungskonzepte-h_sicherungskonzepte)
  - [8.4 Grundprinzipien (Authentifizierung, Autorisierung, Protokollierung)](#84-grundprinzipien-der-sicherheit)
  - [8.5 Integrität (Constraints, Trigger)](#85-integrität)
  - [8.6 Rechte (DAC, MAC, GRANT, REVOKE)](#86-rechte)
  - [8.7 Backup (Arten, Methoden, RAID, Strategie)](#87-backup)
- [9. Data Warehouse Konzepte](#9-data-warehouse-konzepte-i_dwkonzepte)
  - [9.2 OLAP](#92-olap)
  - [9.3 ROLAP / MOLAP / HOLAP](#93-rolap-molap-holap)
  - [9.5 Vergleich OLTP und OLAP](#95-vergleich-oltp-und-olap)
  - [9.6 ETL – Extract, Transform, Load](#96-etl--extract-transform-load)
  - [9.7 Hypercube-Operationen](#97-hypercube-operationen)
- [10. Andere Typen von Datenbanken](#10-andere-typen-von-datenbanken-j_anderedb)
  - [10.1 Hierarchische Datenbanken (IMS)](#101-hierarchische-datenbanken)
  - [10.2 Netzartige Datenbanken (UDS)](#102-netzartige-datenbanken)
  - [10.3 Verteilte Datenbanken (Two-Phase-Commit)](#103-verteilte-datenbanken)
  - [10.4 Objektorientierte Datenbanken](#104-objektorientierte-datenbanken)
  - [10.5 No-SQL-Datenbanken (BASE-Prinzip)](#105-no-sql-datenbanken-not-only-sql)
- [11. Gesamtübersicht & Cheat-Sheet](#11-gesamtübersicht--cheat-sheet)
  - [11.1 Datenbankentwicklungsprozess](#111-datenbankentwicklungsprozess-phasenmodell)
  - [11.2 ERM → Tabellen Kurzreferenz](#112-erm--relationale-tabellen--kurzreferenz)
  - [11.3 Normalformen Kurzreferenz](#113-normalformen--kurzreferenz)
  - [11.4 Relationale Algebra Operatoren](#114-relationale-algebra--vollständiger-operatorensatz)
  - [11.5 SQL SELECT-Syntax](#115-sql--vollständige-select-syntax)
  - [11.6 ACID & Isolationsstufen](#116-transaktionen--acid-und-isolationsstufen)
  - [11.7 Oracle-Speicherstruktur](#117-speicherstrukturen--oracle-hierarchie)
  - [11.8 Backup-Entscheidungsmatrix](#118-backup-entscheidungsmatrix)
  - [11.9 OLTP vs. OLAP](#119-oltp-vs-olap-vs-data-warehouse)
  - [11.10 No-SQL Vergleich](#1110-no-sql-datenbanken--vergleich)
  - [11.11 Begriffe-Schnellreferenz](#1111-wichtige-begriffe--schnellreferenz)

---

## 1. Modellierung (b_Modellierung)
### 1.1 Einführung
#### Definitionen

**Charakteristik der Informationen im Unternehmen:**
- Informationen bilden Entscheidungsgrundlagen
- Informationen können aus unterschiedlichen Quellen stammen
- Qualität hängt von Verfügbarkeit, Korrektheit und Vollständigkeit ab
- Erhebung, Speichern und Verarbeiten erzeugt Aufwände
- Aufgabengebiete sind durch Informationsbeziehungen verknüpft

**Aspekte des Datenmanagements:**
- Architektur (Datenmodellierung)
- Datentechnik (Hardware, Installation, Reorganisation, Sicherung)
- Administration und Datennutzung

**Anforderungen an Datenverwaltung:**
- Zentrale Verwaltung der Daten
- Vermeidung/Einschränkung von Redundanzen
- Vermeidung von Inkonsistenzen
- Gemeinsame Nutzung durch verschiedene Anwendungen
- Datenschutz und Datensicherung
- Datenintegrität
- Datenunabhängigkeit von Anwendungen

**Definitionen:**
- **Daten** = Logisch strukturierte Informationseinheiten
- **Datenbank** = Einrichtung für langfristige sichere Aufbewahrung von Daten

#### Modellierung

Ein **Modell** ist ein Abbild der realen Welt, das man mit Absicht erstellt, um bestimmte Probleme zu lösen.

**Modellbildungsprozess:**
Reales Problem → Modell → Analyse/Simulation → Theoretische Lösung → Interpretation → Überprüfung → Reale Lösung

**Kriterien eines Modells nach Heinrich Hertz:**
1. **Richtigkeit** — Nicht beweisbar, nur durch Experimente überprüfbar und widerlegbar
2. **Zulässigkeit** — Logisch eindeutig formuliert, ohne Widersprüche
3. **Zweckmäßigkeit** — Keine überflüssigen Anteile; so einfach wie möglich, so kompliziert wie nötig

**Modellierungsansätze:** Verschiedene Modellierungssprachen führen zu verschiedenen semantischen Datenmodellen. Praktische Bedeutung haben insbesondere **Entity-Relationship-Modellierung (ERM)** und **UML**. Gängige Vorgehensweise: Erst ER-Modell, dann Konvertierung in relationales Modell.

#### Datenhaltung

Zwei grundsätzliche Formen:
1. **Herkömmliche Form (Dateien):** Datenverwaltung in die Anwendung integriert → enormer Entwicklungsaufwand, kaum Datenaustausch
2. **Datenbanken:** Datenbank = Datenmanagement + Daten. DBMS übernimmt Speicherung, Aufruf, Änderungen, Sortieren, Sicherungen

**Vorteile von Datenbanken gegenüber Dateien:**
- Reduktion der Entwicklungskosten
- Flexible Verarbeitung und Darstellung
- Vermeidung von Redundanzen, Inkonsistenzen, Datenverlust
- Zugriffskontrolle
- Mehrbenutzerbetrieb
- Hohe Verfügbarkeit

**Dateien statt Datenbanken empfohlen bei:**
- Sehr kleinen, nicht-kommerziellen Anwendungen
- Systemnahen Anwendungen
- Verschiedenen Testumgebungen
- Groben konzeptuellen Entwicklungen

#### Architektur

**Client/Server-Architektur:**
- **Client** nimmt die Ressource in Anspruch (z. B. Darstellung)
- **Server** stellt die Ressource zur Verfügung (z. B. Bearbeitung)

**Oracle-Architektur:**
- SQL-Plus, SQL-Developer, Oracle Instant Client → Listener → Dispatcher → DBMS-Instanzen → Datenbestände
- Multi-Tenant-Container und Real Application Cluster (RAC)

**SQLite-Architektur (keine Client/Server-Architektur):**
- DBMS-Instanz direkt in die Anwendung eingebettet
- Datenbestand als Dateien im Dateisystem

#### Datenbankbenutzer

| Rolle | Aufgaben |
|---|---|
| **DBA (Datenbankadministrator)** | DB-Design, Softwareinstallation/-wartung, Speicherplatzverwaltung, Sicherheitsmechanismen, Backup/Recovery, Reorganisation, Systembeobachtung/Tuning |
| **Anwendungsentwickler** | Systemanalyse, SQL, Standard-Abfragen, Anwendungsentwicklung |
| **Endanwender** | Benutzung erstellter Programme, vorgefertigte/Ad-Hoc-Abfragen, QBE-Werkzeuge |

#### Entwicklung

- **1960er Jahre:** Jede Anwendung hat eigenes Datenmanagement und eigene Daten
- **1970er Jahre:** Gemeinsames Datenmanagement, aber noch getrennte Datenbestände
- **Heute:** Gemeinsames Datenmanagement und gemeinsame Datenbestände

Zugriff auf Datenbanken erfolgt programmatisch z. B. über **JDBC** (Java Database Connectivity).

#### Arten von Datenbanken

| Art | Status |
|---|---|
| Hierarchische Datenbanken | Heute selten verwendet |
| Netzartige Datenbanken | Heute selten verwendet |
| Dokumentenbasierte Datenbanken | Selten verwendet (z. B. MongoDB) |
| Key-Value-Datenbanken | Begrenzte Bedeutung (z. B. BerkeleyDB) |
| Objektorientierte Datenbanken | Vorhanden |
| **Relationale Datenbanken** | **Heute fast ausschließlich verwendet** |

**Warum relationale Datenbanken dominieren:**
- Beziehungen und Entitäten werden gleich dargestellt → derselbe Verarbeitungsmechanismus
- Relationale Algebra liefert umfangreiche und fortgeschrittene Operationen
- Alle anderen DB-Typen lassen sich damit emulieren

### 1.2 Codds 12 Regeln

Die **12 Regeln von Codd** definieren eine relationale Datenbank:

1. Vollständige Verwaltung über relationale Fähigkeiten
2. **Darstellung von Informationen:** Alle Informationen als Werte in Tabellen
3. **Zugriff auf Daten:** Über Tabellenname + Primärschlüssel + Spaltenname
4. **Systematische Behandlung von Nullwerten:** Durchgängig gleich als unbekannt/fehlend
5. **Struktur:** Systemkatalog auf derselben logischen Ebene wie die Daten
6. **Abfragesprache:** Mindestens eine Sprache mit vollständigem Befehlssatz (DDL, DML, Integrität, Autorisierung, Transaktionen)
7. **Aktualisieren von Sichten:** Theoretisch aktualisierbare Sichten müssen vom System aktualisierbar sein
8. **Abfragen und Bearbeiten:** Unterstützung für Einfügen, Aktualisieren und Löschen ganzer Tabellen
9. **Physikalische Datenunabhängigkeit:** Logischer Zugriff unabhängig von physikalischen Methoden
10. **Logische Datenunabhängigkeit:** Tabellenstruktur-Änderungen ohne Einfluss auf Anwendungslogik
11. **Unabhängigkeit der Integrität:** Integritätsregeln in der DB-Sprache definierbar, nicht umgehbar
12. **Verteilungsunabhängigkeit:** Logischer Zugriff unverändert bei verteilten Datenbanken

### 1.3 Mengenlehre (b_Mengenlehre)

Die Mengenlehre bildet die **mathematische Grundlage** der Theorie relationaler Datenbanken. Sie wurde von **Georg Cantor** entwickelt.

#### Definition (G. Cantor, 1895)

> Eine **Menge** ist die Zusammenfassung von bestimmten **wohlunterschiedenen Objekten** unserer Anschauung oder unseres Denkens zu einem Ganzen.

#### Eigenschaften einer Menge

1. Die **Natur der Elemente** ist unerheblich
2. Alle Elemente sind **unterschiedlich** (keine Duplikate)
3. **Bezeichnung:** M = { e₁, e₂, ..., eₙ, ... }, eᵢ ∈ M
4. Die **Reihenfolge der Elemente** spielt keine Rolle

**Beispiele:** Menge aller Computer im Unternehmen · Menge der positiven Zahlen · Menge der Elektronen im Universum

**Anzahl der Elemente:**
- **endlich** (z. B. Mitarbeiter einer Firma)
- **unendlich:**
  - **abzählbar** (z. B. ℕ, ℤ)
  - **unabzählbar** (z. B. ℝ)

#### Quantoren

| Symbol | Bedeutung |
|---|---|
| **∀** | Für alle Elemente (Allquantor) |
| **∃** | Es existiert mindestens ein Element (Existenzquantor) |

Quantoren werden verwendet, um Aussagen in der Mengenlehre (und generell in der Mathematik) formal zu schreiben.

#### Operationen über Mengen

Folgende allgemeine Operationen sind über Mengen definiert:

**Kartesisches Produkt (Kreuzprodukt)**
```
A × B = { (a, b) | ∀ a ∈ A und ∀ b ∈ B }
```
Beispiel: A = { +, − }, B = { 1, 2, 3 }
→ A × B = { (+,1), (−,1), (+,2), (−,2), (+,3), (−,3) } = { +1, −1, +2, −2, +3, −3 }

**Kartesisches Produkt mehrerer Mengen:**
```
M₁ × M₂ × ... × Mₙ = { (m₁, m₂, ..., mₙ) | ∀ mᵢ ∈ Mᵢ, ∀ i ∈ [1,...,n] }
```

Die Elemente heißen **n-Tupel**:
- n = 2: **Paar** (Dupel)
- n = 3: **Tripel**
- n = 4: **Quadrupel**
- n = 5: **Quintupel**

**Vereinigung**
```
A ∪ B = { e | ∀ e, e ∈ A oder e ∈ B }
```
Zur Vereinigung gehören alle Elemente aus A und alle aus B (keine Verdoppelung der Elemente).

**Durchschnitt (Schnittmenge)**
```
A ∩ B = { e | ∀ e, e ∈ A und e ∈ B }
```
Zum Durchschnitt gehören die Elemente, die gleichzeitig zu A und zu B gehören.

**Differenz**
```
A — B = { e | ∀ e, e ∈ A und e ∉ B }
```
Zur Differenz gehören die Elemente aus A, die zu B nicht gehören.

#### Zahlenmengen

| Symbol | Name | Definition |
|---|---|---|
| **ℕ** | Natürliche Zahlen | = { 0, 1, 2, 3, ... } |
| **ℤ** | Ganze Zahlen | = { ..., −3, −2, −1, 0, 1, 2, 3, ... } |
| **ℚ** | Rationale Zahlen | = { q \| ∃ x,y ∈ ℤ ⟹ q = x/y } |
| **ℐ** | Irrationale Zahlen | = { s \| ∀ x,y ∈ ℤ, y≠0 ⟹ s ≠ x/y } |
| **ℝ** | Reelle Zahlen | = ℚ ∪ ℐ |
| **ℂ** | Komplexe Zahlen | = { z = a+b×i \| ∀ a,b ∈ ℝ, i×i = −1 } |

**Inklusionen:** ℕ ⊂ ℤ ⊂ ℚ ⊂ ℝ ⊂ ℂ

**Operationen auf ganzen Zahlen:** Addition, Subtraktion, Multiplikation, ganzzahlige Division (liefert Quotient und Rest – zwei unterschiedliche Operationen)

**Operationen auf reellen Zahlen:** Addition, Subtraktion, Multiplikation, reelle Division (liefert nur Quotient; kein Rest definiert)

Alle Mengen außer ℂ haben eine **natürliche (lineare) Ordnung**.

#### Dimensionen

Gegeben zwei Mengen R₁ und R₂ mit dim(R₁) = k und dim(R₂) = n:

| Operation | Dimension des Ergebnisses |
|---|---|
| R₁ × R₂ | k · n |
| R₁ ∪ R₂ | ∈ { max{k,n}, ..., k+n } |
| R₁ ∩ R₂ | ∈ { 0, 1, ..., min{k,n} } |
| R₁ — R₂ | k − dim{ R₁ ∩ R₂ } |

#### Relevanz für Datenbanken

- Eine **Relation** (Tabelle) ist eine Untermenge des kartesischen Produkts mehrerer Datentypen
- **Keine Duplikate** in Mengen → in relationaler Algebra gibt es keine doppelten Tupel (in SQL daher `DISTINCT` nötig)
- Die Mengenlehre erklärt direkt, warum im Fallbeispiel (Mini-Welt 1) gleiche [RechnPosNr, Menge]-Kombinationen zusammengefasst werden müssen

### 1.4 ANSI-SPARC-Modell (Drei-Schichten-Architektur)

Das ANSI-SPARC-Modell gewährleistet Unabhängigkeit der Datenbank von Programmiersprache und Hardware:

| Ebene | Bezeichnung | Inhalt |
|---|---|---|
| **Externe Ebene** | Anwendungs-Ebene | Benutzeroberflächen, Datensichten, API, Schnittstellen. Jede Sicht zeigt nur einen Teil der Daten |
| **Konzeptionelle Ebene** | Logische Ebene | Beziehungen, Daten. Relationales Datenmodell, ERM-Diagramme, Integritätsbedingungen, Zugriffsrechte |
| **Interne Ebene** | Physische Ebene | Art und Form der Speicherung. Dateien, Partitionen, Tablespaces, Zugriffsmechanismen |

### 1.5 Phasen des Datenbankentwurfs

1. **Anforderungsanalyse** → Spezifikation (Pflichtenheft)
2. **Konzeptueller Entwurf** → Konzeptuelles Schema (ERM)
3. **Logischer Entwurf** → Logisches Schema (Tabellen)
4. **Physischer Entwurf** → Physisches Schema (Datenträger)

### 1.6 Anforderungsanalyse

Im Laufe der Anforderungsanalyse wird erfasst:
- Welche Abteilungen mit der DB arbeiten
- Welche Geschäftsprozesse unterstützt werden
- Welche Daten involviert werden
- Wie die Daten strukturiert sind
- Qualitative und quantitative Anforderungen

**Schritte nach A. Kemper:**
1. Identifikation von Organisationseinheiten
2. Identifikation der zu unterstützenden Aufgaben
3. Anforderungs-Sammelplan (zu befragende Personen)
4. Anforderungs-Sammlung
5. Filterung (Verständigkeit und Eindeutigkeit prüfen)
6. Satzklassifikationen (Objekte, Beziehungen, Operationen, Ereignisse)
7. Formalisierung/Systematisierung (ins Pflichtenheft übertragen)

**Ergebnisse der Anforderungsanalyse:**
- **Informationsanforderungen:** Beschreibung von Objekten/Attributen und Beziehungen/Attributen
- **Datenverarbeitungsanforderungen:** Beschreibung von Prozessen

**Drei Arten von Beschreibungen:**

**Objektbeschreibung** (z. B. Uni-Angestellte):

| Attribut | Typ | Länge | Identifizierend | Beispiel |
|---|---|---|---|---|
| PersonalNr | Char | 10 | ja | 1234561234 |
| Gehalt | Dezimal | 8.2 | nein | 9000.11 |
| Rang | String | 4 | nein | W3 |

**Beziehungsbeschreibung** (z. B. prüfen):
- Beteiligte Objekte: Professor (Prüfer), Student (Prüfling), Vorlesung (Lehrstoff)
- Attribute: Datum, Uhrzeit, Note

**Prozessbeschreibung** (z. B. Zeugnisausstellung):
- Häufigkeit, Priorität, benötigte Daten, Datenmenge

### 1.7 Konzeptueller Entwurf – Entity-Relationship-Modell (ERM)

Auf Basis der Anforderungsanalyse wird ein konzeptuelles ERM erstellt. Das konkrete DBMS wird noch nicht betrachtet.

#### Modellierungsstrukturen in Peter-Chen-Notation

| Element | Grafische Darstellung | Bedeutung |
|---|---|---|
| **Entitätstypen** | Rechteck | Objekte der realen Welt |
| **Beziehungstypen** | Raute | Bindungen zwischen Entitäten |
| **Attribute** | Oval/Kreis | Charakteristiken von Entitäten und Beziehungen |
| **Funktionalitäten** | Beschriftung an Verbindungslinien | Kardinalität der Beziehungen |
| **Schlüssel** | Unterstrichene Attribute | Identifizierende Attribute |
| **Rollen** | Beschriftung bei rekursiven Beziehungen | Rolle einer Entität in der Beziehung |

#### Entitätstypen

Gegenstände sind Objekte der realen Welt, die zu **Gegenstandstypen (Entitätstypen)** abstrahiert werden:
- "Zimmermann", "Merkel", "Meier" → **Mensch**
- "VW", "Mercedes", "BMW" → **Auto**

Man arbeitet ausschließlich mit Entitätstypen (abstrakte Klassen), nicht mit einzelnen Instanzen.

#### Beziehungstypen

Beziehungen drücken Bindungen zwischen Entitäten aus. Nicht alle Entitätstypen müssen verbunden sein, aber ein alleinstehender Entitätstyp ohne Beziehung ist verdächtig.

#### Attribute

**Attributierte Beziehungen:** Wenn beide Entitätstypen semantisch gleiche Attribute haben, werden diese dem Beziehungstyp zugeordnet (z. B. Betrag bei "Kredit geben" zwischen Kunde und Bank).

**Entscheidung Entitätstyp vs. Attribut:**
- Wird etwas durch anderes beschrieben → das Beschriebene ist Entitätstyp, das Beschreibende ist Attribut
- Kann etwas durch nichts weiteres beschrieben werden → es ist ein Attribut

**Attributtypen:**

| Typ | Beschreibung | Beispiel |
|---|---|---|
| **Einfach** | Ein Wert zu einem Zeitpunkt | Name = "Müller" |
| **Mehrwertig** | Mehrere Werte gleichzeitig | Ampel: rot + gelb |
| **Zusammengesetzt** | Besteht aus Teilattributen | Adresse: PLZ + Ort + Straße |
| **Abgeleitet** | Aus anderen Attributen berechnet | Bruttopreis = Netto × (1 + MwSt) |

#### Schlüssel und Primärschlüssel

- **Schlüssel:** Attributmenge, deren Werte eine Entität eindeutig identifizieren
- **Schlüsselkandidaten:** Mehrere mögliche Schlüssel
- **Primärschlüssel (PK):** Der Kandidat mit minimaler Länge, im ERM unterstrichen
- **Minimaler Schlüssel:** Keine Untermenge des PK bildet selbst einen Schlüssel
- **Wichtig:** Wahl eines anderen PK ändert das gesamte Modell

#### Rekursive Beziehungen

Beziehungen zwischen Entitäten desselben Entitätstyps. Dabei werden **Rollen** zugeschrieben.

**Beispiele:**
- Vorlesungen → voraussetzen (Vorgänger/Nachfolger)
- Softwareprodukt → Versionsnummer
- Polizisten → im Zweierteam patrouillieren

#### Funktionalitäten

Funktionalität gibt an, wie viele Instanzen in einer Beziehung teilnehmen:

| Typ | Beschreibung | Beispiel |
|---|---|---|
| **1:1** | Einer Entität aus E1 entspricht höchstens eine aus E2 (und umgekehrt) | Persönliche Daten ↔ Ansprechdaten |
| **1:N** | Einer aus E1 entsprechen mehrere aus E2, aber einer aus E2 höchstens eine aus E1 | Schüler → Fahrausweise |
| **N:M** | Mehrere aus E1 entsprechen mehreren aus E2 | Studenten ↔ Vorlesungen (hören) |

**Auflösung einer M:N-Beziehung:** Wird in zwei 1:N-Beziehungen aufgebrochen durch Einführung eines neuen Entitätstyps (z. B. Hersteller ↔ Lieferant → Hersteller → Herstlr_Liefrnt ← Lieferant).

#### (min,max)-Notation

Genauere Angabe der Kardinalitäten als Standardfunktionalitäten:
- **min = 0:** Entitäten, die an keiner Beziehung teilnehmen
- **max = *:** Beliebig viele Entitäten

**Beispiel Polyeder:**
- Polyeder (4,*) — Hülle — (1,1) Flächen
- Flächen (3,*) — Grenze — (2,2) Kanten
- Kanten (2,2) — StartEnde — (3,*) Punkte

#### Mehrstellige Beziehungen

- **Ternäre Beziehung:** Zwischen 3 Entitätstypen
- **n-äre Beziehung:** Zwischen n Entitätstypen
- Sollten möglichst in binäre Beziehungen umgewandelt werden
- Beispiel: "prüfen" (Student, Vorlesung, Professor) → neuer Entitätstyp "Prüfungen" mit binären Beziehungen

#### Spezielle Konzepte

**Komposition / Schwache Entitäten (has-a):**
Existenz eines Entitätstyps ist von der Existenz eines anderen abhängig.
- Beispiel: Konto existiert nur in Zusammenhang mit einer Bank

**Generalisierung (is-a):**
Abstraktion auf Ebene der Entitätstypen. Gemeinsame Eigenschaften werden in einen **Obertyp** ausgelagert, spezifische bleiben bei den **Untertypen**.
- Beispiel: Lebensmittel (gültig bis) und Eisenwaren (Garantiefrist) → Obertyp **Produkt** (Bezeichnung, Hersteller)

**Aggregation (has-a):**
Verschiedene Entitätstypen bilden in ihrer Gemeinsamkeit einen neuen Entitätstyp.
- Beispiel: Fahrrad besteht aus Rahmen (Rohre, Lenker) und Rad (Speiche, Felge)

### 1.8 Logischer Entwurf – Konvertierung ERM → Tabellen

#### Definitionen

- **Datentyp** = Werte + Operationen (z. B. integer: +, -, *, /, mod)
- **Relation** = Untermenge des kartesischen Produktes mehrerer Datentypen = **Tabelle**
- **Tupel** = Zeile (Record, Datensatz)
- **Feld** = Spalte (Attribut, Eigenschaft)
- **Schema** = Namen aller Felder + Datentypen + Länge + Reihenfolge

**Vorteile des relationalen Modells:**
- Entitäten und Beziehungen werden gleich als Tabellen dargestellt
- Dieselben algebraischen Operationen für beide
- Mathematisch begründet durch E.F. Codd

**Notation:**
```
RelationsName = { [ Feld1:Datentyp1, Feld2:Datentyp2, ... ] }
```
Beispiel: `Auto = { [ KFZ:string, Modell:string, Gewicht:real, Baujahr:integer ] }`
Primärschlüssel wird unterstrichen.

#### Konvertierungsregeln

**Regeln für Entitätstypen:**
1. Neue Tabelle (Entitäts-Tabelle) bilden
2. Alle Attribute des Entitätstyps inkludieren

**Regeln für Beziehungstypen:**
1. Neue Tabelle (Beziehungs-Tabelle) bilden
2. Primärschlüssel aller verbundenen Entitätstypen inkludieren → bilden i.d.R. den PK der Beziehungstabelle
3. Attribute des Beziehungstyps inkludieren

#### Vereinfachung der Darstellungen

**1:1-Beziehungen** – Zwei Optionen:
- **Option A:** Beide Entitäts-Tabellen zu einer Tabelle zusammenführen + Beziehungsattribute. Vorsicht: Datensätze können zu groß werden
- **Option B:** Beziehungs-Tabelle weglassen, PK einer Entitäts-Tabelle als FK in die andere aufnehmen

**1:N-Beziehungen:**
- Beziehungs-Tabelle weglassen
- In die Tabelle auf der **N-Seite** den PK der Tabelle auf der **1-Seite** als **Fremdschlüssel (FK)** einfügen
- Beziehungsattribute ebenfalls in die N-Seiten-Tabelle

**Schwache Entitäten:**
- Eigene Tabelle für schwache Entität
- PK der referenzierten (starken) Entität wird **Teil des PK** der schwachen Entität (Unterschied zu normalen 1:N-Beziehungen, wo der FK nicht Teil des PK wird)

#### Beispiel: Uni-Schema als Tabellen

| Tabelle | Felder |
|---|---|
| Professoren | PersNr, Name, Rang, Raum |
| Studenten | MatrNr, Name, Semester |
| Vorlesungen | VorlNr, Titel, SWS, gelesenVon (FK→Professoren) |
| Assistenten | PersNr, Name, Fachgebiet, Boss (FK→Professoren) |
| hören | MatrNr (FK), VorlNr (FK) |
| voraussetzen | Vorgänger (FK), Nachfolger (FK) |
| prüfen | MatrNr (FK), VorlNr (FK), PersNr (FK), Note |

#### Wichtige Bemerkung

**Keine Felder/PK/FK willkürlich in Tabellen hinzufügen!** Nur laut Vereinfachungsregeln.

**Ausnahmen:**
- ERM-bezogene Gründe (z. B. PID, MonsterID)
- Auditing/Richtlinien (z. B. "Alle Zeilen müssen fortlaufend nummeriert werden")
- Administrative Gründe (z. B. Fusion großer Datenmengen)
- Anwendungsbezogene Gründe (z. B. OO-DB pflegen PK selbst)

**Kontroverse um künstliche IDs:**
Einige Autoren empfehlen ausdrücklich künstliche IDs, weil:
- PK soll keine semantischen Informationen enthalten
- PK darf sich nicht mit der Zeit ändern
- PK soll einfach aufgebaut sein (nicht aus mehreren Feldern)

---

## 2. Modellierung – Fallbeispiel (b_ModellierungFB)

### Überblick

Modellierung einer Rechnung: Beispiel-Rechnungen betrachten → Mini-Welten beschreiben → Konzeptuellen Entwurf erstellen → Logischen Entwurf erstellen → Fazit

### Identifizierte Entitätstypen

**Artikel:**
- Artikelnummer (kann fehlen), Beschreibung (immer vorhanden), Einzelpreis (Netto), MwSt-Satz und MwSt-Betrag

**Rechnungsposition:**
- Reihenfolgenummer (kann fehlen, aber wichtig), Menge / Anzahl der Artikel

**Rechnung (übergeordnet):**
- Rechnungsnummer, Datum, Gesamtsumme (abgeleitetes Attribut), MwSt-Betrag der ganzen Rechnung (abgeleitetes Attribut)

**Formale Notation:**
```
Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
Artikel = { [ ArtNr, ArtBezeichnung, EP, MwStSatz ] }
```

### Mini-Welt 1

Alle Rechnungen werden **durchgehend** betrachtet. Gleiche Kombinationen [RechnPosNr, Menge] werden **zusammengefasst** (laut Mengenlehre nach G. Cantor: keine doppelten Elemente).

```
Rechnungsposition = { [ RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
```

**Konzeptueller Entwurf:**

| Beziehung | Funktionalität |
|---|---|
| Rechnung — besteht aus — Rechnungsposition | **M : N** |
| Rechnungsposition — beinhaltet — Artikel | **N : 1** |

**Logischer Entwurf:**
```
Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
Artikel = { [ ArtNr, EP, MwStSatz, ArtBezeichnung ] }
Rechnungsposition = { [ RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
besteht_aus = { [ RgNr, RechnPosNr, Menge ] }
beinhaltet = { [ ArtNr, RechnPosNr, Menge ] }
```

**Vereinfachung** (1:N-Beziehung "beinhaltet" auflösen):
```
Rechnungsposition = { [ ArtNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
```

### Mini-Welt 2

**Alle** Rechnungspositionen aus allen Rechnungen werden individuell erfasst, auch wenn [RechnPosNr, Menge] gleich sind. Da Duplikate nach Cantor nicht zulässig sind, wird ein neues Attribut **LaufendeNummer (LfndNr)** eingeführt.

**Konsequenz:** Mehr Entitäten im Entitätstyp, mehr Redundanz, aber die **Zuordnung jeder Position zu einer Rechnung bleibt erhalten**.

```
Rechnungsposition = { [ LfndNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
```

**Konzeptueller Entwurf:**

| Beziehung | Funktionalität |
|---|---|
| Rechnung — besteht aus — Rechnungsposition | **1 : N** |
| Rechnungsposition — beinhaltet — Artikel | **N : 1** |

**Logischer Entwurf (nach Vereinfachung beider 1:N-Beziehungen):**
```
Rechnungsposition = { [ ArtNr, RgNr, LfndNr, RechnPosNr, Menge,
                        Zwischensumme, ZwischenMwSt ] }
```

**Hinweis:** LfndNr wird nicht für Verknüpfungen (Join-Prädikat) verwendet, hat wenig Semantik, muss aber gepflegt werden.

### Vergleich der Mini-Welten

| Aspekt | Mini-Welt 1 | Mini-Welt 2 |
|---|---|---|
| Beziehung Rechnung↔Position | M:N | 1:N |
| Duplikate | Keine (zusammengefasst) | Individuell (via LfndNr) |
| Zuordnung Position→Rechnung | Geht verloren | Bleibt erhalten |
| Redundanz | Weniger | Mehr |
| Tabellen nach Vereinfachung | 3 + besteht_aus | 3 (alles in einer) |

**Empfehlung:** Beide Modelle implementieren und Antwortzeiten bei größerem Datenumfang vergleichen.

---

## 3. Relationale Algebra (c_Algebra)

### Formale Sprachen für Relationen

| Sprache | Beschreibung |
|---|---|
| **Relationale Algebra** | Definiert Operationen über Relationen; Ergebnis ist wieder eine Relation (Geschlossenheit). Definiert **was** man will, nicht **wie** |
| **Relationenkalkül** | Deklarative Beschreibung gewünschter Ergebnisse |

Die relationale Algebra bildet die **Basis für SQL**.

**Beispiele Relationenkalkül:**
```
{ k | k ∈ KUNDEN ∧ k.STATUS = "Aktiv" }
{ [a.NAME, f.TITEL] | a∈ACTOR ∧ f∈FILM ∧ a.ID=f.A_ID }
```

### Grundoperatoren (vollständiger Satz)

| Operator | Notation | Beschreibung |
|---|---|---|
| **Selektion** | σ_Prädikat(Relation) | Zeilen filtern nach Bedingung |
| **Projektion** | π_Attribute(Relation) | Spalten auswählen |
| **Kartesisches Produkt** | R1 × R2 | Alle Kombinationen von Zeilen |
| **Umbenennung** | ρ_Alias(Relation) | Relation oder Attribute umbenennen |
| **Vereinigung** | R1 ∪ R2 | Tupel aus beiden Relationen zusammenfassen |
| **Differenz** | R1 — R2 | Tupel aus R1, die nicht in R2 vorkommen |

**Wichtig:** Dieser Satz ist **vollständig** — alle anderen Operatoren lassen sich durch diese ausdrücken.

### Operatoren im Detail

#### Selektion σ

Filtert Zeilen einer Relation anhand eines Prädikats. Das Prädikat wird für **jede Zeile** geprüft.

```
σ_{Semester > 10}(Studenten)
→ Ergebnis: MatrNr 24002 (Xenokrates, 18), MatrNr 25403 (Jonas, 12)

σ_{Name = 'Sokrates'}(Professoren)
→ Ergebnis: PersNr 2125, Sokrates, C4, Raum 226
```

#### Projektion π

Wählt bestimmte Spalten aus einer Relation aus.

```
π_{MatrNr, Name}(Studenten)
→ Ergebnis: Nur MatrNr und Name aller Studenten

π_{Rang}(Professoren)
→ Ergebnis: C3, C4 (Duplikate werden in relationaler Algebra eliminiert!)
```

**Wichtig:** In relationaler Algebra gibt es **keine Duplikate**, in SQL schon (deshalb `DISTINCT`).

#### Zusammenhang Algebra ↔ SQL

| Relationale Algebra | SQL |
|---|---|
| **π** (Projektion) | **SELECT** |
| **σ** (Selektion) | **WHERE** |

| Anfrage | Algebra | SQL |
|---|---|---|
| Wie heißen die Professoren? | π_{Name}(Professoren) | `SELECT Name FROM Professoren;` |
| Name des Studenten mit MatrNr 25403? | π_{Name}(σ_{MatrNr=25403}(Studenten)) | `SELECT Name FROM Studenten WHERE MatrNr = 25403` |
| Studenten mit >6 Semestern? | π_{Name,MatrNr}(σ_{Semester>6}(Studenten)) | `SELECT Name, MatrNr FROM Studenten WHERE Semester > 6` |

#### Reihenfolge der Operatoren

**Grundsätzlich dürfen relationale Operatoren in zusammengesetzten Ausdrücken nicht vertauscht werden!**

```
π_{Name,MatrNr}(σ_{Semester>6}(Studenten))     ← korrekt
σ_{Semester>6}(π_{Name,MatrNr}(Studenten))     ← FALSCH (Semester ist nach Projektion weg!)
```

#### Umbenennung ρ

Notwendig wenn:
- Relationen gleich benannte Attribute besitzen, die beide in der Abfrage benötigt werden
- Eine Relation **mehrfach** in einer Abfrage vorkommt (rekursive Beziehungen)

**Umbenennung ist immer temporär (operatorbezogen).**

```
ρ_{Relation-Alias}(Relation)           ← Relation umbenennen
ρ_{Attribut-Alias ← Attribut}(Relation) ← Attribut umbenennen
```

#### Vereinigung ∪

**Voraussetzungen (Vereinigungskompatibilität):**
- Gleiche Anzahl von Attributen
- Attribute gleich benannt
- Gleichnamige Attribute haben denselben Datentyp

Zum Erfüllen der Kriterien können Projektion und Umbenennung verwendet werden.

**Ergebnis:** Selbes Schema wie die Operanden, Tupel zusammengefasst, **Duplikate eliminiert**.

```sql
SELECT Name FROM Studenten UNION
SELECT Name FROM Assistenten UNION
SELECT Name FROM Professoren;
```

**Beispiel:**
```
R = { [1, abc, 1.5], [2, def, 2.3] }
S = { [7, xyz, 4.4], [8, uvw, 6.7] }
R ∪ S = { [1, abc, 1.5], [2, def, 2.3], [7, xyz, 4.4], [8, uvw, 6.7] }
```

#### Differenz —

**Gleiche Voraussetzungen** wie bei Vereinigung.

**Ergebnis:** Selbes Schema, enthält Tupel aus R1, die in R2 **nicht** vorkommen.

```
R = { [1, abc, 1.5], [2, def, 2.3] }
S = { [2, def, 2.3], [7, xyz, 4.4] }
R — S = { [1, abc, 1.5] }
```

**SQL-Umsetzung:**
```sql
-- Variante 1: NOT IN
SELECT Name FROM Studenten WHERE MatrNr NOT IN
  (SELECT DISTINCT MatrNr FROM hoeren);

-- Variante 2: MINUS
SELECT MatrNr FROM Studenten
MINUS
SELECT DISTINCT MatrNr FROM hoeren;
```

#### Schnittmenge ∩

Die Schnittmenge ist **kein Grundoperator**, kann aber abgeleitet werden:

```
A ∩ B = A — (A — B) = B — (B — A)
```

**SQL-Umsetzung:**
```sql
-- Variante 1: INTERSECT
SELECT gelesenVon AS PersNr FROM Vorlesungen
INTERSECT
SELECT PersNr FROM Professoren WHERE Rang = 'C4';

-- Variante 2: IN (falls INTERSECT nicht verfügbar)
SELECT gelesenVon AS PersNr FROM Vorlesungen
WHERE PersNr IN
  (SELECT PersNr FROM Professoren WHERE Rang = 'C4');
```

#### Kartesisches Produkt × und Join

Komplexe Abfragen nutzen das kartesische Produkt mit anschließender Selektion (**Equi-Join**):

**Anfrage:** "Welche Studenten hören welche Vorlesungen?"

```
π_{s.Name, v.Titel}(σ_{h.VorlNr=v.VorlNr ∧ s.MatrNr=h.MatrNr}(
    Studenten s × Vorlesungen v × hoeren h))
```

### Zusammenfassung Operatoren

| Operator | Symbol | SQL-Entsprechung | Grundoperator? |
|---|---|---|---|
| Selektion | σ | WHERE | Ja |
| Projektion | π | SELECT | Ja |
| Kartesisches Produkt | × | FROM (Cross Join) | Ja |
| Umbenennung | ρ | AS | Ja |
| Vereinigung | ∪ | UNION | Ja |
| Differenz | — | MINUS / NOT IN | Ja |
| Schnittmenge | ∩ | INTERSECT / IN | Nein (ableitbar) |
| Join | ⋈ | JOIN ... ON | Nein (σ + ×) |

---

## 4. SQL (d_SQL)

### 4.1 SQL-Kategorien

| Kategorie | Abkürzung | Befehle |
|---|---|---|
| **Data Definition Language** | DDL | ALTER, COMMENT, CREATE, DROP, RENAME, TRUNCATE |
| **Data Manipulation Language** | DML | CALL, DELETE, EXPLAIN, INSERT, LOCK, MERGE, SELECT, UPDATE |
| **Data Control Language** | DCL | GRANT, REVOKE |
| **Transaction Control Language** | TCL | COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION |

### 4.2 Datentypen

**Datentyp = Werte + Operationen**

#### Oracle-Datentypen

| Datentyp | Beschreibung |
|---|---|
| **VARCHAR(n) / VARCHAR2(n)** | Zeichenkette variabler Länge |
| **CHAR(n)** | Zeichenkette fester Länge |
| **NUMBER(p, s)** | Dezimale Zahl, p=Stellen (1–38), s=Nachkomma (-84–127), Werte bis ±10^125 |
| **DECIMAL(p, s)** | Dezimale Zahl, Werte bis ±10^308 |
| **INTEGER** | Ganze Zahl, -2.147.483.648 bis 2.147.483.647 |
| **DATE** | Datum/Uhrzeit (sekundengenau) |
| **RAW(n)** | Binärdaten, 1–2000 Bytes |
| **LONG RAW** | Binärdaten bis 2 GiB |
| **CLOB** | Zeichenketten bis 4 GiB |
| **BLOB** | Binärdaten bis 4 GiB |
| **CFILE / BFILE** | Zeiger auf externe Dateien (Text/Binär) |

### 4.3 Einfache Befehle

#### DDL – Tabellen anlegen und löschen

```sql
CREATE TABLE Professoren (
    PersNr  INTEGER NOT NULL,
    Name    VARCHAR(30) NOT NULL,
    Rang    CHARACTER(2),
    PRIMARY KEY(PersNr)
);

DROP TABLE Professoren;
```

#### DML – Einfügen, Löschen, Ändern

```sql
-- Einzelnes Tupel einfügen
INSERT INTO Professoren (PersNr, Name, Rang)
VALUES (30314, 'Cantor', 'W2');

-- Mehrere Tupel gleichzeitig
INSERT INTO Professoren (PersNr, Name, Rang) VALUES
(30314, 'Cantor', 'W2'),
(30315, 'Leibniz', 'W1'),
(30316, 'Plank', 'W1');

-- Einfügen mit verschachtelter Abfrage
INSERT INTO hoeren
SELECT MatrNr, VorlNr
FROM Studenten, Vorlesungen
WHERE Titel = 'Datenbanken';

-- Teilweises Einfügen (Rang wird NULL)
INSERT INTO Professoren (PersNr, Name)
VALUES (30317, 'Feuerbach');

-- Löschen
DELETE FROM Professoren;
DELETE FROM Professoren WHERE Rang = 'W3';

-- Ändern
UPDATE Studenten SET Semester = Semester + 1;
```

#### Inline-View

Eine SELECT-Anweisung mit einer weiteren SELECT-Anweisung in der FROM-Klausel:

```sql
SELECT p.Name, p.Raum
FROM Professoren p,
    (SELECT DISTINCT Boss FROM Assistenten) a
WHERE p.PersNr = a.Boss;
```

#### Allgemeine SELECT-Syntax

```sql
SELECT column1, column2
FROM table1, table2
WHERE condition
GROUP BY column1, column2
HAVING condition
ORDER BY column1, column2;
```

### 4.4 Erweiterungen

#### Sortieren
```sql
SELECT PersNr, Name, Rang FROM Professoren
ORDER BY Rang DESC, Name ASC;
```

#### Duplikate eliminieren
```sql
SELECT DISTINCT Rang FROM Professoren;
```

#### Platzhalter (nur mit LIKE)
- `_` — genau ein Zeichen
- `%` — beliebig viele Zeichen (auch keines)

```sql
SELECT * FROM Professoren WHERE Rang LIKE 'W_';
SELECT * FROM Professoren WHERE Name LIKE 'T%eophrastos';
```

#### IN / NOT IN
```sql
SELECT Name FROM Studenten WHERE Semester IN (1, 2, 3);

SELECT Name FROM Professoren
WHERE PersNr NOT IN (SELECT gelesenVon FROM Vorlesungen);
```

#### ALL / ANY
```sql
-- ALL: Alle Bedingungen müssen erfüllt sein (AND)
SELECT Name FROM Studenten WHERE Semester >= ALL (7, 8, 9);

-- ANY: Mindestens eine Bedingung (OR)
SELECT Name FROM Studenten WHERE Semester >= ANY (7, 8, 9);
```

#### Aggregatfunktionen

Aggregatfunktionen berechnen einen **einzelnen Wert** aus einer Menge von Zeilen:

| Funktion | Beschreibung | Beispiel |
|---|---|---|
| **COUNT(\*)** | Anzahl aller Zeilen | Anzahl aller Studenten |
| **COUNT(Spalte)** | Anzahl nicht-NULL-Werte | Anzahl Studenten mit gesetztem Semester |
| **SUM(Spalte)** | Summe der Werte | Summe aller Gehälter |
| **AVG(Spalte)** | Durchschnitt | Durchschnittsnote |
| **MIN(Spalte)** | Kleinster Wert | Niedrigstes Semester |
| **MAX(Spalte)** | Größter Wert | Höchstes Semester |

```sql
-- Anzahl aller Studenten
SELECT COUNT(*) FROM Studenten;

-- Durchschnittsnote
SELECT AVG(Note) FROM pruefen;

-- Anzahl verschiedener Ränge
SELECT COUNT(DISTINCT Rang) FROM Professoren;
```

#### GROUP BY

`GROUP BY` gruppiert Zeilen nach gemeinsamen Attributwerten, sodass Aggregatfunktionen **pro Gruppe** berechnet werden:

```sql
-- Anzahl Vorlesungen pro Professor
SELECT gelesenVon, COUNT(*) AS Anzahl
FROM Vorlesungen
GROUP BY gelesenVon;

-- Durchschnittsnote pro Vorlesung
SELECT VorlNr, AVG(Note) AS Schnitt
FROM pruefen
GROUP BY VorlNr;
```

**Wichtig:** In der SELECT-Klausel dürfen bei GROUP BY nur:
- Spalten aus GROUP BY und/oder
- Aggregatfunktionen stehen

#### HAVING

`HAVING` filtert **Gruppen** (analog zu WHERE für Zeilen). Wird immer **nach** GROUP BY angewendet:

```sql
-- Nur Professoren, die mehr als 2 Vorlesungen halten
SELECT gelesenVon, COUNT(*) AS Anzahl
FROM Vorlesungen
GROUP BY gelesenVon
HAVING COUNT(*) > 2;
```

**Reihenfolge der Klauseln:**
```sql
SELECT   ...          -- 5. Projektion
FROM     ...          -- 1. Tabellen bestimmen
WHERE    ...          -- 2. Zeilen filtern
GROUP BY ...          -- 3. Gruppen bilden
HAVING   ...          -- 4. Gruppen filtern
ORDER BY ...          -- 6. Sortieren
```

#### NULL-Werte

- `NULL` bedeutet **unbekannt / nicht vorhanden**
- Vergleiche mit NULL sind immer `NULL` (nicht TRUE oder FALSE)
- Prüfung auf NULL: `IS NULL` / `IS NOT NULL`

```sql
-- Professoren ohne Raum
SELECT Name FROM Professoren WHERE Raum IS NULL;

-- Professoren mit Raum
SELECT Name FROM Professoren WHERE Raum IS NOT NULL;
```

- Aggregatfunktionen **ignorieren** NULL-Werte (außer COUNT(\*))

### 4.5 Anfragen über mehrere Relationen

**Vorgehensweise:**
1. Kreuzprodukt aus Tabellen bilden
2. Relevante Zeilen und Felder ausschneiden

**Wichtigste Voraussetzung:** Information über Verbindung zwischen Tabellen (Join-Prädikat).

```sql
SELECT p.Name Professor, a.Name Assistent
FROM Professoren p, Assistenten a
WHERE p.PersNr = a.Boss;    -- join-Prädikat (access-Prädikat)
```

**Aliasse** sind praktikabel und notwendig, wenn Felder mit gleichen Namen aus verschiedenen Tabellen involviert sind.

### 4.6 JOINs

#### Motivation

Ohne JOIN stehen Join- und Filter-Prädikate zusammen in WHERE. Der JOIN-Operator **trennt** diese:
- **JOIN ... ON**: Join-Prädikat
- **WHERE**: Filter-Prädikat

→ Erleichtert dem Optimizer die Arbeit.

#### Innere JOINs

Tupel **ohne Partner gehen verloren**.

**Natürlicher Verbund (NATURAL JOIN):**
- Voraussetzung: Gleich benannte Attribute mit gleichem Datentyp
- Verknüpft automatisch über gleichnamige Spalten
- Join-Attribute erscheinen nur einmal im Ergebnis

```sql
SELECT MatrNr, Name, Titel
FROM Studenten NATURAL JOIN hoeren NATURAL JOIN Vorlesungen;
```

**Allgemeiner Verbund (Theta-JOIN / INNER JOIN):**
- Beliebige Attribute und Bedingungen
- Keine Attribute werden eliminiert

```sql
SELECT p.Name Professor, a.Name Assistent
FROM Professoren p JOIN Assistenten a ON p.PersNr = a.Boss;
```

#### Äußere JOINs

Tupel **ohne Partner werden mit NULL ergänzt** und bleiben im Ergebnis.

| Typ | Beschreibung | SQL |
|---|---|---|
| **LEFT OUTER JOIN** | Alle Tupel der **linken** Relation bleiben, rechts ggf. NULL | `L LEFT OUTER JOIN R ON ...` |
| **RIGHT OUTER JOIN** | Alle Tupel der **rechten** Relation bleiben, links ggf. NULL | `L RIGHT OUTER JOIN R ON ...` |
| **FULL OUTER JOIN** | Alle Tupel **beider** Relationen bleiben, ggf. NULL | `L FULL OUTER JOIN R ON ...` |

**Beispiel LEFT OUTER JOIN:**

| L.A | L.B | L.C | R.D | R.E |
|---|---|---|---|---|
| a1 | b1 | c1 | d1 | e1 |
| a2 | b2 | c2 | **NULL** | **NULL** |

#### Semi-JOINs

Liefern Tupel **nur aus einer** der beiden Relationen.

| Operator | Symbol | Beschreibung | Formel |
|---|---|---|---|
| Semi-JOIN L mit R | L ⋉ R | Tupel aus L, die Partner in R haben | π_L(L ⋈ R) |
| Semi-JOIN R mit L | L ⋊ R | Tupel aus R, die Partner in L haben | π_R(L ⋈ R) |
| Anti-Semi-JOIN L | L ⊲ R | Tupel aus L **ohne** Partner in R | L — (L ⋉ R) |
| Anti-Semi-JOIN R | L ⊳ R | Tupel aus R **ohne** Partner in L | R — (L ⋊ R) |

```sql
-- Semi-JOIN
SELECT L.* FROM L INNER JOIN R ON L.x = R.x;
SELECT L.* FROM L INNER JOIN R USING (x);
```

#### SQL-Schlüsselwörter

| SQL-Schlüsselwort | Entsprechung |
|---|---|
| CROSS JOIN | Kartesisches Produkt |
| NATURAL JOIN | Natürlicher Verbund |
| INNER JOIN | Allgemeiner Verbund (Theta-JOIN) |
| LEFT OUTER JOIN | Linker äußerer Verbund |
| RIGHT OUTER JOIN | Rechter äußerer Verbund |
| FULL OUTER JOIN | Vollständiger äußerer Verbund |

### 4.7 Anfragebearbeitung

#### Ablauf einer SQL-Anweisung

1. **Parser** → Syntax prüfen
2. **Optimizer** → Optimalen Zugriffsplan erstellen
3. **Row Source Generator** → Ausführungsplan auf physische Ressourcen
4. **Execution Engine** → Ergebnisse erzeugen

#### Optimizer-Algorithmen

| Typ | Beschreibung |
|---|---|
| **RBO (Rule-Based)** | Intern festgelegte Regeln; veraltet |
| **CBO (Cost-Based)** | Interne Statistiken über Tabellen/Indizes; empfohlen |

**Wichtig:** Statistiken müssen regelmäßig aktualisiert werden (Befehl `ANALYZE`). Optimizer-Hints möglich: `/*+CHOOSE */`, `/*+ORDERED */`

#### Suchverfahren

| Methode | Voraussetzung | Geschwindigkeit |
|---|---|---|
| **Full Table Scan** | Keine geeigneten Indizes | Langsamste |
| **Index-Scan** | Geeigneter Index vorhanden | Schnellste (Rückgabe: RowID) |
| **Hash-Scan** | Keine Indizes; Hash-Werte werden generiert | Mittel |

#### Join-Verfahren

| Verfahren | Beschreibung |
|---|---|
| **Verschachtelte Schleifen** (Nested Loops) | Äußere Schleife + innere Schleife für jede Zeile |
| **Sort-Merge-Join** | Beide Tabellen sortieren, dann zusammenführen |
| **Hash-Join** | Hash-Tabelle für eine Tabelle, Suche mit Werten der anderen |
| **Kartesisches Produkt** | Bei fehlenden Verbindungsbedingungen |
| **Index-Join** | Indizes statt Tabellen verknüpfen (nur bei einspaltigen Indizes) |

### 4.8 Indizes

#### Überblick

| Index-Typ | Geeignet für | Beispiel |
|---|---|---|
| **Konventionell (Binärbaum)** | Spalten mit vielen unterschiedlichen Werten | PersID, Matrikelnummer |
| **Bitmap** | Spalten mit vielen gleichen Werten (geringe Kardinalität) | Geschlecht, Kategorie |

**Allgemeiner Aufbau:** `{ [ Suchfeld, RowID ] }`

#### Lineare Listen

**Einfach verkettete Liste:** Jedes Element hat Daten + Zeiger auf nächstes Element.
**Doppelt verkettete Liste:** Zusätzlicher Rückwärts-Zeiger.

**Operationen:**
- Anhängen am Ende (keine Sortierung): O(1)
- Sortiertes Einfügen: O(n)
- Löschen: Zeiger des Vorgängers auf Nachfolger setzen, Speicher freigeben

#### Binärbäume

**Terminologie:**

| Begriff | Bedeutung |
|---|---|
| **Wurzel (Root)** | Einziger Knoten ohne Vorgänger |
| **Blatt** | Knoten ohne Nachfolger |
| **Innerer Knoten** | Weder Wurzel noch Blatt |
| **Kante** | Gerichtete Verbindung (Vorgänger → Nachfolger) |
| **Ebene** | Knoten mit gleicher Pfadlänge zur Wurzel |
| **Tiefe** | Gesamtzahl der Ebenen |
| **Grad** | Maximale Anzahl direkter Nachfolger |

**Suchaufwand:** Logarithmisch O(log n) — aber kann zu O(n) degradieren wenn Baum entartet.

**AVL-Baum:** Höhe beider Teilbäume an jedem Knoten unterscheidet sich höchstens um 1.

**Balancierter Baum:** Höchstens letzte Ebene nicht vollständig besetzt. Jeder balancierte Baum ist ein AVL-Baum, aber nicht umgekehrt.

**Durchlauf-Reihenfolgen:**

| Reihenfolge | Kürzel | Verwendung |
|---|---|---|
| **Preorder** | WLR | Baum linear auf Datenträger speichern |
| **Inorder** | LWR | Sortierte Liste erstellen → balancierten Baum erzeugen |
| **Postorder** | LRW | Geräte programmieren (erst Parameter, dann Operation) |

**Balancierung:**
- **Offline:** Kopie → Inorder-Liste → Binär einfügen → Ausgeglichener Baum. Einfach, aber Zugriffe gesperrt.
- **Online:** Zur Laufzeit rekursiv ausgleichen. Kann kurzfristig zu Fehlern führen.

#### Hashing

**Funktionsprinzip:**
1. Für jeden Datensatz wird ein Schlüssel gebildet
2. Hash-Funktion ordnet dem Schlüssel einen kurzen Hash-Wert zu
3. Hash-Wert dient als Index in der Hash-Tabelle
4. Hash-Tabelle enthält Verweise auf Datensätze

**Kollision:** Zwei unterschiedliche Schlüssel erzeugen denselben Hash-Wert.

**Kollisionsbehandlung:**
- **Hashing mit Verkettung:** Verkettete Listen an Hash-Tabellen-Einträgen
- **Lineares Hashing:** Dynamische Tabellenerweiterung bei hohem Belegungsfaktor
- **Sondierung:** Linear/quadratisch/zufällig in der Tabelle selbst suchen

**Anforderungen an Hash-Funktionen:**
- Effizient berechenbar, geringer Speicherbedarf
- Wenig Kollisionen (Gleichverteilung der Hash-Werte)
- Einwegfunktion (Hash → Schlüssel nicht berechenbar)
- Surjektivität (kein Hash-Wert unmöglich)
- **Lawineneffekt:** 1 Bit Unterschied → mindestens halbe Bits der Hash-Werte unterschiedlich

**Hash-Funktions-Beispiele:**
1. **Modulo:** HW = Key % Basis (Primzahlen empfohlen)
2. **Abschneiden:** Key² berechnen, dann von links/rechts kürzen
3. **Zerlegung & Addition:** Key in gleich große Teile zerlegen und addieren

**Binärbäume vs. Hashing:**
- Bäume: Garantie im Worst Case, Sortierung möglich, dynamische Größe
- Hashing: Schneller im Durchschnitt O(1) vs. O(log n)

#### Bitmap-Indizes

**Geeignet für:**
- Geringe Kardinalität (0,1%–1% unterschiedliche Werte)
- Wenige Änderungen (Data Warehouse / OLAP)

**Aufbau:** Für jeden einzigartigen Wert eine Bit-Spalte. Pro Zeile steht 1 (Treffer) oder 0 (kein Treffer).

**Vorteile:**
- Stark komprimiert → schnell lesbar
- Mehrere Indizes kombinierbar
- Logische Operationen (AND, OR) sehr schnell im Prozessor

**Nachteile:**
- Immenser Wartungsaufwand bei Änderungen
- Bandbreite der Prozessor-Kanäle wichtig
- Können Deadlocks verursachen

---

## 5. Normalformen (e_NFs)

### 5.1 Einführung

**Normalisierung** = Aufteilung von Attributen in mehrere Relationen (Tabellen) mithilfe der Normalisierungsregeln, sodass eine Struktur entsteht, die **keine vermeidbaren Redundanzen** mehr enthält.

**Ziele:**

| Ziel | Beschreibung |
|---|---|
| **Redundanzbeseitigung** | Nur notwendige Redundanz bleibt erhalten |
| **Anomalienvermeidung** | Funktionelle und transitive Abhängigkeiten werden aufgelöst |
| **Klare Struktur** | Erstellung eines klar strukturierten Datenbankmodells |

**Praktische Bedeutung:**
- Praktisch wichtig sind nur die **ersten drei Normalformen** (1NF, 2NF, 3NF)
- Manchmal ist es sinnvoll, auf Normalformen aus **Performancegründen** zu verzichten
- Jede nächste Normalform **basiert auf der vorigen**

### 5.2 Funktionale Abhängigkeit

**Definition:** Y ist von X **funktional abhängig** (X → Y), wenn für alle Tupel t1 und t2 gilt:
```
Wenn t1 ∩ X = t2 ∩ X, dann gilt auch t1 ∩ Y = t2 ∩ Y
```

- Y hängt von X ab, wenn X die Werte von Y **eindeutig bestimmt**
- X bestimmt alle anderen Attribute → X ist ein **Superschlüssel**
- Ist X auch **minimal**, dann ist X ein **Kandidat für Primärschlüssel**

**Arten der Abhängigkeit:**

| Art | Notation | Beschreibung |
|---|---|---|
| **Funktionale Abhängigkeit** | X → Y | X bestimmt Y eindeutig |
| **Mehrwertige Abhängigkeit** (multivalued) | X →→ Y | X bestimmt eine Menge von Y-Werten |

### 5.3 Erste Normalform – 1NF

Eine Tabelle liegt in **1NF** vor, wenn ihre Zellen nur **atomare Werte** beinhalten, d. h. sie enthalten nicht mehr als einen Wert (keine Auflistungen).

**"Atomar"** bedeutet: Die Werte können nicht weiter in kleinere Komponenten zerlegt werden, die **einzeln einen Sinn** im Anwendungsbereich ergeben.

**Regeln:**
- Wiederholungsgruppen werden vermieden, indem jede Gruppe in eine **separate Tabelle** eingefügt und durch eine **1:N-Beziehung** verbunden wird
- Ob ein Attribut atomar ist, hängt **stark von der Mini-Welt** ab
- Laut E. F. Codd müssen Tabellen in 1NF **nicht unbedingt einen Primärschlüssel** haben

**Mini-Welt-Beispiele: Adresse:**

| Mini-Welt | Kontext | Atomar? |
|---|---|---|
| **Logistik-Firma (Müll-Abfuhr)** | PLZ, Straße, Hausnummer werden einzeln für Routenberechnung benötigt | PLZ, Straße, Hausnummer sind **jeweils atomar** |
| **Buchhaltung (Gehaltsabrechnung)** | Nur die gesamte Adresse wird für Briefversand benötigt | Gesamte Adresse ist **als Ganzes atomar** |

**Beispiel Bahnwagen:**

Ausgangstabelle (nicht in 1NF): Feld "Beschreibung" enthält `'Wagentyp, Leergewicht, Kapazität, Hersteller, Baujahr'` → **nicht atomar**

In 1NF gebracht:
```
W1 = { [ WagenID, Status, Ankunft, Station, WagenType,
         Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
```

**Beispiel Vertragsdaten:**

Ausgangstabelle (nicht in 1NF):

| Vertragsdatum | Kunde | Produkt |
|---|---|---|
| 01.02.2010 | Kohl | VW 30.000, BMW 40.000, Opel 40.000 |
| 03.01.2012 | Schröder | VW 32.000, Mercedes 35.000 |

In 1NF gebracht:

| Vertragsdatum | Kunde | Produkt | Preis |
|---|---|---|---|
| 01.02.2010 | Kohl | VW | 30.000 |
| 01.02.2010 | Kohl | BMW | 40.000 |
| 01.02.2010 | Kohl | Opel | 40.000 |
| 03.01.2012 | Schröder | VW | 32.000 |
| 03.01.2012 | Schröder | Mercedes | 35.000 |

### 5.4 Zweite Normalform – 2NF

Eine Tabelle liegt in **2NF** vor, wenn sie:
1. In **1NF** vorliegt
2. Jedes Feld, das **nicht** zum Primärschlüssel gehört, vom **ganzen** Primärschlüssel abhängt

**Regel:** Besteht der Primärschlüssel nur aus **einem Feld**, liegt die Tabelle **automatisch in 2NF** vor.

**Vorgang:** Felder, die nur vom **Teil des Primärschlüssels** abhängig sind, werden zusammen mit dem Teilschlüssel in **neue Tabellen ausgelagert**.

**Beispiel Bahnwagen:**
Die Felder [WagenType], [Leergewicht], [Kapazitaet], [Hersteller], [Baujahr] hängen nur von [WagenID] ab, aber **nicht** von [Ankunft] → nicht in 2NF.

Aufteilung in 2NF:
```
W11 = { [ WagenID, Ankunft, Status, Station ] }         ← PK = [WagenID, Ankunft]
W12 = { [ WagenID, WagenType, Leergewicht, Kapazitaet,
          Hersteller, Baujahr ] }                         ← PK = [WagenID]
```

**Beispiel Vertragsdaten:**
PK = [Vertragsdatum, Kunde, Produkt]
- [Herkunftsland] hängt nur von [Produkt] ab → verletzt 2NF
- [Lieferadresse] hängt nur von [Kunde] ab → verletzt 2NF
- [V-Art] hängt nur von [Produkt] ab → verletzt 2NF

**Beispiel Bestellungen:**
Bei ArtNr : LagerOrt = 1:1 gibt es **zwei Schlüsselkandidaten**: [RNr, ArtNr] und [RNr, LagerOrt]. Die 2NF ist in beiden Fällen verletzt.

**ERM-Bezug:** Wenn man vom **ERM ausgeht** und den konzeptuellen Entwurf korrekt in den logischen umwandelt, kommt man direkt zu Tabellen, die die 2NF nicht verletzen.

### 5.5 Dritte Normalform – 3NF

Eine Tabelle liegt in **3NF** vor, wenn sie:
1. In **2NF** vorliegt
2. Alle Felder, die **nicht** zum Primärschlüssel gehören, **voneinander unabhängig** sind

**Regel:** Wenn nur **ein Nichtschlüsselfeld** in der Tabelle vorhanden ist, liegt die Tabelle **automatisch in 3NF** vor.

**Wichtig:** In der Praxis ist die 3NF oft ausreichend für eine perfekte Balance aus **Redundanz, Performance und Flexibilität**.

**Vorgang:** Funktionale Abhängigkeiten unter Nicht-PK-Feldern werden durch **Aufteilung der Tabelle** aufgelöst.

**Beispiel Bahnwagen:**
Aus 2NF: `W12 = { [ WagenID, WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }`
[Leergewicht], [Kapazitaet], [Hersteller] und ggf. [Baujahr] sind vom Feld [WagenType] abhängig → nicht in 3NF.

Variante a (Baujahr vom WagenType abhängig):
```
W121a = { [ WagenID, WagenType ] }
W122a = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
```

Variante b (Baujahr vom WagenType unabhängig):
```
W121b = { [ WagenID, WagenType, Baujahr ] }
W122b = { [ WagenType, Leergewicht, Kapazitaet, Hersteller ] }
```

### 5.6 Boyce-Codd-Normalform – BCNF

Eine Tabelle liegt in **BCNF** vor, wenn sie:
1. In **3NF** vorliegt
2. **Kein Teil** eines Schlüsselkandidaten funktional von keinem Teil eines **anderen** Schlüsselkandidaten abhängig ist

**Kern:** BCNF behandelt die **Abhängigkeiten zwischen Teilen mehrerer Schlüsselkandidaten**, falls diese sich teilweise **überlappen**.

**Regel:** Gibt es nur **einen Schlüsselkandidaten** oder liegt **keine Überlappung** vor, befindet sich die Tabelle **automatisch in BCNF**.

**Beispiel Sportvereine:**

| Name | Sportart | Verein |
|---|---|---|
| Schulz | Fußball | FC Berlin |
| Mayer | Fußball | FC Berlin |
| Zimmermann | Fußball | FC Marzahn |
| Mayer | Volleyball | VC Hamburg |

Beziehung: Sportart : Verein = 1 : N. Schlüsselkandidaten: [Name, Sportart] und [Name, Verein] → **Überlappung** (Name). [Sportart] hängt vom Nicht-Schlüssel-Feld [Verein] ab → verletzt BCNF.

Lösung:
```
Tabelle 1 = { [ Name, Verein ] }
Tabelle 2 = { [ Sportart, Verein ] }
```

### 5.7 Vierte Normalform – 4NF

Eine Tabelle liegt in **4NF** vor, wenn sie:
1. In **BCNF** vorliegt
2. Nur **semantisch verbundene** Nichtschlüsselattribute sich in der Tabelle befinden

Die 4NF trennt **semantisch (thematisch, inhaltlich) unabhängige** Entitäten durch Aufteilung.

**Beispiel Bahnwagen:**
[Leergewicht] und [Kapazitaet] werden **viel öfter** verwendet als [Hersteller] und [Baujahr] (historische Bedeutung) → **unterschiedliche Semantik**.

```
W122a1 = { [ WagenType, Leergewicht, Kapazitaet ] }    ← technische Daten
W122a2 = { [ WagenType, Hersteller, Baujahr ] }         ← historische Daten
```

### 5.8 Fünfte Normalform – 5NF

Eine Tabelle liegt in **5NF** vor, wenn sie:
1. In **4NF** vorliegt
2. Nicht mehr in Tabellen eines **geringeren Grades** zerlegt werden kann

**Kern:** Die neuen Tabellen können jederzeit den ursprünglichen Zustand **ohne Informationsverlust** wieder herstellen (durch JOIN).

**Nachteil:** Man braucht in der Praxis ständig die ganzen Informationen und muss daher ständig die vereinfachten Tabellen wieder **vereinigen** (JOIN).

**Beispiel Touristik-Firma:**
```
T10 = { [ PersID, TourNr, Trans-Unternehmen ] }    ← PK = alle drei Attribute
```
Zerlegbar in:
```
T11 = { [ PersID, TourNr ] }
T12 = { [ PersID, Trans-Unternehmen ] }
T13 = { [ TourNr, Trans-Unternehmen ] }
```

**Beispiel Hersteller-Produkt-Person:**
```
TA = { [ HerstID, ProduktID ] }
TB = { [ PersID, ProduktID ] }
TC = { [ HerstID, PersID ] }
```

### 5.9 Anomalien ohne Normalisierung

**Beispiel:** Tabelle mit Mitarbeitern, Abteilungen und Projekten (nicht normalisiert):

| PersID | Name | AbtNr | Abteilung | ProjNr | ProjBeschreibung |
|---|---|---|---|---|---|
| 1 | Anna | 42 | Second Level | BE | Bergland ... |
| 1 | Anna | 42 | Second Level | NO | Nordsee ... |
| 2 | Arnold | 42 | Second Level | NO | Nordsee ... |
| 2 | Arnold | 42 | Second Level | OG | Ostgipfel ... |
| 3 | Betty | 53 | First Dept | OG | Ostgipfel ... |
| 3 | Betty | 53 | First Dept | WO | West-Ozean ... |
| 4 | Chris | 53 | First Dept | WO | West-Ozean ... |

| Anomalie | Problem |
|---|---|
| **Einfüge-Anomalie** | Neuer Mitarbeiter mit mehreren Projekten → mehrere Zeilen, Vertippen möglich |
| **Änderungs-Anomalie** | Projektumbenennung → mehrere Zeilen ändern, Übersehen möglich |
| **Lösch-Anomalie** | Mitarbeiter löschen → mehrere Zeilen entfernen, Übersehen möglich |

**Normalisierung → 3NF:**
```
Mitarbeiter   = { [ PersID, Name, AbtNr ] }
Abteilung     = { [ AbtNr, Abteilung ] }
arbeitet_an   = { [ PersID, ProjNr ] }
Projekt       = { [ ProjNr, ProjBeschreibung ] }
```

### 5.10 ERM als Alternative zur Normalisierung

**Wichtige Erkenntnis:** Wenn man vom **ERM ausgeht** und den konzeptuellen Entwurf korrekt in den logischen umwandelt (inkl. Vereinfachung), bekommt man **ziemlich wahrscheinlich** Tabellen in 3NF. ERM und Normalisierung sind **komplementäre Ansätze** zum gleichen Ziel.

### Übersicht Normalformen

| NF | Voraussetzung | Regel | Automatisch erfüllt wenn... |
|---|---|---|---|
| **1NF** | — | Nur atomare Werte in Zellen | Keine Auflistungen vorhanden |
| **2NF** | 1NF | Jedes Nicht-PK-Feld hängt vom **ganzen** PK ab | PK besteht aus nur einem Feld |
| **3NF** | 2NF | Nicht-PK-Felder sind **voneinander unabhängig** | Nur ein Nicht-PK-Feld vorhanden |
| **BCNF** | 3NF | Keine Abhängigkeiten zwischen Teilen verschiedener Schlüsselkandidaten | Nur ein Schlüsselkandidat oder keine Überlappung |
| **4NF** | BCNF | Nur semantisch verbundene Nicht-PK-Attribute zusammen | Alle Attribute thematisch zusammengehörig |
| **5NF** | 4NF | Nicht weiter in Tabellen geringeren Grades zerlegbar | Zerlegung würde Informationsverlust verursachen |

### Durchgängiges Beispiel: Bahnwagen

```
Ausgangstabelle:  { [ WagenID, Beschreibung, Status, Ankunft, Station ] }
→ 1NF:  W1   = { [ WagenID, Status, Ankunft, Station, WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
→ 2NF:  W11  = { [ WagenID, Ankunft, Status, Station ] }
        W12  = { [ WagenID, WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
→ 3NF:  W11  = { [ WagenID, Ankunft, Status, Station ] }
        W121 = { [ WagenID, WagenType ] }
        W122 = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
→ 4NF:  W122a1 = { [ WagenType, Leergewicht, Kapazitaet ] }
        W122a2 = { [ WagenType, Hersteller, Baujahr ] }
```

---

## 6. Transaktionen (f_Transaktionen)

### 6.1 Definition

**Integrität (Konsistenz)** der Datenbank = Zustand der Daten, in dem sie **korrekt, vollständig und widerspruchsfrei** sind.

**Transaktion** = Mehrere Operationen, die:
- Entweder **alle erfolgreich** durchgeführt werden
- Oder, falls ein Fehler vorliegt, die schon durchgeführten **rückgängig gemacht** werden müssen

**Eigenschaften:**
- Transaktionen gewährleisten einen **konsistenten Zustand** der Datenbank
- Sie versetzen den Datenbestand von einem konsistenten Zustand in einen **anderen konsistenten Zustand**
- Eine Transaktion wird als **atomare (ununterbrechbare) Operation** betrachtet
- Bei Fehlern werden Komponenten nicht rückgängig gemacht (zeitintensiv), sondern der **zuvor gespeicherte Zustand** wird wiederhergestellt

### 6.2 Beispiel

Zwei ganze Zahlen A und B:
```
T1 = { A=A+100; B=B+100; }
T2 = { A=A*2;   B=B*2;   }
```

- **Sequenzielle Ausführung** → Konsistenz gewährleistet
- **Gemischte Operationen** → Konsistenz **nicht** mehr gewährleistet

### 6.3 Anforderungen

| Anforderung | Beschreibung |
|---|---|
| Gleichzeitige Verarbeitung | Mehrere Transaktionen müssen **quasi-parallel** verarbeitet werden |
| Fehlerbehandlung | Abgeschlossene Transaktionen bleiben bestehen, offene werden rückgängig gemacht |
| Organisation | Manuell (im Source-Code) oder automatisch |
| Zwischenpunkte | Daten erfolgreich durchgeführter Operationen können gespeichert werden |
| Abschlussarten | Nur **COMMIT** (erfolgreich) oder **ROLLBACK** (erfolglos) |

**Gründe für ROLLBACK:** Systemfehler, Integritätsverletzungen, Deadlock, Benutzeranweisung.

### 6.4 ACID-Eigenschaften

| Eigenschaft | Beschreibung |
|---|---|
| **A**tomicity (Atomarität) | Entweder **alle** Befehle oder **gar keine** werden ausgeführt |
| **C**onsistency (Konsistenz) | Transaktion hinterlässt nach Beendigung einen **konsistenten Datenzustand**, ansonsten komplettes Zurücksetzen |
| **I**solation | Nebenläufige Transaktionen beeinflussen sich **nicht gegenseitig**; jede wird logisch so ausgeführt, als wäre sie die einzig aktive |
| **D**urability (Dauerhaftigkeit) | Wirkung einer erfolgreich abgeschlossenen Transaktion bleibt **dauerhaft** erhalten, auch nach Systemfehler |

### 6.5 Zustände einer Transaktion

```
BoT → Active → Committing → Änderungen festgeschrieben → EoT
         ↓          ↓
    Waiting for   ERROR
    resources       ↓
         ↓      Rolling back → Änderungen rückgängig gemacht → EoT
      DEADLOCK
         ↓
    ROLLBACK → Rolling back
```

| Zustand | Beschreibung |
|---|---|
| **BoT** | Begin of Transaction |
| **Active** | Transaktion führt Operationen aus |
| **Waiting for resources** | Wartet auf gesperrte Ressourcen |
| **DEADLOCK** | Gegenseitige Blockierung erkannt |
| **Committing** | Änderungen werden festgeschrieben (COMMIT) |
| **Rolling back** | Änderungen werden rückgängig gemacht (ROLLBACK) |
| **EoT** | End of Transaction |

### 6.6 Synchronisation

**Synchronisation (Mehrbenutzersynchronisation)** = Koordinierung von mehreren Benutzerprozessen, eng verbunden mit der Ausführung der Transaktionen.

| Art | Beschreibung | Eigenschaft |
|---|---|---|
| **Seriell** | Transaktionen nacheinander | Absolut sicher, aber **langsam**; blockiert nachfolgende Transaktionen |
| **Parallel** | Transaktionen gleichzeitig | Nutzt Ressourcen **besser** aus |
| **Serialisierung** | Anordnung paralleler Operationen | Entspricht in der Wirkung der seriellen Ausführung, garantiert Konsistenz |

### 6.7 Probleme bei paralleler Ausführung

Bei Zugriff auf **denselben Datenbestand** können folgende Probleme entstehen:

#### Lost Update

Die von einer Transaktion geänderten Daten werden von einer anderen Transaktion überschrieben.

**Variante 1 – Direkt:**
```
T1: update TabX set V=42;       T2: ...
T1: ...                          T2: update TabX set V=53;
T1: ...                          T2: commit;
T1: commit;                      T2: ...
```
→ Update von T2 geht verloren. Kommt in Datenbanken **nicht vor**, da T2 auf Freigabe wartet.

**Variante 2 – Über lokale Variable:**
```
T1: select V from TabX into W;  T2: ...
T1: W := W+1;                   T2: update TabX set V=53;
T1: update TabX set V=W;        T2: commit;
T1: commit;                     T2: ...
```
→ Update von T2 geht verloren. Kann durch **höhere Isolationsstufe** vermieden werden.

**Lösung:** `SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;`
- Die Transaktion merkt sich die Daten, die zum **Start der Transaktion** festgeschrieben waren
- Ändert eine andere Transaktion diese Daten, bricht die erste ab
- Fehler: `ORA-08177: can't serialize access for this transaction`

#### Dirty Read

Eine Transaktion liest Daten, die eine andere Transaktion geändert, aber **noch nicht festgeschrieben** hat.

```
T1: ...                          T2: update TabX set V=42;
T1: select V from TabX;          T2: ...        ← T1 liest V=42
T1: ...                          T2: rollback;  ← V=42 war ungültig!
```

**Lösung:** Standard-Isolationsstufe in Oracle ist **READ COMMITTED** → verhindert Dirty Read automatisch. Dirty Read ist nur möglich mit `READ UNCOMMITTED` (in Oracle nicht verfügbar).

#### Non-Repeatable Read

Eine Transaktion liest **zweimal dieselben Daten** und bekommt **unterschiedliche Ergebnisse**.

```
T1: select V from TabX;         T2: ...
T1: ...                          T2: update TabX set V=42;
T1: ...                          T2: commit;
T1: select V from TabX;          T2: ...        ← anderer Wert!
```

**Lösung:** Isolationsstufe **SERIALIZABLE** (Standard READ COMMITTED lässt dies zu).

#### Phantom Read

Ähnlich Non-Repeatable Read, aber mit **Anzahl der Zeilen** statt Werten.

```
T1: select count(*) from TabX;  T2: ...
T1: ...                          T2: insert into TabX ...;
T1: ...                          T2: commit;
T1: select count(*) from TabX;   T2: ...        ← anderer Count!
```

**Lösung:** Isolationsstufe **SERIALIZABLE**.

### 6.8 Trade-off der Isolationsstufen

| Niedrigere Stufe | Höhere Stufe |
|---|---|
| Erlaubt gleichzeitigen Zugriff | Vermindert Probleme |
| Mehr mögliche Nebenwirkungen | Mehr Systemressourcen |
| Höhere Performance | Höhere Blockierungswahrscheinlichkeit |

### 6.9 Isolationsstufen nach ANSI/ISO SQL92

| Isolationsstufe | Verhindert | Besonderheit |
|---|---|---|
| **READ UNCOMMITTED** | — | Dirty Read erlaubt; **fehlt in Oracle** |
| **READ COMMITTED** | Dirty Read | Standard in Oracle; Lesesperren werden kurz gesetzt und aufgehoben |
| **REPEATABLE READ** | Dirty Read, Non-Repeatable Read | Sperren für gesamte Transaktion; **fehlt in Oracle** |
| **SERIALIZABLE** | Dirty Read, Non-Repeatable Read, Phantom Read, Lost Update | Höchste Stufe; keine weiteren schreibenden Transaktionen auf dieselben Daten |

**Hinweis:**
- Die Isolationsstufe betrifft den **Schreibvorgang nicht** – eine Transaktion bekommt immer eine **exklusive Sperre** für alle zu ändernden Daten
- Die Isolationsstufe wirkt auf die **Lesevorgänge** – definiert, wie Lesevorgänge von anderen Transaktionen abhängig sind
- Der SQL-Standard schreibt diese Stufen vor, aber konkrete Datenbanken unterstützen sie **unterschiedlich**

### 6.10 Synchronisationsstrategien

Der **Scheduler** steuert die Ausführungsreihenfolge von Operationen verschiedener Transaktionen.

| Strategie | Beschreibung |
|---|---|
| **Pessimistisch** | Scheduler **verzögert** Operationen, legt optimale Reihenfolge fest |
| **Optimistisch** | Scheduler schickt Operationen **sofort** zur Ausführung |

### 6.11 Synchronisationsverfahren

#### Sperrbasierte Synchronisation

Wird **oft eingesetzt**.

| Regel | Beschreibung |
|---|---|
| Jedes Datenobjekt hat eine Sperre | Tabelle, Datensatz, Attribut, Index, View |
| Sperren vor Benutzung | Jedes Objekt muss vor Zugriff gesperrt werden |
| Warten bei Sperre | Ist Objekt schon gesperrt, muss die Transaktion warten |
| Exklusivität | Nur **eine** Transaktion kann die Sperre halten |
| **Lesesperre** (shared lock) | Andere Transaktionen dürfen die Daten **lesen** |
| **Schreibsperre** (exclusive lock) | Andere Transaktionen dürfen Daten **weder lesen noch ändern** |
| Sperren aufheben | Am Ende der Transaktion werden **alle Sperren** aufgehoben |

**Löst:** Alle Probleme **außer Phantom Read**.

#### 2-Phasen-Sperrprotokoll – 2PL

| Phase | Beschreibung | Sicherste Variante |
|---|---|---|
| **Wachstumsphase** | Viele Sperren werden **angefordert**, wenige freigegeben | Sperren werden nur **gesetzt**, nicht aufgehoben |
| **Minderungsphase** (Schrumpfphase) | Viele Sperren werden **freigegeben**, wenige angefordert | Sperren werden nur **aufgehoben**, nicht gesetzt |

#### Zeitstempelbasierte Synchronisation

Wird **selten eingesetzt**.

| Regel | Beschreibung |
|---|---|
| Eindeutiger Zeitstempel | Jede Transaktion bekommt einen eindeutigen Zeitstempel |
| Ordnung | Scheduler ordnet konkurrierende Operationen nach Zeitstempel |
| Objektstempel | Zu jedem Datenobjekt wird der Zeitstempel der letzten Operation gespeichert |
| Abweisung | Operation mit **früherem** Zeitstempel als der des Objektes wird **abgewiesen** |
| Reihenfolge | Transaktionen müssen laut Zeitstempelreihenfolge beendet werden |

**Löst:** Alle Probleme **außer Phantom Read**.

---

## 7. Speicherstrukturen (g_Speicherstrukturen)

### 7.1 Überblick

Oracle verwaltet eigene Speicherstrukturen auf dem **Datenträger** und im **Arbeitsspeicher** zwecks effizienter und konsistenter Datenbearbeitung.

| Ort | Strukturen |
|---|---|
| **Datenträger** | Tablespaces, Datenbankdateien, Segmente, Redo-Log-Dateien |
| **Arbeitsspeicher** | System Global Area (SGA), Program Global Area (PGA), User Global Area (UGA) |

### 7.2 Datenträger

#### Tablespace

Ein Tablespace enthält theoretisch mehrere **Tabellen** und **Indizes**, verteilt auf mehrere **Datenbankdateien**.

```
Tablespace
├── Tabelle A, Tabelle B, Tabelle C
├── Index D, Index E
├── Datenbankdatei 1
└── Datenbankdatei 2
```

#### Hierarchie der Strukturen

Ein separates Tablespace ist für **jede Anwendung** gedacht (alle User, Tabellen, Indizes, Prozeduren).

| Ebene | Beschreibung |
|---|---|
| **Datenbank** | Besteht aus mehreren **Tablespaces** |
| **Tablespace** | Besteht aus mehreren **Datenbankdateien** |
| **Datenbankdatei** | Besteht aus mehreren **Segmenten** (Extenten), zugeordnet zu Tabellen oder Indizes |
| **Segment** | Besteht aus mehreren **Blöcken** |
| **Block** | Kleinste Einheit, die gelesen/geschrieben werden kann |

Ist eine Tabelle voll, kann sie durch ein **Segment (Extent)** erweitert werden.

#### Logische vs. Physische Objekte

| Typ | Beispiele |
|---|---|
| **Logische Objekte** | Tabellen, Indizes, User, Prozeduren |
| **Physische Objekte** | Tablespace, Datenbankdatei, Segment (Extent), Block |

#### CREATE TABLE mit Storage-Klausel

```sql
CREATE TABLE T (
    A INTEGER, B VARCHAR2(20)
)
TABLESPACE myTabSpc STORAGE (
    INITIAL      1M        -- Anfangssegment
    NEXT         500K      -- Extente (weitere Segmente)
    MINEXTENTS   1         -- minimale Anzahl der Segmente
    MAXEXTENTS   100       -- maximale Anzahl der Segmente
    PCTINCREASE  10        -- Größe der Segmente wächst um 10%
);
```

#### Tablespace-Verwaltung

```sql
-- Tablespace anzeigen
SELECT * FROM user_tablespaces;
SELECT * FROM dba_tablespaces;

-- Tablespace erstellen
CREATE TABLESPACE orion
DATAFILE 'c:\oracle\oradata\ora\orion.dbf'
SIZE 10M
AUTOEXTEND ON NEXT 200K MAXSIZE 200M;

-- Datenbankdatei hinzufügen
ALTER TABLESPACE orion
ADD DATAFILE 'c:\oracle\oradata\ora\orion2.dbf'
SIZE 10M AUTOEXTEND ON NEXT 100K MAXSIZE 800M;

-- Tablespace offline/online schalten
ALTER TABLESPACE orion OFFLINE IMMEDIATE;
ALTER TABLESPACE orion ONLINE;

-- Einzelne Datenbankdateien offline/online
ALTER DATABASE DATAFILE '...\orion3.dbf' OFFLINE DROP;
ALTER DATABASE DATAFILE '...\orion4.dbf' ONLINE;
```

#### Rollback-Segmente und Redo-Log-Dateien

| Struktur | Funktion |
|---|---|
| **Rollback-Segmente** | Speichern Daten **vor** Änderungen; Anfragen lesen aus Rollback-Segmenten, solange Änderungen noch nicht COMMIT sind; in Oracle automatisch via **Undo-Management** im UNDO-Tablespace verwaltet |
| **Redo-Log-Dateien** | Enthalten **schon durchgeführte** Änderungen; ermöglichen Nachvollziehen der gesamten Datenänderungsgeschichte; werden **zyklisch beschrieben** und automatisch archiviert |

### 7.3 Arbeitsspeicher

#### System Global Area – SGA

| Komponente | Beschreibung |
|---|---|
| **Database-Buffer-Cache** | Enthält Datenblöcke (z. B. Zeilen einer Tabelle), die angezeigt/geändert werden müssen; lädt mehrere Zeilen (auch benachbarte) für hohe Zugriffsgeschwindigkeit; wird von speziellen Algorithmen verwaltet (Verdrängung nicht benötigter Daten) |
| **Dirty List** | Liste mit Blockadressen aus dem Database-Buffer-Cache, deren Daten **geändert** wurden; geänderte Blöcke werden nach COMMIT anhand der Dirty List in die Datenbank geschrieben |
| **Redo-Log-Buffer** | Protokolliert Daten vom Database-Buffer-Cache für den Fall eines **unerwarteten Systemabsturzes** |
| **Shared Pool** | Verarbeitet SQL-Anweisungen: Benutzerrechte prüfen, Existenz von Tabellen/Spalten prüfen, Syntax prüfen, Optimierung; nutzt Metadaten aus dem **Data Dictionary** (Tablespace SYSTEM) |
| **Large Pool** | Speicherplatz für System-Komponenten wie z. B. **Recovery-Manager** |
| **Java Pool** | Virtuelle Umgebung für **Java-Anwendungen** |

#### Program Global Area – PGA

Beinhaltet Informationen, die für die **Steuerung der gesamten Oracle-Prozesse** notwendig sind.

#### User Global Area – UGA

Beinhaltet Informationen, die einem **aktuell verbundenen Benutzer** zugeordnet sind (Sitzung).

---

## 8. Sicherungskonzepte (h_Sicherungskonzepte)

### 8.1 Datensicherheit

**Datensicherheit** = Alle technischen und organisatorischen Maßnahmen zum Schutz der Daten vor **Verfälschung, Zerstörung und unzulässiger Weitergabe**.

- Informationssicherheit ist nicht nur Technik, sondern auch abhängig von **organisatorischen und personellen** Rahmenbedingungen
- Das **BSI** (Bundesamt für Sicherheit in der Informationstechnik) veröffentlicht das IT-Grundschutzhandbuch

### 8.2 Schadenskategorien

| Kategorie | Beschreibung | Beispiel |
|---|---|---|
| **Verlust der Verfügbarkeit** | Grundlegende Informationen nicht vorhanden | Keine Geldtransaktionen, Online-Bestellungen oder Produktionsprozesse möglich |
| **Verlust der Vertraulichkeit** | Ungewollte Offenlegung von Informationen | Personenbezogene Daten, Umsatz, Marketing, Forschungsdaten gelangen an Konkurrenz |
| **Verlust der Integrität** | Gefälschte Daten | Fehlbuchungen, falsche Lieferungen, fehlerhafte Produkte |
| **Verlust der Authentizität** | Daten falscher Person zugeordnet | Zahlungsanweisungen zu Lasten Dritter, falsche digitale Willenserklärungen |

### 8.3 Relevante Gesetze

| Gesetz | Kürzel | Jahr |
|---|---|---|
| Bundesdatenschutzgesetz | BDSG | 1990/2003/2009 |
| Telekommunikationsgesetz | TKG | 2004 |
| Telemediengesetz | TMG | 2007 |
| Signaturgesetz | SigG | 2001 |
| Diverse Landesdatenschutzgesetze | — | — |

### 8.4 Grundprinzipien der Sicherheit

| Prinzip | Beschreibung |
|---|---|
| **Authentifizierung** | Subjekte (Benutzer, Rechner, Dienste) müssen ein Konto besitzen und sich mit gültigem Anmeldenamen + Kennwort anmelden; moderne DB erlauben auch Betriebssystem-Authentifizierung und Zertifikate |
| **Autorisierung** | System muss Zugriffsrechte implementieren: Leserechte (ohne Änderung), Änderungsrechte (inkl. Lesen), volle Rechte (inkl. Weitergabe); Verweigerung/Entziehung möglich |
| **Protokollierung** | Alle wichtigen Vorgänge müssen überwacht werden: Lesen/Ändern/Löschen, Anmeldung, DB-Start/Stop, Kontenverwaltung; Mindestangaben: **wer**, **was**, **wann**; in Oracle: **Auditing** |

**Beispiel Verletzung:** Web-Server ordnet alle Anfragen einem pauschalen Konto zu → Verletzung der Authentifizierung → potenzieller Angreifer kann unsinnige Anfragen senden.

### 8.5 Integrität

**Integrität (Konsistenz)** = Zustand der Daten, in dem sie korrekt, vollständig und widerspruchsfrei sind.

| Art | Beschreibung |
|---|---|
| **Semantische Integrität** | Werte gehören zum Wertebereich, richtige Datentypen, keine Tippfehler |
| **Referentielle Integrität** | Korrektheit der Primär- und Fremdschlüssel, Existenz der Verweise |
| **Logische Integrität** | Transaktionen, zusammengehörende Operationen |

#### Gewährleistung der Integrität

| Ebene | Beschreibung |
|---|---|
| **Datenbank** (bessere Lösung) | Klauseln in DDL-Anweisungen |
| **Anwendung** (zusätzliche Lösung) | Programmcode der Anwendung |

**Vorteile der DB-Ebene:**
- DB selbst gewährleistet Konsistenz → inkonsistente Zustände unmöglich
- Ein-/Ausschaltbar (z. B. beim Import)
- Standardisierte Möglichkeiten
- Unabhängig von einzelnen Anwendungen
- Schnellere Anwendungsentwicklung

#### Integritätsverletzende Operationen

- **DML:** INSERT, UPDATE, DELETE
- **DDL:** ALTER, DROP, RENAME

#### Aktionen bei Integritätsverletzung

| Aktion | Beschreibung |
|---|---|
| **Rollback** | Abbrechen der Operation und Zurücksetzen auf Zustand davor |
| **Cascade** | Propagieren der Operation auf alle beteiligten Tabellen |
| **Set Null** | Betroffene Attribute auf NULL setzen |

#### Referentielle Integrität

Die Werte eines **Fremdschlüssels** müssen auch als Werte des **Primärschlüssels** vorhanden sein.

#### Constraint-Typen

| Constraint | Beschreibung |
|---|---|
| **PRIMARY KEY** | Attribut(e) bilden primären Schlüssel; automatisch wird Index angelegt (Oracle) |
| **FOREIGN KEY** | Attribut(e) bilden PK in einer anderen Tabelle |
| **ON DELETE CASCADE** | Löschen in PK-Tabelle löscht auch FK-Datensätze |
| **NOT NULL** | Attribut muss einen Wert haben |
| **UNIQUE** | Werte sind einmalig |
| **CHECK** | Logischer Ausdruck muss wahr sein |

#### Beispiele

```sql
CREATE TABLE Studenten (
    MatrNr   INTEGER PRIMARY KEY,
    Name     VARCHAR(30) NOT NULL,
    Semester INTEGER CHECK Semester BETWEEN 1 AND 13
);

CREATE TABLE Professoren (
    PersNr INTEGER PRIMARY KEY,
    Name   VARCHAR(30) NOT NULL,
    Rang   CHAR(2) CHECK (Rang IN ('C2', 'C3', 'C4')),
    Raum   INTEGER UNIQUE
);

CREATE TABLE voraussetzen (
    Vorgaenger INTEGER REFERENCES Vorlesungen(VorlNr) ON DELETE CASCADE,
    Nachfolger INTEGER REFERENCES Vorlesungen(VorlNr) ON DELETE NO ACTION,
    PRIMARY KEY (Vorgaenger, Nachfolger)
);

CREATE TABLE pruefen (
    MatrNr INTEGER REFERENCES Studenten ON DELETE CASCADE,
    VorlNr INTEGER REFERENCES Vorlesungen,
    PersNr INTEGER REFERENCES Professoren,
    Note   NUMERIC(2,1) CHECK (Note BETWEEN 0.7 AND 5.0),
    PRIMARY KEY (MatrNr, VorlNr)
);
```

#### Trigger

**Trigger** = Prozedur/Funktion, die bei bestimmten Ereignissen **automatisch** gestartet wird.

**Auslöser:**
- DML: INSERT, DELETE, UPDATE
- DDL: CREATE, ALTER, DROP
- An-/Abmeldung, Start/Stop der DB

**Zeitpunkt:**

| Zeitpunkt | Beschreibung |
|---|---|
| **BEFORE** | Vor der Änderung |
| **AFTER** | Nach der Änderung |
| **INSTEAD OF** | Statt der Änderung |

### 8.6 Rechte

#### User/Schema-Konzept in Oracle

- Zentral: **User (Benutzer)**, auch **Schema** genannt
- Oracle-DB besteht aus verschiedenen Schemen, innerhalb derer ERM realisiert sind
- Vordefinierte Benutzer: **SYS** und **SYSTEM** (alle Rechte)
- Alle anderen Benutzer müssen erstellt und mit Rechten versehen werden

#### Zugriffsrichtlinien

Klare Richtlinien sollten festlegen: wer darf zugreifen, auf welche Ressourcen, welche Zugriffsart, an welchen Tagen/Uhrzeiten, von welchen Computern, wer erlaubt/informiert/protokolliert/abrechnet.

#### Sicherheitsmechanismen

| Mechanismus | Beschreibung |
|---|---|
| **DAC** (Discretionary Access Control) | Regel: {O, S, R, P, F} – Objekte, Subjekte, Zugriffsrechte, Prädikat, Recht zur Rechtevergabe |
| **MAC** (Mandatory Access Control) | Hierarchie der Prozesse mit Markierungen (Einstufung); Kommunikation nur bei gleichem Niveau |

#### Privilegien

| Typ | Beispiele |
|---|---|
| **Systemprivilegien** | Anmeldung, Anlegen/Löschen von Tabellen/Benutzern/Prozeduren, Abfragen von Systemtabellen, Verwaltung von Tablespaces |
| **Objektprivilegien** | Abfragen von Tabellen, Ändern von Inhalten, Verwenden von Funktionen |

**Empfehlung:** Sinnvolle **Rollenmatrix** erstellen; Benutzer bekommen keine Privilegien direkt, sondern über **Rollen**.

#### Benutzerverwaltung

```sql
-- Benutzer erstellen
DROP USER Student07;
CREATE USER Student07 IDENTIFIED BY system
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;

-- Passwort ändern
ALTER USER Student07 IDENTIFIED BY System01;

-- Rolle erstellen und Rechte vergeben
DROP ROLE StudentRole;
CREATE ROLE StudentRole;
GRANT CREATE session, CREATE table, CREATE view,
      CREATE synonym, CREATE procedure, CREATE trigger
TO StudentRole;
GRANT StudentRole TO Student07;

-- Objektprivilegien (direkt, nicht empfohlen)
GRANT SELECT ON Tabelle13 TO Student07, Student08;
GRANT INSERT, SELECT ON Student03.TabelleA TO Student07;
GRANT ALL ON database TO dba_user02;

-- Spalten-basierte Rechte
GRANT UPDATE (Spalte1), INSERT (Spalte2, Spalte3)
ON Tabelle52 TO Student07;
```

**Befehle:** Nur **GRANT** (Rechte vergeben) und **REVOKE** (Rechte entziehen).

### 8.7 Backup

#### Definition

**Backup (Datensicherung)** = Speicherung der Daten, mit der ein System nicht direkt arbeitet.

**Eigenschaften:**
- Kann mehrere Dateien und Verzeichnisse beinhalten
- Kann wie eine oder mehrere Dateien aussehen
- Kann verschlüsselt und/oder komprimiert sein
- Kann sich über mehrere Datenträger verbreiten

**Backup-Archiv** = Sammlung von mehreren Backups.

**Zwecke:**
1. Wiederherstellung nach Absturz
2. Wiederherstellung eines bestimmten Zeitpunkts für Statistik (z. B. Jahresbericht)
3. Wiederherstellung für planmäßige Funktionalität (z. B. Forschungsprojekte)

**Regel:** In allen nicht privaten Systemen muss man immer Backup planen und regelmäßig durchführen.

#### RAID

**RAID** (Redundant Array of Inexpensive/Independent Disks) ist **kein Backup!**

| Eigenschaft | Beschreibung |
|---|---|
| Funktion | Redundante Speicherung auf mehreren Festplatten |
| Bei Ausfall | Daten können von anderer Platte gelesen/geschrieben werden |
| Hot-Swap | Kaputte Platte im laufenden Betrieb austauschbar |
| Software-RAID | Von fast allen Betriebssystemen unterstützt |
| Hardware-RAID | Betriebssystemunabhängig |

- RAID erfüllt **keine** Backup-Funktionen
- RAID kann als **Speicherort** für Backup verwendet werden

#### Oracle Backup-Tools

| Tool | Beschreibung |
|---|---|
| **exp/imp** | Ältere Versionen |
| **expdp/impdp** | Neuere Versionen (Data Pump) |
| **RMAN** | Recovery Manager |

**Weitere Tools:** Linux (cp, tar, bzip, gzip, dd), Windows (copy, Server-Sicherung), Drittanbieter (Acronis, Paragon, Fwbackups, Bacula).

#### Backup-Medien

| Medium | Beschreibung |
|---|---|
| **DAS** | Direct Attached Storage (lokale Festplatte) |
| **NAS** | Network Attached Storage (Netzwerk) |
| **SAN** | Storage Area Network (Netzwerk) |
| Magnetband | Bandlaufwerk mit Roboter, bis zu 4 GiB |
| CD/DVD/Blu-Ray | Optische Medien |
| USB-Geräte | Externe Speicher |
| FireWire-Geräte | Externe Speicher |
| Cloud | Sicherheit bedenklich |

**Generationsprinzip (Großvater-Vater-Sohn):**
- 3 Datenträger rotierend: 1. Sicherung → Großvater, 2. → Vater, 3. → Sohn
- 4. Sicherung: Großvater wird zum Sohn überschrieben, Rollen rotieren
- Je mehr Datenträger, desto sicherer

#### Backup-Methoden

| Methode | Beschreibung |
|---|---|
| **Online/Hot Backup** | DB läuft weiter, Daten werden im laufenden Betrieb gesichert; Gefahr: nicht-konsistenter Zustand; DB liefert spezifische Lösungen |
| **Offline/Cold Backup** | DB wird heruntergefahren, geschlossene Dateien kopiert; Datenbestand ist **immer konsistent** |

#### Sicherungsarten

| Art | Umfang | Markierung? | Wiederherstellung | Vorteil/Nachteil |
|---|---|---|---|---|
| **Normal** | Alle ausgewählten Daten | Ja (als gesichert) | Nur diese Sicherung | Einfach, aber groß |
| **Kopie** | Wie Normal | Nein | — | Keine Auswirkung auf andere Strategien |
| **Täglich** | Nur heute geänderte Daten | Ja | — | Klein, tagesbezogen |
| **Inkrementell** | Nur seit letzter Sicherung geänderte Daten | Ja | Letzte Normal + alle Inkrementellen in Reihenfolge | Wenig Zeit/Speicher, aber aufwändige Wiederherstellung |
| **Differenziell** | Nur seit letzter normaler Sicherung geänderte Daten | Nein | Letzte Normal + letzte Differenzielle | Einfache Wiederherstellung, aber wachsende Größe |

#### Sicherungsstrategien

| Strategie | Beispiel |
|---|---|
| Nur normale Sicherungen | Monatlich |
| Normal + Inkrementell | Jährlich normal, monatlich inkrementell |
| Normal + Differenziell | Jährlich normal, monatlich differenziell |

**Wichtig:** Anforderungen des Unternehmens und Speicherbedarf müssen berücksichtigt werden.

---

## 9. Data Warehouse Konzepte (i_DWKonzepte)

### 9.1 Konzepte

Drei Verarbeitungsarten:
- **Batch-Verarbeitung** – klassische Stapelverarbeitung
- **OLTP** = Online Transaction Processing – Tagesgeschäft
- **OLAP** = Online Analytical Processing – Analyse und Auswertung

OLAP-Systeme sind unverzichtbare Instrumente zur **Analyse umfangreicher und mehrdimensionaler Daten**. Sie gewähren anwendungsspezifische Sichten und werden primär von **Managern unterschiedlicher Ebenen** verwendet.

### 9.2 OLAP

**Gründe für OLAP:**
- Trennung von Tagesgeschäft und Auswertungen
- Historisierte Daten mit Zeitraum-Bezug
- Große Mengen von **Nur-Lese-Daten** (Permanenz)
- **Multidimensionale Datenmodelle**
- Gezielte **Denormalisierung** des ganzen Modells

**Eigenschaften von OLAP:**
- Intuitive und interaktive Analyse der Daten
- Flexible Darstellung aus unterschiedlichen Perspektiven
- Basis: **Hypercube** (kartesisches Produkt)
- Besondere Operationen: Rotation, Slice, Dice, Drill-Through, Drill-Across, Roll-Up, Drill-Down
- Clients: Spezielle Programme oder Tabellenkalkulationstools (z.B. Excel)

**Data Warehouse als OLAP-Datenbank dient:**
- Unterstützung strategischer Entscheidungen
- Analyse von Tendenzen und Mustern über große Zeiträume
- Bessere Entscheidungen durch bessere Informationen
- Flexiblere Analysemöglichkeiten
- Verlagerung der Analyse in Fachabteilungen
- Geringere Berichterstellungskosten
- Gemeinsame Informationsbasis im Unternehmen

### 9.3 ROLAP, MOLAP, HOLAP

#### ROLAP – Relationales OLAP

- Basiert auf **relationalen Datenbanken** (Oracle, DB2)
- Verwendet **Star-Schema** (Fakten- und Dimensionstabellen, 3NF bei Dimensionstabellen verletzt) und **Snowflake-Schema** (normalisiert)
- Für hohes Datenvorkommen und große Nutzerzahlen geeignet

**Vorteile:**
- Bewährte relationale Technologien für Abfragen, Verwaltung, Speicherung, Recovery, Archivierung
- Sperrmechanismen und Transaktionen nicht benötigt

**Nachteile:**
- Umfangreiche JOINs, Indizes, Table Scans nötig
- Umfangreiche Aggregationen und Berechnungen

#### MOLAP – Multidimensionales OLAP

- Basiert auf **herstellerspezifischen Datenbanken**
- Optimiert für hohe Performance in multidimensionalen Datenstrukturen
- Schnelle Aggregationen

**Vorteile:**
- Hohe Performance
- Am multidimensionalen Modell ausgerichtet

**Nachteile:**
- Hoher Schulungsaufwand
- Proprietäre Verwaltung
- Oft fehlende Standardschnittstellen

#### HOLAP – Hybrides OLAP

Variante aus ROLAP und MOLAP.

### 9.4 Lebenszyklus eines Data Warehouse

**Schritt A – Planung:**
- Analyse von Architektur und Infrastruktur
- Definition der Ressourcen und Zeitvorgaben
- Archivierungsstrategien
- Verbindungsmöglichkeiten und Ladeprogramme

**Schritt B – Spezifikation & Modellierung:**
- Ermittlung der Entitäten und Attribute
- Geschäftsprozesse und -anwendungsfälle identifizieren
- Ein-/Ausgabedaten und Detailierungsgrad festlegen
- **Logisches Datenmodell** entsteht

**Schritt C – Physischer Datenbankentwurf:**
- Star-Schema / Snowflake-Schema entwerfen
- Aufheben der Normalisierung
- Schlüssel, Indizierungsstrategien, Partitionierung festlegen

**Schritt D – Befüllen des DWH:**
- Definition der Quellsysteme
- Umformungsspezifikationen
- Aktualisierungszyklus festlegen
- **ETL-Prozeduren** definieren und testen
- Automatisierung der Ladevorgänge, Backup- und Recovery-Prozeduren
- Anwendungsentwicklung (Berichte, Dokumentation, Test)

**Schritt E – Betrieb:**
- Test und Überprüfung der Daten
- Schulung, Produktabnahme, Wartung
- Verbesserungen und Weiterentwicklung
- Performance-Untersuchungen

### 9.5 Vergleich OLTP und OLAP

| Merkmal | OLTP | OLAP |
|---|---|---|
| Abfragen | Vorhersehbar, einzelne Datensätze | Komplex, unvorhersehbar |
| Daten | Ständige Änderungen | Statisch, unveränderbar |
| Datenstruktur | Normalisiertes Modell (nur notwendige Redundanz) | Denormalisiertes Modell (verständlich) |
| Fokus | Hohe Transaktionsrate | Aggregation – viele Fakten zu einem Fakt |

### 9.6 ETL – Extract, Transform, Load

#### Extraktion
- Periodischer, ereignisgesteuerter oder anfragegesteuerter Abzug
- Komplette oder Delta-Übertragungen
- Protokollierung der Änderungen und Übertragungen

#### Transformation (im Arbeitsbereich)
- Datentypkonvertierung
- Wertumsetzung
- Schlüsselvergabe, -anpassung, -bereinigung
- Zeitstempelvergabe
- Datenverdichtung, -bereinigung

#### Laden
- Übertragung der Daten aus dem Arbeitsbereich in das Data Warehouse

### 9.7 Hypercube-Operationen

Grundlage: **Mehrdimensionaler Hypercube** mit Dimensionen wie Zeitperioden, Produkte, Abteilungen und Werten wie Absatzvolumen.

#### Navigationsoperationen

| Operation | Beschreibung |
|---|---|
| **Rotation** | Auswahl zweier konkreter Dimensionen (Drehung des Würfels) |
| **Slice** | Voller zweidimensionaler Ausschnitt aus dem Würfel |
| **Dice** | Mehrdimensionaler Ausschnitt (Untermenge, kleiner Würfel) |
| **Drill-Across** | Verbindung mehrerer Würfel gleicher Dimension zu einer Kette |

#### Hierarchische Navigation

| Operation | Beschreibung |
|---|---|
| **Drill-Down** | Von oberer zu tieferer Ebene der Hierarchie |
| **Roll-Up** | Von tieferer zu oberer Ebene der Hierarchie |
| **Drill-Through** | Wenn Drill-Down nicht mehr möglich, wird neue Datenquelle (Würfel) angeschlossen |

### 9.8 Varianten

- **Data Marts** – Begrenzter Anwendungsbereich (z.B. eine Abteilung). Einfacher einzurichten als DWH, aber Konsistenzprobleme bei mehreren Data Marts
- **Operation Data Stores** – Für aktuelle (tägliche) Auswertungen, unterstützen kaum langfristige Abfragen

---

## 10. Andere Typen von Datenbanken (j_AndereDB)

### 10.1 Hierarchische Datenbanken

#### Konzept
- Vermutlich die **ältesten Datenbanken**, heute nur noch historische Bedeutung
- Bei Bedarf durch relationale Datenbanken simulierbar
- Datenbestand: Datensätze mit fester oder variabler Struktur
- Semantische Beziehungen sind **fest programmmäßig durch Verweise** implementiert (Vorgänger-Nachfolger-Prinzip)

#### Vorteile
- Theoretisch sehr schnelle Such-, Einfüge- und Änderungsvorgänge

#### Nachteile
- **Unflexible baumartige Struktur**
- Mit der Zeit werden Zugriffe langsamer (Einfüge-/Löschoperationen) → Baum muss in Gleichgewicht gebracht werden (zeit- und speicheraufwendig)

#### Merkmale
- Gut geeignet für: **Dateisysteme**, LDAP, Internet-Domänen, Stücklisten
- Datensätze können mehr als zwei Verweise enthalten → nicht nur binäre, sondern auch **n-äre Bäume**
- Knoten können auf Bäume mit anders strukturierten Datensätzen verweisen (Bäume/Unterbäume = Entitätstypen)
- Nicht-hierarchische Beziehungen: durch verkettete Listen implementiert

#### IMS von IBM
- Älteste, bis heute eingesetzte hierarchische Datenbank
- Komponenten: Datenbank, IMS Explorer, IMS SOAP Gateway, IMS Java Connector, IMS Data Provider .NET

### 10.2 Netzartige Datenbanken

#### Konzept
- Entstehen aus hierarchischen DB durch **Verweisfelder für Rückwärtsbewegung**
- **Verallgemeinerung** der hierarchischen Datenbanken
- Unterschiedliche Entitätstypen vertreten, Beziehungen durch besondere Art der Datensätze modelliert

#### Vorteile
- Theoretisch vielfältige Verweise möglich

#### Nachteile
- Unflexible netzartige Struktur
- Modellierung der Beziehungen eingeschränkt
- Saubere Trennung der Entitätstypen kaum möglich

#### Merkmale
- Geeignet für: **geografische Elemente**, Makrostrukturen des Internets
- Jeder Knoten kann mehrere Vorgänger und Nachfolger haben
- Semantische Darstellung der Beziehungen meist programmiert
- Bekannter Vertreter: **UDS** (Universal Datenbank System) von Siemens
- Ca. 20 Jahre im Einsatz, dann durch **relationale Datenbanken verdrängt**

### 10.3 Verteilte Datenbanken

#### Konzept
- **Verbund von mehreren** (meist relationalen) Datenbanken
- Zusammenfassung von Informationseinheiten auf **mehreren Knoten** (Computern), über ein Netzwerk verbunden
- **Metadaten** (Zugriffsdaten) in einer übergeordneten Datenbank zusammengefasst
- Verteilte Transaktionen bestehen aus Teil-Transaktionen in den Komponenten-Datenbanken

#### Vorteile
- Optimale Darstellung der Unternehmensstruktur durch lokale Datenbestände
- Unabhängigkeit der Teil-Datenbanken voneinander
- Orts-, Plattform- und Netzwerkunabhängigkeit
- Ständiger Betrieb
- Effizienz durch parallele Verarbeitung
- Transparenz der Anfragen und Anweisungen
- Ergebnis- statt Sourcedaten-Transfer

#### Nachteile
- Vorbereitungsaufwand (Konzepte, Planung, Koordination)
- Zusätzliche Administration der Metadaten (Backup/Restore, Konsistenz)
- Aufwendige Entwicklung der Abfragen
- Abhängigkeit von Lauffähigkeit der einzelnen Teil-Datenbanken

#### Entwurf

Wie bei konventionellen relationalen DB, plus zusätzliche Schritte:
1. **Fragmentierungsschema** erstellen
2. **Zuordnungsschema** erstellen

#### Fragmentierung

Relationen werden in disjunkte Fragmente zerlegt:
- **Horizontale Zerlegung** – Datensätze nach Kriterien zusammengefasst (z.B. Status='Prof')
- **Vertikale Zerlegung** – Attribute zusammengefasst (z.B. Vorname + Nachname)
- **Kombinierte Zerlegung** – horizontal + vertikal

Anforderungen:
- **Vollständigkeit** – Rekonstruktion ergibt vollständige Datenbank
- **Disjunktion** – Fragmente überlappen sich nicht

#### Zuordnung (Allocation)
- Fragmente auf Knoten verteilen (theoretisch redundanzfrei)
- Aus Sicherheits-/Leistungsgründen: **Replikation**
- Benutzer arbeiten idealerweise nur mit dem Gesamtschema (Transparenz)

#### Verteilte Transaktionen
- DBMS muss globale Transaktion in **Teil-Transaktionen** zerlegen
- Entweder alle erfolgreich oder alle zurückgesetzt
- Jede Teil-DB muss **UNDO- und REDO-Funktionalität** beherrschen
- **Two-Phase-Commit**: prepare → ready/failed → commit/abort

### 10.4 Objektorientierte Datenbanken

#### Konzept
- Idee der OO: Daten und Aktionen (Methoden) zusammen bringen → **Kapselung**
- Idee der DB: Daten und deren **Beziehungen** modellieren, unabhängig von Aktionen
- Diese beiden Ideen sind **schwer zu vereinbaren**

#### Eigenschaften
- Vorteilhaft bei **Klassenhierarchien** unter Daten
- Komplexe Objekte speicher- und abrufbar
- **Keine Normalisierung**
- Abfragen langsamer als bei relationalen DB
- Geringe Kompatibilität zu allgemeinen Anwendungen

#### Beispiele
- **db4o** – geringe Speichergröße, für Java/.NET, keine SQL-Abfragesprache (QBE wird unterstützt), unterstützt Transaktionen (COMMIT, ROLLBACK)
- **Oracle** – objektrelationaler Ansatz: Objekttypen (analog zu Klassen) mit Daten, Funktionen und Prozeduren, instanziierbar in PL/SQL

### 10.5 No-SQL-Datenbanken (Not only SQL)

#### Konzept
- **No-SQL = Not only SQL** – betont die Existenz anderer Datenbanken neben relationalen
- Relationale DB bleiben wichtig für Anwendungen mit strengen Konsistenz-/Sicherheitsanforderungen

#### Gründe für No-SQL
- Enorm große Datenvolumen (TiB- und PiB-Bereiche)
- Kurze Laufzeiten der Abfragen nötig
- Konsistenz nicht vorrangig (Daten meist nur abgefragt)
- **Verfügbarkeit vor Konsistenz** (z.B. DNS)
- Speicher für relationale DB wird teuer

#### Eigenschaften
- Einfaches/schwaches/kein Schema
- Einfache horizontale und vertikale **Skalierung** (horizontal bevorzugt)
- **BASE-Prinzip** statt ACID
- Keine Normalformen, keine JOINs, denormalisiert
- Hohe Leistung und Verfügbarkeit dank **Replikation**

#### BASE vs. ACID

| BASE | ACID |
|---|---|
| **B**asically **A**vailable – Verfügbarkeit ggf. auf Kosten der Konsistenz | **A**tomic – Transaktion ununterbrechbar |
| **S**oft State – Konsistenz an Entwickler delegiert | **C**onsistent – konsistenter Zustand gewährleistet |
| **E**ventually Consistent – Abfragen auch bei inkonsistentem Zustand | **I**solated – Transaktionen verletzen einander nicht |
| | **D**urable – ausgefallene Transaktion gefährdet eigene Daten nicht |

#### Document-Stores
- **Schemafrei**, Daten in Dokumenten mit eindeutiger ID
- Keine einheitliche Struktur, verschachtelbar
- Felder können verschiedene Datentypen und Arrays haben
- Hohe Skalierbarkeit
- Beispiele: **MongoDB, CouchDB** (halb-strukturierte Formate: XML, JSON)
- Nachteil: keine Normalisierung → Datenredundanz möglich, Konsistenz durch Anwendung

#### Key-Value-Stores
- Nur **Schlüssel und zugehörige Werte** gespeichert
- Einfaches Schema, Schlüssel sortierbar
- Werte: Zahlen, Zeichenketten, Listen, Dokumente, Tabellen (nicht einheitlich)
- Daten im **Hauptspeicher (In-Memory)** oder auf Datenträger (On-Disc)
- Beispiele: **Berkeley DB, Redis, Amazon DynamoDB**
- Schnelle einfache Abfragen, aber komplexe Beziehungen schwer zu implementieren

#### Wide-Column-Stores
- Datensätze haben **unterschiedliche Struktur** (schemafrei)
- Milliarden von Feldern pro Datensatz möglich
- Feldstruktur: Spaltenname (Schlüssel), Daten, Zeitstempel
- **Column Families** für zusammenhängende Spalten
- Beispiele: **MS Azure Cosmos DB, Cassandra**
- Gut für Big Data Analytics / DWH
- Nicht verwechseln mit spaltenorientierten relationalen DB (die haben festes Schema)

#### XML-Datenbanken
- Daten im **XML-Format** gespeichert
- Abfragesprache: **XPath**
- Beispiel: **BaseX**
- Schnell für ganze Dokumente, langsam bei großen Datenmengen
- Fehlende Operationen wie COMMIT, ROLLBACK
- Eher **Verarbeitungssysteme für XML-Dokumente** als echte Datenbanken

#### Graph-Datenbanken
- Daten in drei Klassen: **Knoten, Attribut, Kante** (Graph-Struktur)
- Knoten = Tupel (Datensätze), Kanten = Beziehungen
- Effektiv für **"wer-kennt-wen"**-Informationen
- Nachteile: keine einheitliche Abfragesprache, keine direkten Zugriffe auf Knoten via Attributen

### Fazit

Die No-SQL-Datenbanken sind **sehr effektiv in ihrem Spezialgebiet**. Relationale DB bleiben wichtig für Anwendungen mit strengen Konsistenz-/Sicherheitsanforderungen.

---

## 11. Gesamtübersicht & Cheat-Sheet

### 11.1 Datenbankentwicklungsprozess (Phasenmodell)

```
Anforderungsanalyse
    ↓
Konzeptueller Entwurf  →  ERM (Peter-Chen-Notation)
    ↓
Logischer Entwurf      →  Relationale Tabellen (Konvertierungsregeln)
    ↓
Normalisierung         →  1NF → 2NF → 3NF → BCNF → 4NF → 5NF
    ↓
Physischer Entwurf     →  Tablespaces, Indizes, Storage-Parameter
    ↓
Implementierung        →  SQL (DDL + DML) + Constraints + Trigger
    ↓
Betrieb                →  Transaktionen, Backup, Rechte, Monitoring
```

### 11.2 ERM → Relationale Tabellen – Kurzreferenz

| ERM-Element | Konvertierungsregel |
|---|---|
| Entitätstyp | Eigene Tabelle; alle Attribute inkl. PK |
| N:M-Beziehung | Eigene Beziehungstabelle; PKs beider Seiten = PK der Beziehungstabelle |
| 1:N-Beziehung | Kein eigene Tabelle; PK der 1-Seite als FK in die N-Seite |
| 1:1-Beziehung | Option A: Zusammenführen; Option B: FK in eine der Tabellen |
| Schwache Entität | Eigene Tabelle; PK der starken Entität wird **Teil des PK** |
| Generalisierung | Obertyp-Tabelle + je eine Untertyp-Tabelle (PK des Obertyps als FK) |
| Mehrwertige Attribute | Eigene Tabelle + 1:N-Beziehung zur Entitätstabelle |

### 11.3 Normalformen – Kurzreferenz

| NF | Verletzung erkennen | Lösung |
|---|---|---|
| **1NF** | Zelle enthält mehrere Werte / Liste | Aufteilen in separate Zeilen oder Tabelle |
| **2NF** | Nicht-PK-Feld hängt nur von *Teil* des zusammengesetzten PK ab | Auslagern in neue Tabelle mit Teilschlüssel als PK |
| **3NF** | Nicht-PK-Feld hängt von einem anderen Nicht-PK-Feld ab (transitive Abhängigkeit) | Auslagern; abhängiges Feld wird PK neuer Tabelle |
| **BCNF** | Teil eines Schlüsselkandidaten hängt von Teil eines anderen Schlüsselkandidaten ab (Überlappung) | Aufteilen nach Schlüsselkandidaten |
| **4NF** | Nicht-PK-Felder sind semantisch unabhängig (unterschiedliche Verwendungshäufigkeit) | Nach Semantik trennen |
| **5NF** | Tabelle kann verlustfrei in kleinere Tabellen zerlegt werden | Vollständig zerlegen (JOIN-Rekonstruktion muss möglich sein) |

### 11.4 Relationale Algebra – Vollständiger Operatorensatz

| Operator | Notation | SQL | Grundoperator |
|---|---|---|---|
| **Selektion** | σ_P(R) | WHERE P | Ja |
| **Projektion** | π_A(R) | SELECT A | Ja |
| **Kartesisches Produkt** | R₁ × R₂ | CROSS JOIN | Ja |
| **Umbenennung** | ρ_alias(R) | AS alias | Ja |
| **Vereinigung** | R₁ ∪ R₂ | UNION | Ja |
| **Differenz** | R₁ — R₂ | MINUS / EXCEPT | Ja |
| **Schnittmenge** | R₁ ∩ R₂ | INTERSECT | Nein (= R₁ — (R₁ — R₂)) |
| **Join (Theta/Inner)** | R₁ ⋈_P R₂ | INNER JOIN ... ON P | Nein (= σ_P(R₁ × R₂)) |
| **Natural Join** | R₁ ⋈ R₂ | NATURAL JOIN | Nein |
| **Left Outer Join** | R₁ ⟕ R₂ | LEFT OUTER JOIN | Nein |
| **Right Outer Join** | R₁ ⟖ R₂ | RIGHT OUTER JOIN | Nein |
| **Full Outer Join** | R₁ ⟗ R₂ | FULL OUTER JOIN | Nein |
| **Semi-JOIN L** | L ⋉ R | SELECT L.* ... INNER JOIN | Nein |
| **Anti-Semi-JOIN L** | L ⊲ R | NOT IN / NOT EXISTS | Nein |

### 11.5 SQL – Vollständige SELECT-Syntax

```sql
SELECT [DISTINCT] spalten | *              -- Projektion (π)
    [, aggregatfunktion(spalte) [AS alias]]
FROM   tabelle1 [alias1]                   -- Quellen (×)
    [JOIN tabelle2 ON bedingung]           -- Verbund (⋈)
    [(SELECT ...) AS inline_view]          -- Inline View
WHERE  filterbedingung                     -- Selektion (σ)
    [AND | OR | NOT weiteresBedingung]
    [AND spalte LIKE 'muster']
    [AND spalte IN (wert1, wert2)]
    [AND spalte IS [NOT] NULL]
GROUP BY gruppierungsspalten               -- Gruppierung
HAVING aggregatbedingung                   -- Gruppenfilter
ORDER BY sortierspalte [ASC | DESC];       -- Sortierung
```

### 11.6 Transaktionen – ACID und Isolationsstufen

| Problem | Tritt auf bei | Gelöst durch |
|---|---|---|
| **Lost Update** | Zwei parallele Updates auf gemeinsamer Variable | SERIALIZABLE |
| **Dirty Read** | Lesen nicht-committeter Änderungen | READ COMMITTED (Oracle-Standard) |
| **Non-Repeatable Read** | Zweifaches Lesen liefert andere Werte | SERIALIZABLE |
| **Phantom Read** | Zweifaches COUNT liefert andere Anzahl | SERIALIZABLE |

| Isolationsstufe | Lost Update | Dirty Read | NR Read | Phantom | Oracle |
|---|---|---|---|---|---|
| READ UNCOMMITTED | ✗ | möglich | möglich | möglich | nicht verfügbar |
| READ COMMITTED | ✗ | verhindert | möglich | möglich | **Standard** |
| REPEATABLE READ | ✗ | verhindert | verhindert | möglich | nicht verfügbar |
| SERIALIZABLE | verhindert | verhindert | verhindert | verhindert | verfügbar |

### 11.7 Speicherstrukturen – Oracle-Hierarchie

```
Datenbank
 └── Tablespace (eine pro Anwendung)
      └── Datenbankdatei (.dbf)
           └── Segment / Extent (erweiterbare Speichereinheit)
                └── Block (kleinste I/O-Einheit)

Arbeitsspeicher:
 ├── SGA (System Global Area)
 │    ├── Database-Buffer-Cache (aktuelle Datenblöcke)
 │    ├── Dirty List (geänderte, noch nicht geschriebene Blöcke)
 │    ├── Redo-Log-Buffer (Änderungsprotokoll für Crash-Recovery)
 │    ├── Shared Pool (SQL-Parsing, Data Dictionary)
 │    ├── Large Pool (Recovery Manager)
 │    └── Java Pool (Java-Anwendungen)
 ├── PGA (Program Global Area) – Prozesssteuerung
 └── UGA (User Global Area)   – Sitzungsdaten je Benutzer
```

### 11.8 Backup-Entscheidungsmatrix

| Kriterium | Normal | Inkrementell | Differenziell | Kopie |
|---|---|---|---|---|
| Umfang | Alle ausgewählten Daten | Seit letzter Sicherung | Seit letzter Normal | Wie Normal |
| Als gesichert markiert? | Ja | Ja | Nein | Nein |
| Wiederherstellung | Diese Sicherung allein | Letzte Normal + alle Inkrementellen | Letzte Normal + letzte Differenzielle | — |
| Speicherbedarf | Hoch | Gering | Mittel | Hoch |
| Wiederherstellungsaufwand | Gering | Hoch | Mittel | — |

### 11.9 OLTP vs. OLAP vs. Data Warehouse

| Merkmal | OLTP | OLAP / DWH |
|---|---|---|
| Zweck | Tagesgeschäft | Analyse / Entscheidungsunterstützung |
| Abfragen | Vorhersehbar, einfach, einzelne Sätze | Komplex, ad-hoc, viele Zeilen |
| Daten | Ständige Änderungen | Statisch, historisiert, Nur-Lesen |
| Schema | Normalisiert (3NF) | Denormalisiert (Star/Snowflake) |
| Transaktionen | Häufig, kurz | Selten / keine |
| Benutzer | Viele operative Benutzer | Wenige Analytiker / Manager |
| Index-Typ | Konventionell (B-Tree) | Bitmap-Indizes (geringe Kardinalität) |

### 11.10 No-SQL-Datenbanken – Vergleich

| Typ | Struktur | Beispiele | Stärke | Schwäche |
|---|---|---|---|---|
| **Document-Store** | Dokumente (JSON/XML) | MongoDB, CouchDB | Flexibles Schema | Keine Normalisierung |
| **Key-Value-Store** | Schlüssel → Wert | Redis, DynamoDB, Berkeley DB | Extrem schnell | Keine komplexen Beziehungen |
| **Wide-Column-Store** | Spaltenorientiert, schemafrei | Cassandra, Azure Cosmos DB | Milliarden Felder, Big Data | Kein festes Schema |
| **XML-Datenbank** | XML + XPath | BaseX | Dokumentverarbeitung | Kein COMMIT/ROLLBACK |
| **Graph-Datenbank** | Knoten + Kanten | Neo4j u.a. | Beziehungsgeflechte | Keine einheitliche Abfragesprache |
| **Relational** | Tabellen, Normalisierung | Oracle, PostgreSQL, MySQL | ACID, SQL, Flexibilität | Skalierung bei extremen Datenmengen |

### 11.11 Wichtige Begriffe – Schnellreferenz

| Begriff | Definition |
|---|---|
| **Relation** | Untermenge des kartesischen Produkts mehrerer Datentypen = Tabelle |
| **Tupel** | Zeile / Datensatz in einer Relation |
| **Attribut / Feld** | Spalte in einer Relation |
| **Schema** | Namen aller Felder + Datentypen + Länge + Reihenfolge |
| **Primärschlüssel (PK)** | Minimaler Schlüssel, der Tupel eindeutig identifiziert |
| **Fremdschlüssel (FK)** | Attribut, das auf PK einer anderen Tabelle verweist |
| **Kardinalität** | Anzahl der Tupel in einer Relation |
| **Grad** | Anzahl der Attribute einer Relation |
| **Funktionale Abhängigkeit** | X → Y: X bestimmt Y eindeutig |
| **Transaktion** | Atomare Folge von Operationen (alles oder nichts) |
| **ACID** | Atomicity, Consistency, Isolation, Durability |
| **BASE** | Basically Available, Soft State, Eventually Consistent |
| **Deadlock** | Zwei Transaktionen warten gegenseitig aufeinander |
| **Serialisierbarkeit** | Parallele Ausführung entspricht in der Wirkung einer seriellen |
| **ETL** | Extract, Transform, Load (Befüllung eines DWH) |
| **OLTP** | Online Transaction Processing (Tagesgeschäft) |
| **OLAP** | Online Analytical Processing (Analyse) |
| **Hypercube** | Mehrdimensionaler Datenwürfel als Basis für OLAP |
| **Tablespace** | Logischer Container für Datenbankobjekte in Oracle |
| **Redo-Log** | Protokoll durchgeführter Änderungen (für Crash-Recovery) |
| **Rollback-Segment** | Speicher für Datenzustand vor Änderungen (für UNDO) |