FileMaker Pro 12

FileMaker Pro 12

Das Grundlagenbuch: Datenbanken entwickeln und verwalten

Horst-Dieter Radke

FileMaker Pro 12

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen National-bibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Copyright © 2013 dpunkt.verlag GmbH, Ringstr. 19B, 69115 Heidelberg

ISBN:

Buch 978-3-944165-00-4

PDF 978-3-944165-84-4

ePub 978-3-944165-85-1

Trotz sorgfältigem Lektorat schleichen sich manchmal Fehler ein. Autoren und Verlag sind Ihnen dankbar für Anregungen und Hinweise!

Alle Rechte vorbehalten. Die Verwendung der Texte und Bilder, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und strafbar. Das gilt insbesondere für die Vervielfältigung, Übersetzung, die Verwendung in Kursunterlagen oder elektronischen Systemen. Der Verlag übernimmt keine Haftung für Folgen, die auf unvollständige oder fehlerhafte Angaben in diesem Buch oder auf die Verwendung der mitgelieferten Software zurückzuführen sind. Nahezu alle in diesem Buch behandelten Hard- und Software-Bezeichnungen sind zugleich eingetragene Warenzeichen oder sollten als solche behandelt werden.

Besuchen Sie uns im Internet!

www.smartbooks.de

www.smartbooks.ch

Übersicht

                  Vorwort

Kapitel 1   Datenbankgrundlagen

Kapitel 2   Mit FileMaker arbeiten ohne Vorkenntnisse

Kapitel 3   Datenbankentwicklung

Kapitel 4   Datenbanken nutzen

Kapitel 5   Suchen und Finden

Kapitel 6   Felder, Formeln und Funktionen

Kapitel 7   Layouten für die Datenbank

Kapitel 8   Berichte erstellen

Kapitel 9   Einführung in die Scriptprogrammierung

Kapitel 10 FileMaker Pro 12 kommunikativ und sicher

Kapitel 11 Tipps, Tricks & Troubleshooting

Kapitel 12 FileMaker mobil

                  Glossar

                  Index

Inhaltsverzeichnis

Vorwort

Kapitel 1   Datenbankgrundlagen

1.1       Datenbankgrundlagen

1.1.1    Was ist eine Datenbank?

1.1.2    Das relationale Modell

1.1.3    SQL – oder die Suche nach der letzten Information

1.1.4    Datenbanksysteme

1.1.5    Probleme der Informationsspeicherung

1.2       Datenbankkonzeption

1.2.1    Datenmodellierung

1.2.2    Eine Datenbank in fünf Schritten

1.2.3    Projektbeschreibung

1.2.4    Das Vermeiden von Mehrfachspeicherungen

Ausgangssituation festlegen

Die erste Normalform – Tabellen werden zerlegt

Die zweite Normalform – doppelte Informationen entfernen

1.2.5    Schlüssel und Index

Datensätze eindeutig identifizieren

Auf den Index gesetzt

Beziehungen pflegen

Die monogame Beziehung

Die offene Beziehung

Jeder mit Jedem

Beziehung zu sich selbst

1.3       FileMaker Pro als relationales Datenbank-Managementsystem

1.4       FileMaker Pro und andere Datenbank-Managementsysteme

Kapitel 2   Mit FileMaker arbeiten ohne Vorkenntnisse

2.1       FileMaker-Starter-Lösungen

2.1.1    FileMaker bedienen

Installation

Nach dem Start

Werkzeuge

2.1.2    Die Starter-Lösungen

Starter-Lösung einrichten

Starter-Lösungen verstehen

2.2       Arbeiten mit einer FileMaker-Datenbank

2.2.1    Daten erfassen

2.2.2    Daten finden

2.2.3    Daten sichern und löschen

Kapitel 3   Datenbankentwicklung

3.1       Datenbankdesign mit FileMaker Pro

3.2       Entwicklungsmethode für überschaubare Projekte

3.2.1    Felder festlegen und Redundanzen erkennen

3.2.2    Tabellen und Felder anlegen

3.2.3    Eine weitere Tabelle anlegen

3.2.4    Felder anlegen

3.2.5    Datentyp festlegen und ändern

3.2.6    Werteliste erstellen

3.2.7    Eine Beziehung herstellen

3.2.8    Formulare erstellen

Mit dem Layoutassistenten arbeiten

Das Layout anpassen

Datenausschnitt in einem Layout

3.3       Datenbankprogrammierung

3.3.1    Skriptprogrammierung für Einsteiger

3.3.2    Formeln für Einsteiger

Eine Formel erstellen

3.3.3    Daten importieren

Datenbasis besorgen

Daten importieren

3.3.4    Der Web Viewer

Das Objekt Web Viewer

Scripteditor

3.4       Fazit

Kapitel 4   Datenbanken nutzen

4.1       FileMaker Pro: Grundlagen

4.2       FileMaker Pro bedienen

4.2.1    FileMaker Pro starten und bedienen

FileMaker-Direktstart

Menü- und Statusleisten

4.2.2    Bestehende Dateien konvertieren

FileMaker-eigene Formate konvertieren

Fremde Formate konvertieren

4.2.3    Starter-Lösungen verwenden und anpassen

Datenbank aus Vorlage erstellen

Datenbankvorlage anpassen

4.3       Mit Datenbanken arbeiten

Datensatz anlegen und Daten eingeben

Kapitel 5   Suchen und Finden

5.1       Daten importieren

5.1.1    Importieren statt Eingeben

5.1.2    Bankleitzahlen herunterladen

Datenbank vorbereiten

5.1.3    Bankleitzahlendatenbank einrichten

5.1.4    Datenimport durchführen

5.1.5    Aktualisierungen durch neuen Import

5.2       Suchen in der Datenbank

5.2.1    Eine Suchabfrage definieren

5.2.2    Fast Match – die Suche per Mausklick

5.2.3    Mit Operatoren suchen

