Beziehungskiste

m:n-Verbindungen mit Lotus Approach 3.0

Am Anfang war der Frust. Der Umstieg vom kleinen, billigen Atari auf den viermal so teuren, angeblich achtmal schnelleren PC erwies sich, was die Verwaltung der Adressen betraf, die sich im Lauf der Jahre angesammelt hatten, als Flop. Der Windows-Karteikasten war höchstens als Spielzeug zu gebrauchen, und kommerzielle Adreßverwaltungen (selbst die, deren Preis schon an den des Atari heranreichten) konnten, bis auf ein paar mehr Felder und ausgefeilte Druckfunktionen, die ich nicht benötigte, auch nicht viel mehr.

Unterthema: Formular-Design
Unterthema: Aus eins mach zwei - und mehr

Vor allem die Hoffnung, auf der nun viermal größeren Bildschirmfläche nicht nur viermal soviel Daten, sondern auch ihre komplexen Beziehungen darstellen zu können, war damit nicht zu verwirklichen. Dann gab es ein Sonderangebot von Lotus Approach, einer Datenbank, die zwar keine Volltextsuche kennt, keine echte Makrosprache besitzt (zwei echte Nachteile) und in puncto Geschwindigkeit weit hinter `1st Address´ auf dem Atari zurückbleibt, doch immerhin mit mehreren Tabellen arbeiten kann. Seither habe ich, unter tausenden Flüchen und hundertfach geäußerter Absicht (auch einiger Anläufe), auf eine `richtige´ Datenbank umzusteigen, die Approach-Anwendung kontinuierlich aufgerüstet - und dabei entdeckt, daß Approach viel mehr kann, als es zu Anfang den Anschein hat.

Adreßverwaltungen mögen Vorteile auf vielen kommerziellen Einsatzgebieten besitzen. Wenn es um die Darstellung von Beziehungen zwischen den Daten geht, sind sie (ebenso wie einfache Datenbankprogramme) überfordert. Das kommt daher, weil sie alle Daten in nur einer Tabelle verwalten - sie betrachten die Welt quasi durchs Nadelöhr einer Tabellenzeile. Denn in solch einer Zeile müssen alle Daten, die eine Beziehung zueinander haben, Platz finden. Moderne, relationale Datenbanken benutzen dagegen mehrere Tabellen, deren Datensätze nach bestimmten Regeln miteinander verbunden werden. Bei zwei Tabellen, die nach dem Schema 1:n (Eins-zu-Viele) verknüpft sind, ist eine Zeile der ersten Tabelle mit beliebig vielen Zeilen der zweiten über ein spezielles Verbindungsfeld gekoppelt. So lassen sich beispielsweise Familienverhältnisse beschreiben: Eine Mutter kann mehrere Kinder haben, jedes Kind aber nur eine Mutter. Die untergeordneten Tabellen werden deshalb auch Kind-Tabellen genannt.

