docs: add obsidian hwr docs

Datenbanken/Klausur/Zimmi Hinweise.md

@@ -0,0 +1,3 @@
+# Klausurhinweise
+
+- Views und Inline-Views in SQL Code erkennen und unterscheiden können

Datenbanken/PA/PA_A4_bis_A8.sql

@@ -0,0 +1,165 @@
+/*
+    Thema:     Datenbanken PA
+    Datum:     20.02.2026
+
+    Autor 1:   Theo Leuthardt
+    MatrNr.:   77205844868
+	Autor 2:   Domenik Wilhelm
+    MatrNr.:   77207300494
+*/
+
+-- Tabellen löschen, falls vorhanden --
+BEGIN EXECUTE IMMEDIATE 'DROP TABLE PA_RESULT CASCADE CONSTRAINTS'; EXCEPTION WHEN OTHERS THEN NULL; END;
+/
+BEGIN EXECUTE IMMEDIATE 'DROP TABLE PA_SATELLITEN CASCADE CONSTRAINTS'; EXCEPTION WHEN OTHERS THEN NULL; END;
+/
+BEGIN EXECUTE IMMEDIATE 'DROP TABLE PA_STERNE CASCADE CONSTRAINTS'; EXCEPTION WHEN OTHERS THEN NULL; END;
+/
+BEGIN EXECUTE IMMEDIATE 'DROP TABLE PA_REFERENZ CASCADE CONSTRAINTS'; EXCEPTION WHEN OTHERS THEN NULL; END;
+/
+
+-- Aufgabe 4: Tabellen erstellen --
+CREATE TABLE PA_REFERENZ (
+    EntscheidungID  INTEGER      PRIMARY KEY,
+    Entscheidung    VARCHAR2(50) NOT NULL
+);
+
+CREATE TABLE PA_STERNE (
+   Stern   VARCHAR2(50)    PRIMARY KEY,
+   Masse   NUMBER          NOT NULL,
+   Radius  NUMBER          NOT NULL
+);
+
+CREATE TABLE PA_SATELLITEN (
+   Kennung         VARCHAR2(50)    PRIMARY KEY,
+   Geschwindigkeit NUMBER          NOT NULL
+);
+
+CREATE TABLE PA_RESULT (
+   Stern           VARCHAR2(50)    NOT NULL,
+   Kennung         VARCHAR2(50)    NOT NULL,
+   EntscheidungID  INTEGER         NOT NULL,
+   CONSTRAINT pk_result        PRIMARY KEY (Stern, Kennung),
+   CONSTRAINT fk_result_stern  FOREIGN KEY (Stern)
+       REFERENCES PA_STERNE (Stern),
+   CONSTRAINT fk_result_sat    FOREIGN KEY (Kennung)
+       REFERENCES PA_SATELLITEN (Kennung),
+   CONSTRAINT fk_result_ref    FOREIGN KEY (EntscheidungID)
+       REFERENCES PA_REFERENZ (EntscheidungID)
+);
+
+COMMIT;
+
+-- Aufgabe 4: Tabellen befüllen --
+INSERT INTO PA_REFERENZ (EntscheidungID, Entscheidung) VALUES (0, 'Kreisen');
+INSERT INTO PA_REFERENZ (EntscheidungID, Entscheidung) VALUES (1, 'Kollidieren');
+INSERT INTO PA_REFERENZ (EntscheidungID, Entscheidung) VALUES (2, 'Weiter fliegen');
+INSERT INTO PA_REFERENZ (EntscheidungID, Entscheidung) VALUES (9, 'Entscheidungsfehler');
+
+INSERT INTO PA_STERNE (Stern, Masse, Radius) VALUES ('Aldebaran',  3.38E+30, 3.07E+10);
+INSERT INTO PA_STERNE (Stern, Masse, Radius) VALUES ('Arktur',     2.19E+30, 1.77E+10);
+INSERT INTO PA_STERNE (Stern, Masse, Radius) VALUES ('Betelgeuse', 3.28E+31, 6.17E+11);
+INSERT INTO PA_STERNE (Stern, Masse, Radius) VALUES ('Orion',      6.20E+35, 1.67E+13);
+INSERT INTO PA_STERNE (Stern, Masse, Radius) VALUES ('Polarstern', 8.70E+30, 7.78E+08);
+INSERT INTO PA_STERNE (Stern, Masse, Radius) VALUES ('Sonne',      1.99E+30, 6.96E+08);
+INSERT INTO PA_STERNE (Stern, Masse, Radius) VALUES ('Erde',       5.97E+24, 6.37E+06);
+
+INSERT INTO PA_SATELLITEN (Kennung, Geschwindigkeit) VALUES ('Bohr',       9.90E+04);
+INSERT INTO PA_SATELLITEN (Kennung, Geschwindigkeit) VALUES ('Galileo',    5.00E+05);
+INSERT INTO PA_SATELLITEN (Kennung, Geschwindigkeit) VALUES ('Higgs',      1.28E+14);
+INSERT INTO PA_SATELLITEN (Kennung, Geschwindigkeit) VALUES ('Kopernikus', 1.31E+08);
+INSERT INTO PA_SATELLITEN (Kennung, Geschwindigkeit) VALUES ('Newton',     9.10E+03);
+INSERT INTO PA_SATELLITEN (Kennung, Geschwindigkeit) VALUES ('Plank',      7.77E+78);
+
+COMMIT;
+
+-- Aufgabe 5: PL/SQL Paket SAT --
+CREATE OR REPLACE PACKAGE SAT AS
+    C_GRAVITATIONSKONSTANTE CONSTANT NUMBER := 6.67E-11;
+    C_WURZEL_ZWEI           CONSTANT NUMBER := 1.41421356237;
+
+    PROCEDURE Action;
+END SAT;
+/
+
+-- Aufgabe 6: PL/SQL Prozedur GetVelocity --
+CREATE OR REPLACE PACKAGE BODY SAT AS
+
+    PROCEDURE GetVelocity(
+        p_EKG    OUT NUMBER,
+        p_ZKG    OUT NUMBER,
+        p_Masse  IN  NUMBER,
+        p_Radius IN  NUMBER
+    ) IS
+    BEGIN
+        p_EKG := SQRT(C_GRAVITATIONSKONSTANTE * p_Masse / p_Radius);
+        p_ZKG := p_EKG * C_WURZEL_ZWEI;
+    END GetVelocity;
+
+-- Aufgabe 7: PL/SQL Prozedur Action --
+
+    PROCEDURE Action IS
+        v_EKG           NUMBER;
+        v_ZKG           NUMBER;
+        v_EntscheidungID INTEGER;
+
+        CURSOR c_Sterne IS
+            SELECT Stern, Masse, Radius
+            FROM PA_STERNE;
+
+        CURSOR c_Satelliten IS
+            SELECT Kennung, Geschwindigkeit
+            FROM PA_SATELLITEN;
+    BEGIN
+        FOR r_Stern IN c_Sterne LOOP
+            FOR r_Satellit IN c_Satelliten LOOP
+                GetVelocity(v_EKG, v_ZKG, r_Stern.Masse, r_Stern.Radius);
+
+                IF r_Satellit.Geschwindigkeit < v_EKG THEN
+                    v_EntscheidungID := 1;
+                ELSIF r_Satellit.Geschwindigkeit <= v_ZKG THEN
+                    v_EntscheidungID := 0;
+                ELSIF r_Satellit.Geschwindigkeit > v_ZKG THEN
+                    v_EntscheidungID := 2;
+                ELSE
+                    v_EntscheidungID := 9;
+                END IF;
+
+                INSERT INTO PA_RESULT (Stern, Kennung, EntscheidungID)
+                VALUES (r_Stern.Stern, r_Satellit.Kennung, v_EntscheidungID);
+            END LOOP;
+        END LOOP;
+    END Action;
+
+END SAT;
+/
+
+-- Aufgabe 8: PL/SQL Anonymer Block --
+DECLARE
+    CURSOR c_Ergebnis IS
+        SELECT r.Stern, r.Kennung, ref.Entscheidung
+        FROM PA_RESULT r
+        JOIN PA_REFERENZ ref ON r.EntscheidungID = ref.EntscheidungID
+        ORDER BY r.Stern, r.Kennung;
+
+    r_Ergebnis c_Ergebnis%ROWTYPE;
+BEGIN
+    DELETE FROM PA_RESULT;
+
+    SAT.Action;
+
+    OPEN c_Ergebnis;
+    LOOP
+        FETCH c_Ergebnis INTO r_Ergebnis;
+        EXIT WHEN c_Ergebnis%NOTFOUND;
+
+        DBMS_OUTPUT.PUT_LINE(
+            'Stern: ' || RPAD(r_Ergebnis.Stern, 12) ||
+            ' | Satellit: ' || RPAD(r_Ergebnis.Kennung, 12) ||
+            ' | Entscheidung: ' || r_Ergebnis.Entscheidung
+        );
+    END LOOP;
+    CLOSE c_Ergebnis;
+END;
+/
+COMMIT;

