Datenbank-ER-Diagramme in PhpStorm automatisch generieren

1. Warum ER-Diagramme beim Einarbeiten helfen

Ein typisches Magento-2-Schema umfasst je nach installierten Modulen zwischen dreihundert und über tausend Tabellen, viele davon mit kryptischen, historisch gewachsenen Namen wie sales_order_item oder catalog_product_entity_decimal. Wer neu in ein Projekt einsteigt, verliert sich schnell beim Versuch, allein aus dem Quellcode oder aus db_schema.xml-Dateien nachzuvollziehen, welche Tabellen tatsächlich zusammenhängen und über welche Spalten sie verknüpft sind.

Ein automatisch generiertes ER-Diagramm macht diese Beziehungen auf einen Blick sichtbar, ohne dass jemand sie von Hand pflegen oder aktuell halten muss. Weil das Diagramm direkt aus der laufenden Datenbank abgeleitet wird, spiegelt es immer den tatsächlichen Ist-Zustand wider, inklusive aller nachträglich per Modul-Setup oder Custom-Script hinzugefügten Tabellen, die in keiner offiziellen Dokumentation mehr auftauchen.

2. Datenquelle in PhpStorm einrichten

Voraussetzung für jedes Diagramm ist eine funktionierende Datenbankverbindung im Database-Tool-Fenster. Bei einem Mark-Shust-Docker-Setup läuft MySQL oder MariaDB in einem eigenen Container, dessen Port über docker compose meist auf einen lokalen Port wie 3306 oder einen individuellen Port gemappt ist. In PhpStorm legt man über das Database-Panel eine neue Data Source vom Typ MySQL an und trägt Host, Port, Benutzername und Passwort aus der env.php oder den Docker-Compose-Umgebungsvariablen ein.

Nach dem Testen der Verbindung fragt PhpStorm, welche Schemas synchronisiert werden sollen, was bei einem einzelnen Magento-Schema unkompliziert ist. Für Projekte mit mehreren Stores oder Umgebungen in getrennten Datenbanken lohnt sich eine eigene Data Source pro Umgebung, damit im Diagramm später eindeutig ist, ob man die lokale Entwicklungsdatenbank oder einen Dump der Staging-Umgebung betrachtet.

PhpStorm: Database-Panel -> + -> Data Source -> MySQL

Host:     127.0.0.1
Port:     3306   (siehe docker compose port mapping, z.B. "3306:3306")
Database: magento
User:     magento
Password: aus src/app/etc/env.php (db -> connection -> default)

Test Connection -> OK -> Schemas auswaehlen -> Apply

3. Ein Diagramm generieren

Sobald die Data Source synchronisiert ist, reicht ein Rechtsklick auf das Schema oder eine Auswahl mehrerer Tabellen im Database-Baum, gefolgt von Diagrams, Show Visualization, um ein Diagramm zu öffnen. PhpStorm zeichnet dabei automatisch alle Tabellen samt Spalten, Primärschlüsseln und erkannten Fremdschlüssel-Beziehungen als verbundene Kästen, die sich frei verschieben und per Mausrad zoomen lassen.

Für ein komplettes Magento-Schema mit über tausend Tabellen ist ein Diagramm über alles selten sinnvoll, weil die grafische Darstellung dann unlesbar wird. Praktikabler ist es, gezielt eine Handvoll thematisch zusammenhängender Tabellen im Baum per Strg-Klick auszuwählen, etwa alle sales_order-Tabellen, und nur für diese Auswahl ein Diagramm zu erzeugen, das sich dann auf eine überschaubare Fläche beschränkt.

4. Magento-EAV-Struktur visualisieren

Magentos EAV-Modell (Entity-Attribute-Value) ist ein klassischer Stolperstein für neue Entwickler: Ein Produkt besteht nicht aus einer einzigen breiten Tabelle mit allen Attributen als Spalten, sondern aus catalog_product_entity plus einer Handvoll typspezifischer Value-Tabellen wie catalog_product_entity_varchar, _int, _decimal und _text, die alle über entity_id und attribute_id verknüpft sind. Im Textformat ist diese Struktur schwer zu greifen, im ER-Diagramm wird das Sternmuster sofort sichtbar.

Bindet man zusätzlich eav_attribute und eav_entity_type in die Auswahl ein, zeigt das Diagramm auch, wie ein Attribut-Code wie color letztlich über die attribute_id mit den passenden Werten in den Value-Tabellen zusammenhängt. Für Entwickler, die zum ersten Mal mit Magentos EAV-Struktur arbeiten, ist dieses eine Diagramm oft der Moment, in dem das Konzept vom abstrakten Begriff zur greifbaren Tabellenlandschaft wird.

5. Beziehungen und Constraints richtig lesen

