Was sind Relationen?

FileMaker ist eine Beziehungskiste. Jede Datei ist eine «Kiste», worin sich verschiedene «Tabellen» erstellen lassen. Jede «Tabelle» hat «Felder», worin Daten abgelegt werden. Tabellen können untereinander «verknüpft» werden. Dadurch ist es etwa möglich, Redundanzen zu vermeiden oder Beziehungen zwischen Informationen aufzuzeigen. Diese Verknüpfungen nennt man auch «Relationen». FileMaker ist ein relationaler Datenbank wegen dieser Möglichkeit. Die meisten Datenbanksysteme heute sind relational aufgebaut.

• Jede FileMaker-Datei enthält eine oder mehreren Tabellen
• Jede Tabelle enthält Felder
• Felder dienen der Informationsablage

Ferner:

• Zwischen Tabellen können Beziehungen definiert werden
• Diese Relationen basieren auf Feldbeziehungen zweier Tabellen

Relationen werden im Fenster «Beziehungs-Diagramm» gezeigt, das über Menü Datei > Verwalten > Datenbank erreichbar ist.

Bewältigung der Komplexität

Ruckzuck erstellt man in FileMaker eine Datenbank. Das ist einfach und FileMaker ist fehlertolerant. Es gibt eine niedrige Einstiegsschwelle, wenn man mit FileMaker zu arbeiten beginnt. Applikationen werden jedoch nicht als Eintagsfliegen entworfen, sondern dienen aufwändigen Geschäftsabläufen. Mit der Zeit entwickelt sich die Datenbank. Die Komplexität und Datenmenge nehmen zu und die Fehlertoleranz der Anfangszeit schwindet. Wie bewältigt man die zunehmende Komplexität?

An diesem Punkt angelangt, suchen viele Menschen Hilfe und Coaching von professionellen Entwicklern. Diese haben gelernt, wie man die Komplexität bewältigt. Erfahrung spielt eine Rolle, aber auch das Verständnis um einige grundlegende Konzepte.

Eines dieser Konzepte betrifft die Art, wie man Relationen in FileMaker erstellt. Dafür gibt es verschiedene Ansätze, die nachfolgend kurz skizziert werden. Ich kenne keinen Entwickler, der nicht durch diese verschiedene Ansätze selbst hindurchgegangen ist. Der Reihe nach geht es um:

1. Spaghetti-Programmierung
2. Das Anker-Boje-Prinzip
3. Selector-Connector (oder ähnlich).

Alle diese Ansätze haben ihren eigenen Reiz. Für die Funktionalität muss es nicht zwangsläufig zu anderen Resultaten kommen, wenn man sich für diese oder jene Variante entscheidet. Der Grund, weshalb die eine oder andere Variante vielleicht besser geeignet ist, liegt nicht in der Funktionalität, sondern in der Wartung und Weiterentwicklung. Dazu gleich mehr.

Das übergeordnete Prinzip, wonach sich etwa das Anker-Boje-Prinzip bei den meisten Entwicklern durchgesetzt hat, liegt in der Vereinfachung der Applikation. Was einfacher ist, lässt sich besser warten. Was übersichtlicher ist, lässt sich schneller und besser weiterentwickeln. Die Fehlersuche gestaltet sich in übersichtlichen Lösungen deutlich einfacher. Diese und weitere Gründe plädieren für einfache, gut strukturierte Lösungen. Weshalb nun manche Strukturen übersichtlicher sind als andere Ansätze, wird hier unten exemplarisch aufgezeigt.

1. Spaghetti-Programmierung

Jeder beginnt hier. Das Rezept ist einfach: Man beginnt an beliebiger Stelle und macht dann immer weiter, und zwar so, dass am Schluss alles mit allem verknüpft ist – wie Spaghetti mit der Sauce. Ein anderer Name für diese Situation lautet «Spinnennetz».

Nachteile solcher Diagramme:

• unübersichtlich
• verlangsamt die Lösung
• Pflege und Weiterentwicklung werden mühsam
• Anfälliger für Fehler.

In der nachfolgenden Darstellung steht jede Farbfläche für eine Tabelle und jede Linie für eine Verknüpfung. Dieselbe Farbe steht für dieselbe Tabelle, die mehrfach auftreten kann. Es spielt keine Rolle, ob diese Situation «schön geordnet» wird, ob Farben genutzt werden oder nicht, sondern das hervorstechende Merkmal ist: Chaos.

