Tag 17: Datenmodellierung & SQL

IHK-Vorbereitung · Fachinformatiker Systemintegration

Tag 17: Datenmodellierung & SQL

Überblick

UML – Unified Modeling Language

UML ist eine standardisierte grafische Notation zur Modellierung von Software- und Systemarchitekturen. Für die IHK-Prüfung (AP1 + AP2) sind insbesondere drei Diagrammtypen prüfungsrelevant:

▶

Aktivitätsdiagramm

Abläufe, Prozesse und Algorithmen; vergleichbar mit einem Flussdiagramm.

□

Klassendiagramm

Statische Struktur: Klassen, Attribute, Methoden und ihre Beziehungen.

◎

Use-Case-Diagramm

Systemgrenzen, Akteure und Anwendungsfälle aus Nutzersicht.

Verhaltensdiagramm

Aktivitätsdiagramm

Zeigt den Ablauf von Aktivitäten, Verzweigungen und parallelen Abläufen. Prüfungsrelevant: Elemente lesen, zeichnen und einen Algorithmus oder Geschäftsprozess modellieren.

Symbol	Name	Bedeutung
●	Startknoten	Ausgefüllter schwarzer Kreis – Beginn des Ablaufs
◉	Endknoten	Kreis mit Punkt – Ende des gesamten Ablaufs
[ ]	Aktion	Abgerundetes Rechteck – einzelne ausführbare Tätigkeit
◇	Entscheidung/Zusammenführung	Raute – Verzweigung mit Bedingungen in eckigen Klammern [Bedingung]
━━	Synchronisation (Fork/Join)	Breiter schwarzer Balken – parallele Abläufe starten oder zusammenführen
\| \|	Swimlane	Vertikale Unterteilung – Verantwortungsbereiche von Akteuren

Beispiel: Bestellprozess

Strukturdiagramm

Klassendiagramm

Modelliert Klassen mit Attributen (Daten) und Methoden (Verhalten) sowie deren Beziehungen untereinander. Jede Klasse wird als dreistufiges Rechteck dargestellt.

Beziehungstyp	Symbol	Bedeutung / Beispiel
Assoziation	————	allgemeine Verbindung: Kunde kauft Produkt
Aggregation	◇————	„Teil-von" (Teile können ohne Ganzes existieren): Abteilung hat Mitarbeiter
Komposition	◆————	starke Teil-von (Teile existieren nur im Ganzen): Rechnung hat Positionen
Vererbung	▷————	Generalisierung: Pkw erbt von Fahrzeug
Realisierung	▷- - -	Klasse implementiert Interface

Beispiel: Onlineshop

⚠️ Prüfungstipp: Sichtbarkeit beachten: + = public, – = private, # = protected. Multiplizitäten (1, *, 0..1, 1..*) müssen korrekt an die Linie geschrieben werden.

Verhaltensdiagramm

Use-Case-Diagramm (Anwendungsfalldiagramm)

Zeigt, welche Akteure welche Funktionen (Use Cases) eines Systems nutzen. Gibt einen Überblick aus Anwenderperspektive – ohne technische Details.

Element	Symbol	Bedeutung
Akteur	Strichmännchen	Person, System oder Rolle außerhalb des Systems
Use Case	Ellipse	Anwendungsfall / Funktion des Systems
Systemgrenze	Rechteck	Umrahmt alle Use Cases des Systems
«include»	gestrichelt →	Ein Use Case ruft einen anderen immer auf (Pflichtbestandteil)
«extend»	gestrichelt →	Ein Use Case kann optional erweitert werden (nur unter Bedingung)
Generalisierung	Vererbungspfeil	Akteur/Use-Case erbt von allgemeinerem

Beispiel: Bibliothekssystem

⚠️ «include» vs. «extend» – häufige Prüfungsfrage: «include» = immer ausgeführt (Pflicht), «extend» = nur unter bestimmter Bedingung (optional). Der Pfeil zeigt beim include vom Basis-UC zum eingebundenen UC; beim extend vom erweiterten UC zum Basis-UC.

Grundkonzept

Entity-Relationship-Modell (ERM) nach Chen

Das ERM ist ein Datenmodell zur konzeptuellen Darstellung von Daten und ihren Beziehungen – unabhängig von einer konkreten Datenbank. Es bildet die Grundlage für das relationale Datenbankmodell.

