Grundlagen relationaler Datenbanktheorie und Implementierung einer Beispieldatenbank

Inhaltsverzeichnis

1 Einleitung: Entwicklung des Datenbankbegriffs

2 Theoretische Grundlagen einer relationaler Datenbank
2.1 Architektur
2.2 Relationales Datenmodell
2.3 Structured Query Language

3 Entwicklung und Implementierung einer Beispieldatenbank
3.1 Externe Phase
3.2 Konzeptionelle Phase
3.3 Logische Phase
3.3.1 Normalisierung
3.3.2 Entity-Relationship-Modell
3.4 Physische Phase
3.5 Programmierung

4 Fazit

5 Anhang
5.1 Relationen der Beispieldatenbank und ihre Datentypen
5.2 Abfragen der Beispieldatenbank in der Detailansicht
5.3 DDL-Anweisungen
5.4 Auskommentierter Quellcode des Importmoduls
5.5 Glossar

Literaturverzeichnis

Abbildungsverzeichnis

Eigenständigkeitserklärung

1 Einleitung: Entwicklung des Datenbankbegriffs

Während der letzten 30 Jahre wurde die Entwicklung von Datenbanksystemen durch eine außerordentliche Produktivität geprägt. Dies hat dazu geführt, dass Datenbanksysteme immer häufiger Einzug und Verwendung in mittelständischen Betrieben und Großkonzernen erhalten haben. Die heutigen Datenbanksysteme zählen zu den wichtigsten Errungenschaften des Software Engineering. Sie dienen als Grundgerüst der präzisen und zentralen Informationsverwaltung und fördern dadurch nicht nur den internen und externen Informationsfluss, sondern bewähren sich auch als effizientes Speichermedium für sensible Daten. Gerade die Entwicklungen der letzten Jahre haben Systeme hervorgebracht, die immer leistungsfähiger arbeiten und durch

ihre einfache, intuitive Bedienung dem Anwender einen leichten Zugang zu komplexen Arbeitsabläufen verschaffen.¹

Ich möchte die oben beschriebene Entwicklung grob in drei Kategorien einteilen und diese im Folgenden näher erläutern.

Anfang der 60er Jahre wurden im Zuge der Industrialisierung und des technischen Fortschritts, im Bereich der Informationsverarbeitung, erste Systeme geschaffen, die eine softwaregestützte Verwaltung von mehreren Datenstrukturen erlaubten. Diesen Dateisystemen mangelte es jedoch an Flexibilität, da die Software abhängig von der zugrunde liegenden Datenbasis und dem eingesetzten Rechnersystem war. Dies führte

zu inkompatiblen Datenstrukturen und somit auch rasch zu der mehrfachen (Redundanz) und teilweise widersprüchlichen (Inkonsistenz) Speicherung von Daten.²

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1.1: Datenzugriff ohne spezielle Verwaltungssoftware

Die obige Grafik soll veranschaulichen, wie das Zusammenspiel zwischen Anwendungssystem und Datenbasis erfolgt. Es gibt mehrere Anwendungen, die ihrerseits auf einen oder mehrere Datenbestände zugreifen können. Es ist allerdings nicht automatisch gewährleistet, dass Anwendung n auf Datenbasis m zugreifen kann, da eine andere Struktur der Daten vorliegen könnte. Die logische Konsequenz bei einer Vielzahl solcher Systeme und Datenbasen äußert sich durch inflexible Datenstrukturen.

Die zweite Stufe stellt die Situation der Entwicklung Ende der 60er Jahre dar. Die Probleme der vorhergehenden Dateisysteme wurden erkannt, konnten jedoch nicht vollständig beseitigt werden. Mit der Einführung sogenannter Dateiverwaltungssysteme erhielten neue Methoden des Datenzugriffs Einzug in die Datenbanktechnik, wie etwa SAM (sequential access method) oder ISAM (indexsequential access method). Hierbei handelt es sich um sequentiellen bzw. indexsequentiellen Zugriff auf die Datenbasis. Nachstehende Grafik erläutert die Beziehungen zwischen Anwendung, Dateiverwaltungssystem und Datenbasis.³

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1.2: Dateiverwaltungssoftware regelt den Umgang mit zugrunde liegenden Daten

Der wesentliche Fortschritt dieser Entwicklungsstufe war die geräteunabhägige Verwaltung der Datenstrukturen. Diese Systeme wurden jedoch weiterhin durch einen redundanten Charakter geprägt und wiesen mit der Zeit zunehmend Inkonsistenzen auf.