Ich kenne keinen Entwickler, der dieses Stadium nicht durchlaufen hat. Ich selber dachte: Es funktioniert alles prächtig, also was kümmert mich das Beziehungsdiagramm? Das funktioniert so lange, bis es nicht mehr funktioniert. Eines Tages ist es nicht mehr deutlich, was wozu in Beziehung steht, auf welche Tabellenauftreten sich die Layouts befinden (die in FileMaker immer mit einer Tabelle verknüpft sind), welche Auswirkungen eine Änderung auf welches Script hat und dieser Dinge mehr. Der Aufwand, die Applikation zu pflegen, wächst rasant. Die Erkenntnis wächst, dass bessere Konzepte nötig sind.

2. Anker-Boje-Prinzip

Als Antwort auf die Spaghetti-Programmierung kam jemand auf die Idee, eine mehr geordnete Struktur für die Relationen zu nutzen. Es sollte nicht mehr alles mit allem verknüpft sein, sondern alles sollte vereinfacht werden. Das Anker-Boje-Prinzip wurde erfunden. Dies hat sich seit vielen Jahren bewährt.

Tabellenauftreten

Im Beziehungsdiagramm von FileMaker kann man Tabellen mehrfach aufführen. Jedes Auftreten einer Tabelle nennt man «Tabellenauftreten». Man kann sich das als Platzhalter für die Tabelle vorstellen. Pro Tabelle können mehrere dieser Platzhalter genutzt werden, die alle eigene Aufgaben (Beziehungen) erfüllen.

Anker und Bojen

Die Platzhalter (Tabellenauftreten) kann man nun bestimmte Funktionen zuweisen. Das ist bloss eine Betrachtungsweise. Einige der Tabellenauftreten nutzt man als «Anker», andere als «Boje». Ihre Funktion ist unterschiedlich.

• Layouts liegen nur auf Anker
• Datenbezüge werden über Bojen gemacht.

Umgekehrt gilt auch:

• Layouts liegen nie auf Bojen
• Datenbezüge werden nie über Anker gemacht.

Ein Anker-Boje-Prinzip, wenn das im Beziehungsdiagramm dargestellt wird, sieht in etwa so aus:

In der Abbildung hier unten wird das Prinzip umgesetzt. Links ist das Tabellenauftreten «Adressen». Layouts werden nur auf diesen Anker erstellt. Das übrige Tabellenauftreten dient lediglich dazu, Daten zu lesen oder zu schreiben.

Inselwelt

Das Anker-Boje-Prinzip denkt immer von den Ankern aus. Bojen dienen lediglich der Informationsbeschaffung. Jeder Anker mit den dazugehörenden Bojen ist eine Welt für sich. Man könnte sich das als Insel vorstellen. Während in der Spaghetti-Programmierung alles mit allem verknüpft ist, wird das beim Anker-Boje-Prinzip drastisch vereinfacht. Bei der Anker-Boje-Darstellung ist es immer klar:

• wo die Layouts sind (ANKER)
• welche Beziehungen von diesem Layout aus genutzt werden können (BOJEN).

Dasselbe Prinzip bedingt natürlich, dass man bei mehreren Tabellen mehrere dieser Inseln entstehen. Es ist eine Inselwelt.

Vielleicht entstehen in absoluten Zahlen auf diese Art mehr Beziehungen als bei der Spaghetti-Programmierung, aber es sind deutlich weniger Beziehungen «pro Insel». Durchaus können mehrere Bojen hintereinander platziert werden, aber bedingt durch das Anker-Boje-Prinzip bleibt das alles verständlich. Dies kommt einer starken Vereinfachung gleich. Bei grösseren Datenmengen wird die Applikation deutlich schneller. Alles ist viel übersichtlicher und lässt sich einfacher pflegen.

Namensgebung der Beziehungen

Jedes Tabellenauftreten muss einen eindeutigen Namen haben. FileMaker setzt dies voraus. Es hat bei vielen Entwicklern bewährt, dass man sich für die Namensgebung jetzt etwas einfallen lässt, woraus die Aufgabe jeder Beziehung klar wird. Dies vereinfacht die Handhabung erheblich. Selbstverständlich gibt es keine fixe Vorschriften dafür «was das Beste» ist, aber bei mir hat sich folgende Vorgehensweise bewährt:

[VonTabelle]_[ZuTabelle]|[Kriterium oder Feld], oder anders gesagt:
[ANKER]_[BOJE]|[FELD worauf die BEZIEHUNG BASIERT]