5.2.4    Ansichten der Ergebnismengen

5.2.5    Mehrere Kriterien bei der Suche einsetzen

Zwei Abfragemethoden

Ergebnismenge exportieren

Ergebnismengen aus der Datenbank löschen

Kapitel 6   Felder, Formeln und Funktionen

6.1       Felder definieren

6.1.1    Feldtypen

Feldtyp Text

Feldtyp Zahl

Feldtyp Datum

Feldtyp Zeit

Feldtyp Zeitstempel

Feldtyp Container

Feldtyp Formel

Feldtyp Statistik

6.1.2    Ergänzendes zu Felddefinitionen

Besonderheiten bei Feldnamen

Feldoptionen einstellen

Indizierung

6.1.3    Formeln erstellen

Arbeiten mit dem Formeleditor

Mit Funktionen arbeiten

6.2       Formeln und Funktionen für Fortgeschrittene

6.2.1    Die Funktion Falls

6.2.2    Texte in Formeln

6.2.3    Informationen aus der Datenbank mit Statusinformationen

6.2.4    Containerfunktionen

6.2.5    Neue und geänderte Funktionen in FileMaker Pro 12

Kapitel 7   Layouten für die Datenbank

7.1       Der Layout-Assistent

7.2       Ein Layout zusammenstellen

Layout-Assistent starten

Layouttypen

Felder auswählen

Design wählen

7.3       Ein Standard-Layout anpassen

Kopfbereich gestalten

Fuβbereich gestalten

Objekte und Variablen einfügen

Layouteinstellungen anpassen

Tabulatorfolge festlegen

Script-Trigger einstellen

Grafische Gestaltungselemente

Ausgabefelder formatieren

Kapitel 8   Berichte erstellen

8.1       Berichte

8.2       Mit dem Berichtsassistenten arbeiten

Berichterstellung vorbereiten

Die Berichteinstellungen festlegen

Bericht ausgeben

Berichte bearbeiten

8.3       Dynamische Berichte erstellen

8.4       Snapshot-Link

Kapitel 9   Einführung in die Scriptprogrammierung

9.1       Einführung in die Scriptprogrammierung

9.2       Ein erstes Script

9.2.1    Ein Script erstellen

Einen Scriptbefehl verstehen

Ein Script an ein Layout binden

Scripteintrag aus dem Menü entfernen

9.2.2    Ein mehrzeiliges Script entwickeln

9.2.3    Ablaufsteuerung im Script

StartScript erstellen

Startscript zuweisen

9.2.4    Eine Schleife programmieren

9.2.5    Eine Meldung ausgeben

9.3       Einige wichtige Scriptschritte

Aktuellen Datensatz prüfen

Aktuelles Script verlassen

Alle Datensätze löschen

Alles auswählen

Datei öffnen

Datei schlieβen

Datensätze zeigen als

Einfügen

Ergebnismenge suchen

Ersetze alle Feldwerte

Feldwert setzen

Kopie speichern unter

Nächste fortlaufende Nummer setzen

Neues Fenster

Programm beenden

9.4       FileMaker Pro Advanced

Werkzeuge

Runtime-Lösungen

Weitere Advanced-Funktionen

9.5       Fazit

Kapitel 10 FileMaker Pro 12 kommunikativ und sicher

10.1    Sicherheit mit FileMaker

10.2    Datenbanken schützen

10.2.1  Konten einrichten

10.2.2  Eigene Berechtigungen definieren

10.2.3  Kontonamen und Passwörter

10.2.4  Duplizieren und Löschen von Konten

10.3    FileMaker Pro 12 im Netzwerk

10.3.1  Voraussetzungen für den Einsatz von FileMaker Pro im Netzwerk

Windows- oder OS-X-Netzwerk

Netzwerk Client und Host

10.3.2  FileMaker Pro 12 für das Netzwerk vorbereiten

10.3.3  Arbeiten mit einer FileMaker-Datenbank im Netzwerk

Auf eine Netzwerkdatenbank vom Client aus zugreifen

Gemeinsamer Zugriff auf einen Datensatz

Meldungen an andere Datenbanknutzer verschicken

Schlieβen einer Datenbank auf dem Host

Probleme im Datenbanknetzwerk

10.4    FileMaker Pro 12 und das Internet

10.4.1  Ins Internet mit FileMaker Pro

10.4.2  Eine Datenbank für das Web-Publishing vorbereiten

10.4.3  Web-Datenbank austesten

10.4.4  Beenden einer Internet-Sitzung

10.5    Schnittstellen

10.5.1  Export und Importformate

Importformate

Datenexport

10.5.2  ODBC und JDBC

Kapitel 11 Tipps, Tricks & Troubleshooting

11.1    Beziehungen bearbeiten

11.1.1  Self-Join-Beziehung aufbauen und nutzen

11.1.2  Beziehungen bearbeiten

11.2    Diagramme mit FileMaker Pro erstellen

11.2.1  Eine schnelle Tabelle anlegen

11.2.2  Das Diagramm erstellen

11.2.3  Das Diagramm bearbeiten

11.3    Troubleshooting

11.3.1  Beschädigte Daten

11.3.2  Beschädigte Datei wiederherstellen

11.3.3  Einen beschädigten Datensatz retten

11.4    Tipps & Tricks

11.4.1  Dublettensuche

11.4.2  Erweiterte Menüs (OS X)

11.4.3  Feld duplizieren

11.4.4  Felder beim Duplizieren nicht füllen

11.4.5  Lästige Abfrage

11.4.6  Merkwürdige Zeilenumbrüche

11.4.7  Objekte und Felder kopieren

11.4.8  Tabulatorsprünge in einem Textfeld

11.4.9  Wertelisten mit zwei Feldern füllen

Kapitel 12 FileMaker mobil

12.1    Von FileMaker Mobile zu FileMaker Go

12.2    FileMaker Go benutzen

