Systematische Datenmodellierung – eine unterschätze Basis für gute Software

Ist ein adäquates Datenbankmodell heute noch wichtig? Unstrittig ja. Oft starten Softwareprojekte mit dem Datenmodell. Denn darüber lässt sich leicht diskutieren: Wie und wo speichere ich das denn ab? Welche Felder gibt es? Welche Werte gibt es für diese Felder?

Aber ist das der richtige Weg, um eine Softwareentwicklung zu starten? Wahrscheinlich nicht. Abgespeichert und geladen bekommt man die Daten relativ sicher „irgendwie“. Aber viel essenzieller ist das Herz der Software: Die Kundenanforderung, die Domäne, die Funktionen, die Use Cases. Was soll die Software können? Welchen Regeln unterliegt sie? Welche Events gibt es? Was passiert, wenn der User dies und jedes macht? Und wie bekommt man all diese „Geheimnisse“ aus einem Anforderer strukturiert „heraus“? Aber darum soll es in diesem Artikel heute nicht gehen – wir konzentrieren uns heute auf die Datenmodellierung, um ein Datenbankschema zu erarbeiten.

Das Thema Datenmodellierung hat bei der INTENSE einen wichtigen Platz. Wir bewegen uns hauptsächlich im Umfeld klassischer relationaler Datenbanken und großen Mengen von Daten, meist ohne stringente Archivierung. Auch diese Modelle wollen gut entworfen sein.

Aber wie designed man ein Datenmodell?

Oft erleben wir es, dass instinktiv direkt die Entwicklungsumgebung geöffnet wird und sofort eine Datenbank und die Tabellen angelegt werden. Felder hinzugefügt. Felder gelöscht. Felder umbenannt. Denn man kann sich beliebig oft im Laufe der Entwicklung wieder ändern.

Vorbereitung der Datenmodellierung

Aber bei diesem sehr affekthaften Ansatz entgeht dem Team eine riesige Chance: das frühzeitige Erkennen von Problemen. Es bietet sich an, erst einmal nachzudenken, wie man die Daten ablegt, bevor man die Datenbanken und Tabellen erstellt. Bringt man das Ergebnis dieses Prozesses erst einmal (digital) zu Papier, ergibt sich ein weiterer Vorteil: Man kann mit Kolleginnen und Kollegen auf einer abstrakten Ebene diskutieren. Ist das Datenmodell erst in einem konkreten DBMS implementiert, ist es oft schwerer sich einen Überblick zu verschaffen aufgrund des hohen Detailierungsgrades und den impliziten Regeln der Datenbank. Eine grafische Darstellung auf hoher Ebene bietet hingegen eine gute Diskussionsgrundlage.

Welches Werkzeug ist für die Vorbereitung der Datenbankmodellierung hilfreich?

Aus Gewohnheit des Alltags mag man mit Excel liebäugeln. Schließlich hat es doch Tabellen und Spalten. Das passt doch sehr gut. Excel fühlt sich doch schon an wie eine Datenbank. Ja, das ist richtig. Und es ist auch besser als die Option „direkt coden“. Aber es existiert keine Standardnotation. Den Effekt kennt fast jeder: man erhält eine Excel Datei von einer Kollegin oder einem Kollegen als Vorarbeit und soll diese Liste abarbeiten, ergänzen, in eine Software einlesen oder in anderer Weise verarbeiten. Aber es fällt unendlich schwer, denn es ist nicht die eigene Excelliste, sondern die einer anderer Personen. Nach deren Ideen erschaffen und auch mit deren Notation. Was bedeutet die rote Spalte? Wieso ist das fett markiert? Weshalb ist dies sortiert? Ist das eindeutig? Die gemeinsame Basis, die gemeinsame Sprache, die Notation fehlt.

Eine mögliche standardisierte Notation ist die Unified Modelling Language, kurz UML. Viele IT-ler kennen sie zumindest aus dem Studium. Und verwenden sie danach nicht mehr. Eine mögliche Erklärung ist, dass UML auch sehr komplex sein kann. Wenn man die vollen Möglichkeiten der Notation nutzt. Aber es kann auch ein schlanker Ansatz gewählt werden. Der dann ggf. weiter verfeinert wird.

Wir bewegen uns dabei im Bereich einer Erweiterung des UML Standardmodells, dem UML Data Model Profile:

Geht man diesen Weg mit UML, dann kann gemeinsam im Team leicht über das Datenbankdesign und -schema gesprochen werden. Oder sogar gemeinsam modelliert werden.

Datenmodellierung in der Praxis

Diesen Ansatz fördern wir bei INTENSE in einem Workshop „Relationales Datenbankdesign in der Praxis“. Wir haben die Erfahrung gemacht, dass gemeinsames praktisches Arbeiten mehr Lerneffekt bietet als Folien über Folien und Monologe.

Bei praktischen Übungen gab es aber in der Vergangenheit zwei Probleme:

Es war teilweise ein hohes Domänen-KnowHow notwendig, welches nicht alle Teilnehmerinnen und Teilnehmer hatten, da sie z. B. aus anderen Branchen kamen.
Wir nutzten Übungen aus dem Studium, die eigentlich zu einfach oder schon bekannt waren. Bibliotheken sind ein beliebtes Beispiel an verschiedenen Hochschulen.

Daher haben wir uns entschieden, unsere Übungen, wie auch die Coding Katas in den Ninja Times, in einer recht neutralen Domäne aufzusetzen. Wir designen in einer Domäne von denen wahrscheinlich jeder ein grobes Grundverständnis hat – oder eben sehr wahrscheinlich niemand tiefgreifendes Wissen hat. Wir erarbeiten uns potenzielle Datenmodelle für bereits existierende Apps oder Spiele.

Team-Training für die Datenmodellierung – so geht´s

Die Teilnehmerinnen und Teilnehmer erhalten am Anfang des Workshops eine Minimal-Einführung in UML und ein online-Modellierungstool an die Hand. Wir nutzen hierbei Lösungen wie draw.io, die ohne Installation für jeden verfügbar sind. Anschließend wird die Business-Anforderung verteilt – ein Dokument mit ca. 10 Seiten, das viele Informationen enthält. Viele wichtige, aber auch viele für ein Datenmodell absolut unwichtige. Darüber hinaus noch Anforderungen von Stakeholdern.

Nachdem die Business-Anforderung gelesen wurde, kann das Team beginnen zu modellieren. Meist wird erst einmal diskutiert, wo angefangen wird. Ein wichtiger Punkt: Was ist denn der wichtigste Teil der Software. Was hängt wovon ab?

Der Moderator hat hier die Aufgabe, das Team etwas zu lenken, meist durch aktives Hinterfragen, aber auch selbst Fragen zu beantworten. Oft ist aber auch die Antwort auf die Fragen des Teams: „Wissen wir noch nicht, überlegt euch eine Annahme“ oder „Bitte lest die Anforderung genauer“. Dabei ist es wichtig zu wissen, dass es keine vorgefertigte Lösung gibt, auf die hingearbeitet werden soll. Es sind viele verschiedene Lösungen möglich. Über deren Qualität und Vor- und Nachteile innerhalb des Workshops diskutiert wird.

Am Ende des Termins steht eine klassische Retrospektive. Lerneffekte aus unseren Retrospektiven sind beispielsweise:

Das Durchführen einer Design-Phase ermöglicht frühzeitig Wissen über das Datenmodell im Team zu verbreiten.
Durch die Arbeit im Team haben wir neue kreative Lösungen gefunden.
Innerhalb des Designs haben wir oft die Tabellen und Tabellenfelder und Datentypen verändert, bis wir zufrieden waren. Hätten wir das mit einer bereits implementierten Datenbank gemacht, hätten wir sehr viel mehr Zeit benötigt.
UML kann auch in Designphasen sinnvoll verwendet werden und nicht nur zur ex-post Architekturdokumentation.

Unser Tipp

Der Workshop umfasst in der Regel einen Zeitraum von zwei Stunden. Das ist auch ausreichend für die gewünschten Lerneffekte und auch oft das Konzentrationslimit des Teams. Als guter Weg haben sich gemischte Gruppen mit ca. 5 Personen erwiesen. Auch Kolleginnen und Kollegen, die keinen tiefen IT-Hintergrund haben, nehmen die Notation schnell auf und können aktiv mitdiskutieren und -modellieren.

Der Autor

Dominik Panzer

Dominik verantwortet als Entwicklungsleiter die technische Produktentwicklung der Intense AG und unterstützt Teams als Technical Agile Coach in den Bereichen Prozesse, Testautomatisierung, Methodiken und Clean Code. Er ist Initiator der Clean Code Advocate Initiative der INTENSE AG.