Symbol	Bezeichnung	Bedeutung
□	Entity (Entität)	Objekt der realen Welt, das eindeutig identifizierbar ist (z.B. Kunde, Artikel)
◇	Relationship (Beziehung)	Verbindung zwischen zwei oder mehr Entitäten (z.B. kauft, enthält)
○	Attribut	Eigenschaft einer Entität oder Beziehung (z.B. Name, Preis)
○	Schlüsselattribut	Attribut zur eindeutigen Identifizierung einer Entität (unterstrichen)

Kardinalitäten (Beziehungstypen)

Kardinalitäten beschreiben, wie viele Instanzen einer Entität mit wie vielen Instanzen einer anderen in Beziehung stehen können. In der IHK-Prüfung sind beide Notationen geläufig.

1:1 Eins-zu-Eins Jeder Datensatz ist genau einem anderen zugeordnet. Beispiel: Person hat einen Reisepass.

1:N Eins-zu-Viele Einer kann mehrere haben, viele gehören zu einem. Beispiel: Abteilung hat viele Mitarbeiter.

N:M Viele-zu-Viele Viele können mit vielen in Beziehung stehen. Beispiel: Schüler besucht viele Fächer, Fach hat viele Schüler. → Erfordert eine Zwischentabelle!

ℹ️ Min-Max-Notation: Neben der einfachen Chen-Notation wird auch die Min-Max-Schreibweise genutzt: (min, max) an jedem Ende der Beziehung. Beispiel: Mitarbeiter (0,n) — arbeitet_in — (1,1) Abteilung bedeutet: Ein Mitarbeiter arbeitet in genau einer Abteilung, eine Abteilung hat 0 bis n Mitarbeiter.

Vom ERM zur Tabelle

Überführung ins relationale Datenbankmodell

Das relationale Modell stellt alle Daten als Tabellen (Relationen) dar. Bei der Überführung gelten folgende Regeln:

Entitäten → werden zu Tabellen; Schlüsselattribut wird zum Primärschlüssel (PK)
1:N-Beziehung → der Primärschlüssel der „1"-Seite wandert als Fremdschlüssel (FK) in die „N"-Tabelle
N:M-Beziehung → wird durch eine Zwischentabelle aufgelöst, die die PKs beider Seiten als FK enthält (zusammengesetzter PK)
1:1-Beziehung → FK in einer der beiden Tabellen (oft in der „schwächeren")

Beispiel: Bestellung ↔ Produkt (N:M)

Bestellung

bestellID PK

datum

kundenID FK

Bestellung_Produkt

bestellID PKFK

produktID PKFK

menge

Produkt

produktID PK

bezeichnung

preis

Wichtige Begriffe im relationalen Modell

Begriff	Bedeutung
Relation	Tabelle mit Zeilen und Spalten
Tupel	Zeile / Datensatz einer Tabelle
Attribut	Spalte / Eigenschaft einer Tabelle
Primärschlüssel (PK)	Eindeutiger Identifikator jedes Tupels – darf nicht NULL sein
Fremdschlüssel (FK)	Verweis auf den PK einer anderen (oder derselben) Tabelle – sichert referenzielle Integrität
Domäne	Wertebereich / erlaubte Werte eines Attributs (z.B. INTEGER, VARCHAR(50))
Referentielle Integrität	FK-Wert muss in referenzierter Tabelle existieren oder NULL sein

Ziel der Normalisierung

Normalisierung & Atomisierung

Normalisierung ist ein schrittweises Verfahren, um Redundanzen und Anomalien in Datenbanken zu vermeiden. Voraussetzung für jede Normalform ist die Atomisierung: Jeder Attributwert muss atomar (unteilbar) sein – keine Listen, keine zusammengesetzten Werte in einer Zelle.

ℹ️ Anomalien ohne Normalisierung: Einfügeanomalie (Daten können nicht eingetragen werden, ohne andere einzufügen), Löschanomalie (beim Löschen gehen unbeabsichtigt andere Daten verloren), Änderungsanomalie (eine Änderung muss an mehreren Stellen vorgenommen werden → Inkonsistenz).

Die drei Normalformen (Prüfungsrelevanz: NF1–NF3)

1NF

Erste Normalform (1NF)

Regel: Alle Attributwerte sind atomar (unteilbar). Keine Mehrfachwerte / Wiederholungsgruppen in einer Spalte. Jede Zeile ist durch einen Primärschlüssel eindeutig identifizierbar.

Verletzung: Spalte „Telefon" enthält „0221/12345, 0151/98765" → aufteilen in separate Zeilen/Spalten.

✓ Atomare Werte ✓ Kein Wiederholungsgruppen ✓ Primärschlüssel vorhanden

2NF

Zweite Normalform (2NF)

Voraussetzung: 1NF muss erfüllt sein.

Regel: Jedes Nicht-Schlüsselattribut ist voll funktional abhängig vom gesamten Primärschlüssel – nicht nur von einem Teil davon. Relevant nur bei zusammengesetzten PKs!

Verletzung: Tabelle Bestellposition(BestellID, ProduktID, Produktname, Menge). „Produktname" hängt nur von ProduktID ab, nicht vom gesamten PK → Produktname in eigene Tabelle Produkt auslagern.

Nur bei zusammengesetztem PK relevant

3NF

Dritte Normalform (3NF)

Voraussetzung: 2NF muss erfüllt sein.

Regel: Es darf keine transitive Abhängigkeit geben – kein Nicht-Schlüsselattribut darf von einem anderen Nicht-Schlüsselattribut abhängen.

Verletzung: Tabelle Mitarbeiter(MitarbeiterID, AbteilungsID, Abteilungsname). „Abteilungsname" hängt von AbteilungsID ab (transitiv über PK) → Abteilung in eigene Tabelle auslagern.

Transitive Abhängigkeiten entfernen

Praxisbeispiel

Normalisierungsbeispiel Schritt für Schritt

Ausgangstabelle (unnormalisiert):

AuftragID	Kunde	Ort	PLZ	Artikel	Preis
1001	Müller	Köln	50667	Laptop, Maus	999, 25
1002	Müller	Köln	50667	Monitor	299

1NF

Artikel und Preis atomarisieren → je eine Zeile pro Artikel. Primärschlüssel: (AuftragID, Artikel)

2NF

Preis hängt nur von Artikel ab, nicht von AuftragID → Artikel + Preis in separate Tabelle Artikel(ArtikelID, Bezeichnung, Preis). Kunde, Ort, PLZ hängen nur von AuftragID ab → in Auftrag-Tabelle.

3NF

Ort hängt von PLZ ab (transitiv) → PLZ + Ort in separate Tabelle Ort(PLZ, Ort). Ergebnis: 4 Tabellen – Auftrag, Kunde, Artikel, Ort – vollständig normalisiert.

⚠️ Merksatz: „The key, the whole key, and nothing but the key" – 1NF: Jedes Attribut hängt vom Key ab. 2NF: vom whole key. 3NF: von nothing but the key.

Sprachkategorien

SQL-Unterbefehle im Überblick

DDL

Data Definition Language

Datenbankstruktur anlegen/ändern: CREATE, ALTER, DROP, TRUNCATE

DML

Data Manipulation Language

Daten einfügen/ändern/löschen: INSERT, UPDATE, DELETE

DQL

Data Query Language

Daten abfragen: SELECT

DCL

Data Control Language

Zugriffsrechte steuern: GRANT, REVOKE

DDL – Prüfungsrelevant

Tabellen erstellen und ändern

CREATE TABLE Kunde (
  kundenID  INT          PRIMARY KEY AUTO_INCREMENT,
  name      VARCHAR(100) NOT NULL,
  email     VARCHAR(150) UNIQUE,
  plz       CHAR(5),
  erstellt  DATE         DEFAULT CURRENT_DATE
);

-- Spalte hinzufügen
ALTER TABLE Kunde ADD telefon VARCHAR(20);

-- Fremdschlüssel definieren
ALTER TABLE Bestellung
  ADD CONSTRAINT fk_kunde
  FOREIGN KEY (kundenID) REFERENCES Kunde(kundenID)
  ON DELETE CASCADE;

Constraint	Bedeutung
`PRIMARY KEY`	Eindeutig + NOT NULL – Hauptidentifikator
`FOREIGN KEY`	Verweis auf PK einer anderen Tabelle
`NOT NULL`	Wert muss angegeben werden
`UNIQUE`	Wert darf nur einmal vorkommen (NULL erlaubt)
`DEFAULT`	Standardwert falls kein Wert angegeben
`CHECK`	Wertebereichseinschränkung: z.B. `CHECK (preis > 0)`
`ON DELETE CASCADE`	Datensätze in Kindtabelle werden mitgelöscht

DML

Daten einfügen, ändern, löschen

-- INSERT: Datensatz einfügen
INSERT INTO Kunde (name, email, plz)
VALUES ('Anna Müller', 'anna@example.de', '50667');

-- UPDATE: Datensätze ändern (WHERE nie vergessen!)
UPDATE Kunde
SET    email = 'neu@example.de'
WHERE  kundenID = 5;

-- DELETE: Datensätze löschen
DELETE FROM Bestellung
WHERE  datum < '2020-01-01';

⚠️ Klassischer Prüfungsfehler: UPDATE oder DELETE ohne WHERE-Klausel betrifft alle Datensätze der Tabelle!

DQL – Schwerpunkt Prüfung

SELECT – Abfragen

Reihenfolge der Klauseln (Auswertungsreihenfolge in Klammern):

SELECT   spalte1, COUNT(*) AS anzahl    -- (6) Projektion
FROM     Tabelle                            -- (1) Quelle
JOIN     AndereTabelle ON bed.             -- (2) Verknüpfung
WHERE    bedingung                          -- (3) Zeilenfilter
GROUP BY spalte1                            -- (4) Gruppierung
HAVING   COUNT(*) > 1                      -- (5) Gruppenfilter
ORDER BY spalte1 DESC                      -- (7) Sortierung
LIMIT    10;                               -- (8) Ausgabemenge

⚠️ WHERE vs. HAVING: WHERE filtert vor der Gruppierung (einzelne Zeilen, keine Aggregatfunktionen erlaubt). HAVING filtert nach der Gruppierung (nur Aggregatfunktionen und GROUP-BY-Spalten erlaubt).

JOIN-Typen

JOIN-Typ	Ergebnis	Beispiel-Anwendungsfall
`INNER JOIN`	Nur Zeilen, die in beiden Tabellen übereinstimmen	Kunden mit mindestens einer Bestellung
`LEFT JOIN`	Alle Zeilen der linken Tabelle, rechts ggf. NULL	Alle Kunden, auch ohne Bestellung
`RIGHT JOIN`	Alle Zeilen der rechten Tabelle, links ggf. NULL	Alle Bestellungen, auch ohne zugeordnetem Kunden
`FULL OUTER JOIN`	Alle Zeilen aus beiden Tabellen, NULLs wo keine Übereinstimmung	Vollständige Gegenüberstellung
`CROSS JOIN`	Kreuzprodukt: jede Zeile mit jeder	Kombinationstabellen, selten in Praxis

-- LEFT JOIN Beispiel: Alle Kunden mit Anzahl Bestellungen
SELECT   k.name,
         COUNT(b.bestellID) AS anzahl_bestellungen
FROM     Kunde k
LEFT JOIN Bestellung b ON k.kundenID = b.kundenID
GROUP BY k.kundenID, k.name
ORDER BY anzahl_bestellungen DESC;

Aggregatfunktionen & weitere Prüfungsthemen

Funktion / Konzept	Bedeutung / Beispiel
`COUNT(*)`	Anzahl Zeilen (inkl. NULL); `COUNT(spalte)` ignoriert NULLs
`SUM(spalte)`	Summe aller Werte
`AVG(spalte)`	Durchschnitt (ignoriert NULL)
`MAX / MIN`	Höchster / niedrigster Wert
`DISTINCT`	`SELECT DISTINCT plz FROM Kunde` – doppelte Werte unterdrücken
`LIKE`	Textmuster: `WHERE name LIKE 'M%'` (% = beliebig viele Zeichen, _ = genau ein Zeichen)
`IN / NOT IN`	`WHERE status IN ('aktiv','pausiert')`
`BETWEEN`	`WHERE preis BETWEEN 10 AND 50` (inklusiv)
`IS NULL / IS NOT NULL`	NULL-Prüfung (nie `= NULL` verwenden!)
`Subquery`	`WHERE preis = (SELECT MAX(preis) FROM Produkt)`

Prüfungsaufgabe-Muster

Typische SQL-Prüfungsaufgaben

„Erstellen Sie die Tabelle X mit folgenden Spalten und Constraints" → CREATE TABLE mit PK, FK, NOT NULL
„Geben Sie alle Kunden aus, die mehr als 3 Bestellungen haben" → SELECT + JOIN + GROUP BY + HAVING COUNT(*) > 3
„Welche Produkte wurden noch nie bestellt?" → LEFT JOIN mit WHERE b.produktID IS NULL
„Erhöhen Sie den Preis aller Produkte der Kategorie 'Elektronik' um 10%" → UPDATE mit WHERE
„Was ist der Unterschied zwischen DELETE und TRUNCATE?" → DELETE = zeilenweise mit WHERE möglich, transaktionssicher; TRUNCATE = löscht alle Zeilen, schneller, kein Rollback
„Erläutern Sie den Unterschied zwischen PRIMARY KEY und UNIQUE" → PK: max. 1 pro Tabelle, nie NULL; UNIQUE: mehrfach möglich, NULL erlaubt