Kurzanleitung zur Benutzung des PowerDesigners
- 1 Check Model
- 2 Generierung der Modelle
- 3 Generierung des SQL-DDL-Scripts
- 4 Bearbeitung der Modelle
- 5 Meta-Daten im Repository
- 6 Re-Engineering von relationalen Schematas
- 7 Export der Diagramme
Das CASE-Tool Power Designer unterstützt Modell-Typen (Model Types) unterschiedlichster Kategorien (Categories). Einen neuen Modell-Typ kann man über das Menü File → New Model … auswählen. Zur Verwendung für die relationale Datenmodellierung arbeiten wir mit den Modell-Typen
- Conceptual Data
- UML Class Diagram
- Logical Data
- Physical Data
der Kategorie Information:
Zur Modellierung von Datenbanken beschreibt diese Anleitung zwei Workflows:
- Modellierung eines eER-Diagramms, welches in ein Relationenmodell überführt wird
- Modellierung eines UML-Klassendiagramms, welches in ein Relationenmodell überführt wird
Workflow eER zu Datenbank
Vom conceptual data model (cdm) generieren wir über das logical data model (ldm) und das physical data model (cdm) ein SQLSkript:
Hinweis: Je nach Anwendungsfall kann aus dem cdm auch direkt ein pdm generiert werden. Der Schritt über die logische Ebene (ldm) wird dann übersprungen.
- konzeptionellen Ebene (in Anlehnung an die eER-Modellierung): Modus Conceptual Data Model, gespeicherte Modelle haben die Extension *.cdm
- logische Ebene (in Anlehnung an ein „erweitertes“ Relationenmodell): Modus Logical Data Model, gespeicherte Modelle haben die Extension *.ldm
- physische Ebene (in Anlehnung an ein „erweitertes“ Relationenmodell): Modus Physical Data Model, gespeicherte Modelle haben die Extension *.pdm
- SQL-DDL-Skript zur Erzeugung des Datenbankschemas auf einem Datenbankserver: Hierbei werden die wichtigsten auf dem Markt vertretenen DBMS mit unterschiedlichen Release-Ständen unterstützt. Konvention für die Skript-Extension *.sql
Workflow UML-Klassendiagramm zu Datenbank
Vom UML-Klassendiagramm (oom) generieren wir das physical data model (pdm) und aus diesem anschließend ein SQLSkript:
Hinweis: Ein UML-Klassendiagramm sieht in der Regel die Verwendung von Primärschlüsseln bzw. primary identifier nicht vor. Für diesen Anwendungsfall, also die Generierung eines Relationenmodells, ist dies allerdings erforderlich.
Hierzu müssen Sie die Properties des gewünschten Attributs öffnen:
Und anschließend im Reiter "Detail" den Haken bei "Primary Identifier" setzen:
1 Check Model
Ein fertiges Modell sollte, insbesondere vor der Generierung eines weiteren darauf basierenden Modells, vorher überprüft werden. Jeder Check muss mit „0 errors“ und sollte – idealerweise - mit „0 warnings“ abgeschlossen werden. Werden Warnings ignoriert, dann sollte zumindest verstanden werden, wie sie zustande kamen.
Tools → Check Model
Tipp: Im PowerDesigner ist es nicht möglich in einem Modell mehrere Attribute mit demselben Namen zu haben, auch nicht wenn diese sich in unterschiedlichen Entitäten befinden. Achten Sie daher darauf, wie Sie ihre Attribute benennen. Andernfalls geht der PowerDesigner davon aus, dass es sich um dasselbe Attribut handelt und es kommt spätestens beim Check Model zu Fehlern. Außerdem können auch nicht richtig gelöschte Komponenten Probleme verursachen. Hierfür siehe Meta-Daten im Repository.
2 Generierung der Modelle
2.1 ldm - logical data model
Ein ldm kann aus einem cdm generiert werden. Hierfür sollte zunächst überprüft werden, ob das cdm fehlerfrei ist mittels Check Model. Ist das der Fall, kann das ldm generiert werden:
Tools → Generate Logical Data Model
Es empfiehlt sich, immer Generate new Logical Data Model zu wählen und ggf. ein bereits existierendes Modell dafür vorher zu löschen, da es bei einem Update, insbesondere bei Umbenennungen von Attributen und Entitäten, zu Problemen kommen kann.
2.2 pdm - physical data model
Ein pdm kann aus einem cdm, ldm oder oom generiert werden. Hierfür sollte zunächst überprüft werden, ob das Quellmodell fehlerfrei ist mittels Check Model.
Ist das der Fall, kann das pdm generiert werden. Als DBMS wählen Sie PostgreSQL 9.x aus:
Tools → Generate Physical Data Model
Es empfiehlt sich, immer Generate new Physical Data Model zu wählen und ggf. ein bereits existierendes Modell dafür vorher zu löschen, da es bei einem Update, insbesondere bei Umbenennungen von Attributen und Entitäten, zu Problemen kommen kann.
3 Generierung des SQL-DDL-Scripts
Um eine Datenbank zu erstellen, die Tabellen gemäß der Modellierung enthält, muss aus einem pdm ein SQL-DDL-Script generiert werden. Dabei werden die Datentypen und SQL-„Dialekte“ des ausgewählten DBMS berücksichtigt. Das generierte SQL-Skript kann auf dem Zielsystem genutzt werden, um das Datenbankschema zu generieren. Hierfür sollte zunächst überprüft werden, ob das pdm fehlerfrei ist mittels Check Model. Ist das der Fall, kann das Script generiert werden. Achten Sie darauf, dass Sie als Speicherort ein Directory auswählen, auf welches Sie Schreibrechte besitzen, denn das ist bei der üblichen Voreinstellung des Windows-Programmdirectories nicht der Fall.
Database → Generate Database
4 Bearbeitung der Modelle
4.1 cdm - conceptual data model
Die wichtigsten grafischen Komponenten der Toolbox zur konzeptionellen Datenmodellierung sind
- Entity
- Relationship
- Inheritance (Supertyp-/Subtyp-Hierarchie)
Jede der grafischen Komponenten kann nach Markierung und Doppelklick auf Registerkarten detailliert beschrieben und bearbeitet werden:
- Entities erhalten Attribute, ggf. als Identifier (primary key)
- Relationships werden über ihre Kardinalitäten und Abhängigkeiten näher beschrieben (identifizierend = dependent) und können auch Attribute enthalten
- Inheritance-Beziehungen enthalten unterschiedliche Optionen zur physischen Implementierung und zur Vererbung wählen.
Achtung: Auf dieser Ebene werden noch keine physischen Referenzen in Form von Foreign-Key Spalten angegeben!
4.2 oom - object oriented model
Die wichtigsten grafischen Komponenten der Toolbox für das UML-Klassendiagramm sind
- Klasse
- Vererbung
- Assoziation
- Aggregation
- Kompostion
Jede der grafischen Komponenten kann nach Markierung und Doppelklick auf Registerkarten detailliert beschrieben und bearbeitet werden:
- Klassen erhalten Attribute, ggf. als Identifier (primary key)
- Inheritance-Beziehungen enthalten unterschiedliche Optionen zur physischen Implementierung und zur Vererbung wählen.
Achtung: Auf dieser Ebene werden noch keine physischen Referenzen in Form von Foreign-Key Spalten angegeben!
4.3 ldm - logical data model
Die wichtigsten grafischen Komponenten der Toolbox zur logischen Datenmodellierung sind
- Entity
- Relationship
- Inheritance (Supertyp-/Subtyp-Hierarchie)
Jede der grafischen Komponenten kann nach Markierung und Doppelklick auf Registerkarten detailliert beschrieben und bearbeitet werden:
- Entities erhalten Attribute, ggf. als Identifier (primary key)
- Relationships werden über ihre Kardinalitäten und Abhängigkeiten näher beschrieben (identifizierend = dependent) und können auch Attribute enthalten
- Inheritance-Beziehungen enthalten unterschiedliche Optionen zur physischen Implementierung und zur Vererbung wählen.
Im Gegensatz zur konzeptionellen Datenmodellierung können hier auch Foreign Keys definiert werden, bzw. sie werden bei der Generierung eines ldm aus einem cdm automatisch hinzugefügt.
4.4 pdm - physical data model
Das Tool generiert aus dem konzeptionellen oder logischen Modell ein physisches Datenmodell im Hinblick auf ein ausgewähltes DBMS (Datentypen, SQL-„Dialekte“ etc.). Die wichtigsten grafischen Komponenten, die ggf. mit Hilfe der Toolbox ergänzt werden können:
- Table
- Reference
- View
Auch hier können die grafischen Komponenten wieder nach Markierung und Doppelklick auf Registerkarten bearbeitet werden:
- Tables enthalten Columns (Spalten), denen Primary-Key- und / oder Foreign-KeyConstraints als Implementierung der Relationships aus dem konzeptionellen bzw. logischen Modell zugeordnet sind.
5 Meta-Daten im Repository
Zu allen drei Modellen findet man die Einträge des Repositorys unter dem Menüpunkt Model. Je nach Modell werden andere Metadaten angezeigt, nachfolgends vom cdm, ldm und pdm:
In diesem Menü können insbesondere nachträglich Komponenten gelöscht bzw. bearbeitet werden, wenn es z.B.
- nicht vollständig gelöschte Komponenten gibt aus geänderten Diagrammen, oder
- Konflikte mit gleichlautenden, synthetisch generierten Bezeichnern (z.B. von FK-Constraints).
6 Re-Engineering von relationalen Schematas
Neben dem Aufbau von Datenmodellen unterstützt das Tool auch das Re-Engineering, indem entweder eine Verbindung zum DB-Server hergestellt wird, sodass das Tool die Daten aus dem Systemkatalog auslesen kann, oder indem man dem Tool das DDL-Skript zur Generierung der DB-Struktur zur Verfügung stellt:
File → Reverse Engineer Database …
Dadurch kann aus einer bestehenden Datenbank ein Modell generiert werden.
7 Export der Diagramme
Es besteht die Möglichkeit, die Grafiken der Datenmodelle ganz oder ausschnittsweise als *.emf, *.bmp, *.jpg etc. zu extrahieren:
Edit → Select All und anschließend Edit → Export.