Anders in der Schule: hier unterrichtet jeder Lehrer viele Schüler, und jeder Schüler wird von mehreren Lehrern unterrichtet. Das abzubilden schafft eine 1:n-Beziehung nicht mehr. Viele-zu-Viele-(m:n-)Verbindungen sind in der realen Welt eigentlich die Regel. Etwa in Betrieben: `Karrieren´, also die wechselnde Zugehörigkeit von Personen zu Firmen oder der berufliche Aufstieg innerhalb einer Firma, lassen sich mit 1:n-Verbindungen nur schwer erfassen. Bei zwei m:n-verbundenen Tabellen wird dagegen sofort sichtbar, welche Position eine bestimmte Person zu einem bestimmten Zeitpunkt eingenommen hat. Dazu bedarf es in der Verbindungstabelle lediglich zweier weiterer Felder, welche die Anfangs- und Endzeitpunkte der Tätigkeit aufnehmen.

Will man seine Daten unter verschiedenen Blickwinkeln betrachten, ist eine Datenbank, die m:n-Verbindungen beherrscht, also unerläßlich. Der Arbeitsaufwand - verglichen mit dem Einsatz fertig konfektionierter Adreßprogramme - kann jedoch beträchtlich sein. Datenbanken ähneln Baukästen, aus denen die fertige Anwendung erst gebastelt werden muß. Und m:n-Verbindungen gehören auch bei Lotus Approach oder MS Access zu den Funktionen, die sich nicht gerade einfach handhaben lassen.

Es sei nicht verschwiegen, daß es auf dem Softwaremarkt auch Datenbankprogramme gibt, die bereits von Haus aus auf das Verwalten von Daten, zwischen denen komplexe Beziehungen bestehen, zugeschnitten sind: AskSam beispielsweise oder InfoCentral. Doch gerade letzteres Programm, das im Verwalten von Beziehungen bisher wohl unschlagbar scheint, hat entscheidende Mängel bei der Darstellung der Daten auf dem Bildschirm. Wenn man auf eine übersichtliche Tabellendarstellung und individuell gestaltete Masken Wert legt, kommt man um den Eigenbau aus der großen Datenbank-Kiste leider immer noch nicht herum.

Teile und verbinde

Der erste Schritt auf dem Weg zur `Beziehungskiste´ besteht darin, die Adreßdaten in zwei 1:n-verbundene Tabellen aufzuspalten. Das läßt sich in Approach wie auch in anderen Datenbanken recht einfach vollziehen. Die Tabellen heißen in unserem Beispiel nach den in ihnen gespeicherten Objekten Firmen und Personen, das Verbindungsfeld, das in beiden Tabellen vorkommen muß, ist das Feld Firma. Auch die Verwaltung der zwei so verbundenen Tabellen unter einer einheitlichen Oberfläche macht noch keine Schwierigkeiten. Approach bietet die Möglichkeit, in Formulare, die auf der 1-Tabelle beruhen, Untertabellen mit den Daten aus der n-Tabelle aufzunehmen. Darin lassen sich sowohl neue Datensätze in der n-Tabelle anlegen als auch bestehende ändern. Wenn alle Daten des n-Datensatzes (also hier einer Person) in eine Zeile der Untertabelle passen, braucht man nicht unbedingt ein zweites, auf der Personen-Tabelle beruhendes Formular. Das wird jedoch nur selten der Fall sein. Insbesondere dann, wenn man auch Personen speichern will, die zu keiner Firma gehören, ist das Personen-Formular zwingend notwendig.

Existiert solch ein zweites Formular, muß man schnell zu diesem (und zurück) wechseln können, ohne die miteinander verbundenen Daten aus dem Auge zu verlieren. Dies gewährleisten die Datenbankprogramme automatisch: Wählt man eine Person in der Untertabelle von Firmen und wechselt ins Personen-Formular, so wird die gewählte Person dort angezeigt. Approach bietet zudem die (im Handbuch nicht erwähnte) Möglichkeit, in Untertabellen Buttons aufzunehmen, die dann in jeder gefüllten Zeile angezeigt werden. Verbindet man den Button mit einem Makro, das zur Ansicht Personen und dort zum aktuellen Datensatz wechselt, wird diese Funktion intuitiv bedienbar.

Nun aber zu den m:n-Verbindungen, um die es eigentlich geht. Auf den ersten Blick sollte es genügen, in die Firmen-Tabelle ein zusätzliches Verbindungsfeld Person aufzunehmen, um aus der 1:n- eine m:n-Verbindung zu machen. Das führt jedoch nicht zum Ziel, wie eine einfache Überlegung zeigt: In einer 1:n-Verbindung zwischen f Firmen und p Personen kann es maximal p Verbindungen geben (jede Person kann zu maximal einer Firma gehören). Die Verbindungsinformationen haben also in den p Datensätzen der Personen-Tabelle Platz. In einer m:n-Verbindung kann es dagegen maximal f × p Verbindungen geben (jede Firma ist mit jeder Person verbunden). In der Firmen-Tabelle haben jedoch, wenn jede Firma nur einmal auftauchen darf, lediglich f zusätzliche Verbindungsinformationen Platz.

