Klausurzusammenfassung: Datenbanken - Praktische Umsetzung

1. Stoffkarte und Prüfungskern

Der Kurs behandelt Datenbanken aus praktischer Sicht: SQL-Syntax sicher anwenden, PostgreSQL-Objekte erstellen, Daten konsistent ändern, Abfragen interpretieren, Logik in Datenbank und Anwendung sauber trennen, Transaktionen verstehen und relationale Systeme von NoSQL-Systemen abgrenzen. Die Übungsklausur zeigt, dass nicht nur Definitionen, sondern konkrete Befehle, Ergebnisermittlung und kurze Codeergänzungen erwartet werden können.

Gliederung

1. Grundlagen, Architektur und Datenmodelle
2. PostgreSQL, DBeaver und SQL-Konventionen
3. DDL, Datentypen und Integritätsbedingungen
4. DML: INSERT, UPDATE, DELETE
5. DQL: SELECT, WHERE, GROUP BY, JOINs, Subqueries
6. Views, Index, Rechte und Systemkatalog
7. DB-seitige Programmierung: Functions, Procedures, Trigger
8. Transaktionen, Isolation, Locks, 2PL und 2PC
9. JDBC, REST, JPA und ORM
10. Relationale Erweiterungen, HANA und verteilte Datenbanken
11. NoSQL: Redis, MongoDB, Cassandra, Neo4j und Polystores
12. Klausurtraining, Checkliste, Fragen und Abdeckung

2. Grundlagen, Architektur und Datenmodelle

2.1 Daten, Information, Wissen

2.2 Datenbank, DBMS, Datenbanksystem

Ein DBMS übernimmt exklusiven physischen Datenzugriff, Konsistenz- und Integritätssicherung, zentrale Zugriffskontrolle sowie interne Hintergrundprozesse wie Optimierung, Logging, Backup und Rechteprüfung. Für die Klausur ist wichtig: Anwendungen sollen nicht direkt an physischen Dateien arbeiten, sondern über das DBMS.

2.3 Datenbanksprachen

2.4 ANSI-SPARC und Datenmodelle

Die Drei-Schichten-Architektur erklärt Datenunabhängigkeit: Fachliche und externe Sichten sollen möglichst stabil bleiben, auch wenn sich physische Speicherung oder interne Optimierungen ändern. In praktischen Aufgaben zeigt sich das später bei Views, JDBC/JPA und REST-Backends.

3. PostgreSQL, DBeaver und SQL-Konventionen

3.1 Warum PostgreSQL im Kurs?

PostgreSQL ist frei, quelloffen, nah am ANSI-SQL-Standard und unterstützt vollständige ACID-Transaktionen, auch für DDL. Es ist stark erweiterbar: eigene Datentypen, Funktionen, Operatoren, Stored Procedures, PL/pgSQL und weitere Prozedursprachen sowie JSON/JSONB-Unterstützung sind möglich. Dadurch eignet es sich sowohl didaktisch als auch praktisch.

3.2 DBeaver

DBeaver ist ein plattformunabhängiger Universal-Datenbankclient. Es bietet SQL-Editor, Syntax-Highlighting, Autovervollständigung, ER-/Relationsschema-Visualisierung sowie Import/Export. Wichtig: Die DBeaver-Visualisierung wird oft als ER-Modell bezeichnet, zeigt praktisch aber das Relationenschema mit Tabellen und Fremdschlüsseln.

3.3 SQL-Konventionen

• SQL-Schlüsselwörter sind nicht case-sensitive, werden aus Lesbarkeitsgründen aber großgeschrieben: SELECT, FROM, WHERE.
• String-Literale stehen in einfachen Hochkommas: 'Metallica'.
• Bezeichner wie Tabellen- und Spaltennamen sollten konsistent geschrieben werden. In PostgreSQL werden nicht quoted identifiers standardmäßig kleingeschrieben.
• SQL ist deklarativ: Man beschreibt das gewünschte Ergebnis, nicht den technischen Zugriffspfad.

