- 2 -

Inhaltsverzeichnis   

1  Einleitung: Entwicklung des Datenbankbegriffs  3

2  Theoretische Grundlagen einer relationaler Datenbank  6

2.1  Architektur  6

2.2  Relationales Datenmodell  7

2.3  Structured Query Language  11

3  Entwicklung und Implementierung einer Beispieldatenbank  17

3.1  Externe Phase  17

3.2  Konzeptionelle Phase  19

3.3  Logische Phase.  20

3.3.1  Normalisierung  21

3.3.2  Entity-Relationship-Modell  25

3.4  Physische Phase.  27

3.5  Programmierung.  30

4  Fazit.  32

5  Anhang.  34

5.1  Relationen der Beispieldatenbank und ihre Datentypen  34

5.2  Abfragen der Beispieldatenbank in der Detailansicht.  35

5.3  DDL-Anweisungen  36

5.4  Auskommentierter Quellcode des Importmoduls  37

5.5  Glossar.  41

Literaturverzeichnis   43

Abbildungsverzeichnis   43

Eigenst  ändigkeitserklärung  44

- 3 -__________________________________________________________________________________________________________

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. 1

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. 2

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

² Ebd., S. 5

- 4 -__________________________________________________________________________________________________________

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. 3

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.

³ Ebd., S. 5

- 5 -__________________________________________________________________________________________________________

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). 4

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.

⁴ Ebd., S. 5

- 6 -__________________________________________________________________________________________________________

2 Theoretische Grundlagen einer relationalen Datenbank

2.1 Architektur 5

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.

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

- 7 -__________________________________________________________________________________________________________

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. 6

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.

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

- 8 -__________________________________________________________________________________________________________

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. 7

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 = {a 1 , a 2 , … a n } 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.“ 8

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:

⁷ Ebd., S. 22

⁸ Ebd., S. 23 ⁹ Ebd., S. 23

- 9 -__________________________________________________________________________________________________________

