Oracle Designer vs. SQL Developer Data Modeler

Transkript

1 Oracle Designer vs. SQL Developer Data Modeler Gerd Volberg OPITZ CONSULTING GmbH Gummersbach Schlüsselworte: ERD, ER-Modell, Datenmodell, Oracle Designer, SQL Developer, Data Modeler Einleitung In diesem Vortrag werden die Tools Oracle Designer (kurz OD) und SQL Developer Data Modeler (kurz SDDM) miteinander verglichen. Beide Tools unterstützen die Modellierung vom ER-Modell über das Datenmodell bis hin zum automatischen Erzeugen der DB-Skripte. Die Ergebnisse werden in einer Liste am Ende des Dokumentes aufgeführt. Diese Daten zeigen die Stärken und Schwächen der einzelnen Tools. Das darauf folgende Resümee rundet den Vortrag ab. Um Vergleichswerte zu bekommen wurde die Modellierung des guten alten Scott-Tiger-Schemas gewählt. Dieses wurde zuerst modelliert, danach überführt ins Datenmodell und zum Schluss wurden die DB-Skripte generiert. Darüber hinaus gibt es noch einen Bereich Wartung, der die Themen abdecken soll, die nach Einführung eines Projektes typisch sind, wie Erweiterungen am Datenmodell, Spalten vergrößern, Spalten hinzufügen, usw. Domänen Bevor man mit dem Datenbank-Design startet, sollte man sich überlegen, welche Domänen man benötigt. Domänen sind fest definierte Datentypen für bestimmte Spalten. Beispielsweise wird in den EMP- und DEPT-Tabellen ein Primary Key benötigt mit dem Datentyp NUMBER (4). Diese Domäne wird ab sofort D_ID heißen und ist NUMBER (4). OD: Domänen können z.b. im Design Editor erstellt. Auf dem Knotenpunkt der Domänen kann man in einem kontextsensitiven Menü (rechte Maustaste) Create Domain anklicken und in einem einfachen Dialog den Namen eingeben und einen Datentyp wählen. Ein Klick auf Finish speichert die neue Domäne. Bewertung der Domänen: 8. Abb. 1: Domänen im OD-Design Editor

2 SDDM: Hier gibt es nur selten kontextsensitive Menüs. Deswegen muss man in der Baumstruktur ein wenig suchen, bis man entdeckt, wie man neue Domänen hinzufügt. Unter Tools / Domain Administration startet man eine eigene Applikation, die für die Verwaltung zuständig ist. Neue Domänen müssen explizit mit Apply hinzugefügt und danach mit Save gespeichert werden, andernfalls droht Datenverlust! Bewertung der Domänen: 3. Abb. 2: Domänen im SDDM ER-Modellierung OD: Initial startet man im Front Panel und meldet sich auf der Datenbank an, in der das Repository gespeichert ist. Alle Informationen zum ER-Modell, zum Datenmodell und zu allen anderen Objekten werden hier zentral gespeichert. Jetzt startet man den ER- Diagrammer, hier lassen sich in einer graphischen Oberfläche Entitäten definieren. Primary Keys und Foreign Keys werden als Attribute nicht definiert, da sie bei der Transformation automatisch erzeugt werden. Bewertung der ER-Modellierung: 6. Abb. 3: ER-Diagramm im OD SDDM: Im Bereich Logical erzeugt man eine neue SubView, in der dann das ER- Diagramm modelliert wird. Hilfreich ist, dass man hier nicht in ein anderes Tool verzweigen muss und alles auf einen Blick sieht.

3 Achtung: Beim Modellieren von Unique Keys sollte man im Attribute-Dialog besser nicht auf Apply drücken. Die linke Seite des Attribute-Shuttles verlöre dann alle Attribute, Relationen blieben dagegen erhalten. Der Shuttle funktioniert noch nicht intuitiv, da nur die Buttons zwischen den beiden Fenstern funktionieren, Doppelklicks oder Drag&Drop jedoch nicht. Gut gelöst wurde die Foreign-Key-Problematik. Die Attribute, die erst später im Datenmodell hinzugefügt werden, sind bereits im ER-Modell sichtbar. Sie werden als nichteditierbare Attribute in der Entity angezeigt und gleichzeitig im ER-Modell ausgeblendet. Primary-Key-Attribute müssen explizit definiert werden, weil sie sonst nicht ins Datenmodell transferiert werden. Bewertung der ER-Modellierung: 7. Abb. 4: ER-Diagramm im SDDM ER-Modell in ein Datenmodell überführen OD: Die Überführung ins Datenmodell wird vom Database Design Transformer gesteuert. Dieser zeigt in einer Listenansicht alle Entitäten an, sowie die zugehörigen Objekte des Datenmodells, sofern es sie schon gibt. Über den Button Settings kann man die Transformationsregeln bestimmen, die genutzt werden sollen. Hier sollte die Einstellung Surrogate Keys aktiviert werden, damit jede neue Tabelle automatisch einen Primary Key bekommt. Ansonsten hätte dieser Schlüssel schon als Attribut definiert werden müssen. Daneben wird eine Domäne angeboten, die als Datentyp für diesen Primary Key genutzt werden soll. Auf der nächsten Registerkarte gibt es noch Optionen zur Steuerung von Präfixen. Bewertung der Transformation: 7. SDDM: Alle Entitäten, die in Tabellen überführt werden sollen, markiert man und benutzt dann die Funktion Engineer to Relational Model. Der folgende Dialog zeigt alle Entitäten auf der linken und Tabellen auf der rechten Seite, die zueinander passen. Auch Tabellen, die noch nicht existieren, werden hier in einer Art Preview dargestellt Ein klarer Vorteil gegenüber dem OD.

