|
|
# Kurzanleitung zur Benutzung des PowerDesigners
|
|
|
|
|
|
* [1 Check Model](#1-check-model)
|
|
|
* [2 Generierung der Modelle](#2-generierung-der-modelle)
|
|
|
+ [2.1 ldm - logical data model](#21-ldm---logical-data-model)
|
|
|
+ [2.2 pdm - physical data model](#22-pdm---physical-data-model)
|
|
|
* [3 Generierung des SQL-DDL-Scripts](#3-generierung-des-sql-ddl-scripts)
|
|
|
* [4 Bearbeitung der Modelle](#4-bearbeitung-der-modelle)
|
|
|
+ [4.1 cdm - conceptual data model](#41-cdm---conceptual-data-model)
|
|
|
+ [4.2 ldm - logical data model](#42-ldm---logical-data-model)
|
|
|
+ [4.3 pdm - physical data model](#43-pdm---physical-data-model)
|
|
|
* [5 Meta-Daten im Repository](#5-meta-daten-im-repository)
|
|
|
* [6 Re-Engineering von relationalen Schematas](#6-re-engineering-von-relationalen-schematas)
|
|
|
* [7 Export der Diagramme](#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
|
|
|
* Logical Data
|
|
|
* Physical Data
|
|
|
|
|
|
der Kategorie Information:
|
|
|
|
|
|

|
|
|
|
|
|
Vom conceptual data model (cdm) generieren wir über das logical data model (ldm) und das physical data model (cdm) ein SQLSkript:
|
|
|
|
|
|

|
|
|
|
|
|
* **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
|
|
|
|
|
|
## 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](#5-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](#1-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 oder einem ldm generiert werden. Hierfür sollte zunächst überprüft werden, ob das cdm bzw. ldm fehlerfrei ist mittels [Check Model](#1-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](#1-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-KeySpalten angegeben!
|
|
|
|
|
|
### 4.2 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.3 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`. |