Die bisher von uns erstellten Datenbanken bestanden immer aus einer Tabelle, in der sämtliche Daten der Datenbank gespeichert waren. In der Praxis wird dies aber eher die Ausnahme als die Regel darstellen. Wird die einzelne Tabelle zu komplex empfiehlt es sich Daten in neue Tabellen auszulagern. Dafür sprechen vor allem die folgenden beiden Gründe:
- Nehmen wir einmal an, dass unsere Reiseagentur zusätzlich zu den Kunden auch noch die zu den entsprechenden Kunden zugehörigen Rechnungen speichern möchte. Dann müsste immer wenn eine neue Rechnung hinzukommt ein neues Datenfeld hinzugefügt werden. Dies ist jedoch äußerst problematisch, da man in diesem Fall den Entwurf der Tabelle verändern muss. Bei nachträglichen Veränderungen an der Struktur einer Tabelle ist immer äußerste Vorsicht geboten. (Für Interessierte: Die Datensätze werden im Speicher des Computers intern in Listen, Hash-Tabellen bzw. in Bäumen gespeichert. Die einzelnen Elemente der Liste liegen wahllos im Speicher verstreut, da ein neues Listenelement immer erst bei Bedarf angelegt und damit auch der erforderliche Speicherplatz angefordert wird. Der Verweis von einem Element der Liste auf das Nächste wird mit Zeigern [englisch pointer] realisiert. Ein einzelner Datensatz stellt einen sogenannten record dar. Die Struktur des Records muss beim Erstellen der Tabellen als spezieller Typ deklariert werden. Will man nun ein neues Datenfeld aufnehmen, so muss die Typdeklaration geändert werden. Diese Änderung muss dann auf die wahllos im Speicher verstreut liegenden Listenelemente übertragen werden. Dies stellt einen hohen programmtechnischen Aufwand dar, den man nach Möglichkeit vermeiden sollte.)
Es wird sicherlich Kunden geben, die öfter mit unserem Reisebüro verreisen werden, andere dafür weniger oder vielleicht auch nur einmal. Trotzdem muss der Speicherplatz beim Hinzufügen von neuen Rechnungen für alle(!) Kunden reserviert werden, unabhängig davon ob dieser Speicherplatz wirklich für alle Kunden benötigt wird oder nicht. Bei sehr großen Datenbanken mit eventuell mehreren tausend Datensätzen kann der dadurch verschwendete Speicherplatz sehr groß und damit teuer sein (Datenbankserver sind hochspezialisierte Rechner und damit sehr teuer [siehe Abbildung]).
Wenn man nun einen Teil der Daten in neue Tabellen auslagern möchte, müssen Beziehungen zwischen den einzelnen Tabellen hergestellt werden. Es muss z.B. erkennbar sein, welche Rechnung zu welchem Kunden gehört. Diese Beziehungen werden über die in den Tabellen vereinbarten Schlüssel realisiert.
Außerdem ist es notwendig, dass man sich schon vor dem Erstellen einer solchen komplexen Datenbank ausführlich Gedanken über die Struktur der zu erstellenden Datenbank macht. Dafür entwickelte der Informatiker Peter Chen im Jahr 1973 das sogenannte Entity - Relationship - Modell. Dieses Werkzeug zur Modellierung von Datenbanken hat sich international durchgesetzt.
- Wir wollen nun gemeinsam zunächst ein ER - Modell für unsere veränderte Datenbank Reiseagentur entwerfen und dann mit Hilfe von Access umsetzen.
- Zunächst wollen wir unsere Tabelle Reisen in Kunden umbenennen um deutlich zu machen, dass in ihr lediglich Angaben zu den Kunden, nicht jedoch zu den Reisen enthalten sind.
- Als nächstes benennen wir im Entwurf der Tabelle das Datenfeld LfdNr der Deutlichkeit halber in KundenID um.
Jetzt erstellen wir einen neue Tabelle Rechnungen. Sie soll folgende Datenfelder enthalten:
Feldname Felddatentyp Beschreibung RechnungID Autowert Primärschlüssel Datum Datum/Uhrzeit - KundenNR Zahl Fremdschlüssel Betrag Währung - Bezahlt Ja/Nein - Jetzt füllen wir unsere neue Tabelle mit einigen Daten:
RechnungID Datum KundenNR Betrag Bezahlt 1 15.03.01 5 236,25 € ja 2 18.04.01 2 1543,25 € ja 3 14.06.01 4 1059,50 € ja 4 23.07.01 6 2156,30 € ja 5 21.11.01 2 236,25 € nein Nun folgt der schwierigste Teil. Wir müssen eine 1 : n - Beziehung zwischen der Tabelle Kunden und der Tabelle Rechnungen herstellen. Dabei zeigt der Fremdschlüssel KundenNR der Tabelle Rechnungen auf den Primärschlüssel KundenID der Tabelle Kunden.
Außerdem sollten wir unbedingt auch eine referenzielle Integrität für diese Beziehung fordern. Darunter versteht man, dass für jeden Wert eines Datenfeldes, das als Fremdschlüssel definiert ist, ein entsprechender Wert in der damit verbundenen Tabelle vorhanden sein muss. Es darf also z.B. nicht vorkommen, dass in der Tabelle Rechnungen ein Kunde 345 angegeben ist, der in der Tabelle Kunden nicht existiert. Das DBMS hat dabei folgende zwei Aufgaben zu erfüllen:
- Wird in der Tabelle Rechnungen ein neuer Datensatz eingefügt, dann muss sichergestellt werden, dass für den Wert in KundenNR ein Datensatz in der Tabelle Kunden vorhanden ist.
- Wird in der Tabelle Kunden ein Datensatz gelöscht, dann muss das DBMS prüfen, ob es in der Tabelle Rechnungen Einträge gibt, die auf diesen Datensatz verweisen.
- Auch unsere Datenbank Adressen wollen wir nun ein wenig abändern. Durch das ständige Hinzufügen weiterer Kommunikationsmöglichkeiten (Fax, E-Mail, Handy1, Handy2, ...) würde auch diese Tabelle weiter nach rechts wachsen. Also wollen wir die Kontaktarten in eine neue Tabelle Kontakte auslagern.
- Entwerfen Sie zunächst ein ER-Modell für unsere neue Datenbank Adressen! Überlegen Sie welcher Beziehungstyp vorliegt!
- Benennen Sie die Tabelle Adressen in Person um!
Erstellen Sie eine neue Tabelle Kontakte mit folgender Struktur:
Datenfeld Datentyp Beschreibung LfdNr Zahl Fremdschlüssel Kontaktart Text -Kontaktwert Text -Jetzt füllen wir unsere neue Tabelle mit einigen Daten:
LfdNr Kontaktart Kontaktwert 1 Telefon 0398512 1 Fax 0398185 1 Handy 01754893 1 E-Mail toni@taste.de Ergänzen Sie selbständig noch einige weitere (Fantasie)Daten!
- Stellen Sie nun die Beziehung zwischen den beiden Tabellen her und überprüfen Sie, ob Ihre Aktion erfolgreich war!
Eine Seite von Mirko Hans