.gitignore

@@ -0,0 +1 @@
+Software-Engineering/GrowGreenPaper/

Betriebssysteme/Klausurvorbereitung.md

@@ -0,0 +1,5 @@
+# Klausurvorbereitung
+
+### Themen:
+- Operationsprinzipien und Bestandteile eines Minimalsystems bei der John-Von-Neumann Architektur
+- Keine Simulation eines Schedulers kommt ran

Betriebssysteme/PA.md

@@ -0,0 +1,16 @@
+# Notizen zur PA
+
+- C-Datei zu Main (Import von Funktionen)
+- C-Datei zu Funktionen
+- H-Datei zu Interfaces/**Deklarationen**/Prototypen
+
+Anforderungen genau befolgen!!!
+
+Anforderung: 
+- wenn eine .c-Datei geändert wird, soll nur die geänderte .c-Datei neu kompiliert werden
+- wenn eine .h-Datei geändert wird, sollen alle .c-Dateien neu kompiliert werden
+- Test Prints können einfach auskommentiert werden (müssen nicht gelöscht werden, gibt aber auch kein Minuspunkt wenn es keine gibt)
+- Jeder Thread soll eine Log-Datei haben
+- Ordnungsgemäß warten bis Thread beendet wurden
+- Funktionen sollten nur EIN return statement haben
+- In Makefile keine Variablen mit $() nutzen sondern Klarnamen der Dateien verwenden!

Betriebssysteme/Zusammenfassung_Dateisysteme.md

@@ -0,0 +1,148 @@
+# Zusammenfassung: Dateisysteme
+## 1. Einführung: Warum externe Speicher?
+Ein Prozessor kann Informationen nicht dauerhaft in Registern speichern, da diese sich ständig ändern. Auch der Arbeitsspeicher (RAM) ist keine Lösung für langfristige Speicherung, da er:
+1. **Flüchtig ist:** Daten gehen beim Ausschalten verloren.
+2. **Teuer und begrenzt ist:** Man kann nicht unendlich viel RAM verbauen.
+### Gründe für Festplatten/externe Datenträger
+- Speicherung sehr großer Datenmengen.
+- Dauerhafte Verfügbarkeit (Persistenz) nach dem Herunterfahren.
+- Gleichzeitige Nutzung der Daten durch viele Prozesse.
+## 2. Definitionen & Grundkonzepte
+### Dateisystem vs. Datenbank
+Es gibt zwei Hauptarten der Datenspeicherung:
+- **Dateisystem:** Das Betriebssystem verwaltet die Daten als Dateien. Es organisiert Speichern, Löschen, Suchen und Umbenennen.
+- **Datenbank (DBMS):** Eine separate Software verwaltet strukturierte Daten. (Ausnahme: OS/400 nutzt eine DB als Dateisystem)
+### Definition Dateisystem
+Es stellt die Regeln dar, wie Daten gespeichert werden. Es sorgt für Transparenz: Der Benutzer muss nicht wissen, wie die Bits physikalisch auf der Platte liegen, er arbeitet nur mit logischen Dateien.
+### Klassifizierung von Dateisystemen
+1. **Lokal:** Befinden sich auf demselben Rechner (z.B. NTFS auf C:).
+2. **Netzwerk:** Befinden sich auf einem anderen Rechner, Kommunikation über OS (z.B. SMB/CIFS).
+3. **Verteilt:** Weiterentwicklung von Netzwerk-FS. Der Client weiß nicht, wo physikalisch der Server steht.
+4. **Virtuell:** Eine große Datei (Container), die intern wie ein Dateisystem strukturiert ist (z.B. .vhd, .vdi).
+## 3. Dateien & Verzeichnisse
+### Dateinamen & Konventionen
+- **Goldene Regel (Kompatibilität):** Nur lateinische Buchstaben, Ziffern, Unterstrich. Maximal 8 Zeichen. Erstes Zeichen ein Buchstabe.
+- **Nicht empfohlene Zeichen:** > < | ? ! * + \ / & ;
+### Erkennung von Dateitypen
+Das OS muss wissen, ob eine Datei ausführbar ist oder Daten enthält.
+1. **Dateierweiterung (für Benutzer):** .exe, .txt, .jpg. Dient der Zuordnung zur Anwendung.
+2. **Magische Zahl (für Programme):** Eine Byte-Sequenz am Anfang der Datei:
+    - **MZ:** Ausführbare MS-DOS/Windows Datei.
+    - **%PDF:** Adobe PDF Dokument.
+    - **FFD8 (Start) / FFD9 (Ende):** JPEG Bild.
+### Zugriffsarten
+- **Sequentiell:** Lesen von Anfang bis Ende (z.B. Magnetbänder).
+- **Direkt:** Sprung an eine beliebige Position (Festplatten).
+- **Indexsequenziell:** Nutzung eines Index-Blocks, um den richtigen Datenblock schnell zu finden.
+### Metadaten (Attribute)
+Jede Datei besitzt neben dem Inhalt auch Verwaltungsdaten:
+- Eigentümer (User ID).
+- Rechte (Read/Write/Execute).
+- Zeitstempel (Erstellt, Geändert, Zugriff).
+- Flags (Hidden, System, Read-only, Archive).
+## 4. Physische Struktur & Partitionierung
+Bevor ein Dateisystem erstellt werden kann, muss der Datenträger partitioniert werden.
+### Sektoren & Cluster
+- **Sektor:** Kleinste physische Einheit der Festplatte (meist 512 Byte).
+- **Cluster (Block):** Kleinste logische Einheit des Dateisystems. Besteht aus mehreren Sektoren (z.B. 4 KiB). Eine Datei belegt immer mindestens einen ganzen Cluster (interne Fragmentierung bei kleinen Dateien).
+### MBR (Master Boot Record)
+Der allererste Sektor der Festplatte.
+- Enthält den IPL (Initial Program Loader) zum Booten.
+- Enthält die Partitionstabelle (max. 4 primäre Partitionen).
+- Adressierung: Zylinder-Kopf-Sektor (CHS). Begrenzt auf 2 TiB.
+### GPT (GUID Partition Table)
+Der moderne Nachfolger des MBR.
+- Teil des UEFI-Standards.
+- Adressierung: LBA (Logical Block Addressing) – Sektoren werden einfach durchnummeriert.
+- Unterstützt Festplatten bis 8 ZiB und (mindestens) 128 Partitionen.
+- Enthält einen "Schutz-MBR" für Kompatibilität.
+### Boot-Prozess
+- **BIOS:** Startet IPL aus MBR. Sehr starr/eingeschränkt.
+- **UEFI:** Modernes "Mini-OS" auf dem Mainboard-Chip. Kann Filesysteme lesen, bietet Grafikmenü, Secure Boot.
+## 5. Speicherzuweisung (Implementierung)
+Wie werden die Blöcke einer Datei auf der Platte organisiert?
+### 1. Kontinuierliche Zuweisung
+- Datei liegt am Stück (Block 1, 2, 3 hintereinander).
+- **Vorteil:** Einfach, sehr schnelles Lesen.
+- **Nachteil:** Externe Fragmentierung (Löcher beim Löschen), Datei kann nicht wachsen, wenn kein Platz dahinter ist.
+### 2. Verknüpfte Liste (Linked List)
+- Jeder Block enthält Daten + Zeiger auf den nächsten Block.
+- **Vorteil:** Keine Fragmentierung, Datei kann wachsen.
+- **Nachteil:** Zugriff auf Block 500 erfordert Lesen von 1 bis 499 (langsam).
+### 3. Informationsknoten (Index / FAT)
+- Die Zeiger werden aus den Blöcken herausgenommen und in einer zentralen Tabelle gespeichert.
+## 6. Konkrete Dateisysteme
+### A. FAT (File Allocation Table)
+Das älteste und einfachste System (FAT12/16/32/exFAT).
+**Struktur:**
+1. **FAT:** Eine Tabelle, die die Festplatte abbildet. Jeder Eintrag entspricht einem Cluster. Inhalte: "Frei", "Defekt", "Letzter Cluster" oder "Zeiger auf nächsten Cluster".
+2. **Hauptverzeichnis:** Tabelle mit Dateinamen, Erweiterung, Attributen und Start-Cluster.
+3. **Datenzone:** Der eigentliche Inhalt.
+**Eigenschaften:** Keine Rechteverwaltung (Sicherheit), kein Besitzer-Konzept, kein Journaling. Dateiidentifikation nur über Name.
+**Attribute (8 Bit):** Read-only, Hidden, System, Volume-Label, Directory, Archive.
+### B. NTFS (New Technology File System)
+Standard seit Windows NT/XP. Proprietär von Microsoft.
+- **Struktur:** Zentral ist die MFT (Master File Table). Jede Datei (und das Verzeichnis) ist ein Eintrag in der MFT.
+- **Identifikation:** Über FRN (File Reference Number), nicht Name.
+**Features:**
+- **ACL (Access Control List):** Sehr feine Rechteverwaltung.
+- **Journaling:** Protokolliert Änderungen, verhindert Inkonsistenz bei Absturz.
+- **EFS:** Verschlüsselung.
+- **Quotas:** Speicherplatzbegrenzung pro User.
+- **Hard Links:** Ein Inhalt, mehrere Dateinamen (FRNs).
+### C. ext (Extended Filesystem - Linux)
+Standard unter Linux (ext2/3/4). Verwendet Inodes.
+- **Identifikation:** Über Inode-Nummer. Dateinamen existieren nur im Verzeichnis.
+**Aufbau:**
+- **Superblock:** Infos über FS-Größe und Typ.
+- **Bitmaps:** I-Bitmap (belegte Inodes) und D-Bitmap (belegte Datenblöcke).
+- **Inode-Liste:** Tabelle aller Inodes.
+**Inode-Struktur (Wichtig!):**
+Enthält Metadaten (UID, GID, Rechte rwxrwxrwx, Zeitstempel) und Zeiger:
+- 12 Direkte Verweise (auf Datenblöcke).
+- 1 Indirekter Verweis 1. Grades (zeigt auf Block mit weiteren Zeigern).
+- 1 Indirekter Verweis 2. Grades.
+- 1 Indirekter Verweis 3. Grades.
+- **Resultat:** Sehr kleine und extrem große Dateien (bis Peta-Bytes) effizient speicherbar.
+**Verzeichnis:** Ist bei ext einfach eine Datei, die eine Liste von "Name ↔ Inode-Nummer" enthält.
+## 7. Fragmentierung & Optimierung
+### Interne Fragmentierung
+Entsteht, wenn die Dateigröße kein Vielfaches der Blockgröße ist. Der letzte Block ist nur halb voll.
+- **Optimierung:** Große Dateien → große Blöcke. Viele kleine Dateien → kleine Blöcke.
+### Externe Fragmentierung
+Dateien sind physikalisch auf der Platte verstreut (nicht am Stück).
+- **FAT:** Stark betroffen.
+- **ext:** Bildet Block-Gruppen und lässt Platz für Wachstum → kaum Fragmentierung.
+- **xfs:** Puffert im RAM, um Größe zu berechnen, bevor geschrieben wird.
+### Bad Blocks
+Fehlerhafte Sektoren werden vom Dateisystem markiert und in einen Reserve-Bereich ("Hot Fix") umgeleitet. Das OS bekommt davon nichts mit.
+## 8. Sicherheit & Links
+### Links (Verknüpfungen)
+- **Hard Link:** Ein zweiter Name für denselben Inode/FRN. Löscht man einen, bleibt die Datei erhalten, solange der "Link-Counter" > 0 ist. (Nur im selben FS möglich).
+- **Soft Link (Symbolic):** Eine kleine Datei, die nur den Pfad zur Zieldatei enthält. (Funktioniert auch partitionsübergreifend).
+### Journaling
+Schutz gegen Abstürze während Schreibvorgängen (Stromausfall).
+- **Problem:** Metadaten (Bitmap, Inode, Verzeichnis) müssen konsistent sein.
+- **Lösung:** Änderungen erst in ein Log (Journal) schreiben, dann ausführen.
+- **Full-Journaling:** Auch Nutzdaten werden protokolliert (sehr sicher, aber langsam).
+
+## 9. Backup & Datensicherung
+**Wichtig:** Ein RAID-System (Redundant Array of Independent Disks) ist KEIN Backup! RAID schützt vor Hardwareausfall (Verfügbarkeit), Backup schützt vor Datenverlust (Löschen, Virus, Feuer).
+### Sicherungsarten (Klausurrelevant!)
+1. **Voll-Backup (Normal):** Sichert alles. Setzt das "Archiv-Bit" zurück (markiert als gesichert)
+2. **Kopie-Sicherung:** Sichert alles, fasst das Archiv-Bit aber nicht an.
+3. **Inkrementell:**
+    - Sichert nur Änderungen seit dem letzten Backup (egal ob voll oder inkrementell).
+    - Markiert Dateien als gesichert.
+    - **Vorteil:** Schnell, klein.
+    - **Nachteil:** Restore aufwändig (Voll + Ink1 + Ink2 + Ink3 ...).
+4. **Differenziell:**
+    - Sichert Änderungen seit dem letzten Voll-Backup.
+    - Markiert Dateien nicht als gesichert. Die Sicherung wächst jeden Tag.
+    - **Vorteil:** Schnellerer Restore (Voll + letzte Diff).
+    - **Nachteil:** Braucht mehr Platz als inkrementell
+### Strategie: Großvater-Vater-Sohn
+Rotationsprinzip mit mehreren Medien (z.B. Monat, Woche, Tag). Ermöglicht Rückgriff auf verschiedene Zeitpunkte in der Vergangenheit.
+### Betriebsarten
+- **Hot Backup:** Im laufenden Betrieb (Gefahr von Inkonsistenz).
+- **Cold Backup:** System wird heruntergefahren (Sicher, konsistent).

Betriebssysteme/Zusammenfassung_Deadlocks.md

