ER-Diagramm vs. UML-Klassendiagramm – wann nehme ich was?

Hallo Anna, der Grundgedanke ist tatsächlich ein bisschen mehr als nur "ER ist für Datenbanken, UML für Software". Der eigentliche Unterschied liegt in der Denkweise dahinter.

Beim ER-Modell denkst du strikt aus der Datensicht: Welche Entitäten gibt es, welche Attribute haben sie, wie hängen sie zusammen. Es gibt dort bewusst kein Konzept für Verhalten oder Methoden, weil ER-Diagramme historisch für den konzeptionellen Datenbankentwurf entwickelt wurden. Am Ende überführst du das Ganze ja meistens in Tabellen mit Primär- und Fremdschlüsseln.

Beim UML-Klassendiagramm denkst du objektorientiert. Eine Klasse hat nicht nur Attribute, sondern auch Methoden, also Verhalten. Zusätzlich kennt UML Konzepte wie Vererbung, Interfaces, Sichtbarkeiten (public/private) oder Aggregation vs. Komposition, die im klassischen ER-Modell so nicht vorgesehen sind. Das heißt: Ein Klassendiagramm beschreibt nicht nur, wie Daten strukturiert sind, sondern auch, wie Objekte sich zur Laufzeit verhalten und miteinander interagieren.

In der Praxis läuft es oft so:

• Fachliche/konzeptionelle Modellierung der Datenbank → ER-Diagramm
• Design der Anwendungslogik/Softwarearchitektur → UML-Klassendiagramm

Bei kleinen, rein datenlastigen Systemen reicht oft ER allein. Sobald aber Programmlogik eine größere Rolle spielt, würde ich wirklich beides getrennt betrachten, weil sie unterschiedliche Fragen beantworten. Insofern ist eure Übung schon sehr praxisnah, auch wenn es sich bei einfachen Beispielen wie Kunde/Bestellung/Produkt optisch ähnlich anfühlt.