Datenbanken/Zusammenfassungen/b_Modellierung - zusammenfassung.md

@@ -0,0 +1,417 @@
+# Modellierung – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–112**
+
+---
+
+## 1. Einführung (Folien 1–32)
+
+### 1.1 Definitionen (Folien 3–6)
+
+**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
+
+### 1.2 Modellierung (Folien 7–9)
+
+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.
+
+### 1.3 Datenhaltung (Folien 10–14)
+
+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
+
+### 1.4 Architektur (Folien 15–18)
+
+**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
+
+### 1.5 Datenbankbenutzer (Folien 19–20)
+
+| 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 |
+
+### 1.6 Entwicklung (Folien 21–24)
+
+- **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).
+
+### 1.7 Arten von Datenbanken (Folien 25–28)
+
+| 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.8 Prinzipien von E.F. Codd (Folien 29–32)
+
+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
+
+---
+
+## 2. Mengenlehre (Folie 33)
+
+Die Mengenlehre bildet die mathematische Grundlage der Theorie relationaler Datenbanken. Behandelt in separatem Skript (b_Mengenlehre). Themen: Definition, Eigenschaften, Operationen, Zahlenmengen, Dimensionen.
+
+---
+
+## 3. ANSI-SPARC-Modell (Folien 34–38)
+
+### 3.1 Drei-Schichten-Architektur (Folien 35–37)
+
+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 |
+
+### 3.2 Phasen des Datenbankentwurfs (Folie 38)
+
+1. **Anforderungsanalyse** → Spezifikation (Pflichtenheft)
+2. **Konzeptueller Entwurf** → Konzeptuelles Schema (ERM)
+3. **Logischer Entwurf** → Logisches Schema (Tabellen)
+4. **Physischer Entwurf** → Physisches Schema (Datenträger)
+
+---
+
+## 4. Anforderungsanalyse (Folien 39–50)
+
+### 4.1 Kurzfassung (Folien 40–42)
+
+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
+
+### 4.2 Beispiel: Universitätsschema (Folien 43–46)
+
+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
+
+### 4.3 Beispiel: Krankenhaus-Modell (Folien 47–50)
+
+Objekte: Ärzte, Pflegepersonal, Patienten mit deren Beziehungen (behandelt, betreut) und Prozessen (Behandlungsplan erstellen).
+
+---
+
+## 5. Konzeptueller Entwurf (Folien 51–87)
+
+### 5.1 Entity-Relationship-Modell (ERM) (Folien 51–54)
+
+Auf Basis der Anforderungsanalyse wird ein konzeptuelles ERM erstellt. Das konkrete DBMS wird noch nicht betrachtet.
+
+**Beispiele:**
+- **Uni-Schema:** Studenten, Vorlesungen, Professoren, Assistenten mit Beziehungen hören, prüfen, lesen, arbeitenFür, voraussetzen
+- **Krankenhaus-Schema:** Arzt, Patient, Pflegepersonal mit Beziehungen behandelt, betreut
+
+### 5.2 Modellierungsstrukturen in Peter-Chen-Notation (Folie 55)
+
+| 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 |
+
+### 5.3 Entitätstypen (Folie 56)
+
+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.
+
+### 5.4 Beziehungstypen (Folie 57)
+
+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.
+
+### 5.5 Attribute (Folien 58–62)
+
+**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) |
+
+### 5.6 Schlüssel und Primärschlüssel (Folien 63–65)
+
+- **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
+
+### 5.7 Rekursive Beziehungen (Folie 66)
+
+Beziehungen zwischen Entitäten desselben Entitätstyps. Dabei werden **Rollen** zugeschrieben.
+
+**Beispiele:**
+- Vorlesungen → voraussetzen (Vorgänger/Nachfolger)
+- Softwareprodukt → Versionsnummer
+- Polizisten → im Zweierteam patrouillieren
+
+### 5.8 Funktionalitäten (Folien 67–76)
+
+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).
+
+### 5.9 (min,max)-Notation (Folien 77–78)
+
+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
+
+### 5.10 Mehrstellige Beziehungen (Folien 79–80)
+
+- **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
+
+### 5.11 Spezielle Konzepte (Folien 82–87)
+
+#### Komposition / Schwache Entitäten (Folie 83)
+Existenz eines Entitätstyps ist von der Existenz eines anderen abhängig (**has-a**).
+- Beispiel: Konto existiert nur in Zusammenhang mit einer Bank
+
+#### Generalisierung (Folien 84–86)
+Abstraktion auf Ebene der Entitätstypen (**is-a**). 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 (Folie 87)
+Verschiedene Entitätstypen bilden in ihrer Gemeinsamkeit einen neuen Entitätstyp (**has-a**).
+- Beispiel: Fahrrad besteht aus Rahmen (Rohre, Lenker) und Rad (Speiche, Felge)
+
+---
+
+## 6. Logischer Entwurf (Folien 88–112)
+
+### 6.1 Definitionen (Folien 89–90)
+
+- **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
+
+### 6.2 Relationale Darstellung (Folien 91–93)
+
+**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.
+
+### 6.3 Konvertierungsregeln ERM → Relational (Folie 93)
+
+**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
+
+### 6.4 Vereinfachung der Darstellungen (Folien 94–106)
+
+#### 1:1-Beziehungen (Folien 95–97)
+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 (Folien 98–99)
+- 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 (Folien 100–101)
+- 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)
+
+### 6.5 Beispiel: Uni-Schema als Tabellen (Folien 102–103)
+
+| 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 |
+
+### 6.6 Wichtige Bemerkung (Folien 109–111)
+
+**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)
+
+Im Unterricht wird auf diese Meinung verzichtet (Verständnis halber), obwohl sie in der Wirtschaft sehr verbreitet ist.
+
+---
+
+## Zusammenfassung der Kernthemen
+
+| Thema | Kernaussage |
+|---|---|
+| Datenbank vs. Dateien | DB bietet Redundanzvermeidung, Mehrbenutzerbetrieb, Zugriffskontrolle |
+| Codds 12 Regeln | Definieren eine relationale DB im strengen Sinne |
+| ANSI-SPARC-Modell | Drei Ebenen: extern, konzeptionell, intern → Datenunabhängigkeit |
+| Anforderungsanalyse | Objekt-, Beziehungs- und Prozessbeschreibungen erstellen |
+| ERM – Peter-Chen | Entitäten (Rechteck), Beziehungen (Raute), Attribute (Oval), Schlüssel (unterstrichen) |
+| Funktionalitäten | 1:1, 1:N, N:M; (min,max)-Notation für genaue Kardinalitäten |
+| Spezielle Konzepte | Komposition (has-a, schwache Entität), Generalisierung (is-a), Aggregation (has-a) |
+| Logischer Entwurf | ERM → Tabellen; Vereinfachung bei 1:1 und 1:N durch Wegfall der Beziehungstabelle |
+| Fremdschlüssel | Bei 1:N wird PK der 1-Seite als FK in die N-Seite eingefügt |