Ein weiterer wichtiger Sprung in der historischen Entwicklung führte Anfang der 70er Jahre den Begriff des Datenbanksystems ein. Jene Systeme kompensieren die Nachteile ihrer Vorgänger und führen gleichzeitig zu einer neuen Definition der Funktionsweise in der bisherigen Datenverwaltung (Basis-Funktionalität).

Datenbanksysteme bestehen aus dem sogenannten Datenbankmanagementsystem (nachfolgend DBMS genannt), welches den eigentlichen Kern mit sämtlichen Software- Modulen zur Verwaltung der Daten darstellt, sowie der zugrunde liegenden Datenbasis. Die ursprünglichen Probleme wurden maßgeblich durch die Implementierung des flexiblen DBMS beseitigt. So profitiert die Datenhaltung von der Redundanzfreiheit und somit auch der wahrheitsgemäßen Speicherung der Daten (Datenkonsistenz).⁴

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1.3: Datenbanksysteme

Die Begriffsdefinition des Datenbanksystems ist für das weitere Verständnis der beschriebenen theoretischen Grundlagen von immenser Wichtigkeit. Im Folgenden werde ich weiter das nötige Grundlagenwissen vertiefen, bevor ich mich der praktischen Seite dieser Arbeit zuwenden werde: der Entwicklung und Implementierung einer Beispieldatenbank für die FOS/BOS Obernburg.

2 Theoretische Grundlagen einer relationalen Datenbank

2.1 Architektur

Die Architektur eines DBMS lässt sich in voneinander abhängige Ebenen einteilen. Die Grundstufe bildet die Ebene des Betriebssystems. Sie wird in der Literatur häufig vernachlässigt, da sie mit der internen Funktionsweise der Datenbankanwendung nichts zu tun hat. Sie dient lediglich als Grundgerüst damit ein DBMS in Betrieb genommen werden kann.

Abseits der Betriebsebene lässt sich eine Dreiteilung der für die Datenbank und deren Nutzer relevanten Ebenen vornehmen. Die unterste Ebene bildet die so genannte interne Ebene. Die interne Ebene definiert alle systemspezifischen Merkmale des DBMS. Sie baut direkt auf die Betriebsebene auf, da sie abhängig von der jeweiligen Speicherstruktur und der verfügbaren Sprachschnittstelle ist.⁵

Die konzeptuelle Ebene ist dagegen vollständig systemunabhängig. Das heißt es gibt an dieser Stelle keine Informationen über die Implementierungsdetails der Datenbank, sondern lediglich eine vollständige Beschreibung der zugrunde liegenden Datenstruktur. Um eine semantisch korrekte und realitätsgetreue Datenstruktur zu erhalten, gibt es zwei wesentliche Werkzeuge, die nachfolgend in der Arbeit ausführlich besprochen werden. (vgl. dazu Kapitel 3.3.1, 3.3.2).

Die Anwender eines solchen DBMS greifen auf die sog. externe Ebene zu. Sie beinhaltet sämtliche Datenbankmasken (Benutzersichten) mit denen der Benutzer den Datenbestand interaktiv verwalten kann. Durch diese Abkapselung von dem internen und konzeptuellen Schema ist gewährleistet, dass der Anwender nichts an der Struktur und internen Implementierung der Datenbank modifizieren kann. Der Anwender hat lediglich Zugriff auf die ihm freigestellten Benutzersichten und kann dementsprechend auch nur die Daten verändern, mit denen er arbeiten muss.

Für die Beispieldatenbank ergeben sich folgende Einschränkungen:

- Es existiert nur eine Sicht.
- Die Datenbank wird nicht im Netzwerk betrieben.
- Das einzusetzende DBMS ist Microsoft Access unter Windows XP/2000.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.1: Zusammenspiel der verschiedenen Ebenen

2.2 Relationales Datenmodell

Das relationale Datenmodell geht ursprünglich auf die Arbeit von Edgar F. Codd zurück. Es stellt die vorhandenen Daten in Tabellenform dar, wobei es sich nur auf die Daten beschränkt und nicht die Beziehungen einzelner Attribute wiedergibt. Die Datensätze liegen demnach in einer zweidimensionalen Struktur vor, was auch gleich einen wesentlichen Nachteil des relationalen Datenmodells erkennen lässt: Möchte man

z. B. Daten über dreidimensionale Messergebnisse (Bewegungen im Raum) verwalten, so stößt man an die Grenzen eines solchen Modells.⁶

