Modellieren und Einrichten einer Datenbank zum Anwendungsbereich Zoo

Inhaltsverzeichnis

1. Einleitung
1.1 Zielsetzung
1.2 Abgrenzung

2. Konzeptueller und logischer Prozess der Datenbankmodellierung
2.1 Weltausschnitt und konzeptuelle Modellierung
2.2 Relationenmodell und logische Modellierung
2.2.1 Normalisierung des Relationenmodells

3. Modellierung der Datenbank ZOO
3.1 Konzeptuelle Modellierung
3.1.1 Realweltausschnitt und Entitätstypen
3.1.2 E/R-Diagramm ZOO
3.2 Logische Modellierung
3.2.1 Transformation des E/R Diagrammes ins Relationenmodell
3.2.2 Normalisierung des Relationenmodells

4. Einrichtung der Datenbank
4.1 Entwicklungsumgebung
4.2 Übertrag des Relationenmodells in Datenbanktabellen

5. Fazit und Möglichkeiten

Abbildungsverzeichnis

Literaturverzeichnis

1. Einleitung

In der heutigen Zeit wird der Umgang mit elektronisch gespeicherten Infor- mationen immer wichtiger. Sie dienen als Basis für diverse elektronische Ge- schäftsvorgänge (Serienbrief, Telefonkontakt etc.) aber auch als Informati- onsquelle über eine Person oder einen Gegenstand welchen man „bearbei- ten“ muss. Der Vorteil dieser elektronisch gespeicherten Daten liegt klar in ihrer informellen Größe bei sehr geringem Platzbedarf. So kann heutzutage die komplette Personaldatenbank eines Unternehmens bequem auf einem Datenträger (z.B. USB-Stick) transportiert und an einem mobilem Gerät wie z.B. einem Smartphone oder einem Tablet bearbeitet bzw. aktualisiert und ausgewertet werden. Früher wurden die Informationen in Ordner abgelegt und in Registraturen in der Größe von Turnhallen aufbewahrt. Eine Informa- tion zu beschaffen dauerte Stunden, heute ist diese nur einen Klick entfernt. Was aber bringt der geringe Platzbedarf und die Portabilität wenn die ge- speicherten Daten nicht entsprechend aufbereitet, richtig abgelegt und Infor- mationspaare nicht miteinander verknüpft sind? Diese Informationen sind für die Unternehmen überlebenswichtig. Falsche oder nicht rechtzeitig zur Ver- fügung gestellte Daten entscheiden oftmals über Erfolg oder Misserfolg. Eine Datenbank sammelt und organisiert die Daten welche untereinander in einer logischen Beziehung stehen. Die Verwaltung übernimmt hierbei das Daten- bankverwaltungssystem (Database Management System, DBMS)¹.

1.1 Zielsetzung

In diesem Assignment soll beispielhaft der Weg von einer textuellen Problembeschreibung bis hin zur fertigen Datenbank beschrieben werden. Dabei soll insbesondere der Vorgang des Modellierens und der späteren Einrichtung der Datenbank unter MySQL im Vordergrund stehen.

1.2 Abgrenzung

Aufgrund der Aufgabenstellung, welche das Modellieren und Einrichten der Datenbank beschreibt, und der recht geringen zur Verfügung stehenden Sei-

tenzahl, wird der theoretische Ansatz nur angerissen und nicht entsprechend vertieft. Der Prozess der physischen Modellierung wird hier nicht beschrie- ben, da dieser in der Regel direkt vom DBMS (Datenbankmanagementsys- tem) übernommen wird. Es gibt zwar Möglichkeiten der Optimierung durch den Datenbankadministrator, z.B. über Indexe o.ä., dieses zu beschreiben würde aber den Rahmen sprengen. Das Assignment endet mit der Imple- mentierung der Tabellen auf dem Datenbankserver. Für eine spätere Ver- wendung müssen dann noch passende GUIs eingerichtet und diverse SQL Befehle zur Pflege und Auswertung der Daten hinterlegt werden.

2. Konzeptueller und logischer Prozess der Datenbankmodel- lierung

2.1 Weltausschnitt und konzeptuelle Modellierung

Die erste Phase bildet die Grundlage für das spätere Datenbankdesign und fordert meiner Meinung nach die größte Aufmerksamkeit. Es beginnt mit einer textuellen Aufgabenbeschreibung, einem sogenannten Realweltausschnitt. Hierbei werden der Zweck der Datenbank und die später zu implementierenden Funktionen in natürlicher Sprache beschrieben. Anschließend werden hieraus die Objekte der Realwelt (Entitätstypen), deren Eigenschaften (Attribute oder Methoden) und die Beziehungen (engl. Relationship) zwischen diesen Objekten ermittelt und festgehalten².

