Refactoring von Datenbankschemas mit Liquibase

Software verändert sich, und mit ihr verändern sich die benötigten Datenstrukturen. Komplexe SQL-Skripte sind meist die Folge. Alternativ dazu existiert ein einfach zu erlernendes, aber mächtiges Werkzeug: Liquibase

“Nichts ist so beständig wie der Wandel“. Dieses oftbenutzte Zitat trifft insbesondere auch auf den Lebenszyklus von Software zu. Es ist nahezu unmöglich, eine Anwendung vollständig auf dem Reißbrett zu entwerfen, sie exakt in der geplanten Form umzusetzen und anschließend nicht mehr verändern zu müssen. Neue ebenso wie sich verändernde Anforderungen erzwingen zu verschiedenen Zeitpunkten im Entwicklungsprozess entweder Ergänzungen oder Änderungen, denen praktisch jeder Teil des Systems unterliegt. Der Begriff “Refactoring” hat mittlerweile einen festen Platz im Vokabular der Softwareentwickler gefunden und wird durch Entwicklungsumgebungen für gängige Programmiersprachen sehr gut unterstützt.

Während diese Aussage ohne Einschränkung auf die Programmiersprache Java und ihre Werkzeuge (zum Beispiel Eclipse) angewendet werden kann, klafft ausgerechnet in deren näherem Umfeld eine Lücke: Wie werden Änderungen im Domänenmodell auf Schemas relationaler Datenbanken übertragen, ohne bestehende Strukturen und bereits vorhandene Daten zu zerstören? …

Lesen Sie den vollständigen Artikel hier:
Download DatabasePro, Ausgabe 2/2009, S. 92 – 96

Textuelle Beschreibung von Domänenmodellen

Codex Dresdensis
Im Zuge einer Migration des Persistenz-Frameworks kann es sinnvoll sein, sein bestehendes Domänenmodell in einer Programmiersprache-neutralen Modellierungssprache neu zu erfassen. Dieser Weg bietet sich insbesondere dann an, wenn die bestehenden Klassen des Datenmodells keine Geschäftslogik besitzen oder wenn die enthaltene Geschäftslogik so regelmäßig ist, dass sie abstrakt beschrieben werden kann. Der Aufwand, der durch die Nachmodellierung entsteht, amortisiert sich schnell durch die zusätzlich gewonnene Flexibilität und Code-Qualität.

Für die Modellierung von Domänenmodellen ist meist die UML mit ihren Klassenstrukturdiagrammen die erste Wahl. Doch dieser Weg soll hier nicht beschritten werden. Anstelle der umfangreichen UML soll eine eigene domänenspezifische Sprache entwickelt werden, die für den beschriebenen Anwendungsfall optimiert ist. Als technische Grundlage wird das Framework Xtext aus dem openArchitectureWare-Werkzeugkasten genutzt.

weiterlesen

JDO-JPA-Migrationsstrategien

Wäre dieser Artikel vor fünf Jahren entstanden, dann wäre die Migrationsrichtung der meisten Projekte sicherlich diese: Weg vom reinen JDBC oder weg von Container-Managed-Persistence hin zu JDO. Im Jahre 2003 erscheint mit JDO 1.0.1 ein Jahr nach der Verabschiedung von JDO 1.0 das erste kleinere Update der Spezifikation, welches auf Jahre hin die Basis einer Hand voll kommerzieller O/R-Mapper-Implementierungen bildet. JDO war damals aus architektonischer Sicht, wenn auch manchmal leicht polarisierend, die erste Wahl für die Persistenzstrategie einer Java-Enterprise-Anwendung. Im Vertrauen auf den Standard wurde eine JDO-Implementierung auch gerne anderen kommerziellen, aber nicht-standard-konformen O/R-Mapping-Frameworks vorgezogen. Heute, im Jahr 2008 sieht die Situation anders aus: Auch wenn JDO 2.0 die heute fortschrittlichste O/R-Mapping-Spezifikation für Java darstellt, kann das Interesse an ihr kaum geringer sein. Neue Projekte, die JDO den Vorzug geben, gibt es faktisch nicht mehr und in bestehenden Projekten ist ein gewisser Migrationsdruck weg von JDO zu verspüren. Wie eine solche Migration möglichst reibungslos vonstatten gehen kann, versucht dieser Artikel im Folgenden aufzuzeigen.
weiterlesen