Die Beziehungen zeichnen
Auch in 28 Sprachen
English · Español · 日本語 · Português (Brasil) · Français · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 2 von 6 im Kapitel Daten nach ihrer Bedeutung modellieren, Kapitel 2 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Auf die Substantive hören · Weiter: Das logische Modell aufbauen
Die Frage, die dieses Modul beantwortet: Wie verwandle ich mögliche Entitäten in ein konzeptionelles Datenmodell?
Wir haben Substantive an der Tafel. Jetzt möchte ich etwas über die Linien zwischen den Kästen wissen, denn eine Sammlung von Entitäten ist noch kein richtiges Datenmodell. In den Beziehungen steckt ein großer Teil der Bedeutung. Ein Handelspartner betreibt Verteilzentren. Eine Ladeliste führt Lieferungen auf. Eine Lieferung geht an einen Empfänger. Eine Crew fährt einen Lkw. Jede dieser Aussagen sagt mir etwas über das Geschäft, und jede liefert mir eine weitere Frage.
Beginnen Sie mit der Sprache des Geschäfts
Abschnitt betitelt „Beginnen Sie mit der Sprache des Geschäfts “Ich möchte immer noch nicht über Salesforce sprechen. Ich frage nicht, ob das eine Nachschlage- oder eine Master-Detail-Beziehung sein soll, denke nicht an Salesforce-Verbindungsobjekte (Junction Objects) und entscheide nicht, was passiert, wenn ein übergeordneter Datensatz gelöscht wird. Ich versuche, die geschäftliche Beziehung zu verstehen.
Nehmen Sie „Ein Handelspartner betreibt Verteilzentren.“ Klingt einfach. Aber kann ein Handelspartner ein Verteilzentrum haben oder viele? Bei Steve Trucking betreibt jeder Handelspartner in jeder Region, die Steve Trucking bedient, ein regionales Verteilzentrum, also viele. Kann ein Verteilzentrum zu mehr als einem Handelspartner gehören? Zählt ein Verteilzentrum für sich, mit eigenem Personal und eigener Historie, oder ist es nur eine Adresse? Wenn ein Handelspartner geht, interessieren uns seine Verteilzentren dann noch?
Das sind keine Salesforce-Fragen. Es sind Geschäftsfragen, und die Antworten können das Modell völlig verändern.
Die Linien lesen
Abschnitt betitelt „Die Linien lesen “Bevor wir tiefer gehen, möchte ich Ihnen die Sprache geben, die wir ab jetzt in jedem Diagramm verwenden. Sie ist klein. Eine Linie zwischen zwei Kästen sagt, dass die beiden Dinge zusammenhängen, und die Markierungen an ihren Enden sagen, wie viele.
Beginnen Sie mit einer einfachen Linie, ganz ohne Markierungen. So fange ich am Whiteboard an: Ich weiß, dass diese beiden Substantive zusammenhängen, ich habe nur noch nicht gefragt, wie. Dann bekommen die Enden Markierungen. Ein einzelner Querstrich über der Linie bedeutet eins. Der Krähenfuß, das Ende, das sich wie ein Vogelfuß in drei teilt, bedeutet viele. Später in diesem Modul sehen Sie neben der ersten eine zweite Markierung erscheinen, einen Strich oder einen Kreis, und die beantwortet eine andere Frage: Kann es auch keinen geben?
Die eine Regel, die Sie sich merken sollten: Sie lesen jede Markierung an dem Kasten, den sie berührt. Die Markierung am nächsten zum Kasten ist das Höchste, was es geben kann; die nächste Markierung weiter außen ist das Mindeste.
Sitz, Bleib, Modell
Abschnitt betitelt „Sitz, Bleib, Modell “Vor Steve Trucking zurück zu den Hunden aus Modul 1. Wir hatten fünf Kästen: Halter:in, Züchter:in, Hund, Rasse und Trick. Jetzt frage ich nach den Linien dazwischen.
Einer oder viele? Halter:innen können mehr als einen Hund haben; Ana hat zwei. Ein Hund hat eine haltende Person, zumindest in unserem Modell. Das ist eins-zu-viele: ein Strich bei Halter:in, ein Krähenfuß beim Hund. Züchter:innen haben dieselbe Form: Ein Zuchtbetrieb züchtet viele Hunde.
Kann es keinen geben? Max kommt aus dem Tierheim, er hat also überhaupt keinen Zuchtbetrieb. Das Ende bei Züchter:in bekommt einen Kreis: Ein Hund hat null oder eine:n Züchter:in. Jeder Hund hat aber eine haltende Person, also bekommt dieses Ende einen zweiten Strich: genau eine.
Viele zu viele? Ein Hund kann viele Tricks, und ein Trick, sagen wir Sitz, wird von vielen Hunden beherrscht. Das ist viele-zu-viele, und genau dort suche ich nach einem versteckten Konzept. Gibt es etwas darüber, dass dieser Hund diesen Trick kann? Wie gut sie ihn macht und wann sie ihn gelernt hat. Die Beziehung hat eigene Tatsachen, also wird sie ein eigenes Ding: Hundetrick, mit dem Hund zuerst im Namen, weil der Hund derjenige ist, der sie antreibt.
Was bedeutet jede Linie? Halter:innen halten einen Hund. Ein Zuchtbetrieb züchtet ihn. Ein Hund kann seine Tricks. Benennen Sie die Linien, und jede:r kann Ihnen das Modell vorlesen.
Jetzt oder im Zeitverlauf? Interessiert es jemanden, wie gut Bella Sitz heute kann, oder wie sie dorthin gekommen ist? Wenn eine Trainerin oder ein Trainer sie alle paar Monate prüft, ist jede Prüfung ein eigener Datensatz: eine Trickbewertung, mit dem Datum, dem Niveau und der Person, die geprüft hat, unter dem Hundetrick, zu dem sie gehört. Selbst eine Beziehung, die zu einem Ding wurde, kann ihre eigene Historie haben.
Die Rasse lasse ich vorerst unverbunden. Sie ist immer noch die Frage aus Modul 1, ein eigener Kasten oder ein Wort beim Hund, und Modul 4 klärt sie.
Jede dieser Fragen funktioniert bei einem echten Geschäft genauso. Stellen wir sie jetzt Steve Trucking.
Fragen Sie „eins oder viele?“
Abschnitt betitelt „Fragen Sie „eins oder viele?“ “Eines der ersten Dinge, die ich über eine Beziehung verstehen möchte, ist ihre Kardinalität. Das ist der Datenbankbegriff; die Frage ist viel einfacher: Wie viele hiervon können mit wie vielen davon zusammenhängen? Auf der konzeptionellen Ebene gibt es drei Grundmuster.
Das ist ein wichtiger Schritt im Vorgehen: Nehmen Sie zwei verschiedene Substantive und verstehen Sie ihre Beziehung. Meist ist es eine Eins-zu-viele- oder eine Viele-zu-eins-Beziehung. Nur selten begegnen Sie einer Eins-zu-eins-Beziehung.
Eins-zu-viele ist überall. Ein Handelspartner hat viele Verteilzentren. Eine Ladeliste führt viele Lieferungen auf. Eine Tour hat etwa zehn Stopps. Wenn ich solche Formulierungen höre, beginne ich die Linie zu zeichnen.
Und jetzt bekommt die Linie ihre Markierungen. Jedes Ende sagt Ihnen, wie viele es von dem Kasten gibt, den es berührt: der Strich für eins, der Krähenfuß für viele. Lesen Sie es von jedem Kasten aus: Ein Handelspartner hat viele Verteilzentren.
Eins-zu-eins-Beziehungen gibt es, aber sie sind selten, und wenn ich eine finde, stelle ich Fragen. Sind das wirklich zwei verschiedene Substantive oder dasselbe? Wenn sie verschieden sind, was ist die Eins-zu-eins-Beziehung zwischen ihnen? Und wird sie immer eins zu eins sein oder nur im Moment? Das sind Schlüsselfragen beim Entwurf des Datenmodells. Eine Crew und ein Lkw wirken an jedem Morgen eins zu eins: zwei Personen, ein Lkw, eine Tour. Über einen Monat gesehen sind sie es nicht, und genau dort versteckt sich die interessanteste Beziehung in diesem Modell.
Viele-zu-viele-Beziehungen sind besonders interessant, denn sie zeigen oft, dass es im Geschäft ein weiteres Konzept gibt. Kann eine Crew im Lauf der Zeit mehr als einen Lkw fahren? Ja. Kann ein Lkw von mehr als einer Crew gefahren werden? Über seine Lebensdauer ganz sicher. Crews und Lkw haben also eine Viele-zu-viele-Beziehung. Aber jetzt möchte ich mehr wissen. Interessiert das Geschäft, wann eine Crew einen Lkw hatte? Für welche Tour, an welchem Tag? Wer hat die Zuweisung vorgenommen? Wenn die Beziehung selbst Informationen trägt, die uns interessieren, haben wir ein weiteres Geschäftskonzept entdeckt: die Crew-Zuweisung (Crew Assignment).
Das ist eine wichtige Gewohnheit beim Modellieren. Manchmal ist das Interessanteste keines der Substantive, die wir zuerst gehört haben. Es versteckt sich in der Beziehung zwischen zwei Substantiven.
Beziehungen können zu Dingen werden
Abschnitt betitelt „Beziehungen können zu Dingen werden “Das ist eine der Stellen, an denen alle aus der Administration anders denken sollen. In Salesforce sind wir es gewohnt, über Objekte und Felder zu sprechen, also behandelt man leicht die Kästen als das Wichtige und die Linien als Leitungen. Aber die Beziehung selbst kann eine geschäftliche Bedeutung haben.
Denken Sie an eine Lieferung und die Produkte darauf. Eine Lieferung kann mehrere Produkte umfassen, etwa eine Waschmaschine und einen Trockner. Ein Produkt, dasselbe Kühlschrankmodell, taucht auf Tausenden von Lieferungen auf. So weit, so einfach. Aber was, wenn ich wissen muss, wie viele von diesem Produkt auf dieser Lieferung sind, ob es installiert wird oder ob das alte Gerät mitgenommen wird? Dann interessiert mich nicht mehr nur eine Beziehung zwischen Lieferung und Produkt. Mich interessiert eine Lieferposition (Delivery Item), und dieses Konzept verdient eine eigene Entität.
Wenn Sie aus der Salesforce-Welt kommen, denken Sie vielleicht schon: „Das ist ein Verbindungsobjekt.“ Das ist nicht falsch. Aber ich möchte nicht dort anfangen. Eine Lieferposition ist ein Geschäftskonzept, bevor sie ein Salesforce-Verbindungsobjekt (Junction Object) ist. Zuerst das Geschäft, dann die Umsetzung.
Ein paar meiner Gewohnheiten für diese Beziehungsentitäten, wo immer sie am Ende gebaut werden.
Geben Sie ihr einen Namen. Wenn das Geschäft schon ein Wort dafür hat, verwenden Sie seines. Wenn nicht, nehmen Sie die Namen der beiden übergeordneten Entitäten und setzen Sie sie zusammen. Denken Sie an einen Auftrag und ein Produkt. Das Ding dazwischen ist die Auftragsposition: der Auftrag und die Position darauf. Es ist ein untergeordnetes Element beider Eltern und wird in Salesforce vielleicht ein Salesforce-Verbindungsobjekt. Aber welcher Name kommt zuerst: Positionsauftrag oder Auftragsposition? Sehen Sie sich an, welche Art von Daten jedes Elternteil ist. Das Produkt ist Referenzdaten; der Auftrag ist eine Transaktion, und der Auftrag treibt es an. Also heißt es Auftragsposition oder Auftragsprodukt, so wie Salesforce das Opportunity-Produkt hat. Bei Steve Trucking ist es die Lieferposition. Der treibende Name kommt zuerst, und der Datensatz sortiert sich in jeder Liste, die Sie je ansehen, neben seinem Besitzer ein.
Geben Sie ihr einen eigenen Schlüssel. Es ist verlockend zu sagen, eine Lieferposition wird durch Lieferung plus Produkt identifiziert, und es dabei zu belassen. Das ist ein zusammengesetzter Schlüssel, und mit zusammengesetzten Schlüsseln ist viel schwerer umzugehen: Jedes System, das auf den Datensatz verweist, muss beide Hälften mitführen. Geben Sie der Beziehungsentität eine eigene Kennung und behalten Sie Lieferung plus Produkt als Regel über die Eindeutigkeit, nicht als Identität.
Beachten Sie, was nicht darauf steht: eine Seriennummer. Eine Menge und eine Seriennummer gehören nicht in denselben Datensatz. Eine Menge zählt mehrere Exemplare einer Sache; eine Seriennummer identifiziert ein bestimmtes Exemplar. Wenn das Geschäft Seriennummern braucht, wird jede Einheit ein eigener Datensatz, und fünf Kühlschränke sind fünf Datensätze. Ich sehe keinen Fall für eine Lieferposition mit einem Lieferpositionsdetail darunter. Es ist das eine oder das andere: eine Zusammenfassung mit Menge oder ein Datensatz pro Einheit. Hier ist es die Menge.
Achten Sie auf Attribute, die eine Historie wollen. Manche Beziehungsentitäten stehen fest, sobald sie erstellt sind: Die Waschmaschine auf dieser Lieferung bleibt die Waschmaschine auf dieser Lieferung. Andere ändern sich ständig. Eine Crew hat diese Woche Lkw 117, und nächste Woche geht der Lkw an eine andere Crew. Wenn sich die Beziehung ändert und das Geschäft wissen will, wie sie früher war, braucht die Beziehungsentität Datumsangaben, und die Crew-Zuweisung ist die, auf die man achten muss. Fragen Sie früh, ob das Geschäft sich für jetzt oder für im Lauf der Zeit interessiert; darauf kommen wir gleich zurück.
Beziehungen bedeuten mehr als ihre Kardinalität
Abschnitt betitelt „Beziehungen bedeuten mehr als ihre Kardinalität “„Eins-zu-viele“ reicht nicht, um eine Beziehung zu verstehen. Ich möchte auch wissen, was die Beziehung bedeutet.
Eine Lieferung hat einen Ort. Welchen? Das Verteilzentrum, von dem sie abgeht? Das Zuhause des Empfängers, zu dem sie geht? Die sind nicht austauschbar. Zwei Modelle können genau dieselben Kästen und dieselbe Kardinalität haben, und die Linien können völlig verschiedene Dinge bedeuten. Deshalb ist ein gutes Modell nicht nur Kästen, die durch Linien verbunden sind. Die Linien brauchen Namen. Wenn ich mein Diagramm an andere in der Architektur weitergebe, sollte niemand raten müssen, was eine Beziehung bedeutet, und wenn ich es dem Fachbereich zeige, sollte es eine Sprache verwenden, die man dort erkennt.
Auch die Optionalität zählt
Abschnitt betitelt „Auch die Optionalität zählt “In „wie viele?“ versteckt sich eine weitere Frage: Ist die Beziehung erforderlich? Kann eine Lieferung existieren, bevor sie einer Tour zugeordnet ist? Sie muss es: Die Ladeliste kommt ein oder zwei Tage vor der Lieferung, und die Touren werden am Vorabend festgelegt. Kann eine Lieferung ohne Handelspartner existieren? Nein; jede Lieferung stammt aus der Ladeliste eines Partners. Das ist Optionalität.
Springen Sie auch hier nicht direkt zum Salesforce-Kontrollkästchen „Erforderlich“. Es ist ein Unterschied, ob man sagt „Jede Lieferung muss einen Handelspartner haben“ oder „Salesforce soll das Feld Handelspartner beim Erstellen des Datensatzes verlangen“. Vielleicht führen beide zur selben Umsetzung, aber es sind nicht dieselben Aussagen. Die erste ist eine Geschäftsregel; die zweite ist eine Art, sie durchzusetzen. In der Architektur wollen wir die erste verstehen, bevor wir die zweite entscheiden.
Im Diagramm ist die Optionalität die zweite Markierung an jedem Ende. Die Markierung am nächsten zum Kasten ist das Höchste, was es geben kann: der Strich für eins, der Krähenfuß für viele. Die nächste Markierung weiter außen ist das Mindeste: ein weiterer Strich heißt mindestens eins, ein Kreis heißt, es können null sein. Jede Lieferung steht also auf genau einer Ladeliste, und eine Ladeliste führt eine oder viele Lieferungen auf. Eine Lieferung gehört zu null oder einem Stopp, keinem, bis sie einer Tour zugeordnet ist, und an einem Stopp werden null oder viele Lieferungen abgegeben.
Zeit verändert Beziehungen
Abschnitt betitelt „Zeit verändert Beziehungen “Eine Frage stelle ich sehr oft: Meinen Sie jetzt oder im Lauf der Zeit?
Eine Crew fährt einen Lkw. Jetzt gerade? Für die heutige Tour? Solange diese beiden Personen zusammenarbeiten? Das ergibt verschiedene Modelle. Wenn das Geschäft nur interessiert, welchen Lkw eine Crew heute hat, kann das Modell einfach bleiben. Wenn es jeden Lkw braucht, den eine Crew gefahren ist, wann und auf welcher Tour, brauchen wir eine Historie, und die Crew-Zuweisung, die wir entdeckt haben, wird plötzlich sehr wichtig.
Das ist eine häufige Quelle von Modellierungsfehlern. Wir modellieren den aktuellen Zustand, weil wir den auf dem Bildschirm sehen. Dann, Wochen später, reicht ein Handelspartner eine Schadensmeldung ein, und jemand fragt: „Welche Crew hatte am 17. März Lkw 117?“ Und wir stellen fest, dass wir die Antwort bei jeder Änderung der Zuweisung überschrieben haben.
Eine Möglichkeit, diese Historie zu bewahren, ist, die Zuweisung zu einem eigenen Datensatz zu machen. Wenn eine Crew zugewiesen wird, erstellen wir eine Crew-Zuweisung mit einem Startdatum. Wenn sich die Zuweisung ändert, setzen wir beim alten Datensatz ein Enddatum und erstellen einen neuen mit eigenem Startdatum. Jetzt ist „Wer hatte diese Zuweisung vor sechs Monaten?“ eine einfach zu beantwortende Frage statt einer Suche im Feldverlauf oder in einem Protokoll der Datenänderungen. Und sobald eine Crew viele Zuweisungen hatte, wird jemand fragen, welche die aktuelle ist, also würde ich auch ein Kennzeichen Aktiv hinzufügen.
Wenn mir also jemand von einer Beziehung erzählt, frage ich nicht nur, wie die Dinge zusammenhängen. Ich frage: Ändert sich diese Beziehung, und interessiert uns ihre Historie?
Erst zeichnen, dann konfigurieren
Abschnitt betitelt „Erst zeichnen, dann konfigurieren “Unser Steve-Trucking-Modell wird nützlich. Wir wissen, welche Beziehungen eins zu viele sind, wo eine Viele-zu-viele-Beziehung ein weiteres Konzept verbirgt, welche Beziehungen optional sind und welche sich im Lauf der Zeit ändern. Und wir haben noch kein einziges Salesforce-Objekt erstellt. Das ist Absicht.
Dieses Diagramm sollte ich dem Fachbereich vorlegen können, und er sollte Salesforce nicht kennen müssen, um mir zu sagen, ob es stimmt. Wenn er es nicht prüfen kann, weil es voller Salesforce-Begriffe ist, bin ich zu schnell in den physischen Entwurf gegangen.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “Wenn ich die Beziehungen in einem konzeptionellen Modell durcharbeite, entscheide ich:
- Wie die wichtigsten Geschäftsentitäten zueinander stehen.
- Ob jede Beziehung eins zu eins, eins zu viele oder viele zu viele ist, jetzt und im Lauf der Zeit.
- Ob jede Beziehung erforderlich oder optional ist.
- Ob eine Viele-zu-viele-Beziehung ein bedeutsames Geschäftskonzept verbirgt.
- Ob sich die Beziehung im Lauf der Zeit ändert und ob wir ihre Historie brauchen.
Nachschlagen oder Master-Detail, die Konfiguration von Verbindungsobjekten, das Löschverhalten und die Freigabe sind physische Entscheidungen; dahin kommen wir noch. Jetzt beantworten wir noch die wichtigere Frage: Wie funktioniert dieses Geschäft eigentlich? Sobald wir die Entitäten und die Beziehungen zwischen ihnen verstehen, können wir die Details hinzufügen, die sie beschreiben. Dann beginnt unser konzeptionelles Modell, ein logisches Datenmodell zu werden.