FMK2017 - Die Anker Boje Methode by Gerhard Schwingenschlögl

8. FileMaker Konferenz | Salzburg | 12.-14. Oktober 2017
www.filemaker-konferenz.com
Mit Anker-Boje-System beginnen und in den Layouts
die Vorteile nutzen.

Gerhard Schwingenschlögl
Tabellenaufbau im Beziehungsgraphen

Anker-Boje-Modell / Gerhard Schwingenschlögl
Über den Sprecher
• Geboren 1958 als „ÖSI“ in Wernstein an der Grenze
zu Deutschland

• Speditionskaufmann, Kraftfahrer, Vermögensberater,
Verkäufer, Mitarbeiter in Marketing und Produktion,
Kundenbetreuer in Softwareunternehmen,
Verkaufsaußen- und Innendienst, Analytiker

• Handwerker im eigenen Haus und Garten

• Hobbyfotograf

Über den Vortrag
• Es ist nichts neu erfundenes zu Anker-Boje-Modell

• Er greift auf praxistaugliche Ansätze anderer Entwickler zu

• Er richtet sich eher an Beginner bzw. Fortgeschrittene, welche sich noch mal
die Basics ansehen wollen

• Es ist (m)ein Weg

• Er zeigt im Übungsteil den Einsatz des Beziehungsgraphen mit mehreren
Bedingungen

• Wer hat noch keine Erfahrung mit Anker-Boje-Modell?

Die Tabellen
• Grundsätzlich sollte jede Tabelle eine eindeutige ID besitzen (UUID)

• Redundante Werte sollten vermieden werden (Normalisierung - eigene Tabelle
bzw. Werteliste)

• Logisch abhängige Tabellen gehören im Beziehungsgraphen verknüpft

• Hilfreich sind noch Präfixe für Feldnamen (z.B.: f_Name für Formelfeld, g_Name
für globales Feld, …)

• Jede neu erstellte Tabelle taucht im Beziehungsgraphen auf

• Nur Tabellen, welche im Beziehungsgraphen sichtbar sind, können von
FileMaker verwendet werden (auch mittels SQL)

Beziehungen
• Im menschlichen Leben können wir grundsätzlich mit jedem Mitmenschen eine
Beziehung aufbauen

• In FileMaker können wir auch grundsätzlich alle Tabellen miteinander in
Beziehung bringen

• Ob eine Beziehung sinnvoll ist oder nicht, müssen wir entscheiden

• In FileMaker sind Beziehungen völlig EMOTIONSLOS - das ist in der
Datenbankverwaltung ein Vorteil !

Beziehungen
• Zuerst tauchen alle angelegten Tabellen unverknüpft im Beziehungsgraphen auf

Beziehungen
• Beispiel mit 2 verknüpften Tabellen und einer Tabelle ohne Bezug

• Über Schlüsselfelder werden Beziehungen hergestellt
Siehe Beispiel 1

Beziehungen
• Auf der linken Seite darf das Abgleichfeld
ein Text, Zahl, Datum, Zeit, Zeitstempel
und ein gespeichertes Formelfeld sein.

• Auf der linken Seite darf das Abgleichfeld
auch als globales Feld definiert sein.

• Auf der rechten Seite darf das
Abgleichfeld auch zusätzlich noch ein
ungespeichertes Formelfeld sein.

• Auf der rechten Seite darf das
Abgleichfeld NICHT als globales Feld
definiert sein (macht ja auch keinen Sinn)!

Beziehungen
Die Bezugstabelle ANSPRECHPARTNER
ist wegen 
der Verknüpfung als Bezugstabelle
aufgelistet. 
Die Tabelle NOTIZ hat keine Verknüpfung
und ist deshalb ohne Bezug aufgelistet.

Es ist eindeutig, dass ADRESSE und
ANSPRECHPARTNER im Bezug
zueinander stehen.
Auswirkung, dargestellt am Dialogfenster  
der Ausschnitteinstellung

Beziehungen
• Beispiel mit 3 verknüpften Tabellen
Siehe Beispiel 1

Beziehungen
Die aktuellen Bezugstabellen
ANSPRECHPARTNER und NOTIZ sind wegen 
der Verknüpfung als Bezugstabellen aufgelistet. 
ABER

Es kann nicht abgeleitet werden, welche echten
Abhängigkeiten es gibt. 
 
Adresse zu Ansprechpartner?

Adresse zu Notiz? 
Adresse zu Ansprechpartner und zu Notiz?

Adresse zu Notiz und zu Ansprechpartner?


Anker-Bojen
• Um diesem Dilemma entgegenzuwirken, hat sich das Anker-Bojen-Modell
entwickelt und bewährt.

• Es kann direkte Abhängigkeiten darstellen und somit Scheinbeziehungen außen
vor halten.

Anker-Bojen
• Jedes Tabellenauftreten hat einen Ursprung

• Dieses TO kann immer als Anker verwendet werden

• Anker sind bei mir immer ROT eingefärbt