4. DDL, Datentypen und Integritätsbedingungen

4.1 Schema und Tabelle erstellen

CREATE SCHEMA employees;
SET SCHEMA 'employees';

CREATE TABLE emp_employee (
  emp_id INTEGER,
  emp_email VARCHAR(50),
  emp_first_name VARCHAR(50),
  emp_last_name VARCHAR(50),
  PRIMARY KEY (emp_id)
);

Ein DBMS kann mehrere Datenbanken verwalten, innerhalb einer Datenbank organisieren Schemas die Tabellen. Tabellen bestehen aus Spaltendefinitionen mit Name, Datentyp und optionalen Constraints.

4.2 PostgreSQL-Datentypen

4.3 ALTER und DROP

DROP SCHEMA employees;
DROP TABLE emp_employee;

ALTER TABLE emp_employee ADD COLUMN birth_date DATE;
ALTER TABLE emp_employee DROP COLUMN first_name;

CREATE legt Objekte an, ALTER verändert bestehende Objekte, DROP löscht ganze Objekte. Das ist strukturelle Arbeit, keine Datensatzmanipulation.

4.4 Constraints

4.5 Referentielle Integrität

CREATE TABLE pro_project (
  pro_id SERIAL,
  pro_name VARCHAR(255),
  PRIMARY KEY (pro_id)
);

CREATE TABLE emp_employee (
  emp_id SERIAL,
  emp_pro_id INTEGER,
  emp_email VARCHAR(50),
  PRIMARY KEY (emp_id),
  CONSTRAINT fk_employee_project
    FOREIGN KEY (emp_pro_id)
    REFERENCES pro_project(pro_id)
    ON DELETE SET NULL
);

5. DML: INSERT, UPDATE, DELETE

5.1 INSERT

INSERT INTO employee (id, email, first_name, last_name)
VALUES (1, 'worker@comp.de', 'Max', 'Muster');

INSERT INTO employee (id, email, first_name, last_name)
VALUES
  (2, 'a@comp.de', 'Anna', 'Auer'),
  (3, 'b@comp.de', 'Ben', 'Bauer');

Beim Einfügen aus einer anderen Tabelle ohne Spaltenliste müssen Anzahl und Typen der Spalten identisch sein. In Klausurantworten ist eine explizite Spaltenliste meistens sicherer.

5.2 UPDATE

UPDATE employee
SET last_name = 'Mustermann',
    first_name = 'Maxi'
WHERE email = 'worker@comp.de'
  AND last_name = 'Muster';

UPDATE bezieht sich auf eine Tabelle. Die WHERE-Klausel filtert die betroffenen Datensätze. Bestehende Inhalte können zur Berechnung neuer Werte genutzt werden, etwa bei Preiserhöhungen.

5.3 DELETE

DELETE FROM employee
WHERE email = 'worker@comp.de';

6. DQL: SELECT, WHERE, GROUP BY, JOINs, Subqueries

6.1 Grundform und logische Reihenfolge

SELECT c.country, COUNT(*) AS anzahl
FROM customer AS c
WHERE c.country IS NOT NULL
GROUP BY c.country
HAVING COUNT(*) > 1
ORDER BY anzahl DESC
LIMIT 10;

6.2 Alias, DISTINCT und Multimengen

Aliase verbessern Lesbarkeit und sind bei mehrfachen Tabellen notwendig, wenn Spalten gleich heißen. DISTINCT entfernt Dubletten. Standard-SQL-Ergebnisse sind aber Multimengen: gleiche Zeilen dürfen mehrfach vorkommen, bis DISTINCT explizit gesetzt wird.

SELECT DISTINCT c.first_name AS vorname
FROM customer AS c;

6.3 Aggregatfunktionen und NULL

6.4 WHERE-Bedingungen

6.5 Datum, Textfunktionen und Type Casts

SELECT CURRENT_TIMESTAMP;
SELECT EXTRACT(MONTH FROM '2025-09-12'::DATE);
SELECT CURRENT_DATE + INTERVAL '7 days';

