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.
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
Zur Verwendung für die relationale Datenmodellierung arbeiten wir mit den Modell-Typen
* Conceptual Data
* Conceptual Data
* UML Class Diagram
* Logical Data
* Logical Data
* Physical Data
* Physical Data
der Kategorie Information:
der Kategorie Information:
**Zur Modellierung von Datenbanken beschreibt diese Anleitung zwei Workflows:**
1. Modellierung eines eER-Diagramms, welches in ein Relationenmodell überführt wird
2. 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:
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
***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
***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
***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
***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:
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.
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.