4 Wichtig ist in den General Options der Punkt Apply Name Translation. Dadurch werden die Entity-Abkürzungen zu den Tabellennamen. Ansonsten würde der Entity- und der Tabellenname gleich lauten. In der klassischen ER-Modellierung nutzt man den Singular eines Objektes für den Entity-Namen und den Plural für den Tabellennamen. Z.B. Entity AUFTRAG und Tabelle AUFTRAEGE. Bewertung der Transformation: 5. Hier ein kurzer Überblick, wie Objekte transformiert werden, und wie sie im jeweiligen Tool benannt werden: Beide Tools Oracle Designer SQL Developer Data Modeler ER-Modell Entity Attribute Unique Identifier Entity-Shortname Entity-Name Entity-Plural Relationship Entity-Short Name Entity-Name Entity-Preferred Abbreviation Relation Datenmodell Table Column Unique Key Table-Alias Table-Name Foreign Key Table-Abbreviation Table-Name Foreign Key Datenmodellierung Die automatisch erzeugten Tabellen müssen nun ein wenig überarbeitet werden. Im Repository wurden automatisch Spalten für die Primary- und Foreign-Keys angelegt, die ein _ID im Namen tragen. Dies wird nun explizit auf die Endung NO umgestellt, da die Spalten EMPNO und DEPTNO heißen müssen. Das Datenmodell wird im Design Editor überarbeitet. Dieses Tool ist optimal dazu geeignet, Tabellen-, View-, Trigger- und Sourcecode-Änderungen zu modellieren, zu verwalten und zu editieren. Bewertung der Datenmodellierung: 9.

5 Abb. 5: Datenmodell im OD Im SDDM gibt es jeweils eine automatisch erzeugte Spalte für die beiden Foreign Keys, DEPTNO und EMPNO1. Letzterer ist die Selbstreferenz auf sich selbst, die nun den Namen MGR bekommt. Bewertung der Datenmodellierung: 8. Abb. 6: Datenmodell im SDDM Beiden Tools merkt man an, dass sie ihre Stärken im Bereich der reinen Datenmodellierung haben. Die Dialoge und Layout-Möglichkeiten sind hier ausgereifter und durchdachter Datenmodell in Skripte überführen Im Oracle Designer kann man Skripte sehr effizient erzeugen. Entweder markiert man die Objekte, die generiert werden sollen und klickt mit der rechten Maustaste auf Generate oder es werden Database-Objekte gebildet, zu denen alle Objekte verlinkt werden, die in einem Generierungslauf erzeugt werden sollen. Bei beiden Methoden kann man im Generate-Dialog auswählen, ob die Skripte für eine leere Datenbank generiert oder ob sogenannte Delta-Skripte erzeugt werden. Diese Skripte

