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.

Daniel hat das schon gut erklärt, ich ergänz mal aus der Praxis, wo ich das konkret trenne.

Wenn ich bei uns z.B. ein neues Berichtswesen oder eine reine Datenablage konzipiere (Stammdaten, Bewegungsdaten, Reporting), dann zeichne ich nur ER. Da interessiert mich: Wie sind die Tabellen normalisiert, wo sind die Fremdschlüssel, stimmen die Kardinalitäten. Methoden brauch ich da gar nicht, weil die Logik eh in SQL-Abfragen oder im BI-Tool passiert, nicht "in" den Daten selbst.

Sobald aber eine richtige Anwendung gebaut wird, also z.B. ein Bestellsystem mit Workflow (Bestellung anlegen, prüfen, stornieren, Rechnung erzeugen), reicht ER nicht mehr. Da will man ja auch festhalten: Wer darf was ändern, welche Methode löst welchen Zustandswechsel aus, gibt's Vererbung (z.B. "Geschäftskunde" und "Privatkunde" als Unterklassen von "Kunde" mit unterschiedlichem Verhalten). Das bekommt man mit reinem ER nicht sauber abgebildet, da fehlt einfach die Verhaltensebene. Typischer Ablauf in echten Projekten, die ich kenne: erst fachlich/ER grob klären, was an Daten überhaupt gebraucht wird, dann für die Implementierung der Anwendung das Klassendiagramm bauen, aus dem am Ende die Tabellen per ORM wieder generiert werden. Am Ende landet also vieles doch wieder in einer DB, nur der Weg dahin ist ein anderer.

Merksatz, den ich mir dazu gemerkt hab: ER fragt "was gibt es und wie hängt's zusammen", UML-Klasse fragt zusätzlich "was kann es tun".