Ü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.

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. ¹⁰ ): β α β α = ∈ ist so ), dom( ) dom( Rel(B), ) ..., S( Rel(A), ) , ..., R( Sei

^{n 2 1 m 2 1} β α β α ∈ = × ..., ( R, ) , ..., ( | ) ..., ..., {( : S b a R

^{2 1 m 2 1 n 2 1 m 2 1} β ∈ R)

n

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 ∪ ), den Durchschnitt von R und S ( R ∩ ) und schließlich die Subtraktion von R ( S S

und S (R \ S). Ich möchte nicht weiter auf die mathematischen Gründe dieser

¹⁰ Ebd., S. 23

- 10 -__________________________________________________________________________________________________________

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

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

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. 12

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

¹² Ebd., S. 58

- 11 -__________________________________________________________________________________________________________

Die Selektion wählt anhand eines Die Projektion stellt anhand eines Merkmals F bestimmte Datensätze aus Merkmals M bestimmte Spalten einer einer Relation R aus. Relation R dar.

Der Verbund kombiniert (ähnlich wie bei Erstellt als Ergebnismenge eine Teiltabelle den mengenorientierten Operatoren) zwei R’ aus R, wobei alle Tupel von R’ mit Relationen R und S anhand eines denen aus S das kartesische Produkt R’ x Merkmals P. 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. 13

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. 14

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 (Query by Example; grafisches Erstellen) zur Erstellung von Abfragen an. Bei Kenntnissen von SQL lassen sich allerdings derartige Abfragen deutlich schneller

¹³ Ebd., S. 67

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

- 12 -__________________________________________________________________________________________________________

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:

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: CREATE TABLE dient zur Erstellung einer neuen Basistabelle ALTER TABLE ermöglicht eine Veränderung der Struktur einer Tabelle CREATE VIEW dient zur Erstellung einer neuen Sicht GRANT erlaubt die Vergabe von Benutzerberechtigungen

Fallbeispiel: Erstellung der Tabelle tblPraktikanten über den SQL-Sprachgebrauch. CREATE TABLE "tblPraktikanten" (

"pID" Counter not null, "Vorname" char(50), "Nachname" char(50), "PLZ" Counter default 0, "Straße" char(50), "Telefon" char(50), "E-Mail" char(50), "zID" Counter default 0, „Geburtsdatum"

DateTime, "Region" Counter default 0, PRIMARY KEY "pID" );

Wie man an diesem Beispiel sieht, beschreibt SQL lediglich die Aktion, die vom DBMS ausgeführt werden soll, definiert aber nicht, wie dies zu geschehen hat (deskriptiver

¹⁵ Ebd., S. 413

- 13 -__________________________________________________________________________________________________________

Ansatz ¹⁶ ). Das vorhergehende Beispiel besagt konkret, dass eine Tabelle mit den Feldern pID, Vorname, Nachname, PLZ, Straße, Telefon, E-Mail, Geburtsdatum und Region angelegt werden soll und legt für die Attribute sogleich bestimmte Eigenschaften, wie beispielsweise den Datentyp (hier bspw. char für Zeichenkette) und die maximale Feldlänge, fest. Abschließend wird über das Schlüsselwort PRIMARY KEY der Primärschlüssel dieser Tabelle festgelegt. Im Anhang befindet sich je ein Beispiel zu allen unterschiedlichen DDL-Anweisungen der Beispieldatenbank.

Data Manipulation Language (DML)

In der DML sind alle Befehle vereint, mit denen man Datensätze aus der Datenbank abfragen oder manipulieren kann. ¹⁷ SELECT wird verwendet, um Daten aus einer Tabelle zu lesen DELETE löscht Zeilen aus einer Tabelle UPDATE aktualisiert Zeilen oder Spalten mehrerer Zeilen INSERT fügt Zeilen einer Tabelle hinzu

Auch hier wieder ein Fall aus der Beispieldatenbank. Um einen E-Mail-Verteiler zu generieren, werden alle Praktikanten mit einem gültigen Wert für das Attribut E-Mail gesucht. Folgende SQL-Anweisung liefert die gewünschte Ergebnismenge zurück:

SELECT tblPraktikanten.[E-Mail]

FROM tblPraktikanten WHERE tblPraktikanten.[E-Mail] Is Not Null;

Über den SELECT-Befehl wird ausgewählt, welche Felder aus der Ursprungstabelle angezeigt werden sollen. Die FROM-Klausel besagt hierbei lediglich, in welcher Tabelle die Datenbank nach den entsprechenden Feldern zu suchen hat. Der WHERE-Befehl in der letzten Zeile der SQL-Anweisung gibt an, nach welchen Kriterien eine Auswahl getroffen werden soll. „Is Not Null“ stellt hier eine Access-interne Funktion dar, welche im Standard-SQL nicht zur Verfügung steht! Die nachfolgende Darstellung soll verdeutlichen, welche Werte (grau melierte Fläche) aus Sicht der Relation ausgewählt werden:

¹⁶ Ebd., S. 413

¹⁷ Ebd., S. 413

- 14 -__________________________________________________________________________________________________________

Natürlich können Abfragen auch abhängige Datensätze über mehrere Tabellen zurückliefern. Hier zur Verdeutlichung ein etwas komplexeres Beispiel:

SELECT DISTINCTROW tblBetriebe.Name

FROM tblVonBis INNER JOIN tblBetriebe ON tblVonBis.bID=tblBetriebe.bID

WHERE tblVonBis.Von Not Between forms.frmparaAvailInternships.txtVon And forms.frmparaAvailInternships.txtBis;

Die Tabellen tblVonBis und tblBetriebe werden über das gemeinsame Attribut bID miteinander per INNER JOIN verknüpft. Konkret heißt das, dass im Falle einer Übereinstimmung der Werte von bID eine Zeile mit Datensätzen aus beiden Tabellen zurückgeliefert wird.

Nachfolgend möchte ich kurz eine simple Beispielanweisung zum DELETE-, UPDATE- und INSERT-Befehl beschreiben.

DELETE FROM tblPraktikanten WHERE tblPraktikanten.pID = ‚1’;

Löscht den Datensatz aus der Tabelle tblPraktikanten, für den der Wert von pID „1“ beträgt. Der Datensatz existiert zwar augenscheinlich nicht mehr in der Datenbank, allerdings wird der dadurch gewonnene Speicherplatz nicht freigegeben! Das heißt, dass neue Datensätze nicht an die Stelle eines gelöschten Datensatzes abgelegt werden, sondern nach wie vor am Ende der Tabelle. Damit die Datenbank nicht im Laufe der Zeit unnötig viel Speicherplatz beansprucht, stellen viele DBMS eine Funktion zur Komprimierung des Datenbestandes bereit. Diese Funktion gibt den Speicherplatz wieder frei.

- 15 -__________________________________________________________________________________________________________

UPDATE tblPraktikanten SET tblPraktikanten.PLZ = ‚63820’ WHERE tblPraktikanten.pID = ‚1’;

Setzt das Attribut PLZ für den Datensatz aus der Tabelle tblPraktikanten mit dem Wert „1“ auf den Wert „63820“.

INSERT INTO tblPraktikanten (Vorname, Nachname, PLZ) VALUES („Bruno“, „Bernstein“, „63839“);

Fügt der Tabelle tblPraktikanten einen Datensatz mit den Werten für die Attribute Vorname, Nachname und PLZ an.

Unter Umständen können Änderungsabfragen aufeinander aufbauen. Käme es innerhalb solcher Abfragen zu einem Absturz des Systems, so würden Daten inkonsistent gespeichert werden, da unter Umständen nicht alle Änderungen vollzogen werden konnten. Ähnliche Probleme können sich im Mehrbenutzerbetrieb ergeben, wenn zeitgleich Änderungen an der Datenbank getätigt werden. Um diesem Effekt vorzubeugen, können mehrere Abfragen in Transaktionen gebündelt werden. Transaktionen werden von der Datenbank wie eine Abfolge einzelner Anfragen behandelt, der genaue Unterschied liegt lediglich darin dass die Abfragen in ihrer Summe zuerst auf Laufzeitfehler und mögliche Inkorrektheiten innerhalb der Datenbank geprüft werden, bevor sie in die Datenbank übernommen werden. Sollte nun ein Fehler in einer, innerhalb einer Transaktion gebündelten, Anfrage auftreten, so wird keine der bereits in der Transaktion gestellten Anfragen vom System übernommen und ein ursprünlicher (konsistenter) Datenbestand wiederhergestellt. Dies kann man auch

- 16 -__________________________________________________________________________________________________________

manuell herbeiführen, da jede Transaktion entweder mit der COMMIT- (die veränderten Daten werden unwiderruflich gespeichert) oder ROLLBACK-Anweisung (verwirft die Änderungen) abgeschlossen werden muss. 18

¹⁸ Vgl. [6] Heuer, Saake: Datenbanken - Konzepte und Sprachen, S. 298 und S. 388

- 17 -__________________________________________________________________________________________________________

3 Entwicklung und Implementierung einer Beispieldatenbank

Die externe Phase bildet eine mit den künftigen Benutzern abgestimmte Ausgangsbasis, um die drei nachfolgenden Schritte durchführen zu können. Diese Schritte fasst man auch unter dem Betriff Designmethodik zusammen. 19

Man versteht darunter einen strukturierten Ansatz, der sämtliche Hilfsmittel verwendet, um den Entwurf eines Datenmodells zu erleichtern. Dieser Vorgang wird in drei Hauptphasen unterteilt: konzeptuelles, logisches und physisches Datenbankdesign. Bevor ich diese Phasen ausführlich darstelle, möchte ich kurz deren Zusammenspiel erläutern.

Das konzeptuelle Design beinhaltet alle Informationen, die für die Konstruktion des Modells von Bedeutung sind. Es ist systemunabhängig, also nicht an Implementierungsdetails wie Programmiersprachen oder der eingesetzten Hardware gebunden. Die logische Phase bildet das konzeptuelle Schema auf ein logisches Datenmodell ab. Es ist nach wie vor systemunabhängig, liefert aber wichtige Informationen, um Entscheidungen hinsichtlich der Leistungsmerkmale bei der nachfolgenden physischen Phase abzuwägen. Zu guter letzt wird anhand des physischen Designs entschieden, „wie die Datenbank implementiert werden soll“. ²⁰ Der physische Entwurf ist also an das verwendete DBMS gebunden.

3.1 Externe Phase

Ausgangslage

Im Zuge der Praktikantenverwaltung existieren an der FOS/BOS Obernburg verschiedene, programmübergreifende Lösungen wie zum Teil auch handschriftliche Notizen. Dieses Datenarchiv dient der Verwaltung der Schüler und Betriebe wie auch der Zuordnung der anfallenden Praktika. Die Flexibilität dieses Systems bleibt wesentlich hinter den Möglichkeiten einer modernen PC-gestützten Einheitslösung mit der entsprechenden Software zurück. Die Vielfalt der aktuellen Lösungen sowie die dezentrale Archivierung der Daten hat dazu geführt, dass der Zeitbedarf bei der Verwaltung deutlich gestiegen ist.

¹⁹ Vgl. [4] Connolly, Begg, Strachan: Datenbanksysteme, S. 259

²⁰ Ebd., S. 259

- 18 -__________________________________________________________________________________________________________

Projektbeschreibung

Es soll eine einheitliche, PC-gestützte Datenbank für die FOS/BOS Obernburg konzipiert und realisiert werden. Die Anwendung soll intuitiv durch die Datenbankmasken führen und sämtliche Verwaltungsaufgaben zentral bearbeiten lassen sowie jederzeit einen Überblick über den gesamten Datenbestand liefern können. Erreicht werden soll eine Optimierung des Zeitbedarfs bei der Verwaltung der eingepflegten Stammdaten. Im Rahmen meiner Seminararbeit sollen u. a. theoretische Grundlagen sowie die Entwicklungsphasen der Beispieldatenbank ausführlich dokumentiert werden.

Anforderungen

• Für die eigentliche Datenbank soll MS Access genutzt werden. Die Nutzung für

Listen und Serienbriefe soll nach wie vor über MS Word erfolgen.

• Damit die Lösung einfach genutzt werden kann, soll eine Anwendung realisiert

werden, die einen minimalen Einarbeitungsaufwand erfordert. Expertenwissen in Access darf nicht erforderlich sein, um die Datenbank bedienen zu können. • Zusätzliche Methoden wie z. B. „Zuteilung der Schüler an die nächstgelegenen

Praktikumsbetriebe“ sollen den Verwaltungsaufwand erleichtern.

• Möglichkeit des Im- und Exports von MS Excel-Daten (Schülerlisten,

Betriebslisten, …)

• Das Berichtswesen soll weitestgehend automatisiert werden. Es sollen Verteilerlisten generiert werden können, um die Schüler per elektronischem (E-Mail) oder postalischem Wege zur Berichterstattung anzuhalten. Die eingegangenen Berichte sollen in der Datenbank hinterlegt werden. • Integriertes Formularwesen

• Selbstreparierende und automatische Funktionalitäten: Die Datenbank soll sich

selbst oder per manuellen Aufruf komprimieren.

• Ein Handbuch soll den Einstieg für neue Benutzer erleichtern.

- 19 -__________________________________________________________________________________________________________

3.2 Konzeptionelle Phase

Das Ziel der konzeptionellen Phase ist „der Aufbau eines lokalen Datenmodells für jede eigene Benutzersicht“. ²¹ Zunächst soll geklärt werden, was man unter einer Benutzersicht versteht. Diese beinhaltet alle Daten, mit denen ein Benutzer konfrontiert werden kann, wenn er mit der Datenbank arbeitet. Die Benutzersicht stellt also einen Bereich dar, der alle Arbeitsabläufe einer bestimmten Funktion beinhaltet. Das kann man gut am Beispiel einer unternehmensweiten Datenbank veranschaulichen: Hier ist es nämlich so, dass für abteilungsspezifische Aufgaben verschiedene Benutzersichten existieren, da Mitarbeiter des Controllings und Personalwesens unterschiedliche Aufgaben zu erledigen haben. Ein Benutzer kann demzufolge auch eine Gruppe von Personen darstellen, abhängig von dem jeweiligen Funktionsbereich. In Anbetracht der Beispielanwendung ergab sich allerdings nur eine Benutzersicht, da nur ein Funktionsbereich (Verwaltung der Praktika) existiert. Ergeben sich je nach Fall mehrere Benutzersichten, so definiert man für jede Sicht ein so genanntes lokales konzeptuelles Datenmodell. Dieses Modell umfasst (vgl. ²² ) - Entitätstypen, - Beziehungstypen, - Attribute, - Wertebereiche der Attribute, - Schlüsselkandidaten und - Primärschlüssel.

Diese Aufzählung wird im Folgenden Schritt für Schritt beim Entwurf des konzeptionellen Schemas bedacht und ausgeführt. Beispielhaft auf die Tabelle Praktikanten bedeutet dies, dass ich alle Attribute, die einen Praktikanten (Entitätstyp) beschreiben zusammengefasst (Attribute) und nach Beziehungen (Schlüssel- kandidaten & Beziehungstypen) zuanderen Relationen gesucht habe. Dabei ergab sich folgende Aufstellung:

• Zur eindeutigen Identifizierung muss ein Primärschlüssel pID vorhanden sein. Der Wertebereich soll hierbei automatisch fortschreitende Zahlen beinhalten. • Die Namen der Praktikanten sollen getrennt in Vorname und Nachname gespeichert werden. Für den Wertebereich ergibt sich das komplette Alphabet inklusive Sonderzeichen.

²¹ Ebd., S. 262

²² Ebd., S. 262

- 20 -__________________________________________________________________________________________________________

• Das Feld Adresse soll zur Angabe der Anschrift dienen. An dieser Stelle wäre später eine Fremdschlüssel-Beziehung über die Postleitzahl möglich. Der Wertebereich umfasst sämtliche Zeichen, da Orts- und Straßennamen wie auch Postleitzahlen gespeichert werden.

• Für jeden Praktikanten können Informationen bezüglich der Telefonnummer und E-Mail-Adresse hinterlegt werden. Für Telefonnummern sollen nicht zur Zahlen den Wertebereich definieren, sondern auch Sonderzeichen, da man Vorwahl und Anschlussnummer für gewöhnlich mit einem „/“ trennt. Für die E-Mail-Adresse gilt das Selbe.

• Jeder Praktikant ist einem schulischen Zweig zugeordnet. Dies soll ebenfalls bei der Eingabe berücksichtigt werden. Eine Fremdschlüssel-Beziehung wäre auch hier denkbar und sinnvoll. Der Wertebereich umfasst auch hier sämtliche Zeichen.

Als Schlüsselkandidaten (Attribute, über die eine potentielle Beziehung hergestellt werden könnte) wurden die Attribute PLZ und Zweig definiert. Der Primärschlüssel ist widerspruchsfrei durch das Attribut pID definiert.

Dieser Schritt wiederholt sich nun für jede abzubildende Entität. Nachdem dieser Vorgang beendet wurde, ist die Ausgangsbasis für die logische Phase geschaffen.

3.3 Logische Phase

Wie schon in Kapitel 2.1 kurz erwähnt wurde, gibt es zwei verschiedene Werkzeuge, um ein realitätsgetreues Datenmodell zu erhalten. In der logischen Phase werden die groben Konzepte, die zuvor in der konzeptionellen Phase festgelegt wurden, mittels dieser Werkzeuge verfeinert. Bevor ich mich nun aber genauer der Normalisierung und dem Entity-Relationship-Modell widmen werde, möchte ich zunächst den Unterschied zwischen einer Relation und einer Entität erläutern.

Eine Relation beruht auf Attributen, die nach den Regeln der Normalisierung zusammengestellt worden sind. Hingegen findet man in einer Entität nur diejenigen Attribute, die eine funktionale Abhängigkeit aufweisen. 23

²³ Vgl. [8] Sauer: Relationale Datenbanken - Theorie und Praxis, S. 224

- 21 -__________________________________________________________________________________________________________

3.3.1 Normalisierung

Das Hauptziel bei der Entwicklung einer relationalen Datenbank sollte sein, ein logisches Datenmodell möglichst realitätsgetreu mit all seinen Beziehungen und Einschränkungen darzustellen. E. F. Codd hat für diesen Vorgang verschiedene wissenschaftliche Formalismen zugrunde gelegt, um seine Erfahrungen einer breiten Masse zugänglich zu machen. Um festzustellen, ob die Erfordernisse einer gegebenen Normalform erfüllt oder verletzt werden, wird der Prozess der Normalisierung oft zur Validierung ausgeführt. Bei der Normalisierung werden die zugrunde liegenden Daten in verschiedene Relationen aufgeteilt, und zwar in der Art und Weise, dass sie nach dem Prozess den Normalisierungsregeln genügen. Um ein möglichst realitätskonformes Datenmodell zu gewährleisten, genügten anfangs drei Normalformen: die erste (1NF), die zweite (2NF) und die dritte (3NF) Normalform. Kurze Zeit später entwickelten R. Boyce und E. F. Codd die Boyce-Codd-Normalform (BCNF), welche eine strengere Definition der dritten Normalform darstellt. Die besprochenen Normalformen basieren ausnahmslos auf funktionalen Abhängigkeiten. Eine funktionale Abhängigkeit beschreibt die Beziehung zwischen den Attributen einer Relation. Sind beispielsweise A und B Attribute (A und B können unter Umständen auch aus mehreren Attributen bestehen) einer Relation R, so ist B von A funktional abhängig (A B), wenn jeder Wert von A genau mit einem Wert von B verbunden ist. Im weiteren Verlauf der Arbeit wird der Zusammenhang zwischen funktionaler Abhängigkeit und dem Prozess der Normalisierung ausführlich erläutert. In den Jahren 1977 und 1979 wurden von Fagit Normalformen geschaffen, die über die BCNF hinausgehen: die vierte (4NF) und fünfte (5NF) Normalform. Diese Formen behandeln jedoch Problemsituationen, die nur sehr selten auftreten. In der praktischen Anwendung genügt es, die ersten drei Formalismen anzuwenden, um ein klar definiertes Datenmodell zu erhalten. ²⁴ Oftmals werden auch aufgrund der Optimierungsschwächen des eingesetzten DBMS selbst die ersten drei Normalisierungsschritte nicht eingehalten, da es mitunter sehr schwierig und umständlich ist, bei komplexen Datenbanken diesen Prozess durchzuführen. In solchen Fällen gilt also, dass man das Datenmodell eher nach Gesichtspunkten der Performance als nach Normalisierungsregeln entwickelt.

Ein wesentlicher Aspekt der Normalisierung ist es, unerwünschte Inkonsistenzen durch DELETE, INSERT und UPDATE-Operationen zu vermeiden (Aktualisierungs-

²⁴ Vgl. [4] Connolly, Begg, Strachan: Datenbanksysteme, S. 225

- 22 -__________________________________________________________________________________________________________

Anomalien). Ich möchte nachfolgend kurz die begriffliche Bedeutung dieser Anomalien erläutern. Hierzu habe ich fiktive Tabellen abseits der Beispieldatenbank angeführt, da sich die einzelnen Sachverhalte so besser darstellen lassen.

- 23 -__________________________________________________________________________________________________________

Erste Normalform

„Eine Relation ist in der ersten Normalform (1NF), wenn alle Attribute nur atomare Werte beinhalten.“ 25

Um das Verständnis zu erleichtern, möchte ich anhand des vorangehenden Konzeptes (Praktikantenverwaltung) erläutern, wie man eine unnormalisierte Relation in die 1NF überführt.

Die hier gezeigte Tabelle befindet sich in der sogenannten nullten Normalform, da das Attribut „Adresse“ mehrere Werte getrennt durch Komma speichert und somit nicht atomar ist. Für diese Werte müssen explizite Attribute in der Relation vorhanden sein. Richtig wäre eine Aufteilung gemäß der nachfolgenden Grafik:

Diese Relation gewährleistet jedoch immer noch nicht, dass Daten nicht redundant und konsistent gespeichert werden. Deutlich wird das an dem Attribut „Ort“, denn bei mehreren Datensätzen kann der Attributwert „Hausen“ durchaus mehrfach aufgeführt werden. Dieser Umstand führt uns direkt zum nächsten Normalisierungsschritt: der zweiten Normalform.

²⁵ Vgl. [8] Sauer: Relationale Datenbanken - Theorie und Praxis, S. 218

- 24 -__________________________________________________________________________________________________________

Zweite Normalform

„Eine Relation ist in der zweiten Normalform (2NF), wenn sie sich in der ersten Normalform befindet und jedes Nicht-Schlüssel-Attribut funktional vom Gesamtschlüssel abhängig ist, nicht aber von einzelnen Schlüsselteilen.“ 26

Eine Verletzung der zweiten Normalform besteht also nur, wenn der Primärschlüssel (in diesem Fall pID) aus mehreren Attributen besteht. Anhand der vorangehenden Grafiken kann man deutlich sehen, dass der Ort mit Hilfe der Relation Orte durch eine Fremdschlüssel-Beziehung zu dem Attribut PLZ der Relation Praktikanten intern aufgeschlüsselt wird. Ähnlich verhält es sich hier mit dem Attribut Region. Auch dies sollte man im Zuge der Normalisierung in eine sekundäre Tabelle ausgliedern und über eine Fremdschlüssel-Beziehung verknüpfen.

Dritte Normalform

„Eine Relation ist in der dritten Normalform (3NF), wenn sie sich in der ersten und in der zweiten Normalform befindet. Ferner sind keine funktionalen Abhängigkeiten zwischen Attributen erlaubt, die nicht als Schlüssel definiert sind.“ 27

Die Relation darf demnach keine transitiven Abhängigkeiten aufweisen. Auf ein Beispiel muss an dieser Stelle verzichtet werden, da sich keine derartigen Problemfälle in der Beispieldatenbank ergeben haben.

²⁶ Ebd., S. 219

²⁷ Ebd., S. 220

- 25 -__________________________________________________________________________________________________________

3.3.2 Entity-Relationship-Modell

In der Praxis ist es häufig der Fall, dass die zu strukturierenden Attribute und deren Beziehungen zueinander nicht eindeutig bestimmt sind. Gerade bei größeren Datenbankprojekten ist es häufig so, dass viele Attribute noch unbekannt sind, weshalb man in einem solchen Falle zu einer anderen Methode der Datenmodellierung greift. Im Wesentlichen spricht man beim ER-Modell von der Top-Down-Methode, die sich in zwei Schritte unterteilt: (vgl. ²⁸ )

1. Die bereits bekannten Attribute werden sinngemäß einer entsprechenden Entität zugeordnet. So würde man beispielsweise alle Informationen, die direkt einen Mitarbeiter eines Unternehmens beschreiben (funktionale Abhängigkeit), der Entität „Mitarbeiter“ zuordnen. Ferner muss dafür gesorgt werden, dass die Beziehungen zwischen den einzelnen Entitäten vorhanden sind und auf semantischer Korrektheit beruhen.

2. Für die im vorhergehenden Schritt festgelegten Entitäten und Beziehungen müssen nun Attribute und Relationen definiert werden, und zwar so, dass am Ende normalisierte Relationen entstehen können.

Mittels des ER-Diagramms werden die so kreierten Entitäten und Beziehungen grafisch dargestellt. In der Literatur findet man unterschiedliche Möglichkeiten, die Darstellung der Beziehungen zu realisieren. Bei kleineren Diagrammen verwendet man für gewöhnlich eine Raute, um symbolisch die Beziehung zwischen Entitäten aufzuzeigen. Bei größeren Diagrammen eignet sich diese Möglichkeit nur bedingt, da gerade bei wechselseitigen Beziehungen der Überblick leicht verloren gehen kann. Die Beziehungen zwischen den Entitäten werden durch Linien dargestellt, die ihrerseits eine Beziehungsbezeichnung enthalten. Ich möchte das an dem zugrunde liegenden ER-Diagramm der Beispieldatenbank veranschaulichen:

²⁸ Ebd., S. 223

- 26 -__________________________________________________________________________________________________________

Die Entitäten werden mit einem Kästchen dargestellt und beinhalten alle Attribute, die die Entität beschreiben. Die Zeichen 1 und n geben in dieser Darstellung den Grad der zugrunde liegenden Beziehungen an. Prinzipiell lassen sich drei Beziehungstypen darstellen: • 1:1-Beziehung ²⁹ (Eins-zu-Eins)

Einer Entitätsmenge A ist genau ein Wert der Entitätsmenge B zugeordnet. • 1:n-Beziehung ³⁰ (Eins-zu-Viele)

Einer Entitätsmenge A können keiner, einer oder mehrere Werte einer Entitätsmenge B zugeordnet werden. • n:m-Beziehung ³¹ (Viele-zu-Viele)

Keinem, einem oder mehreren Werten einer Entitätsmenge A können keine, einer oder mehrere Werte einer Entitätsmenge B zugeordnet werden.

Die oben dargestellte Abbildung ist das Resultat dieser Überlegungen. Anhand der Beziehung von Betrieb zu Ansprechpartner lässt sich überprüfen, ob der Beziehungstyp semantisch korrekt definiert wurde: Jeder Betrieb hat keinen, einen, oder mehrere Ansprechpartner (1:n). Jeder Ansprechpartner hingegen ist wiederum einem Betrieb zugeteilt und kann dort mehreren (also n) Funktionsbereichen zugeteilt sein (z. B. der fachpraktischen Betreuung und Ausbildung).

²⁹ Ebd., S. 227

³⁰ Ebd., S. 230

³¹ Ebd., S. 231

- 27 -__________________________________________________________________________________________________________

Analog hierzu lassen sich sämtliche Beziehungen zwischen den einzelnen Entitäten derart festlegen und in einem solchen ER-Diagramm veranschaulichen. Der zweite Schritt umfasst nun die genauere Betrachtung der einzelnen Entitäten. Die Betrachtung der benötigten Attribute sollte größtenteils schon in der konzeptionellen Phase geschehen sein. Wichtig ist, dass dem ER-Modell keine Normalisierung vorausgehen muss. Man könnte allerdings an dieser Stelle die Ergebnisse der konzeptionellen Phase und des ER-Modells zusammenfassen und anhand der Normalisierung überprüfen, ob durch dieses Modell tatsächlich normalisierte Relationen entstehen.

Nachdem diese Möglichkeiten der Datenmodellierung ausgeschöpft sind und ein realitätsgetreues Datenmodell erstellt werden konnte, muss dieses in der nächsten Phase in ein DBMS implementiert werden.

3.4 Physische Phase

Die physische Phase ist der letzte Schritt im Entwurfsprozess einer Datenbank. Das realitätskonforme Datenmodell, das zuvor in der logischen Phase konstruiert wurde, wird nun angepasst, so dass es problemlos in ein DBMS implementiert werden kann. Durch die nun vorhandene Abhängigkeit zu dem ausgewählten DBMS können sich hinsichtlich Fragen der Leistungssteigerung nachträglich Änderungen am logischen Datenmodell ergeben. Die physische Phase ist demnach nicht endgültig, sondern lässt nach wie vor Spielraum für Veränderungen an der Datenstruktur. 32

Im Fall der Beispieldatenbank soll Microsoft Access als DBMS genutzt werden. Ich greife hier wieder das Beispiel aus der logischen Phase auf. Dort wurde die Relation Praktikanten ausnormalisiert, damit eine einfache Implementierung in das DBMS vorgenommen werden kann. Nachfolgender Bildschirmausschnitt soll verdeutlichen, wie das unter Microsoft Access geschieht:

³² Vgl. [4] Connolly, Begg, Strachan: Datenbanksysteme, S. 301

- 28 -__________________________________________________________________________________________________________

Abbildung 3.4.1: Definieren der Attribute einer Relation (Microsoft Access)

Über diesen Dialog lassen sich alle zuvor definierten Attribute in die Datenbank übertragen. Man sieht hier auch direkt, dass für das Attribut pID ein Primärschlüssel festgelegt wurde. Für jedes einzelne Feld (Attribut) lassen sich sinnvolle Datentypen und Wertebereiche definieren. Änderungen an dieser Struktur können jederzeit durch den Datenbankadministrator vorgenommen werden. Abschließend wird die Tabelle unter dem vorgesehenen Namen in der Datenbank gespeichert.

Für jede Relation die aus der logischen Phase hervorgegangen ist, wiederholt sich dieser Prozess. Wurden sämtliche Relationen erfolgreich übertragen, lassen sich die Beziehungen zueinander in die physische Struktur übernehmen:

- 29 -__________________________________________________________________________________________________________

Abbildung 3.4.2: Beziehungen zwischen den Relationen (Microsoft Access)

Selbst bei wenigen Relationen, die untereinander in Beziehung stehen, ergibt sich bereits ein relativ komplexes Modell. Dies intensiviert nochmals die Bedeutung der zuvor beschriebenen Schritte der konzeptionellen und logischen Phase.

Unter Microsoft Access lassen sich nur Sichten definieren, wenn die Datenbank im Netzwerk betrieben wird (Mehrbenutzerbetrieb). Dennoch dienen Formulare nicht nur der komfortablen Datenpflege, sondern sie stellen in gewissem Sinne auch eine Art Sicht für den Anwender dar. Abschließend verweise ich wieder auf das Beispiel der Tabelle Praktikanten. Im nachfolgenden Bildschirmausschnitt wird veranschaulicht, wie ein Formular zur Dateneingabe aufgebaut sein könnte:

- 30 -__________________________________________________________________________________________________________

3.5 Programmierung

Da man bei der Erstellung von komplexen Datenbankanwendungen sehr schnell an die Grenzen der Access-eigenen Funktionalitäten stößt, entsteht oft ein nicht geringer Programmieraufwand, um Problemstellungen zu lösen. MS Access bietet für solche Zwecke eine leicht abgewandelte Version von Visual Basic ³³ an, die dem Objektmodell von MS Access angepasst wurde.

Speziell im Fall der Bespieldatenbank mussten einige Anpassungen mittels VBA durchgeführt werden. Um den Rahmen meiner Seminararbeit nicht zu sprengen, werde ich lediglich eine programmierte Funktion beschreiben. Der auskommentierte Quellcode befindet sich im Anhang.

Die Beispielanwendung sollte über eine Funktion zum Datenimport aus bereits vorhandenen Excel-Tabellen verfügen. Diese Excel-Daten müssen in das CSV-Format exportiert werden. Das CSV-Format entspricht im Wesentlichen dem Textformat, mit dem Unterschied, dass einzelne Spalten durch ein Semikolon getrennt sind. Der Datenimport wurde über ein eigens entwickeltes Klassenmodul realisiert. Die Daten werden aus einer angegebenen CSV-Datei zeilenweise eingelesen und durch die Funktion StringAufbereitung() in die ursprünglichen Spalten getrennt. Wichtig ist, dass die Feldanzahl der Tabelle angepasst ist, in die importiert werden soll. Nun erfolgt gemäß dem Datentyp der einzelnen Felder aus der Zieltabelle eine Typkonvertierung,

³³ Visual Basic for Applications, kurz VBA

- 31 -__________________________________________________________________________________________________________

damit Importfehler grundsätzlich nicht auf falsche Datentypen zurückzuführen sind. Ist diese Konvertierung erfolgt, wird eine neue Zeile der Tabelle angehängt und mit den ausgelesenen Werten für die einzelnen Attribute gefüllt. Diese Funktion ist universell einsetzbar, allerdings ergibt sich im Fall der Beispieldatenbank eine Besonderheit. Da einzelne Attribute der Zieltabellen in Abhängigkeit mit Attributen aus anderen Tabellen stehen können, muss geprüft werden, ob die Werte dieser Merkmale bereits an anderer Stelle in der Datenbank vorhanden sind, um die Regeln der referentiellen Integrität nicht zu verletzen. Auch hierfür wurde eine Funktion zur Prüfung der Datenintegrität programmiert, die vor dem eigentlichen Importieren die CSV-Datei auf etwaige Inkonsistenzen prüft.

Dies ist sicherlich nur ein kleiner Ausschnitt der programmierten Funktionen. Abseits der Import-Funktion wurde ein Klassenmodul zum Versenden von E-Mails über die MAPI-Schnittstelle bzw. der installierten Outlook-Version und diverse andere Routinen erstellt, um den Umgang mit den Formularen zu erleichtern.

- 32 -__________________________________________________________________________________________________________

4 Fazit

Es muss natürlich betont werden, dass in einer 25 Seiten langen Seminararbeit keine erschöpfende Behandlung eines derart umfangreichen Themenkomplexes realisiert werden kann. Ich musste notgedrungen an einigen Stellen kürzen, obwohl ich persönlich für das tiefere Verständnis gerne noch ein paar zusätzliche Worte niedergeschrieben hätte. Dennoch denke ich, dass die Arbeit eine gute Einführung in die Arbeitsweise relationaler Datenbanksysteme liefert und - um nicht nur von „grauer“ Theorie zu sprechen - auch einen interessanten Einblick in die rasante und ebenso wichtige Entwicklung der Informatik aufzeigt.

Bevor ich mit der eigentlichen Entwicklung der Beispieldatenbank beginnen konnte, musste ich mir zunächst grundlegendes Wissen zur Programmiersprache Visual Basic for Applications (VBA) aneignen. Was zunächst als eine umfangreiche und zeitraubende Arbeit schien, entpuppte sich schnell als überaus interessante und kreative (Vor-)Leistung. Bei der Umsetzung des Gelesenen konnte ich selbst feststellen, welche Grenzen Microsoft Access hat und mir Wege erarbeiten, diese per entwickelten Code zu umgehen. Gerade im Sinne der Performance ist es an vielen Stellen wichtig, kritische Funktionalitäten selbst zu programmieren, um deren Stabilität und Funktionsweise effizienter zu gestalten.

Zur eingesehen Literatur möchte ich kurz erwähnen, dass die beschriebenen Verfahren zur Implementierung einer Datenbank von Autor zu Autor stark in der Reihenfolge und Ausführlichkeit differieren. Ich habe mich bemüht, diese verschiedenen Sichtweisen sinnvoll zu kombinieren. Die meisten Informationen konnte ich aus den Werken [4] und [8] entnehmen, die einen sehr ausführlichen Einstieg in diese Materie verschaffen. Allerdings scheint es, als ob das Kapitel Relationenalgebra generell etwas stiefmütterlich behandelt wird. Die Bücher [3] und [6] geben als Ausnahme einen sehr detaillierten Einblick in die mathematischen Konstrukte der Mengentheorie. Erstaunt hat mich die Qualität der erhältlichen Bücher zum Thema Access-Programmierung. Hier gibt es große Unterschiede, da sich die meisten Werke auf einfache Situationen und Beispiele beschränken. Aus dieser Masse sticht das Buch [1] hervor, das anhand komplexer Beispiele einen guten Einstieg in die professionelle Programmierung mit Access verschafft.

- 33 -__________________________________________________________________________________________________________

Abschließend möchte ich sagen, dass ich von dieser Arbeit sehr profitiert habe, da mir dieser wesentliche Zweig der Informatik bisher nahezu verschlossen blieb und ich persönlich beabsichtige, einen Studiengang im Bereich der Informatik zu wählen.

- 34 -__________________________________________________________________________________________________________

5 Anhang

5.1 Relationen der Beispieldatenbank und ihre Datentypen

- 35 -__________________________________________________________________________________________________________

5.2 Abfragen der Beispieldatenbank in der Detailansicht

- 36 -__________________________________________________________________________________________________________

5.3 DDL-Anweisungen

- 37 -__________________________________________________________________________________________________________

5.4 Auskommentierter Quellcode des Importmoduls

'--------------------------------------------------------------------' Klassenmodul: clsImportCSV '

' Erstellungsdatum: 3. August 2003 ' Letzte Änderung: 27. August 2003 ' Autor: Markus Günther ' Beschreibung: ' Dieses Modul ermöglicht es, beliebig große - an die jeweilige ' Feldanzahl angepasste - Datenmengen in eine Zieltabelle ' zu importieren. Sollte eine Typkonvertierung erforderlich sein, ' wird diese automatisch durchgeführt. ' ' Beispielaufruf: ' Dim clsImport As clsImportCSV ' Dim blnImport As Boolean '

' Set clsImport = New clsImportCSV '

' clsImport.Tabelle = "Tabelle" ' clsImport.Felder = 8 ' clsImport.Dateiname = "C:\Daten.csv" ' blnImport = clsImport.Importieren ' If Not blnImport Then ' MsgBox "Importieren fehlgeschlagen!", Title:="Importmodul" ' End If

^{'---------------------------------------------------------------------} OptionCompare Database

Option Explicit

Private mstrFields() As String ^{'speichert/liefert die Feldnamen} Private mstrTable As String ^{'speichert/liefert den Tabellennamen} Private mstrFileName As String 'speichert/liefert den Dateinamen

Private mintFieldCount As Integer 'speichert/liefert die Feldanzahl

Property Let Tabelle(eTable As String)

^{mstrTable = eTable} End Property

Property Get Tabelle() As String

^{Tabelle = mstrTable} End Property

Property Let Felder(intC As Integer)

^{mintFieldCount = intC} End Property

Property Get Felder() As Integer

^{Felder = mintFieldCount} End Property

- 38 -__________________________________________________________________________________________________________

Property Let Dateiname(eFileName As String)

^{'Prüft den Dateinamen auf syntaktische Korrektheit} If Left(Right(eFileName, 4), 1) <> "." ^{Then mstrFileName = eFileName & ".csv"} End If

If Right(eFileName, 4) <> ".csv" Then

^{MsgBox "Kein gültiger Dateiname!", Title:="ARKOS - Importmodul" mstrFileName = "" Else mstrFileName = eFileName} End If End Property

Property Get Dateiname() As String

^{Dateiname = mstrFileName} End Property

Public Function Importieren() As Boolean

Dim db As ^DAO.Database Dim rst As ^{DAO.Recordset} Dim strZeile As String Dim intTemp As Integer Dim intCounter As Integer Dim strFeldTyp As String Dim ff As Integer

On Error GoTo err_Importieren

'Datenbankobjekte festlegen

Set ^{db = CurrentDb()} Set rst = db.OpenRecordset(mstrTable)

ff = FreeFile

Open mstrFileName For Input As ^ff While Not EOF(ff) 'Lese bis Dateiende

strFeldTyp) ^{Next rst.Update} Wend Close #ff rst.Close

- 39 -__________________________________________________________________________________________________________

^{'Rückgabewert der Funktion, sofern die Daten korrekt importiert werden konnten} Importieren = True Set rst = Nothing Set db = Nothing Exit Function

err_Importieren:

^{'Rückgabewert der Funktion, sofern ein Fehler aufgetreten ist} Importieren = ^{False rst.Close} Set rst = Nothing Set db = Nothing Exit Function End Function

Public Sub StringAufbereitung(eZeile As String)

Dim strTemp As String Dim strChar As String Dim intCounter As Integer Dim i As Integer

^{'erneute Dimensionierung, angepasst an die Feldanzahl} ReDim mstrFields(mintFieldCount) intCounter = 1 i = 0

While Not ^{intCounter = Len(eZeile) 'zeichenweise die Zeile einlesen strChar = Mid(eZeile, intCounter, 1)} If strChar = ";" Then

Else

^{strTemp = strTemp & strChar End If intCounter = intCounter + 1} Wend

^{'Array komplettieren und letztes Zeichen anfügen mstrFields(i) = strTemp & Right(eZeile, 1)} End Sub

Public Function Typumwandlung(eVar As String, eTblF As String) As Variant Select Case ^eTblF Case "Boolean": Typumwandlung = CBool(eVar) Case "Byte": Typumwandlung = CByte(eVar) Case "Integer": Typumwandlung = CInt(eVar) Case "Long Integer": Typumwandlung = CLng(eVar)

- 40 -__________________________________________________________________________________________________________

Case "Währung":

Typumwandlung = CCur(eVar) Case "Single": Typumwandlung = CSng(eVar) Case "Double": Typumwandlung = CDbl(eVar) Case "Datum": Typumwandlung = CDate(eVar) Case "Text":

Case "Binärdaten":

Case "Memo":

Case "GUID":

Case ^"Unbekannt": End Select End Function

Public Function FeldTyp(fld As DAO.Field) As String

Select Case ^fld.Type Case ^{dbBoolean: FeldTyp = "Boolean"} Case ^{dbByte: FeldTyp = "Byte"} Case ^{dbInteger: FeldTyp = "Integer"} Case ^{dbLong: FeldTyp = "Long Integer"} Case ^{dbCurrency: FeldTyp = "Währung"} Case ^{dbSingle: FeldTyp = "Single"} Case ^{dbDouble: FeldTyp = "Double"} Case ^{dbDate: FeldTyp = "Datum"} Case ^{dbText: FeldTyp = "Text"} Case ^{dbLongBinary: FeldTyp = "Binärdaten"} Case ^{dbMemo: FeldTyp = "Memo"} Case ^{dbGUID: FeldTyp = "GUID" Case Else FeldTyp = "Unbekannt"} End Select End Function

- 41 -__________________________________________________________________________________________________________

5.5 Glossar

- 42 -__________________________________________________________________________________________________________

- 43 -__________________________________________________________________________________________________________

Literaturverzeichnis

1. Albrecht, Nicol: Access 2002 programmieren, München, Addison-Wesley Verlag, 2002.

2. Bauder, Bär: Access 2002 Programmierung, München, Hanser Verlag, 2002. 3. Biskup: Grundlagen von Informationssystemen, Friedr. Vieweg & Sohn Verlagsgesellschaft mbH, 1995.

4. Connolly, Begg, Strachan: Datenbanksysteme, 1. Aufl., München, Addison-Wesley Verlag, 2002.

5. Herbolsheimer: Datenbank-Programmierung, 1. Aufl., München, Addison-Wesley Verlag, 2002.

6. Heuer, Saake: Datenbanken - Konzepte und Sprachen, 1. korrigierter Nachdruck, Himberg, International Thomson Publishing GmbH, 1997. 7. Meier: Relationale Datenbanken, 4. Aufl., Berlin, Springer-Verlag, 2001. 8. Sauer: Relationale Datenbanken - Theorie und Praxis, 5. Aufl., München, Addison-Wesley Verlag, 2002.

Abbildungsverzeichnis

Sämtliche Grafiken wurden eigens mit Adobe Photoshop erstellt.

Quellennachweis:

Abbildungen 1.1-1.3, 2.1.1 wurden dem Werk [6] Datenbanken - Konzepte und Sprachen entnommen.

Abbildungen 2.2.1-2.2.6 wurden dem Werk [7] Relationale Datenbanken entnommen.

- 44 -__________________________________________________________________________________________________________

Erklärung

Ich versichere hiermit, dass ich diese Arbeit selbständig angefertigt und keine anderen als die von mir angegebenen Quellen und Hilfsmittel verwendet habe. Die den benutzten Werken wörtlich oder inhaltlich entnommenen Stellen sind als solche gekennzeichnet.

Ort, Datum, Unterschrift:

______________________________________________________