Situationsaufgabe: Datenbankentwicklung
Datenbankentwicklung ist das häufigste Thema im FIAE AP Teil 2 – laut IHK-Statistik taucht es in fast 70 % aller Prüfungen auf. Kein Wunder: relationale Datenbanken sind das Rückgrat jeder Unternehmensanwendung. Die Prüfungsaufgabe testet immer die gleiche Kompetenz-Kette: aus einem Textbeschrieb ein ER-Modell ableiten, die Tabellen normalisieren, geeignete Schlüssel wählen und schließlich SQL-Abfragen schreiben, die reale Anforderungen erfüllen. Diese Lektion arbeitet eine vollständige Situationsaufgabe durch.
1) Das Szenario
Betrieb: Die BuchVerkauf GmbH betreibt einen Online-Buchhandel. Du wirst beauftragt, eine relationale Datenbank für die Bestellverwaltung zu entwerfen.
Anforderungen (aus Analysegespräch):
- Kunden können mehrere Bestellungen aufgeben
- Jede Bestellung enthält ein oder mehrere Bücher in bestimmter Stückzahl
- Bücher haben Titel, ISBN, Preis und einen oder mehrere Autoren
- Ein Autor kann mehrere Bücher geschrieben haben, ein Buch kann mehrere Autoren haben
- Bestellungen haben einen Status (offen, versendet, geliefert, storniert) und ein Bestelldatum
- Kunden haben Name, E-Mail (eindeutig), Adresse und Registrierungsdatum
2) Teilaufgaben mit Musterlösungen
3) Normalisierung – Schritt für Schritt
Klick die Normalform für Definition und Beispiel:
4) SQL-Schnellreferenz für die Prüfung
| SQL-Konstrukt | Syntax | Wann verwendet |
|---|---|---|
| INNER JOIN | FROM A INNER JOIN B ON A.id = B.a_id | Nur übereinstimmende Zeilen aus beiden Tabellen |
| LEFT JOIN | FROM A LEFT JOIN B ON A.id = B.a_id | Alle Zeilen aus A, auch ohne Match in B (NULL) |
| GROUP BY + COUNT | SELECT k_id, COUNT(*) FROM Bestellung GROUP BY k_id | Aggregation: wie viele Bestellungen pro Kunde |
| HAVING | GROUP BY k_id HAVING COUNT(*) > 3 | Filter auf aggregierte Werte (wie WHERE, aber nach GROUP BY) |
| Subquery | WHERE preis = (SELECT MAX(preis) FROM Buch) | Ergebnis einer Abfrage als Bedingung nutzen |
| ORDER BY | ORDER BY bestelldatum DESC | Sortierung; DESC = absteigend |
5) Typische Bewertungsfallen
- n:m-Beziehungen ohne Zwischentabelle. In relationalen DBs gibt es kein direktes n:m. Immer Auflösung durch Beziehungstabelle (z. B. Buch_Autor mit buch_id + autor_id als zusammengesetztem PK).
- NULL in Primärschlüsseln. PKs dürfen nie NULL sein. Immer explizit
NOT NULL PRIMARY KEYangeben. - Normalisierung überspringen. Direkt aus dem Text in 3NF springen – dabei Fehler übersehen. Immer explizit: 0NF → 1NF → 2NF → 3NF durchgehen und jeden Schritt kurz benennen.
- SQL-Aliase vergessen. Bei JOINs mit gleichen Spaltennamen (z. B.
idin mehreren Tabellen) immer Tabellen-Aliase verwenden:k.name, b.titel. - Fremdschlüssel nicht erwähnt. FK-Constraints sind Pflichtbestandteil eines vollständigen Datenbankdesigns.
Zusammenfassung
Datenbankaufgaben folgen immer der gleichen Kette: (1) ER-Modell aus dem Textbeschrieb ableiten (Entitäten, Attribute, Beziehungen mit Kardinalitäten), (2) Normalisierung bis 3NF mit expliziten Schritten, (3) SQL-Abfragen mit JOINs, GROUP BY, HAVING und Subqueries, (4) Optimierung durch Indizes. n:m-Beziehungen immer mit Zwischentabelle auflösen. Primärschlüssel nie NULL. Fremdschlüssel explizit benennen.
Verwandte Lektionen: Format AP Teil 2 FIAE · Situationsaufgabe OOP · Situationsaufgabe API · und mehrWeitere relevante LektionenNormalisierung GrundlagenSQL-AbfragenSecure Coding (SQL Injection)