Aus diesem Grund wird für eine m:n-Verbindung eine dritte Tabelle nötig, welche nur die Verbindungsinformationen enthält. Sie ist mit beiden Tabellen über eine 1:n-Relation verbunden, wobei sie in beiden Fällen die n-Seite darstellt.

Außer zur Aufnahme der Verbindungsinformation dient die m:n-Tabelle aber auch noch anderen Zwecken: In ihr sollten alle Daten gespeichert werden, die nur mit der Verbindung zwischen Firma und Person etwas zu tun haben. Funktion und dienstliche Telefonnummer sind beispielsweise solche Daten, die weder zur Firma noch zur Person gehören, sondern zur Verbindung zwischen beiden.

Die Verbindungsinformation selbst könnte in der m:n-Tabelle als Gegenüberstellung der Klarnamen von Firma und Person gespeichert werden. Da Personennamen normalerweise nicht eindeutig sind, würde dies jedoch zu Doppeldeutigkeiten führen. Also müßten zusätzlich zumindest der Vorname und wahrscheinlich noch eine weitere Angabe in die Verbindungstabelle aufgenommen werden. Der bessere Weg ist die Verwendung von Identitätsnummern (IDs). Diese könnten beispielsweise FID (Firma-ID) und PID (Person-ID) heißen. Das Anlegen und Verwalten von IDs übernehmen die Datenbankprogramme selbst, meist werden diese gleichzeitig als Primärschlüssel verwendet. ID-Nummern sparen zudem Speicherplatz in der Verbindungstabelle. Sie haben jedoch auch einen ganz entscheidenden Nachteil: Sie schützen nicht gegen das Anlegen von Namens-Dubletten. Ein Namensfeld, das als `eindeutig´ definiert ist, kann nicht zweimal den gleichen Inhalt erhalten. Das ist anders, wenn nicht der Name, sondern die ID das Schlüsselfeld darstellt. Um zu verhindern, daß eine Person zweimal, jedoch mit unterschiedlichen PIDs, erfaßt wird, empfiehlt es sich deshalb, bei jedem Versuch einen neuen Datensatz anzulegen, automatisch zu überprüfen, ob ein gleich lautender Eintrag schon existiert. Eine solche automatische Dubletten-Überprüfung bewährt sich vor allem dann, wenn man viele Personen verwaltet. In Approach kann, bei aller Begrenzung der Makrosprache, eine solche Funktion programmiert werden.

Versteckte Ideen

In der Praxis ergibt sich noch ein weiteres Problem: Schließlich will man bei der Arbeit mit seinen Daten nicht mit irgendwelchen kryptischen Zahlen, sondern mit den Klarnamen operieren. Die IDs sollten im Hintergrund verwaltet werden und nach Möglichkeit sogar unsichtbar bleiben. Datenbanken, in denen mit Kunden- und Artikelnummern gearbeitet wird, sind eigentlich nur ein Notbehelf - ein Zugeständnis an die beschränkten Fähigkeiten des Rechners, dem die Unterscheidung zwischen `Fritz Meier aus Lankwitz´ und `Fritz Meier aus Teltow, Hauptstraße´ wesentlich schwerer fällt als die Unterscheidung zwischen zwei mehrstelligen Zahlen. Solange Daten nur angezeigt werden müssen, bereiten versteckte IDs noch keine Probleme. Da jede ID eindeutig mit einer Firma oder Person verknüpft ist, kann sie unsichtbar bleiben, angezeigt werden nur die anderen Daten des Datensatzes. Schwierigkeiten gibt es jedoch, wenn man die Daten einer Person oder Firma verändern oder gar einen neuen Datensatz anlegen will. Datenbankanwendungen arbeiten deshalb in solchen Fällen meist mit Formularen, die nur der Ansicht dienen, und mit Extra-Formularen oder Dialogfenstern zum Ändern und Hinzufügen von Daten.

Approach beispielsweise läßt es nicht zu, in einer m:n-verknüpften Untertabelle einen neuen Datensatz anzulegen, wenn man sich im Formular der Haupttabelle befindet. Das Programm meldet dann `PID muß ausgefüllt werden´, obwohl das PID-Zählerfeld eigentlich automatisch gefüllt wird. Das Ändern oder auch nur das Zufügen eines vorhandenen Namens zu einer Firma wird als Neuanlage interpretiert und ebenfalls abgewiesen. Das liegt daran, daß Name kein Verbindungsfeld ist. Wird die Auswahl über die PID vorgenommen, gibt es keine Probleme. Das Programm füllt dann sogar automatisch die anderen Felder der Zeile aus, einschließlich Name. Diese nützliche Funktion - zu der man jedoch die ID kennen und eingeben muß - nennt sich Auto-Nachschlagen.