@@ -0,0 +1,82 @@
+# Zusammenfassung: Deadlocks (Verklemmungen)
+## 1. Grundlagen: Ressourcen und Prozesse
+Prozesse benötigen zur Ausführung Ressourcen (Prozessor, Speicher, Dateien, Drucker, Laufwerke). Um das Phänomen Deadlock zu verstehen, muss man zunächst die Art der Ressourcen unterscheiden.
+### Arten von Ressourcen
+**1. Preemptable (Unterbrechbar/Entziehbar):**
+- Diese Ressourcen können einem Prozess weggenommen werden, ohne dass das System abstürzt oder Fehler entstehen.
+- **Beispiel:** CPU (durch Scheduling) oder Arbeitsspeicher (auf Standard-PCs durch Paging/Swapping auf die Festplatte).
+- **Hinweis:** Auf Smartphones ist RAM oft nicht entziehbar, da diese meist kein Swapping unterstützen.
+**2. Non-preemptable (Nicht-unterbrechbar/Nicht-entziehbar):**
+- Diese Ressourcen können nicht entzogen werden, ohne dass der Prozess oder die Aufgabe scheitert.
+- **Beispiel:** Drucker (ein halb gedrucktes Blatt kann nicht von einem anderen Job fortgesetzt werden), DVD/Blu-ray-Brenner.
+- **Fokus:** Deadlocks entstehen meistens im Kampf um diese nicht-entziehbaren Ressourcen.
+### Definition eines Deadlocks
+Ein Deadlock ist ein Zustand, in dem mehrere Prozesse aufeinander warten. Jeder Prozess wartet auf ein Ereignis (z. B. Freigabe einer Ressource), das nur ein anderer Prozess in dieser wartenden Gruppe auslösen kann. Da alle warten, passiert nichts mehr.
+## 2. Die 4 Strategien des Betriebssystems
+Wie geht ein OS mit Deadlocks um? Es gibt vier fundamentale Ansätze:
+1. **Ignorieren (Ignoring):** So tun, als ob es keine Deadlocks gibt.
+2. **Erkennen (Recognizing):** Zulassen, aber erkennen und beheben.
+3. **Vermeiden (Avoiding):** Dynamisch zur Laufzeit entscheiden, ob eine Zuweisung sicher ist.
+4. **Verhindern (Preventing):** Das System statisch so designen, dass Deadlocks strukturell unmöglich sind.
+## 3. Strategie 1: Ignorieren (Der Strauß-Algorithmus)
+Dies ist der einfachste Ansatz: Das Betriebssystem ignoriert die Möglichkeit eines Deadlocks komplett. Wenn einer auftritt, bleiben die Prozesse ewig hängen, bis der Benutzer eingreift (z. B. Prozess killt oder neu startet).
+### Rechtfertigung
+- **Wahrscheinlichkeit:** Wenn Deadlocks sehr selten auftreten (z. B. einmal alle 5 Jahre), aber reguläre Hardware-Abstürze wöchentlich passieren, lohnt sich der Aufwand für eine komplexe Deadlock-Lösung nicht.
+- **Performance:** Lösungen kosten oft Leistung oder Komfort. Ingenieure nehmen selten massive Performance-Einbußen in Kauf, um ein extrem seltenes Problem zu lösen.
+- Dieser Ansatz ist technisch "falsch", aber wirtschaftlich oft die Realität (Windows, Linux und macOS nutzen diesen Ansatz in vielen Bereichen).
+## 4. Voraussetzungen: Die Coffman-Bedingungen
+Damit ein Deadlock überhaupt entstehen kann, müssen vier Bedingungen gleichzeitig erfüllt sein (Coffman's Conditions):
+1. **Mutual Exclusion (Gegenseitiger Ausschluss):** Eine Ressource darf nur von einem Prozess exklusiv genutzt werden (nicht teilbar).
+2. **Hold and Wait (Besitzen und Warten):** Ein Prozess besitzt bereits Ressourcen und fordert weitere an, während er die alten behält.
+3. **No Preemption (Nicht-Entziehbarkeit):** Ressourcen können nicht gewaltsam weggenommen werden; der Besitzer muss sie freiwillig zurückgeben.
+4. **Circular Wait (Zirkuläres Warten):** Es gibt eine Kette von Prozessen (A wartet auf B, B wartet auf C ... C wartet auf A), die im Kreis aufeinander warten.
+## 5. Strategie 2: Erkennung (Recognizing)
+Das System lässt Deadlocks zu, überwacht aber den Zustand, um sie zu erkennen und dann zu lösen.
+### Der Ressourcengraph
+Zur Erkennung baut das OS einen Graphen auf:
+- **Kreise:** Stellen Prozesse dar (P).
+- **Rechtecke:** Stellen Ressourcen dar (R).
+- **Pfeil P → R:** Prozess fordert Ressource an (Request).
+- **Pfeil R → P:** Prozess besitzt Ressource (Assignment).
+### Analyse
+Das OS prüft diesen Graphen mittels Algorithmen (Tiefensuche, Rekursion) auf Zyklen.
+- Wird ein Zyklus (Kreis) gefunden, liegt ein Deadlock vor.
+- **Beispiel:** P1 hat Kamera, will HDD. P2 hat USB, will Kamera... P5 hat HDD, will USB. Dies bildet einen geschlossenen Kreis → Deadlock.
+### Behebung (Recovery)
+Wenn ein Deadlock erkannt wurde, muss er durchbrochen werden:
+1. **Killing (Prozessabbruch):** Einen Prozess im Zyklus beenden. Brachial, aber einfach. Am besten trifft es Prozesse, die ohne Datenverlust neu gestartet werden können (z. B. Compiler).
+2. **Preemption (Entzug):** Einer Ressource temporär den Besitzer wegnehmen. Hängt stark von der Hardware ab und ist oft manuell oder gar nicht möglich.
+3. **Rollback (Zurücksetzen):** Prozesse erstellen regelmäßig Checkpoints (Sicherungspunkte des Zustands). Bei Deadlock wird ein Prozess auf einen früheren Zeitpunkt zurückgesetzt (bevor er die kritische Ressource anforderte). Er verliert die Arbeit seit dem Checkpoint, aber der Deadlock ist gelöst
+## 6. Strategie 3: Vermeidung (Avoiding)
+Hier wird versucht, Deadlocks dynamisch zu umgehen, bevor sie entstehen. Das System entscheidet bei jeder Anfrage: "Ist es sicher, diese Ressource jetzt zu vergeben?"
+### Das Konzept des sicheren Zustands
+- Ein Zustand ist sicher, wenn es einen Weg gibt, alle Prozesse nacheinander zu bedienen, ohne dass sie blockieren.
+- Das OS führt Buch darüber, welcher Prozess was braucht. Droht ein "unsicherer Zustand" (Clinch), wird die Ressource nicht vergeben, und der Prozess muss warten.
+### Das Problem
+Avoiding funktioniert nur, wenn das OS in die Zukunft sehen kann. Es muss im Voraus wissen:
+- Welche Prozesse laufen werden.
+- Wann genau sie welche Ressourcen brauchen.
+Da diese Informationen in der Realität fast nie vorliegen, ist diese Strategie in der Praxis kaum anwendbar.
+## 7. Strategie 4: Verhinderung (Preventing)
+Dieser Ansatz ist statisch. Das System wird so designt, dass mindestens eine der vier Coffman-Bedingungen (siehe Punkt 4) niemals erfüllt werden kann. Wenn eine Bedingung fehlt, ist ein Deadlock mathematisch unmöglich.
+Man greift gezielt die einzelnen Bedingungen an:
+### A. Angriff auf "Mutual Exclusion" (Exklusivität)
+- **Idee:** Ressourcen gar nicht exklusiv vergeben.
+- **Lösung:** Spooling. Beispiel Drucker: Kein Prozess greift direkt auf den Drucker zu. Nur ein "Drucker-Daemon" darf das. Prozesse schreiben ihre Daten in eine Datei (Spool-Verzeichnis). Da Prozesse nur Dateien schreiben (was parallel geht) und nicht auf den Drucker warten, gibt es keinen Deadlock am Drucker.
+### B. Angriff auf "Hold and Wait" (Besitzen und Warten)
+- **Idee:** Verhindern, dass jemand Ressourcen hortet und auf neue wartet.
+**Lösung 1:** Ein Prozess muss alle benötigten Ressourcen ganz am Anfang anfordern. Bekommt er sie, läuft er. Wenn nicht, wartet er mit leeren Händen.
+- **Nachteil:** Man weiß oft nicht am Start, was man später braucht. Ressourcen werden verschwendet (lange belegt, aber erst am Ende genutzt).
+- **Beispiel:** Mainframe-Batch-Jobs (JCL) müssen oft alle Ressourcen im Header definieren.
+**Lösung 2:** Wer eine neue Ressource will, muss erst alle alten zurückgeben und dann alles zusammen neu anfordern.
+### C. Angriff auf "No Preemption" (Nicht-Entziehbarkeit)
+- **Idee:** Ressourcen gewaltsam wegnehmen.
+- **Problem:** Bei Druckern oder CD-Brennern führt das zu Chaos/Datenmüll.
+- **Lösung:** Virtualisierung (siehe Spooling). Die Hardware wird "versteckt", aber das geht nicht bei allen Ressourcen (z. B. Datensätzen in Datenbanken).
+### D. Angriff auf "Circular Wait" (Zirkuläres Warten)
+- **Idee:** Kreise unmöglich machen.
+- **Lösung:** Hierarchische Anforderung.
+    - Alle Ressourcen bekommen eine Nummer (1 bis N).
+    - **Regel:** Ein Prozess darf Ressourcen nur in aufsteigender Reihenfolge anfordern.
+    - Wer Ressource Nr. 5 hat, darf Nr. 6 anfordern, aber niemals Nr. 2.
+    - Damit ist ein Kreis (A → B → A) mathematisch ausgeschlossen.

Betriebssysteme/Zusammenfassung_Einführung_Hardware.md

@@ -0,0 +1,254 @@
+# Zusammenfassung Einführung + Hardware
+
+### 1. Definition und Aufgaben
+• **Hauptaufgabe:** Verwaltung physischer und logischer Ressourcen (CPU, RAM, Geräte, Prozesse)
+• **Schlüsselkonzept Transparenz:** Das BS verbirgt die komplexe interne Struktur und Hardware-Details vor dem Benutzer
+• **Zielfunktionen:**
+    ◦ **Auftragsverwaltung:** Steuerung und Abrechnung von Jobs
+    ◦ **Betriebsmittelverwaltung:** Zuweisung von Hardware und Vermeidung von Konflikten (Deadlocks)
+    ◦ **Speicherverwaltung:** Verwaltung von physischem und virtuellem Speicher
+    ◦ **Schutz:** Zugriffskontrolle und Fehlerbehandlung
+### 2. Klassifizierung von Betriebssystemen
+Betriebssysteme werden nach verschiedenen Kriterien unterschieden:
+• **Anzahl der Aufgaben:**
+    ◦ **Single-Tasking:** Nur ein Programm läuft (historisch)
+    ◦ **Multi-Tasking:** Mehrere Programme laufen scheinbar gleichzeitig
+• **Verarbeitungsmodus:**
+    ◦ **Stapelverarbeitung (Batch):** Jobs werden ohne Benutzerinteraktion nacheinander abgearbeitet (Großrechner)
+    ◦ **Dialogbetrieb (Interactive):** Der Benutzer interagiert direkt mit dem System
+    ◦ **Echtzeitverarbeitung (Real-time):** Garantierte Reaktionszeiten für Steuerungsaufgaben
+• **Architektur:** Zentralisiert vs. Verteilt (Zentrale Systemsteuerung existiert/existiert nicht)
+### 3. Eigenschaften moderner Betriebssysteme
+• **Präemptives Multitasking:** Das BS kann einem Prozess die CPU entziehen (im Gegensatz zum kooperativen Multitasking, wo das Programm die CPU freiwillig abgeben musste)
+• **Multithreading:** Eine Anwendung kann mehrere Aufgaben (Threads) parallel ausführen
+• **Symmetrisches Multiprocessing (SMP):** Mehrere gleichwertige Prozessoren teilen sich die Aufgaben ("jeder macht alles")
+• **Stabilität:** Durch Speichertrennung führt der Absturz einer App nicht zum Absturz des Gesamtsystems
+• **Sicherheit (C2-Standard):** Authentifizierung, Zugriffskontrolllisten (ACLs) für Ressourcen und Protokollierung
+• **Skalierbarkeit:** Fähigkeit, Leistung bei wachsenden Anforderungen durch neue Hardware (_Scale Up_) oder neue Rechner (_Scale Out_) zu halten
+### 4. Architektur und Design (Kernel)
+**Bestandteile eines BS:** Kernel (resident im RAM), externe Module (Treiber), Befehlsinterpreter. _Nicht_ dazu gehören Compiler oder Office-Programme
+**Architektur-Modelle:**
+• **Monolithischer Kernel:**
+    ◦ Alles (Dateisystem, Treiber, Speicherverwaltung) läuft im Kernel-Modus in einer Datei.
+    ◦ _Vorteil:_ Sehr schnell.
+    ◦ _Nachteil:_ Ein Fehler im Treiber bringt das ganze System zum Absturz
+• **Mikrokernel:**
+    ◦ Nur minimale Funktionen (IPC, Scheduling) im Kernel-Modus. Treiber und Dateisysteme laufen im Benutzer-Modus.
+    ◦ _Vorteil:_ Sehr stabil.
+    ◦ _Nachteil:_ Langsamer durch Kommunikations-Overhead
+• **Hybrid:** Mischung aus beiden (z.B. Windows, macOS), um Geschwindigkeit und Stabilität zu vereinen
+**Schichtenmodell:** Jede Schicht darf nur Dienste der direkt darunterliegenden Schicht nutzen
+### 5. Dualer Modus
+Zum Schutz vor fehlerhaften Programmen arbeitet der Prozessor in zwei Modi (gesteuert durch das CPL-Bit im Register):
+1. **Kernelmodus (Ring 0 / CPL=0):** Das BS hat vollen Zugriff auf alle Befehle und Hardware
+2. **Benutzermodus (Ring 3 / CPL=3):** Anwendungen laufen hier. Kritische Befehle (Hardwarezugriff, I/O) sind verboten
+### 6. Systemaufrufe
+**Der Systemaufruf (System Call):** Wenn eine Anwendung eine kritische Operation benötigt (z.B. "Speichere Datei"), kann sie das nicht selbst tun.
+• Sie ruft eine Bibliotheksfunktion auf (z.B. `open()`, `read()`)
+• Dies löst einen **Systemaufruf** aus.
+• Die CPU schaltet in den **Kernelmodus**, führt die Aufgabe sicher aus und schaltet zurück
+#### 1. Das Grundproblem
+Eine Anwendung (z.B. Word) darf nicht direkt auf die Hardware (z.B. Festplatte) zugreifen. Würde sie das tun, könnte ein Fehler in Word die Festplatte beschädigen oder Daten anderer Programme überschreiben. Daher laufen Anwendungen im **Benutzermodus (User Mode, Ring 3)** und das Betriebssystem (BS) im **Kernelmodus (Kernel Mode, Ring 0)**.
+Ein **Systemaufruf** ist der definierte Weg, wie eine Anwendung den Kernel bittet: _"Bitte erledige diese privilegierte Aufgabe für mich"_
+#### 2. Der Ablauf eines Systemaufrufs
+Der Prozess ist streng geregelt, um Sicherheit zu garantieren:
+1. **Aufruf:** Die Anwendung ruft eine Bibliotheksfunktion auf (z.B. `read()` in C),.
+2. **Auslöser:** Diese Funktion löst einen Software-Interrupt (Trap) aus. Dies signalisiert der CPU, dass ein Moduswechsel nötig ist.
+3. **Moduswechsel:** Die CPU schaltet vom Benutzermodus (CPL=3) in den Kernelmodus (CPL=0),.
+4. **Identifikation:** Das BS schaut in einer internen Tabelle (System Call Table) nach, welche Funktion ausgeführt werden soll (basierend auf einer ID/Nummer),.
+5. **Prüfung:** Das BS prüft die übergebenen Parameter auf Gültigkeit (z.B.: Darf dieser Nutzer diese Datei lesen?),.
+6. **Ausführung:** Der Kernel führt die Operation (z.B. Festplattenzugriff) aus.
+7. **Rückkehr:** Das BS schaltet zurück in den Benutzermodus und gibt das Ergebnis (oder einen Fehlercode) an die Anwendung zurück
+#### 3. Methoden der Parameterübergabe
+Da der Kernel und die Anwendung in unterschiedlichen Adressräumen arbeiten können, ist die Übergabe von Daten (z.B. "Welche Datei soll geöffnet werden?") nicht trivial. Es gibt drei Methoden:
+1. **Über Register:**
+    ◦ _Funktionsweise:_ Parameter werden direkt in die CPU-Register geschrieben.
+    ◦ _Vorteil:_ Sehr schnell und einfach.
+    ◦ _Nachteil:_ Die Anzahl und Größe der Register ist stark begrenzt (reicht nicht für viele Daten).
+2. **Über einen Speicherblock (Tabelle):**
+    ◦ _Funktionsweise:_ Die Parameter werden in einen Speicherblock im RAM geschrieben. Nur die **Startadresse** dieses Blocks wird in einem Register an den Kernel übergeben.
+    ◦ _Vorteil:_ Anzahl und Größe der Parameter spielen keine Rolle.
+    ◦ _Nachteil:_ Langsamer als Register
+3. **Über den Stack (Stapel):**
+    ◦ _Funktionsweise:_ Parameter werden auf den Stack gelegt (push). Das BS liest sie vom Stack (pop).
+    ◦ _Vorteil:_ Flexible Anzahl an Parametern möglich.
+#### 4. Kategorien und Beispiele
+Systemaufrufe decken alle Bereiche ab, in denen das BS Ressourcen verwaltet. In den Folien werden folgende Kategorien unterschieden:
+
+|   |   |   |
+|---|---|---|
+|Kategorie|Beispiele (Funktionen)|Erklärung|
+|**Prozessmanagement**|`fork()`, `exit()`, `CreateProcess()`|Prozesse erzeugen, beenden oder steuern.|
+|**Dateiverwaltung**|`open()`, `read()`, `CreateFile()`|Dateien öffnen, lesen, schreiben.|
+|**Speicherverwaltung**|`malloc()`, `GlobalAlloc()`|Arbeitsspeicher anfordern.|
+|**Geräteverwaltung**|`ioctl()`, `ReadConsole()`|Hardware konfigurieren oder ansprechen.|
+|**Zeitmanagement**|`sleep()`, `SetTimer()`|Warten oder Zeit messen.|
+|**Schutz/Sicherheit**|`chmod()`, `icacls()`|Zugriffsrechte ändern.|
+
+#### 5. Inkompatibilität zwischen Betriebssystemen
+Warum läuft ein Windows-Programm (.exe) nicht auf Linux? Einer der Hauptgründe sind die Systemaufrufe.
+• Die **Formate** der Systemaufrufe sind unterschiedlich.
+• Die **Art**, wie Parameter übergeben werden, unterscheidet sich. Selbst auf der gleichen Hardware (z.B. Intel CPU) sind Anwendungen daher nicht kompatibel, da sie eine "andere Sprache" sprechen, um mit dem Kernel zu reden
+### 7. Programmausführung & Speicher
+Wie wird aus Code ein Prozess?
+1. **Compiler:** Quellcode -> Objektdatei
+2. **Linker:** Verbindet Objektdatei mit Bibliotheken -> Ausführbare Datei (.exe)
+3. **Loader:** Lädt Datei in den RAM -> **Prozess**
+**Speicheraufbau eines C-Programms im RAM:**
+• **Text:** Der Programmcode
+• **Data:** Initialisierte globale Variablen
+• **BSS:** Nicht-initialisierte globale Variablen
+• **Heap:** Dynamischer Speicher (malloc)
+• **Stack:** Lokale Variablen und Funktionsaufrufe
+## Hardware:
+### 1. Grundbegriffe & Einheiten
+• **EVA-Prinzip:** Eingabe → Verarbeitung → Ausgabe. Peripheriegeräte (Tastatur, Monitor) machen E/A, die Systemeinheit (CPU) macht die Verarbeitung
+• **Maßeinheiten:** Die Folien unterscheiden strikt zwischen dezimalen und binären Präfixen:
+    ◦ **KB, MB, GB:** Basieren auf Faktor 1000 (103).
+    ◦ **KiB, MiB, GiB:** Basieren auf Faktor 1024 (210). _Wichtig: Das Betriebssystem rechnet meist binär (GiB), Festplattenhersteller oft dezimal (GB)._
+### 2. Rechnerarchitekturen
+#### Von-Neumann-Architektur (Standard PC)
+Die meisten modernen PCs basieren auf dem **John-von-Neumann-Prinzip** (1945):
+1. **SISD:** Single Instruction, Single Data (ein Befehl bearbeitet einen Datensatz).
+2. **Gemeinsamer Speicher:** Befehle (Programmcode) und Daten liegen im selben RAM.
+3. **Lineare Adressierung:** Speicherzellen werden über Adressen angesprochen.
+#### Andere Architekturen
+• **Harvard:** Getrennter Speicher für Befehle und Daten (schneller, teurer).
+• **SIMD (Single Instruction Multiple Data):** Ein Befehl bearbeitet viele Daten gleichzeitig (Vektorrechner, Supercomputer).
+• **MIMD (Multiple Instruction Multiple Data):** Viele Prozessoren bearbeiten unterschiedliche Daten mit unterschiedlichen Befehlen.
+#### Das Minimalsystem
+Ein funktionierender Computer benötigt mindestens:
+1. **CPU:** Verarbeitet Daten.
+2. **RAM:** Speichert Daten flüchtig.
+3. **Datenträger:** Speichert Daten dauerhaft.
+4. **Bussystem:** Verbindet alles. Besteht aus:
+	    ◦ _Datenbus_ (Prozessor -> Arbeitsspeicher).
+	    ◦ _Adressbus_ (wählt Speicherzellen/Geräte aus).
+	    ◦ _Steuerbus_ (Taktgeber, Lese-/Schreibsignale).
+#### Mainboard:
+Die Hauptplatine belegt die zentrale Stelle im Systemgehäuse. Sie steuert die Zusammenarbeit aller Bauteile
+**Wichtige Komponenten auf dem Mainboard:**
+• **Prozessorsockel:** Hier wird die CPU eingesetzt. Server-Mainboards können oft mehrere Sockel für mehrere Prozessoren haben, um die Leistung massiv zu steigern
+• **Chipsatz:** Der "Verkehrspolizist" des Mainboards. Er steuert den Datenfluss zwischen Prozessor, Speicher und Peripherie
+• **BIOS & CMOS:**
+    1. **Das BIOS (Basic Input/Output System)** ist die **Firmware** (Software). Es enthält die unveränderlichen Funktionen und Anweisungen, um den Startvorgang (Boot) überhaupt durchzuführen,
+2. **Das CMOS** ist der **Datenspeicher**. Es ist ein kleiner Speicherchip, der die **variablen Einstellungen** (Uhrzeit, Boot-Reihenfolge, Passwörter) speichert. Da dieser Speicher flüchtig ist, wird er von einer kleinen **Batterie** auf dem Mainboard gepuffert, damit die Daten nicht verloren gehen, wenn Sie den Stecker ziehen
+	**Kurz gemerkt:** Das BIOS ist der „Motor“ (das Programm), das CMOS ist der „Tank“ für Ihre persönlichen Einstellungen.
+• **Schnittstellen & Steckplätze:**
+    ◦ _Intern:_ Speicherbänke für RAM, Anschlüsse für Festplatten/SSDs (SATA/M.2)
+    ◦ _Erweiterung:_ Slots (z.B. PCIe) für Grafik-, Sound- oder Netzwerkkarten
+    ◦ _Extern:_ USB, Monitor, Netzwerk
+### 3. Der Prozessor (CPU)
+Die CPU führt arithmetische und logische Operationen aus. Die Leistung hängt von der Taktfrequenz und der Architektur (32-Bit vs. 64-Bit) ab
+#### CISC vs. RISC
+• **CISC (Complex Instruction Set Computing):** (z.B. Intel/AMD)
+    ◦ Mächtige, komplexe Befehle.
+    ◦ Befehle werden intern oft durch **Mikrocode** (Software im Chip) realisiert.
+    ◦ _Nachteil:_ Dekodierung dauert länger.
+• **RISC (Reduced Instruction Set Computing):** (z.B. ARM, SPARC)
+    ◦ Wenige, einfache Befehle.
+    ◦ Fest verdrahtet (kein Mikrocode), sehr schnelle Ausführung.
+#### Wichtige Register
+Register sind extrem schnelle, aber kleine Speicherbereiche direkt im Prozessor. Sie sind entscheidend für die Arbeitsweise der CPU und das Verständnis von Kontextwechseln (Multitasking).
+##### 1. Register-Gruppen und Namenskonventionen
+Die Bezeichnung der Register hängt von der Architektur ab. Die Folien nutzen die Intel-Nomenklatur:
+• **16-Bit:** `AX`, `BX`, `CX` ...
+• **32-Bit:** `EAX`, `EBX`, `ECX` ... (E = Extended)
+• **64-Bit:** `RAX`, `RBX`, `RCX` ... (R = Register/Re-extended)
+##### 2. Datenregister (General Purpose Registers)
+Diese werden für Rechenoperationen genutzt:
+• **AX / EAX / RAX (Accumulator):** Der primäre Akkumulator für arithmetische Operationen. Er wird auch für den Datenaustausch mit dem Arbeitsspeicher genutzt (ein Operand hier, einer im RAM).
+• **BX / EBX / RBX (Base):** Das Basisregister. Es wird oft für die adressierte Indizierung (Zeiger auf Daten) verwendet.
+• **CX / ECX / RCX (Counter):** Das Zählregister. Es ist speziell für Schleifen (`loops`) optimiert, da es automatisch herunterzählen (dekrementieren) kann.
+• **DX / EDX / RDX (Data):** Das Datenregister. Es wird für I/O-Operationen und für Berechnungen mit großen Zahlen (z.B. Multiplikation/Division zusammen mit AX) genutzt.
+##### 3. Segmentregister
+Da der Speicher in Segmente unterteilt ist, zeigen diese Register auf den Beginn eines Segments:
+• **CS (Code Segment):** Startadresse des Programmcodes (Befehle).
+• **DS (Data Segment):** Startadresse der Daten (Variablen, Konstanten).
+• **SS (Stack Segment):** Startadresse des Stacks (für Funktionsaufrufe/lokale Variablen).
+• **ES (Extra Segment):** Zusätzlicher Speicherbereich für Daten.
+##### 4. Zeiger- und Indexregister (Klausurrelevant!)
+Diese Register sind für den Programmablauf und die Stack-Verwaltung essenziell:
+• **IP / EIP / RIP (Instruction Pointer / Befehlszeiger):**
+    ◦ Speichert die Adresse des **nächsten** auszuführenden Befehls.
+    ◦ Zusammen mit dem `CS`-Register (`CS:IP`) ergibt sich die exakte physikalische Adresse des Befehls.
+• **SP / ESP / RSP (Stack Pointer / Stapelzeiger):**
+    ◦ Zeigt immer auf das aktuelle **Ende** (Top) des Stacks.
+    ◦ Wird zusammen mit dem `SS`-Register (`SS:SP`) verwendet.
+• **BP / EBP / RBP (Base Pointer):**
+    ◦ Dient als Referenzrahmen für Funktionsparameter und lokale Variablen auf dem Stack.
+    
+Wenn ein **Interrupt** auftritt oder ein **Prozesswechsel** (Kontextwechsel) stattfindet, muss das Betriebssystem den Inhalt _aller_ dieser Register sichern (in den PCB oder auf den Stack). Wenn der Prozess später weiterrechnet, werden die alten Werte in die Register zurückgeladen, damit der Prozess exakt dort weitermachen kann, wo er unterbrochen wurde
+#### Multicore
+Um Leistung zu steigern, ohne die Taktfrequenz (Wärme!) zu erhöhen, nutzt man mehrere Kerne.
+• **Hyperthreading:** Ein Kern simuliert zwei logische Kerne.
+• **Multi-Core:** Echte physische Kerne auf einem Chip. Jeder Kern hat eigene Rechenwerke (ALU/FPU) und L1-Cache, teilt sich aber oft L2/L3-Cache.
+### 4. Speicherhierarchie & Datenträger
+• **Cache (L1, L2, L3):** Puffer zwischen der sehr schnellen CPU und dem langsamen RAM. Ziel: Daten bereitstellen, bevor die CPU sie anfordert
+• **RAM (Arbeitsspeicher):**
+    ◦ _DRAM:_ Günstig, braucht Refresh-Zyklen (Kondensatoren entladen sich).
+    ◦ _SRAM:_ Schnell, teuer, kein Refresh nötig (Flip-Flops)
+• **Massenspeicher:**
+    ◦ _HDD:_ Mechanisch, Fragmentierung ist ein Problem.
+    ◦ _SSD:_ Flash-Speicher, keine beweglichen Teile, sehr schnell, verhält sich logisch wie eine Festplatte
+### 5. Treiber
+#### Das Grundproblem: Sprachbarrieren
+Das Betriebssystem muss mit vielen unterschiedlichen internen und externen Geräten (Festplatte, Grafikkarte, Drucker, Netzwerkkarte) kommunizieren.
+• **Komplexität:** Jedes Gerät ist technisch anders aufgebaut und besitzt eine eigene, oft sehr komplizierte „Sprache“ (Protokolle, Befehlssätze),.
+• **Unmöglichkeit:** Das Betriebssystem selbst (der Kernel) kann unmöglich alle Sprachen aller existierenden (und zukünftigen) Geräte beherrschen,.
+#### Die Hardware-Seite: Der Controller
+Jedes Gerät besitzt einen **Geräte-Controller** (einen Hardware-Chip).
+• Dieser Controller versteht die spezifische interne Sprache des Geräts und steuert die physischen Vorgänge (z.B. Schreibkopf bewegen, Pixel setzen).
+• Der Controller ist der direkte Ansprechpartner für die Software,.
+#### Die Software-Seite: Der Treiber
+Der **Treiber** ist ein spezielles Programm (Teil des Betriebssystems), das als Übersetzer fungiert.
+1. **Funktion:** Der Treiber kennt die Sprache des spezifischen Geräte-Controllers. Er übersetzt die allgemeinen Befehle des Betriebssystems (z.B. „Drucke Datei“) in die spezifischen Befehle für den Controller,.
+2. **Kommunikation:** Er sorgt für den Datentransfer hin und her zwischen dem Hauptspeicher und dem Gerät,.
+3. **Abstraktion:** Für manche standardisierten Schnittstellen (z.B. USB-Massenspeicher) gibt es generische Treiber, die für viele Geräte funktionieren. Meistens ist ein Treiber aber spezifisch für genau **ein** Gerät und genau **ein** Betriebssystem,.
+#### Geschwindigkeit
+Alle **E/A-Operationen** (Ein-/Ausgabe), die über Treiber laufen, sind im Vergleich zu reinen CPU-Register- oder RAM-Zugriffen extrem **langsam**. Daher versucht das BS oft, diese Wartezeiten durch Multitasking (Prozesswechsel) zu überbrücken.
+### 6. Datenübertragung: DMA (Direct Memory Access)
+**Problem:** Wenn die CPU jedes Byte einzeln von der Festplatte in den RAM kopieren müsste, wäre sie zu 100% ausgelastet ("zu schlau für dumme Arbeit")
+**Lösung (DMA-Ablauf):**
+1. Die **CPU** beauftragt den **DMA-Controller**: "Kopiere X Bytes von Adresse A nach B".
+2. Die CPU widmet sich sofort anderen Prozessen (rechnet weiter).
+3. Der **DMA-Controller** übernimmt den Bus und kopiert die Daten selbstständig.
+4. Nach Abschluss sendet der DMA-Controller einen **Interrupt** an die CPU ("Fertig!").
+5. Die CPU unterbricht ihre Arbeit kurz und bearbeitet das Ende des Transfers.
+### 7. Kommunikation: Polling vs. Interrupts
+#### 1. Polling (Aktives Warten)
+Dies ist die ältere und einfachere, aber ineffiziente Methode.
+**Das Prinzip:** Der Prozessor übernimmt die aktive Rolle. Er befindet sich in einer Schleife und fragt nacheinander jedes angeschlossene Gerät ab: _"Hast du Daten für mich? Hast du einen Auftrag?"_
+**Der Ablauf:**
+1. Die CPU stoppt ihre aktuelle Berechnung.
+2. Sie fragt Gerät A: "Status?".
+3. Sie fragt Gerät B: "Status?".
+4. Wenn kein Gerät etwas will, nimmt die CPU die Berechnung wieder auf oder fängt die Runde von vorne an
+**Die Nachteile (Warum wir es kaum noch nutzen):**
+• **Verschwendung:** Die CPU verbringt einen Großteil ihrer Zeit mit Fragen, auf die die Antwort meistens "Nein" lautet. Diese Zeit fehlt für echte Berechnungen
+• **Datenverlust:** Wenn die CPU gerade Gerät A bedient (Daten kopiert) und Gerät B in diesem Moment wichtige Daten empfängt (z.B. Netzwerkpakete), kann die CPU nicht reagieren. Da Gerät B oft keinen großen eigenen Speicher hat, gehen diese Daten verloren
+#### 2. Interrupts (Unterbrechungen)
+Dies ist der Standard in modernen Systemen. Hier melden sich die Geräte aktiv bei der CPU ("Event-Driven").
+
+**Das Prinzip:** Die CPU kümmert sich nicht um die Geräte, sondern rechnet an ihrem Prozess. Wenn ein Gerät Aufmerksamkeit braucht, sendet es ein elektronisches Signal (Interrupt). Die CPU unterbricht ihre Arbeit _sofort_, erledigt den Job des Geräts und macht dann weiter, als wäre nichts gewesen
+**Notwendige Hardware-Komponenten:** Damit das funktioniert, benötigt die CPU Hilfe:
+• **Interrupt-Register (IR):** Ein spezielles Register in der CPU, in dem Bits gesetzt werden, wenn eine Unterbrechung anliegt.
+• **Interrupt-Controller:** Ein Chip, der die Signale der vielen Geräte sammelt und geordnet an die CPU weiterleitet.
+• **Stack:** Ein Speicherbereich im RAM, um den Zustand der CPU (Kontext) kurzzeitig zu sichern.
+• **Interrupt-Vektoren:** Eine Tabelle im Speicher, die der CPU sagt: "Bei Fehler Nr. 5 springe zu Adresse X".
+• **ISR (Interrupt Service Routine):** Das kleine Programm (Treiber), das das Gerät tatsächlich bedient.
+
+Der detaillierte Ablauf eines Interrupts am Beispiel einer Netzwerkkarte, die Daten empfängt:
+1. **Ereignis:** Daten kommen an der Netzwerkkarte an. Da ihr Speicher klein ist, müssen sie sofort abgeholt werden.
+2. **Signal:** Die Karte sendet ein Signal an den **Interrupt-Controller** (z.B. IRQ 5).
+3. **Weiterleitung:** Der Interrupt-Controller setzt das entsprechende Bit (Nr. 5) im **Interrupt-Register (IR)** der CPU.
+4. **Zyklus-Check:** Die CPU beendet ihren _aktuellen_ Befehl. Bevor sie den nächsten Befehl lädt, prüft sie automatisch das IR.
+5. **Erkennung:** Die CPU sieht: "Bit 5 ist gesetzt!".
+6. **Sicherung (Kontextwechsel):** Die CPU unterbricht das laufende Programm. Sie speichert alle wichtigen Registerinhalte und den Befehlszeiger auf den **Stack**.
+7. **Lookup:** Die CPU schaut in der Vektortabelle nach Eintrag Nr. 5, um die Startadresse der passenden **ISR** zu finden.
+8. **Ausführung:** Die CPU springt zur ISR. Die ISR kopiert die Daten von der Netzwerkkarte in den RAM.
+9. **Restore:** Die ISR ist fertig. Die CPU lädt die alten Registerwerte vom Stack zurück.
+10. **Weiter:** Das ursprüngliche Programm läuft an exakt der gleichen Stelle weiter.
+#### Vergleich:
+• Beim **Polling** geht die Initiative von der CPU aus (teuer, langsam).
+• Beim **Interrupt** geht die Initiative vom Gerät aus (effizient, schnell).

Betriebssysteme/Zusammenfassung_IPC.md

@@ -0,0 +1,112 @@
+# Zusammenfassung: IPC
+## 1. Grundlagen und Motivation
+Prozesse benötigen häufig einen Informationsaustausch (Beispiel: Ein E-Mail-Programm Mail User Agent sendet Daten an den Mail Transfer Agent). Da jeder Prozess grundsätzlich einen eigenen, isolierten Adressraum besitzt, ist eine direkte Kommunikation nicht trivial.
+**Das Grundprinzip:**
+- Für die Kommunikation ist gemeinsam genutzter Speicher (Shared Memory) zwingend erforderlich. Dies kann ein Bereich im Kernel-Adressraum sein oder eine Datei auf der Festplatte.
+- Moderne Betriebssysteme erlauben es Prozessen, Teile ihres Adressraums explizit für andere freizugeben.
+**Prozesse vs. Threads in der IPC:**
+- Threads desselben Prozesses teilen sich bereits automatisch den Adressraum.
+- Wenn zwei Prozesse einen gemeinsamen Speicherbereich nutzen, verhalten sie sich technisch fast identisch zu zwei Threads.
+- Daher gilt der Leitsatz: **Interprozesskommunikation ist im Grunde immer Interthreadkommunikation.**
+## 2. Das Problem: Race-Conditions (Wettlaufsituationen)
+**Definition:** Eine Race-Condition entsteht, wenn mehrere Prozesse/Threads gleichzeitig auf gemeinsam beschreibbare Ressourcen zugreifen und das Endergebnis von der zufälligen zeitlichen Reihenfolge der Ausführung abhängt.
+**Gefahren:**
+- Race-Conditions führen zu semantischen Fehlern, die schwer zu finden sind (keine Syntaxfehler!).
+- Der Code funktioniert meistens korrekt, stürzt aber sporadisch ab („Heisenbugs").
+### Beispiel 1: Das Logdatei-Problem (Der Absturz)
+Zwei Prozesse (A und B) wollen in dieselbe Logdatei schreiben:
+1. Prozess A liest den Status: „Datei ist geschlossen". A setzt intern `is_open = false`.
+2. **Kontextwechsel:** Die Zeitscheibe von A läuft ab, bevor A die Datei wirklich öffnen kann.
+3. Prozess B kommt an die Reihe, liest den Status: „Datei ist geschlossen".
+4. Prozess B öffnet die Datei, schreibt hinein und setzt den Status (physikalisch) auf „offen".
+5. **Kontextwechsel:** B wird unterbrochen.
+6. Prozess A läuft weiter. Da A intern gespeichert hat `is_open = false`, prüft es nicht erneut.
+7. **Fehler:** A versucht, die (bereits offene) Datei erneut zu öffnen → Absturz oder Datenverlust.
+### Beispiel 2: Lost Update (Datenbank)
+Zwei Threads wollen einen Zähler (`counter = 0`) erhöhen. Code: `counter = counter + 1;`
+Obwohl der Code logisch aussieht, passiert auf Maschinenebene Folgendes:
+1. Thread A lädt Wert 0 in Register.
+2. Thread B lädt Wert 0 in Register (bevor A schreibt).
+3. A erhöht auf 1 und speichert.
+4. B erhöht (seine 0) auf 1 und speichert. → Ergebnis ist 1 statt 2. Ein Update ging verloren.
+## 3. Die Lösung: Der Kritische Bereich
+**Definition:** Der Programmteil, in dem auf den gemeinsam genutzten Speicher zugegriffen wird, nennt sich **Kritischer Bereich (Critical Section)**.
+### Die 4 zentralen Bedingungen für Synchronisation
+Um Race-Conditions zu verhindern, muss das Betriebssystem folgende Regeln garantieren:
+1. **Gegenseitiger Ausschluss (Mutual Exclusion):** Es dürfen sich niemals zwei Prozesse gleichzeitig im kritischen Bereich befinden.
+2. **Keine Annahmen:** Die Lösung darf nicht von der Geschwindigkeit der Prozesse oder der Anzahl der CPUs abhängen.
+3. **Keine Blockierung von außen:** Ein Prozess, der sich außerhalb seines kritischen Bereichs befindet, darf andere Prozesse nicht blockieren.
+4. **Kein ewiges Warten (No Starvation):** Jeder Prozess muss irgendwann die Chance bekommen, in den kritischen Bereich einzutreten.
+## 4. Mechanismus 1: Atomare Operationen
+Das Grundproblem ist, dass Hochsprachen-Befehle (wie `i++`) nicht atomar (unteilbar) sind. Sie bestehen aus mehreren CPU-Befehlen (Load, Increment, Store), die unterbrochen werden können.
+**Lösung auf Hardware-Ebene:** Prozessoren bieten spezielle Assembler-Instruktionen, die garantiert nicht unterbrochen werden können. Wären alle Befehle atomar, gäbe es keine Race-Conditions.
+**Wichtige Assembler-Befehle:**
+- **TSL (Test-and-Set-Lock):** Liest ein Byte aus dem Speicher in ein Register und schreibt im selben Taktzyklus einen neuen Wert (z.B. 1) an diese Stelle.
+- **FAA (Fetch-and-Add):** Inkrementiert einen Wert im Speicher atomar.
+- **CAS (Compare-and-Swap):** Vergleicht den Speicherinhalt mit einem Erwartungswert und tauscht ihn nur bei Übereinstimmung aus (Basis für lock-free Algorithmen).
+- **XCHG (Exchange):** Tauscht die Inhalte zweier Register oder Speicheradressen atomar.
+## 5. Mechanismus 2: Mutex (Mutual Exclusion)
+**Konzept:** Ein Mutex ist eine Technik und Datenstruktur, die als "Schloss" dient.
+- Nur der Thread, der den Mutex "besitzt" (lock), darf in den kritischen Bereich.
+- Nur der Besitzer kann den Mutex wieder freigeben (unlock).
+**Ablauf (Code-Schema):**
+```c
+pthread_mutex_lock(&m);   // Versuche Schloss zu holen. Wenn belegt -> Warten.
+/* KRITISCHER BEREICH (z.B. Schreiben in Datei) */
+pthread_mutex_unlock(&m); // Schloss freigeben.
+```
+### Verhalten bei belegtem Mutex
+Wenn Thread A den Mutex hat und Thread B ihn will, hat B drei Optionen:
+1. **Passives Warten:** B gibt die CPU ab und wird vom OS "schlafen gelegt" (blocked), bis der Mutex frei ist.
+2. **Aktives Warten (Spinlock):** B läuft in einer Schleife und prüft permanent („Ist frei? Ist frei?"). Sinnvoll nur bei sehr kurzen Wartezeiten auf Multi-Core-Systemen.
+3. **Timeout:** B bricht den Versuch nach einer Zeit ab.
+## 6. Mechanismus 3: Signale
+**Eigenschaften:** Signale sind ein sehr altes Konzept (Unix) und stellen eine Software-Unterbrechung (Interrupt) dar. Sie können an Prozesse oder Threads gesendet werden.
+**Funktionsweise:**
+- Wenn ein Signal empfangen wird, unterbricht der Prozess seine Arbeit sofort.
+- Entweder führt er eine ISR (Interrupt Service Routine) aus (benutzerdefiniert) oder die Standardaktion des Kernels (z.B. Prozess beenden).
+- **Signalmaske:** Jeder Thread kann definieren, welche Signale er blockieren/ignorieren möchte.
+**Wichtige POSIX-Funktionen:**
+- `pthread_kill()`: Sendet Signal an einen Thread (nicht zwingend tödlich, dient als Benachrichtigung).
+- `sigwait()`: Thread wartet passiv auf ein bestimmtes Signal.
+## 7. Mechanismus 4: Semaphore (nach Dijkstra)
+**Konzept:** Ein Semaphor ist mächtiger als ein Mutex. Er erlaubt den Zugriff einer vordefinierten Anzahl von Threads gleichzeitig.
+### Datenstruktur
+Ein Semaphor besteht aus zwei Elementen:
+1. Einem Zähler (Integer).
+2. Einer Warteschlange (Queue) für blockierte Threads.
+### Die zwei Operationen
+- **P() / wait():** Dekrementiert den Zähler.
+    - Ist der Zähler danach ≥ 0: Zugriff erlaubt.
+    - Ist der Zähler < 0 (bzw. war 0): Thread wird blockiert und in die Queue geschoben.
+- **V() / signal():** Inkrementiert den Zähler.
+    - Wenn Threads in der Queue warten, wird einer geweckt.
+### Unterschied zu Mutex
+- Ein Mutex muss vom Besitzer freigegeben werden. Ein Semaphor kann von jedem Thread inkrementiert (V) werden (Asynchrone Signalisierung).
+- Ein Semaphor mit Zähler = 1 (Binärer Semaphor) verhält sich wie ein Mutex.
+### Beispiel: Bahnhofsüberwachung (Performance-Begrenzung)
+**Szenario:** Es gibt viele Kameras, aber aus Performance-Gründen dürfen maximal 3 Such-Threads gleichzeitig Bilder analysieren.
+- **Initialisierung:** `Semaphore s = new Semaphore(3);`
+- **Thread startet:** `s.P()` (Zähler wird 2... dann 1... dann 0).
+- Der 4. Thread muss warten (Zähler bleibt 0, Thread in Queue).
+- **Thread fertig:** `s.V()` (Zähler wird 1, Wartender darf rein).
+## 8. Mechanismus 5: Monitore
+**Konzept:** Monitore sind ein Konstrukt auf höherer Abstraktionsebene (Sprachunterstützung). Ein Monitor ist ein gekapselter kritischer Bereich (z.B. eine Klasse oder Methode).
+**Eigenschaften:**
+- **Automatische Sicherheit:** Der Compiler garantiert, dass immer nur ein einziger Prozess/Thread gleichzeitig im Monitor aktiv ist.
+- Programmierer müssen Lock/Unlock nicht manuell schreiben → weniger fehleranfällig.
+**Implementierung in Java:**
+- Schlüsselwort: `synchronized`.
+- Kann auf Methoden (`synchronized void methode()`) oder Blöcke (`synchronized(this) { ... }`) angewendet werden.
+### Bedingte Synchronisation (Warten im Monitor)
+Oft muss ein Thread im Monitor warten, bis eine Bedingung erfüllt ist (z.B. Puffer nicht mehr leer). Dazu gibt es spezielle Methoden:
+- `wait()`: Thread legt sich schlafen und gibt den Monitor frei, damit andere eintreten können.
+- `notify()`: Weckt einen wartenden Thread (zufällig).
+- `notifyAll()`: Weckt alle wartenden Threads (sicherer, um Deadlocks zu vermeiden).
+## 9. Weitere Konzepte
+### Das volatile Primitiv
+- Kennzeichnet Variablen, die sich "außerhalb des Programmflusses" ändern können (z.B. durch Hardware oder andere Threads).
+- **Effekt:** Der Compiler schaltet Optimierungen ab und erzwingt bei jedem Zugriff ein Lesen aus dem Hauptspeicher (statt aus dem schnellen CPU-Cache).
+- **Achtung:** `volatile` garantiert Sichtbarkeit (Aktualität), aber keine Atomizität. Es ersetzt keinen Mutex bei komplexen Operationen.
+### Parallele Programmiersprachen
+Sprachen wie Occam, Ada oder Erlang besitzen eingebaute Kontrollstrukturen (z.B. `PAR` für parallele Ausführung oder Kanäle für Kommunikation), um Synchronisation direkt in der Syntax abzubilden, statt externe Bibliotheken zu nutzen.

Betriebssysteme/Zusammenfassung_Prozesse.md

@@ -0,0 +1,120 @@
+# Zusammenfassung: Prozesse und Threads
+
+## Der Prozess: Definition und Konzept
+1. **Bessere Definition:** „Ein Prozess ist eine Instanz eines ausgeführten Programms, einschließlich der aktuellen Werte des Programmzählers, der Register und Variablen.“ [4].
+2. **Umfassende Definition:** Ein Prozess ist der laufende Programmcode plus der Prozesskontext (alle Mittel und Parameter für die Ausführung) [5].
+### Der Unterschied zwischen Programm und Prozess
+Dieser Unterschied ist subtil, aber entscheidend. Ein Programm ist **passiv** (Code auf der Festplatte). Ein Prozess ist **aktiv** (Ressourcenzusammenfassung + Ausführung).
+- Ein Prozess führt ein Programm aus.
+- Viele Prozesse können dasselbe Programm ausführen. Jeder hat dabei seine eigene Instanz im eigenen Adressraum, völlig unabhängig von den anderen [6]
+### Der Prozesskontext
+Der Kontext umfasst alles, was die CPU zur Ausführung benötigt [5]:
+- Registerwerte der CPU.
+- Belegung des Caches (Befehle/Daten).
+- Belegung des Hauptspeichers (Code/Daten).
+- Benutzer- und Gruppenkennungen (IDs).
+- Seitentabellen (Memory Management).
+- Geöffnete Dateien.
+- Prioritäten und Zustandsinformationen.
+
+## Prozessverwaltung durch das Betriebssystem
+### Process Control Block (PCB)
+Das OS fasst alle Informationen eines Prozesses in einer Verwaltungsstruktur zusammen, dem PCB. Für jeden Prozess gibt es einen eigenen PCB. Die Gesamtheit aller PCBs bildet die Prozesstabelle [7].
+- Je komplexer das OS, desto größer der PCB.
+- Unter Linux ist die Struktur in `sched.h` definiert [8].
+### Ressourcennutzung (Code-Sharing)
+Da Prozesse Instanzen desselben Programms sein können, optimiert das OS den Speicher:
+- **Codesegment (CS):** Wird nur einmal geladen und von allen Instanzen geteilt (spart Speicher und Zeit).
+- **Datensegment (DS) & Stapel (SS):** Jeder Prozess erhält seine eigene Kopie.
+- **Instruction Pointer (IP):** Jeder Prozess hat einen eigenen Zeiger, wo er sich im Code gerade befindet. So können Prozesse denselben Code an unterschiedlichen Stellen ausführen, ohne sich zu stören [8], [9].
+### Hierarchie
+Prozesse sind hierarchisch organisiert. Ein Elternprozess (_Parent_) erstellt einen Kindprozess (_Child_). Das Kind erbt Attribute vom Elternteil. Jeder Prozess kennt seine eigene ID (**PID**) und die des Elternprozesses (**PPID**) [10].
+## Lebenszyklus eines Prozesses
+Ein Prozess durchläuft verschiedene Phasen [11]:
+1. Erstellung.
+2. Ausführung auf dem Prozessor.
+3. Anforderung von Ressourcen (Warten auf Zuweisung).
+4. Warten auf Ergebnisse anderer Prozesse.
+5. Erhalt einer Zeitscheibe (Quantum).
+6. Warten auf die nächste Zeitscheibe (nach Entzug der CPU).
+7. Beendigung.
+### Wichtige Zustände (States)
+Nicht zu verwechseln mit den Phasen, gibt es drei Hauptzustände in der Warteschlange [12]:
+- **Bereit (Ready):** Wartet auf Zuteilung der CPU.
+- **Rechnend (Running):** Führt Code aus.
+- **Blockiert (Waiting):** Wartet auf ein Ereignis (z.B. I/O), CPU wurde entzogen.
+### Kontextwechsel (Context Switch)
+Der Wechsel von Prozess A zu Prozess B erfordert das Speichern des Zustands von A im PCB-A und das Laden von B aus PCB-B.
+- Dies ist sehr zeitaufwändig.
+- Hardware-Unterstützung (mehrere Registersätze) kann dies beschleunigen [13], [14].
+### Prozessbeendigung
+Ein Prozess kann auf drei Arten enden [15]:
+1. **Normal:** Geplantes Ende (letzte Anweisung, `return`).
+2. **Fehler:** Ungeplant (Nulldivision, Datei fehlt, Speicherfehler).
+3. **Kill:** Befehl von außen (z.B. `kill -9 PID` unter Linux) [16].
+**Probleme bei der Beendigung:**
+- **Speicherlecks:** Wenn `malloc` genutzt wurde, aber kein `free`, bleibt Speicher belegt. Moderne Sprachen (Java, Go) nutzen Garbage Collection
+- **Zombies:** Ein Prozess ist beendet, aber der Elternprozess hat den Status nicht abgefragt. Er bleibt als "Leiche" in der Tabelle
+## Prozesserstellung: Linux vs. Windows
+### Linux (`fork` & `exec`)
+Das Verfahren ist zweistufig und sehr flexibel:
+1. **`fork()`:** Erzeugt eine exakte Kopie des Elternprozesses.
+    - Der neue Prozess (Kind) beginnt an der gleichen Stelle (nach dem fork).
+    - **Unterscheidung durch Rückgabewert:**
+        - `0`: Ich bin das Kind.
+        - `PID > 0`: Ich bin der Elternprozess (Wert ist die PID des Kindes).
+        - `-1`: Fehler.
+2. **`exec()` (optional):** Lädt ein neues Programm in den Speicher des Kindprozesses und überschreibt den alten Code.
+### Windows
+Nutzt den Systemaufruf `CreateProcess()`.
+## Threads
+**Definition:** Ein Thread ist ein sequenzieller Kontrollfluss innerhalb eines Prozesses. Ein Prozess kann mehrere Threads haben, die parallel ausgeführt werden. Threads dienen dazu, die Programmausführung zu beschleunigen und Aufgaben zu parallelisieren (z.B. Rechnen vs. E/A).
+### Ressourcenteilung
+Threads und Prozesse sind unterschiedliche Konzepte. Der Prozess dient der Ressourcengruppierung, der Thread ist die Einheit der Ausführung auf der CPU.
+
+|**Gemeinsam genutzt (Shared)**|**Privat pro Thread (Private)**|
+|---|---|
+|Adressraum im Speicher|Program Counter (PC/IP)|
+|Globale Variablen|Stack (Stapel)|
+|Geöffnete Dateien|CPU-Register|
+|Untergeordnete Prozesse|Zustand & Priorität|
+|Benutzer-/Gruppen-ID|Signale (teils)|
+|IPC-Mittel||
+
+**Vorteile von Threads:**
+- Erstellung ist 10- bis 100-mal schneller als bei Prozessen.
+- Einfacher Zugriff auf gemeinsame Daten (kein komplexes IPC nötig).
+- Echte Parallelität auf Multi-Core-Systemen [24].
+## Thread-Modelle: User vs. Kernel
+### A. User-Threads (Benutzer-Ebene)
+Das Betriebssystem weiß nichts von diesen Threads. Sie werden von einer Bibliothek (Runtime System) im User-Space verwaltet.
+- **Vorteile:**
+    - Keine Kernel-Aufrufe nötig (schnell).
+    - Verwaltung rein lokal im Prozessspeicher.
+    - Eigenes Scheduling möglich [28].
+- **Nachteile:**
+    - **Blockierung:** Wenn ein Thread einen blockierenden Systemaufruf macht (z.B. Warten auf Tastatur), blockiert der gesamte Prozess (alle Threads stehen).
+### B. Kernel-Threads (Betriebssystem-Ebene)
+Das Betriebssystem kennt und verwaltet die Threads direkt.
+- **Vorteile:**
+    - Wenn ein Thread blockiert, laufen andere weiter.
+    - Echte parallele Verteilung auf mehrere CPUs [30].
+- **Nachteile:**
+    - Langsamer (Systemaufrufe nötig für Erstellung/Wechsel).
+    - Belegt mehr Speicher im Kernel [30], [31].
+### C. Mapping (Die Verbindung)
+Es muss eine Beziehung zwischen User- und Kernel-Threads geben [32], [33]:
+- **Many-to-One:** Viele User-Threads auf einen Kernel-Thread (wie reines User-Threading).
+- **One-to-One:** Jeder User-Thread hat einen Kernel-Thread (WinAPI, Linux Pthreads).
+- **Many-to-Many:** Hybridansatz.
+## Programmierung und Standards
+POSIX Pthreads (IEEE 1003.1c):
+Der Standard für Unix/Linux.
+- **Bibliothek:** `pthread`
+- **Funktionen:** `pthread_create`, `pthread_join` (warten auf Ende).
+WinAPI Threads:
+Der Standard für Windows.
+- **Funktionen:** `CreateThread`, `WaitForSingleObject` (statt join), `CloseHandle`.
+**Java & Go:**
+- **Java:** Threads werden vom Runtime-System verwaltet (früher User-Threads, heute oft Mapping auf Kernel-Threads). Klasse `Thread` oder Interface `Runnable`. Starten mit `.start()` (ruft `.run()` auf) [33].
+- **Go:** „Goroutinen“ (`go function()`). Sehr leichtgewichtig, vom Go-Runtime-System verwaltet [38], [39].

Betriebssysteme/Zusammenfassung_Scheduling.md

@@ -0,0 +1,121 @@
+# Zusammenfassung: Scheduling
+## 1. Grundlagen und Definitionen
+**Was ist Scheduling?** Scheduling ist die Strategie und Methode, mit der das Betriebssystem die verfügbare Prozessorzeit (CPU-Zeit) auf die verschiedenen lauffähigen Prozesse oder Threads verteilt.
+### Die drei Arten des Schedulings
+1. **Kurzfristiges Scheduling (Short-Term / CPU-Scheduling):** Die Entscheidung, welcher Prozess als nächstes die CPU bekommt. (Dies ist der Fokus dieser Zusammenfassung)
+2. **Mittelfristiges Scheduling:** Verwaltung des Arbeitsspeichers (Swapping, Prozess auslagern).
+3. **Langfristiges Scheduling:** Entscheidung, welche Aufgaben (Jobs) überhaupt ins System zugelassen werden (Job-Queue).
+### Wichtige Komponenten
+- **Scheduler:** Die „Logik". Er entscheidet basierend auf einem Algorithmus, welcher Prozess als nächstes laufen darf.
+- **Dispatcher:** Der „Mechaniker". Er führt den tatsächlichen Kontextwechsel durch. Er stoppt den alten Prozess, sichert den Status, lädt den neuen Status und übergibt die Kontrolle an die CPU.
+    - **Dispatch-Latenz:** Die Zeit, die der Dispatcher für das Umschalten braucht. Diese Zeit ist „Verlust" (Overhead) und sollte so gering wie möglich sein.
+## 2. Prozess-Verhalten: Bursts
+Prozesse arbeiten nicht linear. Sie wechseln ständig zwischen zwei Phasen:
+1. **CPU-Burst:** Der Prozess rechnet aktiv (nutzt die CPU).
+2. **E/A-Burst (I/O-Burst):** Der Prozess wartet auf Daten (Festplatte, Netzwerk, Tastatur) und nutzt die CPU nicht.
+### Unterscheidung der Prozess-Typen
+- **CPU-gebunden (CPU-bound):** Lange CPU-Bursts, seltenes Warten. (Beispiel: Videorendering, Simulationen)
+- **E/A-gebunden (I/O-bound):** Kurze CPU-Bursts, häufiges Warten. (Beispiel: Texteditor, Webbrowser)
+- **Ziel:** Ein guter Scheduler mischt diese Typen, um die Hardware optimal auszulasten.
+## 3. Wann wird geschedult?
+Der Scheduler muss in vier Situationen aktiv werden:
+1. **Neuer Prozess:** Ein Programm wird gestartet.
+2. **Prozessende:** Ein Prozess ist fertig.
+3. **Blockierung:** Ein Prozess wartet auf E/A oder einen Semaphor/Mutex.
+4. **Interrupt (nur bei Präemption):** Ein Hardware-Timer (Clock-Interrupt) unterbricht den laufenden Prozess.
+## 4. Ziele des Schedulings
+Die Ziele hängen stark von der Art des Systems ab. Es gibt oft Konflikte (z.B. Fairness vs. Effizienz).
+### Allgemeine Ziele
+- **Fairness:** Jeder Prozess erhält einen gerechten Anteil der CPU (Mindestzuteilung).
+- **Effizienz:** Die CPU soll immer zu 100% beschäftigt sein (kein Leerlauf).
+- **Balance:** Alle Systemteile (CPU, Disk, RAM) sollen ausgelastet sein.
+- **Policy Enforcement:** Durchsetzung von Regeln (z.B. „Chef-Prozesse haben Vorrang").
+### Spezifische Ziele nach Modus
+**Batch-Systeme (Stapelverarbeitung):**
+- Maximierung des Durchsatzes (Jobs pro Stunde).
+- Minimierung der Durchlaufzeit (Zeit von Abgabe bis Fertigstellung).
+**Interaktive Systeme (PC/Server):**
+- Minimierung der Antwortzeit (Zeit bis zur ersten Reaktion auf eine Eingabe).
+- Minimierung der Wartezeit in der "Bereit"-Schlange.
+**Echtzeitsysteme:**
+- Einhaltung von Deadlines (Fristen).
+- Vorhersagbarkeit (kein Datenverlust durch Verzögerung).
+## 5. Algorithmen-Konzepte: Präemptiv vs. Nicht-Präemptiv
+### A. Nicht-Präemptiv (Kooperativ)
+- Ein Prozess behält die CPU, bis er fertig ist, blockiert (I/O) oder sie freiwillig abgibt.
+- **Vorteil:** Einfach, keine Timer-Hardware nötig.
+- **Nachteil:** Ein Endlos-Schleifen-Prozess kann das ganze System einfrieren (Windows 3.1 Ära).
+### B. Präemptiv (Verdrängend)
+- Das OS kann einem Prozess die CPU gewaltsam entziehen.
+- Benötigt Clock-Interrupts.
+- Jeder Prozess erhält ein Zeitquantum (Zeitscheibe, typisch 10–200 ms).
+- **Faustregel:** Verhältnis Kontextwechsel zu Quantum sollte ca. 1:20 bis 1:50 betragen, um Overhead gering zu halten.
+## 6. Die Scheduling-Algorithmen im Detail
+### 6.1 FCFS (First Come First Serve)
+- **Prinzip:** „Wer zuerst kommt, mahlt zuerst". Einfache Warteschlange (FIFO).
+- **Typ:** Nicht-präemptiv.
+- **Vorteil:** Sehr einfach zu implementieren.
+- **Nachteil:** Konvoi-Effekt. Ein langer CPU-Prozess blockiert alle kurzen E/A-Prozesse. Führt zu schlechter Durchschnitts-Wartezeit.
+### 6.2 SJF (Shortest Job First)
+- **Prinzip:** Der Prozess mit dem kürzesten CPU-Burst wird als nächstes gewählt.
+- **Typ:** Nicht-präemptiv.
+- **Vorteil:** Garantiert die beste (minimale) durchschnittliche Wartezeit aller Verfahren.
+- **Nachteil:** Die Laufzeit muss im Voraus bekannt sein (schwierig bei interaktiven Systemen). Gefahr von Starvation (Verhungern) langer Jobs, wenn immer neue kurze Jobs kommen.
+### 6.3 SRTN (Shortest Remaining Time Next)
+- **Prinzip:** Die präemptive Version von SJF. Wenn ein neuer Job kommt, dessen Laufzeit kürzer ist als der Rest des aktuellen Jobs, wird gewechselt.
+- **Vorteil:** Sehr gut für kurze Jobs geeignet.
+- **Nachteil:** Laufzeit muss bekannt sein; Overhead durch Überwachung der Restzeiten.
+### 6.4 RR (Round Robin)
+- **Prinzip:** Jeder Prozess bekommt die CPU für ein festes Zeitquantum (z.B. 20ms). Ist er nicht fertig, kommt er ans Ende der Schlange.
+- **Typ:** Präemptiv.
+- **Vorteil:** Der fairste Algorithmus. Keine Starvation. Gute Antwortzeit für Benutzer.
+- **Nachteil:** Durchschnittliche Durchlaufzeit oft schlechter als SJF.
+**Das Quantum-Problem:**
+- **Zu groß:** RR verhält sich wie FCFS (schlechte Reaktion).
+- **Zu klein:** Zu viele Kontextwechsel (CPU verbringt nur Zeit mit Umschalten, nicht mit Rechnen).
+## 7. Prioritätsmechanismen
+Priorität ist kein eigener Algorithmus, sondern ein Aufsatz auf andere (z.B. Priority-Queue statt FIFO).
+### Hierarchie (Wer hat Vorrang?)
+1. Kernel (Höchste Prio).
+2. OS-Dienste / Treiber.
+3. Interrupts.
+4. GUI / Interaktive Apps.
+5. Hintergrunddienste.
+### Problem Starvation & Lösungen
+Wenn Prozesse mit hoher Priorität die CPU monopolisieren, verhungern niedrige Prozesse.
+- **Aging (Altern):** Die Priorität wartender Prozesse wird schrittweise erhöht.
+- **Dynamische Anpassung:** Das OS beobachtet das Verhalten (z.B. Gauß-Methode oder Lotterie-Scheduling) und passt Prioritäten zur Laufzeit an.
+## 8. Echtzeit-Modus (Real-Time)
+Hier zählt nicht Geschwindigkeit, sondern Vorhersagbarkeit.
+- **Harte Echtzeit:** Deadline muss gehalten werden (z.B. Airbag-Auslösung). Verspätung = Systemversagen.
+- **Weiche Echtzeit:** Verspätung ist tolerierbar, aber Qualität sinkt (z.B. Video-Stream ruckelt).
+- **Bedingung:** Das System ist nur planbar, wenn die Summe aller Prozess-Laufzeiten kleiner ist als die verfügbare CPU-Zeit.
+## 9. Das große Rechenbeispiel (Klausur-relevant!)
+Die Quelle vergleicht Algorithmen anhand von 5 Prozessen. Dies zeigt die Unterschiede in der Durchlaufzeit (Turnaround Time).
+### Szenario
+- **Prozesse:** A (Länge 12), B (6), C (7), D (2), E (9).
+- **Prioritäten (0=hoch):** C(1), B(2), E(3), A(4), D(5). (Achtung: D hat niedrigste Prio!)
+### A. FCFS (Reihenfolge A, B, C, D, E)
+- A wartet 0, läuft 12 → Ende bei 12.
+- B wartet auf A (12), läuft 6 → Ende bei 18.
+- C endet bei 25.
+- D endet bei 27.
+- E endet bei 36.
+- **Durchschnitt:** (12+18+25+27+36)/5 = **23,6**
+### B. SJF (Sortiert nach Länge: D, B, C, E, A)
+- D (2) läuft zuerst → Ende bei 2.
+- B (6) startet bei 2 → Ende bei 8.
+- C (7) startet bei 8 → Ende bei 15.
+- E (9) startet bei 15 → Ende bei 24.
+- A (12) startet bei 24 → Ende bei 36.
+- **Durchschnitt:** (2+8+15+24+36)/5 = **17**
+- **Fazit:** SJF ist der beste für den Durchsatz, aber unfair für A.
+### C. Round Robin mit Priorität (Hier als Beispiel für "Worst Case")
+- Im Beispiel führt dies zu vielen Wechseln und einer durchschnittlichen Zeit von 25,4.
+- **Fazit:** RR ist der schlechteste für die Durchlaufzeit, aber der fairste Algorithmus.
+## 10. Zusammenfassende Erkenntnisse für MC-Fragen
+1. **Dispatcher vs. Scheduler:** Scheduler plant, Dispatcher schaltet.
+2. **SJF:** Beste Performance, aber Gefahr von Starvation und schwer vorhersagbar.
+3. **Round Robin:** Beste Fairness, Nutzung in interaktiven Systemen, abhängig vom Quantum.
+4. **Batch vs. Interaktiv:** Batch will Durchsatz, Interaktiv will kurze Antwortzeiten.
+5. **1:20 bis 1:50:** Das goldene Verhältnis von Overhead (Kontextwechsel) zu Nutzlast (Quantum).

Betriebssysteme/Zusammenfassung_Speicherverwaltung.md

@@ -0,0 +1,140 @@
+# Zusammenfassung: Speicherverwaltung
+## 1. Einführung: Die Direkte Speicherverwaltung
+Die einfachste und historisch älteste Form der Speicherverwaltung ist die direkte Verwaltung.
+- **Grundprinzip:** Alle Adressen, die im Programmcode stehen, entsprechen direkt den physikalischen Adressen im Hauptspeicher (RAM). Es gibt keine Übersetzungsschicht.
+- **Beispiel:** Der Assembler-Befehl `mov AX, 42` bedeutet, dass der Prozessor direkt auf die physikalische Speicherzelle Nr. 42 zugreift und deren Inhalt in das Register AX lädt.
+### Historische Speichertypen
+Frühere Computer unterschieden strikt zwei Arten von Speicher:
+1. **ROM (Read-Only-Memory):** Ein kleiner Speicher (ca. 64 KiB), der nicht überschrieben werden konnte. Er enthielt Boot-Funktionen, Treiber und Teile des Betriebssystems.
+2. **RAM (Random-Access-Memory):** Der große Arbeitsspeicher für das Betriebssystem und die Benutzerprogramme.
+### Organisation
+Wenn nur ein einziges Benutzerprogramm und das Betriebssystem (OS) im Speicher sind, gab es drei Organisationsformen:
+1. OS im RAM (unten), Benutzerprogramm darüber.
+2. OS im ROM (oben), Benutzerprogramm im RAM.
+3. Treiber im ROM, OS und Benutzerprogramm im RAM.
+### Nachteile der direkten Verwaltung
+Dieses Modell stößt schnell an Grenzen:
+1. **Mangelnder Schutz:** Ein Programm kann versehentlich das Betriebssystem oder andere Programme beschädigen, da es Zugriff auf jedes physikalische Byte hat.
+2. **Kein echtes Multitasking:** Es ist fast unmöglich, mehrere Programme gleichzeitig laufen zu lassen. Wenn zwei Programme hartkodierte Adressen nutzen (z.B. beide wollen an Adresse 1000 starten), können sie nicht gleichzeitig im Speicher liegen.
+3. **Größenbeschränkung:** Das gesamte Programm muss vollständig in den physikalischen Speicher passen ("The whole program must be presented in memory").
+## 2. Die erste Lösung: Adressräume & Swapping
+Um die Probleme der direkten Verwaltung zu lösen, wurden Adressräume eingeführt. Ein Adressraum ist die Menge aller Adressen, die ein Prozess verwenden darf. Jeder Prozess erhält seinen eigenen, isolierten Raum.
+### Hardware-Unterstützung (Basis & Limit)
+Der Prozessor nutzt zwei spezielle Register zur Verwaltung:
+1. **Basisregister:** Enthält die physikalische Startadresse des Programms.
+2. **Grenzwertregister (Limit):** Enthält die Gesamtlänge des Programms.
+- **Berechnung:** Die effektive physikalische Adresse = Programmadresse + Basisregister.
+- **Schutz:** Die Hardware prüft bei jedem Zugriff: Effektive Adresse ≤ Basis + Limit. Ist dies nicht der Fall, wird der Zugriff verweigert (Schutzverletzung).
+### Das Konzept des Swapping (Auslagerung)
+Da der Arbeitsspeicher selten groß genug ist, um alle Prozesse gleichzeitig vollständig zu halten, nutzt das OS "Swapping".
+- **Vorgang:** Wenn der Platz knapp wird, wird ein inaktiver Prozess komplett auf die Festplatte geschrieben (ausgelagert) und ein anderer Prozess komplett in den Speicher geladen.
+- **Problem der Fragmentierung:** Durch das ständige Ein- und Auslagern entstehen ungenutzte Lücken ("Löcher") zwischen den Prozessen. Der Speicher zerstückelt.
+- **Lösung:** Das OS muss den Speicher defragmentieren (komprimieren), was jedoch sehr rechenaufwändig ist.
+### Speicherzuweisungs-Algorithmen (Allocation Algorithms)
+Wenn ein neuer Prozess geladen werden soll, muss das OS eine passende Lücke im RAM finden. Hierfür gibt es fünf klassische Strategien:
+1. **First Fit:** Wählt die erste Lücke, die groß genug ist. Schnell, aber fragmentiert den Speicher vorne.
+2. **Next Fit:** Beginnt die Suche dort, wo die letzte Zuweisung endete.
+3. **Best Fit:** Sucht die kleinste Lücke, die gerade so ausreicht. Nachteil: Hinterlässt winzige, nutzlose Rest-Lücken.
+4. **Worst Fit:** Wählt die größte verfügbare Lücke. Idee: Der Rest ist groß genug für weitere Prozesse.
+5. **Quick Fit:** Hält separate Listen für häufig benötigte Lückengrößen bereit.
+## 3. Virtuelle Speicherverwaltung (Paging)
+Das ist der Standard in allen modernen Systemen (Windows, Linux, Android, macOS). Es entkoppelt die Sicht des Programms von der physikalischen Realität.
+### Kernkonzepte
+- **Virtueller Speicher:** Das Programm "sieht" einen perfekten, linearen Speicher, der in Pages (Seiten) unterteilt ist.
+- **Physischer Speicher:** Der RAM ist in Frames (Seitenrahmen) unterteilt.
+- **Mapping:** Es gilt immer: Größe Frame = Größe Page (Standard ist oft 4 KiB).
+- **Vorteil:** Ein Programm kann größer sein als der physikalische Speicher. Die Seiten müssen nicht zusammenhängend im RAM liegen.
+### MMU (Memory Management Unit)
+Die MMU ist ein Hardware-Baustein direkt auf dem Prozessor-Chip.
+- **Aufgabe:** Sie übersetzt bei jedem Speicherzugriff die virtuelle Adresse in eine physikalische Adresse.
+- **Richtung:** Immer Virtuell → Physikalisch (niemals umgekehrt!).
+### Berechnung der optimalen Seitengröße
+Die Wahl der Seitengröße ist ein Kompromiss.
+- **Kleine Seiten:** Weniger Verschnitt (interne Fragmentierung), aber riesige Verwaltungstabellen.
+- **Große Seiten:** Kleine Tabellen, aber viel ungenutzter Platz am Ende der letzten Seite.
+- **Formel:** p = √(2 · s · e)
+    - p: Seitengröße
+    - s: Durchschnittliche Prozessgröße
+    - e: Größe eines Seitentabellen-Eintrags
+    - Beispiel: Bei 1 MiB Programmgröße und 8 Byte Eintrag ergibt sich mathematisch eine optimale Größe von 4 KiB.
+## 4. Datenstrukturen: Seitentabellen & TLB
+### Die Seitentabelle (Page Table)
+Jeder Prozess besitzt eine eigene Seitentabelle im RAM. Sie dient der MMU als Nachschlagewerk. Ein Eintrag in dieser Tabelle (typisch 32 Bit / 4 Byte) enthält komplexe Statusinformationen:
+1. **Rahmennummer:** Die eigentliche physikalische Adresse im RAM (wo liegt die Seite?).
+2. **Present/Absent Bit (P):**
+    - 1: Seite ist im RAM (Zugriff okay).
+    - 0: Seite ist nicht im RAM (löst Seitenfehler / Page Fault aus).
+3. **Modified Bit (M) / Dirty Bit:**
+    - 1: Die Seite wurde verändert (geschrieben). Sie muss beim Entfernen auf die Festplatte zurückgesichert werden.
+    - 0: Seite ist sauber (identisch mit der Festplatte), kann einfach überschrieben werden.
+4. **Referenced Bit (R):**
+    - 1: Seite wurde kürzlich gelesen oder beschrieben. Wichtig für Ersetzungs-Algorithmen. Das OS setzt dieses Bit periodisch auf 0 zurück.
+5. **Schutz-Bits (RWX):** Definieren Rechte (Read, Write, Execute).
+
+### Das Problem der Größe
+Da jeder Prozess eine Tabelle braucht, kann dies viel Speicher kosten. Bei 32-Bit oder 64-Bit Systemen können Tabellen mehrere Megabyte groß werden (z.B. 4 MiB).
+- **Lösung:** Mehrstufige Seitentabellen (Paged Page Tables).
+### TLB (Translation Lookaside Buffer)
+Da ein Zugriff auf die Seitentabelle im RAM langsam ist (Verdopplung der Zugriffszeit: 1x Tabelle lesen, 1x Daten lesen), nutzt die MMU einen Hardware-Cache namens TLB.
+- Der TLB speichert die häufigsten Übersetzungen.
+- Die MMU prüft zuerst den TLB. Nur bei einem "Miss" greift sie auf die langsame Tabelle im RAM zu.
+## 5. Seitenersetzungs-Algorithmen (Page Replacement)
+Wenn der physikalische Speicher voll ist und eine neue Seite geladen werden muss (Demand Paging), muss eine alte Seite weichen ("Opfer"). Welcher Algorithmus trifft diese Entscheidung?
+### A. NRU (Not Recently Used)
+Klassifiziert Seiten anhand der R- und M-Bits in 4 Klassen:
+- **Klasse 0:** Nicht referenziert, nicht modifiziert. (Bestes Opfer).
+- **Klasse 1:** Nicht referenziert, modifiziert.
+- **Klasse 2:** Referenziert, nicht modifiziert.
+- **Klasse 3:** Referenziert, modifiziert. (Schlechtes Opfer, wird oft gebraucht).
+**Strategie:** Löscht zufällig eine Seite aus der niedrigsten vorhandenen Klasse. Einfach, aber mäßig effizient.
+### B. FIFO (First-In-First-Out)
+- **Strategie:** Führt eine Liste aller Seiten. Die älteste (zuerst geladene) Seite fliegt raus.
+- **Nachteil:** Die älteste Seite kann eine wichtige Kernel-Bibliothek sein, die ständig benötigt wird. FIFO ist daher in Reinform ineffizient.
+### C. Second Chance (SC)
+Eine Verbesserung von FIFO. Prüft das R-Bit der ältesten Seite:
+- **R=0:** Seite ist alt und unbenutzt → Raus.
+- **R=1:** Seite ist alt, aber aktiv → R-Bit löschen, Seite ans Ende der Liste verschieben (wie neu geladen). Sie erhält eine "zweite Chance".
+### D. Clock (Uhr-Algorithmus)
+- Eine effizientere Implementierung von Second Chance mittels einer zirkulären Liste (wie ein Zifferblatt).
+- Ein Zeiger dreht sich im Kreis. Trifft er auf R=1, setzt er es auf 0 und geht weiter. Trifft er auf R=0, wird die Seite ersetzt.
+### E. LRU (Least Recently Used)
+- **Idee:** Die Vergangenheit sagt die Zukunft voraus. Seiten, die lange nicht genutzt wurden, werden wohl auch bald nicht gebraucht.
+- **Implementierung:** Theoretisch bräuchte man einen Zeitstempel bei jedem Zugriff (zu teuer).
+- **Praxis:** Hardware-Zähler in der Seitentabelle oder Matrix-Methoden. Gilt als einer der besten Algorithmen.
+### F. Working Set (WS)
+- Definiert eine "Arbeitsmenge" an Seiten, die ein Prozess in einem Zeitfenster τ (z.B. 100ms) benötigt hat.
+- **Strategie:** Entferne nur Seiten, die nicht zum aktuellen Working Set gehören. Verhindert "Thrashing" (das System ist nur noch mit Auslagern beschäftigt).
+## 6. Der Ablauf eines Seitenfehlers (Page Fault)
+Was passiert im Detail, wenn ein Prozess auf eine Adresse zugreift, deren Present-Bit 0 ist? Dies ist ein komplexer Vorgang in 11 Schritten:
+1. **Trap:** Die Hardware bemerkt den Fehler. Ein Interrupt wird ausgelöst, der Programmzähler (PC) wird im Stack gesichert. Der Modus wechselt zu Kernel-Mode.
+2. **Sichern:** Alle flüchtigen Informationen (Register) werden gespeichert.
+3. **Identifikation:** Das OS ermittelt, welche virtuelle Adresse den Fehler verursacht hat (steht oft in einem Spezialregister der CPU).
+4. **Validierung:** Das OS prüft: Ist die Adresse überhaupt gültig? Hat der Prozess Rechte dafür? Falls nein → Prozess-Abbruch (Segmentation Fault).
+5. **Rahmensuche:** Das OS sucht einen freien physikalischen Rahmen. Falls keiner frei ist, muss der Seitenersetzungsalgorithmus (siehe Punkt 5) ausgeführt werden, um Platz zu schaffen.
+6. **Auslagern (Eviction):** Wenn die "Opfer-Seite" modifiziert war (M=1), muss sie erst auf die Festplatte geschrieben werden.
+7. **Kontextwechsel:** Da Festplattenzugriffe langsam sind, wird der aktuelle Prozess blockiert und ein anderer Prozess darf solange rechnen (CPU-Nutzung optimieren).
+8. **Laden:** Die eigentlich angeforderte Seite wird nun von der Festplatte in den freien Rahmen geladen.
+9. **Update:** Die Seitentabelle wird aktualisiert: Rahmennummer eintragen, Present-Bit auf 1 setzen.
+10. **Wiederherstellung (Restore):** Die gesicherten Register des Prozesses werden wiederhergestellt. Der Programmzähler wird auf den Befehl zurückgesetzt, der den Fehler verursachte.
+11. **Fortsetzung:** Der Befehl wird erneut ausgeführt – diesmal erfolgreich, da die Seite nun im RAM ist.
+## 7. Segmente & Speicherschutz
+Ein moderner Prozess-Adressraum ist nicht homogen, sondern in logische Segmente unterteilt, die unterschiedliche Rechte (Schutz-Bits) haben:
+1. **Code-Segment (Text):** Enthält die Maschinenbefehle.
+    - Rechte: Nur Lesen und Ausführen (r-x). Schreiben ist verboten (verhindert selbst-modifizierenden Code).
+2. **Daten-Segment:** Enthält globale Variablen.
+    - Rechte: Lesen und Schreiben (rw-). Ausführen verboten (Schutz vor Buffer-Overflow-Exploits).
+3. **Stack-Segment:** Für lokale Variablen und Funktionsaufrufe. (rw-).
+4. **Heap-Segment:** Für dynamisch angeforderten Speicher (malloc / new). (rw-).
+### Segmentation Fault
+Ein "Segfault" tritt auf, wenn ein Programm versucht, auf eine Adresse zuzugreifen, für die es keine Rechte hat (z.B. Schreiben in Code-Segment) oder die nicht existiert (z.B. Dereferenzierung eines Null-Zeigers).
+## 8. Vergleich: Swapping vs. Paging
+
+|Merkmal|Swapping (Veraltet)|Paging (Modern)|
+|---|---|---|
+|**Einheit**|Ganzer Prozess wird verschoben.|Einzelne Seiten (Teile) werden verschoben.|
+|**Speicherart**|Nur bei direkter Speicherverwaltung nötig.|Nur bei virtueller Speicherverwaltung.|
+|**Effizienz**|Gering (große Datenmengen, Fragmentierung).|Hoch (feingranular, nur benötigte Teile).|
+|**Hardware**|Benötigt Basis-/Limit-Register.|Benötigt MMU und Seitentabellen.|
+
+### Demand Paging
+Moderne Systeme laden Seiten nicht im Voraus ("Prefetching"), sondern strikt nach Bedarf ("Demand"). Eine Seite wird erst geladen, wenn ein Page Fault auftritt. Das spart Speicher und I/O-Bandbreite.

Dashboard.md

@@ -0,0 +1,25 @@
+# 📊 Studium Dashboard
+
+> Letzte Aktualisierung: `2026-03-19`
+
+---
+
+## Fortschritt Übersicht
+
+| Modul                                      | Vorlesungen | Folien | Zusammenfassungen | NotebookLM | Status |
+| ------------------------------------------ | ----------- | ------ | ----------------- | ---------- | ------ |
+| [[Kryptografie/_Overview\|Kryptografie]]   | 6           | 5/6    | 5/6               | 5/6        | 🟡     |
+| [[Netzwerke/_Overview\|Netzwerke]]         | 11          | 4/11   | 4/11              | 4/11       | 🟡     |
+| [[IT-Sicherheit/_Overview\|IT-Sicherheit]] | 10          | 5/10   | 5/10              | 5/10       | 🟡     |
+
+**Legende:** 🔴 Nicht begonnen · 🟡 In Arbeit · 🟢 Abgeschlossen
+
+---
+
+## Workflow
+
+1. **Folien erhalten** → Vorlesung besucht, Folien gesichert
+2. **Zusammenfassung** → Folien an Claude schicken, Markdown speichern
+3. **NotebookLM** → Zusammenfassung hochladen
+4. **Lernkarten** → Quiz und Karten in NotebookLM erstellen
+5. **Durchgearbeitet** → Karten gelernt, Thema sitzt

Datenbanken/Klausur/Zimmi Hinweise.md

@@ -0,0 +1,4 @@
+# Klausurhinweise
+
+- Views und Inline-Views in SQL Code erkennen und unterscheiden können
+- Constraints kommen 100%

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**.

Digitaltechnik/1aus8Decoder.circ

@@ -0,0 +1,285 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+  This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+
+  <lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4">
+    <tool name="ROM">
+      <a name="contents">addr/data: 8 8
+0
+</a>
+    </tool>
+  </lib>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <appear>
+      <path d="M61,51 Q65,61 69,51" fill="none" stroke="#808080" stroke-width="2"/>
+      <rect fill="none" height="30" stroke="#000000" stroke-width="2" width="30" x="50" y="50"/>
+      <circ-anchor facing="east" height="6" width="6" x="47" y="47"/>
+    </appear>
+  </circuit>
+  <circuit name="1aus8Decoder">
+    <a name="circuit" val="1aus8Decoder"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <wire from="(400,750)" to="(400,820)"/>
+    <wire from="(400,610)" to="(400,680)"/>
+    <wire from="(400,470)" to="(400,540)"/>
+    <wire from="(400,330)" to="(400,400)"/>
+    <wire from="(290,460)" to="(290,530)"/>
+    <wire from="(290,320)" to="(290,390)"/>
+    <wire from="(140,670)" to="(140,740)"/>
+    <wire from="(200,870)" to="(260,870)"/>
+    <wire from="(200,910)" to="(260,910)"/>
+    <wire from="(350,570)" to="(350,710)"/>
+    <wire from="(350,430)" to="(350,570)"/>
+    <wire from="(350,290)" to="(350,430)"/>
+    <wire from="(160,200)" to="(210,200)"/>
+    <wire from="(430,310)" to="(430,320)"/>
+    <wire from="(240,240)" to="(290,240)"/>
+    <wire from="(260,940)" to="(260,950)"/>
+    <wire from="(180,500)" to="(180,640)"/>
+    <wire from="(180,360)" to="(180,500)"/>
+    <wire from="(180,640)" to="(180,780)"/>
+    <wire from="(160,510)" to="(160,720)"/>
+    <wire from="(290,240)" to="(290,320)"/>
+    <wire from="(320,650)" to="(430,650)"/>
+    <wire from="(320,590)" to="(430,590)"/>
+    <wire from="(320,370)" to="(430,370)"/>
+    <wire from="(320,310)" to="(430,310)"/>
+    <wire from="(320,370)" to="(320,590)"/>
+    <wire from="(140,740)" to="(430,740)"/>
+    <wire from="(140,600)" to="(430,600)"/>
+    <wire from="(490,520)" to="(530,520)"/>
+    <wire from="(490,380)" to="(530,380)"/>
+    <wire from="(490,660)" to="(530,660)"/>
+    <wire from="(490,800)" to="(530,800)"/>
+    <wire from="(180,160)" to="(210,160)"/>
+    <wire from="(310,920)" to="(400,920)"/>
+    <wire from="(400,820)" to="(430,820)"/>
+    <wire from="(400,680)" to="(430,680)"/>
+    <wire from="(400,540)" to="(430,540)"/>
+    <wire from="(400,400)" to="(430,400)"/>
+    <wire from="(160,720)" to="(430,720)"/>
+    <wire from="(160,440)" to="(430,440)"/>
+    <wire from="(290,460)" to="(430,460)"/>
+    <wire from="(290,320)" to="(430,320)"/>
+    <wire from="(240,200)" to="(320,200)"/>
+    <wire from="(350,710)" to="(430,710)"/>
+    <wire from="(350,570)" to="(430,570)"/>
+    <wire from="(350,430)" to="(430,430)"/>
+    <wire from="(350,290)" to="(430,290)"/>
+    <wire from="(130,950)" to="(260,950)"/>
+    <wire from="(400,680)" to="(400,750)"/>
+    <wire from="(400,540)" to="(400,610)"/>
+    <wire from="(400,400)" to="(400,470)"/>
+    <wire from="(290,390)" to="(290,460)"/>
+    <wire from="(140,740)" to="(140,810)"/>
+    <wire from="(160,720)" to="(160,790)"/>
+    <wire from="(140,600)" to="(140,670)"/>
+    <wire from="(160,440)" to="(160,510)"/>
+    <wire from="(180,780)" to="(430,780)"/>
+    <wire from="(180,640)" to="(430,640)"/>
+    <wire from="(180,500)" to="(430,500)"/>
+    <wire from="(180,360)" to="(430,360)"/>
+    <wire from="(350,160)" to="(350,290)"/>
+    <wire from="(180,160)" to="(180,360)"/>
+    <wire from="(130,160)" to="(180,160)"/>
+    <wire from="(240,160)" to="(350,160)"/>
+    <wire from="(130,870)" to="(170,870)"/>
+    <wire from="(130,910)" to="(170,910)"/>
+    <wire from="(260,870)" to="(260,900)"/>
+    <wire from="(140,810)" to="(430,810)"/>
+    <wire from="(140,670)" to="(430,670)"/>
+    <wire from="(490,310)" to="(530,310)"/>
+    <wire from="(490,450)" to="(530,450)"/>
+    <wire from="(490,590)" to="(530,590)"/>
+    <wire from="(490,730)" to="(530,730)"/>
+    <wire from="(130,200)" to="(160,200)"/>
+    <wire from="(400,820)" to="(400,920)"/>
+    <wire from="(400,750)" to="(430,750)"/>
+    <wire from="(400,330)" to="(430,330)"/>
+    <wire from="(400,610)" to="(430,610)"/>
+    <wire from="(400,470)" to="(430,470)"/>
+    <wire from="(140,240)" to="(140,600)"/>
+    <wire from="(320,200)" to="(320,310)"/>
+    <wire from="(160,790)" to="(430,790)"/>
+    <wire from="(160,510)" to="(430,510)"/>
+    <wire from="(290,530)" to="(430,530)"/>
+    <wire from="(290,390)" to="(430,390)"/>
+    <wire from="(160,200)" to="(160,440)"/>
+    <wire from="(130,240)" to="(140,240)"/>
+    <wire from="(140,240)" to="(210,240)"/>
+    <wire from="(320,310)" to="(320,370)"/>
+    <wire from="(320,590)" to="(320,650)"/>
+    <comp lib="1" loc="(490,520)" name="NAND Gate"/>
+    <comp lib="6" loc="(89,203)" name="Text">
+      <a name="text" val="A1"/>
+    </comp>
+    <comp lib="6" loc="(89,913)" name="Text">
+      <a name="text" val="E2"/>
+    </comp>
+    <comp lib="1" loc="(200,870)" name="NOT Gate"/>
+    <comp lib="0" loc="(530,380)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="1" loc="(490,380)" name="NAND Gate"/>
+    <comp lib="1" loc="(490,310)" name="NAND Gate"/>
+    <comp lib="0" loc="(530,520)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="1" loc="(490,800)" name="NAND Gate"/>
+    <comp lib="0" loc="(530,730)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="0" loc="(530,800)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="6" loc="(88,164)" name="Text">
+      <a name="text" val="A0"/>
+    </comp>
+    <comp lib="6" loc="(578,735)" name="Text">
+      <a name="text" val="O7_N"/>
+    </comp>
+    <comp lib="0" loc="(130,950)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="6" loc="(90,954)" name="Text">
+      <a name="text" val="E3"/>
+    </comp>
+    <comp lib="1" loc="(310,920)" name="AND Gate"/>
+    <comp lib="0" loc="(130,200)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="1" loc="(200,910)" name="NOT Gate"/>
+    <comp lib="1" loc="(490,450)" name="NAND Gate"/>
+    <comp lib="0" loc="(130,240)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="6" loc="(578,385)" name="Text">
+      <a name="text" val="O1_N"/>
+    </comp>
+    <comp lib="1" loc="(240,240)" name="NOT Gate"/>
+    <comp lib="1" loc="(240,200)" name="NOT Gate"/>
+    <comp lib="1" loc="(240,160)" name="NOT Gate"/>
+    <comp lib="6" loc="(90,244)" name="Text">
+      <a name="text" val="A2"/>
+    </comp>
+    <comp lib="6" loc="(580,803)" name="Text">
+      <a name="text" val="O8_N"/>
+    </comp>
+    <comp lib="0" loc="(130,870)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="0" loc="(530,660)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="6" loc="(136,63)" name="Text">
+      <a name="text" val="1 aus 8 Decoder"/>
+      <a name="font" val="SansSerif bold 20"/>
+    </comp>
+    <comp lib="6" loc="(88,874)" name="Text">
+      <a name="text" val="E1"/>
+    </comp>
+    <comp lib="0" loc="(530,310)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="tristate" val="false"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="1" loc="(490,590)" name="NAND Gate"/>
+    <comp lib="1" loc="(490,730)" name="NAND Gate"/>
+    <comp lib="0" loc="(530,450)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="6" loc="(580,314)" name="Text">
+      <a name="text" val="O0_N"/>
+    </comp>
+    <comp lib="0" loc="(530,590)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="tristate" val="false"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="6" loc="(580,592)" name="Text">
+      <a name="text" val="O5_N"/>
+    </comp>
+    <comp lib="1" loc="(490,660)" name="NAND Gate"/>
+    <comp lib="6" loc="(580,525)" name="Text">
+      <a name="text" val="O4_N"/>
+    </comp>
+    <comp lib="6" loc="(578,663)" name="Text">
+      <a name="text" val="O6_N"/>
+    </comp>
+    <comp lib="0" loc="(130,160)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="6" loc="(578,457)" name="Text">
+      <a name="text" val="O3_N"/>
+    </comp>
+    <comp lib="0" loc="(130,910)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+  </circuit>
+</project>

Digitaltechnik/3BItSynchronZähler.circ

@@ -0,0 +1,194 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+  This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+
+  <lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4"/>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <wire from="(370,200)" to="(370,270)"/>
+    <wire from="(110,180)" to="(170,180)"/>
+    <wire from="(280,340)" to="(280,470)"/>
+    <wire from="(250,310)" to="(250,320)"/>
+    <wire from="(560,80)" to="(560,340)"/>
+    <wire from="(150,440)" to="(520,440)"/>
+    <wire from="(190,250)" to="(240,250)"/>
+    <wire from="(60,270)" to="(170,270)"/>
+    <wire from="(460,320)" to="(460,340)"/>
+    <wire from="(460,340)" to="(460,360)"/>
+    <wire from="(280,280)" to="(380,280)"/>
+    <wire from="(470,210)" to="(470,240)"/>
+    <wire from="(300,220)" to="(300,250)"/>
+    <wire from="(580,340)" to="(580,360)"/>
+    <wire from="(600,300)" to="(600,340)"/>
+    <wire from="(210,80)" to="(560,80)"/>
+    <wire from="(600,350)" to="(620,350)"/>
+    <wire from="(190,340)" to="(280,340)"/>
+    <wire from="(380,220)" to="(410,220)"/>
+    <wire from="(290,160)" to="(310,160)"/>
+    <wire from="(310,340)" to="(330,340)"/>
+    <wire from="(320,350)" to="(340,350)"/>
+    <wire from="(460,150)" to="(480,150)"/>
+    <wire from="(250,310)" to="(400,310)"/>
+    <wire from="(170,270)" to="(170,320)"/>
+    <wire from="(400,260)" to="(410,260)"/>
+    <wire from="(470,350)" to="(480,350)"/>
+    <wire from="(460,240)" to="(470,240)"/>
+    <wire from="(290,250)" to="(300,250)"/>
+    <wire from="(300,220)" to="(310,220)"/>
+    <wire from="(360,200)" to="(370,200)"/>
+    <wire from="(400,260)" to="(400,310)"/>
+    <wire from="(680,340)" to="(680,530)"/>
+    <wire from="(560,340)" to="(560,530)"/>
+    <wire from="(460,320)" to="(540,320)"/>
+    <wire from="(60,150)" to="(60,270)"/>
+    <wire from="(170,180)" to="(240,180)"/>
+    <wire from="(280,280)" to="(280,340)"/>
+    <wire from="(400,340)" to="(400,530)"/>
+    <wire from="(470,410)" to="(600,410)"/>
+    <wire from="(380,220)" to="(380,280)"/>
+    <wire from="(470,350)" to="(470,410)"/>
+    <wire from="(280,470)" to="(660,470)"/>
+    <wire from="(380,100)" to="(380,170)"/>
+    <wire from="(330,270)" to="(330,340)"/>
+    <wire from="(110,110)" to="(110,180)"/>
+    <wire from="(60,110)" to="(60,120)"/>
+    <wire from="(540,190)" to="(540,320)"/>
+    <wire from="(110,100)" to="(110,110)"/>
+    <wire from="(60,110)" to="(110,110)"/>
+    <wire from="(390,120)" to="(390,130)"/>
+    <wire from="(310,160)" to="(310,180)"/>
+    <wire from="(580,360)" to="(620,360)"/>
+    <wire from="(310,340)" to="(310,360)"/>
+    <wire from="(520,340)" to="(560,340)"/>
+    <wire from="(150,230)" to="(150,440)"/>
+    <wire from="(380,100)" to="(680,100)"/>
+    <wire from="(480,150)" to="(480,170)"/>
+    <wire from="(190,250)" to="(190,340)"/>
+    <wire from="(520,360)" to="(520,440)"/>
+    <wire from="(330,270)" to="(370,270)"/>
+    <wire from="(210,140)" to="(240,140)"/>
+    <wire from="(580,340)" to="(600,340)"/>
+    <wire from="(660,360)" to="(660,470)"/>
+    <wire from="(150,230)" to="(240,230)"/>
+    <wire from="(230,410)" to="(320,410)"/>
+    <wire from="(600,340)" to="(620,340)"/>
+    <wire from="(170,120)" to="(390,120)"/>
+    <wire from="(660,340)" to="(680,340)"/>
+    <wire from="(310,360)" to="(340,360)"/>
+    <wire from="(380,170)" to="(410,170)"/>
+    <wire from="(390,130)" to="(410,130)"/>
+    <wire from="(230,100)" to="(380,100)"/>
+    <wire from="(380,340)" to="(400,340)"/>
+    <wire from="(470,210)" to="(490,210)"/>
+    <wire from="(460,340)" to="(480,340)"/>
+    <wire from="(460,360)" to="(480,360)"/>
+    <wire from="(320,410)" to="(470,410)"/>
+    <wire from="(480,170)" to="(490,170)"/>
+    <wire from="(170,320)" to="(250,320)"/>
+    <wire from="(330,340)" to="(340,340)"/>
+    <wire from="(600,350)" to="(600,410)"/>
+    <wire from="(230,160)" to="(240,160)"/>
+    <wire from="(170,270)" to="(240,270)"/>
+    <wire from="(320,350)" to="(320,410)"/>
+    <wire from="(680,100)" to="(680,340)"/>
+    <wire from="(170,120)" to="(170,180)"/>
+    <wire from="(230,100)" to="(230,160)"/>
+    <wire from="(210,80)" to="(210,140)"/>
+    <comp lib="0" loc="(600,300)" name="Constant">
+      <a name="facing" val="south"/>
+    </comp>
+    <comp lib="0" loc="(400,530)" name="Pin">
+      <a name="facing" val="north"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="0" loc="(230,410)" name="Clock"/>
+    <comp lib="1" loc="(360,200)" name="AND Gate">
+      <a name="inputs" val="2"/>
+    </comp>
+    <comp lib="4" loc="(520,340)" name="J-K Flip-Flop"/>
+    <comp lib="1" loc="(540,190)" name="AND Gate">
+      <a name="inputs" val="2"/>
+    </comp>
+    <comp lib="0" loc="(560,530)" name="Pin">
+      <a name="facing" val="north"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="1" loc="(290,250)" name="OR Gate">
+      <a name="inputs" val="3"/>
+    </comp>
+    <comp lib="1" loc="(290,160)" name="OR Gate">
+      <a name="inputs" val="3"/>
+    </comp>
+    <comp lib="4" loc="(660,340)" name="J-K Flip-Flop"/>
+    <comp lib="1" loc="(460,150)" name="OR Gate">
+      <a name="inputs" val="2"/>
+    </comp>
+    <comp lib="1" loc="(60,150)" name="NOT Gate">
+      <a name="facing" val="south"/>
+    </comp>
+    <comp lib="4" loc="(380,340)" name="J-K Flip-Flop"/>
+    <comp lib="0" loc="(110,100)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="1" loc="(460,240)" name="OR Gate">
+      <a name="inputs" val="2"/>
+    </comp>
+    <comp lib="0" loc="(680,530)" name="Pin">
+      <a name="facing" val="north"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+  </circuit>
+</project>

Digitaltechnik/4bitForwardCounter.circ

@@ -0,0 +1,139 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+  This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+
+  <lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4"/>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <wire from="(470,60)" to="(470,130)"/>
+    <wire from="(300,30)" to="(300,100)"/>
+    <wire from="(350,60)" to="(350,130)"/>
+    <wire from="(470,130)" to="(470,140)"/>
+    <wire from="(350,130)" to="(350,140)"/>
+    <wire from="(490,150)" to="(490,170)"/>
+    <wire from="(300,30)" to="(410,30)"/>
+    <wire from="(380,170)" to="(490,170)"/>
+    <wire from="(150,140)" to="(190,140)"/>
+    <wire from="(280,100)" to="(280,130)"/>
+    <wire from="(80,80)" to="(180,80)"/>
+    <wire from="(380,150)" to="(420,150)"/>
+    <wire from="(530,140)" to="(550,140)"/>
+    <wire from="(280,150)" to="(300,150)"/>
+    <wire from="(280,130)" to="(300,130)"/>
+    <wire from="(540,30)" to="(540,130)"/>
+    <wire from="(180,80)" to="(180,130)"/>
+    <wire from="(410,130)" to="(420,130)"/>
+    <wire from="(230,130)" to="(240,130)"/>
+    <wire from="(240,140)" to="(250,140)"/>
+    <wire from="(410,30)" to="(540,30)"/>
+    <wire from="(50,140)" to="(120,140)"/>
+    <wire from="(590,130)" to="(600,130)"/>
+    <wire from="(490,150)" to="(550,150)"/>
+    <wire from="(240,60)" to="(240,130)"/>
+    <wire from="(240,130)" to="(240,140)"/>
+    <wire from="(160,170)" to="(280,170)"/>
+    <wire from="(180,30)" to="(300,30)"/>
+    <wire from="(600,60)" to="(600,130)"/>
+    <wire from="(280,150)" to="(280,170)"/>
+    <wire from="(380,150)" to="(380,170)"/>
+    <wire from="(160,150)" to="(160,170)"/>
+    <wire from="(280,170)" to="(380,170)"/>
+    <wire from="(160,150)" to="(190,150)"/>
+    <wire from="(410,30)" to="(410,130)"/>
+    <wire from="(470,140)" to="(500,140)"/>
+    <wire from="(390,140)" to="(420,140)"/>
+    <wire from="(280,140)" to="(300,140)"/>
+    <wire from="(280,100)" to="(300,100)"/>
+    <wire from="(180,30)" to="(180,80)"/>
+    <wire from="(80,170)" to="(160,170)"/>
+    <wire from="(460,130)" to="(470,130)"/>
+    <wire from="(340,130)" to="(350,130)"/>
+    <wire from="(350,140)" to="(360,140)"/>
+    <wire from="(180,130)" to="(190,130)"/>
+    <wire from="(540,130)" to="(550,130)"/>
+    <comp lib="0" loc="(240,60)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="1" loc="(390,140)" name="NOT Gate"/>
+    <comp lib="0" loc="(600,60)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="0" loc="(80,80)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="4" loc="(460,130)" name="J-K Flip-Flop"/>
+    <comp lib="0" loc="(350,60)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="4" loc="(590,130)" name="J-K Flip-Flop"/>
+    <comp lib="1" loc="(530,140)" name="NOT Gate"/>
+    <comp lib="0" loc="(80,170)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="4" loc="(230,130)" name="J-K Flip-Flop"/>
+    <comp lib="0" loc="(470,60)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="1" loc="(280,140)" name="NOT Gate"/>
+    <comp lib="0" loc="(50,140)" name="Clock"/>
+    <comp lib="1" loc="(150,140)" name="NOT Gate"/>
+    <comp lib="4" loc="(340,130)" name="J-K Flip-Flop"/>
+  </circuit>
+</project>

Digitaltechnik/DNF.circ

@@ -0,0 +1,148 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+  This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+
+  <lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4"/>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <wire from="(770,310)" to="(770,320)"/>
+    <wire from="(470,390)" to="(660,390)"/>
+    <wire from="(190,390)" to="(190,910)"/>
+    <wire from="(470,230)" to="(780,230)"/>
+    <wire from="(290,110)" to="(290,130)"/>
+    <wire from="(220,230)" to="(220,310)"/>
+    <wire from="(850,340)" to="(890,340)"/>
+    <wire from="(700,360)" to="(800,360)"/>
+    <wire from="(150,110)" to="(150,130)"/>
+    <wire from="(190,90)" to="(190,110)"/>
+    <wire from="(120,290)" to="(420,290)"/>
+    <wire from="(190,110)" to="(190,390)"/>
+    <wire from="(780,230)" to="(780,310)"/>
+    <wire from="(290,160)" to="(290,250)"/>
+    <wire from="(190,110)" to="(220,110)"/>
+    <wire from="(220,310)" to="(220,920)"/>
+    <wire from="(150,210)" to="(150,370)"/>
+    <wire from="(120,290)" to="(120,900)"/>
+    <wire from="(150,370)" to="(150,920)"/>
+    <wire from="(780,310)" to="(800,310)"/>
+    <wire from="(130,920)" to="(150,920)"/>
+    <wire from="(150,210)" to="(420,210)"/>
+    <wire from="(150,370)" to="(420,370)"/>
+    <wire from="(680,350)" to="(680,470)"/>
+    <wire from="(280,920)" to="(290,920)"/>
+    <wire from="(700,360)" to="(700,550)"/>
+    <wire from="(290,250)" to="(420,250)"/>
+    <wire from="(290,330)" to="(420,330)"/>
+    <wire from="(290,410)" to="(420,410)"/>
+    <wire from="(470,620)" to="(730,620)"/>
+    <wire from="(660,330)" to="(800,330)"/>
+    <wire from="(680,350)" to="(800,350)"/>
+    <wire from="(220,160)" to="(220,230)"/>
+    <wire from="(470,310)" to="(770,310)"/>
+    <wire from="(290,250)" to="(290,330)"/>
+    <wire from="(290,330)" to="(290,410)"/>
+    <wire from="(120,90)" to="(120,110)"/>
+    <wire from="(220,110)" to="(220,130)"/>
+    <wire from="(260,90)" to="(260,110)"/>
+    <wire from="(190,390)" to="(420,390)"/>
+    <wire from="(470,550)" to="(700,550)"/>
+    <wire from="(120,110)" to="(150,110)"/>
+    <wire from="(260,110)" to="(260,910)"/>
+    <wire from="(260,110)" to="(290,110)"/>
+    <wire from="(770,320)" to="(800,320)"/>
+    <wire from="(470,470)" to="(680,470)"/>
+    <wire from="(150,160)" to="(150,210)"/>
+    <wire from="(730,370)" to="(730,620)"/>
+    <wire from="(730,370)" to="(800,370)"/>
+    <wire from="(260,910)" to="(270,910)"/>
+    <wire from="(120,110)" to="(120,290)"/>
+    <wire from="(660,330)" to="(660,390)"/>
+    <wire from="(290,410)" to="(290,920)"/>
+    <wire from="(890,340)" to="(900,340)"/>
+    <wire from="(220,230)" to="(420,230)"/>
+    <wire from="(220,310)" to="(420,310)"/>
+    <comp lib="1" loc="(470,230)" name="AND Gate"/>
+    <comp lib="1" loc="(850,340)" name="OR Gate">
+      <a name="inputs" val="6"/>
+    </comp>
+    <comp lib="1" loc="(220,160)" name="NOT Gate">
+      <a name="facing" val="south"/>
+    </comp>
+    <comp lib="0" loc="(120,90)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+      <a name="label" val="A"/>
+    </comp>
+    <comp lib="1" loc="(470,390)" name="AND Gate"/>
+    <comp lib="1" loc="(150,160)" name="NOT Gate">
+      <a name="facing" val="south"/>
+    </comp>
+    <comp lib="1" loc="(470,620)" name="AND Gate"/>
+    <comp lib="1" loc="(470,550)" name="AND Gate"/>
+    <comp lib="0" loc="(260,90)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+      <a name="label" val="C"/>
+    </comp>
+    <comp lib="1" loc="(290,160)" name="NOT Gate">
+      <a name="facing" val="south"/>
+    </comp>
+    <comp lib="1" loc="(470,470)" name="AND Gate"/>
+    <comp lib="5" loc="(890,340)" name="LED"/>
+    <comp lib="0" loc="(190,90)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+      <a name="label" val="B"/>
+    </comp>
+    <comp lib="1" loc="(470,310)" name="AND Gate"/>
+  </circuit>
+</project>

Digitaltechnik/DualGrayUmsetzer.circ

@@ -0,0 +1,132 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+  This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+
+  <lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4"/>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <wire from="(170,430)" to="(170,500)"/>
+    <wire from="(230,150)" to="(230,540)"/>
+    <wire from="(230,620)" to="(230,720)"/>
+    <wire from="(110,390)" to="(110,720)"/>
+    <wire from="(230,540)" to="(230,620)"/>
+    <wire from="(230,540)" to="(400,540)"/>
+    <wire from="(230,620)" to="(400,620)"/>
+    <wire from="(290,660)" to="(400,660)"/>
+    <wire from="(110,240)" to="(110,390)"/>
+    <wire from="(170,430)" to="(400,430)"/>
+    <wire from="(170,500)" to="(400,500)"/>
+    <wire from="(290,660)" to="(290,720)"/>
+    <wire from="(170,150)" to="(170,430)"/>
+    <wire from="(290,150)" to="(290,660)"/>
+    <wire from="(110,150)" to="(110,240)"/>
+    <wire from="(110,240)" to="(530,240)"/>
+    <wire from="(460,640)" to="(530,640)"/>
+    <wire from="(460,520)" to="(530,520)"/>
+    <wire from="(460,410)" to="(530,410)"/>
+    <wire from="(170,500)" to="(170,720)"/>
+    <wire from="(530,410)" to="(540,410)"/>
+    <wire from="(110,390)" to="(400,390)"/>
+    <comp lib="6" loc="(229,111)" name="Text">
+      <a name="text" val="d1"/>
+    </comp>
+    <comp lib="6" loc="(571,241)" name="Text">
+      <a name="text" val="g3"/>
+    </comp>
+    <comp lib="1" loc="(460,410)" name="XOR Gate"/>
+    <comp lib="6" loc="(569,414)" name="Text">
+      <a name="text" val="g2"/>
+    </comp>
+    <comp lib="5" loc="(530,240)" name="LED"/>
+    <comp lib="5" loc="(530,410)" name="LED"/>
+    <comp lib="5" loc="(530,640)" name="LED"/>
+    <comp lib="0" loc="(110,150)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="1" loc="(460,640)" name="XOR Gate"/>
+    <comp lib="0" loc="(230,150)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="6" loc="(170,112)" name="Text">
+      <a name="text" val="d2"/>
+    </comp>
+    <comp lib="1" loc="(460,520)" name="XOR Gate"/>
+    <comp lib="0" loc="(170,150)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="6" loc="(290,110)" name="Text">
+      <a name="text" val="d0"/>
+    </comp>
+    <comp lib="6" loc="(237,55)" name="Text">
+      <a name="text" val="Dual/Gray-Code Umsetzer"/>
+      <a name="font" val="SansSerif bold 20"/>
+    </comp>
+    <comp lib="5" loc="(530,520)" name="LED"/>
+    <comp lib="6" loc="(572,645)" name="Text">
+      <a name="text" val="g0"/>
+    </comp>
+    <comp lib="0" loc="(290,150)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="6" loc="(109,113)" name="Text">
+      <a name="text" val="d3"/>
+    </comp>
+    <comp lib="6" loc="(572,526)" name="Text">
+      <a name="text" val="g1"/>
+    </comp>
+  </circuit>
+</project>

Digitaltechnik/FlipFlop.circ

@@ -0,0 +1,386 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+  This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+
+  <lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4">
+    <tool name="ROM">
+      <a name="contents">addr/data: 8 8
+0
+</a>
+    </tool>
+  </lib>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <wire from="(650,450)" to="(650,460)"/>
+    <wire from="(550,410)" to="(670,410)"/>
+    <wire from="(370,960)" to="(430,960)"/>
+    <wire from="(660,100)" to="(710,100)"/>
+    <wire from="(640,200)" to="(690,200)"/>
+    <wire from="(180,730)" to="(240,730)"/>
+    <wire from="(670,340)" to="(670,410)"/>
+    <wire from="(290,210)" to="(290,220)"/>
+    <wire from="(280,200)" to="(280,220)"/>
+    <wire from="(120,160)" to="(120,180)"/>
+    <wire from="(550,110)" to="(550,140)"/>
+    <wire from="(550,350)" to="(550,380)"/>
+    <wire from="(670,340)" to="(780,340)"/>
+    <wire from="(490,890)" to="(490,920)"/>
+    <wire from="(300,660)" to="(300,690)"/>
+    <wire from="(400,110)" to="(400,200)"/>
+    <wire from="(120,180)" to="(150,180)"/>
+    <wire from="(550,180)" to="(570,180)"/>
+    <wire from="(460,920)" to="(490,920)"/>
+    <wire from="(90,620)" to="(180,620)"/>
+    <wire from="(300,690)" to="(320,690)"/>
+    <wire from="(300,890)" to="(320,890)"/>
+    <wire from="(490,920)" to="(510,920)"/>
+    <wire from="(790,850)" to="(790,1010)"/>
+    <wire from="(710,100)" to="(710,200)"/>
+    <wire from="(780,960)" to="(810,960)"/>
+    <wire from="(210,410)" to="(220,410)"/>
+    <wire from="(210,970)" to="(220,970)"/>
+    <wire from="(660,100)" to="(660,160)"/>
+    <wire from="(560,730)" to="(700,730)"/>
+    <wire from="(560,320)" to="(570,320)"/>
+    <wire from="(80,460)" to="(210,460)"/>
+    <wire from="(80,380)" to="(210,380)"/>
+    <wire from="(140,810)" to="(780,810)"/>
+    <wire from="(770,850)" to="(770,920)"/>
+    <wire from="(320,850)" to="(370,850)"/>
+    <wire from="(690,130)" to="(690,200)"/>
+    <wire from="(290,220)" to="(290,230)"/>
+    <wire from="(580,620)" to="(580,690)"/>
+    <wire from="(400,90)" to="(400,110)"/>
+    <wire from="(470,640)" to="(470,660)"/>
+    <wire from="(140,990)" to="(140,1010)"/>
+    <wire from="(780,810)" to="(780,960)"/>
+    <wire from="(550,160)" to="(550,180)"/>
+    <wire from="(210,380)" to="(210,410)"/>
+    <wire from="(660,870)" to="(660,890)"/>
+    <wire from="(120,130)" to="(120,160)"/>
+    <wire from="(770,850)" to="(790,850)"/>
+    <wire from="(570,940)" to="(570,980)"/>
+    <wire from="(550,110)" to="(570,110)"/>
+    <wire from="(550,350)" to="(570,350)"/>
+    <wire from="(660,940)" to="(680,940)"/>
+    <wire from="(290,210)" to="(310,210)"/>
+    <wire from="(300,660)" to="(320,660)"/>
+    <wire from="(370,850)" to="(370,960)"/>
+    <wire from="(740,850)" to="(770,850)"/>
+    <wire from="(400,240)" to="(420,240)"/>
+    <wire from="(400,200)" to="(420,200)"/>
+    <wire from="(550,620)" to="(580,620)"/>
+    <wire from="(630,100)" to="(660,100)"/>
+    <wire from="(470,710)" to="(490,710)"/>
+    <wire from="(490,890)" to="(510,890)"/>
+    <wire from="(180,620)" to="(180,730)"/>
+    <wire from="(320,850)" to="(320,890)"/>
+    <wire from="(380,710)" to="(380,750)"/>
+    <wire from="(90,690)" to="(300,690)"/>
+    <wire from="(230,870)" to="(250,870)"/>
+    <wire from="(210,850)" to="(230,850)"/>
+    <wire from="(690,130)" to="(760,130)"/>
+    <wire from="(140,1010)" to="(790,1010)"/>
+    <wire from="(80,420)" to="(220,420)"/>
+    <wire from="(500,220)" to="(570,220)"/>
+    <wire from="(630,200)" to="(640,200)"/>
+    <wire from="(220,910)" to="(220,970)"/>
+    <wire from="(580,620)" to="(700,620)"/>
+    <wire from="(460,960)" to="(510,960)"/>
+    <wire from="(270,730)" to="(320,730)"/>
+    <wire from="(650,380)" to="(650,450)"/>
+    <wire from="(630,340)" to="(670,340)"/>
+    <wire from="(400,220)" to="(400,240)"/>
+    <wire from="(470,690)" to="(470,710)"/>
+    <wire from="(380,750)" to="(490,750)"/>
+    <wire from="(760,100)" to="(760,130)"/>
+    <wire from="(550,410)" to="(550,440)"/>
+    <wire from="(230,850)" to="(230,870)"/>
+    <wire from="(550,160)" to="(660,160)"/>
+    <wire from="(570,980)" to="(680,980)"/>
+    <wire from="(210,430)" to="(210,460)"/>
+    <wire from="(660,920)" to="(660,940)"/>
+    <wire from="(470,660)" to="(560,660)"/>
+    <wire from="(570,830)" to="(570,870)"/>
+    <wire from="(260,410)" to="(350,410)"/>
+    <wire from="(550,440)" to="(570,440)"/>
+    <wire from="(660,870)" to="(680,870)"/>
+    <wire from="(470,640)" to="(490,640)"/>
+    <wire from="(660,890)" to="(750,890)"/>
+    <wire from="(550,140)" to="(640,140)"/>
+    <wire from="(380,600)" to="(380,640)"/>
+    <wire from="(140,830)" to="(160,830)"/>
+    <wire from="(140,990)" to="(160,990)"/>
+    <wire from="(710,200)" to="(780,200)"/>
+    <wire from="(280,220)" to="(290,220)"/>
+    <wire from="(200,200)" to="(280,200)"/>
+    <wire from="(210,430)" to="(220,430)"/>
+    <wire from="(640,140)" to="(640,200)"/>
+    <wire from="(80,90)" to="(150,90)"/>
+    <wire from="(740,960)" to="(750,960)"/>
+    <wire from="(550,730)" to="(560,730)"/>
+    <wire from="(750,890)" to="(750,960)"/>
+    <wire from="(560,660)" to="(560,730)"/>
+    <wire from="(530,90)" to="(570,90)"/>
+    <wire from="(380,600)" to="(490,600)"/>
+    <wire from="(550,380)" to="(650,380)"/>
+    <wire from="(470,690)" to="(580,690)"/>
+    <wire from="(140,810)" to="(140,830)"/>
+    <wire from="(660,920)" to="(770,920)"/>
+    <wire from="(80,160)" to="(120,160)"/>
+    <wire from="(570,830)" to="(680,830)"/>
+    <wire from="(790,850)" to="(810,850)"/>
+    <wire from="(220,910)" to="(250,910)"/>
+    <wire from="(120,130)" to="(150,130)"/>
+    <wire from="(630,450)" to="(650,450)"/>
+    <wire from="(500,470)" to="(530,470)"/>
+    <wire from="(760,100)" to="(780,100)"/>
+    <wire from="(370,220)" to="(400,220)"/>
+    <wire from="(290,230)" to="(310,230)"/>
+    <wire from="(750,960)" to="(780,960)"/>
+    <wire from="(480,220)" to="(500,220)"/>
+    <wire from="(530,90)" to="(530,320)"/>
+    <wire from="(370,850)" to="(510,850)"/>
+    <wire from="(650,460)" to="(780,460)"/>
+    <wire from="(180,620)" to="(320,620)"/>
+    <wire from="(400,90)" to="(530,90)"/>
+    <wire from="(200,110)" to="(400,110)"/>
+    <wire from="(80,220)" to="(150,220)"/>
+    <wire from="(90,950)" to="(160,950)"/>
+    <wire from="(90,870)" to="(160,870)"/>
+    <wire from="(500,220)" to="(500,470)"/>
+    <wire from="(560,470)" to="(570,470)"/>
+    <comp lib="0" loc="(780,200)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="6" loc="(491,189)" name="Text">
+      <a name="text" val="R*"/>
+    </comp>
+    <comp lib="6" loc="(57,870)" name="Text">
+      <a name="text" val="j"/>
+    </comp>
+    <comp lib="6" loc="(40,93)" name="Text">
+      <a name="text" val="S"/>
+    </comp>
+    <comp lib="0" loc="(780,340)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="1" loc="(570,940)" name="NAND Gate"/>
+    <comp lib="6" loc="(490,834)" name="Text">
+      <a name="text" val="/S"/>
+    </comp>
+    <comp lib="1" loc="(210,970)" name="AND Gate"/>
+    <comp lib="1" loc="(210,850)" name="AND Gate"/>
+    <comp lib="0" loc="(90,950)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="0" loc="(90,870)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="1" loc="(550,730)" name="NAND Gate"/>
+    <comp lib="1" loc="(570,870)" name="NAND Gate"/>
+    <comp lib="0" loc="(780,460)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="0" loc="(80,460)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="1" loc="(380,640)" name="NAND Gate"/>
+    <comp lib="1" loc="(550,620)" name="NAND Gate"/>
+    <comp lib="6" loc="(423,925)" name="Text">
+      <a name="text" val="Clk"/>
+    </comp>
+    <comp lib="1" loc="(740,960)" name="NAND Gate"/>
+    <comp lib="6" loc="(104,341)" name="Text">
+      <a name="text" val="Taktgesteuertes FF"/>
+    </comp>
+    <comp lib="6" loc="(374,837)" name="Text">
+      <a name="text" val="D"/>
+    </comp>
+    <comp lib="6" loc="(750,736)" name="Text">
+      <a name="text" val="/Q"/>
+    </comp>
+    <comp lib="6" loc="(43,695)" name="Text">
+      <a name="text" val="Clk"/>
+    </comp>
+    <comp lib="0" loc="(90,620)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="1" loc="(560,320)" name="NOT Gate"/>
+    <comp lib="0" loc="(700,730)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="0" loc="(350,410)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="6" loc="(38,225)" name="Text">
+      <a name="text" val="R"/>
+    </comp>
+    <comp lib="6" loc="(382,267)" name="Text">
+      <a name="text" val="Vermeidung des verbotenen Zustands"/>
+    </comp>
+    <comp lib="1" loc="(300,890)" name="OR Gate">
+      <a name="inputs" val="2"/>
+    </comp>
+    <comp lib="0" loc="(80,90)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="6" loc="(466,72)" name="Text">
+      <a name="text" val="S*"/>
+    </comp>
+    <comp lib="1" loc="(370,220)" name="NOR Gate"/>
+    <comp lib="6" loc="(57,953)" name="Text">
+      <a name="text" val="K"/>
+    </comp>
+    <comp lib="1" loc="(630,200)" name="NOR Gate"/>
+    <comp lib="1" loc="(380,710)" name="NAND Gate"/>
+    <comp lib="6" loc="(37,162)" name="Text">
+      <a name="text" val="C"/>
+    </comp>
+    <comp lib="0" loc="(810,960)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="6" loc="(860,966)" name="Text">
+      <a name="text" val="/Q"/>
+    </comp>
+    <comp lib="6" loc="(85,557)" name="Text">
+      <a name="text" val="D-FlipFlop"/>
+    </comp>
+    <comp lib="0" loc="(80,220)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="0" loc="(780,100)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="6" loc="(95,787)" name="Text">
+      <a name="text" val="JK-FlipFlop"/>
+    </comp>
+    <comp lib="1" loc="(740,850)" name="NAND Gate"/>
+    <comp lib="1" loc="(560,470)" name="NOT Gate"/>
+    <comp lib="0" loc="(80,160)" name="Clock"/>
+    <comp lib="1" loc="(270,730)" name="NOT Gate"/>
+    <comp lib="1" loc="(460,960)" name="NOT Gate"/>
+    <comp lib="6" loc="(488,986)" name="Text">
+      <a name="text" val="/R"/>
+    </comp>
+    <comp lib="1" loc="(480,220)" name="NOR Gate"/>
+    <comp lib="0" loc="(80,380)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="6" loc="(840,205)" name="Text">
+      <a name="text" val="/Q"/>
+    </comp>
+    <comp lib="6" loc="(842,341)" name="Text">
+      <a name="text" val="Q"/>
+    </comp>
+    <comp lib="6" loc="(746,628)" name="Text">
+      <a name="text" val="Q"/>
+    </comp>
+    <comp lib="6" loc="(129,263)" name="Text">
+      <a name="text" val="Flankensteuerung"/>
+    </comp>
+    <comp lib="1" loc="(630,450)" name="NAND Gate"/>
+    <comp lib="1" loc="(630,100)" name="NOR Gate"/>
+    <comp lib="6" loc="(295,601)" name="Text">
+      <a name="text" val="/S"/>
+    </comp>
+    <comp lib="4" loc="(260,410)" name="S-R Flip-Flop"/>
+    <comp lib="6" loc="(42,621)" name="Text">
+      <a name="text" val="D"/>
+    </comp>
+    <comp lib="6" loc="(298,756)" name="Text">
+      <a name="text" val="/R"/>
+    </comp>
+    <comp lib="0" loc="(80,420)" name="Clock"/>
+    <comp lib="6" loc="(842,103)" name="Text">
+      <a name="text" val="Q"/>
+    </comp>
+    <comp lib="6" loc="(837,462)" name="Text">
+      <a name="text" val="/Q"/>
+    </comp>
+    <comp lib="1" loc="(200,110)" name="AND Gate"/>
+    <comp lib="6" loc="(856,858)" name="Text">
+      <a name="text" val="Q"/>
+    </comp>
+    <comp lib="0" loc="(460,920)" name="Clock"/>
+    <comp lib="0" loc="(700,620)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="1" loc="(200,200)" name="AND Gate"/>
+    <comp lib="1" loc="(630,340)" name="NAND Gate"/>
+    <comp lib="0" loc="(810,850)" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="6" loc="(68,43)" name="Text">
+      <a name="text" val="SR-FlipFlop"/>
+    </comp>
+    <comp lib="0" loc="(90,690)" name="Clock"/>
+  </circuit>
+</project>

Digitaltechnik/GrayDualUmsetzer.circ

@@ -0,0 +1,160 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+  This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+
+  <lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4">
+    <tool name="ROM">
+      <a name="contents">addr/data: 8 8
+0
+</a>
+    </tool>
+  </lib>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <appear>
+      <circ-anchor facing="east" height="6" width="6" x="47" y="47"/>
+    </appear>
+  </circuit>
+  <circuit name="7Seg_Anzeige">
+    <a name="circuit" val="7Seg_Anzeige"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+  </circuit>
+  <circuit name="Gray/Dual_Umsetzer">
+    <a name="circuit" val="Gray/Dual_Umsetzer"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <wire from="(470,520)" to="(470,590)"/>
+    <wire from="(470,520)" to="(530,520)"/>
+    <wire from="(470,410)" to="(530,410)"/>
+    <wire from="(230,150)" to="(230,540)"/>
+    <wire from="(110,390)" to="(110,720)"/>
+    <wire from="(360,470)" to="(470,470)"/>
+    <wire from="(360,590)" to="(470,590)"/>
+    <wire from="(110,240)" to="(110,390)"/>
+    <wire from="(170,150)" to="(170,430)"/>
+    <wire from="(110,150)" to="(110,240)"/>
+    <wire from="(360,470)" to="(360,500)"/>
+    <wire from="(360,590)" to="(360,620)"/>
+    <wire from="(110,240)" to="(530,240)"/>
+    <wire from="(170,430)" to="(170,720)"/>
+    <wire from="(440,640)" to="(530,640)"/>
+    <wire from="(290,660)" to="(380,660)"/>
+    <wire from="(440,520)" to="(470,520)"/>
+    <wire from="(440,410)" to="(470,410)"/>
+    <wire from="(360,500)" to="(380,500)"/>
+    <wire from="(230,540)" to="(380,540)"/>
+    <wire from="(360,620)" to="(380,620)"/>
+    <wire from="(170,430)" to="(380,430)"/>
+    <wire from="(110,390)" to="(380,390)"/>
+    <wire from="(230,540)" to="(230,720)"/>
+    <wire from="(290,660)" to="(290,720)"/>
+    <wire from="(290,150)" to="(290,660)"/>
+    <wire from="(470,410)" to="(470,470)"/>
+    <wire from="(530,410)" to="(540,410)"/>
+    <wire from="(530,640)" to="(540,640)"/>
+    <comp lib="0" loc="(170,150)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="1" loc="(440,520)" name="XOR Gate"/>
+    <comp lib="5" loc="(530,410)" name="LED"/>
+    <comp lib="5" loc="(530,640)" name="LED"/>
+    <comp lib="6" loc="(170,112)" name="Text">
+      <a name="text" val="d2"/>
+    </comp>
+    <comp lib="6" loc="(571,241)" name="Text">
+      <a name="text" val="g3"/>
+    </comp>
+    <comp lib="6" loc="(569,414)" name="Text">
+      <a name="text" val="g2"/>
+    </comp>
+    <comp lib="6" loc="(109,113)" name="Text">
+      <a name="text" val="d3"/>
+    </comp>
+    <comp lib="6" loc="(290,110)" name="Text">
+      <a name="text" val="d0"/>
+    </comp>
+    <comp lib="5" loc="(530,520)" name="LED"/>
+    <comp lib="6" loc="(237,55)" name="Text">
+      <a name="text" val="Gray/Dual-Code Umsetzer"/>
+      <a name="font" val="SansSerif bold 20"/>
+    </comp>
+    <comp lib="1" loc="(440,640)" name="XOR Gate"/>
+    <comp lib="6" loc="(572,645)" name="Text">
+      <a name="text" val="g0"/>
+    </comp>
+    <comp lib="0" loc="(230,150)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="6" loc="(229,111)" name="Text">
+      <a name="text" val="d1"/>
+    </comp>
+    <comp lib="0" loc="(290,150)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="1" loc="(440,410)" name="XOR Gate"/>
+    <comp lib="0" loc="(110,150)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="5" loc="(530,240)" name="LED"/>
+    <comp lib="6" loc="(572,526)" name="Text">
+      <a name="text" val="g1"/>
+    </comp>
+  </circuit>
+</project>

Digitaltechnik/Klausuruebung.circ

@@ -0,0 +1,155 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+  This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+
+  <lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4">
+    <tool name="ROM">
+      <a name="contents">addr/data: 8 8
+0
+</a>
+    </tool>
+  </lib>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <wire from="(840,340)" to="(890,340)"/>
+    <wire from="(190,300)" to="(510,300)"/>
+    <wire from="(330,460)" to="(330,910)"/>
+    <wire from="(120,240)" to="(120,760)"/>
+    <wire from="(120,760)" to="(620,760)"/>
+    <wire from="(290,110)" to="(290,130)"/>
+    <wire from="(670,780)" to="(900,780)"/>
+    <wire from="(330,90)" to="(330,110)"/>
+    <wire from="(120,760)" to="(120,910)"/>
+    <wire from="(150,110)" to="(150,130)"/>
+    <wire from="(190,90)" to="(190,110)"/>
+    <wire from="(510,250)" to="(510,280)"/>
+    <wire from="(190,270)" to="(190,300)"/>
+    <wire from="(190,110)" to="(220,110)"/>
+    <wire from="(190,300)" to="(190,910)"/>
+    <wire from="(190,110)" to="(190,270)"/>
+    <wire from="(460,480)" to="(490,480)"/>
+    <wire from="(260,500)" to="(260,790)"/>
+    <wire from="(330,110)" to="(360,110)"/>
+    <wire from="(330,110)" to="(330,410)"/>
+    <wire from="(490,420)" to="(510,420)"/>
+    <wire from="(330,410)" to="(480,410)"/>
+    <wire from="(570,410)" to="(770,410)"/>
+    <wire from="(770,350)" to="(770,410)"/>
+    <wire from="(330,410)" to="(330,460)"/>
+    <wire from="(150,160)" to="(150,920)"/>
+    <wire from="(290,160)" to="(290,920)"/>
+    <wire from="(260,790)" to="(260,910)"/>
+    <wire from="(330,460)" to="(400,460)"/>
+    <wire from="(120,110)" to="(120,240)"/>
+    <wire from="(260,110)" to="(260,500)"/>
+    <wire from="(460,250)" to="(510,250)"/>
+    <wire from="(360,110)" to="(360,130)"/>
+    <wire from="(480,390)" to="(480,410)"/>
+    <wire from="(120,90)" to="(120,110)"/>
+    <wire from="(770,300)" to="(770,330)"/>
+    <wire from="(220,110)" to="(220,130)"/>
+    <wire from="(260,90)" to="(260,110)"/>
+    <wire from="(260,790)" to="(620,790)"/>
+    <wire from="(120,110)" to="(150,110)"/>
+    <wire from="(480,390)" to="(510,390)"/>
+    <wire from="(260,110)" to="(290,110)"/>
+    <wire from="(770,330)" to="(790,330)"/>
+    <wire from="(770,350)" to="(790,350)"/>
+    <wire from="(120,240)" to="(400,240)"/>
+    <wire from="(190,270)" to="(400,270)"/>
+    <wire from="(570,300)" to="(770,300)"/>
+    <wire from="(260,500)" to="(400,500)"/>
+    <wire from="(890,340)" to="(900,340)"/>
+    <wire from="(220,160)" to="(220,920)"/>
+    <wire from="(490,420)" to="(490,480)"/>
+    <wire from="(360,160)" to="(360,920)"/>
+    <comp lib="1" loc="(220,160)" name="NOT Gate">
+      <a name="facing" val="south"/>
+    </comp>
+    <comp lib="0" loc="(120,90)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+      <a name="label" val="A"/>
+    </comp>
+    <comp lib="1" loc="(150,160)" name="NOT Gate">
+      <a name="facing" val="south"/>
+    </comp>
+    <comp lib="1" loc="(670,780)" name="AND Gate"/>
+    <comp lib="1" loc="(360,160)" name="NOT Gate">
+      <a name="facing" val="south"/>
+    </comp>
+    <comp lib="0" loc="(260,90)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+      <a name="label" val="C"/>
+    </comp>
+    <comp lib="1" loc="(460,480)" name="XOR Gate"/>
+    <comp lib="1" loc="(570,410)" name="XOR Gate"/>
+    <comp lib="0" loc="(330,90)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="1" loc="(290,160)" name="NOT Gate">
+      <a name="facing" val="south"/>
+    </comp>
+    <comp lib="1" loc="(840,340)" name="AND Gate"/>
+    <comp lib="5" loc="(890,340)" name="LED"/>
+    <comp lib="0" loc="(190,90)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="tristate" val="false"/>
+      <a name="label" val="B"/>
+    </comp>
+    <comp lib="5" loc="(900,780)" name="LED"/>
+    <comp lib="1" loc="(460,250)" name="XOR Gate"/>
+    <comp lib="1" loc="(570,300)" name="XOR Gate"/>
+  </circuit>
+</project>

Digitaltechnik/SynchronDualZähler.circ

@@ -0,0 +1,149 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+  This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+
+  <lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4"/>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <wire from="(170,260)" to="(170,330)"/>
+    <wire from="(230,100)" to="(230,170)"/>
+    <wire from="(50,330)" to="(170,330)"/>
+    <wire from="(530,260)" to="(530,330)"/>
+    <wire from="(390,250)" to="(390,270)"/>
+    <wire from="(430,150)" to="(430,170)"/>
+    <wire from="(500,160)" to="(500,180)"/>
+    <wire from="(130,200)" to="(170,200)"/>
+    <wire from="(540,140)" to="(540,180)"/>
+    <wire from="(230,250)" to="(260,250)"/>
+    <wire from="(340,150)" to="(340,250)"/>
+    <wire from="(340,150)" to="(430,150)"/>
+    <wire from="(520,250)" to="(540,250)"/>
+    <wire from="(520,270)" to="(540,270)"/>
+    <wire from="(160,270)" to="(180,270)"/>
+    <wire from="(460,100)" to="(460,140)"/>
+    <wire from="(400,260)" to="(410,260)"/>
+    <wire from="(450,250)" to="(460,250)"/>
+    <wire from="(280,260)" to="(290,260)"/>
+    <wire from="(330,250)" to="(340,250)"/>
+    <wire from="(170,250)" to="(180,250)"/>
+    <wire from="(460,140)" to="(540,140)"/>
+    <wire from="(340,100)" to="(340,150)"/>
+    <wire from="(400,260)" to="(400,330)"/>
+    <wire from="(280,260)" to="(280,330)"/>
+    <wire from="(280,330)" to="(400,330)"/>
+    <wire from="(410,220)" to="(410,230)"/>
+    <wire from="(370,160)" to="(370,170)"/>
+    <wire from="(170,330)" to="(280,330)"/>
+    <wire from="(260,250)" to="(260,270)"/>
+    <wire from="(380,230)" to="(380,250)"/>
+    <wire from="(230,170)" to="(230,250)"/>
+    <wire from="(520,230)" to="(520,250)"/>
+    <wire from="(520,250)" to="(520,270)"/>
+    <wire from="(160,250)" to="(160,270)"/>
+    <wire from="(520,150)" to="(520,180)"/>
+    <wire from="(590,100)" to="(590,250)"/>
+    <wire from="(430,150)" to="(520,150)"/>
+    <wire from="(260,270)" to="(290,270)"/>
+    <wire from="(260,250)" to="(290,250)"/>
+    <wire from="(380,230)" to="(410,230)"/>
+    <wire from="(460,140)" to="(460,250)"/>
+    <wire from="(370,170)" to="(390,170)"/>
+    <wire from="(390,270)" to="(410,270)"/>
+    <wire from="(390,250)" to="(410,250)"/>
+    <wire from="(170,200)" to="(170,250)"/>
+    <wire from="(380,250)" to="(390,250)"/>
+    <wire from="(170,260)" to="(180,260)"/>
+    <wire from="(160,250)" to="(170,250)"/>
+    <wire from="(220,250)" to="(230,250)"/>
+    <wire from="(230,170)" to="(370,170)"/>
+    <wire from="(400,330)" to="(530,330)"/>
+    <wire from="(370,160)" to="(500,160)"/>
+    <wire from="(580,250)" to="(590,250)"/>
+    <wire from="(530,260)" to="(540,260)"/>
+    <comp lib="1" loc="(410,220)" name="AND Gate">
+      <a name="facing" val="south"/>
+      <a name="inputs" val="2"/>
+    </comp>
+    <comp lib="4" loc="(450,250)" name="J-K Flip-Flop"/>
+    <comp lib="0" loc="(340,100)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="0" loc="(460,100)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="0" loc="(130,200)" name="Pin">
+      <a name="tristate" val="false"/>
+    </comp>
+    <comp lib="4" loc="(580,250)" name="J-K Flip-Flop"/>
+    <comp lib="0" loc="(230,100)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="1" loc="(520,230)" name="AND Gate">
+      <a name="facing" val="south"/>
+      <a name="inputs" val="3"/>
+    </comp>
+    <comp lib="4" loc="(330,250)" name="J-K Flip-Flop"/>
+    <comp lib="0" loc="(590,100)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="4" loc="(220,250)" name="J-K Flip-Flop"/>
+    <comp lib="0" loc="(50,330)" name="Clock"/>
+  </circuit>
+</project>

Digitaltechnik/elektronischerWuerfel.circ

@@ -0,0 +1,58 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+  This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+
+  <lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4"/>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+  </circuit>
+</project>

Digitaltechnik/labor7/4BitAsynchronZaehler_3b.circ

@@ -0,0 +1,206 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<project source="2.7.1" version="1.0">
+This file is intended to be loaded by Logisim (http://www.cburch.com/logisim/).
+<lib desc="#Wiring" name="0"/>
+  <lib desc="#Gates" name="1"/>
+  <lib desc="#Plexers" name="2"/>
+  <lib desc="#Arithmetic" name="3"/>
+  <lib desc="#Memory" name="4">
+    <tool name="ROM">
+      <a name="contents">addr/data: 8 8
+0
+</a>
+    </tool>
+  </lib>
+  <lib desc="#I/O" name="5"/>
+  <lib desc="#Base" name="6">
+    <tool name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+  </lib>
+  <main name="main"/>
+  <options>
+    <a name="gateUndefined" val="ignore"/>
+    <a name="simlimit" val="1000"/>
+    <a name="simrand" val="0"/>
+  </options>
+  <mappings>
+    <tool lib="6" map="Button2" name="Menu Tool"/>
+    <tool lib="6" map="Button3" name="Menu Tool"/>
+    <tool lib="6" map="Ctrl Button1" name="Menu Tool"/>
+  </mappings>
+  <toolbar>
+    <tool lib="6" name="Poke Tool"/>
+    <tool lib="6" name="Edit Tool"/>
+    <tool lib="6" name="Text Tool">
+      <a name="text" val=""/>
+      <a name="font" val="SansSerif plain 12"/>
+      <a name="halign" val="center"/>
+      <a name="valign" val="base"/>
+    </tool>
+    <sep/>
+    <tool lib="0" name="Pin">
+      <a name="tristate" val="false"/>
+    </tool>
+    <tool lib="0" name="Pin">
+      <a name="facing" val="west"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </tool>
+    <tool lib="1" name="NOT Gate"/>
+    <tool lib="1" name="AND Gate"/>
+    <tool lib="1" name="OR Gate"/>
+  </toolbar>
+  <circuit name="main">
+    <a name="circuit" val="main"/>
+    <a name="clabel" val=""/>
+    <a name="clabelup" val="east"/>
+    <a name="clabelfont" val="SansSerif plain 12"/>
+    <wire from="(260,170)" to="(320,170)"/>
+    <wire from="(790,290)" to="(790,300)"/>
+    <wire from="(240,240)" to="(240,250)"/>
+    <wire from="(330,210)" to="(380,210)"/>
+    <wire from="(220,400)" to="(340,400)"/>
+    <wire from="(480,240)" to="(480,250)"/>
+    <wire from="(340,400)" to="(460,400)"/>
+    <wire from="(360,240)" to="(360,250)"/>
+    <wire from="(330,150)" to="(330,160)"/>
+    <wire from="(370,290)" to="(370,310)"/>
+    <wire from="(370,310)" to="(370,330)"/>
+    <wire from="(350,150)" to="(350,170)"/>
+    <wire from="(350,170)" to="(350,190)"/>
+    <wire from="(490,290)" to="(490,310)"/>
+    <wire from="(490,310)" to="(490,330)"/>
+    <wire from="(750,300)" to="(790,300)"/>
+    <wire from="(260,170)" to="(260,250)"/>
+    <wire from="(250,290)" to="(250,310)"/>
+    <wire from="(250,310)" to="(250,330)"/>
+    <wire from="(170,360)" to="(210,360)"/>
+    <wire from="(510,250)" to="(610,250)"/>
+    <wire from="(580,340)" to="(580,360)"/>
+    <wire from="(750,130)" to="(750,300)"/>
+    <wire from="(540,330)" to="(560,330)"/>
+    <wire from="(600,330)" to="(620,330)"/>
+    <wire from="(100,310)" to="(190,310)"/>
+    <wire from="(360,250)" to="(380,250)"/>
+    <wire from="(170,290)" to="(170,330)"/>
+    <wire from="(670,170)" to="(670,330)"/>
+    <wire from="(290,290)" to="(290,330)"/>
+    <wire from="(410,290)" to="(410,330)"/>
+    <wire from="(240,250)" to="(260,250)"/>
+    <wire from="(470,310)" to="(480,310)"/>
+    <wire from="(170,290)" to="(250,290)"/>
+    <wire from="(350,310)" to="(360,310)"/>
+    <wire from="(400,200)" to="(400,250)"/>
+    <wire from="(290,290)" to="(370,290)"/>
+    <wire from="(230,310)" to="(240,310)"/>
+    <wire from="(610,250)" to="(610,310)"/>
+    <wire from="(410,290)" to="(490,290)"/>
+    <wire from="(340,340)" to="(340,400)"/>
+    <wire from="(460,400)" to="(590,400)"/>
+    <wire from="(510,190)" to="(510,250)"/>
+    <wire from="(460,340)" to="(460,400)"/>
+    <wire from="(220,340)" to="(220,400)"/>
+    <wire from="(340,200)" to="(400,200)"/>
+    <wire from="(370,310)" to="(430,310)"/>
+    <wire from="(330,160)" to="(710,160)"/>
+    <wire from="(610,240)" to="(610,250)"/>
+    <wire from="(350,170)" to="(670,170)"/>
+    <wire from="(250,310)" to="(310,310)"/>
+    <wire from="(210,360)" to="(330,360)"/>
+    <wire from="(330,360)" to="(450,360)"/>
+    <wire from="(320,150)" to="(320,170)"/>
+    <wire from="(330,340)" to="(330,360)"/>
+    <wire from="(450,340)" to="(450,360)"/>
+    <wire from="(590,400)" to="(690,400)"/>
+    <wire from="(210,340)" to="(210,360)"/>
+    <wire from="(690,380)" to="(690,400)"/>
+    <wire from="(540,290)" to="(540,330)"/>
+    <wire from="(710,160)" to="(710,330)"/>
+    <wire from="(620,290)" to="(620,330)"/>
+    <wire from="(340,130)" to="(750,130)"/>
+    <wire from="(350,190)" to="(510,190)"/>
+    <wire from="(290,330)" to="(310,330)"/>
+    <wire from="(350,330)" to="(370,330)"/>
+    <wire from="(410,330)" to="(430,330)"/>
+    <wire from="(470,330)" to="(490,330)"/>
+    <wire from="(380,210)" to="(380,250)"/>
+    <wire from="(170,330)" to="(190,330)"/>
+    <wire from="(230,330)" to="(250,330)"/>
+    <wire from="(590,340)" to="(590,400)"/>
+    <wire from="(400,250)" to="(480,250)"/>
+    <wire from="(340,150)" to="(340,200)"/>
+    <wire from="(330,160)" to="(330,210)"/>
+    <wire from="(540,290)" to="(620,290)"/>
+    <wire from="(450,360)" to="(580,360)"/>
+    <wire from="(360,250)" to="(360,310)"/>
+    <wire from="(480,250)" to="(480,310)"/>
+    <wire from="(490,310)" to="(560,310)"/>
+    <wire from="(240,250)" to="(240,310)"/>
+    <wire from="(600,310)" to="(610,310)"/>
+    <comp lib="6" loc="(211,234)" name="Text">
+      <a name="text" val="Q0"/>
+    </comp>
+    <comp lib="0" loc="(240,240)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="4" loc="(230,310)" name="D Flip-Flop"/>
+    <comp lib="0" loc="(480,240)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="1" loc="(690,380)" name="AND Gate">
+      <a name="facing" val="south"/>
+      <a name="inputs" val="2"/>
+    </comp>
+    <comp lib="0" loc="(340,130)" name="Splitter">
+      <a name="facing" val="south"/>
+      <a name="fanout" val="4"/>
+      <a name="incoming" val="4"/>
+      <a name="appear" val="center"/>
+      <a name="bit0" val="3"/>
+      <a name="bit1" val="2"/>
+      <a name="bit2" val="1"/>
+      <a name="bit3" val="0"/>
+    </comp>
+    <comp lib="6" loc="(452,234)" name="Text">
+      <a name="text" val="Q2"/>
+    </comp>
+    <comp lib="6" loc="(775,359)" name="Text">
+      <a name="text" val="0-9 Begrenzung!"/>
+      <a name="font" val="SansSerif bold 12"/>
+    </comp>
+    <comp lib="4" loc="(470,310)" name="D Flip-Flop"/>
+    <comp lib="0" loc="(170,360)" name="Constant"/>
+    <comp lib="4" loc="(600,310)" name="D Flip-Flop"/>
+    <comp lib="6" loc="(245,66)" name="Text">
+      <a name="text" val="4-Bit Asynchrozähler mit D-FF"/>
+      <a name="font" val="SansSerif bold 20"/>
+    </comp>
+    <comp lib="6" loc="(582,235)" name="Text">
+      <a name="text" val="Q3"/>
+    </comp>
+    <comp lib="6" loc="(335,235)" name="Text">
+      <a name="text" val="Q1"/>
+    </comp>
+    <comp lib="5" loc="(790,290)" name="Hex Digit Display"/>
+    <comp lib="4" loc="(350,310)" name="D Flip-Flop"/>
+    <comp lib="0" loc="(610,240)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+    <comp lib="0" loc="(100,310)" name="Clock"/>
+    <comp lib="0" loc="(360,240)" name="Pin">
+      <a name="facing" val="south"/>
+      <a name="output" val="true"/>
+      <a name="labelloc" val="east"/>
+    </comp>
+  </circuit>
+</project>

Grafik/Hackbarth/Hackbarth Einstiegsprojekt.md

@@ -0,0 +1,22 @@
+# Einstiegsprojekt in Visual Studio
+
+### Erstellung des Projekts
+- C++ Game erstellen auswählen (Win11 SDK wichtig!)
+- Desktop Installer Projekt erstellen
+- main.cpp als Entrypoint
+	- windows.h inkludieren für Windows API!
+	- Docs: [Windows API Docs](https://learn.microsoft.com/en-us/windows/win32/learnwin32/creating-a-window)
+
+```
+#include <Windows.h>
+
+int main(
+  HINSTANCE hInstance,
+  HINSTANCE hPrevInstance,
+  LPSTR     lpCmdLine,
+  int       nShowCmd
+)
+{
+	return 0;
+};
+```

Grafik/Hackbarth/Klausurthemen.md

@@ -0,0 +1,96 @@
+# Klausurvorbereitung
+
+- Es gibt keine Minuspunkte, aber halbe Punkte
+- Antwortlänge an Punkte pro Frage anpassen
+- Reihenfolgen und Sortierungsfragen auch werden auch dabei sein
+- Datentypen oder Enumwerte aus D3D9/D3D11 (z. B. WMQUITE, WMDESTROY, WMEXIT)
+- History-Inhalte aus den Folien aus den Folien kommt nicht
+
+**Transformation**:(Local Space) 
+- World
+- View
+- Projection
+
+**Zugelassen für Rechnungen**:
+- Taschenrechner (nicht programmierbar)
+- Windows oder Physisch
+
+### Themengebiete:
+##### Generell: 
+- Graphics C ++ (z. B. warum C++ benutzen)
+- Unterschied zwischen Pointer und Handle, Pointer-Pointer 
+- COM (Component Object Model von Windows)
+- generelle Graphics Programmingsachen
+##### Fenster: 
+- Fensternachrichten (Typen aus Vorlesungsfolien) 
+- Messagequeue
+- Wozu braucht man Nachrichten?
+- Messagequeue-Funktion: Window Prop
+##### Graphics -API:
+- Welche gibt es?
+- Direct 3D
+- Fixed Function vs. Programmable Pipeline
+- Elemente der Pipelines: Vertex, Mesh, Transformation, Spaces, Projektion, Primitive Types, Unterschied List vs. Strip, Texture Mapping (Was ist eine Normale?)
+- Homogenisierte Koordinaten und dessen Bedeutung
+- Berechnungen: Koordinaten, FPS, Deltatime, Größe von Strukturen 
+	- Beispiele:
+		- Indexbuffers -> kibiByte beachten -> Indices zählen
+		- Vertexbuffer berechnen (Umschrieben, nicht direkt gestellt)
+		- Texturebuffer berechnen
+		- Mipmapping (zählen der Stufen)
+- Textures: 
+	- UV-Mapping
+	- UV-Tiling (Address Modes)
+	- Bild von Modell und gefragt wie viele Verticies benötigt werden und welche
+- Lighting: 
+	- Sources, Lichtbestandteile (Ambient Light, Diffuse Light, Specular Light, Emission Light
+	- Vertex- vs. Pixel-Lighting
+- Stages: 
+	- Screen-Stage
+	- Rasterizer-Stage: Front faces /Back faces
+
+##### Direct3D/DirectX: 
+- Direct3D9 and Direct3D11
+- ID3D11 Device Context, IDirectDevice9
+- konkrete Datentypen aus Framework
+- ID3D11 Device vs. ID3D11 Device Context
+##### Shader: 
+- Shadertypen (6): 
+	- Vertex shade
+	- Hall Shader
+	- Domain Shader
+	- Geometry Shader
+	- Pixelshader
+	- Computeshader
+- zu jedem Shader Grundfunktionalitäten, wozu
+  sie da sind
+- Shader Ressources (Vertexbuffer, Indexbuffer, Constantbuffer)
+- HSL: High Level Shader Language, genereller Sinn von Semantiken in HSL
+
+
+##### Verticies berechnen: 
+- Ziel: Lichtberechnung und Texturierung
+1. Verticiesanzahl berechnen: Verticies = Ecken (4 pro Fläche)
+	- 4 Verticies * 6 Flächen = **24 Verticies**
+	- Eine Normale pro Fläche wegrn des Lichts, deswegen 24 Verticies statt 8
+2. Vertexgröße: 
+	- Position: 3 Floats (x,y,z)
+	- Normale: 3 Floats (x,y,z)
+	- UV-Koordinaten: 2 Floats
+	- 1 Float = 4 Byte
+	↳ 8 Floats. 4 Byles: **32 Byte pro Vertex**
+	- Verfexcolor: 4 Floats
+	- Grafikkarte ist auf Floats optimiert
+3. Vertexbuffergröße:
+	- 24 Vertexe * 32 Byte pro Vertex = **768 Byte**
+	- 2 Byle = 1 Word
+##### Indexbuffer berechnen: 
+- Primitive Type Lists: Triangle List (oder Linelist, Pointlist)
+- 6 Flächen, 2 Dreiecke pro Fläche
+- Mehrfachverwendung der Verticies
+- Zusatzinfos nötig für die Berechnung: Wie viele Flächen und welche Form haben die Flächen
+- wenn die Wahl frei steht: Triangle List (haben wir in der Vorlesung immer benutzt)
+- Bytegröße selbst wählen: Anzahl der Indicies muss in die Bytegröße passen
+- Berechnung: 
+	1. 12 Dreiecke * 3 Ecken = 36 Indicies
+	2. 36 Indicies * 2 Byte = **72 Byte**

Grafik/Hackbarth/Links & Lighting.md

@@ -0,0 +1,29 @@
+---
+share_link: https://share.note.sx/432fk0nz#QrHwi4GF8i8Br/2gDbauKzSsc3TUy6hNjn0oYBUNeUk
+share_updated: 2025-12-04T13:48:22+01:00
+---
+# Links & Lighting
+
+Stages & Pipeline: https://learn.microsoft.com/de-de/windows/win32/direct3d9/direct3d-architecture
+
+Strukturen: Vertices, Edges und Triangles
+
+Transformation: https://learn.microsoft.com/de-de/windows/win32/direct3d9/transforms
+World Transformation: https://learn.microsoft.com/de-de/windows/win32/direct3d9/world-transform
+View Transformation: https://learn.microsoft.com/de-de/windows/win32/direct3d9/view-transform
+Projection Transformation: https://learn.microsoft.com/de-de/windows/win32/direct3d9/projection-transform
+
+Camera Grenze: Near & Far Clipping Plane
+
+Licht:
+- Tiefen wahrnehmen -> Realismus
+- Zum Einbeziehen: Lichtquellen
+	- Directional Light
+	- Point Light
+	- Spot Light
+- Typen:
+	- Ambient Light
+	- Diffuse Light
+	- Specular Light
+	- Emission Light
+- Formel für eine Lichtquelle: Texturen * (Umgebung + Diffuse) + Specular + Emission

Grafik/Hackbarth/Tag1_Bericht.md

@@ -0,0 +1,400 @@
+Fundamentale Architektur: Ein umfassender technischer Leitfaden zu Windows-APIs und der DirectX-Grafikpipeline-Evolution (D3D9 zu D3D11)
+
+TEIL 1: Windows- und C++-Grundlagen für die Grafikanwendung
+
+1. Abstraktion und Ressourcenverwaltung in C++ und Win32
+
+1.1. Pointer versus Handle: Detaillierte Unterschiede, technische Implementation und Verwendungszwecke
+
+Die Unterscheidung zwischen Pointern und Handles ist ein grundlegender Aspekt des Windows-Architekturentwurfs, der die Sicherheit und Stabilität des Betriebssystems gewährleistet.
+
+Ein **Pointer** ist eine direkte, typisierte virtuelle Speicheradresse im User Space. Die Anwendung hat volle Kontrolle über den Speicher, auf den der Pointer verweist, und der C++-Typ (`T*`) definiert, wie der Compiler diesen Speicher interpretiert.[1] Pointer bieten Transparenz und ermöglichen direkten Zugriff, was sie jedoch gefährlich für kritische Systemressourcen macht.
+
+Im Gegensatz dazu ist ein **Handle** (z. B. `HANDLE`, `HWND`) eine **opake Referenz**, die nicht notwendigerweise eine Speicheradresse darstellt.[1] Ein Handle ist ein Pseudo-Pointer, oft als numerischer Wert oder als `void*` Alias implementiert.[2]
+
+**Technische Implementation und Sicherheitsmechanismen:** Handles dienen als Abstraktionsschicht für systemweite Ressourcen (wie Fenster, Dateien oder Device Contexts). Der Windows-Kernel verwendet den Handle-Wert als Index oder ID, um einen Eintrag in einer internen, prozessübergreifenden Handle-Tabelle nachzuschlagen.[3, 4] Dieser Eintrag im Kernel Space enthält die tatsächlichen Adressen und Statusinformationen der Ressource. Dies entkoppelt die Anwendung von der internen Kernel-Struktur.[1] Der entscheidende Vorteil dieser Opazität ist die **Kernel-Sicherheit**: User-Mode-Anwendungen können kritische Systemressourcen nur über gesicherte API-Funktionen, die den Handle validieren, manipulieren.
+
+**Gültigkeitsprüfung und Lebenszyklus:** Da Handles vom Betriebssystem verwaltet werden, ist das Konzept der **Typsicherheit** weniger relevant als bei C++-Pointern; der Typ wird implizit durch die aufrufende API-Funktion bestimmt.[2] Die Verwaltung des Handles durch den Kernel führt zu einem kritischen Problem: **Handle Recycling**. Wenn eine Ressource geschlossen wird (z. B. ein Fenster zerstört), kann der numerische Handle-Wert sofort einer neuen, völlig anderen Ressource zugewiesen werden. Daher ist die einfache Überprüfung eines Handles auf Ungleichheit mit NULL oder `INVALID_HANDLE_VALUE` unzureichend, da ein recycelter Handle scheinbar gültig sein kann, aber auf das falsche Objekt verweist.[5] Die Anwendung ist verpflichtet, den Lebenszyklus des Handles strikt zu verfolgen.
+
+|   |   |   |
+|---|---|---|
+|**Feature**|**C++ Pointer (RAW)**|**Windows Handle (HANDLE, HWND)**|
+|**Natur**|Direkte, typisierte Speicheradresse.|Opaque Reference (Pseudopointer/ID).[1, 3]|
+|**Verwaltungshoheit**|Userspace, manuelle Freigabe.|Kernel Space, Abstraktion von Systemressourcen.[4]|
+|**Typsicherheit**|Streng typisiert (z. B. T∗).|Generisch (void∗/HANDLE); Typ wird durch API-Kontext bestimmt.[2]|
+|**Gültigkeitsprüfung**|Risiko des Handle Recycling; erfordert striktes Lifecycle-Tracking.[5]||
+
+1.2. HWND und andere Windows-Handles: HDC, HINSTANCE, HMODULE
+
+Windows verwendet spezifische Handle-Typen, um verschiedene Ressourcen zu identifizieren:
+
+• **HWND (Handle to a Window):** Der primäre Bezeichner für ein Fenster oder ein Kindfenster-Steuerelement. Er dient als Ziel für Rendering-Operationen und als Adresse für das Windows Message System.[2, 6]
+
+• **HDC (Handle to a Device Context):** Repräsentiert die logische Verbindung zu einem bestimmten Zielgerät (z. B. Bildschirm). Es ist unerlässlich, um GDI- oder ältere Grafik-APIs an ein Fenster zu binden.
+
+• **HINSTANCE (Handle to an Instance):** Repräsentiert die geladene Instanz des Programms.[6] Es wird in der `WNDCLASS`-Struktur benötigt, um die Fensterklasse zu registrieren.[7]
+
+• **HMODULE (Handle to a Module):** Funktional oft identisch mit `HINSTANCE` in modernen Windows-Versionen; es bezeichnet die Basisadresse des geladenen Moduls (EXE oder DLL).
+
+1.3. Windows-Datentypen: DWORD, WORD, BYTE, LPARAM, WPARAM, LRESULT
+
+Die Win32-API definiert aliasierte Datentypen mit expliziter Größe, um die Kompatibilität zwischen 32-Bit- und 64-Bit-Architekturen zu standardisieren.[8]
+
+• **BYTE:** Ein Unsigned 8-Bit-Integer.
+
+• **WORD:** Ein Unsigned 16-Bit-Integer.
+
+• **DWORD (Double Word):** Ein Unsigned 32-Bit-Integer (Bereich: 0 bis 232−1, also 4.294.967.295).[8, 9]
+
+• **WPARAM / LPARAM / LRESULT:** Diese Typen dienen der Übertragung von Informationen in Nachrichten (Window Messages). Während in 16-Bit-Systemen `WPARAM` 16 Bit und `LPARAM` 32 Bit waren, wurden sie in modernen 64-Bit-Systemen auf 64 Bit erweitert. Dies geschieht, damit sie Zeiger (`PVOID`) oder große Werte speichern können, was für die Konsistenz und Zukunftsfähigkeit der API entscheidend ist.[8] `LRESULT` ist der Rückgabewert der Window Procedure.
+
+2. Component Object Model (COM)
+
+Das Component Object Model (COM) bildet das architektonische Rückgrat für Direct3D. Es ist ein binärer Standard, der die Sprache, in der ein Objekt implementiert wurde, abstrahiert.[10]
+
+2.1. Architektur, Interface-Konzept (IUnknown) und Bedeutung für DirectX
+
+**Architektur und Interface-Konzept:** Ein COM-Objekt (`Coclass`) implementiert eine oder mehrere Schnittstellen (`Interfaces`).[10] Jede Schnittstelle ist streng nach dem Prinzip der Vererbung von **IUnknown** abgeleitet. Interfaces sind V-Table-basierte Methodensammlungen. Diese binäre Standardisierung ist notwendig, um die **Application Binary Interface (ABI)** über verschiedene Compiler-Versionen und Programmiersprachen hinweg stabil zu halten.
+
+**Bedeutung für DirectX:** DirectX, beginnend mit Direct3D 8, basiert vollständig auf COM. Jedes kritische API-Objekt in Direct3D, wie beispielsweise `IDirect3DDevice9` oder `ID3D11Device`, ist ein COM-Interface. Dies ermöglicht es Microsoft, die Laufzeitumgebung (Runtime) und die zugrunde liegenden Treiber-Implementierungen zu aktualisieren, ohne dass bestehende Binärcode-Anwendungen neu kompiliert werden müssen.
+
+2.2. Reference Counting (AddRef/Release) und QueryInterface
+
+COM verwendet ein Reference Counting, um den Lebenszyklus des Objekts zu steuern.
+
+• **AddRef/Release:** Das `IUnknown`-Interface exponiert diese Methoden, die einen internen 32-Bit-Referenzzähler steuern.[11] Wenn ein neuer Zeiger auf eine Schnittstelle erstellt oder geklont wird, wird `AddRef` aufgerufen.[11] `Release` dekrementiert den Zähler. Sobald der Zähler Null erreicht, ist das COM-Objekt dafür verantwortlich, seinen eigenen Speicher freizugeben (`self-destruction`).[10] In C++ ist die Nutzung von Smart Pointers (`ComPtr`) die Best Practice, um diese Verwaltung automatisch und fehlerfrei über das RAII-Prinzip sicherzustellen.[10]
+
+• **QueryInterface:** Dies ist der Mechanismus für die dynamische Typerkennung und -navigation innerhalb eines COM-Objekts.[12]
+
+    ◦ Die Methode akzeptiert eine **IID** (Interface Identifier), die ein **GUID** (Globally Unique Identifier) ist.[13]
+
+    ◦ Wenn das Objekt die angeforderte Schnittstelle unterstützt, wird der Zeiger auf diese Schnittstelle zurückgegeben und sofort `AddRef` aufgerufen.[12] Dies ist notwendig, da der neue Zeiger die Lebensdauer des Objekts verlängert.
+
+    ◦ Andernfalls wird der Fehlercode `E_NOINTERFACE` zurückgegeben, was funktionell einem fehlschlagenden C++ DynamicCast entspricht.[13]
+
+2.3. HRESULT, GUID/IID und COM-Initialisierung
+
+• **HRESULT:** Der universelle 32-Bit-Rückgabewert aller COM-Methoden. Er signalisiert den Status des Aufrufs. Werte von Null oder größer (`S_OK`, `S_FALSE`) bedeuten Erfolg, während negative Werte Fehlerzustände darstellen.
+
+• **GUID/IID:** Die 128-Bit-Bezeichner (Global Unique Identifiers), die die Eindeutigkeit von COM-Klassen (`CLSID`) und deren Schnittstellen (`IID`) garantieren. Diese Uniqueness ist entscheidend für das dynamische Laden von Komponenten.
+
+• **COM-Initialisierung (CoInitializeEx):** Bevor ein Thread COM-Interfaces verwenden oder Komponenten instanziieren kann, muss er die COM-Bibliothek initialisieren, indem er `CoInitializeEx` aufruft.[14] Die Funktion ist pro Thread erforderlich. Der zweite Parameter (`dwCoInit`) legt das Threading-Modell fest:
+
+    ◦ **COINIT_APARTMENTTHREADED (STA):** Apartment Threading. Erfordert die Garantie, dass auf COM-Objekte nur über einen einzigen Thread zugegriffen wird, und setzt voraus, dass der Thread eine **Nachrichtenschleife** (`Message Loop`) besitzt.[14]
+
+    ◦ **COINIT_MULTITHREADED (MTA):** Multi-Threading. Erlaubt den Zugriff über mehrere Threads, erfordert jedoch eine komplexe Synchronisation.
+
+Die Anforderung, dass STA-Threads eine Message Loop besitzen müssen, schafft eine direkte kausale Verbindung zwischen dem Windows Message System und der korrigierten COM-Nutzung: wenn der Haupt-Thread einer Grafikanwendung als STA initialisiert wird (was üblich ist, da er das Fenster erstellt), muss die Message Loop (`GetMessage` oder `PeekMessage`) korrekt funktionieren, um auch interne COM-Synchronisationsnachrichten zu verarbeiten.[14]
+
+3. Das Windows-Nachrichtensystem (Message System)
+
+Das Nachrichtensystem ist der Kernmechanismus der Event-driven Programming in Windows und steuert den Lebenszyklus sowie die Interaktion der Anwendung.
+
+3.1. Window Creation: WNDCLASS, RegisterClass, CreateWindow, ShowWindow
+
+Die Erstellung eines Fensters folgt einer strikten Sequenz:
+
+1. **WNDCLASS/WNDCLASSEX:** Definition der Fensterklasse. Die Struktur enthält kritische Elemente wie das Handle der Anwendung (`hInstance`), den Klassennamen (`lpszClassName`) und, am wichtigsten, den Funktionszeiger zur **Window Procedure** (`lpfnWndProc`).[7]
+
+2. **RegisterClass/RegisterClassEx:** Registriert die definierte Klasse beim Betriebssystem.[7]
+
+3. **CreateWindow/CreateWindowEx:** Erstellt eine Instanz der registrierten Klasse und gibt das `HWND` (Handle to a Window) zurück.
+
+4. **ShowWindow / UpdateWindow:** Macht das Fenster sichtbar. `UpdateWindow` sendet die erste `WM_PAINT`-Nachricht, um den Client-Bereich zu zeichnen.
+
+3.2. Message Queue und Window Procedure
+
+Das System arbeitet über dedizierte Message Queues pro Thread.
+
+• **Message Loop:** Die Anwendung muss kontinuierlich Nachrichten aus ihrer Queue abrufen. Die Wahl der Abruffunktion ist entscheidend für die Anwendungsarchitektur:
+
+    ◦ **GetMessage():** Dies ist ein **blockierender** Aufruf. Wenn die Queue leer ist, hält der Thread an, bis eine Nachricht verfügbar ist.[15] Dies ist für traditionelle UI-Anwendungen geeignet, aber in Echtzeit-Anwendungen (Game Loops) unbrauchbar, da es keine Idle Processing (Rendern) zulässt.
+
+    ◦ **PeekMessage():** Dies ist ein **nicht-blockierender** Aufruf. Er kehrt sofort zurück, unabhängig davon, ob eine Nachricht in der Queue gefunden wurde.[15, 16] Wenn `PeekMessage` `FALSE` zurückgibt, kann die Anwendung sofort zur Real-Time-Rendering-Logik übergehen ("Idle Processing").[15]
+
+• **DispatchMessage und TranslateMessage:**
+
+    ◦ `TranslateMessage` verarbeitet virtuelle Tastatur-Codes und generiert `WM_CHAR`-Nachrichten.
+
+    ◦ `DispatchMessage` leitet die Nachricht an die Window Procedure (`WndProc`) des korrespondierenden `HWND` weiter.
+
+• **DefWindowProc:** Nachrichten, die die Anwendung nicht explizit behandelt, müssen an `DefWindowProc` zurückgegeben werden.[17] Diese Funktion stellt das standardmäßige, vom Betriebssystem erwartete Verhalten (z. B. Verschieben des Fensters, Minimieren) sicher.
+
+3.3. Windows Message System: WM_QUIT, WM_DESTROY, WM_CLOSE, WM_PAINT, WM_SIZE
+
+Die geordnete Behandlung von Fensternachrichten ist für die Stabilität von Grafikanwendungen fundamental.
+
+• **WM_CLOSE:** Eine höfliche **Anfrage** zur Beendigung, die gesendet wird, wenn der Benutzer auf das Schließen-Symbol klickt. Die Anwendung kann diese Anfrage ablehnen (z. B. um den Benutzer zum Speichern aufzufordern).[18] Die Standardreaktion ist der Aufruf von `DestroyWindow`.[18]
+
+• **WM_DESTROY:** Ein Signal, das an das Fenster gesendet wird, nachdem es vom Bildschirm entfernt wurde, aber bevor seine Ressourcen (einschließlich Kindfenster) freigegeben werden.[19] Dies ist der Zeitpunkt, an dem alle Direct3D-Ressourcen, die direkt dem Fenster zugeordnet sind (wie die Swap Chain), freigegeben werden müssen.[18] Für das Hauptanwendungsfenster wird hier typischerweise `PostQuitMessage(0)` aufgerufen.[17, 19]
+
+• **WM_QUIT:** Dies ist **keine Fensternachricht**; sie wird direkt in die Thread-Queue eingefügt und dient ausschließlich dazu, die Message Loop zu beenden. Wenn `GetMessage` diese Nachricht abruft, gibt es 0 zurück und terminiert damit die Schleife.[18]
+
+• **WM_SIZE:** Wird gesendet, wenn die Abmessungen des Client-Bereichs geändert wurden. Dies ist der kritische Hook, um die Rendering-Infrastruktur neu zu konfigurieren: die Viewport-Größe muss angepasst und die Swap-Chain (Backbuffer) muss neu dimensioniert werden.
+
+• **WM_PAINT:** Signalisiert einen ungültigen Bereich, der neu gezeichnet werden muss. `WM_SIZE` wird typischerweise von einem `WM_PAINT`-Aufruf gefolgt.[20] In einem Game Loop, der kontinuierlich rendert, wird `WM_PAINT` oft ignoriert, da das Rendern bereits im Idle Processing stattfindet.
+
+TEIL 2: Theoretische und Praktische Grafikpipeline-Architekturen
+
+4. Die Evolution der Rendering-Pipelines
+
+Die Entwicklung der Grafikhardware hat zu einem Paradigmenwechsel von der Fixed Function Pipeline (FFP) zur modernen Programmable Pipeline (PP) geführt.
+
+4.1. Fixed Function Pipeline (FFP)
+
+Die FFP, wie sie in älteren OpenGL- und Direct3D-Versionen (bis D3D9 im FFP-Modus) verwendet wurde, war eine starre Kette von Verarbeitungsstufen.[21] Ihre Logik war im Grafikprozessor (GPU) hartkodiert und konnte nur durch das Setzen von Render States konfiguriert werden.[22]
+
+**Stages und Limitierungen:**
+
+• **Vertex Processing und Lighting (T&L):** Die Geometrie-Transformation und die Beleuchtungsberechnungen (typischerweise Blinn-Phong-Modell) waren fixiert und erfolgten pro Vertex.[22] Die mangelnde Flexibilität bedeutete, dass keine benutzerdefinierten Beleuchtungsmodelle oder realistisches Per-Pixel-Lighting möglich waren.[23]
+
+• **Texture Stages (Combiner):** Anstelle programmierbarer Pixel Shader wurde ein komplexes System von Textur-Umgebungen und Combinern verwendet, um festzulegen, wie mehrere Texturen und Farben gemischt werden.[22]
+
+• **Steuerung:** Die Steuerung erfolgte über Tausende von API-Aufrufen, die den internen Zustand der GPU änderten, wie `IDirect3DDevice9::SetRenderState`.[24]
+
+• **Limitierungen:** Die größte Einschränkung war die Unmöglichkeit, neue Algorithmen zu implementieren. Anspruchsvolle Effekte erforderten ineffizientes Multi-Pass-Rendering und komplexe "Cubemap magic".[23]
+
+4.2. Programmable Pipeline (PP)
+
+Die Programmable Pipeline ersetzte starre Stufen durch Shader-Programme, die direkt auf der GPU ausgeführt werden.
+
+**Shader-basierte Flexibilität und Vorteile:** Die Einführung von Vertex Shadern (VS) und Pixel Shadern (PS) ermöglichte es Entwicklern, die Transformations- und Beleuchtungslogik vollständig neu zu definieren. Die Flexibilität erlaubt:
+
+1. **Per-Pixel Beleuchtung:** Deutlich realistischere Beleuchtung, die im Pixel Shader berechnet wird.[23]
+
+2. **Reduzierte Draw Calls:** Komplexe Materiallogik, die früher mehrere FFP-Pässe erforderte, kann in einem einzigen Shader zusammengefasst werden, was den Zustandwechsel-Overhead reduziert.[23]
+
+3. **Moderne Architekturen:** Die PP ist die Basis für Tessellation (Hull/Domain Shaders, ab SM 5.0) und GPGPU-Computing (Compute Shaders).
+
+**Shader-Kompilierung:** HLSL (High-Level Shading Language) wird von der Entwicklungsumgebung in einen hardwareunabhängigen Bytecode kompiliert. Die Grafik-Runtime (DirectX-Treiber) übersetzt diesen Bytecode zur Laufzeit in Maschinencode für die spezifische GPU-Architektur.
+
+4.3. Vergleich beider Pipelines
+
+Die PP ist nicht in jeder Hinsicht schneller als die FFP. Wenn ein Entwickler einen Shader schreibt, der exakt die gleiche einfache Beleuchtungslogik der FFP implementiert, könnte die FFP aufgrund ihrer extremen Hardware-Optimierung leicht überlegen sein.[23] Die wahre Leistungssteigerung der PP liegt in der Möglichkeit, komplexe Effekte in wenigen Durchgängen zu realisieren, die in der FFP nur durch viele Pässe oder gar nicht möglich wären.
+
+Tabelle 4.1: Vergleich von Fixed Function Pipeline (FFP) und Programmable Pipeline (PP)
+
+|   |   |   |
+|---|---|---|
+|**Kriterium**|**Fixed Function Pipeline (D3D9 Legacy)**|**Programmable Pipeline (D3D11)**|
+|**Flexibilität**|Gering, nur Konfiguration über Zustände.[21]|Sehr hoch, benutzerdefinierte Shader-Programme.[23]|
+|**Beleuchtung**|Per-Vertex, hartkodiert (z. B. Blinn-Phong).[22]|Per-Pixel, frei definierbar, hochrealistisch.[23]|
+|**Zustandsverwaltung**|Hoher CPU-Overhead durch viele `SetRenderState`-Aufrufe.[25]|Effizient durch Immutable State Objects und konstanten Datenaustausch.[26]|
+|**Use Cases**|Einfache 3D-Anwendungen, Legacy-Support.|Moderne Spiele, erweiterte Physik, GPGPU-Computing.|
+
+5. Geometrie-Verarbeitung und Transformation
+
+5.1. Vertex: Struktur, Attribute und Deklaration
+
+Ein Vertex ist die fundamentale Dateneinheit, die die Geometrie und deren Eigenschaften definiert.
+
+**Attribute:** Neben der **Position** (XYZ) im lokalen Raum gehören dazu:
+
+• **Normalen:** Richtungsvektoren, die für die Berechnung der Beleuchtung pro Vertex oder zur Interpolation für den Pixel Shader notwendig sind.[27]
+
+• **Tangenten und Binormalen:** Werden benötigt, um das lokale TBN-Koordinatensystem (Tangent, Binormal, Normal) für Effekte wie Normal Mapping zu definieren.[27]
+
+• **Texturkoordinaten (TexCoord/UV Sets):** Definieren, wie Texturdaten auf die Oberfläche abgebildet werden.[27]
+
+**Vertex Declaration und FVF:**
+
+• **FVF (Flexible Vertex Format):** In Direct3D 9 verwendete ein kompaktes Bit-Flag-Schema (`D3DFVF_XYZ | D3DFVF_NORMAL`), um den Inhalt eines Vertex zu definieren. Es war einfach, aber unflexibel für benutzerdefinierte Attribute.[28, 29]
+
+• **Input Layout (D3D11):** Im modernen Pipeline-Ansatz wird ein explizites `Input Layout` erstellt, das das Speicher-Layout des Vertex-Buffers mit der Eingabesignatur des Vertex Shaders (definiert durch Semantics wie `POSITION0`, `TEXCOORD1`) abgleicht.[29] Dies bietet eine präzisere und typsicherere Methode zur Datenübergabe.
+
+5.2. Mesh: Definition, Organisation und Index-Nutzung
+
+Ein Mesh ist die Organisation der Geometriedaten. Die effizienteste Organisation beinhaltet **Vertex-Sharing** durch die Verwendung eines **Index Buffers**.[30]
+
+• **Definition und Organisation:** Ein Mesh besteht aus einem Vertex Buffer (die eigentlichen Datenpunkte) und einem optionalen Index Buffer (die Reihenfolge, in der die Vertices verarbeitet werden sollen).[30]
+
+• **Index-Nutzung:** Anstatt die gleichen Vertex-Daten für mehrere benachbarte Dreiecke zu duplizieren (z. B. an einer Kante), enthält der Index Buffer nur die Indizes der Vertices, die das Dreieck bilden. Dies reduziert die Speichernutzung drastisch und verbessert die Effizienz des Post-Transform Vertex Cache auf der GPU, da Vertices, die bereits transformiert wurden, wiederverwendet werden können.[30]
+
+5.3. Transformation: Model-, View-, Projection-Matrix
+
+Die Grafikpipeline transformiert Vertices durch eine Reihe von Koordinatensystemen mithilfe von Matrizen.
+
+• **Model-Matrix (M):** Transformiert von Local/Object Space in World Space (Position, Rotation, Skalierung des Objekts).[31]
+
+• **View-Matrix (V):** Transformiert von World Space in View/Camera Space (Positionierung und Ausrichtung der Kamera).[31]
+
+• **Projection-Matrix (P):** Transformiert von View Space in den Homogenen Clip Space. Sie definiert das Sichtvolumen (Frustum) und wendet die perspektivische Verzerrung an.[31]
+
+**MVP-Matrix und Multiplikationsreihenfolge:** Die Gesamttransformation wird oft in einer einzigen Matrix, der MVP-Matrix (P×V×M), zusammengefasst. Wenn der Vektor V![](data:image/svg+xml;utf8,<svg%20xmlns="http://www.w3.org/2000/svg"%20width="0.471em"%20height="0.714em"%20style="width:0.471em"%20viewBox="0%200%20471%20714"%20preserveAspectRatio="xMinYMin"><path%20d="M377%2020c0-5.333%201.833-10%205.5-14S391%200%20397%200c4.667%200%208.667%201.667%2012%2053.333%202.667%206.667%209%2010%2019%206.667%2024.667%2020.333%2043.667%2041%2057%207.333%204.667%201110.667%2011%2018%200%206-1%2010-3%2012s-6.667%205-14%209c-28.667%2014.667-53.667%2035.667-75%2063-1.333%201.333-3.167%203.5-5.5%206.5s-4%204.833-5%205.5c-1%20.667-2.5%201.333-4.5%202s-4.333%201-7%201c-4.667%200-9.167-1.833-13.5-5.5S337%20184%20337%20178c0-12.667%2015.667-32.333%2047-59H213l-171-1c-8.667-6-13-12.333-13-19%200-4.667%204.333-11.333%2013-20h359c-16-25.333-24-45-24-59z"></path></svg>)local​ als Spaltenvektor multipliziert wird, lautet die korrekte Reihenfolge der Operationen: V![](data:image/svg+xml;utf8,<svg%20xmlns="http://www.w3.org/2000/svg"%20width="0.471em"%20height="0.714em"%20style="width:0.471em"%20viewBox="0%200%20471%20714"%20preserveAspectRatio="xMinYMin"><path%20d="M377%2020c0-5.333%201.833-10%205.5-14S391%200%20397%200c4.667%200%208.667%201.667%2012%2053.333%202.667%206.667%209%2010%2019%206.667%2024.667%2020.333%2043.667%2041%2057%207.333%204.667%201110.667%2011%2018%200%206-1%2010-3%2012s-6.667%205-14%209c-28.667%2014.667-53.667%2035.667-75%2063-1.333%201.333-3.167%203.5-5.5%206.5s-4%204.833-5%205.5c-1%20.667-2.5%201.333-4.5%202s-4.333%201-7%201c-4.667%200-9.167-1.833-13.5-5.5S337%20184%20337%20178c0-12.667%2015.667-32.333%2047-59H213l-171-1c-8.667-6-13-12.333-13-19%200-4.667%204.333-11.333%2013-20h359c-16-25.333-24-45-24-59z"></path></svg>)clip​=P×V×M×V![](data:image/svg+xml;utf8,<svg%20xmlns="http://www.w3.org/2000/svg"%20width="0.471em"%20height="0.714em"%20style="width:0.471em"%20viewBox="0%200%20471%20714"%20preserveAspectRatio="xMinYMin"><path%20d="M377%2020c0-5.333%201.833-10%205.5-14S391%200%20397%200c4.667%200%208.667%201.667%2012%2053.333%202.667%206.667%209%2010%2019%206.667%2024.667%2020.333%2043.667%2041%2057%207.333%204.667%201110.667%2011%2018%200%206-1%2010-3%2012s-6.667%205-14%209c-28.667%2014.667-53.667%2035.667-75%2063-1.333%201.333-3.167%203.5-5.5%206.5s-4%204.833-5%205.5c-1%20.667-2.5%201.333-4.5%202s-4.333%201-7%201c-4.667%200-9.167-1.833-13.5-5.5S337%20184%20337%20178c0-12.667%2015.667-32.333%2047-59H213l-171-1c-8.667-6-13-12.333-13-19%200-4.667%204.333-11.333%2013-20h359c-16-25.333-24-45-24-59z"></path></svg>)local​ Die Transformationen werden in der Reihenfolge M, dann V, dann P angewendet.[32] Während eine Vorberechnung der gesamten MVP-Matrix im Vertex Shader Rechenzeit sparen kann, erfordern die Transformation von Normalen oder Tangenten zusätzliche Matrizen (z. B. nur M oder V×M).[33]
+
+**Handedness (DirectX Left-Handed):** DirectX verwendet standardmäßig ein linkshändiges Koordinatensystem, bei dem die positive Z-Achse in die Szene hinein zeigt. Dies ist eine kritische Designentscheidung, die sich auf die Definition der View- und Projection-Matrizen sowie auf die Winding Order (für das Culling) auswirkt.
+
+5.4. Coordinate Spaces
+
+Die Transformationskette definiert die folgenden fünf kritischen Räume:
+
+1. **Local/Object Space:** Koordinaten relativ zum Ursprung des 3D-Modells.
+
+2. **World Space:** Koordinaten relativ zum globalen Ursprung der Szene (nach M).
+
+3. **View/Camera Space (Eye Space):** Koordinaten relativ zur Position der virtuellen Kamera (nach V).[31]
+
+4. **Clip Space (Homogeneous Coordinates):** Koordinaten im Bereich von (wobei W die perspektivische Tiefe ist) (nach P).[31] Clipping und perspektivische Division erfolgen hier.
+
+5. **Screen Space (Viewport):** Die endgültigen 2D-Pixelkoordinaten, nachdem die Viewport-Transformation die normalisierten Koordinaten (NDC, Normalized Device Coordinates, [−1,1]) in den tatsächlichen Bildschirmbereich konvertiert hat.[34]
+
+6. Primitive Assembly und Rasterization Stage
+
+6.1. Primitives: List, Strip, Fan und Effizienz
+
+Die Input Assembler (IA) Stage setzt die Vertices, unter Verwendung der Indizes, zu Primitiven zusammen.
+
+• **Point List, Line List/Strip:** Grundlegende Topologien.
+
+• **Triangle List:** Dreiecke sind voneinander unabhängig (z. B. V0​,V1​,V2​;V3​,V4​,V5​). Für N Dreiecke sind 3N Vertices erforderlich.
+
+• **Triangle Strip und Triangle Fan:** Diese Topologien maximieren die Vertex-Wiederverwendung und sind daher effizienter. Für N Vertices generieren sowohl Strips als auch Fans N−2 Dreiecke (N≥3).[35, 36]
+
+    ◦ **Triangle Strip:** Jedes neue Dreieck teilt sich die letzten beiden Vertices mit dem vorherigen. Ideal für zusammenhängende Oberflächen wie Geländebänder oder Zylinderseiten.[35]
+
+    ◦ **Triangle Fan:** Alle Dreiecke teilen sich den ersten Vertex. Ideal für konvexe Polygone oder Zylinderkappen.[35]
+
+6.2. Rasterizer Stage
+
+Die Rasterizer Stage (RS) ist der feste Teil der Pipeline, der Vektorgeometrie in rasterbasierte Fragmente (potenzielle Pixel) umwandelt.[37, 38]
+
+**Operationen:**
+
+• **Clipping:** Primitiven, die teilweise außerhalb des Sichtvolumens (Clip Space) liegen, werden zugeschnitten, während vollständig außerhalb liegende Primitiven verworfen werden.[37]
+
+• **Culling und Winding Order:** Back-Face Culling verwirft Dreiecke, deren Winding Order (Reihenfolge der Vertices, z. B. CW oder CCW) angibt, dass sie von der Kamera abgewandt sind. Dies reduziert die zu verarbeitende Geometrie frühzeitig.
+
+• **Viewport-Transformation:** Die 3D-Koordinaten werden in 2D-Bildschirmkoordinaten umgewandelt.[34, 38]
+
+• **Triangle Rasterization:** Algorithmen (z. B. Scan-Line oder Edge Functions) bestimmen, welche Pixel auf dem Bildschirm vom Dreieck bedeckt sind. Die **Top-Left Fill Convention** stellt sicher, dass benachbarte Dreiecke keine überlappenden Pixel erzeugen.[39]
+
+• **Interpolation von Vertex-Attributen:** Attribute (Farbe, UVs, Normalen, Tiefe) werden über die Fläche des Dreiecks interpoliert und dem generierten Fragment zugewiesen. Dies geschieht typischerweise mithilfe von **Barycentric Coordinates**, um eine perspektivisch korrekte Interpolation zu gewährleisten.[39]
+
+7. Output Merger (OM)
+
+Der Output Merger (OM) ist die letzte Stufe der Pipeline, die entscheidet, wie und ob das generierte Fragment die Zielpuffer (Framebuffers) beeinflusst.
+
+• **Screen Stage und Framebuffers:** Die Render-Ziele bestehen aus dem **Frame Buffer** (Farbe), dem **Depth Buffer** (Z-Buffer, Speicherung der Tiefe) und dem **Stencil Buffer** (logische Maskierung).
+
+• **Depth Buffer (Z-Buffer):** Speichert den Tiefenwert des nächstgelegenen Pixels. Der **Depth Test** vergleicht die Tiefe des eingehenden Fragments mit dem Wert im Depth Buffer. Wenn das Fragment den Test besteht (z. B. näher liegt), darf es fortfahren. Das Deaktivieren des Z-Buffer-Schreibens kann eine Optimierung sein, wenn sichergestellt ist, dass die Objekte in einer bestimmten Reihenfolge (z. B. Depth First) gerendert werden.[26]
+
+• **Stencil Buffer:** Wird für komplexe Maskierungseffekte, Portale oder Schattenvolumina verwendet. Der **Stencil Test** wendet benutzerdefinierte logische Regeln an.
+
+• **Blending:** Nach den Tests kombiniert der OM die Farbe des Fragments mit der bereits im Render Target vorhandenen Farbe (z. B. für Transparenz oder additive Effekte).[26]
+
+• **Multi-Render-Targets (MRT):** Ermöglicht das gleichzeitige Schreiben in mehrere Farbpuffer (Texturen) in einem einzigen Durchgang. Dies ist fundamental für Techniken wie Deferred Shading, bei dem Normalen, Tiefen und Materialeigenschaften in separate Texturen (G-Buffer) geschrieben werden.
+
+TEIL 3: DirectX-Versionsvergleich und API-Migration
+
+8. Direct3D 9: Die monolithische Ära
+
+Direct3D 9 (D3D9) war die vorherrschende API für über ein Jahrzehnt und zeichnete sich durch einen monolithischen Ansatz aus, der sowohl FFP als auch die frühen Shader Models (bis SM 3.0) unterstützte.
+
+• **Device-Konzept und Immediate Mode:**
+
+    ◦ Das gesamte API-Management war in der einzigen zentralen Schnittstelle, `IDirect3DDevice9`, gebündelt.[40] Dieses Device war für die Ressourcenerstellung, das Setzen von Zuständen und die Ausführung von Draw Calls verantwortlich.
+
+    ◦ Dieses Design erzwang den sogenannten **Immediate Mode**, bei dem Befehle sofort zur Ausführung an den Treiber gesendet wurden. Dies verursachte Engpässe auf modernen Multi-Core-CPUs, da alle API-Aufrufe notwendigerweise sequenziell auf einem einzigen Thread synchronisiert werden mussten.
+
+• **API-Struktur und Initialisierung:**
+
+    ◦ Die Initialisierung erforderte die Erstellung des `IDirect3D9`-Objekts (API-Zugriff), die Auswahl eines Adapters und den Aufruf von `IDirect3D9::CreateDevice` mit den `D3DPRESENT_PARAMETERS`, welche die Backbuffer- und Fenster-Einstellungen enthielten.[17]
+
+• **Pipeline-Steuerung und FFP-Zustände:**
+
+    ◦ Die Steuerung der Pipeline erfolgte über Funktionen wie `IDirect3DDevice9::SetVertexShader` und `IDirect3DDevice9::SetPixelShader`.
+
+    ◦ Die Fixed Function Pipeline wurde mittels `SetRenderState` konfiguriert (z. B. `D3DRS_LIGHTING`, `D3DRS_CULLMODE`).[24]
+
+• **Ressourcen-Handling:**
+
+    ◦ Buffers (`CreateVertexBuffer`, `CreateIndexBuffer`) wurden erstellt und der Zugriff vom CPU-Speicher auf den GPU-Speicher für Updates erfolgte über die Methoden **Lock und Unlock**. `Lock` war oft ein blockierender Aufruf, der erhebliche Performance-Stalls verursachen konnte, da er Synchronisation mit der GPU erzwingen musste.
+
+9. Direct3D 11: Moderne, Multithread-fähige Architektur
+
+Direct3D 11 (D3D11) führte eine tiefgreifende architektonische Umstrukturierung ein, um die Skalierbarkeit auf Multi-Core-CPUs zu gewährleisten und modernere Shader Models zu unterstützen.
+
+9.1. Trennung Device vs. Device Context
+
+Die wichtigste Neuerung war die funktionale Trennung der Verantwortlichkeiten:
+
+• **ID3D11Device:** Das Device ist thread-sicher und dient ausschließlich der **Erstellung von Ressourcen** (Buffers, Texturen, Views, State Objects) und der Abfrage von Hardware-Fähigkeiten.[40]
+
+• **ID3D11DeviceContext:** Der Context ist für die **Setzung des Pipeline-Zustands** (State Binding) und die **Generierung von Render-Befehlen** (`Draw Calls`) zuständig.[40]
+
+**Multithreading-Vorteile (Deferred Context):** Diese Trennung ermöglichte echtes Multithreading. Ein **Immediate Context** wird vom Haupt-Thread verwendet. Zusätzlich können **Deferred Contexts** auf Worker-Threads verwendet werden, um Render-Befehle und State-Bindungen parallel vorzubereiten. Die Ergebnisse dieser parallelen Arbeit werden in **Command Lists** gespeichert. Diese Command Lists können anschließend schnell vom Immediate Context eingereicht werden, was die CPU-Last für das Rendering effizient über mehrere Kerne verteilt und die Framerate in CPU-gebundenen Szenarien verbessert.[41]
+
+9.2. DXGI und Feature Levels
+
+• **DXGI (DirectX Graphics Infrastructure):** Eine dedizierte API-Schicht, die von Direct3D entkoppelt wurde, um allgemeine Grafik-Infrastrukturaufgaben zu übernehmen. DXGI verwaltet Adapter-Enumeration, Multi-Monitor-Konfiguration und die **Swap Chain**.[40, 42]
+
+• **Feature Levels:** D3D11 führte Feature Levels (9_1 bis 11_1) ein, um die Komplexität der Hardware-Erkennung zu standardisieren.[41, 43] Ein Entwickler kann `D3D11CreateDevice` aufrufen und den maximal benötigten Feature Level anfordern (z. B. 11_0). Die Runtime wählt das höchste unterstützte Level auf der Hardware. Dies bedeutet, dass D3D11-Code auf D3D9-Hardware laufen kann (z. B. Feature Level 9_3), wobei automatisch die entsprechenden Einschränkungen (z. B. Shader Model 3.0, keine Geometry Shader) beachtet werden.[41]
+
+9.3. Ressourcen-Management und Views-Konzept
+
+D3D11 implementiert ein striktes, auf Views basierendes Ressourcen-Binding-System.
+
+• **Ressourcen und Views:** Die zugrundeliegenden Ressourcen (Buffers, Texturen) müssen über eine explizite **View** an die Pipeline gebunden werden.[40]
+
+    ◦ **SRV (Shader Resource View):** Lesezugriff in Shadern.
+
+    ◦ **RTV (Render Target View):** Schreibzugriff in der Output Merger Stage (Farbe).
+
+    ◦ **DSV (Depth Stencil View):** Zugriff auf Tiefen- und Stencil-Puffer.
+
+    ◦ **UAV (Unordered Access View):** Ungeordnete Lese-/Schreibzugriffe (für Compute Shaders).[44, 45]
+
+    ◦ **Konfliktvermeidung:** Das System verhindert, dass dieselbe Ressource gleichzeitig als Lese- (SRV) und Schreib-Ressource (RTV/UAV) an dieselbe Pipeline-Stufe gebunden wird.[45]
+
+• **Input Assembler (IA) und Input Layout:** Die IA-Stage ist verantwortlich für das Binden des Vertex- und Index-Buffers. Das **Input Layout** ist dabei die zwingend notwendige Metadaten-Beschreibung, die festlegt, wie die Bits des Vertex-Buffers dem Vertex Shader zugeordnet werden (Ablösung des FVF-Systems).[28]
+
+10. Detaillierter Vergleich und Migrationspfad (D3D9 vs. D3D11)
+
+Der Übergang von D3D9 zu D3D11 stellt einen bedeutenden architektonischen Wandel dar.[46]
+
+10.1. API-Calls und Initialisierung-Unterschiede
+
+|   |   |   |
+|---|---|---|
+|**Merkmal**|**Direct3D 9**|**Direct3D 11**|
+|**API-Initialisierung**|Multi-Schritt-Prozess: `Direct3DCreate9` → `CreateDevice`.|Einzelfunktion: `D3D11CreateDevice` (erstellt Device und Context).[40]|
+|**Swap Chain**|Implizit im Device-Objekt enthalten.|Gemanagt durch separate DXGI-Schnittstelle.[40]|
+|**Draw-Calls**|`IDirect3DDevice9::DrawPrimitive`.|`ID3D11DeviceContext::Draw` (über Context aufgerufen).|
+
+10.2. State-Management (State Objects vs SetRenderState)
+
+Dies ist der tiefgreifendste Paradigmenwechsel.
+
+• **D3D9 (Zustands-Imperativ):** Der Entwickler setzte Zustände (Culling, Blending, Tiefentest) dynamisch zur Laufzeit mithilfe zahlreicher `SetRenderState`-Aufrufe. Jede dieser Änderungen war ein API-Aufruf, der potenziell hohen Treiber-Overhead verursachte, da die GPU-Pipeline-Konfiguration häufig neu berechnet werden musste.[25]
+
+• **D3D11 (Zustands-Deklarativ / State Objects):** Alle fixen Pipeline-Zustände werden in unveränderlichen Objekten (`ID3D11RasterizerState`, `ID3D11DepthStencilState`) gekapselt und einmalig erstellt.[40] Zur Laufzeit bindet der Context diese Objekte als Ganzes. Dies ermöglicht dem Treiber eine bessere interne Voroptimierung und reduziert den Aufwand für Zustandswechsel im Rendering-Loop drastisch.
+
+10.3. Shader-Handling und Ressourcen-Binding
+
+• **Shader Model 3.0 vs 5.0:** D3D9 war auf SM 3.0 beschränkt, was keine Tessellation oder Compute Shaders unterstützte. SM 5.0 (D3D11) fügte diese modernen Stufen hinzu und erhöhte die Komplexität und Größe der Shader-Programme erheblich.[41]
+
+• **Constant Buffers vs Constants:** Anstelle der begrenzten, einfachen Konstantenregister von D3D9 verwendet D3D11 **Constant Buffers (C-Buffers)**. Dies sind strukturierte Ressourcen, die effizient über `ID3D11DeviceContext::Map`/`Unmap` von der CPU aktualisiert werden können, was das Daten-Streaming zur GPU verbessert.
+
+10.4. Migration-Aspekte
+
+Der Wechsel von D3D9 zu D3D11/D3D10 ist ein signifikanter Bruch, da die grundlegenden Annahmen über State Management und Datenfluss sich ändern.[46]
+
+• **Architektonische Vorbereitung:** Experten empfehlen, die D3D9-API-Aufrufe so früh wie möglich durch eine eigene Abstraktionsschicht zu isolieren. Dies minimiert den Umfang der Code-Änderungen, wenn Konzepte wie Input Layout und State Objects eingeführt werden müssen.[46]
+
+• **Performance-Implikationen:** Die primäre Performance-Steigerung bei der Migration zu D3D11 wird oft durch die verbesserte CPU-Skalierung (Multithreading via Deferred Contexts) und die effizientere Zustandsverwaltung (State Objects) erzielt.[47]
+
+• **Deprecations:** Das Flexible Vertex Format (FVF) und die Fixed Function Pipeline wurden in D3D11 vollständig abgeschafft. Anwendungen müssen die FFP-Logik in Shader-Code (Vertex und Pixel Shader) portieren.
+
+• **HLSL-Syntax-Unterschiede:** Während HLSL in seiner Basis ähnlich bleibt, erfordert D3D11 die Verwendung von Puffer-Semantiken und konstanten Puffer-Definitionen, die in D3D9 nicht existierten.
+
+Schlussfolgerung
+
+Die evolutionäre Analyse von Windows-Grafikprogrammierung, von den Win32-Fundamentals bis zur Direct3D-Architektur, zeigt einen klaren Trend: die Verschiebung von einer **imperativen, CPU-zentrierten Steuerung** hin zu einer **deklarativen, GPU-zentrierten Programmierung**.
+
+In der Windows-Grundlagenarchitektur dient die Opazität von Handles und die Struktur des Component Object Model (COM) der Durchsetzung der Kernel-Integrität und der binären Stabilität der API. Die korrekte Interaktion mit dem Message System, insbesondere die Wahl zwischen `GetMessage` und `PeekMessage`, ist der notwendige Mechanismus, der es der Anwendung ermöglicht, sowohl auf Events zu reagieren als auch Echtzeit-Idle-Processing (Rendering) durchzuführen.
+
+Der Wandel von der Fixed Function Pipeline zu den programmierbaren Shadern in Direct3D 11 ist die Antwort auf die Notwendigkeit flexiblerer und realistischerer Grafikeffekte. Die D3D11-Architektur löst die Performance-Probleme von D3D9, indem sie die monolithische Steuerung in separate Device- und Context-Objekte zerlegt. Diese Trennung und die Einführung von Immutable State Objects sind die technologischen Voraussetzungen für die Skalierbarkeit des Rendering-Workloads über moderne Multi-Core-CPUs. Entwickler, die von D3D9 migrieren, müssen diese architektonischen Verschiebungen – von dynamischem State Management zu deklarativen State Objects und von FVF zu Input Layouts – vollständig adaptieren, um die Performance-Vorteile der modernen Hardware voll auszuschöpfen.
+
+![[TTS/Tag1_Bericht - Dec 16 2025 14-25.mp3]]
+
+![[TTS/Tag1_Bericht - Dec 16 2025 14-32.mp3]]

Grafik/Hackbarth/Tag2_Bericht.md

@@ -0,0 +1,200 @@
+Detaillierte Analyse der GPU-Pipeline in DirectX: Shader, Beleuchtung und Texturierung
+
+Dieser Bericht dient als umfassende Lernressource und prüfungsrelevante Aufbereitung der Kernkonzepte des Real-Time Renderings in Direct3D. Er beleuchtet die Architektur programmierbarer Shader-Stufen, die Implementierung physisch basierter Beleuchtungsmodelle und die Optimierung von Textur-Streaming und Qualität.
+
+TEIL 1: Erweiterte Shader-Programmierung in DirectX
+
+Die programmierbaren Shader-Stufen bilden das Rückgrat der modernen DirectX-Pipeline und ermöglichen eine hochgradig flexible und parallele Verarbeitung von Geometrie und Pixeldaten.
+
+1.1 Die Sechs Programmierbaren Shader-Typen
+
+Die Pipeline in Direct3D ist modular aufgebaut und bietet sechs programmierbare Stufen, die jeweils spezifische Aufgaben in der Datenverarbeitung von den initialen Vertices bis zum finalen Pixel übernehmen.
+
+1.1.1 Vertex Shader
+
+Der Vertex Shader ist eine obligatorische Stufe in der minimalen Rendering-Pipeline. Er wird einmal pro Vertex ausgeführt und ist primär für die räumliche Transformation zuständig. Die Hauptaufgabe des VS besteht darin, die lokale Koordinatenposition des Vertex unter Anwendung der World-View-Projection Matrizen in die homogene Clip-Space-Position zu überführen. Dieser obligatorische Output muss die System Value Semantik SV_Position tragen. Darüber hinaus transformiert der VS alle für spätere Stufen benötigten Attribute wie Normalen, Tangenten und Texturkoordinaten in den erforderlichen Raum, meist Weltraum oder Sichtraum, und leitet sie zur Rasterization weiter. Die Input-Daten für den VS stammen aus dem Vertex Buffer und werden durch User Semantics wie POSITION0, NORMAL0 oder TEXCOORD0 gebunden.
+
+1.1.2 Tesselation Stages: Hull Shader und Domain Shader
+
+Die Tessellation ermöglicht die dynamische Generierung geometrischer Details auf der GPU, was die LOD-Verwaltung deutlich vereinfacht.
+
+Hull Shader: Diese Stufe, auch bekannt als Tessellation Control Stage, verarbeitet einen Input-Patch, eine Gruppe von Kontrollpunkten zwischen 1 und 32, und generiert neue Kontrollpunkte sowie Patch-Konstanten. Die wichtigste Ausgabe sind die Tessellation Factors, numerische Werte, welche die Dichte der Unterteilung der Patch-Kanten und des Inneren für die nachfolgende fixe Tessellator-Stufe definieren. Eine wichtige Optimierung liegt in der Möglichkeit, den gesamten Patch zu verwerfen, also Culling, indem der HS die Tessellation Factors auf 0 oder NaN setzt.
+
+Domain Shader: Der Domain Shader wird einmal pro Ausgabekoordinate des Tessellators aufgerufen. Er fungiert als Evaluator, indem er die vom Tessellator bereitgestellten Koordinaten, zum Beispiel baryzentrische Koordinaten, sowie die Kontrollpunkte des HS-Outputs nutzt, um die exakte 3D-Position der neuen, hochauflösenden Vertices zu berechnen. Im Prinzip führt der DS die Transformationen des ursprünglichen Vertex Shaders für die neu generierte Geometrie durch und liefert die transformierte Vertex-Position an den Rasterizer.
+
+1.1.3 Geometry Shader
+
+Der Geometry Shader arbeitet auf Primitiven: Punkten, Linien oder Dreiecken. Im Gegensatz zum VS, der 1:1 Vertices verarbeitet, kann der GS die Topologie manipulieren, indem er Primitiven entfernt oder neue Geometrie erzeugt, zum Beispiel aus einem Punkt ein Quad generiert. Ein zentrales Feature des GS ist Stream-Out, das es ermöglicht, verarbeitete Geometriedaten direkt zurück in einen GPU-Buffer zu schreiben, anstatt sie dem Rasterizer zuzuführen. Dies ist fundamental für Rückkopplungsschleifen, wie sie in Partikelsimulationen oder komplexen LOD-Systemen benötigt werden.
+
+Architektonische Implikation: Aufgrund seiner sequenziellen Natur und der Schwierigkeit, seine Ausführung effizient zu parallelisieren, gilt der GS als Performance-Engpass. In Direct3D 12 Ultimate wird er daher durch die effizienteren, GPU-gesteuerten Mesh Shaders ersetzt. Es ist bemerkenswert, dass der Mesh Shader den Stream-Out-Mechanismus in seiner ursprünglichen Form nicht fortführt, was auf einen Paradigmenwechsel in der Geometrieverarbeitung hindeutet.
+
+1.1.4 Pixel Shader
+
+Der Pixel Shader, oder Fragment Shader, ist die zweite obligatorische Stufe. Er wird pro Pixel oder Fragment ausgeführt, das vom Rasterizer als abgedeckt identifiziert wird. Der PS erhält alle vom VS, oder DS/GS, ausgegebenen und vom Rasterizer über die Oberfläche des Primitivs interpolierten Attribute, zum Beispiel interpolierte Normalen, UV-Koordinaten und Weltposition. Seine Hauptfunktion ist die Berechnung der endgültigen Farbe, oft basierend auf Beleuchtungsmodellen und Textur-Sampling. Die finale Ausgabe des PS muss über die Semantik SV_Target erfolgen, die den Farbwert in den gebundenen Render Target Buffer schreibt. Der PS kann optional die Screen-Space-Position, also Pixelkoordinaten X/Y, als Input über SV_Position empfangen, was für gewisse Post-Processing-Effekte nützlich ist.
+
+1.1.5 Compute Shader
+
+Der Compute Shader ist technisch gesehen kein Teil der klassischen Rendering-Pipeline, sondern ermöglicht General Purpose GPU Computing, GPGPU. Er bietet hochparallele Rechenleistung für beliebige, nicht-grafische Aufgaben, wie Physik-Simulationen, Raytracing-Beschleunigung oder komplexes Culling. Compute Shader greifen typischerweise über Unordered Access Views, UAVs, auf Ressourcen zu, die wahlfreien Lese- und Schreibzugriff erlauben.
+
+1.2 Shader-Ressourcen: Buffer und Speichermanagement
+
+Shader-Ressourcen werden in Buffern organisiert und dienen der Bereitstellung von Geometrie-Input oder konstanten Uniform-Daten.
+
+1.2.1 Vertex und Index Buffer
+
+Vertex Buffer: Speichert die Kernattribute der Geometrie: Position, Normale, UV und Farbe.
+
+Index Buffer: Enthält eine Liste von Indizes, die definieren, welche Vertices aus dem VB zur Konstruktion von Primitiven verwendet werden sollen. Die Nutzung des Index Buffers ist ein entscheidender Performance-Vorteil, da sie die Menge der zu speichernden Duplikate von Vertices reduziert. Darüber hinaus verbessert die Verwendung von Indizes und eine gute Indexreihenfolge die Vertex-Cache-Effizienz auf der GPU, da oft dieselben Vertex-Daten schnell aus dem Cache abgerufen werden können, was die Gesamtgeschwindigkeit des Renderings erhöht.
+
+1.2.2 Constant Buffer
+
+Constant Buffers, CBs, speichern Daten, die für alle Invocations eines Shaders konstant bleiben, jedoch häufig von der CPU aktualisiert werden, zum Beispiel Transformationsmatrizen oder Lichtparameter. CBs sind für den Transfer kleiner, oft aktualisierter Datensätze optimiert.
+
+HLSL Packing Rules: Um eine effiziente Ausrichtung und Übertragung von Daten zwischen CPU und GPU zu gewährleisten, wendet HLSL strenge Packing-Regeln an, die Daten in 16-Byte-Vektoren gruppieren. Variablen werden so angeordnet, dass sie keine 16-Byte-Grenze überschreiten. Dies verhindert unnötigen Overhead beim Hochladen von Daten.
+
+Packing-Beispiel und Effizienz: Ein float4 belegt genau 16 Bytes. Wenn man innerhalb eines cbuffer kleine Datentypen ungeschickt platziert, entsteht Padding. Wenn die Struktur nicht optimiert wird, führt dies zu einer unnötig großen Datenmenge, die bei jedem Aufruf des Constant Buffers von der CPU zur GPU übertragen werden muss. Eine bewusste Organisation der HLSL-Strukturen, um die Vektor-Packing-Regeln auszunutzen, ist daher eine kritische Optimierungsstrategie für Rendering-Architekten.
+
+1.3 HLSL und Semantiken
+
+HLSL ist eine C-ähnliche Sprache. Sie verwendet Basistypen wie float, int, und deren Vektorvarianten float2 bis float4 sowie matrix.
+
+Semantiken als Pipeline-Schnittstelle: Semantiken sind Bindungsnamen, die dem Compiler und der Hardware mitteilen, welche Daten wohin fließen sollen. Sie sind in zwei Hauptkategorien unterteilt:
+
+1. User Semantiken: Werden zur Identifizierung benutzerdefinierter Datenströme verwendet, hauptsächlich Input-Attribute aus dem Vertex Buffer: POSITION, NORMAL, TEXCOORD.
+    
+2. System Value Semantiken: Spezielle Semantiken, die von der Pipeline selbst verarbeitet werden. SV_Position: Obligatorischer Output des Vertex Shaders, definiert die transformierte 4D-Position im Clip Space. Kann auch als optionaler Input im Pixel Shader verwendet werden, um die Pixelkoordinaten im Screen Space zu erhalten. SV_Target: Obligatorischer Output des Pixel Shaders, definiert die endgültige Farbe, die in das Render Target geschrieben wird.
+    
+
+1.4 Shader-Pipeline-Flow
+
+Die Rendering-Pipeline ist sequenziell. Der minimale Flow besteht aus Vertex Shader und Pixel Shader. Die optionalen Stufen, HS, DS, GS, werden eingefügt, um spezifische Effekte wie Tessellation oder Geometrie-Manipulation zu erzielen.
+
+TEIL 2: Lighting, Beleuchtung
+
+Die Beleuchtung in DirectX wird durch die Implementierung von lokalen Beleuchtungsmodellen in den Shadern, typischerweise im Pixel Shader, realisiert, wobei die Intensität des reflektierten Lichts durch die Art der Lichtquelle und die Materialeigenschaften bestimmt wird.
+
+2.1 Lichtquellen-Typen
+
+Directional Light: Parallele Strahlen von unendlicher Entfernung, zum Beispiel die Sonne. Definiert nur durch Richtung L. Keine Attenuation, geringe Berechnung mit konstantem L.
+
+Point Light: Strahlt in alle Richtungen von einem Punkt P. Definiert durch Position und Radius. Attenuation nur abstandsabhängig, mittlere Berechnung mit Abstand d, L variiert.
+
+Spot Light: Kegelförmige Strahlenbündel. Definiert durch Position P, Richtung D und Winkel. Attenuation durch Abstand und Kegel-Form, hohe Berechnung mit Abstand d, L variiert und Cone-Test.
+
+2.2 Licht-Komponenten des Beleuchtungsmodells
+
+Das lokale Beleuchtungsmodell, häufig basierend auf Phong oder Blinn-Phong, setzt sich aus additiven Komponenten zusammen.
+
+Ambient: Simuliert indirektes oder gestreutes Licht. Es ist konstant und richtungsunabhängig.
+
+Diffuse: Simuliert die matte Reflexion. Die Intensität hängt von der Orientierung der Oberfläche zur Lichtquelle ab, Lambert'sches Gesetz. Diffuse ist proportional zu Maximum von N mal L, 0, wobei N die Normale und L die Lichtrichtung ist.
+
+Specular: Simuliert glänzende Highlights auf der Oberfläche. Die Intensität ist stark von der Blickrichtung V und der Oberflächenrauheit, Shininess, abhängig.
+
+Emission: Licht, das vom Objekt selbst ausgestrahlt wird, unabhängig von externen Lichtquellen.
+
+Die finale beleuchtete Farbe C Final wird durch die Summe dieser Komponenten bestimmt: C Final gleich Ambient plus Diffuse plus Specular plus Emission.
+
+2.3 Beleuchtungs-Berechnungen
+
+2.3.1 Blinn-Phong Specular
+
+Während das klassische Phong-Modell den Reflexionsvektor R und den Blickvektor V vergleicht, nutzt das Blinn-Phong-Modell den Halbvektor H. Dies ist rechnerisch effizienter.
+
+Der Halbvektor H wird als normalisierte Summe der Lichtrichtung L und der Blickrichtung V berechnet: H gleich L plus V geteilt durch die Norm von L plus V. Die spekulare Intensität wird dann berechnet als: Specular gleich C Specular mal Maximum von N mal H, 0 hoch n. Wobei n der Shininess-Exponent ist, der die Glanzstärke des Materials bestimmt.
+
+2.3.2 Attenuation, Dämpfung
+
+Die quadratische Attenuation ist das Standardmodell zur Simulation der realistischen Intensitätsabnahme von Point und Spot Lights mit der Entfernung d.
+
+Attenuation von d gleich 1 geteilt durch c const plus c linear mal d plus c quadratic mal d Quadrat.
+
+Der konstante, lineare und quadratische Koeffizient steuern, wie schnell und stark die Lichtintensität abfällt. Ein häufiger Fehler in HLSL-Implementierungen ist die fehlerhafte Priorisierung von Operatoren, zum Beispiel 1,0f geteilt durch d mal d statt 1,0f geteilt durch Klammer auf d mal d Klammer zu, was zu falschen oder fehlenden Dämpfungseffekten führt.
+
+2.4 Vertex Lighting versus Pixel Lighting, Gouraud versus Phong
+
+Die Wahl des Beleuchtungsorts, VS oder PS, stellt einen kritischen Trade-off zwischen Renderqualität und Performance dar.
+
+Vertex Lighting, Gouraud Shading: Die Beleuchtung wird einmal pro Vertex im Vertex Shader berechnet. Die resultierenden Farbewerte werden vom Rasterizer über die Fläche des Primitivs interpoliert. Dies ist sehr schnell, Performance proportional zur Anzahl der Vertices, führt aber zu unpräzisen Ergebnissen, insbesondere bei großen Polygonen oder kleinen, glänzenden Highlights, die zwischen den Vertices verschwinden können. Die Interpolation der fertigen Farbe kann zu sichtbaren Farbabstufungen, Mach Bands, führen.
+
+Pixel Lighting, Phong Shading: Die Beleuchtung wird für jeden Pixel im Pixel Shader neu berechnet. Hierbei werden die Normalenvektoren vom VS an den PS weitergegeben und über die Oberfläche interpoliert. Da die Beleuchtung pro Pixel erfolgt, ist die Qualität deutlich höher, die Highlights sind glatt und präzise, unabhängig von der Polygondichte. Der Nachteil ist der höhere Rechenaufwand, da die teure Beleuchtungsberechnung für potenziell Millionen von Pixeln durchgeführt werden muss, Performance proportional zur Anzahl der Pixel.
+
+Pixel Lighting, Phong Shading, ist der heutige Standard, da moderne GPUs die zusätzliche Last gut bewältigen können, um die notwendige visuelle Qualität zu gewährleisten.
+
+TEIL 3: Texturen, Mapping und Filtertechniken
+
+Texturen sind essentielle Datenquellen für Shader und erfordern spezielle Techniken für Adressierung, Sampling und Qualitätsoptimierung.
+
+3.1 UV-Mapping und Adressierungsmodi
+
+UV-Mapping: Definiert die Abbildung von 3D-Vertex-Positionen auf die 2D-Texturkoordinaten u und v. Der Standardbereich für Texturkoordinaten liegt in 0 bis 1 mal 0 bis 1. Ein einzelnes Bildelement in der Textur wird als Texel bezeichnet.
+
+Texture Address Modes, UV-Tiling: Diese Modi bestimmen das Verhalten des Samplers, wenn die übergebenen UV-Koordinaten außerhalb des Standardbereichs liegen.
+
+Wrap, Repeat: Die Textur wird wiederholt, indem nur der gebrochene Teil der Koordinate verwendet wird, zum Beispiel u modulo 1,0. Anwendung: Tiling von Oberflächen wie Wände und Böden.
+
+Mirror: Die Textur wird bei jeder ganzzahligen Grenze gespiegelt. Reduziert sichtbare Nähte bei Kachelung.
+
+Clamp: Die Koordinaten werden auf 0 bis 1 begrenzt. Die Farbe der Randtexel wird bis zur Grenze des Primitivs ausgedehnt, Smearing. Anwendung: Einzelobjekte, die nicht kacheln sollen, zum Beispiel UI-Elemente.
+
+Border: Außerhalb von 0 bis 1 wird eine definierte Border Color verwendet. Vermeidung von Smearing bei bestimmten Effekten.
+
+3.2 Texture Sampling und Filterung
+
+Sampling beschreibt den Prozess des Auslesens von Farbinformationen an einer bestimmten UV-Koordinate.
+
+Point Filtering, Nearest Neighbor: Wählt den Farbwert des Texels, dessen Zentrum dem Sample-Punkt am nächsten liegt. Resultiert in einer blockigen, pixelierten Optik.
+
+Linear Filtering, Bilinear: Interpoliert linear zwischen den vier nächstgelegenen Texeln auf der aktuellen Mipmap-Stufe, um einen glatteren Farbübergang zu erzeugen.
+
+Mipmapping
+
+Mipmapping ist eine Hierarchie von vorab berechneten, kleineren Versionen der Originaltextur, Level 0.
+
+Zweck: Mipmapping dient primär dazu, das Minifikations-Aliasing, Moiré-Effekte bei Texturen in der Ferne, zu reduzieren und die Performance zu steigern, da der GPU-Speicherzugriff, Bandbreite, stark reduziert wird, wenn weit entfernte Objekte kleinere Textur-Levels verwenden.
+
+Berechnung der Stufenanzahl L: Die Anzahl der Mipmap-Levels für eine Textur mit den Dimensionen W mal H wird berechnet als: L gleich Abrundung von Logarithmus zur Basis 2 von Maximum von W, H plus 1.
+
+Beispiel 1: 256 mal 256 ergibt Logarithmus zur Basis 2 von 256 plus 1 gleich 8 plus 1 gleich 9 Stufen.
+
+Beispiel 2: 1024 mal 1024 ergibt Logarithmus zur Basis 2 von 1024 plus 1 gleich 10 plus 1 gleich 11 Stufen.
+
+Speicher-Overhead: Der gesamte zusätzliche Speicher, der für alle Mipmap-Stufen benötigt wird, beträgt nur etwa 33% der Größe der ursprünglichen, größten Textur, Level 0. Dies macht Mipmapping zu einer sehr effizienten Methode.
+
+Trilinear und Anisotropic Filtering
+
+Trilinear Filtering: Verbessert das Bilinear Filtering, indem es nicht nur innerhalb eines Mipmap-Levels interpoliert, sondern zusätzlich linear zwischen den beiden Mipmap-Stufen, LOD A und LOD B, interpoliert, die dem optimalen Level of Detail am nächsten liegen. Dies verhindert das abrupte Umschalten zwischen Mipmap-Stufen, bekannt als Mipmap Popping.
+
+Anisotropic Filtering, AF: Dies ist die hochwertigste Filterung. Bilinear und Trilinear sind isotrop, filtern gleichmäßig. Bei schrägen Blickwinkeln, zum Beispiel bei Bodenflächen, führt dies zu Unschärfe, da das Aliasing in einer Achse stärker ist als in der anderen. AF wendet eine richtungsabhängige Filterung an, um die Texturdetails auch bei extrem schrägen Winkeln scharf und detailliert zu halten. Trotz der höheren Qualität hat AF auf modernen GPUs nur einen minimalen Performance-Einfluss und wird daher fast immer in den höchsten Stufen verwendet.
+
+3.3 Advanced Texturing Techniken
+
+3.3.1 Texture-Typen
+
+Cube Maps: Bestehen aus sechs 2D-Texturen, die die Seiten eines Würfels repräsentieren. Sie werden primär für das Environment Mapping, zum Beispiel Skyboxes oder Reflexionen, verwendet, um die Umgebung aus einem zentralen Punkt zu erfassen.
+
+Texture Arrays: Sammlungen von 1D-, 2D- oder 3D-Texturen, die es dem Shader ermöglichen, schnell auf verschiedene Texturlayer zuzugreifen, ohne die Shader-Bindings ändern zu müssen. Dies ist nützlich für Terrain-Layering oder das Verwalten von Textursätzen.
+
+3.3.2 Normal Mapping
+
+Normal Mapping ist eine Bump-Mapping-Technik, die mittels einer speziellen Textur, der Normal Map, detaillierte Oberflächenbeleuchtung simuliert, ohne die Geometrie zu erhöhen.
+
+Tangent Space: Da die in der Normal Map gespeicherten Normalenvektoren typischerweise relative Normalen sind, lokal zum Polygon, müssen die Beleuchtungsberechnungen im Tangent Space durchgeführt werden.
+
+TBN Matrix: Um die Normalen aus der Textur korrekt im Raum zu orientieren, wird eine Basis aus drei Vektoren definiert: der Tangente T, der Bitangente B und der geometrischen Normale N. Diese drei Vektoren bilden die TBN-Matrix, die es ermöglicht, die Beleuchtungsvektoren, Lichtrichtung L, Blickrichtung V, vom Weltraum in den Tangent Space zu transformieren, sodass sie mit der Normalen aus der Textur verglichen werden können.
+
+3.3.3 Parallax Mapping
+
+Parallax Mapping nutzt das Prinzip der Parallaxe, der scheinbaren Verschiebung von Objekten bei Änderung des Blickwinkels, um eine Illusion von Tiefe auf einer flachen 2D-Textur zu erzeugen.
+
+Funktion: Die Technik verwendet eine Höhenkarte, Height Map, ein Graustufenbild, wobei hellere Werte höhere Bereiche darstellen, und verschiebt die UV-Koordinaten des Texels abhängig vom Blickwinkel des Betrachters.
+
+UV-Verschiebung: Die Verschiebung Delta UV wird in Abhängigkeit von der Höhe H aus der Höhenkarte und dem Blickvektor V ts im Tangent Space berechnet. Wenn der Blickwinkel steiler ist, flacher Winkel zur Oberfläche, ist die Verschiebung größer, was die Tiefenillusion verstärkt.
+
+Erweiterte Formen: Einfaches Parallax Mapping berücksichtigt keine Selbstverdeckung. Techniken wie Parallax Occlusion Mapping, POM, nutzen iterative Verfahren, zum Beispiel Ray-Marching, gegen das Höhenfeld, um den korrekten Schnittpunkt zu finden und somit Selbstverschattung und präzisere Silhouetten zu ermöglichen.
+
+Schlussfolgerung
+
+Die Beherrschung der DirectX-Pipeline erfordert ein tiefes Verständnis der Interaktion zwischen programmierbaren Stufen und GPU-Architektur. Prüfungsrelevant sind insbesondere die Schnittstellen, Semantiken, die Optimierungsansätze, HLSL Packing und Vertex Caching durch Index Buffer, und die Trade-offs zwischen Qualität und Performance.
+
+Die evolutionären Schritte in der Pipeline zeigen eine klare Verschiebung hin zu mehr GPU-Kontrolle, Tessellation, Mesh Shaders als Ersatz für GS. Im Bereich Beleuchtung bleibt Blinn-Phong der Standard aufgrund seiner Balance zwischen Qualität und Leistung. Bei Texturen stellen Mipmaps und Anisotropic Filtering nicht nur Qualitätsverbesserungen dar, sondern sind fundamentale Mechanismen zur effizienten Bandbreitennutzung und Cache-Optimierung auf modernen GPU-Systemen. Die korrekte Anwendung von TBN-Matrizen und Parallax-Algorithmen ermöglicht es schließlich, visuelle Komplexität zu simulieren, die weit über die tatsächliche Geometriedichte hinausgeht.

Grafik/Hackbarth/Tag2_Themen.md

@@ -0,0 +1,84 @@
+Erstelle einen umfassenden, detaillierten Lernbericht zu folgenden DirectX-Berechnungsthemen für Grafikprogrammierung:
+TEIL 1: Vertices & Buffer-Berechnungen
+- Vertex-Struktur und Attribute:
+  * Position: 3D-Koordinaten (x, y, z), Datentyp float, Speichergröße
+  * Normale: Normalisierter Vektor (nx, ny, nz), Verwendung für Beleuchtung
+  * Tangente und Binormale: Für Normal Mapping, Speichergröße
+  * UV-Koordinaten: Texturkoordinaten (u, v), Wertebereich [0,1]
+  * Farbe: RGBA vs. ARGB, Byte vs. Float-Repräsentation
+- Vertex-Count-Berechnungen für verschiedene Geometrien:
+  * Würfel: Warum 24 Vertices statt 8? (4 Vertices pro Fläche × 6 Flächen)
+  * Quad/Plane: Vertex-Count mit und ohne Shared Vertices
+  * Zylinder: Berechnung basierend auf Segmenten (Seitenflächen + Deckel)
+  * Kugel/Sphere: Berechnung basierend auf Längen- und Breitengraden
+- Vertex-Buffer-Größenberechnung:
+  * Formel: Anzahl Vertices × Bytes pro Vertex
+  * Detaillierte Beispiele:
+    - Position (3 floats) + Normal (3 floats) + UV (2 floats) = 8 floats
+    - 8 floats × 4 Bytes = 32 Bytes pro Vertex
+    - Würfel: 24 Vertices × 32 Bytes = 768 Bytes
+  * Verschiedene Vertex-Formate und deren Größen
+  * Padding und Alignment-Regeln (16-Byte-Alignment)
+  * Beispielrechnungen mit verschiedenen Attribut-Kombinationen
+- Vertex-Buffer-Typen:
+  * Static vs. Dynamic vs. Staging Buffers
+- Praktische Übungsaufgaben:
+  * Berechne Vertex-Buffer-Größe für verschiedene Mesh-Typen
+TEIL 2: Index-Buffer-Berechnungen
+- Index-Buffer-Grundlagen:
+  * Zweck: Vertex-Wiederverwendung, Memory-Effizienz
+  * Index-Datentypen: 16-bit (WORD, 0-65535) vs. 32-bit (DWORD)
+- Triangle List Index-Berechnungen:
+  * Formel: Anzahl Dreiecke × 3 Indices
+  * Index-Buffer-Größe: 36 Indices × 2 Bytes (WORD) = 72 Bytes
+- Index-Count für verschiedene Primitive-Typen:
+  * Triangle List: N Dreiecke = 3N Indices
+  * Triangle Strip: N Dreiecke = N+2 Indices (Effizienz!)
+  * Triangle Fan: N Dreiecke = N+2 Indices
+  * Line List: N Linien = 2N Indices
+  * Line Strip: N Linien = N+1 Indices
+- Detaillierte Geometrie-Berechnungen:
+  * Würfel: 12 Dreiecke (Triangle List) vs. optimierte Strip-Varianten
+  * Quad: 2 Dreiecke, 6 Indices (List) vs. 4 Indices (Strip)
+  * Zylinder: Mantel + Deckel, Index-Berechnung
+  * Kugel: Segments × Rings × 6 Indices (bei Triangle List)
+TEIL 3: Transformationen und Koordinatensysteme
+- Coordinate Spaces im Detail:
+  * Local/Object Space: Mesh-eigenes Koordinatensystem, Origin am Pivot
+  * World Space: Globales 3D-Koordinatensystem der Szene
+  * View/Camera/Eye Space: Kamera am Origin, Blickrichtung -Z
+  * Clip Space: Nach Projection, homogene Koordinaten, [-1,1] oder [0,1]
+  * Screen/Viewport Space: 2D-Pixel-Koordinaten
+- Transformations-Pipeline:
+  * Reihenfolge: Local → World → View → Projection → Clip → Screen
+  * Matrix-Multiplikation: Vertex × Model × View × Projection
+  * Warum diese Reihenfolge?
+- Model/World Transformation:
+  * Translation: Verschiebung im Raum, Translation Matrix
+  * Rotation: Um X, Y, Z-Achse, Euler Angles, Rotation Matrices
+  * Scaling: Uniform vs. Non-Uniform, Scaling Matrix
+  * Kombinierte Transformation: Scale → Rotate → Translate (SRT)
+  * Matrix-Multiplikations-Reihenfolge und deren Bedeutung
+- View Transformation:
+  * Look-At Matrix: Eye Position, Target, Up-Vector
+  * Kamera-Position und Orientierung
+  * View Matrix Berechnung
+- Projection Transformation:
+  * Perspective Projection: FOV (Field of View), Aspect Ratio, Near/Far Plane
+  * Orthographic Projection: Left, Right, Top, Bottom, Near, Far
+  * Perspective, Orthographic Matrix Aufbau und Vergleich
+- Homogene Koordinaten:
+  * 4D-Vektoren (x, y, z, w) für 3D-Grafik
+  * Warum w-Komponente? Perspektivische Teilung, Translation in Matrix-Form
+  * Homogenisierung: Division durch w nach Projection
+  * w = 0 für Richtungsvektoren, w = 1 für Punkte
+  * Perspective Divide: (x/w, y/w, z/w)
+- Viewport Transformation:
+  * Clip Space [-1,1] → Screen Space [0, Width]×[0, Height]
+  * Viewport-Parameter: X, Y, Width, Height, MinDepth, MaxDepth
+  * Depth Buffer Mapping [0,1]
+- Praktische Transformations-Beispiele:
+  * Schritt-für-Schritt: Vertex durch alle Transformationen
+  * Numerische Berechnungen mit Beispiel-Matrizen
+  * Verständnis: Was passiert in jedem Space?
+Füge zu jedem Abschnitt hinzu: Schritt-für-Schritt-Berechnungen, Formeln in mathematischer Notation, konkrete Zahlenbeispiele, Visualisierungen (beschreibe sie textuell), häufige Rechenfehler. Strukturiere den Bericht so, dass Berechnungswege klar nachvollziehbar sind und sich für Karteikarten mit Rechenaufgaben eignen. Erstelle Übungsaufgaben mit Lösungen für jedes Thema.

Grafik/Hackbarth/Tag3_Themen.md

@@ -0,0 +1,86 @@
+Erstelle einen detaillierten Lernbericht zu Shader, Lighting und Texturen in DirectX. Fokussiere auf prüfungsrelevante Konzepte mit prägnanten Erklärungen und praktischen Beispielen:
+
+TEIL 1: Shader-Programmierung
+- Die 6 Shader-Typen (Grundfunktion, Input/Output, Verwendungszweck):
+  * Vertex Shader (VS): Vertex-Transformation, Position-Berechnung, Attribute-Weiterleitung
+  * Hull Shader (HS): Tesselation Control, Patch-Verarbeitung, Tesselation-Faktoren
+  * Domain Shader (DS): Tesselation Evaluation, neue Vertices generieren
+  * Geometry Shader (GS): Primitive-Manipulation, Stream-Out, zusätzliche Geometrie erzeugen
+  * Pixel Shader (PS): Per-Pixel-Farbe, Lighting, Texturing
+  * Compute Shader (CS): General Purpose GPU Computing, nicht in Rendering-Pipeline
+- Shader-Ressourcen:
+  * Vertex Buffer: Input für Vertex Shader, Vertex-Daten (Position, Normal, UV, etc.)
+  * Index Buffer: Definiert Primitive-Topologie, optimiert Vertex-Sharing
+  * Constant Buffer: Uniforme Daten (Matrizen, Lichtdaten, Material), updates per Frame/Object
+  * Unterschiede: Buffer-Typen, Binding-Slots, Update-Frequenz
+- HLSL (High Level Shading Language):
+  * Syntax: C-ähnlich, Datentypen (float, float2-4, matrix, struct)
+  * Semantiken: Bindings zwischen Pipeline-Stages (POSITION, NORMAL, TEXCOORD, SV_Position, SV_Target)
+  * Input-Semantiken: Was kommt rein? (z.B. POSITION0)
+  * Output-Semantiken: Was geht raus? (z.B. SV_Position für Vertex Shader)
+  * System-Value-Semantiken: SV_* (spezielle GPU-Werte)
+  * Shader-Kompilierung: .hlsl → Bytecode
+- Shader-Pipeline-Flow:
+  * Datenfluss durch alle Stages
+  * Welche Shader sind verpflichtend? (VS + PS minimal)
+  * Optional: HS+DS (Tesselation), GS
+TEIL 2: Lighting (Beleuchtung)
+- Lichtquellen-Typen:
+  * Directional Light: Parallele Strahlen, keine Position, nur Richtung (z.B. Sonne)
+  * Point Light: Strahlt in alle Richtungen, Position + Reichweite, Attenuation
+  * Spot Light: Kegelförmig, Position + Richtung, Inner/Outer Cone Angle, Attenuation
+  * Vergleich: Berechnungsaufwand, Anwendungsfälle
+- Licht-Komponenten (Beleuchtungsmodell):
+  * Ambient: Konstante Grundhelligkeit, keine Richtung, simuliert indirektes Licht
+  * Diffuse: Matte Oberfläche, Lambert-Reflexion, abhängig von Normal·Light-Direction
+  * Specular: Glänzende Highlights, abhängig von View-Direction, Shininess/Power
+  * Emission: Selbstleuchtende Objekte, unabhängig von Lichtquellen
+  * Formel: Final = Ambient + Diffuse + Specular + Emission
+- Beleuchtungs-Berechnungen:
+  * Lambert (Diffuse): max(N·L, 0)
+  * Phong Specular: (R·V)^n (Reflection Vector)
+  * Blinn-Phong: (N·H)^n (Half Vector, effizienter)
+  * Attenuation für Point/Spot: 1/(constant + linear*d + quadratic*d²)
+- Vertex Lighting vs. Pixel Lighting:
+  * Vertex Lighting: Berechnung im Vertex Shader, Interpolation, weniger präzise, schneller
+  * Pixel Lighting: Berechnung im Pixel Shader, pro Pixel, präziser, teurer
+  * Vergleich: Qualität, Performance, wann was verwenden?
+  * Gouraud Shading (Vertex) vs. Phong Shading (Pixel)
+TEIL 3: Texturen
+- UV-Mapping:
+  * Texturkoordinaten (u,v): 2D-Koordinaten [0,1] × [0,1]
+  * Mapping: 3D-Vertices → 2D-Textur
+  * UV-Layout, UV-Unwrapping
+  * Texel: Texture Pixel
+- Texture Address Modes (UV-Tiling):
+  * Wrap/Repeat: Textur wiederholt sich (u % 1.0)
+  * Mirror: Spiegelt sich an Grenzen
+  * Clamp: Letzte Texel-Farbe wird wiederholt
+  * Border: Definierte Border-Color außerhalb [0,1]
+  * Anwendung: Tiling von Oberflächen vs. einzelne Objekte
+- Texture Sampling:
+  * Sampler States: Filter-Modi, Address-Modes
+  * Point Filtering: Nächster Texel, blocky
+  * Linear Filtering: Bilineare Interpolation, smooth
+  * Anisotropic Filtering: Qualität bei schrägen Winkeln
+- Mipmapping:
+  * Zweck: Performance, Anti-Aliasing für Distanz
+  * Mipmap-Stufen: Jede Stufe ist halbe Auflösung
+  * Berechnung Anzahl Stufen: log₂(max(width, height)) + 1
+  * Beispiele: 
+    - 256×256 → Stufen: log₂(256) + 1 = 8 + 1 = 9 Stufen
+    - 512×256 → log₂(512) + 1 = 9 + 1 = 10 Stufen
+    - 1024×1024 → 11 Stufen
+  * Memory-Overhead: ~33% zusätzlicher Speicher
+  * Trilinear Filtering: Interpolation zwischen Mipmap-Stufen
+- Texture-Typen:
+  * 1D, 2D, 3D Textures
+  * Cube Maps: 6 Faces für Environment Mapping
+  * Texture Arrays
+- Advanced Texturing:
+  * Normal Mapping: Tangent Space, Detail ohne Geometrie
+  * Parallax Mapping: Tiefenillusion
+  * Multi-Texturing: Mehrere Texturen kombinieren
+Füge hinzu: Kernkonzepte, Formeln, Berechnungsbeispiele für Mipmaps, Code-Snippets in HLSL wo relevant, Vergleichstabellen, und prüfungsrelevante Details. Strukturiere für Karteikarten-Erstellung mit Fokus auf Verständnis und Anwendung.
+
+Erstelle mir bitte nur auf Grundlage der Quelle: ("Detaillierte Analyse der GPU-Pipeline in DirectX: Shader, Beleuchtung und Texturierung") Lernkarten zum ausführlichen Lernen der Inhalte und decke bitte alles ab.

Grafik/Hackbarth/Zeitplan.md

@@ -0,0 +1,85 @@
+# Zeitplan
+
+## Tag 1: Grundlagen, Fenster & Pipeline-Struktur
+
+**Ziel:** Das "Gerüst" verstehen (Windows, COM) und den Ablauf der Grafikpipeline verinnerlichen.
+
+### 1. Windows & C++ Basics (45 Min)
+
+- Verstehe den Unterschied zwischen Pointer und Handle sowie das COM (Component Object Model).
+- Lerne die Fensternachrichten (`WM_QUIT`, `WM_DESTROY`, `WM_EXIT`) und die Funktion der Messagequeue (`Window Proc`).
+- Frage dich: Wozu braucht man Nachrichten?
+
+### 2. Die Pipelines (1 Std.)
+
+- Vergleiche Fixed Function vs. Programmable Pipeline.
+- Lerne die Elemente der Pipeline auswendig: Vertex, Mesh, Transformation, Primitives (Unterschied List vs. Strip).
+- Schau dir die Stages an: Rasterizer (Front/Back Faces) und Screen-Stage.
+
+### 3. DirectX Versionen (30 Min)
+
+- Unterscheide Direct3D9 (Device) vs. Direct3D11 (Device Context vs. Device).
+
+---
+
+## Tag 2: Berechnungen (Der "Anwendungs"-Teil)
+
+**Ziel:** Die Rechenaufgaben sicher beherrschen. Der Taschenrechner ist erlaubt, also übe den Weg.
+
+### 1. Vertices & Buffer berechnen (1,5 Std.) – WICHTIG
+
+- Verinnerliche das Beispiel aus der Quelle: Ein Würfel braucht 24 Vertices (4 pro Fläche × 6 Flächen), nicht 8, wegen der Normalen.
+- Berechne die Vertexgröße:
+    - Position (3 Floats) + Normale (3 Floats) + UV (2 Floats) = 8 Floats
+    - 8 Floats × 4 Byte = 32 Byte pro Vertex
+- Gesamtgröße Vertexbuffer: 24 Vertices × 32 Byte = 768 Byte
+
+### 2. Indexbuffer berechnen (45 Min)
+
+- Verstehe die `Triangle List`: 6 Flächen × 2 Dreiecke × 3 Ecken = 36 Indices.
+- Rechnung: 36 Indices × 2 Byte (Word) = 72 Byte
+
+### 3. Transformationen (30 Min)
+
+- Lerne die Reihenfolge der Spaces: Local Space → World → View → Projection
+- Verstehe homogenisierte Koordinaten.
+
+---
+
+## Tag 3: Shader, Licht & Texturen
+
+**Ziel:** Die programmierbare Pipeline und visuelle Details verstehen.
+
+### 1. Shader (1 Std.)
+
+- Lerne alle 6 Shadertypen und ihre Grundfunktion: Vertex, Hull, Domain, Geometry, Pixel, Compute.
+- Was sind Shader Ressources (Vertex-, Index-, Constantbuffer)?
+- Was ist HLSL und wozu dienen Semantiken?
+
+### 2. Lighting (1 Std.)
+
+- Kenne die Lichtquellen (Directional, Point, Spot) und Lichtbestandteile (Ambient, Diffuse, Specular, Emission).
+- Unterschied: Vertex-Lighting vs. Pixel-Lighting
+
+### 3. Texturen (30 Min)
+
+- UV-Mapping und UV-Tiling (Address Modes) verstehen.
+- Mipmapping: Stufen zählen können.
+
+---
+
+## Tag 4: Wiederholung & Lücken füllen
+
+**Ziel:** Wissen festigen und Details prüfen.
+
+### 1. Datentypen-Check (1 Std.)
+
+- Gehe konkrete Datentypen aus dem Framework (D3D9/D3D11) durch.
+
+### 2. Simulation (1 Std.)
+
+- Rechne ein Beispiel für Vertex- und Indexbuffer mit anderen Werten durch (z.B. nur eine Fläche oder eine Pyramide), um sicherzugehen, dass du das Prinzip (Vertices pro Fläche zählen) verstanden hast.
+
+### 3. Review (30 Min)
+
+- Gehe die Liste in `Klausurthemen.md` noch einmal Punkt für Punkt durch. Alles abgehakt?

Grafik/Kalki/Hausaufgabe 1.md

@@ -0,0 +1,211 @@
+Name: Theo Leuthardt
+Datum: 09.09.2025
+
+---
+#### Aufgabe 1:
+##### Definition und Grundverständnis:
+**Multimedia** bezeichnet die Integration verschiedener Medientypen (Text, Grafik, Audio, Video, Animation) in einem System zur gemeinsamen Verarbeitung und Präsentation über die Wahrnehmung des Menschen mithilfe seiner sechs Sinne.
+##### Verschiedene Sichtweisen und Aspekte:
+**Technische Perspektive:**
+- Verarbeitung verschiedenen Typen von Daten (Text, Bild, Audio, Video)
+- Herausforderungen bei Speicherung und Übertragung (Höhere Qualität = größere Speichernutzung z.B.)
+- _Problem:_ Hohe Hardwareanforderungen und Bandbreite
+
+**Benutzerperspektive:**
+- Interaktive und ansprechende Benutzererfahrung bei einer Multimediaanwendung
+- Verschiedene Lerntypen werden angesprochen: z.B. visuell oder hörender
+- _Vorteil:_ Besseres Verständnis durch multiple Sinneskanäle und damit mehr Optionen zur Aufnahme von Informationen
+- _Nachteil:_ Mögliche kognitive Überlastung
+
+**Historische Entwicklung:**
+- Von statischen Medien zu interaktiven Systemen über die zeitliche Entwicklung von Multimedia
+- Evolution von Medien auf CD-ROM zu Web-basierten Anwendungen für die Anzeige, Wiedergabe oder Spielbarkeit der Medien
+##### Kritische Bewertung:
+**Stärken:**
+- Erhöhte Informationsdichte durch die Ansammlung an Informationen in oben genannten Datentypen
+- Bessere Wissensvermittlung durch mehrere Möglichkeiten des Lernens für die verschiedenen Lerntypen
+- Zugänglichkeit für verschiedene Nutzergruppen: z.B. Barrierefreiheit für behinderte Menschen
+- Möglichkeit zum Erleben von Phantasiewelten in immer realer aussehenden Bewegbildproduktionen (Geschichten aus Büchern werden Realität in 4K/8K-Filmen mit Animationen oder Realverfilmungen)
+
+**Schwächen:**
+- Ansteigende Komplexität in Entwicklung und Wartung multimedialer Anwendungen oder von Medien selber
+- Hohe Kosten der Produktionen (egal ob multimediale Anwendungen oder Filmproduktionen) und technische Anforderungen bei der Entwicklung
+- Abhängigkeit von technischer Infrastruktur je nach Typ des Mediums: z.B. Grafische Datenverarbeitung mithilfe der GPU bei der Erstellung eines Modells in Blender
+##### Fazit:
+Multimedia ist nicht nur eine technische Integration verschiedener Medientypen, sondern ein paradigmatischer Ansatz zur Informationsvermittlung, der sowohl große Chancen als auch erhebliche Herausforderungen mit sich bringt.
+
+---
+#### Aufgabe 2:
+##### Entropiecodierung:
+- Versucht die theoretische Grenze der verlustfreien Kompression zu erreichen (Entropie)
+- Daten werden komprimiert durch Reduktion der Codierungsredundanz mithilfe der Symbolverteilung
+- Häufige Symbole erhalten kürzere Codes
+- Erhöhung der Informationsdichte für die effizientere Nutzung des Speicherplatzes
+- Beispiele: Huffman-Codierung, Arithmetische Codierung
+Quelle: https://link.springer.com/chapter/10.1007/978-3-322-92815-3_4
+##### Quellcodierung:
+- Erstellt eine Zuordnung von Symbolen zu Codewörtern zur Umwandlung von Daten in eine für die Kompression optimierte Form, um Redundanzen zu reduzieren
+- Nutzt Eigenschaften der menschlichen Wahrnehmung
+- Findung effizienterer Darstelltungen z.B. eine Codetabelle
+- Beispiele: DCT bei JPEG (Transformation), Prädiktive Codierung
+- Oft höhere Kompressionsraten als reine Entropiecodierung
+
+---
+#### Aufgabe 3:
+##### Unformatierter Text (Plain Text):
+- Reine Zeichenketten ohne Formatierung
+- ASCII, UTF-8, UTF-16 (zeichenkettenkodiert), Unicode
+- Beispiel: .txt-Dateien
+##### Formatierter Text:
+- Enthält Formatierungsinformationen
+- Schriftart, -größe, -farbe, Ausrichtung
+- Beispiel: RTF (Rich Text Format)
+##### Strukturierter Text (Tagged Text):
+- Hierarchische oder logische Struktur zur Strukturierung des Textes
+- Markup-Sprachen (XML, HTML)
+- Metadaten und Tags
+##### Hypertext:
+- Verknüpfte Textdokumente
+- Navigation durch Links
+- Realisierungen: Webseiten, Wiki-Systeme
+
+---
+#### Aufgabe 4:
+
+##### Card Shark:
+Card Shark ist **kartenbasiertes System**, worin jede "Karte" eine Informationseinheit enthält. Die Navigation erfolgt zwischen Karten über Links, was dem Hypercard-Konzept ähnelt. Hierbei handelt es sich im ein statisches Informationsmodell zur textbasierten Darstellung von Informationen.
+##### Holly Scroller:
+Holly Scroller sind ein **scrollbasiertes System**, worin ein kontinuierlicher Informationsfluss herrscht mit vertikaler oder horizontaler Navigation. Durch die vertikale oder horizontale Darstellung wird eine dynamische Anzeige von Inhalten ermöglicht. Da es keine Informationen zugewiesen zu einer "Karte" gibt aus den Card Sharks, ist die Navigation weniger strukturiert.
+
+---
+#### Aufgabe 5:
+
+##### Strukturelle Links (Navigational Links):
+- Hierarchische Beziehungen (Parent-Child)
+- Sequenzielle Navigation (Next-Previous)
+##### Referentielle Links (Referential Links):
+- Verweise auf verwandte Inhalte
+- Querverweise, Zitate
+##### Organisatorische Links (Document Structural Links):
+- Gruppierung ähnlicher Inhalte
+- Kategorisierung
+##### Assoziative Links (Associative Links):
+- Thematische Verbindungen
+- Konzeptuelle Zusammenhänge
+##### Annotative Links (Annotation Links):
+- Kommentare und Ergänzungen
+- Erklärungen zu Begriffen
+
+---
+#### Aufgabe 6:
+##### JPEG-Quantisierung: DCT-Transformation (Diskrete Cosinus-Transformation)
+Die DCT transformiert Bilddaten vom Ortsbereich in den Frequenzbereich und bildet den Mittelpunkt der JPEG-Kompression. Dabei wird das Bild in 8×8 Pixel-Blöcke aufgeteilt und jeder Block einzeln verarbeitet.
+Die DCT nutzt Cosinus-Funktionen als Basisfunktionen und jede Funktion kann als Summe von Cosinus-Funktionen dargestellt werden.
+Für eine N×N Matrix wird die DCT-Matrix wie folgt berechnet:
+- Für m=0: DCT[m][n] = √(1/N)
+- Für m>0: DCT[m][n] = √(2/N) × cos((2n+1)πm/(2N))
+###### Quantisierungsmatrix
+JPEG teilt jeden DCT-Wert durch einen Quantisierungsfaktor, der dann zur nächsten ganzen Zahl gerundet wird. Die Quantisierungsmatrix ist eine 8×8-Tabelle mit spezifischen Koeffizienten für jeden Frequenzbereich.
+
+**Aufbau der Matrix:**
+- Kleinere Werte in der oberen linken Ecke (niedrige Frequenzen)
+- Größere Werte in der unteren rechten Ecke (hohe Frequenzen)
+- Kleine Koeffizienten für niedrige Frequenzen und große Koeffizienten für hohe Frequenzen
+
+**Beispiel einer Standard-Quantisierungsmatrix:**
+
+```
+16  11  10  16  24  40  51  61
+12  12  14  19  26  58  60  55
+14  13  16  24  40  57  69  56
+14  17  22  29  51  87  80  62
+18  22  37  56  68 109 103  77
+24  35  55  64  81 104 113  92
+49  64  78  87 103 121 120 101
+72  92  95  98 112 100 103  99
+```
+
+###### Rundung und Informationsverlust
+Nach der Division durch die Quantisierungsmatrix werden die Ergebnisse zur nächsten ganzen Zahl gerundet. Dieser Schritt verursacht den charakteristischen Informationsverlust der JPEG-Kompression:
+- Nachkommastellen gehen unwiderruflich verloren
+- Kleinere DCT-Koeffizienten werden oft zu Null gerundet
+- Je größer der Quantisierungsfaktor, desto mehr Informationen gehen verloren
+###### Qualitätsfaktor
+Der Qualitätsfaktor skaliert die gesamte Quantisierungsmatrix und bestimmt das Verhältnis zwischen Kompression und Bildqualität:
+
+**Funktionsweise:**
+- Niedrigere Qualitätswerte = größere Quantisierungskoeffizienten = mehr Kompression, schlechtere Qualität
+- Höhere Qualitätswerte = kleinere Quantisierungskoeffizienten = weniger Kompression, bessere Qualität
+- In Bildbearbeitungsprogrammen entspricht die "Qualitäts"-Einstellung der Modifikation dieser Koeffizienten
+
+**Mathematische Beziehung:** 
+Quantisierte Matrix = round(DCT Koeffizienten / (Quantisierungsmatrix * Qualitätsfaktor))
+
+**Quelle:** https://dev.to/marycheung021213/understanding-dct-and-quantization-in-jpeg-compression-1col
+
+---
+#### Aufgabe 7:
+##### Geschlechtsspezifische Unterschiede:
+- **Stimmfrequenzen**: Männer (85-180 Hz), Frauen (165-265 Hz)
+- **Formanten**: Unterschiedliche Resonanzfrequenzen in der Stimme
+##### Mögliche Optimierungen:
+- Angepasste Frequenzbänder-Aufteilung
+- Optimierte Bit-Allokation für relevante Frequenzbereiche
+- Geschlechtsspezifische psychoakustische Modelle
+- Adaptive Codierung basierend auf Sprecheridentifikation
+
+Anhand dieser Ansätze wäre ein solches MP3-Codierungsmodell denkbar, jedoch muss auch die reale Nutzbarkeit beachtet werden, da eine automatische Geschlechtserkennung fehleranfällig wäre und gemischte Inhalte wie z.B. Duette zu Schwierigkeiten führen können. Außerdem besteht abseits davon ein Diskrimierungspotential bei automatischer Klassifizierung für nur marginale Verbesserungen aus technischer Sicht.
+
+---
+#### Aufgabe 8:
+##### Intraframe-Codierung (I-Frames):
+- JPEG-ähnliche Kompression einzelner Bilder
+- DCT, Quantisierung, Entropiecodierung
+##### Interframe-Codierung (P-/B-Frames):
+- **Motion Compensation**: Bewegungsschätzung zwischen Frames
+- **Differenzcodierung**: Nur Unterschiede werden codiert
+- **Predictive Coding**: Vorhersage basierend auf vorherigen Frames
+##### Moderne Verfahren:
+- **H.264/AVC**: Advanced Video Coding
+- **H.265/HEVC**: High Efficiency Video Coding
+- **AV1**: Open-Source-Codec von Alliance for Open Media
+- **VP9**: Google-entwickelter Codec
+
+---
+#### Aufgabe 9:
+##### Szenario A: MIT Beitragsservice (GEZ)
+**Struktur:**
+- ARD/ZDF bleiben zentrale öffentlich-rechtliche Anbieter
+- Pflichtfinanzierung sichert Grundversorgung
+- Private Streaming-Dienste als Ergänzung
+**Vorteile:**
+- Unabhängige, werbefreie Inhalte
+- Bildungsauftrag und Informationsqualität
+- Regionale/lokale Berichterstattung garantiert
+**Herausforderungen:**
+- Konkurrenzdruck durch Netflix, Amazon Prime
+- Generationswechsel zu Streaming-Plattformen
+- Legitimationsdruck bei jüngeren Zielgruppen
+##### Szenario B: OHNE Beitragsservice
+**Struktur:**
+- Vollständig privatisierte/kommerzialisierte Medienlandschaft
+- Abo-Modelle und werbefinanzierte Dienste
+- Marktbasierte Inhaltsproduktion
+**Vorteile:**
+- Marktorientierte, nachfragebasierte Inhalte
+- Keine Zwangsfinanzierung
+- Höhere Innovationsrate
+**Risiken:**
+- Verlust der Meinungsvielfalt
+- Kommerzialisierung aller Inhalte
+- Benachteiligung einkommensschwacher Schichten
+- Wegfall gesellschaftlich wichtiger, aber nicht profitabler Inhalte
+##### Lösung: Hybridmodell
+**Reformierter öffentlich-rechtlicher Bereich:**
+- Reduzierte, zielgerichtete Finanzierung
+- Fokus auf Nachrichten, Bildung, Kultur
+- Stärkere digitale Präsenz durch Apps und Webseiten
+**Ergänzung durch Privatanbieter:**
+- Entertainment und spezialisierte Inhalte
+- Innovative Distributionsformen
+- Internationale Zusammenarbeit

Grafik/Kalki/White Lavender Review/Aufnahmen.md

@@ -0,0 +1,6 @@
+# Aufnahmen
+- [x] Startsequenz ✅ 2025-11-28
+- [x] Walking Video ✅ 2025-11-28
+- [x] Dodge Roll ✅ 2025-11-28
+- [x] Fight ✅ 2025-11-28
+- [x] Look at Screen ✅ 2025-11-28

Grafik/Kalki/White Lavender Review/Drehbuch.md

@@ -0,0 +1,68 @@
+---
+share_link: https://share.note.sx/70wu5aar#4yyPDdY8sVCpafWbQGK11IQo17686i7Qy9lQN8lPBiY
+share_updated: 2025-11-29T18:09:53+01:00
+---
+# Drehbuch
+
+Review zum Spiel "White Lavender"
+
+### Anforderungen:
+
+###### 1. Was soll vermittelt werden:
+
+- Grundlagen und Struktur von Soulslikespielen in Action-RPGs
+- Bewertung der Inhalte des Spiels "White Lavender"
+- Bewertung der technischen Anforderungen des Spiels
+- Fazit zum Spiel und Empfehlung
+- Ziel: Comedyreview (Mischung aus ehrlicher Analyse und witzigen Elementen)
+
+###### 2. Zielgruppe:
+- Gamer, Streamer
+
+### Styleguide/Design:
+- Startszene von Reviewern
+- Spiel im Full Screen
+- Gameplay im Hintergrund
+- Review in Audioformat
+
+### Technischer Entwurf:
+- Videoformat: mkv, mov
+- Editor: Davinci Resolve
+- Audioaufnahme: Audacity 
+- Audioformat: 48kHz, FLAC-Format, Stereo, 24Bit (verlustfreie kompression)
+- Geteilter Speicher für Audios/Videos: NAS-Speicher
+- Geteiltes Skript schreiben: Google Docs
+
+### Skript:
+
+| Szenen-Nr. | Titel      | Inhalte                                                                                                                     | Bild                                                                                                                                                    | Audio/Kommentar                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    | Dauer     |     |
+| ---------- | ---------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------- | --- |
+| 1          | INTRO      | Energetischer Einstieg ins Review                                                                                           | Energetischer Einstieg                                                                                                                                  | "Was passiert, wenn ihr Soulslikes nehmt, einen CRT-Filter drüberkippt und das Ganze aussehen lasst wie ein Fiebertraum aus den 90ern? Richtig – White Lavender! Heute schauen wir uns dieses bunte Indie-Soulslike an, das beweist, dass man nicht immer düster und ernst sein muss, um schwer zu sein. Spoiler: Es ist chaotisch, es ist bunt, und ja – es hat Bugs. Aber lohnt es sich trotzdem? Let's go!"                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     | 0:00-0:20 |     |
+| 2          | SOULSLIKES | Theoretische Erklärung mit Inhalten was Soulslikes ausmacht                                                                 | B-Roll: Ausschnitte aus Dark Souls, Elden Ring, etc.                                                                                                    | "Für die, die noch nie ein Soulslike gespielt haben – hier ein Crash-Course: Soulslikes sind Action-RPGs, die für ihre knallharte Schwierigkeit berüchtigt sind. Ihr seid ein Kämpfer in einer Welt voller Monster und Gefahren – das Ziel? Überleben und stärker werden. Präzises Timing, Ausdauer-Management, Bosskämpfe die euch an den Rand des Wahnsinns treiben, und wenn ihr sterbt? Dann dürft ihr schön zurücklaufen und eure Seelen einsammeln... falls ihr es bis dahin schafft. Die bekanntesten Vertreter? Dark Souls, Elden Ring, Bloodborne – Spiele die legendär dafür sind, dass Gamer ihre Controller an die Wand werfen. White Lavender nimmt diese Formel und dreht den Weird-Regler auf Maximum."                                                                                                                                                                                                                                                                                                                                                                                                                                             | 0:20-0:45 |     |
+| 3          | GRAFIK     | Super einzigartiger retroartiger Grafikstil, sehr bunt, CRT-Filter, lustiges Charakterdesign, Rüstung sichtbar am Charakter | Gameplay von White Lavender mit Fokus auf Visuals, Heranzoomen an Charakter-Füße                                                                        | "Optisch ist das Spiel einfach nicht so das, was man vom Genre kennt. Aber im guten Sinne! Der retro-artige Grafikstil mit dem CRT-Filter sieht aus, als würde man auf einem alten Röhrenfernseher zocken. Alles ist super bunt und poppig – das komplette Gegenteil von den düsteren Souls-Spielen, die am bekanntesten in dem Genre sind. Das Charakterdesign ist absolut goofy und liebenswert. Und das Beste: Eure Rüstung ist tatsächlich am Charakter sichtbar! Fashion Souls könnte man schon fast sagen. Aber schaut euch mal diese Füße an... die kleben förmlich am Boden. Das Movement ist ebenfalls... nun ja, auch echt speziell. Aber dazu kommen wir jetzt."                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | 0:45-1:15 |     |
+| 4          | MOVEMENT   | Movement des Spiels vorstellen                                                                                              | Movement-Showcase, Movement und Fähigkeiten am Anfang des Spiels zeigen                                                                                 | "Also, sprechen wir über Movement. Am Anfang fühlt sich euer Charakter an wie... naja, wie jemand der in Honig watet. Ihr habt die Basic-Bewegungen: Laufen, Rollen, Springen – aber es fühlt sich etwas schwerfällig an. Die Füße haben wirklich diesen 'klebe-am-Boden-Effekt', was dem Ganzen einen ungewollt komischen Touch gibt. Aber hey, sobald ihr ein paar Fähigkeiten freischaltet und euch an die Physik gewöhnt habt, wird's besser. Es ist anders, aber man gewöhnt sich dran."                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | 1:15-1:35 |     |
+| 5          | ENEMIES    | Combat gegen normale Gegner im Detail bewerten                                                                              | Kampfszenen gegen normale Gegner, Hitbox-Problem zeigen, verschiedene Waffen zeigen                                                                     | "Der Combat gegen normale Gegner macht grundsätzlich Spaß – aber er hat leider seine Macken. Timing-basiertes Angreifen, Ausweichen, Ausdauer-Management – das Soulslike-Package ist vollstens vorhanden. ABER: Gerade bei größeren Waffen merkt man den Animation Lock heftig. Einmal geschwungen, seid ihr committed – und dann kanns tödlich sein. Und dann die Hitboxen... besonders bei kleineren Gegnern gehen eure Angriffe manchmal einfach daneben. Das ist frustrierend, wenn ihr wisst, dass der Hit eigentlich sitzen sollte. Aber positiv ist: Das Spiel fördert echt das Waffenexperimentieren! Verschiedene Gebiete, verschiedene Gegnertypen – da lohnt es sich, mehrere Waffen auszuprobieren. Die Waffenvielfalt ist cool, von Standard bis komplett abgedreht."                                                                                                                                                                                                                                                                                                                                                                                 | 1:35-2:00 |     |
+| 6          | BOSSE      | Bossdesign und Schwierigkeit des Spiels bewerten                                                                            | Boss-Kampf-Footage, Endboss-Kampf, Kampfszenen gegen verschiedene Bosse                                                                                 | "Und dann kommen wir zum Herzstück eines jeden Soulslikes, den Bossen... ein zweischneidiges Schwert in diesem Spiel. Das Bossdesign ist kreativ und jeder Boss sieht unique aus. ABER: Die Patterns sind manchmal echt simpel und langweilig. Nach ein, zwei Versuchen habt ihr die meisten Bosse durchschaut. Der Endboss ist im Vergleich zu den anderen Bossen extrem schwach. Wir haben sogar diesen Bug gefunden: [PAUSE] Wenn man direkt unter ihm steht, kann er euch nicht treffen. Da steht man dann und wundert sich... [PAUSE] Die Schwierigkeit ist also sehr inkonsistent – manche Bosse machen euch das Leben zur Hölle und andere macht ihr im Schlaf."                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            | 2:00-2:30 |     |
+| 7          | ERKUNDEN   | Bewertung des Erlebnisses beim Erkunden des Spiels in der Open World                                                        | Open World Exploration, Portal-Reisen, Items aufheben zeigen, Traveling durch Portale (alle Gebiete zeigen), verschiedene Items auffindbar über die Map | "Die Open World zu erkunden macht echt Laune! Ihr reist durch verschiedene Gebiete via Portale – und jedes Gebiet hat seinen eigenen Vibe. Von bunten Wäldern, über dunkle Höhlen bis zu trippy Landschaften ist alles dabei. Überall findet ihr Items, Geheimnisse und versteckte Wege. Es lohnt sich also definitiv, jeden Winkel zu erkunden. [PAUSE] Aber das Gefühl, wenn man einen versteckten Schatz findet? _Chef's kiss_ Unbezahlbar"                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     | 2:25-2:45 |     |
+| 8          | NPCs       | NPC-Interaktionen bewerten und dessen Qualität/Tiefe, Questlines, Humorvoller Touch                                         | NPC-Gespräche, Szenen beim Reden mit NPCs                                                                                                               | "Die NPCs in White Lavender sind sogar überraschend charmant! Die Dialoge haben einen humorvollen Touch und die Questlines sind echt interessant. Klar, es ist jetzt keine narrative Meisterleistung wie man es von AAA-Titeln kennt, aber die NPCs haben Persönlichkeit und sorgen für ein paar Lacher während des Gameplays. Insgesamt fühlen sich die Interaktionen lebendiger an als man von einem Indie-Titel vielleicht erwarten würde."                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     | 2:45-3:05 |     |
+| 9          | MUSIK      | Kurze Erklärung was für Musik genutzt wird (Genre) und ob es zum Charakter des Spiels passt                                 | Hintergrund-Gameplay mit Musik, Hintergrundgameplay von White Lavender                                                                                  | "Der Soundtrack passt perfekt zum psychedelischen Vibe des Spiels. Es ist oft diese Mischung aus ambient und retro-synth Sounds, die das Ganze zusammenhält. Zusätzlich sind auch wirklich häufig Banger dabei, die man jetzt nicht so erwartet hat. Die Musik untermalt so die sowohl entspannenden Momente wie das Erkunden in der Welt als auch die sehr aufregenden Momente des Spiel wie die Bosskämpfe."                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     | 3:05-3:20 |     |
+| 10         | BUGS       | Aktuelle Probleme des Spiels und Fehler bei unserem Run                                                                     | Bug-Footage, spezifische Bug-Beispiele zeigen, Endboss-Bug nochmal zeigen, spezifische Ausschnitte der Bugs                                             | "Okay, jetzt müssen wir noch über den Elefanten im Raum sprechen: nämlich die Bugs im Spiel. Und oh junge, die Liste ist lang. Wir hatten: Enemy Snapping-Probleme – Gegner teleportieren sich plötzlich, Clipping-Issues und Gegner die in Wänden stecken, Framerate-Drops, und der absolute  Kracher: Am Ende unseres Runs ließen sich Gegner GAR NICHT MEHR anvisieren. Also so komplett. Das Target-Lock-System hat einfach aufgegeben. Und wie gesagt, der Endboss kann euch nicht treffen wenn ihr unter ihm steht. Das ist jetzt weniger ein Bug und mehr ein 'haben wir nicht gebalanced'-Problem. Für ein Indie-Spiel ist das nicht ungewöhnlich, aber aktuell müsst ihr mit diesen technischen Problemen leider leben. Die Devs patchen hoffentlich fleißig, [PAUSE, dann leise] Gott bewahre... "                                                                                                                                                                                                                                                                                                                                                       | 3:20-3:45 |     |
+| 11         | FAZIT      | Scoring System und Bewertung zusammenfassen übers Video                                                                     | Zusammenfassung mit Best-of Footage, Hintergrund: Gameplay (unscharf), Vordergrund: Grafiken der vergebenen Scorings pro Videosektion, Outro            | "White Lavender ist ein ambitioniertes Indie-Soulslike mit einer richtig coolen Idee. Der einzigartige Artstyle und die bunte Welt sind erfrischend anders. Das Waffenexperimentieren macht Spaß und die notwendige Varietät ist da. ABER: Die technischen Probleme und Design-Schwächen ziehen das Erlebnis deutlich runter. Animation Lock, miese Hitboxen, simple Bosspatterns, ein viel zu schwacher Endboss, und Bugs die das Spiel teilweise unspielbar machen – das muss man als Spieler auch erstmal schlucken, wenn man das zu spät nach einem Kauf merkt. Es fühlt sich an wie ein Early Access-Titel der noch ein paar Monate Entwicklung braucht. Das Potential ist da, aber aktuell ist es eher was für die hardcore Indie-Fans, die über technische Probleme hinwegsehen können. Wenn die Devs weiter dran arbeiten sollten, könnte das wirklich eine gute Abwechslung zu den eher bekannten Soulslike-Titeln wie eben Dark Souls oder Elden Ring werden. Aber im aktuellen Zustand? Eher schwierig. Habt ihr White Lavender schon gespielt und was sind eure Erfahrungen mit Soulslike Spielen? Lasst es und gerne wissen und bis zum nächsten Mal! | 3:45-4:10 |     |
+
+---
+
+## NOTIZEN FÜR DIE BEARBEITUNG:
+
+- **Pacing:** Schnelle Cuts, dynamische Übergänge
+- **B-Roll:** Viel Gameplay-Material, Bug-Highlights besonders wichtig
+- **Kritische Momente betonen:**
+    - Animation Lock bei großen Waffen zeigen
+    - Hitbox-Fails bei kleinen Gegnern
+    - Enemy Snapping deutlich machen
+    - Target-Lock Bug am Ende des Videos
+    - Endboss-Schwäche (unter ihm stehen)
+    - Simple/langweilige Bosspatterns
+- **Musik:** Energetische Hintergrundmusik, White Lavender OST wo passend
+- **Text-Overlays:** Bei Bugs und kritischen Punkten
+- **Balance:** Positive Aspekte zeigen, aber ehrlich bei Problemen sein
+- **Länge:** ~4:00-4:15 Minuten final

Grafik/Kalki/White Lavender Review/Prod TODOs.md

@@ -0,0 +1,8 @@
+# TODOs
+
+- [x] Texte aufnehmen
+- [x] Soulslike Gameplay aufnehmen (Khazan, Elden Ring, Dark Souls)
+- [ ] Doku schreiben
+
+
+

Grafik/Kalki/White Lavender Review/Projektinformationen.md

@@ -0,0 +1,22 @@
+# Projekt
+
+#### Randbedingungen
+Partner: Domi
+Rahmen: 
+- Medienkompetenz
+- Praktische Anwendungen
+- Praktisches Projekt
+
+**Ideen**:
+1. Generell: Koop in Website Games Koop in Websites wie [Bruno Simon Portfolio](https://bruno-simon.com/)
+	- 2D/3D Mario Website Game (1 Welt, paar Level)
+	- Rythmusgame
+2. Animation zu:
+	- Calisthenicsübung
+	- Schmetterlingseffekt-Video
+3. **Reviews zu** **(Greenscreen + Cam + Mic, "very serious")**: 
+	- lustiges, dummes Spiel (z.B. White Lavender)
+	- schäbiges Spiel
+	- Tierlist zu irgendwas unnötigem
+	- irgendwas im echten Leben (Calisthenics, Papier, Holzfeeling, Filme)
+

Grafik/White Lavender Review/Drehbuch(Projekt).md

@@ -0,0 +1,42 @@
+---
+share_link: https://share.note.sx/7nwowzi5#4yyPDdY8sVCpafWbQGK11IQo17686i7Qy9lQN8lPBiY
+share_updated: 2025-10-18T17:09:11+02:00
+---
+# Drehbuch
+Review zum Spiel "White Lavender"
+
+### Anforderungen:
+###### 1. Was soll vermittelt werden:
+- Grundlagen und Struktur von Soulslikespielen in Action-RPGs
+- Bewertung der Inhalte des Spiels "White Lavender"
+- Bewertung der technischen Anforderungen des Spiels
+- Fazit zum Spiel und Empfehlung
+- Ziel: Comedyreview (Mischung aus ehrlicher Analyse und witzigen Elementen)
+###### 2. Zielgruppe:
+- Gamer, Streamer
+
+### Styleguide/Design:
+- Einblendung der Reviewer im Stehen mit Mikrofon und Greenscreen im Video unten rechts oder andere Ecken je nach aktuellem Inhalt
+- Spiel im Full Screen
+- Gameplay im Hintergrund
+- Einblendung von Informationen in Textform zu gegebener Zeit
+### Technischer Entwurf:
+- Videoformat: mkv, mov
+- Editor: Davinci Resolve
+- Versionsverwaltung: NAS-Speicher
+
+### Skript:
+
+| Szenen-Nr. | Titel                              | Inhalte                                                                                                                                                                           | Bild                                                                                                            | Audio/Kommentar | Dauer |
+| ---------- | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------- | ----- |
+| 1          | Einführung ins Review              | Story vorstellen                                                                                                                                                                  | (Einblendung) Anfangsszene des Spiels zur Story vom Main Character und der kranken Schwester                    |                 |       |
+| 2          | Erklärung des Genres: Soulslike    | Theoretische Erklärung mit Inhalten was Soulslikes ausmacht                                                                                                                       | Zusammenschnitt mehrerer Ausschnitte aus Soulslikes wie Dark Souls, Elden Ring und weiteren Beispielen          |                 |       |
+| 3          | Grafikstil/Designbewertung         | Super einzigartiger retroartiger Grafikstil, sehr bunt, CRT-Filter, lustiges Charakterdesign, Rüstung sichtbar am Charakter,  Überleitung zu Movement mit goofy Füßeklebenbleiben | Gameplay mit Inhalten von lustigen Skins und Waffen, Heranzoomen an bestimmte Inhalte wie das Füßeklebenbleiben |                 |       |
+| 4          | Spielabläufe: Movement             | Movement des Spiels vorstellen                                                                                                                                                    | Movement und Fähigkeiten am Anfang des Spiels zeigen                                                            |                 |       |
+| 5          | Spielabläufe: Combat gegen Enemies | Combat gegen normale Gegner im Detail bewerten                                                                                                                                    | Kampfszenen gegen verschiedene Gegner                                                                           |                 |       |
+| 6          | Spielabläufe: Combat gegen Bosse   | Bossdesign und Schwierigkeit des Spiels bewerten                                                                                                                                  | Kampfszenen gegen verschieden Bosse                                                                             |                 |       |
+| 7          | Spielabläufe: Erkunden             | Bewertung des Erlebnisses beim Erkunden des Spiels in der Open World                                                                                                              | Traveling durch Portale (mal alle Gebiete zeigen), verschiedene Items auffindbar über die Map                   |                 |       |
+| 8          | Spielabläufe: NPC Interaktion      | NPC-Interaktionen bewerten und dessen Qualität/Tiefe, Questlines, Humorvoller Touch                                                                                               | Szenen beim Reden mit NPCs                                                                                      |                 |       |
+| 9          | Musik                              | Kurze Erklärung was für Musik genutzt wird (Genre) und ob es zum Spielcharakter passt                                                                                             | ?                                                                                                               |                 |       |
+| 10         | Bugs                               | Aktuelle Probleme des Spiels und Fehler bei unserem Run                                                                                                                           | Spezifische Ausschnitte der Bugs, was genau falsch ist                                                          |                 |       |
+| 11         | Fazit                              | Scoring System und Bewertung zusammenfassen übers Video                                                                                                                           | Hintergrund: Gameplay (unscharf) Vordergrund: Grafiken der vergebenen Scorings pro Videosektion                 |                 |       |

Grafik/White Lavender Review/Projektinformationen.md

@@ -0,0 +1,22 @@
+# Projekt
+
+#### Randbedingungen
+Partner: Domi
+Rahmen: 
+- Medienkompetenz
+- Praktische Anwendungen
+- Praktisches Projekt
+
+**Ideen**:
+1. Generell: Koop in Website Games Koop in Websites wie [Bruno Simon Portfolio](https://bruno-simon.com/)
+	- 2D/3D Mario Website Game (1 Welt, paar Level)
+	- Rythmusgame
+2. Animation zu:
+	- Calisthenicsübung
+	- Schmetterlingseffekt-Video
+3. **Reviews zu** **(Greenscreen + Cam + Mic, "very serious", anschließendes Interview mit Alex)**: 
+	- lustiges, dummes Spiel (z.B. White Lavender)
+	- schäbiges Spiel
+	- Tierlist zu irgendwas unnötigem
+	- irgendwas im echten Leben (Calisthenics, Papier, Holzfeeling, Filme)
+