Java-Persistenz mit Hibernate

8 Legacy-Datenbanken und eigenes SQL (S. 285-286)

Die Themen dieses Kapitels:

Integration von Legacy-Datenbanken und knifflige Mappings
Anpassung von SQL-Anweisungen
Verbesserung des SQL-Schemas mit eigener DDL

Bei vielen Beispielen in diesem Kapitel geht es um „schwierige" Mappings. Das erste Mal wenn Sie Probleme mit dem Erstellen eines Mappings bekommen, wird wahrscheinlich sein, wenn das Datenbankschema eines Legacy-, also eines Altsystems nicht verändert werden kann. Wir besprechen typische Probleme, auf die Sie bei einem solchen Szenario stoßen werden, und wie Sie Ihre Mapping-Metadaten anpassen können, statt Ihre Applikation oder das Datenbankschema zu verändern.

Wir zeigen Ihnen auch, wie Sie das von Hibernate automatisch generierte SQL überschreiben können. Dazu gehören SQL-Abfragen, DML-Operationen (Create, Update, Delete) und auch die automatische DDL-Generierung von Hibernate. Sie erfahren, wie Stored Procedures und benutzerdefinierte SQL-Funktionen gemappt werden und wie Sie die richtigen Integritätsregeln in Ihrem Datenbankschema anwenden. Dieser Abschnitt wird besonders dann nützlich sein, wenn Ihr Datenbankadministrator die vollständige Kontrolle braucht (oder wenn Sie selbst der DBA sind und Hibernate auf SQL-Ebene optimieren wollen). Wie Sie sehen, sind die Themen dieses Kapitels breit gestreut, Sie brauchen nicht alles am Stück zu lesen. Sie können einen Großteil dieses Kapitels als Referenzmaterial betrachten und darauf zurückgreifen, wenn ein bestimmtes Problem auftritt.

8.1 Integration von Datenbanken aus Altsystemen

In diesem Abschnitt decken wir hoffentlich alle die Eventualitäten ab, auf die Sie bei der Arbeit mit einer vorhandenen Altsystem-Datenbank oder (und das ist oft das Gleiche) einem eigenartigen bzw. kaputten Schema arbeiten müssen. Wenn Ihr Entwicklungsprozess Top-down ist, können Sie diesen Abschnitt jedoch überspringen. Darüber hinaus empfehlen wir Ihnen, dass Sie zuerst alle Kapitel über Klassen-, Collection- und Assoziations- Mappings lesen, bevor Sie versuchen, mit Reverse Engineering ein komplexes Legacy- Schema anzugehen.

Wir müssen Sie warnen: Wenn Ihre Applikation ein vorhandenes Legacy-Datenbankschema erbt, sollten Sie an diesem Schema normalerweise so wenig Änderungen wie möglich vornehmen. Jede Änderung daran könnte andere vorhandene Applikationen beeinträchtigen, die auf die Datenbank zugreifen. Möglicherweise müssen Sie auch eine kostspielige Migration vorhandener Daten in Betracht ziehen. Im Allgemeinen ist es nicht möglich, eine neue Applikation zu erstellen und keine Änderungen am vorhandenen Datenmodell zu machen – eine neue Applikation bedeutet normalerweise zusätzliche Business-Anforderungen, die naturgemäß eine Weiterentwicklung des Datenbankschemas nach sich zieht. Wir werden von daher zwei Arten von Problemen betrachten: solche, die mit den sich verändernden Business-Anforderungen zu tun haben (die im Allgemeinen nicht ohne Überarbeitung des Schemas gelöst werden können), und solche, die sich nur darauf beziehen, wie Sie das gleiche Business-Problem in Ihrer neuen Applikation repräsentieren wollen (gewöhnlich kann das ohne Änderungen am Datenbankschema gelöst werden, aber nicht immer).

Es sollte klar sein, dass die erste Art von Problemen schon erkennbar wird, wenn man sich nur das logische Datenmodell anschaut. Die zweite bezieht sich häufiger auf die Implementierung des logischen Datenmodells als physisches Datenbankschema. Wenn Sie diesen Beobachtung zustimmen, merken Sie, dass Schemaveränderungen bei folgenden Problemen erforderlich sind: Einfügen neuer Entities, Refakturierung vorhandener Entities, Einfügen neuer Attribute bei vorhandenen Entities und Überarbeitungen der Assoziationen zwischen Entities. Bei den ohne Schemaveränderungen lösbaren Problemen geht es gewöhnlich um unpraktische Tabellen- oder Spaltendefinitionen für eine bestimmte Entity. In diesem Abschnitt konzentrieren wir uns auf diese Art Probleme.

Wir gehen davon aus, dass Sie bereits ein Reverse Engineering des vorhandenen Schemas mit dem Hibernate Toolset probiert haben, wie wir es in Kapitel 2, Abschnitt 2.3 „Reverse Engineering einer Legacy-Datenbank", beschrieben haben. Die Konzepte und Lösungen, die in den folgenden Abschnitten vorgestellt werden, gehen davon aus, dass Sie ein grundlegendes objekt-relationales Mapping etabliert haben und zusätzliche Änderungen machen müssen, um es ans Laufen zu kriegen. Alternativ können Sie versuchen, das Mapping ohne Tools fürs Reverse Engineering komplett per Hand zu schreiben. Fangen wir mit dem offensichtlichsten Problem an: den Legacy-Primärschlüsseln.