• Zum allgemeinen Verständnis ist es leichter, sich von dort Kopien von
Tabellenauftreten zu erzeugen und als Bojen zu führen

Anker-Bojen
• Die äußerst linke Tabelle wird als Ankertabelle bezeichnet

• Jede weitere verknüpfte Tabelle wird als Bojentabelle bezeichnet

• Jede Tabelle im Beziehungsgraphen nimmt den Namen aller Vortabellen im
eigenen Namen auf.

• Zur besseren Unterscheidung im Beziehungsgraphen werden Anker- und
Bojentabellen unterschiedlich eingefärbt 
(Bei mir die Ankertabellen rot - die Bojentabellen gelb)
Kopien der Anker

Anker-Bojen
Mit dem Anker-Bojen-Modell kann immer
festgestellt werden, welche echten Beziehungen
zwischen Tabellen bestehen.

Das ist der ANKER
Das sind die BOJEN

Anker-Bojen
• Durch die ausgeschriebenen Namen werden die Tabellennamen mit jeder
weiteren Boje ziemlich lang

• Eine Verkürzung ist sinnvoll

• Mit einem System ideal!
Das fängt schon bei der Erstellung der Tabellen an

Der Namensaufbau der Tabellen
• Die ersten 3 Großbuchstaben geben das Kürzel für die Tabelle an

• Ein Unterstrich trennt Kürzel vom Tabellennamen

• Nach dem Unterstrich kommt der ursprüngliche Tabellenname
ADR_Adresse
ANS_Ansprechpartner
NOT_Notiz

Beziehungen in Kurzform
• Im Beziehungsgraphen verwenden wir immer nur die ersten 3 Großbuchstaben
der Tabellennamen

• Eine Tilde oder ein anderes signifikantes Zeichen trennt die TO-Namen im
Beziehungsgraphen

• Im allgemeinen kann im laufenden Entwicklungsbetrieb immer vom Kürzel auf
den eigentlichen Tabellennamen geschlossen werden.

Beziehungen in Kurzform
• Ein Verweilen des Mauszeigers über der linken Ecke des TO zeigt im Tooltip die
verwendete Tabelle im Originalnamen an

Die Schlüsselfelder
• Bis jetzt haben wir die Schlüsselfelder mit

pkName (PrimaryKey) und

fkName (ForeignKey)

festgelegt
• Der Inhalt (Text oder Zahl) ist daraus nicht ersichtlich

• Ebenfalls nicht ersichtlich, ob es sich um einen strengen Datentyp handelt

Die UUID (Universally Unique Identifier)

ist eine Kombination aus Zeichen und Ziffern  
(Gibt eine eindeutige 16-Byte- (128-Bit-) Zeichenfolge zurück.) 
E47E7AE0-5CF0-FF45-B3AD-C12B3E765CD5 
• gibt es nur einmal in unserem Universum

• ist in JEDEM Fall eindeutig

• kann sich deshalb NIE mit anderen eindeutigen Schlüsselfeldern in Konflikt
bringen (laufender Nummernkreis einer Datei mit dem laufenden
Nummernkreis einer anderen Datei - z.Bsp. beim Import)

• braucht deshalb auch nicht explizit als „strenger Datentyp“ festgelegt
werden

Die UUID

• wird mit der Formel
Hole(UUID) erzeugt

• Der Primärschlüssel einer Tabelle ist immer die UUID (ohne weitere Bezeichnung)

• Der Sekundärschlüssel einer Tabelle ist immer die UUID mit Unterstrich und
dem Kürzel der TO, zu der eine Verbindung hergestellt werden soll

So lässt sich in diesem Beispiel leicht erkennen,  
wie die TOs ADR mit ADR~ANS  
und 
wie die TOs ADR~ANS mit ADR~ANS~NOT  
verbunden werden soll

Die Reichweite der Beziehungen
Von Links nach
Rechts geht es nur
immer 
einen Schritt
Von Rechts nach
Links können von
der äußerst
rechten TO bis hin
zur Anker-TO auf
alle Felder
zugegriffen
werden!
= unser Ankerpunkt

?
= unser Ankerpunkt  
(Ankerlayout)
Wie kann ich auf entfernte TO zugreifen?
Zum Beispiel mit Layoutwechsel mittels Script und Verwendung  
von Variablen (das kann ziemlich aufwändig werden)

Springe zu Notiz 
und lege einen 
neuen Datensatz an
Speichern, schließen und 
zurückkehren
Mindestens zwei Scripts sind notwendig, um das Layout zu
wechseln und zurück zu kommen

Alternativ - Die Beziehungsnähe
• Erzeugen eines „künstlichen“ Primärschlüssels in der Ankertabelle

• Ranholen entfernter TO zur Ankertabelle (Erstellung neuer DS zulassen)

• Eine Scriptzeile für die Verbindung
Beispiel 1f

Die Abgleichsfelder
• Zum Abgleich beider TO lege ich ein neues Textfeld beim Anker an