Führt also kein Weg an der Zahlen-Jongliererei vorbei? Doch! Dafür haben die Programmierer sogar eine komfortable Funktion vorgesehen, nämlich in Drop-Down-Listen (und nur in diesen) statt des eigentlichen Feldinhalts ein anderes Feld als `Beschreibungsfeld´ anzuzeigen. Also: PID in die Untertabelle einfügen, als Drop-Down-Feld definieren und Option `mit Beschreibungsfeld´ wählen. Als Beschreibungsfeld läßt man am besten ein berechnetes Feld anzeigen, das Name, Vorname, Titel und eventuell andere Angaben zu einem eindeutigen Ausdruck kombiniert (dieser Ausdruck muß ebenso eindeutig sein wie die PID, da in der Auswahlliste von gleichlautenden Ausdrücken nur der jeweils erste angezeigt wird). Anschließend kann das PID-Feld auf die Größe des Drop-Down-Pfeils verkleinert werden. Obwohl der Anwender eigentlich mit der PID arbeitet, bleibt diese unsichtbar. Angezeigt wird die ausgewählte Person in einem daneben gestellten Feld, für das man zweckmäßigerweise das zum Füllen der Drop-Down-Liste benutzte berechnete Feld wählt.

Dieser Trick erlaubt das Zufügen einer vorhandenen Person zu einer im Firmen-Formular aktiven Firma, ohne das Formular zu wechseln. Zur Neu-Anlage eines Personen-Datensatzes muß jedoch auch hier ins Personen-Formular gewechselt werden (beides gleichzeitig in einem Formular zu erledigen, läßt auch Access nicht zu.) Das ist jedoch kein großer Nachteil, da man meist doch mehr Daten einzutragen hat, als in einer Zeile der Personen-Untertabelle Platz finden.

m alias n

Eine Firma ist immer eine Firma, eine Person immer eine Person, ein Mitarbeiter kann jedoch sowohl Vorgesetzter als auch Untergebener sein. Wenn Beziehungen zwischen solchen Objekten, deren Klassenzugehörigkeit wechseln kann ( Firmen und Personen sind dagegen eindeutig definierte Objekt-Klassen), abgebildet werden sollen, kommt die Alias-Verbindung ins Spiel. 1:n-Beziehungen der Art Vorgesetzte-Mitarbeiter werden, statt für die Vorgesetzten eine eigene Tabelle anzulegen, über die Verbindung der Personen-Tabelle mit sich selbst verwaltet. Dazu wird in die Personen-Tabelle lediglich ein Feld zur Aufnahme der PID des Vorgesetzten aufgenommen. Anschließend wird die Original-Personen-Tabelle mit dem `Alias´ dieser Tabelle (einer Art virtueller Kopie) verbunden. Verbindungsfelder stellen das eben genannte Vorgesetzten-PID-Feld und das PID-Schlüsselfeld dar.

Sollen komplexere Beziehungen - etwa Verwandtschaftsbeziehungen - verwaltet werden, ist auch hier wieder eine m:n-Verbindung unter den Alias-Tabellen nötig. Im Prinzip wird diese, wie oben beschrieben, über eine dritte Tabelle hergestellt, die man zwischen die beiden Alias-Tabellen schaltet und die mindestens die Verbindungsfelder PIDa und PIDb enthält. Jedoch nur im Prinzip. Die Tatsache, daß ein zweites Formular für die zweite `Blickrichtung´ auf die Beziehung hier unsinnig wird, macht die Verhältnisse noch etwas komplizierter. Das muß etwas näher erläutert werden:

Bei zwei m:n-verknüpften Tabellen mit den Objektklassen Firmen und Personen lassen sich in den zwei zugehörigen Formularen alle verbundenen Objekte (Datensätze) der Gegenseite vollständig darstellen. Anders, wenn die Objekte sich nicht mehr eindeutig zwei Klassen (und damit Formularen) zuordnen lassen. Beispiel: Zwischen zwei Personen besteht die Beziehung `Vater-Sohn´. Wählt man in einem Formular, das auf der ersten (Original-)Personen-Tabelle beruht, den Vater-Datensatz und stellt von dort aus die Verbindung her, wird der Datensatz des Sohnes in diesem Formular richtig eingeblendet. Geht man in dem gleichen Formular zum Sohn-Datensatz, wird dort jedoch keine Verbindung zum Vater angezeigt. Die rückwärtige Verbindung Sohn-Vater wird nur in einem Formular angezeigt, das auf der zweiten (Alias-)Tabelle beruht. Ein solches Formular anzulegen würde jedoch nur Verwirrung stiften. Beide Formulare enthielten bis auf die Verwandtschaftsbeziehung völlig identische Daten, und man würde nie wissen, in welchem Formular man die interessierende Beziehung gerade suchen muß.

Ein Ausweg aus diesem Dilemma ist, bei jeder Herstellung einer Personen-Beziehung in der verknüpfenden m:n-Tabelle nicht nur einen, sondern zwei Datensätze anzulegen: einen für die Hin-, den anderen für die Rückverbindung. Sie unterscheiden sich durch die Vertauschung der gespeicherten PIDs und eventuell durch unterschiedliche Verbindungsbezeichnungen (zu `Vater´ gehört zum Beispiel `Sohn´ oder `Tochter´). Beim Löschen einer Beziehung müssen dann natürlich, um die Daten-Integrität zu gewährleisten, auch beide Datensätze gelöscht werden. Das läßt sich, ebenso wie das automatische Anlegen zweier Datensätze, mit Makros erreichen.

Sollen zu einer Beziehung weitere Daten gespeichert werden, etwa Zeitraum der Beziehung oder Notizen, ist die Existenz zweier Datensätze pro Beziehung wieder hinderlich. Deshalb zum Schluß noch ein weiterer Tip: Bilden Sie aus den beiden Schlüsselfeldern PIDa und PIDb durch Verknüpfung ein neues (berechnetes) Feld, das eindeutig, jedoch unabhängig von der Reihenfolge von PIDa und PIDb ist. Es dient als Verknüpfungsfeld mit einer Tabelle, welche die zusätzlichen Beziehungsdaten aufnimmt. (ae)

Formular-Design

Bei der Gestaltung eines Formulars für m:n-verknüpfte Tabellen erweist es sich weder als trivial noch unwesentlich, aus welchen Tabellen die aufgenommenen Felder stammen. Außerdem spielt für eine ordnungsgemäße Funktion eine Rolle, welches die `Hauptdatenbank´ eines Formulars oder einer Untertabelle ist. Prinzipiell sind in ein Formular beliebige Felder aufnehmbar, solange die darin angezeigten Daten aus miteinander verbundenen Tabellen stammen. Formulare sollten diejenige Tabelle zur Hauptdatenbank haben, durch die man `blättern´ möchte. Für Untertabellen in solchen Formularen sollte man die Tabelle als Hauptdatenbank wählen, welche die Verbindungsinformationen enthält. Dann lassen sich auch noch die Daten von wesentlich differenzierter aufgeteilten Tabellen mit nur zwei Formularen verwalten.