PhpStorm zeichnet Fremdschlüssel-Beziehungen anhand der tatsächlich in der Datenbank definierten Constraints, wie sie Magentos db_schema.xml über das Element referenceId deklariert und beim Setup-Upgrade als echte FOREIGN-KEY-Constraints anlegt. Das unterscheidet Magento von manch anderem PHP-Framework: Die Fremdschlüssel existieren wirklich auf Datenbankebene und sind nicht nur implizit im Anwendungscode modelliert, weshalb PhpStorms automatische Erkennung hier zuverlässig funktioniert.

Nicht jede logische Beziehung ist jedoch als Constraint hinterlegt, etwa lose Verknüpfungen über gespeicherte IDs ohne referenzielle Integrität in manchen Drittanbieter-Modulen. Solche Beziehungen tauchen im automatisch generierten Diagramm nicht als Linie auf, lassen sich aber nachträglich manuell im Diagramm-Editor als virtuelle Verbindung ergänzen, um die tatsächliche fachliche Beziehung trotzdem sichtbar zu dokumentieren.

6. Filtern nach Tabellenpräfix und Teilbereichen

Der Database-Baum erlaubt eine textbasierte Filterung nach Tabellennamen, was bei Magento sofort nützlich wird: Ein Filter nach sales_ zeigt nur den Bestellprozess, catalog_ nur Produkte und Kategorien, customer_ nur Kundendaten. So lässt sich ein Diagramm gezielt auf den Teilbereich beschränken, der gerade für ein Feature oder einen Bugfix relevant ist, statt sich in tausend unbeteiligten Tabellen zu verlieren.

Für individuelle Module lohnt sich zusätzlich ein Filter auf das eigene Tabellenpräfix, etwa mironsoft_seosuite_, um ausschließlich die selbst geschaffenen Tabellen samt ihrer Verbindungen zu core-Magento-Tabellen wie catalog_category_entity darzustellen. Das ist besonders hilfreich, um im Review zu prüfen, ob ein neues Modul tatsächlich nur über deklarierte Fremdschlüssel und nicht über verstreute, unkontrollierte ID-Referenzen an den Core andockt.

7. Export für die Dokumentation

Ein fertiges Diagramm lässt sich über File, Export Diagram als PNG, SVG oder in einem druckfähigen Layout exportieren. SVG ist meist die bessere Wahl für eine Wiki-Seite oder Confluence-Dokumentation, weil sich das Bild verlustfrei skalieren lässt und auch bei einem großen Diagramm mit vielen Tabellen noch lesbar bleibt, während ein PNG bei starkem Zoom schnell unscharf wird.

Für ein Projekt-Onboarding-Dokument bietet es sich an, mehrere thematisch fokussierte Exporte statt eines einzigen Mega-Diagramms abzulegen, etwa je ein Bild für Bestellprozess, Produktkatalog und Kundenverwaltung. Neue Teammitglieder finden sich dadurch deutlich schneller zurecht als mit einem einzigen, aus der Distanz kaum lesbaren Diagramm über das komplette Schema.

8. Diagramm nach Schema-Änderungen aktuell halten

Weil das Diagramm aus dem aktuellen Datenbankzustand generiert wird, veraltet es automatisch, sobald sich das Schema durch neue Module oder ein Setup-Upgrade ändert. PhpStorm merkt sich zwar die Positionierung der Tabellen in einem bereits erstellten Diagramm, neue Tabellen erscheinen dort aber nicht automatisch, sie müssen nach einem Refresh der Data Source manuell in die bestehende Ansicht gezogen werden.

Ein einfacher Workflow ist deshalb, nach jedem bin/magento setup:upgrade zunächst die Data Source über Rechtsklick, Refresh zu synchronisieren und danach bei Bedarf ein neues, aktuelles Diagramm für den jeweils relevanten Teilbereich zu erzeugen, statt zu versuchen, ein bestehendes Diagramm über Monate hinweg manuell zu pflegen. Der Aufwand für ein frisches Diagramm ist gering genug, dass sich Pflege in den meisten Fällen nicht lohnt.

9. Einsatz im Team und Vergleich zu anderen Werkzeugen

Im Team ersetzt PhpStorms ER-Diagramm keine dedizierte Datenmodellierungs-Software, ist dafür aber ohne zusätzliche Installation direkt in der ohnehin genutzten IDE verfügbar und benötigt keine separate Lizenz oder einen externen Dienst, an den das Schema hochgeladen werden müsste, was gerade bei sensiblen Kundendatenbanken ein Vorteil ist. Für schnelle Ad-hoc-Fragen beim Onboarding oder Debugging ist es damit oft die pragmatischere Wahl.

Die folgende Tabelle vergleicht PhpStorm mit drei gängigen Alternativen für die Magento-Praxis: MySQL Workbench als klassisches, eigenständiges Werkzeug, phpMyAdmin als webbasierte Oberfläche ohne echte Diagramm-Funktion, und dbdiagram.io als externer Cloud-Dienst mit manueller Schema-Eingabe statt automatischer Live-Verbindung.

10. Zusammenfassung

11. FAQ: ER-Diagramme in PhpStorm: Das Wichtigste auf einen Blick