12.2.1  Installation und Einrichtung

12.2.2  Datenbanken übertragen und synchronisieren

12.2.3  FileMaker-Datenbanken entwickeln

12.2.4  Gemeinsam Datenbestände verwenden

Glossar

Index

Vorwort

Vorwort

Das Vorwort für ein Buch über ein Datenbankmanagementsystem zu schreiben ist eine undankbare Sache. Erkläre ich nun, was eine Datenbank ist? Oder gehört das nicht schon in den Hauptteil des Buches? Ich kann ja nicht davon ausgehen, dass das Wissen über Datenbanken schon so bekannt ist wie beispielsweise die Funktion einer Textverarbeitung. Andererseits irritiere ich dann diejenigen, die mit voller Kenntnis der Thematik zu diesem Buch greifen, weil sie von einer anderen Datenbank kommen und nun einen Einstieg in FileMaker Pro suchen. Sicher ist es da besser, ich halte das Vorwort kurz und lasse die Themen dort, wo sie hingehören: in den Hauptteil des Buches. Der geneigte Leser wird sie dort schon finden.

Dieses Buch hat einige Vorgänger. Seit der Version FileMaker Pro 7 sind vier Bücher erschienen, die diese Datenbanksoftware bis zur Version 11 begleitet haben. Jedes Buch hat davon profitiert, dass Leser dem Autor Rückmeldungen gegeben haben. Das Konzept ist im Großen und Ganzen gleich geblieben – die Vorgehensweise so zu erklären, dass sie praktisch nachvollzogen werden kann. Im Detail hat sich von Buch zu Buch manches geändert. Außerdem ist es mir wichtig, die theoretischen und grundlegenden Zusammenhänge zu Datenbanken nicht nur mit dem Blick auf FileMaker zu betrachten, sondern auf allgemeiner Ebene zu behandeln, ohne dabei zu theorielastig zu werden.

Das Buch ist als Lern- und Arbeitsbuch aufgebaut, das heißt, die Informationen sind so aufbereitet, dass ein systematisches Lernen, aber auch ein gezieltes Nachschlagen möglich ist. Falls Ihnen etwas nicht oder im Gegenteil besonders gut gefällt, falls Sie meinen, dass etwas überflüssig ist oder fehlt, dann schreiben Sie mir eine Mail (radke@smartbooks.de). Ich bemühe mich, auf jede Anfrage zu reagieren, zumindest ist in der Vergangenheit kaum eine Anfrage unbeantwortet geblieben. Es gibt auch Leser, die sich zu jeder neuen Ausgabe melden, was mich freut.

Horst-Dieter Radke

Lauda, im April 2013

Kapitel 1

Datenbankgrundlagen

Dass eine Datenbank nichts ist, auf das man sich setzen kann, weiß jeder, der dieses Buch zur Hand nimmt. Damit ist aber bei vielen schon fast das Ende der Informationen darüber, worum es sich bei diesem Begriff handelt, erreicht. Allerdings sind zwei Gruppen zu unterscheiden: die eine, die es mit griechischen Philosophen Sokrates hält und »weiß, dass sie nichts weiß«. Und die andere, die meint, alles über das Thema Datenbanken zu wissen. Die zweite Gruppe hätte aber niemals dieses Buch zur Hand genommen und wenn doch, dann das erste Kapitel gleich überschlagen. Sie, der Sie es lesen, gehören also zur ersten Gruppe und Sie tun gut daran, bevor Sie mit der Arbeit mit FileMaker beginnen, sich über Grundlegendes bei Datenbanken, auch über FileMaker hinaus, zu informieren. Das Kapitel dient diesem Zweck.

1.1 Datenbankgrundlagen

Wenn Ihnen heute noch jemand den Vergleich mit dem Karteikasten liefert, um eine Datenbank zu beschreiben, dann sollten Sie skeptisch und vorsichtig sein. Ein Karteikasten ist ein lineares System, das nur die Anordnung der Datensätze (Karteikarten) hintereinander zulässt. Der Zugriff von einer Karteikarte auf eine andere Karteikarte ist nur umständlich möglich und auch nur dann, wenn direkte Verweise auf der Karte angebracht sind, die mit dem Ordnungssystem des Kastens übereinstimmen. Je umfangreicher solch eine Karteikartensammlung wird, um so schwieriger wird das Pflegen dieses Verweissystems und der Zugriff auf bestimmte Datensätze, wenn die Informationen nicht direkt im Ordnungsbegriff verankert sind.

In einer Datenbank ist es aber möglich, direkt von einem Datensatz auf einen weiteren zu verweisen. Auch der Zugriff auf bestimmte Datensätze ist auf vielfache Weise möglich. Deshalb schließt sich der Verweis auf den Karteikasten eigentlich aus, wenn man von (elektronischen) Datenbanken spricht.

1.1.1 Was ist eine Datenbank?

Als »Datenbank« bezeichnet man ein System, mit dem umfangreiche Informationen gesammelt und verwaltet werden können. Besteht diese Datenbank aus mehreren Tabellen, zwischen denen Verknüpfungen (Beziehungen) hergestellt werden können, so spricht man von einer »relationalen Datenbank«. Nicht selten wird schon eine einfache Tabelle, wie man sie zum Beispiel aus einer Tabellenkalkulation kennt, als Datenbank bezeichnet. Das ist allerdings nicht korrekt, auch wenn man in einer einzelnen Tabelle Datensätze sinnvoll anordnen kann. Zwar entspricht die Grundstruktur – Zeilen und Spalten nehmen an den Schnittstellen (den Feldern) die Informationen auf – durchaus einer relationalen Datenbank. Da aber keine echten Beziehungen zwischen mehreren Tabellen hergestellt werden können, stimmt der Vergleich nicht.

Eine etwas vereinfachte Definition für eine Datenbank ist folgende:

Eine Tabellenkalkulation wie Excel kann auch Daten verwalten, ist aber trotzdem keine vollwertige Datenbank.

1.1.2 Das relationale Modell

Das wohl bekannteste Datenbankmodell ist das relationale. Es wurde in den sechziger und siebziger Jahren des vergangenen Jahrhunderts bei IBM entwickelt und zwar von Edgar F. Codd (1923 – 2003).

Dr. Codd erhielt 1981 für seine Arbeiten auf dem Gebiet der Datenbank den Turing-Award, eine der höchsten Auszeichnungen in der Informatik.

1.1.3 SQL – oder die Suche nach der letzten Information

Es genügt nicht, dass Informationen in einer Datenbank gesammelt sind, man muss sie auch auswerten können. Je größer die Informationssammlung ist, um so schwieriger wird das Heraussuchen gewünschter Informationen. Deshalb wurden schon früh Such- und Abfragemethoden für Datenbanksysteme entwickelt.

In den siebziger Jahren entwickelte IBM eine Abfragesprache für Datenbanken unter der Bezeichnung SEQUEL (Structured English Query Language). SEQUEL war der Vorläufer von SQL (Structured Query Language). Diese Sprache wurde schnell vom Markt aufgegriffen, führte aber auch zu individuellen »Anpassungen«, sodass bereits 1982 ein Komitee eine ANSI-Norm für SQL zu erarbeiten begann. 1986 wurde die erste offizielle Norm verabschiedet und ein Jahr später die Übernahme des Standards als ISO-Norm festgelegt. Eine zweite Normierung erfolgte 1992 (SQL 2 oder SQL 92). Aktueller Stand der Sprachnorm ist SQL 99 bzw. SQL3.

Die meisten Standardanwendungen sind heute mit SQL-Schnittstellen oder Modulen versehen. Selbst eine Tabellenkalkulation wie Excel kann damit heute aufwarten.

Relationale Datenbanken arbeiten mit Tabellen. In diesen Tabellen werden die klassischen relationalen Operationen der Relationen-Algebra – also Projektion, natürlicher Verbund und Selektion – eingesetzt. Trotzdem ist das Ganze keine Sache ausschließlich für Mathematiker. Wenn Sie noch nie etwas von dieser Art Algebra gehört haben und auch mit den genannten Begriffen (Projektion, Verbund, Selektion) nicht vertraut sind, verstehen Sie die Abfragesprache trotzdem leicht. Sie besteht aus Symbolwörtern wie z. B. SELECT, UPDATE, DELETE, INSERT, die meistens selbsterklärend sind. Man kann den Umgang und die Ausnutzung dieses Systems somit schnell erlernen. FileMaker-Pro-Anwender werden auf diese Sprache zunächst gar nicht zurückgreifen müssen, da die eigenen Such- und Selektionsoptionen so leistungsfähig und dabei noch so bequem anzuwenden sind, dass eine Abfragesprache in der Art von SQL völlig unangemessen erscheint. Interessant wird es dann, wenn mit FileMaker fremde SQL-Datenbanken ausgewertet werden sollen. Aber das ist dann eher ein Thema für den fortgeschrittenen FileMaker-Anwender und -Entwickler.

Wir werden uns in diesem Grundlagenbuch nicht weiter mit dem Thema SQL beschäftigen. Dafür werden die Such- und Filterfähigkeiten von FileMaker Pro 12 genauer ausgeleuchtet.

1.1.4 Datenbanksysteme

Trotz der einfachen Struktur der relationalen Datenbanken, die aus zwei oder mehreren Datentabellen bestehen, zeigt sich bei genauerer Betrachtung, welche Leistungsfähigkeit darin steckt: Die tabellarisch aufgebauten Daten kann man als festes Set in einem Schritt bearbeiten. Der Anwender braucht sich um die physikalischen Details, also darum, an welchen Speicherstellen die Daten abgelegt sind, nicht mehr zu kümmern. Es muss selbst für komplexe Informationsabfragen kein langer und fehlerträchtiger Programmcode geschrieben werden.

Obwohl die relationalen Datenbanksysteme dominieren, sind die hierarchischen Datenbanken, mit denen alles angefangen hat, längst nicht verschwunden. Ein hierarchisches Datenbankmodell bildet die reale Welt durch eine Baumstruktur ab. Jeder Satz (Record) hat also genau einen Vorgänger, mit Ausnahme genau eines Satzes, nämlich der Wurzel der so entstehenden Baumstruktur. Diese alten Datenbanksysteme haben einen Vorteil: Aufgrund ausgefeilter Suchsysteme sind Suchvorgänge sehr schnell. Deshalb werden diese hierarchischen Datenbankstrukturen gern bei der Indexsuche oder in Mailprogrammen (z. B. bei der Namensverwaltung) eingesetzt. Da aber Redundanzen nur schwer zu vermeiden sind und jede Änderung neu programmiert werden muss, ist die Einsatzmöglichkeit dieser hierarchischen Datenbanksysteme inzwischen nur noch selten sinnvoll.

Eine neue Entwicklung sind die objektorientierten Datenbankenmodelle. Dabei gibt es zwei Entwicklungslinien: Die eine versucht die relationalen Datenbanken in Richtung »Objektorientierung« zu erweitern (objektrelationale Datenbanken), die andere geht von den objektorientierten Programmiersprachen aus und bemüht sich um eine Neuentwicklung.

Datenbanken lassen sich aber auch in lokale und Client/Server-Datenbanken unterteilen. Eine lokale Datenbank ist nur auf einem Arbeitsplatz und in der Regel auch nur für einen Benutzer vorhanden. Eine lokale Datenbank kann aber auch auf einem Server liegen und den Zugriff verschiedener Benutzer gleichzeitig zulassen. Dabei werden allerdings immer komplette Tabellen im Netz übertragen. Effektiver ist eine Client/Server-Datenbank. Bei dieser wird ebenfalls die Abfrage verschiedener Benutzer zugelassen – übertragen wird aber immer nur das Abfrageergebnis an den Client. Die Netzbelastung ist erheblich geringer.