SELECT UPPER('sql'), LOWER('SQL');
SELECT LENGTH('Hochschule');
SELECT TRIM('   Text   ');
SELECT SUBSTRING('Datenbank' FROM 6 FOR 4);
SELECT CONCAT('Max', ' ', 'Muster');

SELECT '123'::INTEGER;
SELECT CAST('2025-09-12' AS DATE);

SELECT *
FROM orderitem
ORDER BY ordered_qty DESC
LIMIT 1 OFFSET 10;

6.6 GROUP BY und HAVING

SELECT country, COUNT(country) AS count
FROM xcustomer
GROUP BY country
HAVING COUNT(country) > 1;

Aus der Übungsklausur ergibt diese Abfrage für die gegebene Tabelle die Länder, die mehr als einmal vorkommen: Canada, Brazil und USA mit jeweils 2.

6.7 Unterabfragen

Unterabfragen können als Wert, Wertemenge, Inline View im FROM-Teil oder korrelierte Unterabfrage verwendet werden. Eine korrelierte Unterabfrage hängt von der äußeren Abfrage ab und wird logisch für jede relevante äußere Zeile ausgewertet.

SELECT c.customer_id, c.last_name
FROM customer AS c
WHERE EXISTS (
  SELECT 1
  FROM invoice AS i
  WHERE i.customer_id = c.customer_id
);

6.8 JOINs

SELECT al.title, ar.name
FROM album AS al
JOIN artist AS ar
  ON al.artist_id = ar.artist_id
WHERE ar.name = 'Metallica';

6.9 Mengenoperationen

UNION, INTERSECT und EXCEPT kombinieren Ergebnismengen. Die beteiligten SELECTs müssen kompatible Spaltenanzahl und Datentypen liefern. UNION entfernt Duplikate, UNION ALL behält sie.

7. Views, Index, Rechte und Systemkatalog

7.1 Views

Views sind gespeicherte Abfragen, die sich nach außen wie Tabellen verhalten. Sie dienen als Abstraktionsschicht, zur Wiederverwendung komplexer SELECTs, für Berichte, Geschäftsregeln und Sicherheit.

CREATE VIEW mitarbeiter_namen AS
SELECT id, vornamen, nachname
FROM mitarbeiter;

CREATE VIEW mitarbeiter_namen2 (nummer, vname, nname) AS
SELECT id, vornamen, nachname
FROM mitarbeiter;

DROP VIEW mitarbeiter_namen;

7.2 Index

CREATE INDEX idx_invoice_country ON invoice(billing_country);
CREATE UNIQUE INDEX idx_user_email ON app_user(email);
EXPLAIN SELECT * FROM invoice WHERE billing_country = 'Germany';

Indizes verbessern Lesezugriffe, verschlechtern aber Schreiboperationen, weil der Index bei INSERT, UPDATE und DELETE mitgepflegt werden muss. Primärschlüssel sind indiziert. Ein UNIQUE INDEX erzwingt Eindeutigkeit ähnlich wie ein Primärschlüssel, ersetzt aber nicht automatisch alle fachlichen Schlüsselentscheidungen.

7.3 Rechteverwaltung

CREATE USER martin WITH PASSWORD '123456789';
GRANT SELECT ON invoice TO martin;
GRANT SELECT (emp_first_name, emp_last_name) ON emp_employee TO martin;
REVOKE SELECT ON emp_employee FROM martin;

CREATE ROLE buchhaltung;
GRANT SELECT ON invoice TO buchhaltung;
GRANT buchhaltung TO martin;

Rechte sollten nach dem Prinzip der minimalen Rechte vergeben werden. Rollenbasierte Zugriffskontrolle ist übersichtlicher als direkte Rechtevergabe an einzelne User, weil Rechte an Rollen und Rollen an Benutzer gekoppelt werden.

7.4 System Catalog und Information Schema

SELECT *
FROM pg_attribute
WHERE attname LIKE 'billing_country';