Wenn man dies so handhabt, werden mehrere Beziehungen automatisch alphabetisch sortiert, wenn FileMaker diese in einer Auswahl zur Verfügung stellt. Die Beziehungen können leicht interpretiert werden.

Verzweigungen im Anker-Boje-Modell

In FileMaker gibt es den Befehl, womit man über eine Beziehung zu einer Auswahl von Bezugsdaten verzweigen kann. Im Anker-Boje-Prinzip nutzt man für die Verzweigung die Bojen. Beim gleichen Befehl kann man auch angeben, auf welchem Layout man verzweigen will. Dort gibt man dann erneut ein Anker-Layout der Zieltabelle an. Man springt also zum gewünschten Kontext und sucht sich dabei ein passendes Layout.

• Gehe zu [Zieltabelle via BOJE]
• mit Layout [ANKER-Layout der Zieltabelle]

Das ist auf den ersten Blick nicht die einfachste Lösung. Ich habe oft gesehen, wie über die Verzweigung dann das Tabellenauftreten der Boje für das Layout verwendet wird. Gerade das ist jedoch, was später für Verwirrung sorgt. Hier greifen die Vorteile vom Anker-Boje-Prinzip. Arbeitet man eine Weile mit sauberen «Inseln», worin klar ist, auf welche Tabellenauftreten die Layouts liegen, dann wird alles einfacher.

Man sollte auch bedenken, dass zwar jedes Tabellenauftreten mit einem Layout kommt, aber mehrere Layouts dasselbe Tabellenauftreten haben können. Auf alle diese Layouts gelten dann dieselben Relationen.

Denkt man diesen Aufbau weiter, kann es sinnvoll erscheinen, Scripts bevorzugt auf einer solchen Anker-Boje-Insel zu begrenzen. Auch das vermeidet Spaghetti-ähnliche Verknüpfungen. Finde hier die Lösungen, die Dich weiter bringen.

3. Selector-Connector

Das Selector-Connector-Modell gibt es in verschiedenen Varianten. Der Name wurde von Todd Geist geprägt (Idee aus 2014 hier). Vereinfacht rede ich hier nur vom Selector-Connector-Modell, auch wenn weitere ähnliche Ideen die Runde tun.

Das Selector-Connector-Modell ist eine Weiterentwicklung vom Anker-Boje-Prinzip. Man hat versucht, die Inselwelt vom Anker-Boje-Prinzip zu einem Kontinent zu upgraden, worin alles integriert ist. Das gelang durch Implementierung eines Systems, worin Beziehungen bei Bedarf aufgebaut werden. Das System hat eine grosse Flexibilität gebracht, weil es so etwas wie ein universaler Zusammenhang für jede Aufgabe kreiert werden konnte. Nutzt man das System, entsteht jedoch auch eine Abhängigkeit von dem System.

Die meisten Entwickler, die ich kenne und die diese Herangehensweise getestet haben, sind mittlerweile wieder zum Anker-Boje-Prinzip zurückgekehrt. Ich habe verschiedene Gründe dafür gesehen:

1. Einige berichteten von Datenfehlern und Performance-Problemen
2. Das Modell zwingt ein bestimmtes System auf

In der Praxis erwies sich das Anker-Boje-Prinzip als einfacher und zuverlässiger (einfach und zuverlässig gehen häufig Hand in Hand).

Zusammenfassung

Die Vereinfachung der Datenstruktur wird durch das Anker-Boje-Prinzip wirksam unterstützt. Anwendungen werden übersichtlicher, oft schneller, sind einfacher zu pflegen und besser zu erweitern. Mit diesen paar Angaben ist nicht alles über FileMaker Entwicklung gesagt und wie man einzelne Aufgaben jetzt löst. Der Ansatz ist jedoch bewährt und es ist eine gute Ausgangslage für die Weiterentwicklung von FileMaker-Projekten.

Weil bereits viele Entwickler mit dem Anker-Boje-Prinzip arbeiten, ist es für die Datenpflege auf Dauer sehr nützlich, dieses Prinzip zu implementieren. Sollte einmal der hauseigene Entwickler ausfallen, kommen andere Entwickler auch besser mit der Anwendung zurecht.

Natürlich ist mit diesen Ausführungen nicht alles gesagt. Eine gute Entwicklung benötigt jedoch bewährte Konzepte, damit sie gelingt. Dies war eine Kurzeinführung in ein solches Konzept.