Die Standardversion FileMaker Pro 12 ist bereits in Netzwerken einsetzbar. Bis zu neun Anwender können auf eine Serverdatenbank zugreifen. Sollen Datenbanken für mehr Arbeitsplatzrechner zur Verfügung gestellt werden, ist allerdings die FileMaker-Server-Version nötig, die in zwei Ausführungen zur Verfügung steht. FileMaker Server 12 ermöglicht den Zugriff von 250 FileMaker-Pro-Clients. Bei FileMaker Server 12 Advanced ist die Menge der zugreifenden Clients nicht limitiert.

Die Server-Version ist nicht Thema dieses Buches. Weitere Informationen zum Einsatz von FileMaker Pro 12 in Netzwerken finden Sie im Kapitel »FileMaker kommunikativ«.

1.1.5 Probleme der Informationsspeicherung

Eine Datenbank ist mithilfe moderner Datenbank-Managementsysteme (DBMS) wie FileMaker Pro 12 schnell eingerichtet. Eine oder mehrere Tabellen sind in kürzester Zeit konzipiert, und Daten können erfasst werden. Je mehr Daten allerdings in solch einer Datenbank enthalten sind, desto länger müssen Sie suchen, um bestimmte Informationen zu finden. Darüber hinaus kann es vorkommen, das Informationen doppelt oder mehrfach vorliegen. Die Aktualisierung solcher (redundanten) Daten ist nicht unproblematisch.

Verwenden Sie beispielsweise eine Adressdatenbank, so können in verschiedenen Datensätzen gleiche Orte vorkommen. Kritisch kann es werden, wenn wesentliche Details verändert werden.

Diese Überlegungen machen deutlich, dass ein Minimum an Planung nötig ist, wenn eine neue Datenbank angelegt werden soll.

1.2 Datenbankkonzeption

Anstoß zur Entwicklung einer Datenbank gibt in der Regel ein Problem, das einer Lösung bedarf. Informationen, die bereitgehalten, ausgewertet, ergänzt und verändert werden sollen, stehen dabei meist im Mittelpunkt. Die Problemlösung selbst geschieht nicht mit dem Datenbank-Managementsystem – etwa FileMaker Pro 12 – sondern auf dem Papier. Ein Stapel Konzeptpapier und Schreibgeräte in greifbarer Nähe sind deshalb für Datenbankentwickler kein veraltetes Requisit. Selbstverständlich ist auch die elektronische Erfassung am PC in einem Editor oder für den, der es grafisch mag, in einem Zeichenprogramm möglich; keinesfalls aber in der Datenbankanwendung direkt.

1.2.1 Datenmodellierung

Datenmodellierung ist ein Stichwort, das in diesem Zusammenhang immer wieder genannt wird. Gemeint sind damit Verfahren zur Abbildung der relevanten Objekte, ihrer Attribute und Beziehungen. Bis es zu einem brauchbaren Datenmodell kommt, werden in der Regel mehrere Modellierungsstufen durchlaufen.

Es gibt verschiedene Verfahren zur Datenmodellierung. Eines der bekanntesten ist die Entity-Relationship-Methode, die insbesondere bei relationalen Datenbanken häufig angewendet wird. Wichtige Begriffe sind:

Entitätstyp (für die Kopfzeile in einer relationalen Datenbank)

Attribut (für die Spaltenüberschrift)

Entitätsmenge oder –set (die gesamte Tabelle)

funktionale Beziehungen (Relationship, auch Fremdschlüssel)

Entität (Datensatz, Zeile der Tabelle)

Attributwert (Inhalt einer Datenzelle)

Für dieses Buch reicht ein verkürztes Modell, mit dem sich funktionierende Datenbanken selbst mit komplexen Strukturen erstellen lassen, um eine Einführung zu geben.

1.2.2 Eine Datenbank in fünf Schritten

Der Weg zur fertigen Datenbank kann als ein Weg in fünf Schritten beschrieben werden. Um dies besser nachvollziehen zu können, wird dieser Weg exemplarisch an einem Beispiel gezeigt. Sie können diese Schritte allerdings auf jedes Problem, für das Sie eine Datenbank entwickeln wollen, übertragen.

Als Beispiel soll eine Datenbank zur Speicherung von Musik-CDs erstellt werden. Dabei soll es möglich sein, nicht nur nach kompletten CDs zu suchen, sondern auch nach Interpreten und nach Titeln zu strukturieren und zu suchen.

1.2.3 Projektbeschreibung

1. Informationen sortieren: Im ersten Schritt werden nur die Objekte betrachtet, die für die Datenbank in Frage kommen. In diesem Beispiel sind das die CDs.

2. Daten klassifizieren: Im zweiten Schritt werden die Objekte näher untersucht. Dabei ist schnell festgestellt, dass die Titel auf der CD fehlen. Sie kommen als Objekt hinzu.

3. Objekteigenschaften erfassen: Im dritten Schritt werden die Objekteigenschaften beschrieben. Diese Eigenschaften dienen der näheren Beschreibung der Objekte. Den CDs kann ein Veröffentlichungsjahr zugeordnet werden, den Titeln Künstler, vielleicht Komponisten usw. Aus der Vielzahl von Eigenschaften werden diejenigen herausgesucht, die für den speziellen Verwendungszweck der Datenbank benötigt werden.

4. Datenbank einrichten: In der Implementierungsphase wird die Datenbank eingerichtet. Tabellen, Layouts (Formulare, Berichte) und Programme (Skripte) werden erstellt und Testdaten eingegeben.

5. Daten erfassen: In der Nutzungsphase werden die echten Informationen (Daten) erfasst und zur Anwendung freigegeben.