Das Ergebnis wird dann grafisch in einem Entity-Relationship-Diagramm (E/R-Diagramm) festgehalten. Dabei werden in der klassischen Notation die Entitätstypen (Bsp. Tiere) als Rechtecke, die zugehörigen Attribute als Ellipsen (Bsp. Name, Gattung) und die Beziehungen als Raute dargestellt. Attribute welche eine einzelne Entität eindeutig identifizieren, werden auch Schlüsselattribute genannt und im E/R-Diagramm durch Unterstreichung hervorgehoben. Neben diesen grafischen Elementen werden auch die Beziehungstypen (Kardinalitäten) zwischen den beteiligten Entitätstypen als 1:1-, 1:n- oder n:m- Beziehung festgehalten³. Den Abschluss der konzeptuellen Modellierung bildet das fertige E/R-Diagramm.

2.2 Relationenmodell und logische Modellierung

In der nächsten Phase wird das bisher erstellte konzeptuelle in ein logisches Datenmodell transformiert. Während sich die erste Phase noch hauptsächlich an der Aufgabenbeschreibung und der Abbildung eines Anwendungsbereiches orientiert hatte, beschäftigt sich die logische Modellierung damit, das E/R-Diagramm in für die Datenbank tauglichen Relationen, sprich Tabellen umzuwandeln. Dabei gilt es ein paar simple Transformationsregeln einzuhalten wie sie Dr. Thimm und Dr. Blaschka beschreiben:

Abbildung in dieser Leseprobe nicht enthalten.

Abbildung 1 - Transformationsregeln im Relationenmodell⁴

Werden diese Regeln befolgt, erhält man nach der Transformation das Relationenmodell. Hierbei werden die Daten bereits in Tabellenstruktur angezeigt und durch Fremdschlüssel miteinander verknüpft.

Abbildung in dieser Leseprobe nicht enthalten.

Abbildung 2 - Transformation vom Entitätstyp zur Relation

2.2.1 Normalisierung des Relationenmodells

Während der Transformation ins Relationenmodell ergibt sich aus der Struk- tur der Daten oft ein recht unschönes Bild in Bezug auf Redundanzen und die spätere Performanz der Datenbank. Um dieses Problem zu lösen, wur- den Regeln festgelegt die sich darin wiederspiegeln, in welcher Normalform sich die Relation gerade befindet. Dadurch werden die Redundanzen inner- halb der Datenbank vermindert; ebenso die daraus eventuell resultierende Inkonsistenz mehrfach gespeicherter Daten. Insgesamt gibt es fünf Normal- formen in denen sich eine Datenbank befinden kann, wobei die nächsthöhere

Form die Definitionen der vorhergehenden beinhaltet bzw. diese voraussetzt. Da die vierte und fünfte Normalform in der Praxis eher eine untergeordnete Rolle spielen, möchte ich hier nur die ersten drei kurz vorstellen. Hierzu bediene ich mich der Definitionen von SCHICKER:⁵

Abbildung in dieser Leseprobe nicht enthalten.

Das bedeutet, dass es innerhalb eines Attributes nur Einzelwerte geben darf. Das wäre nicht der Fall, wenn z.B. mehrere Werte per Komma getrennt eingegeben werden können (Feld Rechnungsnummer 123,124,125,…)

Abbildung in dieser Leseprobe nicht enthalten.

Grundsätzlich hängen alle Attribute einer Relation immer an dem, den Tupel eindeutig identifizierenden, Primärschlüssel. Ist dieser aus zwei Attributen zusammengesetzt, kann es sein, dass einzelne Nichtschlüsselattribute nur von einem Teil des Primärschlüssels abhängen. Hier würde die Relation dann gegen die zweite NF verstoßen und die Attribute und das ihnen zuge- hörige Schlüsselattribut müssten in eine eigene Relation „ausgelagert“ wer- den.

Abbildung in dieser Leseprobe nicht enthalten.

Das klassische Beispiel einer Relation die oftmals gegen die dritte NF verstößt, ist eine Adressdatenbank. Hier sind in der Regel Attribute enthalten welche andere Nichtschlüsselattribute beschreiben, und somit nicht direkt vom Primärschlüssel abhängig sind. Diese können in eigene Relationen ausgegliedert werden um Redundanzen zu vermeiden (Bsp. Vorwahl und Ort hängen an der PLZ und nicht am Namen).