Durch die Zuweisung von Schlüsselfeldern können Beziehungen zwischen Attributen verschiedener Relationen konstruiert werden. Man unterscheidet folgende Schlüsseltypen:

- Primärschlüssel
- Sekundärschlüssel
- Fremdschlüssel

Die hier genannten Fachtermini werden ausführlich im angehängten Glossar erläutert. Die Kenntnis über die Funktionsweise von Schlüsselfeldern wird vorausgesetzt.

Zur Veranschaulichung möchte ich drei Relationen der Beispieldatenbank vorstellen.

Abbildung in dieser Leseprobe nicht enthalten

Der große Vorteil des relationalen Modells – die klare Datenstruktur dank mehrerer Relationen – ist zugleich auch ein wesentlicher Nachteil. Bei komplexen Abfragen müssen unter Umständen Beziehungen über mehrere Relationen definiert werden, was nicht nur schwierig zu implementieren ist, sondern sich auch zu Lasten der Performance auswirkt.

Dennoch wird das relationale Modell gerade in betrieblichen EDV-Umgebungen sehr häufig eingesetzt, weil durch die einfache Struktur und den mengenorientierten Operatoren mächtige Werkzeuge zur Verfügung stehen.⁷

Ausgehend von den mathematischen Wurzeln des relationalen Datenmodells lässt sich eine Relation folgendermaßen definieren:

„Ein Objekt kann mehrere Eigenschaften haben, die wir im Folgenden Attribute nennen wollen. Es sei A = {a1, a2, … an} eine endliche Menge von Attributen, wobei jedes Attribut einen Wertebereich besitzt. Man nennt diesen auch Domäne, dom(a). Bei dem Wertebereich handelt es sich um atomare Werte z. B. Integer, String, Boolean etc.“⁸

So ließe sich eine n-stellige Relation R über den gesamten Wertebereich A als Teilmenge des kartesischen Produkts über den Attribut-Domänen von A mathematisch wie folgt beschreiben:

R Í dom (a 1) ´ ...´ dom (a n) ⁹

Überträgt man diese Formel auf das vorangehende Beispiel, so heißt das nichts anderes, als dass alle Attribute, die ein bestimmtes Objekt (in diesem Fall z. B. Betriebe) beschreiben, in einer Relation gebündelt werden können.

Nachfolgend möchte ich einen der wichtigsten Operatoren beschreiben. Der natürliche Verbund (natural join) ist bereits im voranstehenden Beispiel zu sehen. Er verknüpft zwei Relationen, indem das kartesische Produkt der Ausgangstabellen gebildet wird.

R Ù b S

Abbildung in dieser Leseprobe nicht enthalten

Natürlicher Verbund (Beispiel)

Wie man an der obigen Darstellung erkennt, wurden die beiden Relationen R und S über das gemeinsame Attribut b miteinander verknüpft. Es finden sich also nur die Werte in der Ergebnismenge wieder, für die gleiche Werte von b in den Ausgangsrelationen existieren. Die doppelte Spalte b ist nach der Operation nur noch einmal vorhanden. Mathematisch lässt sich das wie folgt beschreiben (vgl. ¹⁰ ):

Sei R([Abbildung in dieser Leseprobe nicht enthalten])

Prinzipiell lassen sich Relationen als eine Menge von Attributwerten darstellen. Diese Mengen lassen sich algebraisch miteinander verknüpfen, sofern eine wesentliche Bedingung erfüllt ist: Die zu verknüpfenden Relationen müssen vereinigungsverträglich sein. Das heißt konkret, dass die Tabellen die gleichen Merkmale sowie identische Datentypen der gemeinsamen Attributwerte besitzen müssen. Neben dem natürlichen Verbund gibt es noch drei weitere Operatoren, die auf Mengen wirken (R und S seien hier zwei Relationen): Die Vereinigung von R und S ( R È S ), den Durchschnitt von R und S ( R Ç S ) und schließlich die Subtraktion von R und S (R \ S). Ich möchte nicht weiter auf die mathematischen Gründe dieser

Operatoren eingehen, sondern lediglich anhand eines Schemas ihre Wirkungsweise demonstrieren. Die dick umrandete Linie kennzeichnet hierbei die resultierende Ergebnismenge.¹¹

Vereinigungsmenge R und S Durchschnitt von R und S Subtraktion von R und S

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.1 Abbildung 2.2.2 Abbildung 2.2.3