Schritt 1 und 2 stellen die Projektdefinition dar, Schritt 3 die Entwurfsphase. Es folgt dann mit Schritt 4 die Implementierungsphase und mit Schritt 5 die anschließende Nutzung. Mit den ersten drei Schritten beschäftigt sich dieses Kapitel, mit den Schritten 4 und 5 die folgenden.

1.2.4 Das Vermeiden von Mehrfachspeicherungen

Auf das Problem der Mehrfachspeicherung (Redundanz) von Daten, die durch das Sammeln in einer einzigen Tabelle oder durch das Speichern in mehrere, voneinander unabhängige Tabellen entstehen können, habe ich bereits hingewiesen. Es wird dadurch nicht nur mehr Festplattenspeicher benötigt, sondern auch die Performance beeinträchtigt. Hinzu kommt der höhere Verwaltungsaufwand, insbesondere bei der Aktualisierung der Daten. Außerdem ist die Gefahr des Auftretens von Fehlern höher.

Der Prozess der Normalisierung wird an diesem Beispiel in einfacher Form und ohne theoretischen Ballast dargestellt.

Ausgangssituation festlegen

Zunächst muss festgelegt werden, welche Informationen benötigt werden. Die erste Konzeption der Tabellen kann dabei frei und ohne Einschränkung erfolgen. Bezogen auf unser Beispiel könnte die Tabelle CD folgendermaßen aussehen:

Diese Tabelle zeigt deutlich einige Probleme:

Die Informationen im Feld Tracks sind unübersichtlich. Ein gezielter Zugriff auf einen bestimmten Track ist schwierig zu realisieren.

Das Eintragen jeweils nur eines Tracks in einer Zeile führt zu erheblichen Redundanzen in der Tabelle.

Informationen zum Feld Interpret sind dürftig. Das Ergänzen um weitere Spalten führt ebenfalls zu Redundanzen in dieser Tabelle.

Eine brauchbare Datenbank enthält keinerlei redundante Informationen. Das erreicht man durch den Prozess der Normalisierung. Und diese führt man durch, indem man die vorhandenen Tabellen zerlegt, und zwar so lange, bis alle Redundanzen verschwunden sind.

Die erste Normalform – Tabellen werden zerlegt

In der ersten Stufe werden in der Tabelle alle Felder so weit zerlegt, bis jedes Feld nur noch eine Information enthält. Die Tabelle CD sieht in der ersten Normalform folgendermaßen aus:

Das Feld Tracks wurde in zwei Felder (Tracknr, Track) aufgeteilt. Nun ist der Zugriff auf jeden einzelnen Song möglich. Das Problem der Redundanz – wiederholtes Speichern der Informationen – tritt aber überdeutlich zu Tage.

Die zweite Normalform – doppelte Informationen entfernen

Da es das Ziel der Normalisierung ist, redundante Datenspeicherung zu vermeiden, müssen diese doppelten Einträge entfernt werden. Trotzdem sollen die Informationen mit den anderen Objektdaten in einen Zusammenhang gebracht werden können. Erreicht wird dies durch Aufteilung der Tabelle und Festlegung von Primärschlüsseln.

Die Tabellen CD und Tracks sehen in der zweiten Normalform folgendermaßen aus:

Die komplette Trackliste ist nun in eine eigene Tabelle ausgelagert worden. Über das Feld CD-Nr. kann aber auf die Daten der Tabelle CD zugegriffen werden.

Bei umfangreicheren Projekten muss man den Prozess der Normalisierung noch weiter treiben. Manchmal geht es bis zur 5. Normalform. In diesem Fall ist die zweite Normalform ausreichend. Auch das Erweitern der Informationen (Interpret) schenken wir uns an dieser Stelle, da das Ziel, die Normalisierung im Ansatz zu erklären, hier schon erreicht ist.

1.2.5 Schlüssel und Index

Zwei Begriffe schauen wir uns noch an, um das Thema Datenbankgrundlagen abzurunden: Primärschlüssel und Index.

Datensätze eindeutig identifizieren

Der Primärschlüssel wurde in den vorangegangenen Beschreibungen bereits erwähnt. Er ist in relationalen Datenbanktabellen eine wichtige Information, denn er dient zur eindeutigen Identifikation eines Datensatzes in der Tabelle. Kein anderer Datensatz der Tabelle darf den gleichen Primärschlüssel besitzen. Über diesen Schlüssel ist also ein Datensatz eindeutig identifizierbar.

Tatsächlich kann eine Tabelle auch ohne Primärschlüsselfeld erstellt werden. Allerdings kann diese dann niemals als Primärtabelle eingesetzt werden und damit an einer gültigen Beziehung teilhaben. Das bedeutet, dass andere Tabellen nicht auf Datensätze dieser Tabelle verweisen können.

Ein Primärschlüssel in einer Datenbanktabelle hat vielfältige Aufgaben. Dazu gehören:

eindeutige Identifizierung eines jeden Datensatzes

Indexerstellung für die schnelle Suche nach Datensätzen

Anzeige der Daten in Primärschlüssel-Reihenfolge

Verhindern eines weiteren Datensatzes mit identischem Schlüssel.

FileMaker war schon immer die »etwas andere Datenbank«. Bei FileMaker Pro sind es die Abgleichfelder, die eine entsprechende Schlüsselfunktion haben. Ein Abgleichfeld ist ein Feld in der aktuellen Tabelle und ein Feld in einer Bezugstabelle, deren Werte für den Zugriff auf übereinstimmende Datensätze verwendet werden. Im Glossar von FileMaker Pro (finden Sie über Hilfe | FileMaker Pro Hilfe; das Glossar steht als letzter Eintrag unter Referenz) findet man dann unter Schlüssel noch die Definition: eine oder mehrere Spalten, durch die eine bestimmte Zeile eindeutig wird (entspricht einem Abgleichfeld).

Das FileMaker-Glossar wird über die Hilfe aufgerufen.

Auf den Index gesetzt

