Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung
unter dem Förderkennzeichen 16OH21005 gefördert.
Die Verantwortung für den Inhalt dieser Veröffentlichung liegt
beim Autor/bei der Autorin.
2 In diesem Abschnitt werden wir uns mit der Fragestellung beschäftigen, wie man
überhaupt vorgeht, um Datenmodelle zu erstellen.
Ziel ist es ja, ein Datenmodell zu erstellen, in dem wir verstehen, welche Informationen zu verarbeiten sind und die einzelnen Informationen zusammenhängen bzw. in Beziehung stehen.
Aufgrund des Datenmodells können wir dann unsere Datenbank anlegen und mit Daten füllen.
Wir werden hierbei im einzelnen folgenden Fragestellungen nachgehen:
• Welche sind die wichtigsten Schritte . Also wie sieht der Prozess insgesamt aus?
• Was hat das Datenmodell mit der Anforderungsanalyse zu tun?
• Wie sieht der erste Schritt aus?
• Wie sieht der zweite Schritt aus?
• Wie sieht der dritte und letzte Schritt aus?
Die Abbildung zeigt die generellen Lösungsansätze für den Datenbankentwurfsprozess.
Auf der linke Seite sehen Sie den sogenannten Top/Down Ansatz.
Bei dem Top-Down Ansatz geht man von folgenden Bedingungen aus:
• Es handelt sich um eine NEUE Softwarelösung
• Es liegt noch kein Datenmodell vor
Man beginnt zunächst mit den abstrakten Anforderungen und versucht diese in nachfolgenden Schritte immer weiter zu verfeinern, bis hin zu ganz konkreten Modellen, die man mit einer relationalen Datenbank umsetzen kann.
Meist kommt es aber auch vor, dass bereits ein System mit einer Datenbank vorhanden ist und dieses System erweitert werden soll. In diesen Fällen ist bereits eine Datenbank vorhanden.
Hier wird dann einBottom–Up Ansatz verfolgt.
Bei dem Bottom-Up Ansatz geht man von folgenden Bedingungen aus:
• Es liegt bereits eine Datenbank vor
• Das Ziel ist es, die Datenbank zu erweitern, um neue Anwendungen bzw. neue Funktionen zu ermöglichen.
Die einzelnen Vorgehensweisen werden wir uns im folgenden näher ansehen.
3
Top-Down Ansatz
Bei einem Top Down Ansatz beginnt man mit zumeist abstrakten Anforderungen, die immer weiter konkretisiert werden.
Da in diesem Fall noch kein Datenmodell vorliegt, stehen somit folgende Punkte im Mittelpunkt der Aktivitäten :
• Welchen Informationen / Daten sind wichtig?
• Gibt es Beziehungen zwischen den Daten. Wenn ja, um welche Art von Beziehungen handelt es sich?
Die Schritte im einzelnen sind wie folgt:
1. Man beginnt zunächst mit einer Anforderungsanalyse. Ziel ist hierbei, die Aufgabenstellung überhaupt zu verstehen und um sie eingrenzen zu können.
2. Danach erstellt man das erste sogenannte Begriffliche Modell. Ziel ist hierbei, genau zu dokumentieren und zu modellieren, mit welchen Begriffen und Informationen wir es im einzelnen zu tun haben und wie der Auftraggeber die Welt sieht.
3. Auf der Basis des „Begrifflichen Modells“ wird ein Logisches Modell erstellt. Ziel hierbei ist, ein erstes Modell aus Sicht der IT-Welt zu erhalten. Hier fließt zum ersten Mal der relationale Ansatz in das Modell ein.
4. Auf Basis des „Logischen Modells“ wird ein physikalisches Modell erstellt. Ziel ist es, ein Modell zu erhalten, auf deren Basis man eine Datenbank anlegen kann. Wie wir später sehen werden, wenn wir die Sprache SQL kennengelernt haben, kann man mit der Hilfe von Werkzeugen aufgrund der Beschreibungen eines physikalischen Modells direkt ein SQL-Script erzeugen, um ein Datenbankschema anzulegen.
Ein Datenbank Schema beinhaltet alle Definitionen und Vorschriften, um ein relationales Modell zu implementieren. Dies bedeutet anlegen von Tabellen und Beziehungen inkl.
Schlüssel usw.
4
Hier wollen wir uns die Analysephase näher ansehen.
In der Analysephase geht es im wesentlichem um:
• Die Begriffe des Auftraggebers zu verstehen
• Ggf. die Begriffe zu hinterfragen
• Erste Ideen für Entity-Typen zu entwickeln
Unter anderem kommen hier folgende Methoden zum Einsatz:
• Interview-Techniken
• Verbale Konversation mit End Usern
• Brainstorming Sessions
• etc.
Potentielle Methoden sind alle Techniken und Methoden aus dem Bereich Requirements Engineering.
Am Ende der Anforderungs-Analyse erhält man ein oder mehrere Dokumente mit dem Ziel, das man das Problem verstanden hat und es auch beschreiben kann.
Wichtig dabei ist, dass man auch den Problemkontext verstanden und ggf.
Dokumentiert hat.
Zur Dokumentation kommen folgende Arten von Aufzeichnungen zum Einsatz:
• Fotoprotokolle von Whiteboards, Flipcharts, Poster Wänden etc.
• Mind-Maps
• Karteikarten
• Tabellen / Spreadsheets
• Prosa-Text
• Alle Arten von Skizzen und Diagrammen
Hinweis:
Hie wird der Begriff Anforderungsanalyse wir hier in einem engeren Sinne verstanden.
Nämlich für das Sammeln von ersten Anforderungen.
Sie können daher diesen ersten Schritt auch als „Kick-Off“-Schritt bezeichnen anstatt Anforderungsanalyse.
In vielen Quellen wird Anforderungsanalyse in einem allgemeineren Sin verstanden, in der alle Aktivitäten zusammen gefasst werden um eine Grundlage für ein Design zu erhalten.
5
Auf Grund der ersten Aufzeichnungen aus der Anforderungsanalyse wird ein sogenanntes Begriffliches Modell erstellt.
Das Begriffliche Modell wird meist auch „Konzeptionelles Modell“ genannt. Im Englischsprachlichen wird hierfür der Begriff ‚conceptual model‘ verwendet.
Ziel:
• Identifizierte Entity-Typen in das Modell eintragen
• Begriffe des Auftraggebers verwenden. Dies gilt sowohl für Entity-Typen und Namen für Beziehungen.
• Sachverhalte so notieren, dass sie vom Auftraggeber verstanden und verifiziert werden können.
Charakteristiken:
• Umgangssprachliche Begriffe
• DBMS unabhängig
• Beschreibung, die der Anwender versteht
• Semi-Formal Darstellung
Die Herausforderungen sind:
• Die wichtigsten Entity-Typen identifizieren. Meist 20-50 Stück
• Die wichtigsten Beziehungen finden und dokumentieren
• Die wichtigsten Attribute dokumentieren
• Die wichtigsten Kardinalitäten dokumentieren .. Sofern bekannt
Tipp:
• Entity-Kandidaten sind alle Dinge (real oder abstrakt), die aus Sicht des Anwenders in irgendeiner Form beobachtet, gelesen, bearbeitet oder in sonst einer Weise beachtet werden.
• Ein Entity-Type ist in der Regel immer ein Substantiv.
6
In dieser Abbildung sehen Sie ein Beispiel für ein Begriffliches-Modell.
Das Beispiel zeigt, wie ein Begriffliches-Modell für eine Autovermietung aussehen könnte.
Aus dem Modell gehen die wichtigsten Entity-Typen hervor. Als Entity-Typen finden sie meist Begriffe aus der realen Welt. Es ist außerdem zu erkennen, dass die Namen der Beziehungen die Sachverhalte wiederspiegeln, die direkt aus der Problem bzw. Aufgabenbeschreibung hervorgehen. Es wird also versucht das Problem bzw. die Aufgabe in Form eines Datenmodells zu beschreiben, ungeachtet wie dies in ein Implementation umgesetzt werden könnte.
Die wichtigsten Informationen aus dem Model sind:
• Ein Kunde kann ein Fahrzeug reservieren
• Ein Kunde kann ein Fahrzeug mieten
• Ein Kunde kann ein Fahrzeug zurück geben
• Ein Mitarbeiter nimmt ein Fahrzeug entgegen ( welches zurückgegeben wurde .. Vermutlich)
• Es gibt sogenannte Interessenten, die sich für ein bestimmtes Fahrzeug interessieren
• Ein Kunde kann einen Mietvertrag abschließen, der von einem Mitarbeiter
unterschrieben ist(/ sein muss und der genau für ein Fahrzeugt gilt.
Charakteristiken des Modell / Best -Practices
• Enthält die wichtigsten Entity-Typen, Anzahl der Entity-Typen meist zwischen 10- <
50
• Enthält meist keine Kardinalitäten. Kardinalitäten werden nur dann eingetragen, wenn diese für den Auftraggeber absolut wichtig sind, weil diese zum Beispiel auf Grund einer Geschäftsregel (Business Rule) unbedingt eingehalten werden müssen
• Attribute werden nur eingetragen, sofern diese zum Verständnis des Modell notwendig erscheinen bzw. hilfreich sind.
• Es werden keine Annahmen gemacht bzgl. einer speziellen Implementation bzw. einer später zu verwendenden Datenbank (Plattformunabhängigkeit)
• Sofern Attribute in das Model eingetragen werden, werden für diese Attribute in der Regel keine Datentypen festgelegt. Sofern der Auftraggeber auf eine bestimmtes Datenformat Wert legt, so trägt man ganz abstrakte Datentypen ein wie (Zeichenkette, Nummer, etc.) Die Namen der Datentypen müssen keine Datentypen sein, die es in der IT-Welt gibt. Verwenden Sie einfach Namen, aus denen der Sinn des Datenformates hervorgeht wie z.B. KreditkartenNummer.
7
Auf Grund des „Begrifflichen Modells“ wird nun ein „Logisches Datenmodell“
erstellt. Hierbei werden die Begriffe in ein Modell überführt, welches von IT Experten verstanden wird.
Charakteristiken des Modells/ Best -Practices
• Vervollständigen der Liste der Entity-Typen
• Attribute der Entity-Typen sind vervollständigt
• Für jedes Attribut wird ein Datentyp aus der IT-Welt zugeordnet
• Die Beziehungen werden vervollständigt
• M-M Beziehungen verwenden, sofern vorhanden
• Die Schlüssel festlegen. Ggf. künstliche Schlüssel einführen.
• Definiere Sie ggf. Wertebereich für einzelne Attribute, sofern dies sich aus der Aufgabestellung ergeben
Tipp:
• Es ist wichtig bei dem Übergang vom Begrifflichen Modell auf das Logische Modell Widersprüche zu identifizieren und aufzulösen
• Achten Sie dabei auf Homonyme und Synonyme
• In der Praxis verwendet man für die Logischen Modelle ein Daten-
Modellierungswerkzeug.
• Bei der Auswahl des Werkzeuges sollte man darauf achten, dass man mit diesem
Werkzeug das Logische Modell weiterverarbeiten kann, um daraus ein physikalisches Modell zu erstellen.
8
Aus dem „Logischen Modell“ wird in einem weiteren Schritt ein sogenanntes
„Physikalische-Modell“ erstellt.
Bei der Erstellung des physikalischen Modells verwendet man meist ein
Werkzeug, in dem man das logische Modell weiterverarbeiten kann, um daraus ein physikalisches Modell zu erstellen.
Bei diesem Schritt muss zunächst eine Designentscheidung getroffen werden. Es muss nämlich festgelegt werden, für welchen spätere RDBMS Hersteller das Modell erstellt werden soll.
Physikalische Modelle sind somit herstellerspezifisch. Dies hat folgende Gründe:
• Datentypen sind nicht bei allen Herstellern gleich
• Es gibt Hersteller spezifische Datentypen
• Da der SQL Standard (wie wir später im Abschnitt SQL noch sehen werden) nicht alles abdeckt, gibt es herstellerspezifische Erweiterungen insb. für das Anlegen der Tabellen.
Charakteristiken des Modells / Best -Practices
• Alle N-M Beziehungen müssen in 1-N aufgespalten werden
• Allen Attributen muss ein Datentyp zugewiesen werden.
• Das Modell in die 3.Normalform bringen. (Normalisierung ist ein eigener Abschnitt gewidmet.
Ist das Physikalische-Modell erstellt, werden –wie bereits erwähnt- mit den
entsprechenden Werkzeuge ein oder mehrere SQL –Scripts erstellt, die dazu verwendet werden können, um in einer Datenbank das entsprechende Datenbankschema anzulegen.
9
Bottom-Up Ansatz
Bei einem Bottom-Up Ansatz beginnt man bei dem existierenden Datenbank- Schema und erweitert. D.h. hinzufügen von neuen Tabellen etc.
Somit stehen folgende Punkte im Mittelpunkt der Aktivitäten:
• Welche Informationen / Daten sind noch nicht in dem existierenden Datenmodell erfasst?
• Welche Beziehungen kommen neu hinzu?
• Ändern sich bestehende Beziehungen?
Wie die einzelnen Schritte genau ablaufen , sehen wir uns als nächstes an.
Die Schritte beim Bottom-Up Ansatz sind wie folgt:
1. Schritt (1) Sofern ein Physikalisches Modell nicht ODER nicht mehr vorliegt, kann man mit Werkzeugen wie zum Beispiel mit CA-Erwin ein existierendes Datenbank Schema einem „Reverse-Engineering“ unterziehen. Dies
bedeutet, dass man aus einer laufenden Datenbank ein Datenbankschema auslesen kann und erhält ein dazu passendes physikalisches Modell.
2. Schritt (2) - ist optional. Man kann das physikalische Modell in ein logisches Modell überführen , in dem an ggf. Beziehungen auflöst und in N-M
Beziehungen wieder einführt. Dies ist meist aber ein manueller Schritt und ist bei umfangreichen Modellen mit einem hohen Aufwand verbunden.
3. Schritt (3) hat zum Ziel eine Begriffliches ´Modell zu erstellen. Dies beinhaltet die gleichen Aktivitäten und Ergebnisse wie bei dem Top-Down Ansatz. Ziel ist es, die Aufgabenstellung zu verstehen, um im nächsten Schritt die entsprechenden Änderungen und Erweiterungen vornehmen zu können.
4. Schritt (4) – ist optional. Sofern eine logisches Modell vorliegt, werden in diesem Schritt die notwendigen Änderungen und Erweiterungen – die sich aus der Aufgabenstellung ergeben – in das Modell eingetragen.
5. Schritt (5) In diesem Schritt werden die notwendigen Erweiterungen und Ergänzungen aus dem logischen Modell übertragen. Hierbei gelten die gleichen Regeln wie bei dem Top-Down Ansatz. Liegt kein logisches Modell vor, so ergeben sich die notwenigen Änderungen und Erweiterungen aus dem
11
begrifflichen Modell.
6. Schritt(6) Dies ist der letzte Schritt. Hier besteht die Aufgabe aus dem physikalischen Model ein SQL Script zu erzeugen, um das neue Datenbankschema anzulegen. Die Besonderheit hier ist, dass ggf. auch ein sogenanntes „Update Script“ erstellt werden muss, um eine existierende Datenbankinstanz an das neue Schema anzupassen bzw. zu erweitern. „Update Scripts“ werden meist manuell erstellt.
12
14