Um die in den Bildern gezeigten Formulare für eine Beispieldatenbank aus acht verknüpften Tabellen zu erstellen, sind folgende Einstellungen nötig:

Ansicht Organisationen:

• Formular und alle Felder außer Sprechzeit stammen aus der Tabelle Organis.

• Sprechzeit stammt aus Tabelle Abteilung.

• Untertabelle Abteilung: Hauptdatenbank ist Abteilung, die angezeigten Felder beruhen ebenfalls auf dieser Tabelle.

• Untertabelle Personen: Hauptdatenbank ist die m:n-Tabelle Position. Das (bis auf den Drop-Down-Pfeil unsichtbare) PID-Feld stammt gleichfalls aus Position. Angezeigt wird ein berechnetes Feld.

Ansicht Personen:

• Formular und alle Felder bis auf die unter Position und Privat stammen aus der Tabelle Personen.

• Untertabelle Organisationen: basiert auf Tabelle Position. Das (bis auf den Drop-Down-Pfeil unsichtbare) BID-Feld (Bereichs/Abteilungs-ID) stammt ebenso aus Position. Angezeigt wird das Feld Abteilung:Organisation (schreibgeschützt). Auch das Abteilungsfeld rechts daneben ist schreibgeschützt und dient nur zur Klartext-Anzeige der mit dem Drop-Down-Feld daneben ausgewählten BID. Letzteres Feld wurde wieder bis auf den Pfeil verkleinert. Vom linken BID-Feld unterscheidet sich das Feld dadurch, daß für die Drop-Down-Liste hier der Abteilungsname als Beschreibungsfeld ausgewählt wurde und zusätzlich eine Filterung mit dem Feld Organisation erfolgt, um nur die zur jeweiligen Organisation gehörigen Abteilungen anzuzeigen. Das Feld dient zur Auswahl und zur Änderung der Abteilungszugehörigkeit einer Person. Neue Abteilungen anlegen kann man nur in der Firmen-Ansicht. Die kleinen roten Auswahl-Kästchen in den Listen dienen als Markierhilfe, wenn eine Verbindung gelöscht werden soll.