SELECT *
FROM information_schema.tables
WHERE table_schema = 'chinook';

Der Systemkatalog enthält Metadaten zu Tabellen, Spalten und Verwaltung. information_schema ist standardisiert und daher portabler; pg_*-Tabellen sind PostgreSQL-spezifisch.

8. DB-seitige Programmierung: Functions, Procedures, Trigger

8.1 Warum DB-seitige Logik?

8.2 Functions mit LANGUAGE SQL

Benutzerdefinierte Funktionen liefern einen Skalarwert, Datensatz oder void. Sie können in SQL-Abfragen genutzt werden und erweitern dadurch die Sprache SQL.

CREATE OR REPLACE FUNCTION kundenname(cust_id integer)
RETURNS varchar(100)
LANGUAGE SQL
AS $$
  SELECT "FirstName" || ' ' || "LastName"
  FROM "Customer"
  WHERE "CustomerId" = cust_id;
$$;

SELECT kundenname(5);

• Bei LANGUAGE SQL ergibt sich der Rückgabewert implizit aus der letzten SQL-Anweisung.
• $$ ... $$ ist Dollar-Quoting und verhindert Probleme mit Hochkommas und Zeilenumbrüchen im Body.
• Bei mehreren DML-Anweisungen kann BEGIN ATOMIC ... END Atomarität herstellen.
• COMMIT und ROLLBACK sind in Functions nicht zulässig.

8.3 Functions mit PL/pgSQL

CREATE OR REPLACE FUNCTION anzahl(unteregrenze int, oberegrenze int)
RETURNS int
LANGUAGE plpgsql
AS $$
DECLARE
  anzahl int;
BEGIN
  SELECT COUNT(*)
  INTO anzahl
  FROM invoice
  WHERE total BETWEEN unteregrenze AND oberegrenze;

  RETURN anzahl;
END
$$;

PL/pgSQL bietet Variablen, DECLARE, BEGIN ... END, IF, CASE, LOOP, WHILE, FOR und Fehlerbehandlung mit EXCEPTION. Übergabeparameter sind implizit verfügbar; lokale Variablen müssen deklariert werden. Abfrageergebnisse werden mit SELECT ... INTO variable gespeichert.

8.4 Procedures

CREATE OR REPLACE PROCEDURE change_support_staff(
  p_customer_id INT,
  p_new_support_id INT
)
LANGUAGE plpgsql
AS $$
BEGIN
  UPDATE customer
  SET support_rep_id = p_new_support_id
  WHERE customer_id = p_customer_id;
END
$$;

CALL change_support_staff(1, 5);

8.5 Trigger

CREATE OR REPLACE FUNCTION validate_hire_date()
RETURNS TRIGGER
LANGUAGE plpgsql
AS $$
BEGIN
  IF NEW.hire_date <= NEW.birth_date THEN
    RAISE EXCEPTION 'Fehler: Geburtstag nach Einstelldatum';
  END IF;
  RETURN NEW;
END;
$$;

CREATE TRIGGER check_hire_date
BEFORE INSERT ON employee
FOR EACH ROW
EXECUTE FUNCTION validate_hire_date();

9. Transaktionen, Isolation, Locks, 2PL und 2PC

9.1 Transaktion und ACID

Eine Transaktion ist eine Folge von Datenmanipulationen, die eine logische Arbeitseinheit bildet. Einzelne Zwischenschritte können inkonsistent sein; nach erfolgreichem Abschluss muss die Datenbank wieder konsistent sein. Wenn Abschluss nicht möglich ist, werden Änderungen über Log-Informationen zurückgenommen.

START TRANSACTION;
UPDATE account SET balance = balance - 100 WHERE id = 1;
UPDATE account SET balance = balance + 100 WHERE id = 2;
COMMIT;
-- oder bei Fehler:
ROLLBACK;

Auto-Commit führt nach jeder einzelnen DML-Anweisung automatisch ein Commit aus. Das ist bequem, aber falsch, wenn mehrere Befehle fachlich eine gemeinsame Transaktion bilden.