3. Modellierung der Datenbank ZOO

3.1 Konzeptuelle Modellierung

Ausgangspunkt aller Datenbankmodellierungen ist eine textuelle Beschreibung der Anforderung an die spätere Datenbank, d.h. welche Daten sollen erfasst bzw. verarbeitet werden und in welchem Zusammenhang stehen diese zueinander. In diesem Fall soll aus dem Anwendungsbereich Zoo ein relationales Datenmodell erstellt werden.

3.1.1 Realweltausschnitt und Entitätstypen

Der Realweltausschnitt wird hier durch die Aufgabenbeschreibung bereits klar definiert und muss nicht nochmals wiederholt werden. Es handelt sich hierbei um eine Datenbank zur Verwaltung üblicher Aufgaben innerhalb ei- nes Zoos.

Eine Entität kann sowohl ein physisches (Tier, Gebäude,…) als auch ein konzeptuelles (digitale Tierakte, Studienmodul,…) Objekt der realen Welt sein. Sie bildet die Basis für das spätere Ziel der konzeptuellen Modellierung, das E/R Diagramm.⁶ Aus der Aufgabenbeschreibung sind folgende Entitätstypen und deren Eigenschaften zu erkennen:

Abbildung in dieser Leseprobe nicht enthalten.

Abbildung 3 - Tabelle der Entitätstypen

Zusätzlich zu den oben genannten Entitätstypen, gibt es noch erweiterte Ei- genschaften der Beziehungen einzelner Entitätstypen untereinander. Diese habe ich aber nicht explizit den Entitäten zugeordnet. Ein Beispiel ist die „Fütterung“, sie stellt die Beziehung der Tiere zum Futter dar und verfügt selbst über eigene Attribute (Datum, Menge). Sie wird später in einer eigenen Relation dargestellt, ist aber kein Entitätstyp im klassischen Sinn.

In der Aufgabenbeschreibung soll bei den Tieren die Anzahl der jeweiligen Gattung eingepflegt werden. Diese ist aber weder ein Attribut des Entitäts- typs noch ein später in der Datenbank zu pflegendes Feld. Die Anzahl der Tiere einer Gattung zu ermitteln, ist Aufgabe des späteren Datenbank- Frontend bzw. des entsprechenden SQL-Statements (z.B. „Select Count (Gattung) from Tiere“ o.ä.) und muss hier nicht weiter behandelt werden.

3.1.2 E/R-Diagramm ZOO

Im ersten Teil der konzeptuellen Modellierung wurden die Entitätstypen des Aufgabenbereichs ermittelt. Diese bilden nun die Basis für das E/R- Diagramm und werden als Rechtecke dargestellt. Die dazugehörigen Attribu- te werden in Form von Ellipsen an die Rechtecke „angehängt“. Dabei wird das Schlüsselattribut, also das Attribut welches die einzelne Entität eindeutig identifiziert, unterstrichen.

Der Entitätstyp „Pfleger“ wird durch die Attribute PersNr, Name und Vorname beschrieben, wobei die PersNr für jede Entität eindeutig ist.

Abbildung in dieser Leseprobe nicht enthalten.

Abbildung 4 - Entitätstyp Pfleger

Die Beziehungen der Entitätstypen untereinander, werden im E/R Diagramm als Rauten dargestellt und gegebenenfalls mit Attributen versehen. Die Kardinalität der Beziehung wird mittels Zahlen am Ende der Verbindung dargestellt und immer an das Ende der Leserichtung geschrieben.

Die Verbindung zwischen Pfleger und Tiere wird über die Beziehung „Betreuung“ beschrieben. Dabei werden Beginn und Ende der Betreuung erfasst.

Abbildung in dieser Leseprobe nicht enthalten.

Abbildung 5 - Beziehung Pfleger und Tiere

[...]

¹ Vgl. Schicker, Datenbanken und SQL, Seite 3

² Vgl. Hansen/Neumann, Wirtschaftsinformatik 1, Seite 286

³ Vgl. Laudon, Wirtschaftsinformatik - Eine Einführung, Seite 304

⁴ Quelle: Thimm/Blaschka, Datenbankentwurf DBA102, Seite 36

⁵ Schicker, Datenbanken und SQL, Seite 57 ff

⁶ Vgl. Elmasri et.al, Grundlagen von Datenbanksystemen, Seite 62