In Datenbanken werden Indizes verwendet, um Datenbestände zu sortieren und Datenbankoperationen zu beschleunigen. Wird eine Tabelle ohne Index angelegt, werden die Daten in den Tabellen durch das Datenbankmanagementsystem in der Reihenfolge der Eingabe abgespeichert und auch in dieser Reihenfolge angezeigt. Ist ein Primärschlüssel festgelegt, wird zwar immer noch in der Reihenfolge der Eingabe gespeichert, die Anzeige der Daten erfolgt jetzt aber in der Sortierung nach dem Primärschlüssel.

Das funktioniert, weil das Datenbankmanagementsystem automatisch eine weitere Tabelle anlegt, in der die sortierten Primärschlüssel mit einem Hinweis auf den zugehörigen Datensatz hinterlegt werden. Auf diese Indextabelle wird zuerst zugegriffen, sodass die eigentliche Tabelle immer in der vorgegebenen Sortierung erscheint.

Haben Sie zum Beispiel eine umfangreiche Adressdatenbank, in der Sie oft auch Adressen anhand des Namens suchen, erhöht die Indizierung dieses Feldes die Suchgeschwindigkeit. Nicht die gesamte Tabelle wird dadurch in den Speicher geladen und durchsucht, sondern nur der Index. Wird ein passender Name gefunden, wird die zugehörige Adresse geladen. Dies geschieht vollautomatisch im Hintergrund. Sie müssen in der Tabelle nur die entsprechenden Felder als Index auswählen.

Die Nachteile einer Indizierung sind die, dass zusätzlicher Platz auf dem Datenträger benötigt wird und dass Aktualisierungsvorgänge sich verlangsamen. Schließlich muss jede Änderung auch in den Indextabellen berücksichtigt werden. Es ist also immer abzuwägen, inwieweit eine Tabelle beziehungsweise Datenbank durch zusätzliche Indizierung noch vergrößert werden soll. Eine richtig eingesetzte Indizierung sorgt allerdings für eine funktionale und gut zu handhabende Datenbank.

FileMaker Pro 12 stellt Optionen zur Indizierung von Feldern bereit und erlaubt auch das Speichern von berechneten Ergebnissen. Dazu mehr in den folgenden Kapiteln.

Beziehungen pflegen

Eine Tabelle macht noch keine Datenbank; zumindest keine relationale Datenbank. Erst wenn mehrere Tabellen miteinander verknüpft werden, kann man von einer echten, relationalen Datenbank sprechen. Diese Verknüpfungen nennt man auch »Beziehungen«.

Im Beispiel der CD-Datenbank wurde der Prozess der Normalisierung durchgeführt, damit redundante Informationen in der Datenbank nicht mehr vorkommen. Erreicht wurde das durch Aufteilung des Datenbestands in zwei Tabellen. Da die Informationen in diesen Tabellen aber irgendwie doch zusammengehören, muss eine Möglichkeit gefunden werden, Verbindungen zwischen diesen Tabellen herzustellen. Diese Verbindungen sind die Beziehungen.

Es gibt vier verschiedene Arten von Beziehungen zwischen Tabellen:

1:1-Beziehungen

1:n-Beziehungen

n:1-Beziehungen

n:m-Beziehungen

Die monogame Beziehung

Wird ein Datensatz einer Tabelle mit nur genau einem Datensatz einer anderen Tabelle in Beziehung gesetzt, spricht man von einer 1:1-Beziehung (Eins-zu-Eins-Beziehung). Das kommt zum Beispiel dann vor, wenn bestimmte Datensätze aufgespalten werden, etwa um differenzierte Zugriffsrechte zu gewährleisten.

Ein Beispiel: Eine umfangreiche Kundentabelle wird aufgeteilt in eine Tabelle, die Informationen allgemeiner Art (etwa die Anschrift) und eine weitere Tabelle, die Informationen spezieller Art (zum Beispiel Umsatz, Bestellhäufigkeit, Ansprechpartner) enthält. Hier kann nur ein Datensatz eines Kunden einem Datensatz in der anderen Tabelle gegenüberstehen.

In unserem CD-Beispiel kommt diese Beziehung nicht vor. Würde aber je CD ein Platz im Regal eingetragen und dieser Platz in einer eigenen Tabelle verwaltet, dann läge solch eine Beziehung vor. Es kann ja immer nur einen Platz für eine CD im Regal geben.

Die offene Beziehung

Am häufigsten kommen die 1:n-Beziehung (Eins-zu-Viele-Beziehung) und die n:1-Beziehung (Viele-zu-Eins-Beziehung) in relationalen Datenbanken vor. Ein Datensatz der einen Tabelle ist mit vielen Datensätzen der anderen Tabelle verbunden (1:n). In der zweiten Tabelle gibt es aber viele Datensätze, die mit einem Datensatz der ersten Tabelle in Beziehung stehen (n:1).

Ein Artikeldatensatz kann zum Beispiel in mehreren Datensätzen der Auftragsdatentabelle vorkommen (1:n). Mehrere Datensätze der Auftragsdatentabelle können aber einem Datensatz der Artikeltabelle gegenüberstehen (n:1). Das Schlüsselfeld in der Tabelle mit der 1:n-Beziehung muss eindeutig sein und kann keine Duplikate zulassen.

In unserem Beispiel besteht zwischen der CD-Tabelle und der Track-Tabelle eine n:1-Beziehung. Ein Track kann immer nur auf eine CD verweisen (n:1). Eine CD kann aber mehrere Tracks in der Tabelle haben (1:n). Das Schlüsselfeld in der Tabelle mit der n:1-Beziehung darf mehrdeutig sein und kann Duplikate zulassen.

Jeder mit Jedem