Datenbanken/Zusammenfassungen/b_ModellierungFB - zusammenfassung.md

@@ -0,0 +1,157 @@
+# Modellierung – Fallbeispiel – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–16**
+
+---
+
+## 1. Überblick (Folie 1)
+
+Das Fallbeispiel behandelt die **Modellierung einer Rechnung** und folgt dem Schema:
+1. Beispiel-Rechnungen betrachten
+2. Mini-Welten beschreiben
+3. Konzeptuellen Entwurf für jede Mini-Welt erstellen
+4. Logischen Entwurf für jede Mini-Welt erstellen
+5. Fazit
+
+---
+
+## 2. Beispiel-Rechnungen (Folien 2–5)
+
+Es werden verschiedene reale Rechnungen als Ausgangspunkt gezeigt, aus denen die relevanten Entitätstypen und Beziehungen abgeleitet werden.
+
+---
+
+## 3. Mini-Welten – Entitätstypen (Folien 6–8)
+
+Aus den Rechnungen werden **mindestens 3 Entitätstypen** identifiziert:
+
+### 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)
+
+**Hinweis:** Kundeninformation wird bewusst vernachlässigt. Es gibt viele abgeleitete Attribute.
+
+### Formale Notation
+
+Entitätstypen als Mengen:
+```
+E = { e } = { [ Attr1, Attr2, ..., AttrN ] }
+```
+
+**Feste Entitätstypen (in beiden Mini-Welten gleich):**
+```
+Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
+Artikel = { [ ArtNr, ArtBezeichnung, EP, MwStSatz ] }
+```
+
+**Beziehungen:**
+- Rechnung **besteht aus** Rechnungspositionen
+- Rechnungsposition **beinhaltet** Artikel
+
+---
+
+## 4. Mini-Welt 1 (Folien 9–11)
+
+### Ansatz
+Alle Rechnungen werden **durchgehend** betrachtet. Gleiche Kombinationen [RechnPosNr, Menge] werden **zusammengefasst** (laut Mengenlehre nach G. Cantor: keine doppelten Elemente).
+
+**Beispiel:** Wenn in Rechnung A die erste Zeile 2 Tastaturen enthält und in Rechnung B die erste Zeile 2 Drucker, ist für beide nur ein Element [1, 2] zuständig.
+
+```
+Rechnungsposition = { [ RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
+```
+
+### Konzeptueller Entwurf (Folie 10)
+
+| Beziehung | Funktionalität |
+|---|---|
+| Rechnung — besteht aus — Rechnungsposition | **M : N** |
+| Rechnungsposition — beinhaltet — Artikel | **N : 1** |
+
+### Logischer Entwurf (Folie 11)
+
+```
+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 ] }
+```
+Dabei wird ArtNr als Fremdschlüssel eingefügt.
+
+---
+
+## 5. Mini-Welt 2 (Folien 12–14)
+
+### Ansatz
+**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** (anders als in Mini-Welt 1, wo sie verloren geht).
+
+```
+Rechnungsposition = { [ LfndNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
+```
+
+### Konzeptueller Entwurf (Folie 13)
+
+| Beziehung | Funktionalität |
+|---|---|
+| Rechnung — besteht aus — Rechnungsposition | **1 : N** |
+| Rechnungsposition — beinhaltet — Artikel | **N : 1** |
+
+### Logischer Entwurf (Folie 14)
+
+```
+Rechnung = { [ RgNr, Datum, Gesamtpreis, GesamtMwSt ] }
+Artikel = { [ ArtNr, EP, MwStSatz, ArtBezeichnung ] }
+Rechnungsposition = { [ LfndNr, RechnPosNr, Menge, Zwischensumme, ZwischenMwSt ] }
+besteht_aus = { [ RgNr, LfndNr ] }
+beinhaltet = { [ ArtNr, LfndNr ] }
+```
+
+**Vereinfachung** (beide 1:N-Beziehungen auflösen):
+```
+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.
+
+---
+
+## 6. Fazit (Folie 15)
+
+Beide Mini-Welten bilden den Sachverhalt ab. Welches Modell besser ist, hängt von den zuvor angeforderten Kriterien ab (z. B. Leistung/Geschwindigkeit).
+
+**Empfehlung:**
+- Beide Modelle implementieren
+- Antwortzeiten bei größerem Datenumfang vergleichen
+- Häufigste Abfragen vergleichen, seltene ebenfalls
+
+---
+
+## 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) |

Datenbanken/Zusammenfassungen/c_Algebra - zusammenfassung.md

@@ -0,0 +1,205 @@
+# Relationale Algebra – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–16**
+
+---
+
+## 1. Definitionen (Folien 1–3)
+
+### Formale Sprachen für Relationen
+
+Es gibt zwei formale Sprachen für die Behandlung von 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** (Structured Query Language).
+
+**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.
+
+---
+
+## 2. Operatoren im Detail (Folien 4–15)
+
+### 2.1 Selektion σ (Folie 4)
+
+Filtert Zeilen einer Relation anhand eines Prädikats. Das Prädikat wird für **jede Zeile** geprüft.
+
+**Beispiele:**
+```
+σ_{Semester > 10}(Studenten)
+→ Ergebnis: MatrNr 24002 (Xenokrates, 18), MatrNr 25403 (Jonas, 12)
+
+σ_{Name = 'Sokrates'}(Professoren)
+→ Ergebnis: PersNr 2125, Sokrates, C4, Raum 226
+```
+
+### 2.2 Projektion π (Folie 5)
+
+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`).
+
+### 2.3 Zusammenhang Algebra ↔ SQL (Folien 6–7)
+
+| Relationale Algebra | SQL |
+|---|---|
+| **π** (Projektion) | **SELECT** |
+| **σ** (Selektion) | **WHERE** |
+
+**Beispiele:**
+
+| 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 (Folie 7)
+
+**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!)
+```
+
+### 2.4 Umbenennung ρ (Folie 8)
+
+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
+```
+
+### 2.5 Vereinigung ∪ (Folien 9–10)
+
+**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] }
+```
+
+### 2.6 Differenz — (Folien 11–13)
+
+**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;
+```
+
+### 2.7 Schnittmenge ∩ (Folie 14)
+
+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');
+```
+
+### 2.8 Kartesisches Produkt × und Join (Folie 15)
+
+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))
+```
+
+Oder ausführlich mit expliziter Umbenennung:
+```
+π_{s.Name, v.Titel}(σ_{v.VorlNr=h.VorlNr ∧ h.MatrNr=s.MatrNr}(
+    ρ_s(Studenten) × ρ_v(Vorlesungen) × ρ_h(hoeren)))
+```
+
+---
+
+## Zusammenfassung
+
+| 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 (σ + ×) |

