Hibernate Reverse Engineering

Hibernate kann mit seinen Reverse Engineering Tools sehr leicht ein Modell für eine existierende Datenbank erstellen. Aber was ist, wenn diese Datenbank nicht allen Regeln der NormalForm entspricht? Fangen wir zuerst an, wie eine hibernate.reveng.xml-Datei für MS SQL aussieht:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-reverse-engineering PUBLIC "-//Hibernate/Hibernate Reverse Engineering DTD 3.0//EN"
 "http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd" >
<hibernate-reverse-engineering>
  <schema-selection match-schema="dbo" />
</hibernate-reverse-engineering>

Dieser Code legt fest, dass wir immer mit dem dbo-Schema arbeiten wollen. Dies ist bei MS SQL das Standardschema. Nehmen wir jetzt an, dass wir die Tabelle ‚XYZ‘ ausschließen wollen, sprich es soll keine Mappingklasse für diese Tabelle erstellt werden:

  <table-filter match-name="XYZ" exclude="true" />

Damit taucht diese Tabelle nicht mehr auf. Jetzt wollen wir die Spalte ‚abc‘ aus der Tabelle ‚ABC‘ ausschließen:

  <table name="ABC" schema="dbo">
    <column name="abc" exclude="true" />
  </table>

Und die Spalte ‚def‘ der Tabelle ‚ABC‘ hat den falschen Typ (es stehen Zahlen in einer VARCHAR-Spalte):

    <column name="def" type="int" />

Und es fehlt auch noch ein Foreign Key von GHI auf DEF:

  <table name="GHI" schema="dbo">
    <foreign-key foreign-table="DEF" foreign-schema="dbo">
      <column-ref local-column="defId" foreign-column="ID" />
    </foreign-key>
  <table>

Und es gibt zwei Tabellen mit existierenden Foreign Keys, doch Hibernate generiert keinen brauchbaren Namen:

  <table name="GHI" schema="dbo">
    <foreign-key constraint-name="FK_GHI_GFI">
      <column-ref local-column="defId" foreign-column="ID" />
      <many-to-one property="parent" />
      <set property="children"/>
    </foreign-key>
  <table>

Und er Tabelle QWE fehlte der Primary Key:

  <table name="QWE" schema="dbo"> 
    <primary-key> 
       <key-column name="ID" /> 
    </primary-key> 
  </table> 
 

All das simuliert der Modellgenerierung von Hibernate eine Datenbank, die vorhandene Schwächen versteckt, ohne tatsächlich Änderungen an der Datenkbank zu machen (und damit evtl. bestehende Anwendungen zu gefährden). Diese Beispiele veranschaulichen nur einen Teil dessen, wie man mit Hibernate ein brauchbares Datenmodell für eine ‚legacy‘ Datenbank erstellen kann. Ich kann als weitere Lektüre Chapter 6. Controlling reverse engineering empfehlen.

Copyright © christophbrill.de, 2002-2017.