Krähenfuss-Notation

Krähenfuß - korrekt: Information-Engineering-Notation - setzt an jedes Ende einer Beziehungslinie zwei Zeichen. Das weiter von der Entität entfernte ist das Maximum, das näher an der Entität das Minimum.

Kombiniert ergeben sich genau vier Möglichkeiten, und das ist die ganze Notation:

Das ist die einzige Sache am Krähenfuß, die wirklich gegen die Intuition läuft, und sie erklärt die meisten falsch gelesenen Diagramme. Die Symbole an einem Ende beschreiben die Entität an diesem Ende, und man liest sie, während man sich auf diese Entität zubewegt.

Auf der vierten Linie im Diagramm oben sitzt der Krähenfuß am Order-Ende. Er bedeutet nicht „viele Kunden“. Er bedeutet: zu einem Kunden gehören null oder mehr Bestellungen. Sagen Sie es als Reise - „ich starte bei einem Kunden, folge der Linie und komme bei null oder mehr Bestellungen an“ - und die Richtung ist nicht mehr mehrdeutig.

Eine Gewohnheit, die das Problem ganz beseitigt: schreiben Sie die Verbphrase in Leserichtung auf die Linie und lesen Sie die Rückrichtung laut, bevor Sie weitergehen. Dreißig Sekunden pro Beziehung - und es findet Fehler, die in einem Dokument monatelang überleben.

Der Linienstil trägt eine zweite Information, und die betrifft Schlüssel statt Anzahlen.

Der Test ist eine Frage: ließe sich diese Zeile ohne Kenntnis ihres Elternteils identifizieren? Eine Bestellposition Nummer 3 ist ohne die Bestellung sinnlos - das ist identifizierend. Eine Bestellung von Kunde 41 ist unabhängig davon weiterhin Bestellung 8817 - das ist nicht identifizierend.

Ein Krähenfuß an beiden Enden sagt „viele zu viele“, und keine relationale Datenbank kann das in zwei Tabellen speichern. Die Beziehung wird zu einer eigenen Entität - einer Verknüpfungs-, Assoziations- oder Link-Entität - die je einen Fremdschlüssel auf beide Seiten hält.

Daraus folgen zwei Dinge, und das zweite ist der Grund, das früh zu tun statt erst bei der Umsetzung:

1. Die Verknüpfungsentität hat meist eigene Attribute. Eine Einschreibung hat ein Datum, eine Note, einen Status. Diese Attribute hatten keinen Ort, solange die Beziehung eine Linie war, und ihr Fehlen verbarg eine Lücke im Modell.
2. Die Verknüpfungsentität verdient einen echten Namen. Enrolment, Booking, Assignment - nicht StudentCourse. Ein Fachexperte erkennt das erste und kann das zweite nicht prüfen, und der Name ist meist ein Wort, das der Fachbereich schon benutzt.

Beachten Sie die Schlüssel in der Verknüpfungsentität oben: beide Fremdschlüssel bilden zusammen den Primärschlüssel, und genau das verhindert, dass sich derselbe Studierende zweimal in denselben Kurs einschreibt. Diese Einschränkung kam gratis aus sauberer Modellierung und wäre sonst eine Validierung gewesen, an die jemand gedacht hat.

Nichts davon schließt sich aus. Sehr viele reale Projekte zeichnen Krähenfuß für die Datenbank und ein Klassendiagramm für das Domänenmodell und behalten beides, weil sie verschiedene Fragen zu denselben Substantiven beantworten.

1. Symbole am falschen Ende. Der häufigste Fehler in dieser Notation. Lesen Sie beide Sätze laut.
2. Alles optional. Ein Kreis an jeder inneren Position heißt, das Modell behauptet keine Regeln - und jede davon wird stattdessen Anwendungscode.
3. n:m im logischen Modell belassen. Konzeptionell in Ordnung, physisch unmöglich. Lösen Sie es auf und benennen Sie die Verknüpfung.
4. Verknüpfungsentitäten durch Aneinanderreihen benannt. OrderProduct sagt einem Prüfer nichts; OrderLine sagt ihm alles.
5. Sich allein auf den Strichstil verlassen. Werkzeuge sind sich uneins. Zeigen Sie den zusammengesetzten Schlüssel auch im Kasten.
6. Unbeschriftete Beziehungen. Das Verb macht die Linie laut lesbar - und das laute Lesen ist das Review.

Ist die Kardinalität geklärt, lautet die nächste Frage, welche Tabellen es überhaupt geben soll - und das ist Schema-Entwurf: Schlüssel, Normalisierung und der Weg vom Modell zum DDL.