Datenbanken/Zusammenfassungen/d_SQL - zusammenfassung.md

@@ -0,0 +1,406 @@
+# SQL – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–96**
+
+---
+
+## 1. Überblick (Folie 2)
+
+SQL-Befehle sind in vier Kategorien unterteilt:
+
+| 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 |
+
+---
+
+## 2. Datentypen (Folien 3–5)
+
+**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) |
+
+---
+
+## 3. Einfache Befehle (Folien 6–11)
+
+### 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
+-- Professoren, die Assistenten haben
+SELECT p.Name, p.Raum
+FROM Professoren p,
+    (SELECT DISTINCT Boss FROM Assistenten) a
+WHERE p.PersNr = a.Boss;
+```
+
+### Allgemeine SELECT-Syntax (Folie 11)
+
+```sql
+SELECT column1, column2
+FROM table1, table2
+WHERE condition
+GROUP BY column1, column2
+HAVING condition
+ORDER BY column1, column2;
+```
+
+---
+
+## 4. Erweiterungen (Folien 12–14)
+
+### 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);
+```
+
+---
+
+## 5. Anfragen über mehrere Relationen (Folien 15–20)
+
+**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.
+
+---
+
+## 6. Operator JOIN (Folien 21–53)
+
+### 6.1 Motivation (Folie 21)
+
+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.
+
+### 6.2 Innere JOINs (Folien 23–30)
+
+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;
+```
+
+### 6.3 Äußere JOINs (Folien 31–37)
+
+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** |
+
+### 6.4 Semi-JOINs (Folien 38–46)
+
+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);
+```
+
+### 6.5 SQL-Implementierung (Folien 47–53)
+
+| 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 |
+
+---
+
+## 7. Anfragebearbeitung (Folien 54–58)
+
+### 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) |
+
+---
+
+## 8. Indizes (Folien 59–95)
+
+### 8.1 Überblick (Folie 59)
+
+| 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 ] }`
+
+### 8.2 Lineare Listen (Folien 60–64)
+
+**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
+
+### 8.3 Binärbäume (Folien 65–75)
+
+**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.
+
+### 8.4 Hashing (Folien 76–90)
+
+**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)
+
+### 8.5 Bitmap-Indizes (Folien 92–95)
+
+**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
+
+---
+
+## Zusammenfassung
+
+| Thema | Kernaussage |
+|---|---|
+| SQL-Kategorien | DDL (Struktur), DML (Daten), DCL (Rechte), TCL (Transaktionen) |
+| Einfache Befehle | CREATE, INSERT, UPDATE, DELETE, SELECT |
+| JOINs | Inner (NATURAL, Theta), Outer (LEFT, RIGHT, FULL), Semi (⋉, ⋊, ⊲, ⊳) |
+| Anfragebearbeitung | Parser → Optimizer (RBO/CBO) → Row Source Generator → Execution Engine |
+| Suchverfahren | Full Table Scan, Index-Scan (schnellste), Hash-Scan |
+| Binärbäume | O(log n) Suche; AVL/balanciert halten; Preorder/Inorder/Postorder |
+| Hashing | O(1) Durchschnitt; Kollisionsbehandlung; Modulo/Abschneiden/Zerlegung |
+| Bitmap-Indizes | Für geringe Kardinalität; Bit-Spalten pro Wert; schnelle logische Operationen |

Datenbanken/Zusammenfassungen/e_NFs - zusammenfassung.md

@@ -0,0 +1,423 @@
+# Normalisierung – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–41**
+
+---
+
+## 1. Einführung (Folien 1–6)
+
+### Was ist Normalisierung?
+
+Die relationale Darstellung einer entworfenen Datenbank kann noch **verfeinert** werden. Die Basis dafür bilden die **Normalformen** der Tabellen.
+
+**Normalisierung** = Aufteilung von Attributen in mehrere Relationen (Tabellen) mithilfe der Normalisierungsregeln, sodass eine Struktur entsteht, die **keine vermeidbaren Redundanzen** mehr enthält.
+
+### Ziele der Normalisierung
+
+| 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 (z. B. lange Laufzeiten, große Anzahl der Tabellen)
+- Jede nächste Normalform **basiert auf der vorigen**
+
+### Funktionale Abhängigkeit (Folie 4)
+
+**Definition:** Man betrachtet eine Relation, X und Y sind Mengen der Attribute. 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 (Folie 5)
+
+| 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 |
+
+### Überblick Normalformen (Folie 6)
+
+Die Normalformen bilden eine **aufsteigende Kette**: 1NF → 2NF → 3NF → BCNF → 4NF → 5NF
+
+---
+
+## 2. Erste Normalform – 1NF (Folien 7–16)
+
+### Definition (Folie 8)
+
+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 der 1NF
+
+- 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 – dieser ist erst für weitere Normalformen nötig
+
+### Mini-Welt-Beispiele: Adresse (Folien 9–10)
+
+| 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 (Folien 12–13)
+
+**Ausgangstabelle (nicht in 1NF):**
+```
+Wagen = { [ WagenID, Beschreibung, Status, Ankunft, Station ] }
+PK = [WagenID, Ankunft]
+```
+
+**Problem:** 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 (Folien 14–16)
+
+**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** – Produkt und Preis werden getrennt, jede Kombination ist eine eigene Zeile:
+
+| 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 |
+
+**Erweitertes Beispiel (Folie 15–16):** Tabelle mit Produkt+Herkunftsland und Menge+V.art als nicht-atomare Felder → Zerlegung in 7 separate Spalten (Vertragsdatum, Kunde, Produkt, Herkunftsland, V-Art, Lieferadresse, Menge). In 1NF ist hier **kein PK nötig**.
+
+---
+
+## 3. Zweite Normalform – 2NF (Folien 17–24)
+
+### Definition (Folie 17)
+
+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 (Folie 18)
+
+Felder, die nur vom **Teil des Primärschlüssels** abhängig sind, werden zusammen mit dem Teilschlüssel in **neue Tabellen ausgelagert**:
+
+```
+Vorher:  PK = [S1, S2] → alle Felder
+Nachher: Tabelle 1: PK = [S1, S2] → Felder die vom ganzen PK abhängen
+         Tabelle 2: PK = [S2]     → Felder die nur von S2 abhängen (DepS2)
+```
+
+### Beispiel: Bahnwagen (Folie 19)
+
+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 (Folien 20–22)
+
+**PK festgelegt:** [Vertragsdatum, Kunde, Produkt]
+
+**Analyse der Abhängigkeiten:**
+- [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**
+
+**Aufteilung:**
+```
+T-1 = { [ Vertragsdatum, Kunde, Produkt, Herkunftsland, Menge ] }
+T-2 = { [ Produkt, Herkunftsland ] }          ← falls V-Art unabhängig
+T-3 = { [ Kunde, Lieferadresse ] }
+```
+
+Wenn [V-Art] nur von [Produkt] abhängig ist, wird T-2 weiter aufgeteilt:
+```
+T-3-1 = { [ Produkt, Herkunftsland ] }
+T-3-2 = { [ Produkt, V-Art ] }
+```
+
+### Beispiel: Bestellungen (Folie 23)
+
+| RNr | ArtNr | LagerOrt | Anzahl |
+|---|---|---|---|
+| 100100 | 1010 | 22 | 1 |
+| 100100 | 1020 | 15 | 2 |
+| 100103 | 1040 | 13 | 10 |
+
+Bei ArtNr : LagerOrt = 1:1 gibt es **zwei Schlüsselkandidaten**: [RNr, ArtNr] und [RNr, LagerOrt]. Die **2NF ist in beiden Fällen verletzt**, da [LagerOrt] vom Teilschlüssel [ArtNr] abhängt (bzw. umgekehrt).
+
+**Lösung:**
+```
+Tabelle 1 = { [ RNr, ArtNr, Anzahl ] }
+Tabelle 2 = { [ ArtNr, LagerOrt ] }
+```
+
+### ERM-Bezug (Folie 24)
+
+Wenn man vom **ERM ausgeht** und den konzeptuellen Entwurf korrekt in den logischen umwandelt, kommt man direkt zu Tabellen, die die 2NF nicht verletzen – die Normalisierung ist dann nicht nötig.
+
+---
+
+## 4. Dritte Normalform – 3NF (Folien 25–28)
+
+### Definition (Folie 25)
+
+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, um eine perfekte Balance aus **Redundanz, Performance und Flexibilität** zu gewährleisten. Es gibt Sonderfälle (z. B. wissenschaftlicher Bereich), wo weiter normalisiert werden muss.
+
+### Vorgang (Folie 26)
+
+Funktionale Abhängigkeiten unter Nicht-PK-Feldern werden durch **Aufteilung der Tabelle** aufgelöst:
+
+```
+Vorher:  PK = [S1, S2], Feld F hängt von DepF ab (beide Nicht-PK)
+Nachher: Tabelle 1: [S1, S2, F]      ← F bleibt als FK
+         Tabelle 2: [F, DepF]         ← F wird PK der neuen Tabelle
+```
+
+### Beispiel: Bahnwagen (Folie 27)
+
+Aus der 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 ist vom WagenType abhängig):
+```
+W121a = { [ WagenID, WagenType ] }
+W122a = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
+```
+
+**Variante b** (Baujahr ist vom WagenType unabhängig):
+```
+W121b = { [ WagenID, WagenType, Baujahr ] }
+W122b = { [ WagenType, Leergewicht, Kapazitaet, Hersteller ] }
+```
+
+### Beispiel: Kunden (Folie 28)
+
+**Ausgangstabelle:** `{ [ KundenID, Adresse, Telefon ] }`
+
+Wenn Adresse und Telefon voneinander unabhängig sind (nur vom PK KundenID abhängig), ist die Tabelle bereits in 3NF. Falls nicht → Aufteilung:
+```
+Tabelle 1 = { [ KundenID, Adresse ] }
+Tabelle 2 = { [ KundenID, Telefon ] }
+```
+
+---
+
+## 5. Boyce-Codd-Normalform – BCNF (Folien 29–30)
+
+### Definition (Folie 29)
+
+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 (Folie 30)
+
+| 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 (ein Verein betreibt nur eine Sportart, aber zu einer Sportart gehören mehrere Vereine)
+
+**Schlüsselkandidaten:** [Name, Sportart] und [Name, Verein] → **Überlappung** (Name)
+
+**Problem:** [Sportart] hängt vom Nicht-Schlüssel-Feld [Verein] ab → verletzt BCNF
+
+**Lösung:**
+```
+Tabelle 1 = { [ Name, Verein ] }
+Tabelle 2 = { [ Sportart, Verein ] }
+```
+
+---
+
+## 6. Vierte Normalform – 4NF (Folie 31)
+
+### Definition
+
+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 der Tabelle.
+
+### Beispiel: Bahnwagen
+
+Aus der 3NF: `W122a = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }`
+
+[Leergewicht] und [Kapazitaet] werden **viel öfter** verwendet als [Hersteller] und [Baujahr] (historische Bedeutung) → **unterschiedliche Semantik** → werden nie gleichzeitig benötigt.
+
+**Aufteilung in 4NF:**
+```
+W122a1 = { [ WagenType, Leergewicht, Kapazitaet ] }    ← technische Daten
+W122a2 = { [ WagenType, Hersteller, Baujahr ] }         ← historische Daten
+```
+
+---
+
+## 7. Fünfte Normalform – 5NF (Folien 32–34)
+
+### Definition (Folie 32)
+
+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 1: Touristik-Firma (Folie 33)
+
+```
+T10 = { [ PersID, TourNr, Trans-Unternehmen ] }    ← PK = alle drei Attribute
+```
+
+Keine mehrwertigen Abhängigkeiten, da die drei Felder zusammen eine informative Einheit bilden. Trotzdem zerlegbar in:
+
+```
+T11 = { [ PersID, TourNr ] }
+T12 = { [ PersID, Trans-Unternehmen ] }
+T13 = { [ TourNr, Trans-Unternehmen ] }
+```
+
+Diese drei Tabellen können durch JOIN wieder die Originaltabelle herstellen.
+
+### Beispiel 2: Hersteller-Produkt-Person (Folie 34)
+
+| HerstID | ProduktID | PersID |
+|---|---|---|
+| 1 | Stift | 006 |
+| 1 | Ordner-L | 007 |
+| 1 | Kopierpapier | 007 |
+| 2 | Ordner-Z | 006 |
+| 3 | Kopierpapier | 007 |
+
+**Zerlegung in 5NF:**
+```
+TA = { [ HerstID, ProduktID ] }
+TB = { [ PersID, ProduktID ] }
+TC = { [ HerstID, PersID ] }
+```
+
+---
+
+## 8. Bedeutung des ERM (Folien 35–41)
+
+### ERM als Alternative zur Normalisierung (Folie 35)
+
+- Für die Praxis ist es empfehlenswert, dass Tabellen sich in **3NF** befinden
+- Höhere Normalformen sind eher für **theoretische Untersuchungen** wichtig
+- In der Praxis gelten Richtlinien (z. B. Geschwindigkeit), die manchmal den Verzicht auf 3NF (sogar 2NF) erfordern
+
+**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.
+
+### Anomalien ohne Normalisierung (Folien 36–38)
+
+**Beispiel:** Eine 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 ... |
+
+**Probleme (Anomalien):**
+
+| 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 (Folie 39)
+
+**Ergebnis der Normalisierung:**
+```
+Mitarbeiter   = { [ PersID, Name, AbtNr ] }
+Abteilung     = { [ AbtNr, Abteilung ] }
+arbeitet_an   = { [ PersID, ProjNr ] }
+Projekt       = { [ ProjNr, ProjBeschreibung ] }
+```
+
+### ERM-Ansatz liefert dasselbe Ergebnis (Folie 40)
+
+Wenn man mit dem **ERM anfängt** (konzeptuellen Entwurf richtig durchführt):
+
+```
+Abteilung (1) — gehört zu — (N) Mitarbeiter (M) — arbeitet an — (N) Projekt
+```
+
+Die Überführung in die relationale Darstellung liefert **dieselben Tabellen** wie die Normalisierung → ERM und Normalisierung sind **komplementäre Ansätze** zum gleichen Ziel.
+
+---
+
+## Zusammenfassung
+
+| Normalform | 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 ] }
+```