Zur Steuerung der Formulare und zur automatischen Dubletten-Prüfung sind eine Reihe von Makros notwendig, die hier nicht beschrieben werden können. (Die gesamte Approach-Datei wird jedoch in der c't-Mailbox zur Verfügung stehen.) Da Approach keine echte Makro-Sprache hat, müssen die Befehle in einem Fenster per Maustaste ausgewählt und aneinandergereiht werden. Das ist für Anwender ohne Programmierkenntnisse von Vorteil, wirft aber bei komplexeren Anforderungen große Hindernisse auf, zumal die Makros nicht immer so funktionieren, wie sie sollen. Das Approach-Handbuch ist übrigens im Makro- wie auch in allen anderen Kapiteln ein Musterbeispiel dafür, wie man es nicht machen sollte: In ermüdender Redundanz werden zu jeder Aktion die gleichen Grundfunktionen beim Arbeiten mit Fenstern beschrieben. Wichtige Funktionen und Besonderheiten kommen dagegen zu kurz oder sind unter soviel unnützer `Information´ nur schwer zu finden.

• Die Untertabelle Beziehungen basiert auf der Tabelle Beziehung. Das erste Feld enthält eine Drop-Down-Liste mit vorgegebenen Beziehungswerten (Vater, Mutter, Ehepartner ...), das zweite das bis auf den Drop-Down-Pfeil verkleinerte PIDb-Feld. Angezeigt wird ein berechnetes Feld (aus Name, Vorname, Titel) aus der Alias-Tabelle Personen:2. Die Datumsangaben (Von:, Bis:) stammen aus der Tabelle Bez_dat, ebenso das Memo-Feld Bemerkungen zu:.

Zur Gewährleistung der Daten-Integrität sollten bei allen Verbindungen die (voreingestellten) Aktualisierungsoptionen und bei den Verbindungen Organisation-Abteilung, Abteilung-Position, Person-Privat, Person-Position, Person-Beziehung und Beziehung-Bez_Daten auch die Option Löschweitergabe gewählt werden (jeweils in Richtung der untergeordneten Tabelle).

Die Dubletten-Prüfung funktioniert so: Nach jeder Neueingabe eines Nachnamens zeigt das Programm eine Liste aller gespeicherten Personen dieses Namens. Es kann nun entweder eine Person ausgewählt oder eine neue Person mit gleichem Namen angelegt werden. Die Verbindung zu einer zuvor gewählten Firma wird automatisch hergestellt. Firmennamen können nicht doppelt vergeben werden, da dieses Feld ein Schlüsselfeld darstellt (Option einmalig ist gewählt).

Allzu große Geschwindigkeitsanforderungen sollte man an ein komplexes System aus vielen verbundenen Tabellen nicht mehr stellen, vor allem dann, wenn viele Makros eingebunden sind. Approach (benutzt wurde Version 3.02, das letzte `stille Update´ von Lotus, unter WfW 3.11) wurde mit der beschriebenen Beispieldatenbank mit etwa 1600 Firmen- und Personendatensätzen auf einem 486DX2/66 mit 20 MB RAM manchmal schon recht langsam.

Aus eins mach zwei - und mehr

So bereiten Sie Ihre Datenbank für eine 1:n- oder m:n-Verbindung vor: Haben Sie bisher Ihre Adressen in einer einzigen Tabelle (Datenbank) erfaßt, so ist die Aufteilung in eine 1:n-Verbindung recht einfach. Zuerst sollten Sie die beiden neuen Tabellen mit allen benötigten Feldern anlegen. Die Firmen-Datenbank erhält alle Felder, die pro Firma nur einmal existieren, also Firmenname, Anschrift, Telefon (Zentrale) und so weiter. Analog gilt dies für die Personen-Tabelle. Diese muß aber zusätzlich noch das Verbindungsfeld enthalten, das hier Firma hieße. Wenn auch Abteilungsnamen aufgenommen werden, gehört das entsprechende Feld ebenfalls in die Personen-Tabelle. Es sei denn, Sie wollen konsequent sein und eine eigene Abteilungsdatenbank einrichten, die zwischen der Firmen- und der Personen-Datenbank plaziert ist. Die Vorgehensweise ist dann jedoch prinzipiell gleich. Achten Sie darauf, daß die neuen Felder lang genug sind, um die Einträge der alten Datenbank aufzunehmen. Schwierigkeiten kann es auch geben, wenn sie nicht das gleiche Feldformat haben.

Anschließend importieren Sie nacheinander in beide neuen, noch leeren Datenbanken die entsprechenden Felder der alten Adreßdatei. Personen ist damit schon fertig, Firmen hat noch etwas Nacharbeit nötig. Diese Tabelle enthält nämlich jetzt viele Dubletten, da Firmennamen in der Adreßdatei mehrfach vorkamen. Echte Dubletten (wenn alle Felder zweier Datensätze aus Firmen gleich sind) können Sie sofort löschen. Approach bietet dafür eine `speziell Suchen´-Funktion an, mit der sich Dubletten schnell finden lassen. Auf Wunsch wird der jeweils erste Datensatz von mehrfach vorhandenen Sätzen (der ja nicht gelöscht werden darf) gleich vom Such-Ergebnis ausgeschlossen.

Was übrigbleibt, enthält nun wahrscheinlich immer noch Sätze mit gleichen Firmennamen, aber unterschiedlichen anderen Feldeinträgen. Ordnen Sie deren Daten einem einzigen Firmen-Datensatz zu und löschen Sie alle anderen. In der fertigen Firmen-Datenbank muß das Verbindungsfeld Firma eindeutig sein, darf also nicht zwei Sätze mit dem gleichen Firmennamen enthalten. Dieser Zustand läßt sich auf Dauer sichern, wenn man jetzt (nicht vorher) für das Feld Firma die Option einmalig einstellt. Das Programm akzeptiert nun nicht mehr das Anlegen eines neuen Firmen-Datensatzes, wenn die Firma bereits vorhanden ist.

Etwas aufwendiger ist das Erstellen einer m:n-Verbindung aus vorhandenen Daten. Die Verbindungsinformation, bei einer 1:n-Verbindung in der Tabelle der n-Seite gespeichert, bekommt nun eine eigene Tabelle. Deshalb kommt man um ID-Nummern kaum herum, ansonsten müßten in diese Tabelle nicht nur die Firmennamen, sondern auch eindeutige Personennamen aufgenommen werden. Da es die nicht gibt, müßte also wenigstens der Vorname als zweites Verbindungsfeld aufgenommen werden, und selbst das ist nicht völlig sicher.

Und so gelingt es:

1. Erstellen Sie wie oben beschrieben zwei eindeutige Datenbank-Tabellen Firmen und Personen, die 1:n-verknüpft sind, und exportieren sie die Daten in zwei Dateien, um sie zu sichern.

2. Löschen Sie den Inhalt von Firmen und Personen und erstellen Sie in beiden Tabellen ein ID-Feld als Zählerfeld (numerisches Feld, das automatisch um 1 erhöht wird). Die beiden Felder könnten FID und PID heißen.

3. Importieren sie nun die beiden eben gesicherten Dateien wieder. Dabei trägt das Programm automatisch eindeutige IDs in die entsprechenden Felder. Die Firmen-Tabelle ist damit fertig.

4. Sichern Sie die Personen-Tabelle erneut in eine eigene Datei. Löschen Sie dann alle Datensätze aus Personen, in denen das Feld Firma leer ist - für Personen, die keiner Firma zugeordnet sind, wird schließlich auch keine Verbindungsinformation benötigt. Was übrigbleibt, ist die Basis für die künftige m:n-Tabelle. Exportieren Sie daraus die Felder Firma und PID in eine eigene Datei.

5. Anschließend den Inhalt von Personen löschen und den alten Inhalt wieder herstellen (die in Punkt 4 gesicherte Datei wieder importieren). Wichtig: PID muß jetzt mit importiert werden. Nun kann das Feld Firma gelöscht werden, und fertig ist die Personen-Tabelle.

6. Legen Sie die m:n-Tabelle mit den Feldern FID, PID und dem vorübergehend noch benötigten Feld Firma an. FID und PID dürfen jetzt keine Zählfelder und auch nicht `eindeutig´ sein - lediglich numerische Felder ausreichender Größe. In die m:n-Tabelle wird die Datei mit den Feldern Firma und PID importiert.

7. Jetzt muß in dieser Tabelle nur noch Firma durch die entsprechende FID ersetzt werden. Dazu aktualisieren Sie die m:n-Tabelle mit der bereits existierenden Tabelle Firmen. Die Import-Funktion von Approach bietet dafür eine komfortable Aktualisierungsoption. Stellen Sie diese so ein, daß immer dann, wenn die Einträge der Felder Firma in den beiden Tabellen gleich sind, die FID aus der Firmen-Tabelle in das entsprechende Feld der m:n-Tabelle geschrieben wird. Anschließend kann das Feld Firma aus der m:n-Tabelle gelöscht werden. Die relationale Adreß-Datenbank mit m:n-Verknüpfung ist fertig.

Zu diesem Artikel existieren Programmbeispiele.