9.2 Nebenläufigkeitsanomalien

9.3 Isolation Level

9.4 Synchronisationsstrategien, Locks und Deadlocks

Locks schützen Relationen oder Datensätze vor gleichzeitigen Zugriffen. Ein Deadlock entsteht, wenn Transaktion 1 Ressource A hält und auf B wartet, während Transaktion 2 B hält und auf A wartet.

9.5 2PL vs. 2PC

10. JDBC, REST, JPA und ORM

10.1 JDBC

JDBC (Java Database Connectivity) ist die Standard-Schnittstelle für SQL-Datenbankzugriff aus Java. JDBC enthält keinen datenbankspezifischen Code; datenbankspezifische Details kommen über den JDBC-Treiber. Im Kurs wird der Typ-4-Treiber für PostgreSQL genutzt: vollständig in Java, setzt JDBC-Calls direkt in das Datenbankprotokoll um.

String adresse = "jdbc:postgresql://localhost:5432/postgres?currentSchema=%s";
String schema = "chinook";
String url = String.format(adresse, schema);

Properties props = new Properties();
props.setProperty("user", "postgres");
props.setProperty("password", "postgres");

Connection conn = DriverManager.getConnection(url, props);
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery("SELECT * FROM chinook.genre;");

while (rs.next()) {
  Integer id = rs.getInt("genre_id");
  String name = rs.getString("name");
}

rs.close();
st.close();
conn.close();

Ein ResultSet wird cursorartig mit next() durchlaufen. ResultSet, Statement und Connection müssen geschlossen werden, sonst bleiben Ressourcen länger als nötig belegt.

10.2 JDBC-Transaktionen

conn.setAutoCommit(false);
try {
  // mehrere DML-Befehle
  conn.commit();
} catch (SQLException ex) {
  conn.rollback();
  throw ex;
}

10.3 SQL Injection und PreparedStatement

Bei String-Verkettung kann Benutzereingabe die SQL-Logik verändern, z. B. durch 'Blues' OR 1=1. Prepared Statements trennen SQL-Struktur und Parameterwerte.

PreparedStatement pst = conn.prepareStatement(
  "UPDATE genre SET name = 'Blues Rock' WHERE name = ?"
);
pst.setString(1, eingabe);
int affectedRows = pst.executeUpdate();

10.4 REST und 3-Schichten-Architektur

10.5 ORM, JPA und Hibernate

Der Object-Relational Impedance Mismatch beschreibt Konflikte zwischen Objektwelt und relationaler Welt: Vererbung vs. Tabellen, Objektidentität vs. Primärschlüssel, Objektgraph-Navigation vs. JOINs, RAM-Zustand vs. persistenter Zustand. ORM überbrückt diese Unterschiede.

11. Relationale Erweiterungen, HANA und verteilte Datenbanken

11.1 OLTP vs. OLAP

Data Cubes strukturieren Kennzahlen nach Dimensionen wie Zeit, Produkt und Region. Operationen sind Slicing, Dicing, Roll-up und Drill-down. Das Sternschema bildet Cubes relational ab: Faktentabelle in der Mitte, Dimensionstabellen außen. Dimensionstabellen werden bewusst denormalisiert, weil OLAP stark lesend arbeitet.

11.2 ORDBMS und SAP HANA

Objektrelationale Datenbanken erweitern relationale Systeme um benutzerdefinierte Datentypen, Typ- und Tabellenhierarchien, Methoden, Objektidentität und komplexe Objekte. Moderne SQL-Datenbanken enthalten viele dieser Features, ohne im Alltag noch separat als ORDBMS bezeichnet zu werden.

11.3 Verteilte Datenbanken

Eine verteilte Datenbank hat ein einziges logisches Schema, aber mehrere physische Fragmente auf vernetzten Rechnern. Ein DDBMS soll Verteilungstransparenz herstellen: Für Nutzer wirkt das System wie eine Datenbank.

11.4 CAP und BASE

12. NoSQL: Redis, MongoDB, Cassandra, Neo4j und Polystores

12.1 NoSQL-Grundidee

Fachlich ist „nicht-relational“ oft präziser als „NoSQL“, weil einige Systeme SQL-ähnliche Sprachen besitzen. Entscheidend ist das andere Datenmodell: Key-Value, Dokument, Wide-Column oder Graph. Treiber sind Big Data-Anforderungen: Volume, Variety und Velocity sowie horizontale Skalierung, Replikation, flexible Schemata und häufig BASE/Eventual Consistency.

12.2 Key-Value Stores und Redis

SET user:U17547:nachname Mueller
GET user:U17547:nachname

HSET user:U17547 vorname Max nachname Mueller email max@example.com
HGETALL user:U17547

Redis hält Daten primär im RAM. Persistenz entsteht durch RDB-Snapshots und AOF-Journaling. Redis ist streng genommen eine Key-Data-Structure-Datenbank, weil Values strukturierte Typen wie Strings, Hashes, Lists, Sets, Streams oder RedisJSON sein können. Ein Redis Hash ist für Objekte oft besser als viele einzelne String-Keys, weil alle Felder eines Objekts mit HGETALL gelesen werden können.

12.3 Dokumentendatenbanken und MongoDB

MongoDB speichert BSON, eine binäre JSON-Repräsentation mit zusätzlichen Datentypen. Jedes Dokument erhält ein eindeutiges _id-Feld, bei fehlender Angabe automatisch als ObjectId. Schemafreiheit bedeutet nicht Regelfreiheit: Die Applikation trägt mehr Verantwortung für Struktur, Validierung und Beziehungen.

db.benutzer.insertOne({
  name: "Anna Schmidt",
  alter: 28,
  status: "aktiv",
  interessen: ["Lesen", "Wandern"]
});

db.benutzer.find({ alter: { $gt: 25 } }, { name: 1, _id: 0 });

db.benutzer.updateOne(
  { name: "Anna Schmidt" },
  { $set: { status: "aktiv" }, $inc: { anzahl_updates: 1 } }
);

db.benutzer.deleteOne({ name: "Anna Schmidt" });

12.4 Wide-Column Stores und Cassandra

Wide-Column Stores gruppieren Daten in Column Families. Sie eignen sich für sparse data, hohe Schreiblast, Zeitreihen, Logging, IoT und massiv verteilte Daten. Logisch kann man sie als sortierte Map verstehen:

(RowKey, ColumnFamily, Column, Timestamp) → Value

CREATE TABLE personen (
  id UUID,
  name text,
  alter int,
  PRIMARY KEY (id)
);

-- Zusammengesetzt:
PRIMARY KEY ((land), stadt, strasse)

12.5 Graphdatenbanken und Neo4j

Graphdatenbanken behandeln Beziehungen als First-Class Citizens. Im Property-Graph-Modell bestehen Daten aus Knoten, gerichteten Kanten, Properties und Labels. Der Vorteil entsteht bei tief vernetzten Daten, etwa Social Graphs, Empfehlungslogik, Fraud Detection, Knowledge Graphs und Netzwerktopologien.

CREATE (:Person {name: 'Anna', alter: 28});

MATCH (p:Person)-[:ARBEITET_BEI]->(f:Firma)
WHERE p.alter > 25
RETURN p.name, f.name;

MATCH (p:Person {name: 'Anna'})
DETACH DELETE p;

12.6 NoSQL-Einsatzszenarien, Polystores, Self-Tuning

Polystores verbinden heterogene Speicher-Engines unter einer gemeinsamen Abfrageschnittstelle. Beispiel E-Commerce: relationale Datenbank für Bestellungen, Dokumentendatenbank für Produktkatalog, Graphdatenbank für Empfehlungen, Key-Value Store für Klickpfade. Herausforderung sind Komplexität, Datentransfer, Latenz und globale Konsistenz.