• Als Namen verwende ich den Fremdschlüssel der Boje - gefolgt von einer Raute
(UUID_ANS#)

• Das Feld soll ein globales Speicherfeld sein

• Die Raute sagt mir, dass es sich um einen künstlichen Primärschlüssel handelt

• Weil im Text der Begriff UUID vorkommt, weiß ich, dass es sich um eine UUID
für den Abgleich handelt

• Weil beim Anker und in der Boje beide Felder den gleichen Namen haben (die
Raute stellt quasi die Verbindungsaufforderung dar), ist es immer klar, welche
Felder verbunden gehören, um die gewünschte Beziehung zu erstellen

UUID_ANS#UUID_ANS

Die Steuerung
• Bezogen auf unser Beispiel erhält das Portal für ANS eine Taste mit nur einem
einzigen Scriptschritt

Die Umstellung des Portals
• Beim bestehenden Beispiel braucht jetzt nur noch die Quelle des Portals auf die
neue Beziehung umgestellt werden

1 x für die Ausschnittreihe selber

1 x für jedes Feld, welches im Portal  
vorkommt

Die Vorteile von Anker-Boje
• Wir sehen immer nur die einwandfreien Beziehungen

• Wir können Rückschlüsse auf benötigte Felder von Nachbartabellen ziehen

• Durch die Sortierung sind alle zugehörigen Beziehungen schön beieinander

• Neu erstellte Beziehungen fügen sich nahtlos in bestehende ein

• Mit den Kürzeln sparen wir Platz

Grundsätzliches zur Verknüpfung
• Die Schlüsselfelder lassen sich immer nur mit dem ganzen Feldwert vergleichen

• Schlüsselfelder auf der linken Seite dürfen nicht leer sein

• Die Schlüsselfelder auf der linken Seite können auch viele Werte - getrennt
durch ein Absatzzeichen - aufweisen

• Wenn mehrere Schlüsselfelder auf der linken Seite existieren, dann muss jedes
dieser Schlüsselfelder mindestens einen Wert aufweisen, sobald dieses Feld ein
Teil der Verknüpfung ist (ohne geht gar nichts!)

• Die gelieferte Datenmenge entspricht genau der Bedingung(en) dieser
Verknüpfung

• Die Schlüsselfelder auf der linken Seite können statisch, dynamisch oder
variabel gefüllt werden

• Wenn vorhanden, übernimmt der Server die Rechenleistung für die Abfrage

• ACHTUNG

• Will man in Portalen Daten neu erstellen, dann darf die Verbindung nur mit

• gleich =

• größer gleich >=

• kleiner gleich <=

• aufgebaut werden

• ACHTUNG

• Ist so ein Operator beteiligt

• ungleich <>

• größer >

• kleiner <

• kartesisches Produkt x

• dann können über diese Beziehung keine neuen  
Datensätzen erstellt werden

Der Normalfall
• Verwendet werden im Normalfall immer die vorhandenen Primär- und
Sekundärschlüsselfelder

• Meist immer nur eine Verknüpfung zwischen zwei Tabellen

• Beispiel Kunden 1a

Der Normalfall
• In Listenform dargestellt werden immer alle Bezugsdaten dargestellt

• Suchen in Ergebnismengen verringern die Ansicht, der Datenbestand jedoch
ist immer ausgehend von ALLE

• Beispiel Kunden 1a

Die Erweiterung
• Zusätzliche Primärschlüsselfelder in der Ankertabelle erweitern die Optionen!

Die Erweiterung
• Filtern über die Beziehung bringt mit jeder Änderung der Abfrage immer nur die
benötigten Daten

• Die Performance über das Netzwerk steigt - es werden weniger Daten
übermittelt

Die Erweiterung
• Markierungsfelder lassen Mehrfachauswahl zu
• Alle anderen Felder können immer nur einen Wert anzeigen
• Optionsfelder lassen mit gedrückter SHIFT-Taste ebenfalls Mehrfachauswahl zu

Die Erweiterung
Und nun zur praktischen Übung!
• Unbearbeitete Datenbank: FMK Offerte 1A

• Erste Datenbankanpassung: FMK Offerte 1B

• Fertiges Beispiel: FMK Offerte 1C

Zum Schluss
Niemand ist Fehlerfrei!
Bitte lasst mich wissen, wenn Begriffe etc. nicht korrekt in den Folien
vorkommen

Mail an

g.schwingenschloegl@hotmail.com

Vielen Dank unseren Sponsoren
Danke für das Bewerten dieses Vortrages

FMK2017 - Die Anker Boje Methode by Gerhard Schwingenschlögl

FMK2017 - Die Anker Boje Methode by Gerhard Schwingenschlögl

Recommended

More Related Content

What's hot

What's hot(20)

Similar to FMK2017 - Die Anker Boje Methode by Gerhard Schwingenschlögl

Similar to FMK2017 - Die Anker Boje Methode by Gerhard Schwingenschlögl(16)

More from Verein FM Konferenz

More from Verein FM Konferenz(20)

FMK2017 - Die Anker Boje Methode by Gerhard Schwingenschlögl