Datenbanken/Zusammenfassungen/f_Transaktionen - zusammenfassung.md

@@ -0,0 +1,273 @@
+# Transaktionen – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–31**
+
+---
+
+## 1. Definition (Folien 1–2)
+
+### Integrität und Transaktionen
+
+**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
+
+---
+
+## 2. Beispiel (Folie 3)
+
+Zwei ganze Zahlen A und B (Datenbestand):
+
+```
+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
+
+---
+
+## 3. Anforderungen (Folien 4–5)
+
+### Allgemeine Anforderungen (Folie 4)
+
+| 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.
+
+### ACID-Eigenschaften (Folie 5)
+
+| 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 |
+
+---
+
+## 4. Zustände einer Transaktion (Folie 6)
+
+```
+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 |
+
+---
+
+## 5. Synchronisation (Folien 7–8)
+
+### Definition
+
+**Synchronisation (Mehrbenutzersynchronisation)** = Koordinierung von mehreren Benutzerprozessen, eng verbunden mit der Ausführung der Transaktionen.
+
+### Ausführungsarten
+
+| 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. Probleme bei paralleler Ausführung (Folien 9–26)
+
+### Übersicht (Folie 10)
+
+Bei Zugriff auf **denselben Datenbestand** können folgende Probleme entstehen:
+1. **Lost Update**
+2. **Dirty Read**
+3. **Non-Repeatable Read**
+4. **Phantom Read**
+
+Diese Probleme können durch **Isolation** (verschiedene Sicherheitsstufen) vermieden werden.
+
+### Isolationsstufen – allgemein (Folie 11)
+
+- 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
+
+### 6.1 Lost Update (Folien 12–17)
+
+**Problem:** Die von einer Transaktion geänderten Daten werden von einer anderen Transaktion überschrieben.
+
+**Variante 1 – Direkt (Folie 12):**
+```
+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 (Folie 13):**
+```
+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`
+
+### 6.2 Dirty Read (Folien 18–19)
+
+**Problem:** 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).
+
+### 6.3 Non-Repeatable Read (Folien 20–21)
+
+**Problem:** 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).
+
+### 6.4 Phantom Read (Folie 22–23)
+
+**Problem:** Ä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** löst auch dieses Problem in Oracle.
+
+### Trade-off der Isolationsstufen (Folie 24)
+
+| Niedrigere Stufe | Höhere Stufe |
+|---|---|
+| Erlaubt gleichzeitigen Zugriff | Vermindert Probleme |
+| Mehr mögliche Nebenwirkungen | Mehr Systemressourcen |
+| Höhere Performance | Höhere Blockierungswahrscheinlichkeit |
+
+### Isolationsstufen nach ANSI/ISO SQL92 (Folien 25–26)
+
+| 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:** Der SQL-Standard schreibt diese Stufen vor, aber konkrete Datenbanken unterstützen sie **unterschiedlich**.
+
+---
+
+## 7. Synchronisationsstrategien (Folie 27)
+
+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 |
+
+---
+
+## 8. Synchronisationsverfahren (Folien 28–30)
+
+### 8.1 Sperrbasierte Synchronisation (Folie 28)
+
+Wird **oft eingesetzt**. Idee:
+
+| 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 (Folie 29)
+
+| 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 |
+
+### 8.2 Zeitstempelbasierte Synchronisation (Folie 30)
+
+Wird **selten eingesetzt**. Idee:
+
+| 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**.
+
+---
+
+## Zusammenfassung
+
+| Konzept | Beschreibung |
+|---|---|
+| **Transaktion** | Atomare Operation: alles oder nichts (COMMIT/ROLLBACK) |
+| **ACID** | Atomicity, Consistency, Isolation, Durability |
+| **Lost Update** | Überschreiben von Änderungen → SERIALIZABLE |
+| **Dirty Read** | Lesen nicht festgeschriebener Daten → READ COMMITTED |
+| **Non-Repeatable Read** | Unterschiedliche Leseergebnisse → SERIALIZABLE |
+| **Phantom Read** | Geänderte Zeilenanzahl → SERIALIZABLE |
+| **Sperrbasiert (2PL)** | Wachstums- und Schrumpfphase, shared/exclusive locks |
+| **Zeitstempelbasiert** | Ordnung nach Transaktions-Zeitstempeln |

Datenbanken/Zusammenfassungen/g_Speicherstrukturen - zusammenfassung.md

@@ -0,0 +1,138 @@
+# Speicherstrukturen – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–11**
+
+---
+
+## 1. Überblick (Folie 2)
+
+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) |
+
+---
+
+## 2. Datenträger (Folien 3–7)
+
+### Tablespace (Folie 3)
+
+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 (Folie 4)
+
+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 (Folie 5)
+
+| Typ | Beispiele |
+|---|---|
+| **Logische Objekte** | Tabellen, Indizes, User, Prozeduren |
+| **Physische Objekte** | Tablespace, Datenbankdatei, Segment (Extent), Block |
+
+### CREATE TABLE mit Storage-Klausel (Folie 5)
+
+```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 (Folie 6)
+
+```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 (Folie 7)
+
+| 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 |
+
+---
+
+## 3. Arbeitsspeicher (Folien 8–10)
+
+### System Global Area – SGA (Folien 8–9)
+
+| 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 (Folie 10)
+
+Beinhaltet Informationen, die für die **Steuerung der gesamten Oracle-Prozesse** notwendig sind.
+
+### User Global Area – UGA (Folie 10)
+
+Beinhaltet Informationen, die einem **aktuell verbundenen Benutzer** zugeordnet sind (Sitzung).
+
+---
+
+## Zusammenfassung
+
+| Ebene | Struktur | Funktion |
+|---|---|---|
+| **Datenträger** | Tablespace | Container für Anwendungsdaten |
+| | Datenbankdatei | Physische Dateien im Tablespace |
+| | Segment/Extent | Erweiterbare Speichereinheit für Tabellen/Indizes |
+| | Block | Kleinste I/O-Einheit |
+| | Rollback-Segment | Daten vor Änderung (UNDO) |
+| | Redo-Log-Datei | Daten nach Änderung (REDO) |
+| **Arbeitsspeicher** | SGA | Globaler Speicher: Buffer-Cache, Dirty List, Redo-Log-Buffer, Shared Pool, Large Pool, Java Pool |
+| | PGA | Prozesssteuerung |
+| | UGA | Benutzer-Sitzungsdaten |

Datenbanken/Zusammenfassungen/h_Sicherungskonzepte - zusammenfassung.md

@@ -0,0 +1,314 @@
+# Sicherungskonzepte – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–49**
+
+---
+
+## 1. Einführung (Folien 1–12)
+
+### Datensicherheit (Folie 3)
+
+**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 (ab 2005: IT-Grundschutz-Kataloge) unter www.bsi.bund.de
+
+### Schadenskategorien (Folien 5–6)
+
+| 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 |
+
+### Relevante Gesetze (Folie 7)
+
+| Gesetz | Kürzel | Jahr |
+|---|---|---|
+| Bundesdatenschutzgesetz | BDSG | 1990/2003/2009 |
+| Telekommunikationsgesetz | TKG | 2004 |
+| Telemediengesetz | TMG | 2007 |
+| Signaturgesetz | SigG | 2001 |
+| Diverse Landesdatenschutzgesetze | — | — |
+
+### Grundprinzipien der Sicherheit (Folien 8–12)
+
+| 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.
+
+---
+
+## 2. Integrität (Folien 13–23)
+
+### Definition (Folie 14)
+
+**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 (Folie 15)
+
+| Ebene | Beschreibung |
+|---|---|
+| **Datenbank** (bessere Lösung) | Klauseln in DDL-Anweisungen |
+| **Anwendung** (zusätzliche Lösung) | Programmcode der Anwendung |
+
+**Vorteile der DB-Ebene** (Folie 16):
+- 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 (Folie 17)
+
+- **DML:** INSERT, UPDATE, DELETE
+- **DDL:** ALTER, DROP, RENAME
+
+### Aktionen bei Integritätsverletzung (Folie 18)
+
+| 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 (Folie 19)
+
+Die Werte eines **Fremdschlüssels** müssen auch als Werte des **Primärschlüssels** vorhanden sein.
+
+### Constraint-Typen (Folie 20)
+
+| 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 (Folien 21–22)
+
+```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 (Folie 23)
+
+**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 |
+
+---
+
+## 3. Rechte (Folien 24–31)
+
+### User/Schema-Konzept in Oracle (Folie 25)
+
+- 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 (Folie 26)
+
+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 (Folie 27)
+
+| 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 (Folie 28)
+
+| 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 (Folien 29–31)
+
+```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).
+
+---
+
+## 4. Backup (Folien 32–49)
+
+### Definition (Folien 33–34)
+
+**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 (Folien 35–38)
+
+**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 (Folie 39)
+
+| Tool | Beschreibung |
+|---|---|
+| **exp/imp** | Ältere Versionen |
+| **expdp/impdp** | Neuere Versionen (Data Pump) |
+| **RMAN** | Recovery Manager |
+
+**Weitere Tools (Folie 40):** Linux (cp, tar, bzip, gzip, dd), Windows (copy, Server-Sicherung), Drittanbieter (Acronis, Paragon, Fwbackups, Bacula).
+
+### Backup-Medien (Folien 41–42)
+
+| 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 (Folie 43)
+
+| 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 (Folien 44–47)
+
+| 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 (Folie 48)
+
+| 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.
+
+---
+
+## Zusammenfassung
+
+| Bereich | Kernkonzepte |
+|---|---|
+| **Grundprinzipien** | Authentifizierung, Autorisierung, Protokollierung |
+| **Integrität** | Semantisch, Referentiell, Logisch; Constraints (PK, FK, NOT NULL, UNIQUE, CHECK); Trigger |
+| **Rechte** | DAC/MAC, System-/Objektprivilegien, Rollen, GRANT/REVOKE |
+| **Backup** | Hot/Cold, Normal/Inkrementell/Differenziell, RAID ≠ Backup, Generationsprinzip |

Datenbanken/Zusammenfassungen/i_DWKonzepte - zusammenfassung.md

@@ -0,0 +1,163 @@
+# Data Warehouse Konzepte – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–19**
+
+---
+
+## 1. Konzepte (Folie 2)
+
+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.
+
+---
+
+## 2. OLAP (Folien 3–5)
+
+### 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
+
+---
+
+## 3. ROLAP und MOLAP (Folien 6–8)
+
+### 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
+
+---
+
+## 4. Lebenszyklus eines Data Warehouse (Folien 9–13)
+
+### 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
+
+---
+
+## 5. Vergleich OLTP und OLAP (Folie 14)
+
+| 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 |
+
+---
+
+## 6. ETL – Extract, Transform, Load (Folie 15)
+
+### 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
+
+---
+
+## 7. Funktionsweise – Hypercube-Operationen (Folien 16–17)
+
+Grundlage: **Mehrdimensionaler Hypercube** mit Dimensionen wie Zeitperioden, Produkte, Abteilungen und Werten wie Absatzvolumen.
+
+### Navigationsoperationen
+- **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
+- **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
+
+---
+
+## 8. Varianten (Folie 18)
+
+- **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

Datenbanken/Zusammenfassungen/j_AndereDB - zusammenfassung.md

@@ -0,0 +1,199 @@
+# Andere Typen von Datenbanken – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–44**
+
+---
+
+## 1. Hierarchische Datenbanken (Folien 2–14)
+
+### 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
+
+---
+
+## 2. Netzartige Datenbanken (Folien 15–17)
+
+### 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**
+
+---
+
+## 3. Verteilte Datenbanken (Folien 18–25)
+
+### 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
+
+---
+
+## 4. Objektorientierte Datenbanken (Folien 26–29)
+
+### 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
+
+---
+
+## 5. No-SQL-Datenbanken (Folien 30–43)
+
+### 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 |
+
+### Vertreter der No-SQL-Datenbanken
+
+#### 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**.