Self-Tuning-Datenbanken passen Konfiguration und physische Struktur automatisch an, etwa Indizes, Partitionierung, Materialized Views, Buffer-Größen, Parallelität und Checkpointing-Intervalle.

12.7 Historische Konzepte

Vor dem relationalen Modell gab es hierarchische und netzwerkartige Datenbanken. Hierarchische Systeme modellieren baumartige 1:n-Strukturen; Netzwerkdatenbanken erlauben n:m-Beziehungen über Owner-Member-Sets. Der Zugriff war navigierend und stärker programmiert als in SQL.

13. Klausurtraining, Checkliste, Fragen und Abdeckung

13.1 Aufgabentypen aus der Übungsklausur

13.2 Musterlösungen als Denkgerüst

CREATE TABLE album (
  album_id INTEGER,
  title VARCHAR(255) NOT NULL,
  artist_id INTEGER NOT NULL,
  PRIMARY KEY (album_id),
  CONSTRAINT fk_album_artist
    FOREIGN KEY (artist_id)
    REFERENCES artist(artist_id)
);

SELECT al.title
FROM album AS al
JOIN artist AS ar
  ON al.artist_id = ar.artist_id
WHERE ar.name = 'Metallica';

CREATE OR REPLACE FUNCTION set_default_genre()
RETURNS TRIGGER
LANGUAGE plpgsql
AS $$
BEGIN
  IF NEW.name IS NULL THEN
    NEW.name := 'Untitled Genre';
  END IF;
  RETURN NEW;
END;
$$;

CREATE TRIGGER trg_default_genre
BEFORE INSERT ON genre
FOR EACH ROW
EXECUTE FUNCTION set_default_genre();

PreparedStatement ps = conn.prepareStatement(
  "SELECT * FROM artist WHERE name = ?"
);
ps.setString(1, name);
ResultSet rs = ps.executeQuery();
while (rs.next()) {
  System.out.println(rs.getString("name"));
}
rs.close();
ps.close();

13.3 Typische Fehler und Prüfungsfallen

13.4 Lerncheckliste

13.5 Mögliche Klausurfragen

1. Erstellen Sie eine Tabelle inklusive Primärschlüssel, Fremdschlüssel und ON DELETE-Verhalten.
2. Bestimmen Sie das Ergebnis einer SELECT-Abfrage mit GROUP BY und HAVING.
3. Formulieren Sie eine SQL-Abfrage über mehrere Tabellen, z. B. Alben eines bestimmten Künstlers.
4. Erklären Sie, warum WHERE count(*) > 1 falsch ist und wie es korrekt lautet.
5. Schreiben oder ergänzen Sie eine PL/pgSQL-Function mit SELECT ... INTO und RETURN.
6. Schreiben Sie eine Trigger-Funktion, die bei INSERT einen Defaultwert setzt oder eine Regel prüft.
7. Erklären Sie, warum ein Trigger in PostgreSQL eine separate Trigger-Funktion benötigt.
8. Vergleichen Sie Read Committed, Repeatable Read und Serializable anhand erlaubter Anomalien.
9. Unterscheiden Sie 2PL und 2PC nach Ziel, Phasen und ACID-Bezug.
10. Ergänzen Sie JDBC-Code mit PreparedStatement und korrekter Ressourcenfreigabe.
11. Erklären Sie den Unterschied zwischen direktem JDBC-Zugriff und REST-Backend.
12. Ordnen Sie JPA, Hibernate und JDBC in einer Architektur ein.
13. Erklären Sie CAP und BASE und grenzen Sie CAP-Consistency von ACID-Consistency ab.
14. Wählen Sie für ein Szenario Redis, MongoDB, Cassandra oder Neo4j und begründen Sie.
15. Erklären Sie bei Cassandra Partition Key, Clustering Columns, UPSERT und Consistency Level.
16. Erklären Sie, warum Neo4j für tiefe Beziehungen geeignet ist und worin Indexfreie Adjazenz besteht.

13.6 Abdeckungstabelle