Die beschriebenen Operatoren wirken ausschließlich auf ganze Mengen. Abseits dessen gibt es weitere Möglichkeiten, Relationen algebraisch zu verknüpfen. Diese Verknüpfungen wirken sich allerdings nicht auf ganze Tabellen aus, sondern sind parametergesteuert. Sie geben nur den gewünschten Teil einer Relation oder mehrerer Relationen wieder. Man fasst diese Operatoren unter dem Begriff „ relationenorientiere Operatoren“ zusammen. Diese Beschreibung ist im Vergleich zu den

„ mengenorientierten Operatoren“ etwas widersprüchlich, da auch hier die Regeln der Mengentheorie Anwendung finden. Ich möchte mich an dieser Stelle auch nur auf eine schematische Erläuterung beschränken.¹²

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.4 Abbildung 2.2.5

Die Selektion wählt anhand eines Merkmals F bestimmte Datensätze aus einer Relation R aus.

Die Projektion stellt anhand eines Merkmals M bestimmte Spalten einer Relation R dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.5 Abbildung 2.2.6

Der Verbund kombiniert (ähnlich wie bei den mengenorientierten Operatoren) zwei Relationen R und S anhand eines Merkmals P.

Erstellt als Ergebnismenge eine Teiltabelle R’ aus R, wobei alle Tupel von R’ mit denen aus S das kartesische Produkt R’ x S bilden.

Abschließend sei erwähnt, dass Vereinigung, Differenz, kartesisches Produkt sowie Projektions- und Selektionsoperatoren die Basis einer funktionstüchtigen Relationenalgebra bilden. Alle weiteren Operatoren lassen sich mathematisch durch die Verwendung dieser fünf Operatoren herleiten.¹³

2.3 Structured Query Language (SQL)

Anhand einer Datenbanksprache lassen sich relationale Strukturen erzeugen und grundlegende Tätigkeiten für das Verwalten von Daten ausführen. Man verwendet Abfragesprachen u. a. um einfache oder komplexe Abfragen durchzuführen, damit man aus den gespeicherten Daten nutzbringende Informationen gewinnen kann.¹⁴

Einige Strukturen sowie alle Abfragen der Beispieldatenbank wurden mit SQL beschrieben. Demzufolge möchte ich die Sprache kurz vorstellen und näher auf ihre grundlegenden Konzepte eingehen. Microsoft Access bietet prinzipiell SQL und QBE (Q uery b y E xample; grafisches Erstellen) zur Erstellung von Abfragen an. Bei Kenntnissen von SQL lassen sich allerdings derartige Abfragen deutlich schneller

erstellen, weshalb ich mich bei der Beispieldatenbank für den Einsatz SQL entschieden habe. Zuvor möchte ich allerdings die begrifflichen Unterschiede zwischen dem SQL- Sprachgebrauch und der relationalen DBMS aufzeigen:

Abbildung in dieser Leseprobe nicht enthalten

Sämtliche Datenbankbefehle können zwei verschiedenen Kategorien von Datenbankanweisungen zugeschrieben werden:

Data Definition Language (DDL)

In der DDL sind alle Operationen vereint, mit denen der Anwender die logische Struktur einer Tabelle oder Datenbank erstellen bzw. verändern kann.¹⁵ Nachfolgend eine kurze Übersicht gängiger Anweisungen sowie ein Fallbeispiel aus der Beispieldatenbank:

Abbildung in dieser Leseprobe nicht enthalten

Fallbeispiel: Erstellung der Tabelle tblPraktikanten über den SQL-Sprachgebrauch.

Abbildung in dieser Leseprobe nicht enthalten

[...]

---

¹ Vgl. [6] Heuer, Saake: Datenbanken – Konzepte und Sprachen, S. 4

² Ebd., S. 5

³ Ebd., S. 5

⁴ Ebd., S. 5

⁵ Vgl. [6] Heuer, Saake: Datenbanken – Konzepte und Sprachen, S. 25-27

⁶ Vgl. [5] Herbolsheimer: Datenbank-Programmierung, S. 21-22

⁷ Ebd., S. 22

⁸ Ebd., S. 23

⁹ Ebd., S. 23

¹⁰ Ebd., S. 23

¹¹ Vgl. [7] Meier: Relationale Datenbanken, S. 57

¹² Ebd., S. 58

¹³ Ebd., S. 67

¹⁴ Vgl. [4] Connolly, Begg, Strachan: Datenbanksysteme, S. 412

¹⁵ Ebd., S. 413