Die n:m- oder Viele-zu-Viele-Beziehungen sind nicht so unwahrscheinlich, wie man zunächst denken mag. Werden Schüler und Unterrichtsfächer in Verbindung gebracht, so wird dies sofort deutlich. Ein Schüler hat verschiedene Unterrichtsfächer. In einem Unterrichtsfach ist aber nicht nur ein Schüler, sondern es sind viele Schüler vertreten. Eine Datenbank, die Schüler und Unterrichtsfächer verwaltet, zum Beispiel um Stundenpläne zu erstellen, muss dies berücksichtigen.

Beziehung zu sich selbst

Es klingt zunächst paradox: eine Beziehung zu sich selbst – wie soll das möglich sein? Und welchen Nutzen hat das? Diese so genannte Self-Join-Beziehung ist mit FileMaker Pro durchaus zu realisieren. Dabei wird eine Information in einem Datensatz mit allen anderen Datensätzen verglichen. Sie können über solch eine Beziehung das Anlegen von Duplikaten bereits bei der Datenerfassung verhindern. Oder es können über bestimmte Informationen vorhandene weitere Informationen übernommen werden (zum Beispiel über die Bankleitzahl das Bankinstitut). Damit solch eine Beziehung realisiert werden kann, erzeugt FileMaker Pro eine zweite Instanz der Tabelle.

Damit kein Zirkelbezug entsteht, erzeugt FileMaker eine zweite Instanz der Tabelle.

Datenbank-Entwickler haben sich also intensiv mit den Beziehungen in der Datenbank auseinanderzusetzen. Gut organisierte Beziehungen zwischen den Tabellen sorgen für ein effektives und weitgehend problemfreies Arbeiten mit den Datenbanktabellen.

1.3 FileMaker Pro als relationales Datenbank-Managementsystem

FileMaker Pro ist seit der Version 3 ein relationales Datenbanksystem. Daten wurden in Tabellen verwaltet, und zwischen den Tabellen können über Abgleichfelder Beziehungen hergestellt werden. Die Kritik, dass dieses relationale System nur angeflickt sei, ist nur teilweise berechtigt und seit der Version FileMaker Pro 7 gar nicht mehr. Die komplette Datenbank-Engine – also der Teil des Programms, der sich mit der Datenbankverwaltung beschäftigt – wurde neu entwickelt. Sämtliche Tabellen können nun in einer Datei verwaltet werden, und Beziehungen lassen sich grafisch erzeugen. Was FileMaker Pro nach wie vor von anderen Datenbank-Managementsystemen unterscheidet, ist die einfache Handhabung, die schnelle Entwicklung selbst komplexer Datenbanken ermöglicht und leider auch das Fehlen einer objektorientierten Programmiersprache.

Beziehungen erzeugen Sie per Mausklick.

1.4 FileMaker Pro und andere Datenbank-Managementsysteme

Obwohl FileMaker Pro nach wie vor Marktführer auf Apple-Computern ist, droht inzwischen Konkurrenz durch die freie Datenbank MySQL. Da OS X im Grunde ein Unix-Betriebssystem ist, war es eine Frage der Zeit, wann Adaptionen dieser Open-Source-Datenbank für den Mac verfügbar sein würden. Aber ist MySQL wirklich eine Konkurrenz für FileMaker Pro?

Wer sich näher mit dieser Thematik beschäftigt, wird schnell sehen, dass dies nicht so ist. MySQL ist ein »reines« Datenbank-Managementsystem mit einer sehr rustikalen Benutzerschnittstelle. Eine Datenbankentwicklung, wie sie mit FileMaker Pro 12 möglich ist, ist mit MySQL schlichtweg nicht denkbar. Zwar existieren inzwischen einige Tools (z. B. phpMyAdmin), welche die Administration einer MySQL-Datenbank erleichtern; ein Vergleich mit der Flexibilität von FileMaker Pro ist aber trotzdem nicht möglich.

MySQL ist dort interessant, wo SQL-Datenbanken im Netzwerk (besonders im Internet) gefragt sind und entsprechende Entwickler zur Verfügung stehen. Große Datenbestände, die ständig aktualisiert werden müssen, und komplexe Abfragen sind die Hauptdomäne solcher Datenbanken. Da MySQL sehr stabil, dazu weltweit erprobt und bei richtiger Konfiguration auch sehr schnell ist, steht damit eine gute Lösung für Netzwerke und das Internet bereit. Für den Privatanwender ist MySQL aber ohne tiefere Kenntnisse einer Skriptsprache wie PHP oder Python, mit der Datenbank-Anwendungen benutzerfreundlich entwickelt werden können, keine sinnvolle Lösung. Auch der Datenbankentwickler wird mit MySQL nicht so schnell und flexibel Anwendungen entwickeln können wie mit FileMaker.

MySQL ist Open Source und damit kostenlos. Ebenso der Webserver Apache und die Skriptsprache PHP. Wer aber deshalb davon ausgeht, dass eine Webdatenbank in dieser Kombination billiger ist als eine FileMaker-Pro-12-Lösung, der macht möglicherweise einen schwerwiegenden Fehler. Der Entwicklungs- und Pflegeaufwand ist bei einer XAMP- (OS X/Apache/MySQL/PHP) oder WAMP-Lösung (Windows/Apache/MySQL/PHP) erheblich größer als bei FileMaker Pro.

Hauptkonkurrent im Windows-Umfeld ist sicher nach wie vor Microsoft Access. Dank der integrierten und objektorientierten Programmiersprache Visual Basic for Application (VBA) können damit Datenbank-Anwendungen entwickelt werden, die sich sehr flexibel den jeweils geforderten Bedingungen anpassen lassen. FileMaker Pro kann da mit den eigenen Skriptbefehlen – die in etwa mit den Makrobefehlen von MS Access verglichen werden können – nicht mithalten. Abgesehen davon hat FileMaker Pro inzwischen aufgeholt – mit jedem weiteren Versionssprung jedes Mal noch ein weiteres Stück. In Sachen Benutzerfreundlichkeit ist FileMaker Access um Längen voraus.