Gut bei allem ist die Ordnung: Datenbank-Planung und Realisierung, Teil 2
Im ersten Kursteil leisteten wir die Vorbereitungsarbeiten für den Entwurf einer Datenbank. Jetzt gehen wir »in medias res«. Anhand einer Bestandsverwaltung setzen wir unser erworbenes Wissen in die Praxis um.
Im Zuge der Auswertung gesammelter Informationen entsteht als erstes die Datenbankstruktur.
Jede Datenbank besteht aus einer oder mehreren »logischen Dateien«. Das sind die Karteikästen der Karteiorganisation. Die »Datensätze«, also die Karteikarten einer solchen logischen Datei, dürfen über mehrere Seiten gehen, müssen aber je Seite ein einheitliches Gesicht haben - die »Maske«. Als Besonderheit von Datenbanken dürfen verschiedene logische Dateien miteinander verknüpft werden. Daraus ergeben sich bestimmte Anforderungen an die Unterteilung in logische Dateien. Das Ergebnis ist die Datenbankstruktur.
Erinnern wir uns an die Aufgabenstellung: »Eine Datenbank soll Adressen und Termine verwalten. Für später ist die Übernahme einer Bestandsverwaltung vorzusehen.« Um Adressen und Termine zu verwalten, können wir zum Beispiel auf die konventionelle Lösung zurückgreifen und eine einzige logische Kartei »Adressen« anlegen. Die erste Seite der Maske (Vorderseite der Karteikarte) enthält alle Adreßangaben, die zweite Seite (Karteikartenrückseite) dazugehörige Terminangaben. Erledigte oder abgesagte Termine sind zu löschen, geänderte zu überschreiben. Gegenüber konventionellen Lösungen bietet eine solche Datenbank den Vorteil, daß Sie die Kartei nach den verschiedensten Sortierkriterien aufbereiten, nach unterschiedlichen Sortiermerkmalen suchen und Ausdrucke anfertigen dürfen. Dieser Lösungsansatz hat jedoch einen gravierenden Schönheitsfehler: Geänderte Termine erscheinen unsortiert. So können etwa alte Termine unten stehen und nachgetragene oder geänderte (überschriebene) irgendwo zwischendrin.
Es empfiehlt sich also, die Datenbank um eine zweite logische Datei »Termine« zu erweitern. Die Datei »Adress« enthält alle Adreßangaben, die Datei »Termin« je Datensatz einen dazugehörigen Termin. Damit sind beide logischen Dateien sachgerecht sortierbar. Aber wie finden wir nun von den Adressen zu den Terminen und umgekehrt? Datenbanken machen's möglich. Hier können Sie unterschiedliche logische Dateien miteinander verknüpfen. Dazu müssen die zu verbindenden Dateien (Karteien) über mindestens ein gleiches Merkmal verfügen, ein sogenanntes Karteieintragsfeld. Wir können beispielsweise die beiden logischen Dateien mit dem Namen verknüpfen. Zu jedem Namen existieren dann ein Adreß-Datensatz und Termin-Datensätze. So kommen wir über den Namen zu den zugehörigen Terminen und umgekehrt. Ob nur einer oder beide Zugriffswege erlaubt sind, bestimmen wir beim Anlegen der Datenbank.
Bisher haben wir mit einfachen Adressen gearbeitet. In der Praxis gehören jedoch häufig zu einer Adresse mehrere Ansprechpartner, oder ein Kunde hat mehrere Lieferanschriften. Nehmen wir an, mit unterschiedlichen Ansprechpartnern der gleichen Adresse (Firma) wären Termine auszumachen. Für Datenbanken ist das kein Problem. Wir legen die dritte logische Datei »Partner« an. Die zugehörigen Datensätze enthalten den Namen des Partners, seine Telefonnummer und die Adresse. Damit finden wir von den Adressen zu den Partnern oder den Terminen, von den Partnern zu den Terminen oder Adressen bzw. von den Terminen zu den Adressen oder Partnern - und umgekehrt.
Die gemeinsame Anbindung dreier Dateien über nur ein Verbindungsmerkmal ist in der Praxis meist nicht sinnvoll. Besser ist es, »Partner« und »Termin« über ein spezielles Verbindungsmerkmal zu verknüpfen. Hierfür ist zum Beispiel der Partner-Name zweckmäßig. Dann können wir nämlich von der Adresse zum Partner und von dort auf die zugehörigen Termine zugreifen oder auch umgekehrt. Einzige Bedingung hierfür ist, daß sowohl die Partner- wie auch die Termin-Datei neben einem gemeinsamen Adreßfeld auch über ein gemeinsames Partnerfeld verfügen. Mit dieser letzten Struktur ist die Forderung des ersten Satzes der Aufgabenstellung erfüllt.
Im zweiten Satz der Aufgabenstellung heißt es aber, daß für später die Erweiterung um eine Bestandsverwaltung vorzusehen ist. Wir müssen daher diese Struktur gedanklich um eine solche Bestandsverwaltung erweitern. Bisher sind wir ganz allgemein vorgegangen, das heißt, wir mußten uns zum besseren Verständnis keinen speziellen Anwender vorstellen. Die nun folgenden Überlegungen werden leichter, wenn wir annehmen, die Datenbank wäre für einen KFZ-Händler bestimmt. Er handelt mit Neu-, Gebraucht- und Kommissionswagen.
Wir legen jetzt eine vierte logische Datei (Kartei) »Bestand« an. Führte der Händler nur Neu- und Gebrauchtwagen, könnte diese Datei für sich allein stehen. Aber er führt auch Kommissionswagen. Zu diesen gehört ein Eigentümer. Deshalb verbinden wir die Bestandsdatei über den Namen mit den Adressen bzw. Partnern. Dabei entsteht zwangsläufig auch eine Anbindung an die Termine, was zum Beispiel im Zusammenhang mit der Speicherung von Vorführungszeitpunkten nützlich ist.
Die Unterscheidung von Neu- und Gebrauchtwagen erreichen wir in der Bestandsdatei beispielsweise über ein Feld mit dem Tachostand. Kommissionswagen kennzeichnen wir durch einen entsprechenden Eintrag, etwa im Namens-Feld.
Bestände müssen nicht immer vorrätig sein. Nehmen wir einmal an, daß zu einer Adresse ein Partner und von diesem ein Vorführtermin zu suchen ist. Dann wäre es sinnvoll festzustellen, ob auch der gewünschte Wagen auf Lager ist. Aus den bestehenden Verbindungen ist diese Verzahnung aber nicht herstellbar. Also müssen wir »Termin« und »Bestand« miteinander verbinden. Wir benötigen hierzu für beide Masken ein Merkmal »Typ«.
Schlüssel und Verbindungen
Verbindungen haben wir bereits bei der gedanklichen Entwicklung der Datenbankstruktur kennengelernt. Zur Struktur gehört aber auch das Festlegen von Schlüsseln.
Verbindungen sind Schlüsselfelder, die unterschiedliche logische Dateien (Karteien) miteinander verknüpfen. Die Masken der beteiligten Dateien müssen gleiche Schlüsselfelder mit sich entsprechenden Einträgen haben. Der Datentyp dieser Schlüsselfelder muß identisch sein, gleich ob Text, Zahl oder Termin. In Datenbanken versteht man unter Schlüsseln Such-und Sortiermerkmale. Am einfachsten erklärt sich der Sinn eines Schlüssels am Stichwortverzeichnis. Hier sind einzelne Stichworte alphabetisch aufgelistet und mit einem Hinweis auf die Fundstelle versehen. Die Logik ist eindeutig: Suchmerkmal ist das Stichwort, sortiert wird alphabetisch. Der Fundstellenhinweis zeigt, wo Aussagen zu finden sind.
Datenbanken bedienen sich der gleichen Logik. Felder, nach denen wir sortieren oder suchen wollen, legen wir als Schlüssel an. Der Inhalt solcher Schlüsselfelder ist in »Indexbäumen« organisiert, um schnelle Zugriffe zu gewährleisten. Die meisten Programme sortieren die Daten
- in aufsteigender Reihenfolge, also A-Z, a-z, 0-9
- in absteigender Reihenfolge, also Z-A, z-a, 9-0
Manche Datenbankprogramme gestatten auch ein sequentielles Sortieren. Genau genommen findet dann gar kein Sortiervorgang statt, sondern die Datensätze erscheinen in der Reihenfolge ihrer Eingabe. Datenbankprogramme unterscheiden mehrere Datentypen. Die wichtigsten sind:
- Text: Zeichenkette (Buchstaben und/oder Ziffern)
- Zahl: Ganz-, Dezimal- oder Währungszahl
- Termin: Datum oder Uhrzeit
Textschlüssel beanspruchen den meisten Platz, sowohl in den Datensätzen als auch in den Indexbäumen. Ihr Erfassen, Ändern oder Löschen beansprucht die meiste Zeit, weil der Neuaufbau zugehöriger Indexbäume zeitraubend ist. Aus diesem Grund sollte man mit Textschlüsseln möglichst sparsam umgehen. Andererseits bieten sie den großen Vorteil, daß wir bei ihnen nach Fragmenten suchen dürfen. Dabei forscht die Datenbank nicht nach dem vollständigen Suchbegriff, sondern nach einem verstümmelten. Für fehlende Zeichen oder Zeichengruppen schreibt man einen sogenannten Platzhalter, etwa ein Fragezeichen.
Einfache Schlüssel sind normale Datensatzfelder, die als Schlüssel oder Verbindung deklariert wurden. In einem Datensatz bzw. in einer Maske sind mehrere Schlüsselfelder zulässig - ein wichtiger Unterschied zur konventionellen Karteiorganisation. Ob man immer nur nach einem oder gleichzeitig nach mehreren Schlüsselfeldern sortiert, hängt vom Datenbankprogramm ab. Schlüsselfelder, die zugleich Verbindung sind, haben gegenüber anderen Priorität.
Das leidige Platz- und Zeitproblem der Textschlüssel können Sie oft durch passende Spezialschlüssel entschärfen. Dabei bleibt der Schlüssel zwar ein Textfeld, dieses wird aber intelligenter benutzt. Nehmen wir einmal an, wir sind Händler und bieten Artikel unterschiedlicher Gruppen an. Für Werbezwecke hilft es uns zu wissen, welcher Kunde an welcher Artikelgruppe interessiert ist. Stellen wir uns weiter vor, daß unser Artikelsortiment aus neun Gruppen besteht. In diesem Fall reicht zur Klassifizierung ein achtstelliges Textfeld.
Die Artikelgruppen drücken wir durch 1 bis 9 aus bzw. durch 0 für alle. Interessiert sich ein Kunde für die Artikelgruppen 1, 3, 4, 7 lautet sein Eintrag: »Status: 1347«. Interessiert sich der Kunde für alle Artikel, lautet der Eintrag »0«.
Wollen wir, etwa im Rahmen einer Werbeaktion, alle Kunden suchen, die an den Artikelgruppen 1, 2, 4, 9 interessiert sind, fragen wir nach:
Status = 0 oder 1 oder 2 oder 4 oder 9
Den obige Eintrag findet das Programm in jedem Fall. Zusammengesetzte Schlüssel bieten einen weiteren Ansatz zur Lösung der Textschlüsselproblematik. Auch sie sind Textschlüssel, setzen sich aber aus Fragmenten mehrerer Einzelfelder zusammen. Als typisches Beispiel für einen solchen zusammengesetzten Schlüssel sei die Kundenkennung genannt. Aus Rechnungen kennen wir die sogenannte Kunden-Nummer. Sie ist in ihrer ursprünglichen Form ein Relikt aus der Zeit, als Buchungsmaschinen noch keine alphanumerischen Begriffe verarbeiteten. Aber welcher Kunde gibt schon bei der Korrespondenz oder Zahlung seine Kunden-Nummer an? Wollen wir dann einen Vorgang richtig zuordnen, brauchen wir erst die Kunden-Nummer aus einer Hilfsdatei. Viel sinnvoller wäre also ein Schlüssel, dessen Inhalt sich in jedem Fall rekonstruieren läßt.
Eine denkbare Kombination für eine solche Kundenkennung ist in Bild 8 dargestellt. Sie entstand aus der Adresse »Irgendwer, Jawodenn Str. 12, 1234 Irgendwo« und enthält Fragmente des Namens, der Straße sowie die Postleitzahl und Haus-Nummer. An Stelle der Straße und Haus-Nummer kann auch eine Postfach-Nummer treten. Bei Abfragen ist meist schon mit dem Namensfragment und der Postleitzahl ein Zugriff möglich. Es gibt aber auch Allerweltsnamen wie Huber, Krause, Maier, Mayer, Meier, Schneider, Schulze usw. Hier erweisen sich die Straße und gegebenenfalls auch die Haus-Nummer als nützlich. Ein weiteres Beispiel für einen zusammengesetzten Schlüssel ist die Artikel-Nummer. Im Bild 9 wurden mehrere Aussagen zu einem Artikel zusammengefaßt. Der Schlüssel steht für »PC, Atari, lfd.Nr. 123, Lager 1« und enthält Bestandteile der Artikelgruppe und Bezeichnung sowie die »lfd.Nr« und Lager-Nummer. Auch hier sind Zugriffe sehr schnell und nach den unterschiedlichsten Kriterien möglich. (tb)
Kursübersicht
Teil 1: Was ist eine Datenbank? □ wichtige Unterschiede zwischen Kartei und Datenbank □ Vorbereitungsarbeiten
Teil 2: Entwurf der Datenbankstruktur □ Schlüssel und Verbindungen
Teil 3: Entwurf der Masken □ View und Join □ Pflichtenheft
Hans Körner