{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Prüfungskern\nWas ist der typische Lösungsweg für praktische Datenbankaufgaben?","answer":"1. **Schema verstehen:** Tabellen, Attribute, Primär- und Fremdschlüssel erkennen.\n2. **Integrität prüfen:** `NOT NULL`, `UNIQUE`, `CHECK`, `FOREIGN KEY` und Referenzaktionen beachten.\n3. **Passenden SQL-Befehl wählen:** DDL, DML, DQL, DCL oder TCL.\n4. **Bedingungen sauber setzen:** besonders `WHERE`, `JOIN ... ON`, `GROUP BY`, `HAVING`.\n5. **Nebenwirkungen prüfen:** Transaktion, Sperren, Constraints, Performance, NoSQL-Abgrenzung.","tags":["pruefung","ueberblick"],"source":"Zusammenfassung §1; Übungsklausur","external_id":"db-praktisch-001"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Daten, Information, Wissen\nWie unterscheiden sich Daten, Information und Wissen?","answer":"- **Daten:** rohe Zeichen/Werte ohne Kontext, z. B. `42`.\n- **Information:** Daten mit Bedeutung/Kontext, z. B. `42 offene Bestellungen`.\n- **Wissen:** interpretierte Information plus Erfahrung/Regeln, z. B. `42 offene Bestellungen sind SLA-kritisch`.\n\nPrüfungsfalle: Nicht jeden gespeicherten Wert automatisch als Wissen bezeichnen.","tags":["grundlagen"],"source":"Zusammenfassung §2.1; Skript Einführung","external_id":"db-praktisch-002"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Datenbank, DBMS, Datenbanksystem\nWas ist der Unterschied?","answer":"- **Datenbank:** logisch zusammengehörender Datenbestand inklusive Metadaten.\n- **DBMS:** Software zum Definieren, Speichern, Abfragen, Sichern und Verwalten der Daten.\n- **Datenbanksystem:** Datenbank + DBMS + Anwendungskontext/Nutzer/Hardware.\n\nBeispiel: PostgreSQL als DBMS, konkrete Kundendatenbank als Datenbank.","tags":["grundlagen","dbms"],"source":"Zusammenfassung §2.2; Skript Einführung","external_id":"db-praktisch-003"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# DBMS-Anforderungen\nWelche zentralen Aufgaben übernimmt ein DBMS?","answer":"Ein DBMS übernimmt typischerweise:\n\n- Datenbanksprachen: DDL, DML/DQL, DCL, TCL\n- Zugriffskontrolle und Autorisierung\n- Integritätssicherung\n- Recovery nach Fehlern\n- Mehrbenutzer-Synchronisation\n- Optimierung und effizienter physischer Zugriff\n\nKernidee: Anwendungen sollen nicht direkt auf physischen Dateien arbeiten.","tags":["grundlagen","dbms"],"source":"Skript Einführung S. 11; Zusammenfassung §2.2","external_id":"db-praktisch-004"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SQL-Sprachklassen\nWofür stehen DDL, DML, DQL, DCL und TCL?","answer":"| Klasse | Zweck | Beispiele |\n|---|---|---|\n| DDL | Strukturen definieren/ändern | `CREATE`, `ALTER`, `DROP` |\n| DML | Daten ändern | `INSERT`, `UPDATE`, `DELETE` |\n| DQL | Daten abfragen | `SELECT` |\n| DCL | Rechte steuern | `GRANT`, `REVOKE` |\n| TCL | Transaktionen steuern | `COMMIT`, `ROLLBACK` |\n\nPrüfungsfalle: `CREATE` fügt keine Nutzdaten ein.","tags":["sql","grundlagen"],"source":"Zusammenfassung §2.3; SQL Teil 1","external_id":"db-praktisch-005"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# ANSI-SPARC\nWelche drei Ebenen beschreibt die ANSI-SPARC-Architektur?","answer":"1. **Externe Ebene:** Benutzersichten, z. B. Views oder Anwendungsausschnitte.\n2. **Konzeptionelle Ebene:** logisches Gesamtschema.\n3. **Interne Ebene:** physische Speicherung, Indexe, Zugriffspfade.\n\nZiel: **Datenunabhängigkeit**. Änderungen unten sollen möglichst wenig Auswirkungen oben haben.","tags":["architektur"],"source":"Zusammenfassung §2.4; Skript Einführung","external_id":"db-praktisch-006"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Relationales Modell\nWie werden Tabellen formal verstanden?","answer":"Eine Tabelle ist eine **Relation**:\n\n- Spalten = Attribute\n- Zeilen = Tupel/Datensätze\n- Domänen = zulässige Wertebereiche\n- Ergebnis relationaler Operationen ist wieder eine Relation\n\nTypische Operatoren: Selektion $\\sigma$, Projektion $\\pi$, Verbund $R \\bowtie S$.","tags":["relationales-modell","sql"],"source":"Zusammenfassung §2.4; SQL Teil 1 S. 3","external_id":"db-praktisch-007"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Primärschlüssel vs Fremdschlüssel\nWie unterscheiden sie sich?","answer":"- **Primärschlüssel (`PRIMARY KEY`):** identifiziert jede Zeile eindeutig; impliziert `UNIQUE` und `NOT NULL`.\n- **Fremdschlüssel (`FOREIGN KEY`):** verweist auf einen Schlüssel einer anderen oder derselben Tabelle.\n\nPrüfungsfalle: Ein Fremdschlüssel ist nicht automatisch eindeutig. Viele Kindzeilen dürfen auf denselben Elternsatz zeigen.","tags":["ddl","constraints"],"source":"Zusammenfassung §4.4-4.5; SQL Teil 1","external_id":"db-praktisch-008"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# PostgreSQL\nWarum eignet sich PostgreSQL als Kursdatenbank?","answer":"PostgreSQL ist:\n\n- frei und quelloffen\n- nah am SQL-Standard\n- ACID-konform, auch bei vielen DDL-Operationen\n- stark erweiterbar: Typen, Funktionen, Operatoren, PL/pgSQL, JSON/JSONB\n- praktisch geeignet für SQL, Transaktionen, Trigger und NoSQL-nahe Erweiterungen","tags":["postgresql"],"source":"Zusammenfassung §3.1; SQL Teil 1","external_id":"db-praktisch-009"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# DBeaver\nWelche Rolle spielt DBeaver in der Vorlesung?","answer":"DBeaver ist ein plattformunabhängiger Datenbankclient mit SQL-Editor, Syntax-Highlighting, Autovervollständigung, Import/Export und Schema-Visualisierung.\n\nPrüfungsfalle: Die Visualisierung wird oft als ER-Modell bezeichnet, zeigt praktisch aber meist das **Relationenschema** mit Tabellen und Fremdschlüsseln.","tags":["postgresql","tooling"],"source":"Zusammenfassung §3.2","external_id":"db-praktisch-010"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SQL-Konventionen\nWelche Schreibkonventionen sind wichtig?","answer":"- SQL-Schlüsselwörter groß schreiben: `SELECT`, `FROM`, `WHERE`.\n- Nicht gequotete PostgreSQL-Bezeichner werden klein normalisiert.\n- Quoted identifiers wie `\"CustomerID\"` sind case-sensitive.\n- Konkrete Spalten besser explizit nennen statt `SELECT *`.\n\nSQL ist deklarativ: Es beschreibt **was** geliefert werden soll, nicht **wie** der Zugriff technisch erfolgt.","tags":["sql","postgresql"],"source":"Zusammenfassung §3.3; SQL Teil 2 S. 3","external_id":"db-praktisch-011"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SELECT *\nWarum ist `SELECT *` in Klausurantworten riskant?","answer":"`SELECT *` ist bequem, aber unpräzise:\n\n- gibt alle Spalten zurück, auch unerwünschte\n- macht Ergebnis abhängig von Schemaänderungen\n- kann bei Joins doppelte/mehrdeutige Spalten liefern\n- zeigt nicht, ob die geforderte Projektion verstanden wurde\n\nWenn konkrete Attribute gefragt sind: explizit projizieren.","tags":["sql","pruefungsfalle"],"source":"Zusammenfassung §3.3","external_id":"db-praktisch-012"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# CREATE TABLE\nWie sieht ein typisches `CREATE TABLE` mit Constraints aus?","answer":"```sql\nCREATE TABLE album (\n  album_id INTEGER PRIMARY KEY,\n  title VARCHAR(160) NOT NULL,\n  artist_id INTEGER NOT NULL,\n  CONSTRAINT fk_album_artist\n    FOREIGN KEY (artist_id)\n    REFERENCES artist(artist_id)\n);\n```\n\nWichtig: Datentypen, `NOT NULL`, Primärschlüssel und Fremdschlüssel vollständig notieren.","tags":["ddl","sql"],"source":"Zusammenfassung §4.1; Übungsklausur Typ DDL","external_id":"db-praktisch-013"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# PostgreSQL-Datentypen\nWelche Datentypen sind klausurrelevant?","answer":"Typische Datentypen:\n\n- Zahlen: `INTEGER`, `BIGINT`, `NUMERIC(p, s)`, `REAL`, `DOUBLE PRECISION`\n- Text: `CHAR(n)`, `VARCHAR(n)`, `TEXT`\n- Zeit: `DATE`, `TIME`, `TIMESTAMP`\n- Boolean: `BOOLEAN`\n- Automatische IDs: `SERIAL` oder standardnäher `GENERATED ... AS IDENTITY`\n\nPrüfungsfalle: `SERIAL` ist PostgreSQL-praktisch, aber kein echter Standard-SQL-Typ.","tags":["ddl","postgresql"],"source":"Zusammenfassung §4.2; SQL Teil 1","external_id":"db-praktisch-014"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# NULL\nWas bedeutet `NULL` in SQL?","answer":"`NULL` bedeutet **unbekannt, nicht vorhanden oder nicht anwendbar**. Es ist kein leerer String und nicht die Zahl `0`.\n\nRegeln:\n\n- Vergleich mit `=` funktioniert nicht: nutze `IS NULL` / `IS NOT NULL`.\n- Viele Aggregatfunktionen ignorieren `NULL`.\n- `COUNT(*)` zählt Zeilen, `COUNT(spalte)` zählt nur Nicht-NULL-Werte.","tags":["sql","null"],"source":"Zusammenfassung §6.3-6.4; SQL Teil 2 S. 69","external_id":"db-praktisch-015"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Constraints\nWelche Integritätsbedingungen solltest du bei DDL-Aufgaben prüfen?","answer":"- `PRIMARY KEY`: eindeutige, nicht-leere Identifikation\n- `FOREIGN KEY`: referentielle Integrität\n- `UNIQUE`: Eindeutigkeit ohne Primärschlüsselrolle\n- `NOT NULL`: Pflichtfeld\n- `CHECK`: fachliche Bedingung, z. B. `price >= 0`\n- `DEFAULT`: Standardwert beim Einfügen\n\nKlausurtechnik: Erst Relationenschema lesen, dann jede Bedingung explizit in SQL übersetzen.","tags":["ddl","constraints"],"source":"Zusammenfassung §4.4; SQL Teil 1","external_id":"db-praktisch-016"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# PRIMARY KEY vs UNIQUE\nWie unterscheiden sich `PRIMARY KEY` und `UNIQUE`?","answer":"- `PRIMARY KEY` identifiziert die Zeile zentral und erlaubt keine `NULL`-Werte.\n- `UNIQUE` verhindert doppelte Werte, ist aber nicht der primäre Identifikator.\n- Eine Tabelle hat höchstens einen Primärschlüssel, aber mehrere `UNIQUE`-Constraints.\n\nPostgreSQL-Hinweis: `UNIQUE` erlaubt bei `NULL` typischerweise mehrere `NULL`-Einträge, weil `NULL` unbekannt ist.","tags":["ddl","constraints"],"source":"Zusammenfassung §4.4","external_id":"db-praktisch-017"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Fremdschlüssel-Aktionen\nWas bedeuten `CASCADE`, `RESTRICT` und `SET NULL`?","answer":"- `ON DELETE CASCADE`: Löschen des Elternsatzes löscht abhängige Kindzeilen mit.\n- `ON DELETE RESTRICT` / `NO ACTION`: Löschen wird verhindert, solange Kindzeilen existieren.\n- `ON DELETE SET NULL`: Fremdschlüssel in Kindzeilen wird auf `NULL` gesetzt.\n\nPrüfungsfalle: `SET NULL` passt nur, wenn die FK-Spalte `NULL` erlauben darf.","tags":["ddl","constraints"],"source":"Zusammenfassung §4.5; SQL Teil 1","external_id":"db-praktisch-018"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Referentielle Integrität\nWas stellt sie sicher?","answer":"Referentielle Integrität stellt sicher, dass ein Fremdschlüsselwert auf einen existierenden Datensatz der referenzierten Tabelle verweist.\n\n```sql\nFOREIGN KEY (artist_id) REFERENCES artist(artist_id)\n```\n\nDann darf `album.artist_id` nur Werte enthalten, die in `artist.artist_id` existieren - außer die Spalte erlaubt `NULL`.","tags":["ddl","constraints"],"source":"Zusammenfassung §4.5","external_id":"db-praktisch-019"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# ALTER TABLE\nWofür nutzt man `ALTER TABLE`?","answer":"`ALTER TABLE` ändert bestehende Tabellenstrukturen:\n\n```sql\nALTER TABLE album ADD COLUMN release_year INTEGER;\nALTER TABLE album DROP COLUMN release_year;\nALTER TABLE album ADD CONSTRAINT chk_year CHECK (release_year >= 1900);\n```\n\nKlausurpunkt: `ALTER` ändert Struktur, `UPDATE` ändert Daten.","tags":["ddl","sql"],"source":"Zusammenfassung §4.3; SQL Teil 1","external_id":"db-praktisch-020"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# DROP und CASCADE\nWas ist bei `DROP ... CASCADE` zu beachten?","answer":"`DROP` löscht Datenbankobjekte. Mit `CASCADE` werden abhängige Objekte mitgelöscht.\n\n```sql\nDROP TABLE artist CASCADE;\n```\n\nDas kann abhängige Fremdschlüssel, Views oder weitere Objekte betreffen. Nur verwenden, wenn Abhängigkeiten wirklich mit entfernt werden sollen.","tags":["ddl","pruefungsfalle"],"source":"Zusammenfassung §4.3; SQL Teil 1","external_id":"db-praktisch-021"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# INSERT\nWie schreibt man ein robustes `INSERT`?","answer":"```sql\nINSERT INTO genre (genre_id, name)\nVALUES (1, 'Rock');\n```\n\nRobust, weil die Spaltenliste explizit ist. Ohne Spaltenliste müssen Anzahl, Reihenfolge und Typen exakt zur Tabelle passen.","tags":["dml","sql"],"source":"Zusammenfassung §5.1; SQL Teil 1","external_id":"db-praktisch-022"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# INSERT SELECT\nWann verwendet man `INSERT ... SELECT`?","answer":"Wenn Daten aus einer Abfrage in eine Tabelle übernommen werden sollen:\n\n```sql\nINSERT INTO premium_customer (customer_id, name)\nSELECT customer_id, name\nFROM customer\nWHERE total_revenue > 1000;\n```\n\nDie ausgewählten Spalten müssen zur Zieltabelle passen: Anzahl, Reihenfolge und kompatible Datentypen.","tags":["dml","sql"],"source":"Zusammenfassung §5.1","external_id":"db-praktisch-023"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# UPDATE\nWas ist die wichtigste Prüfungsfalle bei `UPDATE`?","answer":"Eine fehlende oder falsche `WHERE`-Klausel ändert zu viele Zeilen.\n\n```sql\nUPDATE track\nSET unit_price = unit_price * 1.10\nWHERE genre_id = 1;\n```\n\nOhne `WHERE` würden alle Tracks geändert. Bei DML immer prüfen: **Welche Zeilen sind betroffen?**","tags":["dml","pruefungsfalle"],"source":"Zusammenfassung §5.2; SQL Teil 1","external_id":"db-praktisch-024"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# DELETE vs TRUNCATE\nWie unterscheiden sie sich?","answer":"- `DELETE FROM t WHERE ...`: löscht ausgewählte Zeilen, kann gefiltert werden.\n- `DELETE FROM t`: löscht alle Zeilen, aber zeilenorientiert.\n- `TRUNCATE t`: leert Tabelle meist schneller und struktureller, ohne `WHERE`.\n\nWenn nur bestimmte Datensätze gelöscht werden sollen, brauchst du `DELETE ... WHERE`.","tags":["dml","sql"],"source":"Zusammenfassung §5.3","external_id":"db-praktisch-025"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SELECT-Reihenfolge\nIn welcher logischen Reihenfolge wird `SELECT` verarbeitet?","answer":"Logische Reihenfolge:\n\n1. `FROM` / `JOIN`\n2. `WHERE`\n3. `GROUP BY`\n4. `HAVING`\n5. `SELECT`\n6. `DISTINCT`\n7. `ORDER BY`\n8. `LIMIT` / `OFFSET`\n\nMerke: `WHERE` filtert Zeilen vor der Gruppierung, `HAVING` Gruppen nach der Gruppierung.","tags":["dql","sql"],"source":"Zusammenfassung §6.1; SQL Teil 2","external_id":"db-praktisch-026"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SELECT-Minimum\nWelche Bestandteile sind bei einer einfachen Tabellenabfrage zwingend?","answer":"Normalerweise:\n\n```sql\nSELECT spalten\nFROM tabelle;\n```\n\nOptional: `WHERE`, `GROUP BY`, `HAVING`, `ORDER BY`, `LIMIT`.\n\nKlausurrelevant: `SELECT` und `FROM` sind die Pflichtbestandteile klassischer Tabellenabfragen.","tags":["dql","sql"],"source":"SQL Teil 2 S. 69; Zusammenfassung §6.1","external_id":"db-praktisch-027"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Aliase\nWarum nutzt man Aliase in SQL?","answer":"Aliase verbessern Lesbarkeit und vermeiden Mehrdeutigkeit:\n\n```sql\nSELECT c.last_name AS nachname, i.total\nFROM customer AS c\nJOIN invoice AS i ON i.customer_id = c.customer_id;\n```\n\nBesonders wichtig bei Joins, Self Joins und berechneten Spalten.","tags":["dql","sql"],"source":"Zusammenfassung §6.2; SQL Teil 2 S. 69","external_id":"db-praktisch-028"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# DISTINCT\nWas macht `DISTINCT` und warum ist es nicht immer harmlos?","answer":"`DISTINCT` entfernt doppelte Ergebniszeilen.\n\nSQL arbeitet grundsätzlich mit Multimengen: gleiche Zeilen dürfen mehrfach vorkommen.\n\nPrüfungsfalle: `DISTINCT` kann einen falschen Join kaschieren, der eigentlich unnötige Duplikate erzeugt.","tags":["dql","sql","pruefungsfalle"],"source":"Zusammenfassung §6.2; SQL Teil 2","external_id":"db-praktisch-029"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# COUNT\nWie unterscheiden sich `COUNT(*)` und `COUNT(spalte)`?","answer":"- `COUNT(*)` zählt alle Zeilen der Ergebnisgruppe.\n- `COUNT(spalte)` zählt nur Zeilen, in denen `spalte IS NOT NULL` ist.\n\nWenn `email` teilweise `NULL` ist, ist `COUNT(email)` kleiner als `COUNT(*)`.","tags":["dql","aggregation","null"],"source":"Zusammenfassung §6.3; SQL Teil 2 S. 69","external_id":"db-praktisch-030"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Aggregatfunktionen und NULL\nWie behandeln Aggregatfunktionen `NULL`?","answer":"Viele Aggregatfunktionen ignorieren `NULL`:\n\n- `SUM(spalte)` ignoriert `NULL`\n- `AVG(spalte)` mittelt nur Nicht-NULL-Werte\n- `MIN`/`MAX` ignorieren `NULL`\n- `COUNT(spalte)` zählt Nicht-NULL-Werte\n- `COUNT(*)` zählt alle Zeilen","tags":["dql","aggregation","null"],"source":"Zusammenfassung §6.3","external_id":"db-praktisch-031"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# WHERE-Operatoren\nWelche typischen Operatoren gehören in die `WHERE`-Klausel?","answer":"Typische Filter:\n\n```sql\nWHERE price >= 10\nWHERE country IN ('Germany', 'Austria')\nWHERE total BETWEEN 100 AND 500\nWHERE name LIKE 'A%'\nWHERE deleted_at IS NULL\n```\n\nErst Zeilenbedingung formulieren, dann Gruppierung/Aggregation ergänzen.","tags":["dql","sql"],"source":"Zusammenfassung §6.4","external_id":"db-praktisch-032"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# LIKE\nWas bedeuten `%` und `_` in `LIKE`-Mustern?","answer":"- `%` steht für beliebig viele Zeichen, auch null Zeichen.\n- `_` steht für genau ein beliebiges Zeichen.\n\n```sql\nWHERE name LIKE 'A%'   -- beginnt mit A\nWHERE code LIKE 'A_1'  -- A, genau ein Zeichen, dann 1\n```\n\n`LIKE 'A_'` passt nicht auf `A` und nicht auf `ABC`.","tags":["dql","sql"],"source":"Zusammenfassung §6.4; SQL Teil 2 S. 69","external_id":"db-praktisch-033"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# NULL-Vergleich\nWarum ist `WHERE spalte = NULL` falsch?","answer":"`NULL` ist unbekannt. Der Vergleich `= NULL` ergibt nicht `TRUE`.\n\nRichtig:\n\n```sql\nWHERE spalte IS NULL\nWHERE spalte IS NOT NULL\n```\n\nDas ist eine häufige Klausurfalle bei Filtern und Aggregaten.","tags":["dql","null","pruefungsfalle"],"source":"Zusammenfassung §6.4; SQL Teil 2 S. 69","external_id":"db-praktisch-034"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# ORDER BY, LIMIT, OFFSET\nWofür nutzt man diese Klauseln?","answer":"- `ORDER BY`: sortiert das Ergebnis.\n- `LIMIT`: begrenzt die Anzahl der zurückgegebenen Zeilen.\n- `OFFSET`: überspringt Zeilen, oft für Pagination.\n\n```sql\nSELECT *\nFROM invoice\nORDER BY invoice_date DESC\nLIMIT 10 OFFSET 20;\n```\n\nOhne `ORDER BY` ist die Reihenfolge nicht verlässlich.","tags":["dql","sql"],"source":"Zusammenfassung §6.1; SQL Teil 2 S. 69","external_id":"db-praktisch-035"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# GROUP BY und HAVING\nWann nutzt man `GROUP BY`, wann `HAVING`?","answer":"`GROUP BY` bildet Gruppen. `HAVING` filtert Gruppen nach Aggregation.\n\n```sql\nSELECT country, COUNT(*) AS anzahl\nFROM customer\nGROUP BY country\nHAVING COUNT(*) > 1;\n```\n\n`WHERE` filtert einzelne Zeilen vorher; `HAVING` aggregierte Gruppen nachher.","tags":["dql","aggregation"],"source":"Zusammenfassung §6.6; Übungsklausur","external_id":"db-praktisch-036"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# GROUP-BY-Regel\nWelche Spalten dürfen in der `SELECT`-Liste stehen?","answer":"Bei Gruppierung dürfen in `SELECT` nur stehen:\n\n- Spalten, die in `GROUP BY` stehen\n- Aggregatfunktionen wie `COUNT(*)`, `SUM(total)`, `AVG(price)`\n\nFalsch:\n\n```sql\nSELECT country, first_name, COUNT(*)\nFROM customer\nGROUP BY country;\n```\n\n`first_name` ist weder gruppiert noch aggregiert.","tags":["dql","aggregation","pruefungsfalle"],"source":"Zusammenfassung §6.6; SQL Teil 2 S. 69","external_id":"db-praktisch-037"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Unterabfragen\nWelche Typen von Unterabfragen sind wichtig?","answer":"- **Skalare Unterabfrage:** liefert einen einzelnen Wert.\n- **Mengen-Unterabfrage:** liefert mehrere Werte, oft mit `IN`.\n- **Korrelierte Unterabfrage:** hängt von der äußeren Abfrage ab und wird logisch je äußerer Zeile ausgewertet.\n\nBeispiel:\n\n```sql\nWHERE customer_id IN (SELECT customer_id FROM invoice)\n```","tags":["dql","subquery"],"source":"Zusammenfassung §6.7; SQL Teil 2","external_id":"db-praktisch-038"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Korrelierte Unterabfrage\nWas ist das?","answer":"Eine korrelierte Unterabfrage verwendet Werte der äußeren Abfrage.\n\n```sql\nSELECT p1.name\nFROM person p1\nWHERE EXISTS (\n  SELECT 1\n  FROM person p2\n  WHERE p2.last_name = p1.last_name\n    AND p2.salary > p1.salary\n);\n```\n\nSie ist logisch abhängig von jeder Zeile der äußeren Abfrage.","tags":["dql","subquery"],"source":"Zusammenfassung §6.7; SQL Teil 2 S. 36","external_id":"db-praktisch-039"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# IN vs EXISTS\nWann passt was?","answer":"- `IN` prüft, ob ein Wert in einer Ergebnisliste vorkommt.\n- `EXISTS` prüft, ob eine passende Zeile existiert.\n\n```sql\nWHERE EXISTS (\n  SELECT 1 FROM invoice i\n  WHERE i.customer_id = c.customer_id\n)\n```\n\nBei korrelierten Existenzprüfungen ist `EXISTS` oft ausdrucksstärker.","tags":["dql","subquery"],"source":"Zusammenfassung §6.7","external_id":"db-praktisch-040"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# INNER JOIN\nWas liefert ein `INNER JOIN`?","answer":"Ein `INNER JOIN` liefert nur Zeilen, für die die Join-Bedingung auf beiden Seiten passt.\n\n```sql\nSELECT a.title, ar.name\nFROM album a\nJOIN artist ar ON ar.artist_id = a.artist_id;\n```\n\nAlben ohne passenden Künstler und Künstler ohne Album erscheinen nicht.","tags":["dql","join"],"source":"Zusammenfassung §6.8; SQL Teil 2 S. 69","external_id":"db-praktisch-041"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# OUTER JOIN\nWie unterscheiden sich `LEFT`, `RIGHT` und `FULL OUTER JOIN`?","answer":"- `LEFT JOIN`: alle Zeilen links, passende rechts; fehlende rechte Werte werden `NULL`.\n- `RIGHT JOIN`: alle Zeilen rechts, passende links.\n- `FULL OUTER JOIN`: alle Zeilen beider Seiten, fehlende Partner als `NULL`.\n\nBei „auch wenn kein Partner existiert“ ist meist ein Outer Join nötig.","tags":["dql","join"],"source":"Zusammenfassung §6.8; SQL Teil 2 S. 69","external_id":"db-praktisch-042"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Kartesisches Produkt\nWann entsteht es in SQL?","answer":"Ein kartesisches Produkt entsteht, wenn Tabellen ohne passende Join-Bedingung kombiniert werden:\n\n```sql\nSELECT *\nFROM customer, invoice;\n```\n\nJede Zeile von `customer` wird mit jeder Zeile von `invoice` kombiniert. Bei Joins immer `ON` prüfen.","tags":["dql","join","pruefungsfalle"],"source":"Zusammenfassung §6.8; SQL Teil 2 S. 69","external_id":"db-praktisch-043"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SELF JOIN\nWas ist ein Self Join?","answer":"Ein Self Join verknüpft eine Tabelle mit sich selbst, meist über Aliase.\n\n```sql\nSELECT e.name AS employee, m.name AS manager\nFROM employee e\nLEFT JOIN employee m ON m.employee_id = e.manager_id;\n```\n\nTypisch für Hierarchien, z. B. Mitarbeiter und Vorgesetzte.","tags":["dql","join"],"source":"Zusammenfassung §6.8; SQL Teil 2 S. 69","external_id":"db-praktisch-044"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# JOINs vs Mengenoperationen\nWie unterscheiden sie sich?","answer":"- **JOINs** kombinieren Tabellen horizontal: Spalten werden nebeneinandergeführt.\n- **Mengenoperationen** kombinieren Ergebnisse vertikal: Zeilen werden untereinandergeführt.\n\nMengenoperationen: `UNION`, `INTERSECT`, `EXCEPT`.\n\nBedingung: gleiche Spaltenanzahl und kompatible Typen an denselben Positionen.","tags":["dql","mengenoperationen"],"source":"Zusammenfassung §6.9; SQL Teil 2 S. 69","external_id":"db-praktisch-045"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# UNION vs UNION ALL\nWas ist der Unterschied?","answer":"- `UNION` entfernt Duplikate.\n- `UNION ALL` behält Duplikate.\n\nWenn Mehrfachvorkommen fachlich relevant sind, nicht versehentlich `UNION` verwenden.","tags":["dql","mengenoperationen"],"source":"Zusammenfassung §6.9","external_id":"db-praktisch-046"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Views\nWas ist eine View?","answer":"Eine View ist eine gespeicherte SQL-Abfrage, die wie eine virtuelle Tabelle genutzt wird.\n\n```sql\nCREATE VIEW german_customers AS\nSELECT customer_id, first_name, last_name\nFROM customer\nWHERE country = 'Germany';\n```\n\nNutzen: Vereinfachung, Zugriffsbeschränkung, stabile externe Sicht.","tags":["views","sql"],"source":"Zusammenfassung §7.1; SQL Teil 3","external_id":"db-praktisch-047"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Änderbare Views\nWann ist eine View typischerweise nicht änderbar?","answer":"Views sind oft nicht direkt änderbar, wenn sie enthalten:\n\n- Aggregationen\n- `GROUP BY`\n- `DISTINCT`\n- Joins mit Mehrdeutigkeiten\n- berechnete Spalten\n- Mengenoperationen\n\nEine View sieht wie eine Tabelle aus, ist aber nicht automatisch eine änderbare Tabelle.","tags":["views","pruefungsfalle"],"source":"Zusammenfassung §7.1","external_id":"db-praktisch-048"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Index\nWas macht ein Index?","answer":"Ein Index beschleunigt Such-, Sortier- und Join-Zugriffe auf Kosten von Speicher und Schreibaufwand.\n\n```sql\nCREATE INDEX idx_invoice_customer\nON invoice(customer_id);\n```\n\nIndexe ändern nicht die logische Ergebnismenge, sondern die Zugriffseffizienz.","tags":["index","performance"],"source":"Zusammenfassung §7.2; SQL Teil 3","external_id":"db-praktisch-049"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Index-Falle\nWarum nicht „auf jede Spalte“ einen Index setzen?","answer":"Jeder Index kostet:\n\n- Speicherplatz\n- Pflege bei `INSERT`, `UPDATE`, `DELETE`\n- Optimizer-Komplexität\n\nSinnvoll sind Indexe vor allem auf häufig gefilterten, gejointen oder sortierten Spalten mit geeigneter Selektivität.","tags":["index","performance","pruefungsfalle"],"source":"Zusammenfassung §7.2","external_id":"db-praktisch-050"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Rechteverwaltung\nWie funktionieren `GRANT` und `REVOKE`?","answer":"`GRANT` vergibt Rechte, `REVOKE` entzieht sie.\n\n```sql\nGRANT SELECT ON customer TO martin;\nREVOKE SELECT ON customer FROM martin;\n```\n\nAuch spaltenbezogene Rechte sind möglich:\n\n```sql\nGRANT SELECT (first_name, last_name) ON customer TO martin;\n```","tags":["rechte","sql"],"source":"Zusammenfassung §7.3; SQL Teil 3 S. 13","external_id":"db-praktisch-051"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# System Catalog vs Information Schema\nWas ist der Unterschied?","answer":"- `information_schema`: standardisierte Metadaten-Sichten, portabler zwischen SQL-Datenbanken.\n- PostgreSQL-Systemkataloge (`pg_*`): PostgreSQL-spezifisch, oft detaillierter.\n\nFür portable Metadatenabfragen zuerst an `information_schema` denken.","tags":["metadaten","postgresql"],"source":"Zusammenfassung §7.4; SQL Teil 3","external_id":"db-praktisch-052"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# DB-seitige Logik\nWarum verlagert man Logik in die Datenbank?","answer":"Vorteile:\n\n- Nähe zu Daten, weniger Netzwerkverkehr\n- zentrale Durchsetzung von Regeln\n- Wiederverwendung durch mehrere Anwendungen\n- Performance bei datenintensiven Operationen\n\nNachteile: DB-spezifische Syntax, schwierigere Tests/Versionierung, stärkere DB-Kopplung.","tags":["db-programmierung"],"source":"Zusammenfassung §8.1; Skript DB-seitig/Transaktionen","external_id":"db-praktisch-053"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SQL-Function\nWie sieht eine PostgreSQL-Function mit `LANGUAGE SQL` aus?","answer":"```sql\nCREATE OR REPLACE FUNCTION track_count()\nRETURNS INTEGER\nLANGUAGE SQL\nAS $$\n  SELECT COUNT(*) FROM track;\n$$;\n```\n\nBei `LANGUAGE SQL` ergibt sich der Rückgabewert aus der letzten SQL-Anweisung.","tags":["db-programmierung","function","postgresql"],"source":"Zusammenfassung §8.2; DB-seitig/Transaktionen","external_id":"db-praktisch-054"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# PL/pgSQL-Function\nWelche Grundstruktur hat sie?","answer":"```sql\nCREATE OR REPLACE FUNCTION get_total(p_invoice_id INTEGER)\nRETURNS NUMERIC\nLANGUAGE plpgsql\nAS $$\nDECLARE\n  v_total NUMERIC;\nBEGIN\n  SELECT total INTO v_total\n  FROM invoice\n  WHERE invoice_id = p_invoice_id;\n\n  RETURN v_total;\nEND;\n$$;\n```\n\nWichtig: `DECLARE`, `BEGIN ... END`, `SELECT ... INTO`, `RETURN`.","tags":["db-programmierung","function","postgresql"],"source":"Zusammenfassung §8.3; DB-seitig/Transaktionen","external_id":"db-praktisch-055"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SELECT INTO in PL/pgSQL\nWas macht `SELECT ... INTO variable`?","answer":"Es speichert ein Abfrageergebnis in eine PL/pgSQL-Variable.\n\n```sql\nSELECT COUNT(*) INTO v_count\nFROM invoice\nWHERE customer_id = p_customer_id;\n```\n\nPrüfungsfalle: In PL/pgSQL ist das eine Variablenzuweisung, nicht eine Tabellenerzeugung.","tags":["db-programmierung","function"],"source":"Zusammenfassung §8.3","external_id":"db-praktisch-056"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Function vs Procedure\nWie unterscheiden sie sich in PostgreSQL?","answer":"| Function | Procedure |\n|---|---|\n| liefert Wert oder `void` | kein klassischer Rückgabewert nötig |\n| kann in SQL-Ausdrücken genutzt werden | wird mit `CALL` aufgerufen |\n| keine Transaktionsbefehle in der Function | Procedures können Transaktionsbefehle enthalten, je nach Kontext |\n\nMerksatz: Function berechnet, Procedure führt Ablauf aus.","tags":["db-programmierung","procedure"],"source":"Zusammenfassung §8.4; DB-seitig/Transaktionen","external_id":"db-praktisch-057"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Procedure-Syntax\nWie wird eine Procedure erstellt und aufgerufen?","answer":"```sql\nCREATE OR REPLACE PROCEDURE raise_prices(p_factor NUMERIC)\nLANGUAGE plpgsql\nAS $$\nBEGIN\n  UPDATE track\n  SET unit_price = unit_price * p_factor;\nEND;\n$$;\n\nCALL raise_prices(1.10);\n```\n\nKlausurfalle: Eine Procedure wird per `CALL` aufgerufen, nicht per `SELECT`.","tags":["db-programmierung","procedure","postgresql"],"source":"Zusammenfassung §8.4","external_id":"db-praktisch-058"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Trigger\nWas ist ein Trigger?","answer":"Ein Trigger ist automatisch ausgeführte DB-Logik bei Ereignissen wie `INSERT`, `UPDATE` oder `DELETE`.\n\nTypische Einsatzfälle:\n\n- Default-/Validierungslogik\n- Audit-Tabellen\n- abgeleitete Werte\n- Integritätsregeln, die mit einfachen Constraints nicht gut ausdrückbar sind\n\nPostgreSQL benötigt dafür eine separate Trigger-Funktion.","tags":["db-programmierung","trigger"],"source":"Zusammenfassung §8.5; Übungsklausur Functions/Trigger","external_id":"db-praktisch-059"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# NEW, OLD, TG_OP\nWelche Trigger-Spezialvariablen sind wichtig?","answer":"In PostgreSQL-Triggerfunktionen:\n\n- `NEW`: neue Zeile bei `INSERT`/`UPDATE`\n- `OLD`: alte Zeile bei `UPDATE`/`DELETE`\n- `TG_OP`: Operation als Text, z. B. `INSERT`\n\n```sql\nIF NEW.name IS NULL THEN\n  NEW.name := 'Untitled Genre';\nEND IF;\n```","tags":["db-programmierung","trigger","postgresql"],"source":"Zusammenfassung §8.5; Übungsklausur","external_id":"db-praktisch-060"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# BEFORE vs AFTER Trigger\nWann nutzt man was?","answer":"- `BEFORE`: vor der Änderung; geeignet, um `NEW` zu prüfen oder zu verändern.\n- `AFTER`: nach erfolgreicher Änderung; geeignet für Logging, Audit, Folgeaktionen.\n- `FOR EACH ROW`: pro betroffener Zeile.\n- `FOR EACH STATEMENT`: einmal pro SQL-Anweisung.\n\nDefault setzen: meist `BEFORE INSERT FOR EACH ROW`.","tags":["db-programmierung","trigger"],"source":"Zusammenfassung §8.5","external_id":"db-praktisch-061"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Trigger-Beispiel\nWie setzt man per Trigger einen Default-Namen für neue Genres?","answer":"```sql\nCREATE OR REPLACE FUNCTION set_default_genre_name()\nRETURNS TRIGGER\nLANGUAGE plpgsql\nAS $$\nBEGIN\n  IF NEW.name IS NULL THEN\n    NEW.name := 'Untitled Genre';\n  END IF;\n  RETURN NEW;\nEND;\n$$;\n\nCREATE TRIGGER trg_genre_default_name\nBEFORE INSERT ON genre\nFOR EACH ROW\nEXECUTE FUNCTION set_default_genre_name();\n```\n\nWichtig: Trigger-Funktion und `CREATE TRIGGER` getrennt angeben.","tags":["db-programmierung","trigger","klausur"],"source":"Übungsklausur S. 4; Zusammenfassung §8.5","external_id":"db-praktisch-062"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# ACID\nWofür stehen die ACID-Eigenschaften?","answer":"- **Atomicity:** ganz oder gar nicht.\n- **Consistency:** gültiger DB-Zustand bleibt gültig.\n- **Isolation:** parallele Transaktionen stören sich nicht unzulässig.\n- **Durability:** bestätigte Änderungen bleiben nach Fehlern erhalten.\n\nKlausurpunkt: ACID-Konsistenz meint Integritätsregeln, nicht CAP-Einheitlichkeit.","tags":["transaktionen","acid"],"source":"Zusammenfassung §9.1; DB-seitig/Transaktionen","external_id":"db-praktisch-063"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Auto-Commit\nWas bedeutet Auto-Commit?","answer":"Bei Auto-Commit wird jede einzelne SQL-Anweisung automatisch als eigene Transaktion bestätigt.\n\nFür zusammengehörige Schritte:\n\n```sql\nBEGIN;\nUPDATE account SET balance = balance - 100 WHERE id = 1;\nUPDATE account SET balance = balance + 100 WHERE id = 2;\nCOMMIT;\n```\n\nBei Fehler: `ROLLBACK`.","tags":["transaktionen"],"source":"Zusammenfassung §9.1; DB-seitig/Transaktionen S. 72","external_id":"db-praktisch-064"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Nebenläufigkeitsanomalien\nWelche typischen Anomalien gibt es?","answer":"- **Dirty Read:** Lesen nicht bestätigter Daten.\n- **Non-Repeatable Read:** dieselbe Zeile liefert später andere Werte.\n- **Phantom Read:** dieselbe Bereichsabfrage liefert später zusätzliche/fehlende Zeilen.\n- **Lost Update:** parallele Änderungen überschreiben sich.\n\nIsolation Levels reduzieren diese Effekte unterschiedlich stark.","tags":["transaktionen","isolation"],"source":"Zusammenfassung §9.2; DB-seitig/Transaktionen","external_id":"db-praktisch-065"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Isolation Levels\nWelche Level sind klausurrelevant?","answer":"| Level | Idee |\n|---|---|\n| `READ UNCOMMITTED` | sehr schwach; in PostgreSQL wie Read Committed behandelt |\n| `READ COMMITTED` | nur bestätigte Daten lesen |\n| `REPEATABLE READ` | wiederholtes Lesen bleibt stabiler |\n| `SERIALIZABLE` | Ergebnis wie serielle Ausführung |\n\nTradeoff: höhere Isolation = weniger Anomalien, aber mehr Konfliktkosten.","tags":["transaktionen","isolation"],"source":"Zusammenfassung §9.3","external_id":"db-praktisch-066"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Locks\nWarum verwendet ein DBMS Locks?","answer":"Locks koordinieren parallele Zugriffe:\n\n- Schreibvorgänge sollen keine inkonsistenten Zustände erzeugen.\n- Leser und Schreiber werden je nach Isolation/Sperrtyp koordiniert.\n- Sperren können auf Zeilen, Tabellen oder anderen Objekten liegen.\n\nMehr Sperren erhöhen Korrektheit, können aber Wartezeiten und Deadlocks verursachen.","tags":["transaktionen","locks"],"source":"Zusammenfassung §9.4","external_id":"db-praktisch-067"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Deadlock\nWas ist ein Deadlock?","answer":"Ein Deadlock entsteht, wenn Transaktionen zyklisch aufeinander warten.\n\n- T1 hält Lock auf A und wartet auf B.\n- T2 hält Lock auf B und wartet auf A.\n\nDBMS erkennen Deadlocks typischerweise und brechen eine Transaktion ab. Anwendungen müssen ggf. wiederholen.","tags":["transaktionen","locks"],"source":"Zusammenfassung §9.4","external_id":"db-praktisch-068"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Two-Phase Locking vs Two-Phase Commit\nWas ist der Unterschied?","answer":"- **2PL (Two-Phase Locking):** Sperrprotokoll für Isolation/Serialisierbarkeit mit Wachstums- und Schrumpfphase.\n- **2PC (Two-Phase Commit):** Protokoll für verteiltes Commit mit Prepare/Vote und Commit/Abort.\n\nNicht verwechseln: 2PL regelt Sperren, 2PC regelt verteilte Transaktionsentscheidung.","tags":["transaktionen","verteilte-db"],"source":"Zusammenfassung §9.5; Erweiterungen/verteilte DB","external_id":"db-praktisch-069"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# JDBC-Treibertypen\nWelche Treibertypen gibt es grob?","answer":"Klassische Einteilung:\n\n1. Typ 1: JDBC-ODBC-Bridge\n2. Typ 2: Native-API-Treiber\n3. Typ 3: Middleware/Netzwerktreiber\n4. Typ 4: Pure Java, direktes DB-Protokoll\n\nPraktisch heute wichtig: Typ-4-Treiber, z. B. PostgreSQL JDBC Driver.","tags":["jdbc"],"source":"Zusammenfassung §10.1; Skript JDBC/JPA","external_id":"db-praktisch-070"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# JDBC-Ablauf\nWie sieht der typische Ablauf für eine `SELECT`-Abfrage aus?","answer":"1. `Connection` bereitstellen.\n2. `PreparedStatement` oder `Statement` erzeugen.\n3. SQL mit `executeQuery()` ausführen.\n4. `ResultSet` zeilenweise lesen.\n5. Ressourcen schließen, ideal mit `try-with-resources`.\n\n```java\ntry (Connection con = dataSource.getConnection();\n     PreparedStatement ps = con.prepareStatement(sql);\n     ResultSet rs = ps.executeQuery()) {\n  while (rs.next()) { /* Werte lesen */ }\n}\n```","tags":["jdbc","java"],"source":"Zusammenfassung §10.1; Übungsklausur JDBC","external_id":"db-praktisch-071"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# executeQuery, executeUpdate, execute\nWann nutzt man welche Methode?","answer":"- `executeQuery()`: für `SELECT`, liefert `ResultSet`.\n- `executeUpdate()`: für `INSERT`, `UPDATE`, `DELETE`, DDL; liefert Anzahl betroffener Zeilen bzw. Status.\n- `execute()`: allgemein, wenn Ergebnisart nicht vorher klar ist.\n\nKlausurfalle: `SELECT` nicht mit `executeUpdate()` lösen.","tags":["jdbc","java"],"source":"Zusammenfassung §10.1","external_id":"db-praktisch-072"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# ResultSet\nWie funktioniert ein `ResultSet`?","answer":"Ein `ResultSet` ist ein Cursor über Ergebniszeilen.\n\n```java\nwhile (rs.next()) {\n  int id = rs.getInt(\"customer_id\");\n  String name = rs.getString(\"last_name\");\n}\n```\n\n`rs.next()` bewegt den Cursor zur nächsten Zeile und liefert `false`, wenn keine Zeile mehr existiert.","tags":["jdbc","java"],"source":"Zusammenfassung §10.1; Skript JDBC/JPA","external_id":"db-praktisch-073"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# JDBC-Ressourcen\nWarum ist Ressourcenfreigabe wichtig?","answer":"Connections, Statements und ResultSets belegen DB- und Netzwerkressourcen.\n\nEmpfohlen:\n\n```java\ntry (Connection con = ds.getConnection();\n     PreparedStatement ps = con.prepareStatement(sql);\n     ResultSet rs = ps.executeQuery()) {\n  // Verarbeitung\n}\n```\n\nDadurch werden Ressourcen auch bei Exceptions zuverlässig geschlossen.","tags":["jdbc","java","pruefungsfalle"],"source":"Übungsklausur S. 6; Zusammenfassung §10.1","external_id":"db-praktisch-074"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# JDBC-Transaktionen\nWie steuert man Transaktionen in JDBC?","answer":"```java\ncon.setAutoCommit(false);\ntry {\n  // mehrere SQL-Operationen\n  con.commit();\n} catch (SQLException ex) {\n  con.rollback();\n  throw ex;\n}\n```\n\nWichtig: Auto-Commit deaktivieren, bei Erfolg `commit`, bei Fehler `rollback`.","tags":["jdbc","transaktionen","java"],"source":"Zusammenfassung §10.2; Skript JDBC/JPA","external_id":"db-praktisch-075"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SQL Injection\nWas ist das?","answer":"SQL Injection entsteht, wenn Benutzereingaben ungeprüft in SQL-Strings verkettet werden.\n\nRiskant:\n\n```java\nString sql = \"SELECT * FROM user WHERE name = '\" + input + \"'\";\n```\n\nEin Angreifer kann SQL-Logik einschleusen, z. B. über `' OR '1'='1`.","tags":["jdbc","security","pruefungsfalle"],"source":"Zusammenfassung §10.3","external_id":"db-praktisch-076"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# PreparedStatement\nWarum verhindert es SQL Injection?","answer":"Parameter werden getrennt vom SQL-Code übertragen:\n\n```java\nPreparedStatement ps = con.prepareStatement(\n  \"SELECT * FROM customer WHERE email = ?\"\n);\nps.setString(1, email);\nResultSet rs = ps.executeQuery();\n```\n\nDie Eingabe wird als Wert behandelt, nicht als ausführbarer SQL-Code.","tags":["jdbc","security"],"source":"Zusammenfassung §10.3; Skript JDBC/JPA","external_id":"db-praktisch-077"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# REST und 3-Schichten\nWie passt REST in die Architektur?","answer":"Typische Schichten:\n\n1. **Präsentation:** UI/Client.\n2. **Anwendungs-/Service-Schicht:** REST-API, Geschäftslogik, Validierung.\n3. **Datenhaltung:** DBMS, SQL, JPA/JDBC.\n\nREST stellt Ressourcen über HTTP bereit. Die Datenbank bleibt hinter der Service-Schicht gekapselt.","tags":["architektur","rest"],"source":"Zusammenfassung §10.4; Skript JDBC/JPA","external_id":"db-praktisch-078"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# ORM, JPA, Hibernate\nWie hängen sie zusammen?","answer":"- **ORM:** Prinzip, Objekte auf relationale Tabellen abzubilden.\n- **JPA:** Java-Spezifikation für Persistenz/ORM.\n- **Hibernate:** konkrete JPA-Implementierung.\n\nMerksatz: JPA ist die Spezifikation, Hibernate eine Implementierung.","tags":["jpa","orm"],"source":"Zusammenfassung §10.5; Skript JDBC/JPA","external_id":"db-praktisch-079"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Object-Relational Impedance Mismatch\nWas bedeutet das?","answer":"Objektmodell und relationales Modell passen nicht perfekt zusammen:\n\n- Objekte haben Identität, Referenzen, Vererbung, Collections.\n- Relationale DBs arbeiten mit Tabellen, Schlüsseln, Mengen und Joins.\n- Beziehungen müssen zwischen Objektgraphen und Fremdschlüsseln übersetzt werden.\n\nORM reduziert den Aufwand, beseitigt den Grundkonflikt aber nicht vollständig.","tags":["jpa","orm"],"source":"Zusammenfassung §10.5","external_id":"db-praktisch-080"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# EntityManager\nWelche Aufgaben hat der JPA `EntityManager`?","answer":"Der `EntityManager` verwaltet Entitäten und Persistenzkontext:\n\n- `persist(entity)`: neue Entität persistent machen\n- `find(Entity.class, id)`: Entität laden\n- `merge(entity)`: detached Änderungen zusammenführen\n- `remove(entity)`: Entität löschen\n- Queries/JPQL ausführen\n\nEr ist die zentrale API zwischen Java-Objekten und Datenbank.","tags":["jpa","java"],"source":"Zusammenfassung §10.5; Skript JDBC/JPA","external_id":"db-praktisch-081"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# JPA-Lebenszyklus\nWelche Zustände hat eine Entity?","answer":"Wichtige Zustände:\n\n- **new/transient:** Objekt existiert nur im Speicher.\n- **managed/persistent:** EntityManager verwaltet das Objekt; Änderungen werden synchronisiert.\n- **detached:** Objekt nicht mehr im Persistenzkontext.\n- **removed:** zum Löschen markiert.\n\nKlausurfalle: Nur managed Entities werden automatisch per Dirty Checking berücksichtigt.","tags":["jpa","orm"],"source":"Zusammenfassung §10.5","external_id":"db-praktisch-082"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# JPQL vs SQL\nWie unterscheidet sich JPQL von SQL?","answer":"- SQL fragt Tabellen und Spalten ab.\n- JPQL fragt Entities und deren Attribute ab.\n\nBeispiel:\n\n```java\nSELECT c FROM Customer c WHERE c.country = :country\n```\n\n`Customer` ist eine Entity, nicht zwingend der Tabellenname.","tags":["jpa","sql"],"source":"Zusammenfassung §10.5","external_id":"db-praktisch-083"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# OLTP vs OLAP\nWie unterscheiden sie sich?","answer":"| OLTP | OLAP |\n|---|---|\n| Tagesgeschäft | Analyse/Entscheidung |\n| viele kurze Transaktionen | wenige komplexe Abfragen |\n| schreib- und änderungsnah | lese- und aggregationsnah |\n| aktuelle operative Daten | historische/verdichtete Daten |\n\nBestellung buchen = OLTP, Umsatztrend analysieren = OLAP.","tags":["rdbms-erweiterungen","olap"],"source":"Zusammenfassung §11.1; Erweiterungen/verteilte DB S. 46","external_id":"db-praktisch-084"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# ORDBMS\nWas ist ein objektrelationales DBMS?","answer":"Ein ORDBMS erweitert relationale Datenbanken um objektnahe Konzepte:\n\n- komplexe Datentypen\n- benutzerdefinierte Typen/Funktionen\n- Vererbung oder strukturierte Werte\n- JSON/Array-Unterstützung je nach System\n\nPostgreSQL besitzt viele objektrelationale Erweiterungen.","tags":["rdbms-erweiterungen","postgresql"],"source":"Zusammenfassung §11.2; Erweiterungen/verteilte DB","external_id":"db-praktisch-085"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SAP HANA und Code-to-Data\nWas bedeutet Code-to-Data?","answer":"**Data-to-Code:** Daten werden zur Anwendung übertragen, dort verarbeitet.\n\n**Code-to-Data:** Berechnungslogik wird nah an die Datenbank verlagert.\n\nVorteil bei HANA/In-Memory/Column Store: große Datenmengen können direkt in der DB gescannt und aggregiert werden; weniger Netzwerk- und Applikationsserverlast.","tags":["rdbms-erweiterungen","hana"],"source":"Zusammenfassung §11.2; Erweiterungen/verteilte DB S. 24, 46","external_id":"db-praktisch-086"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Verteilte Datenbank\nWas ist das?","answer":"Eine verteilte Datenbank ist logisch eine zusammengehörige Datenbank, deren Daten physisch auf mehrere über ein Netzwerk verbundene Rechner verteilt sind.\n\nWichtige Konzepte:\n\n- Fragmentierung: horizontal oder vertikal\n- Replikation: Kopien auf mehreren Knoten\n- verteilte Transaktionen\n- Konsistenz- und Verfügbarkeitsprobleme","tags":["verteilte-db"],"source":"Zusammenfassung §11.3; Erweiterungen/verteilte DB S. 46","external_id":"db-praktisch-087"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Horizontale vs vertikale Fragmentierung\nWie unterscheiden sie sich?","answer":"- **Horizontal:** Tabelle wird nach Zeilen aufgeteilt, z. B. Kunden nach Region.\n- **Vertikal:** Tabelle wird nach Spalten aufgeteilt; der Primärschlüssel muss in Fragmenten erhalten bleiben.\n\nBeispiel horizontal: `customer_eu`, `customer_us`.\nBeispiel vertikal: `customer_contact`, `customer_billing`.","tags":["verteilte-db"],"source":"Erweiterungen/verteilte DB S. 46; Zusammenfassung §11.3","external_id":"db-praktisch-088"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# CAP-Theorem\nWofür stehen C, A und P?","answer":"- **Consistency:** alle Knoten sehen denselben aktuellen Datenstand.\n- **Availability:** jede Anfrage erhält eine Antwort.\n- **Partition Tolerance:** System arbeitet trotz Netzwerkpartition weiter.\n\nBei einer Netzwerkpartition muss ein verteiltes System zwischen strikter Konsistenz und Verfügbarkeit abwägen.","tags":["verteilte-db","cap"],"source":"Zusammenfassung §11.4; Erweiterungen/verteilte DB S. 46","external_id":"db-praktisch-089"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# CAP-Tradeoff\nWarum kann man bei Partition nicht gleichzeitig strikte C und A garantieren?","answer":"Bei Netzwerktrennung können Knoten nicht sicher synchronisieren.\n\n- Wählt man **Consistency**, müssen unsichere Anfragen abgelehnt oder blockiert werden.\n- Wählt man **Availability**, antworten Knoten weiter, riskieren aber veraltete/abweichende Daten.\n\nPartition Tolerance ist in verteilten Systemen praktisch unvermeidbar.","tags":["verteilte-db","cap"],"source":"Zusammenfassung §11.4; Erweiterungen/verteilte DB S. 46","external_id":"db-praktisch-090"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# ACID-Konsistenz vs CAP-Konsistenz\nWarum meint Konsistenz nicht dasselbe?","answer":"- **ACID Consistency:** Eine Transaktion erhält Integritätsregeln der Datenbank. Gültiger Zustand -> gültiger Zustand.\n- **CAP Consistency:** Alle Knoten liefern denselben aktuellen Wert, also Einheitlichkeit der Replikate.\n\nPrüfungsfalle: Nicht beide Begriffe vermischen.","tags":["transaktionen","cap","pruefungsfalle"],"source":"Zusammenfassung §11.4; Erweiterungen/verteilte DB S. 46","external_id":"db-praktisch-091"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# BASE\nWofür steht BASE und wie grenzt es sich von ACID ab?","answer":"BASE steht für:\n\n- **Basically Available**\n- **Soft State**\n- **Eventual Consistency**\n\nBASE akzeptiert vorübergehend inkonsistente Zustände zugunsten von Verfügbarkeit und Skalierbarkeit. ACID zielt auf strikte Transaktionssicherheit.","tags":["nosql","cap","base"],"source":"Zusammenfassung §11.4; NoSQL S. 122","external_id":"db-praktisch-092"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Eventual Consistency\nWas bedeutet das?","answer":"Nach einem Schreibvorgang sehen nicht sofort alle Knoten denselben Wert. Wenn keine weiteren Änderungen passieren, konvergieren die Replikate irgendwann zu demselben Zustand.\n\nKlausurformulierung: **vorübergehend inkonsistent, langfristig konsistent**.","tags":["nosql","base","verteilte-db"],"source":"Zusammenfassung §11.4; Erweiterungen/verteilte DB S. 46","external_id":"db-praktisch-093"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# NoSQL-Grundidee\nWarum ist „nicht-relational“ oft präziser als „NoSQL“?","answer":"Viele NoSQL-Systeme besitzen SQL-ähnliche Sprachen, z. B. Cassandra CQL. Das Hauptmerkmal ist daher nicht zwingend „kein SQL“, sondern:\n\n- anderes Datenmodell\n- flexible Schemata\n- horizontale Skalierung\n- Replikation/Partitionierung\n- oft BASE/Eventual Consistency\n\nKategorien: Key-Value, Dokument, Wide-Column, Graph.","tags":["nosql"],"source":"Zusammenfassung §12.1; NoSQL S. 122","external_id":"db-praktisch-094"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Drei Vs\nWelche Big-Data-Treiber führen häufig zu NoSQL?","answer":"Die drei klassischen Vs:\n\n- **Volume:** große Datenmengen\n- **Variety:** vielfältige/heterogene Strukturen\n- **Velocity:** hohe Geschwindigkeit bei Erzeugung/Verarbeitung\n\nNoSQL-Systeme adressieren diese Anforderungen oft durch horizontale Skalierung und flexiblere Datenmodelle.","tags":["nosql","big-data"],"source":"Zusammenfassung §12.1; NoSQL S. 122","external_id":"db-praktisch-095"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# NoSQL-Kategorien\nWelche Hauptkategorien gibt es?","answer":"1. **Key-Value Stores:** Schlüssel -> Wert, z. B. Redis.\n2. **Dokumentendatenbanken:** Dokumente, z. B. MongoDB.\n3. **Wide-Column Stores:** Column Families, z. B. Cassandra.\n4. **Graphdatenbanken:** Knoten und Kanten, z. B. Neo4j.\n\nMerksatz: Datenmodell nach Zugriffsmuster wählen.","tags":["nosql"],"source":"Zusammenfassung §12.1; NoSQL S. 2","external_id":"db-praktisch-096"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Redis\nWas ist das Grundmodell?","answer":"Redis ist ein Key-Value Store. Daten werden über Schlüssel adressiert, Werte können verschiedene Strukturen haben:\n\n- Strings\n- Hashes\n- Lists\n- Sets\n- Sorted Sets\n\nTypisch: Cache, Sessions, Zähler, Queues.","tags":["nosql","redis"],"source":"Zusammenfassung §12.2; NoSQL S. 122","external_id":"db-praktisch-097"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Redis-Persistenz\nWie kann Redis trotz RAM-Nutzung persistent sein?","answer":"Redis ist sehr schnell durch In-Memory-Verarbeitung, kann aber auf Platte sichern:\n\n- **RDB Snapshots:** periodische Momentaufnahmen.\n- **AOF (Append Only File):** Änderungsoperationen fortlaufend in ein Journal schreiben.\n\nTradeoff: Performance, Wiederherstellbarkeit und Datenverlustfenster hängen von der Konfiguration ab.","tags":["nosql","redis"],"source":"NoSQL S. 122; Zusammenfassung §12.2","external_id":"db-praktisch-098"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# MongoDB Mapping\nWie mappt MongoDB relationale Begriffe?","answer":"| Relational | MongoDB |\n|---|---|\n| Tabelle | Collection |\n| Zeile/Tupel | Document |\n| Spalte | Field |\n| Primärschlüssel | `_id` |\n\nDokumente sind meist BSON: Binary JSON, effizienter und mit zusätzlichen Datentypen wie Date.","tags":["nosql","mongodb"],"source":"Zusammenfassung §12.3; NoSQL S. 122","external_id":"db-praktisch-099"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# MongoDB ObjectId\nWelche Rolle hat `_id`?","answer":"Jedes MongoDB-Dokument braucht ein eindeutiges `_id`-Feld.\n\nWenn kein `_id` gesetzt wird, erzeugt MongoDB typischerweise automatisch eine `ObjectId`.\n\n`_id` entspricht funktional dem eindeutigen Dokument-Identifier, ähnlich einem Primärschlüssel.","tags":["nosql","mongodb"],"source":"Zusammenfassung §12.3; NoSQL S. 122","external_id":"db-praktisch-100"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Dokumentenmodell\nWann passt eine Dokumentendatenbank gut?","answer":"Dokumentendatenbanken passen gut, wenn:\n\n- Daten objekt-/dokumentartig zusammen gelesen werden\n- Strukturen variieren dürfen\n- eingebettete Teilobjekte sinnvoll sind\n- horizontale Skalierung wichtiger ist als komplexe Joins\n\nPrüfungsfalle: Flexible Schemata ersetzen kein gutes Zugriffsmuster-Design.","tags":["nosql","mongodb"],"source":"Zusammenfassung §12.3","external_id":"db-praktisch-101"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Cassandra-Datenmodell\nWie lässt sich das Wide-Column-Modell kompakt darstellen?","answer":"Kompakte Formel:\n\n$$(RowKey, ColumnFamily, Column, Timestamp) \\to Value$$\n\nCassandra speichert Daten in Tabellen/Column Families mit dynamischen Spalten. Der Partition Key bestimmt die Datenverteilung über Knoten.","tags":["nosql","cassandra"],"source":"Zusammenfassung §12.4","external_id":"db-praktisch-102"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Cassandra Query First\nWas bedeutet Query-First-Modellierung?","answer":"Cassandra-Tabellen werden nach den benötigten Abfragen entworfen, nicht nach Normalformen.\n\nGrund: Cassandra unterstützt keine freien Joins/Subqueries wie relationale Systeme.\n\nKonsequenz:\n\n- Denormalisierung ist normal.\n- „One query per table“ ist ein typisches Designprinzip.\n- Datenmodellierung beginnt bei Zugriffsmustern.","tags":["nosql","cassandra"],"source":"NoSQL S. 62, 122; Zusammenfassung §12.4","external_id":"db-praktisch-103"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Cassandra vs RDBMS\nWas sind zentrale Unterschiede?","answer":"| RDBMS | Cassandra |\n|---|---|\n| Normalisierung | Denormalisierung nach Query |\n| Joins/Subqueries | stark eingeschränkt/nicht vorgesehen |\n| referentielle Integrität | keine klassische FK-Integrität |\n| oft vertikal + relational | stark horizontal skaliert |\n| SQL | CQL mit SQL-ähnlicher Syntax |\n\nCQL sieht SQL-ähnlich aus, bedeutet aber nicht relationale Abfragefreiheit.","tags":["nosql","cassandra","pruefungsfalle"],"source":"NoSQL S. 62; Zusammenfassung §12.4","external_id":"db-praktisch-104"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Cassandra UPSERT\nWas bedeutet UPSERT?","answer":"Schreiboperationen werden als Upsert behandelt:\n\n- Existiert der Key bereits, wird der Wert überschrieben/ergänzt.\n- Existiert er nicht, wird ein neuer Eintrag angelegt.\n\nDas ist für hohen Schreibdurchsatz optimiert, verlangt aber sauberes Datenmodell und Konfliktverständnis.","tags":["nosql","cassandra"],"source":"NoSQL S. 122; Zusammenfassung §12.4","external_id":"db-praktisch-105"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Neo4j Graphmodell\nWelche Grundelemente gibt es?","answer":"Neo4j modelliert Daten als Graph:\n\n- **Nodes:** Entitäten, z. B. Person, Ort\n- **Relationships:** gerichtete Beziehungen zwischen Nodes\n- **Labels:** Typisierung von Nodes\n- **Properties:** Attribute auf Nodes und Relationships\n\nStark, wenn Beziehungen wichtiger sind als einzelne Datensätze.","tags":["nosql","neo4j"],"source":"Zusammenfassung §12.5; NoSQL S. 122","external_id":"db-praktisch-106"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Cypher\nWie sieht eine einfache Cypher-Abfrage aus?","answer":"```cypher\nMATCH (p:Person)-[:FRIEND_OF]->(f:Person)\nWHERE p.name = 'Mia'\nRETURN f.name;\n```\n\nCypher beschreibt Muster im Graphen. Beziehungen sind im Graphmodell explizit gespeichert und werden nicht erst wie relationale Joins rekonstruiert.","tags":["nosql","neo4j"],"source":"Zusammenfassung §12.5","external_id":"db-praktisch-107"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Neo4j und ACID\nWelche Besonderheit hat Neo4j?","answer":"Neo4j ist eine Graphdatenbank und gilt im Kurs als eine der NoSQL-Datenbanken mit vollständiger ACID-Konformität.\n\nPrüfungsfalle: NoSQL bedeutet nicht automatisch „keine Transaktionen“ oder „nie ACID“. Die Eigenschaften sind systemabhängig.","tags":["nosql","neo4j","acid"],"source":"Zusammenfassung §12.5","external_id":"db-praktisch-108"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Polystores\nWas ist ein Polystore-Ansatz?","answer":"Ein Polystore nutzt mehrere spezialisierte Datenbanksysteme gemeinsam:\n\n- relationale DB für Transaktionen\n- Graphdatenbank für Beziehungen\n- Dokumentenstore für flexible Dokumente\n- Key-Value Store für Cache/Sessions\n\nIdee: Best-of-Breed statt ein einziges System für alle Anforderungen.","tags":["nosql","architektur"],"source":"Zusammenfassung §12.6; NoSQL S. 122","external_id":"db-praktisch-109"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# NoSQL-Einsatzszenarien\nWie wählt man einen passenden NoSQL-Typ?","answer":"- **Redis/Key-Value:** Cache, Session, schnelle Lookups.\n- **MongoDB/Dokument:** flexible, dokumentartige Aggregate.\n- **Cassandra/Wide-Column:** sehr große, verteilte Schreiblast, Query-first.\n- **Neo4j/Graph:** stark vernetzte Daten, Pfade, Beziehungen.\n\nImmer vom Zugriffsmuster argumentieren, nicht nur vom Produktnamen.","tags":["nosql","pruefung"],"source":"Zusammenfassung §12.6","external_id":"db-praktisch-110"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Historische nicht-relationale DBs\nWie unterscheiden sich hierarchische und Netzwerkdatenbanken?","answer":"- **Hierarchische Datenbanken:** baumartige 1:n-Strukturen; Zugriff entlang der Hierarchie.\n- **Netzwerkdatenbanken:** komplexere n:m-Beziehungen über Owner-Member-Sets.\n\nBeide sind stärker navigierend/programmiert als relationale SQL-Systeme.","tags":["nosql","historisch"],"source":"Zusammenfassung §12.7; NoSQL S. 2","external_id":"db-praktisch-111"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# DDL-Klausuraufgabe\nWie gehst du bei gegebenem Relationenschema vor?","answer":"Checkliste:\n\n1. Tabellenname und Attribute übernehmen.\n2. Datentypen sinnvoll wählen.\n3. `PRIMARY KEY` setzen.\n4. Pflichtfelder mit `NOT NULL` markieren.\n5. `UNIQUE`/`CHECK` ergänzen, falls fachlich gegeben.\n6. `FOREIGN KEY ... REFERENCES ...` mit Referenzaktionen ergänzen.\n7. Syntax auf Kommas und Klammern prüfen.","tags":["klausur","ddl"],"source":"Übungsklausur S. 1; Zusammenfassung §13.1","external_id":"db-praktisch-112"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SQL-Ergebnis von Hand\nWie ermittelst du eine SQL-Ergebnistabelle?","answer":"Vorgehen nach logischer Reihenfolge:\n\n1. `FROM`/`JOIN`: Ausgangstabelle bilden.\n2. `WHERE`: Zeilen streichen.\n3. `GROUP BY`: Gruppen bilden.\n4. Aggregate berechnen.\n5. `HAVING`: Gruppen filtern.\n6. `SELECT`: Spalten/Expressions auswählen.\n7. `ORDER BY`, `LIMIT`, `OFFSET` anwenden.\n\nNicht in Schreibreihenfolge denken.","tags":["klausur","dql"],"source":"Übungsklausur S. 2; Zusammenfassung §13.1","external_id":"db-praktisch-113"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Function-/Trigger-Aufgabe\nWas darf bei PostgreSQL-Trigger-Aufgaben nicht fehlen?","answer":"Immer zwei Teile liefern:\n\n1. Trigger-Funktion:\n\n```sql\nCREATE OR REPLACE FUNCTION ...\nRETURNS TRIGGER\nLANGUAGE plpgsql\nAS $$ ... $$;\n```\n\n2. Trigger-Registrierung:\n\n```sql\nCREATE TRIGGER ...\nBEFORE INSERT ON ...\nFOR EACH ROW\nEXECUTE FUNCTION ...();\n```\n\nNur die Funktion zu schreiben reicht nicht.","tags":["klausur","trigger"],"source":"Übungsklausur S. 3-4; Zusammenfassung §13.1","external_id":"db-praktisch-114"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# JDBC-Klausuraufgabe\nWelche Bausteine werden typischerweise geprüft?","answer":"Häufige Lücken:\n\n- `Connection` erzeugen/verwenden\n- `Statement` oder besser `PreparedStatement`\n- passende `execute...`-Methode\n- `ResultSet` mit `while (rs.next())`\n- Parameter setzen\n- `commit`/`rollback` bei Transaktionen\n- Ressourcen schließen\n\nPrüfungsfalle: SQL Injection durch String-Verkettung vermeiden.","tags":["klausur","jdbc"],"source":"Übungsklausur S. 6; Zusammenfassung §13.1","external_id":"db-praktisch-115"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Häufige SQL-Fehler\nWelche Fehler kosten schnell Punkte?","answer":"- fehlendes `WHERE` bei `UPDATE`/`DELETE`\n- falsche oder fehlende `JOIN ... ON`-Bedingung\n- `= NULL` statt `IS NULL`\n- `WHERE` und `HAVING` verwechselt\n- nicht gruppierte Spalten in `SELECT`\n- `COUNT(spalte)` statt `COUNT(*)` falsch interpretiert\n- `UNION` verwendet, obwohl Duplikate relevant sind","tags":["pruefungsfalle","sql"],"source":"Zusammenfassung §13.3","external_id":"db-praktisch-116"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Häufige Architektur-Fehler\nWelche konzeptionellen Verwechslungen sind typisch?","answer":"- ACID-Konsistenz mit CAP-Konsistenz verwechseln.\n- 2PL mit 2PC verwechseln.\n- JPA als Implementierung statt Spezifikation beschreiben.\n- Hibernate als Spezifikation statt Implementierung beschreiben.\n- NoSQL als „keine SQL-Sprache“ definieren.\n- DBeaver-Relationenschema als echtes ER-Modell behandeln.","tags":["pruefungsfalle","architektur"],"source":"Zusammenfassung §13.3","external_id":"db-praktisch-117"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SQL-Muster: Länder mehrfach\nWelche Abfrage findet Länder, die mehr als einmal vorkommen?","answer":"```sql\nSELECT country, COUNT(*) AS count\nFROM customer\nGROUP BY country\nHAVING COUNT(*) > 1;\n```\n\nWarum `HAVING`? Die Bedingung bezieht sich auf die Gruppe nach `GROUP BY`, nicht auf einzelne Zeilen.","tags":["klausur","dql","aggregation"],"source":"Übungsklausur S. 2; Zusammenfassung §6.6","external_id":"db-praktisch-118"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SQL-Muster: Alben eines Künstlers\nWie fragst du Alben eines bestimmten Künstlers ab?","answer":"```sql\nSELECT a.title\nFROM album a\nJOIN artist ar ON ar.artist_id = a.artist_id\nWHERE ar.name = 'AC/DC';\n```\n\nJoin-Bedingung verbindet Fremdschlüssel `album.artist_id` mit Primärschlüssel `artist.artist_id`; Filter auf Künstlernamen gehört in `WHERE`.","tags":["klausur","dql","join"],"source":"Zusammenfassung §13.2; mögliche Klausurfragen","external_id":"db-praktisch-119"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SQL-Muster: Duplikate finden\nWie findest du doppelte Werte in einer Spalte?","answer":"```sql\nSELECT email, COUNT(*) AS anzahl\nFROM customer\nGROUP BY email\nHAVING COUNT(*) > 1;\n```\n\nAllgemeines Muster: Gruppiere nach der zu prüfenden Spalte und filtere Gruppen mit Anzahl größer als 1.","tags":["dql","aggregation","klausur"],"source":"Zusammenfassung §6.6; Klausurtraining","external_id":"db-praktisch-120"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SQL-Muster: fehlende Partner\nWie findest du Datensätze ohne passenden Partner?","answer":"Typisches `LEFT JOIN ... IS NULL`-Muster:\n\n```sql\nSELECT c.customer_id\nFROM customer c\nLEFT JOIN invoice i ON i.customer_id = c.customer_id\nWHERE i.invoice_id IS NULL;\n```\n\nBedeutung: Alle Kunden, für die kein passender Rechnungsdatensatz existiert.","tags":["dql","join","klausur"],"source":"Zusammenfassung §6.8","external_id":"db-praktisch-121"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# SQL-Muster: sichere Änderung\nWie formulierst du eine sichere Preisänderung?","answer":"```sql\nUPDATE track\nSET unit_price = unit_price * 1.10\nWHERE genre_id = 1;\n```\n\nVorher sinnvoll prüfen:\n\n```sql\nSELECT COUNT(*)\nFROM track\nWHERE genre_id = 1;\n```\n\nDie `WHERE`-Bedingung ist Teil der fachlichen Lösung.","tags":["dml","klausur"],"source":"Zusammenfassung §5.2; §13.3","external_id":"db-praktisch-122"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# CHECK Constraint\nWie formulierst du eine einfache fachliche Wertebedingung?","answer":"```sql\nCREATE TABLE product (\n  product_id INTEGER PRIMARY KEY,\n  price NUMERIC(10, 2) NOT NULL,\n  CONSTRAINT chk_product_price CHECK (price >= 0)\n);\n```\n\n`CHECK` eignet sich für Regeln innerhalb einer Zeile, z. B. Preis nicht negativ.","tags":["ddl","constraints","klausur"],"source":"Zusammenfassung §4.4","external_id":"db-praktisch-123"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# DEFAULT\nWann ist `DEFAULT` sinnvoll?","answer":"`DEFAULT` setzt einen Standardwert, wenn beim `INSERT` kein Wert angegeben wird.\n\n```sql\nCREATE TABLE genre (\n  genre_id INTEGER PRIMARY KEY,\n  name VARCHAR(120) DEFAULT 'Untitled Genre'\n);\n```\n\nWenn die Regel komplexer ist oder vom Ereignis abhängt, kann ein Trigger passender sein.","tags":["ddl","constraints"],"source":"Zusammenfassung §4.4; Übungsklausur Trigger","external_id":"db-praktisch-124"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Normalisierung vs Cassandra\nWarum ist Normalisierung dort nicht immer das Ziel?","answer":"Relationale Modellierung vermeidet Redundanz und nutzt Joins. Cassandra optimiert auf verteilte, schnelle Abfragen ohne freie Joins.\n\nDeshalb wird bewusst denormalisiert:\n\n- Daten nach Abfrage speichern\n- Redundanz akzeptieren\n- Partition Key passend zum Zugriff wählen\n\nRDBMS-Normalformen nicht blind auf Cassandra übertragen.","tags":["nosql","cassandra","pruefungsfalle"],"source":"NoSQL S. 62; Zusammenfassung §12.4","external_id":"db-praktisch-125"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# RDBMS oder NoSQL?\nWann ist ein relationales DBMS meist besser?","answer":"Relational passt besonders gut bei:\n\n- klar strukturierten Daten\n- komplexen Ad-hoc-Abfragen\n- Joins über mehrere Entitäten\n- starken Transaktionen und Integritätsregeln\n- ausgereiftem SQL-Reporting\n\nNoSQL ist keine pauschale Verbesserung, sondern eine Architekturentscheidung.","tags":["nosql","rdbms","architektur"],"source":"Zusammenfassung §12.6","external_id":"db-praktisch-126"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Code-to-Data und DB-seitige Funktionen\nWie hängen sie zusammen?","answer":"Beide bringen Verarbeitung näher an die Daten.\n\n- DB-seitige Functions/Procedures/Trigger kapseln Logik direkt im DBMS.\n- Code-to-Data verlagert rechenintensive Verarbeitung zur Datenbank, um Datenbewegung zu reduzieren.\n\nTradeoff: Performance und Zentralisierung gegen DB-Kopplung und schwierigere Tests.","tags":["db-programmierung","hana","architektur"],"source":"Zusammenfassung §8.1 und §11.2","external_id":"db-praktisch-127"}
{"semester":"Semester 4","subject":"Datenbanken - Praktische Umsetzung","deck":"Semester 4","question":"# Prüfungs-Merksatz SQL\nWelcher Merksatz hilft bei fast jeder SQL-Aufgabe?","answer":"**Erst die Datenbasis, dann die Zeilen, dann die Gruppen, dann die Ausgabe.**\n\nÜbersetzt:\n\n```text\nFROM/JOIN -> WHERE -> GROUP BY -> HAVING -> SELECT -> ORDER/LIMIT\n```\n\nDamit vermeidest du viele Fehler bei Joins, Aggregaten und Ergebnisermittlung.","tags":["klausur","dql"],"source":"Zusammenfassung §6.1; §13.2","external_id":"db-praktisch-128"}