Planen einer relationalen Datenbank

Bevor Sie eine relationale Datenbank mithilfe des Beziehungsdiagramms erstellen, gestalten Sie Ihre Datenbank auf Papier oder am Bildschirm. Im Datenbankjargon ist der Plan, den Sie entwickeln, ein Entity-Relationship-Diagramm.

Die allgemeinen Schritte beim Entwickeln einer eigenen FileMaker Pro-App finden Sie unter Erstellen eigener Apps.

So planen Sie eine relationale Datenbank:

  1. Bestimmen Sie die Kategorien der Informationen, die Ihre relationale Datenbank benötigt. Diese Kategorien werden dann Tabellen in FileMaker Pro.

    Eine typische Vertriebsdatenbank könnte z. B. folgende Tabellen enthalten: „Kunden“ mit Kundendaten, „Rechnungen“ mit Bestelldaten und „Produkte“ mit Produktinformationen.

  2.  

    Kunden-, Rechnungen- und Produkttabellen

  3. Legen Sie die Beziehungen für die Tabellen untereinander fest. Dafür können Sie den Zusammenhang zwischen den Kategorien in einfache Sätze fassen, z. B. „Kunden bestellen Produkte“ und „Rechnungen folgen auf Kundenbestellungen“.
  4. Verbinden Sie eine Tabelle mit einer anderen, um eine Beziehung zwischen ihnen zu zeigen. „Kunden“ kann beispielsweise „Rechnungen“ enthalten und „Rechnungen“ kann „Produkte“ enthalten.

    Wenn eine Tabelle keine Beziehung zu einer anderen aufweist, ist sie wahrscheinlich überflüssig. In diesem Beispiel passt die Tabelle „Mitarbeiter“ nicht in diese relationale Datenbank.

  5.  

    Drei Tabellen zeigen Beziehungen zueinander, Tabelle „Mitarbeiter“ nicht.

  6. Geben Sie den Beziehungstyp zwischen Tabellen an, indem Sie sie mit einem entsprechenden Symbol verbinden.
    • In einer 1:1-Beziehung entspricht ein Datensatz in Tabelle A genau einem Datensatz in Tabelle B.
    • In einer 1:n-Beziehung entspricht ein Datensatz in Tabelle A mehreren Datensätzen in Tabelle B.
    • In einer n:n-Beziehung entsprechen mehrere Datensätze in Tabelle A mehreren Datensätzen in Tabelle B.

    Weitere Informationen finden Sie unter Erläuterung von Beziehungen.

  7.  

    Drei Tabelle mit ihren Beziehungen zueinander

    Dieses Beispiel zeigt:

    • Ein Kunde kann mehrere Rechnungen haben.
    • Ein Produkt kann auf vielen Rechnungen vorkommen.
    • Eine Rechnung kann viele Produkte umfassen.
  8. Beachten Sie, dass zwischen „Rechnungen“ und „Produkte“ eine n:n-Beziehung besteht. Es ist nicht möglich, eine n:n-Beziehung direkt zwischen zwei Tabellen einzurichten.

    Relationale Datenbanken können nur 1:1- und 1:n-Beziehungen direkt verarbeiten. Sie müssen die n:n-Beziehung durch eine Zwischentabelle lösen, die die n:n-Beziehung in zwei 1:n-Beziehungen zerlegt. Um das Problem in diesem Beispiel zu lösen, fügen Sie die Zwischentabelle „Positionen“ hinzu, die Informationen über verkaufte Produkte speichert.

  9.  

    Angepasste Beziehungen mit der Tabelle „Positionen“ als Verknüpfungstabelle

    Nach dem Auflösen der n:n-Beziehung zeigt dieses Beispiel:

    • Ein Kunde kann mehrere Rechnungen haben.
    • Eine Rechnung kann viele Positionen umfassen.
    • Ein Produkt kann in vielen Positionen vorkommen.
  10. Legen Sie die Felder fest, die jede Tabelle braucht.

    Jede Tabelle dient nur einem Zweck und alle Felder in einer Tabelle beschreiben nur diesen Zweck. Beispiel: Die Felder in einem Datensatz in der Kundentabelle enthalten alle Informationen zu einem Kunden.

    Aus demselben Grund sollten Sie jedem Kunden eine eindeutige Nummer zuordnen. In Ihrer Datenbank ist das ein Primärschlüssel. Sie geben eine KundenID erst dann an, wenn Sie einen neuen Kunden hinzufügen, d. h., die Existenz einer KundenID bestimmt die Existenz eines Datensatzes. Eine Kundentabelle kann auch Felder für Name, Adresse und Telefonnummer des Kunden enthalten.

    Eine Produkttabelle kann Felder für eine Produktnummer, Stückpreis für jedes Produkt und Lagerbestand enthalten. Eine Positionentabelle kann Felder für ProduktID und RechnungsID, Name, Stückpreis, Anzahl und Gesamtpreis jedes verkauften Produkts enthalten. Eine Rechnungstabelle könnte Felder für RechnungsID, Bestelldatum und Verkäufer enthalten.

  11.  

    Aufgelistete Felder pro Tabelle

  12. Legen Sie das Primärschlüsselfeld (bzw. mehrere Primärschlüsselfelder für eine Beziehung mit mehreren Kriterien) für jede Tabelle fest und markieren Sie jedes in Ihrem Plan. Kennzeichnen Sie dann das bzw. die Fremdschlüsselfelder in jeder Tabelle.

    In diesem Beispiel:

    • Die Primärschlüssel sind „Kunden::KundenID“, „Rechnungen::RechnungID“, „Produkte::ProduktID“ und „Positionen::PositionID“.
    • Die Fremdschlüssel sind „Rechnungen::KundenID“ und „Positionen::ProduktID“.
  13. Zur Anzeige von Kundendaten in der Tabelle „Rechnungen“ benötigen Sie ein gemeinsames Feld zwischen den beiden Tabellen, um eine Beziehung festzulegen. KundenID ist dieses gemeinsame Feld. In der Tabelle „Kunden“ ist dies der Primärschlüssel, in der Tabelle „Rechnungen“ der Fremdschlüssel.

    In der Tabelle „Positionen“ ist „ProduktID“ das gemeinsame Feld zwischen den Tabellen „Positionen“ und „Produkte“. In der Tabelle „Produkte“ ist dies der Primärschlüssel, in der Tabelle „Positionen“ der Fremdschlüssel.

    Diese Schlüsselfelder sind eine Art von Abgleichsfeld. Weitere Informationen finden Sie unter Erläuterung von Beziehungen.

     

    Umkringelte Schlüsselfelder in jeder Tabelle

  14. Entscheiden Sie für jede Tabelle, welche Felder Daten speichern und welche Felder Daten aus anderen (Bezugs-) Tabellen anzeigen sollen.

    Basierend auf dem Zweck einer Tabelle können Sie sehen, wo Daten gespeichert werden und wo sie aus einer Bezugstabelle stammen sollen. Im Unterschied zu Schlüsselfeldern sollten alle anderen Felder nur einmal in Ihrer Datenbank vorkommen. Streichen Sie jedes Auftreten von Feldern durch, die nicht zum Thema der Tabelle gehören.

  15.  

    Durchgestrichene überflüssige Felder in den Tabellen

  16. Verbinden Sie jeden Primärschlüssel mit seinem entsprechenden Fremdschlüssel in der Bezugstabelle.

    Eine Beziehung zwischen Tabellen wird dadurch etabliert, dass ihre Schlüsselfelder Daten enthalten, die den Kriterien der Beziehung entsprechen.

  17.  

    Beziehungen zwischen Schlüsselfeldern in den Tabellen

    Dieser Plan zeigt jetzt:

    • Ein Kunde kann mehrere Rechnungen haben, aber für eine einzelne Rechnung ist nur ein Kunde möglich.
    • Eine Rechnung kann mehrere Positionen enthalten, aber eine einzelne Position erscheint nur auf einer Rechnung.
    • Ein Produkt kann auf mehreren verschiedenen Positionen erscheinen, aber eine einzelne Position enthält nur ein Produkt.