6 arbeiten auf Basis von Alter Table und erzeugen z.b. nur die Columns neu, die nachträglich noch hinzugefügt werden sollten. Wichtiger erscheint mir in diesem Zusammenhang jedoch, dass jeglicher Sourcecode in Form von Stored Procedures, Stored Functions oder Stored Packages erzeugt werden kann. Typ- Deklarationen oder DB-Trigger sind ebenfalls möglich. Bewertung Skripte erzeugen: 9. Im Data Modeler sind die Fähigkeiten zum automatischen Erzeugen von Skripten sehr begrenzt. Initiale Create-Statements sind kein Problem und auch sehr schnell zu erzeugen, jedoch fehlt die komplette Palette zur Erzeugung von Stored-DB-Objekten. Die Erzeugung von Deltaskripten ist möglich, aber nur mit Mühe zu entdecken. Delta-Skripte können erzeugt werden, indem unter File / Import / Data Dictionary der Import Wizard gestartet wird. Hier klickt man die Objekte an, die in der Datenbank geändert werden sollen. Im letzten Schritt gibt es eine kleine Checkbox Swap Target Model, die angeklickt werden muss. Danach startet ein Merge-Vorgang. Dieser Dialog zeigt einem dann die DDL-Skripte an, die zum Beispiel Alter Table -Statements gegen die Datenbank starten. Bewertung Skripte erzeugen: 6. Kapselung der Objekte Der OD arbeitet intern mit sogenannten Applikations-Systemen, in denen die Entitäten und Tabellen abgespeichert werden. Diese Gruppierung hat den Vorteil, dass man nur mit den Entitäten oder Tabellen arbeitet, die für eine bestimmte Applikation wichtig sind. Bewertung der Kapselung: 7. Im SDDM werden sogenannte Designs gespeichert. Die Entitäten und Tabellen werden hier im logischen, bzw. relationalen Teil des Designs gespeichert. Im relationalen Modell, nicht zu verwechseln mit dem ER-Modell, können mehrere Modelle unter dem eigenen Namen gespeichert werden. Diese Aufsplittung von Tabellen führt m. E. nicht zu dem gewünschten Ziel, nämlich, dass in einem Design alle Objekte einer Applikation liegen. Vielmehr verführt diese Funktion dazu, die Entitäten aller Applikationen in einem Design zu halten und in diesem Design dann so viele relationale Modelle anzulegen, wie es Applikationen gibt. Durch diese Kopplung entfernt man sich von dem Ziel, ein XML-Repository pro Applikation zu besitzen. Bewertung der Kapselung: 5. Reverse Engineering Der Oracle Designer ist in der Lage eine komplette Datenbank mit allen Objekte reverse in das eigene Repository zu schreiben. Diese Aktion kann schon mal eine Nacht dauern. Dafür ist aber dann das gesamte Datenmodell samt aller Sourcecodes in einem Applikationssystem enthalten und kann überarbeitet werden. Bewertung des Reverse Engineering: 8. Der Data Modeler kann Tabellen, Views und einige andere Objekte importieren, jedoch keinerlei Sourcecode. 500 Tabellen und Views benötigen z.b. beim Import nur wenige Sekunden. Bewertung des Reverse Engineering: 7.

7 Zukunftssicherheit Hier gibt es für den Oracle Designer die schlechtesten Noten. Er wird seit einigen Jahren nicht mehr weiterentwickelt und unterstützt viele Neuerungen aus der Oracle 10g und 11g nicht mehr. Teilweise wird dies kompensiert durch das Oracle Designer Development Kit von Jonathan Wallace (Oracle Australien). Dieses Toolkit kann über User-Extensions beliebige neue Objekte erzeugen, die über einen komplizierten Mechanismus bei der Skript- Generierung genutzt werden können. Dank dieses Toolkits kann man zumindestens große Projekte, in denen der Designer genutzt wird, noch lange weiterleben lassen. Bewertung der Zukunftssicherheit: 2. Der SQL Developer Data Modeler ist zurzeit das einzige Oracle ERM-Tool. Da alle Weiterentwicklungen in dieses Tool gesteckt werden, ist zu erwarten, dass es stetig verbessert wird. Bewertung der Zukunftssicherheit: 7. Stärken und Schwächen Als Bewertungssystem wird eine Skala von 1-10 benutzt. 10 steht dabei für hervorragend. Kapitel Oracle Designer SQL Developer Data Modeler Domänen 8 3 ER-Modellierung 6 7 ER-Modell in ein Datenmodell überführen 7 5 Datenmodellierung 9 8 Datenmodell in Skripte überführen 9 6 Kapselung der Objekte 7 5 Reverse Engineering 8 7 Zukunftssicherheit 2 7 Resümee Fast alle hier beschriebenen Punkte sprechen für den guten alten Oracle Designer, außer dem nicht unwesentlichen Thema Zukunftssicherheit. Dies ist sicherlich ein sehr wichtiger Aspekt, der nicht leichtfertig abgetan werden kann. Jedoch können die vielen positiven Features des Oracle Designers in den meisten Projekten die Effizienz so stark erhöhen, dass der Einsatz immer noch zu rechtfertigen ist. Ich hoffe an dieser Stelle, dass Oracle mit Hochdruck an den Themen Stored Packages, Stored Functions und Stored Procedures und Verbesserung der Usability arbeiten wird, damit der Data Modeler eines Tages genau so leistungsfähig sein wird wie der Oracle Designer und auch in der Wartungsphase einer Applikation effizient genutzt werden kann. Viel Spaß beim Modellieren Gerd Volberg

8 Kontaktadresse: Gerd Volberg OPITZ CONSULTING GmbH Kirchstr. 6 D Gummersbach Telefon: +49(0) Fax: +49(0) gerd.volberg@opitz-consulting.com Blog: