Das logische Modell aufbauen
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 3 von 6 im Kapitel Daten nach ihrer Bedeutung modellieren, Kapitel 2 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Die Beziehungen zeichnen · Weiter: Daten dorthin, wo sie hingehören
Die Frage, die dieses Modul beantwortet: Wie verwandle ich ein konzeptionelles Modell in ein logisches Datenmodell?
Das konzeptionelle Modell hat uns gesagt, was es bei Steve Trucking gibt und wie es zusammenhängt: Handelspartner und ihre Verteilzentren, Ladelisten und Lieferungen, Empfänger, Touren und Stopps, Crews, Lkw und Crew-Zuweisungen. Das reicht für ein sehr produktives Gespräch mit dem Fachbereich. Aber irgendwann brauche ich mehr Details. Was müssen wir über eine Lieferung wissen? Was unterscheidet ein Verteilzentrum von einem anderen? Wie identifizieren wir einen Empfänger? Was gehört zu einer Crew-Zuweisung statt zur Crew oder zum Lkw? Diese Fragen führen uns vom konzeptionellen Modell zu einem logischen Datenmodell, und wir bauen immer noch kein Salesforce.
Sitz, Bleib, Modell
Abschnitt betitelt „Sitz, Bleib, Modell “Zuerst zurück zu den Hunden. Wir haben die Kästen und die Linien. Jetzt zwei neue Fragen: Was wissen wir über jedes Ding, und wie unterscheiden wir eines vom anderen?
Was beschreibt es? Ein Hund hat einen Namen und ein Geburtsdatum. Halter:innen haben einen Namen, eine Telefonnummer und eine Adresse. Ein Trick hat einen Namen und einen Schwierigkeitsgrad. Jede Tatsache kommt auf den Kasten, den sie beschreibt.
Dann die Verbindung. Wie gut Bella Sitz macht und wann sie es gelernt hat: Beschreibt das Bella? Nicht ganz; manche Tricks kann sie besser als andere. Beschreibt es Sitz? Nein; jeder Hund macht Sitz anders. Es beschreibt Bella und Sitz zusammen, also gehört es auf den Hundetrick: das Niveau und das Lerndatum. Deshalb gibt es die Verbindung: Manche Tatsachen gehören nur zum Paar.
Welcher Hund ist welcher? Versuchen Sie es zuerst mit dem Namen. Es gibt viele Hunde namens Max, also ist der Name nicht eindeutig. Die Telefonnummer der Halterin oder des Halters? Marcus hat zwei Hunde unter derselben Nummer, Menschen wechseln ihre Nummern, und es sind personenbezogene Daten, die in jedes System kopiert würden, das je auf einen Hund verweist. Die Mikrochipnummer sieht besser aus: Sie ist eindeutig und ändert sich nicht. Aber ein neuer Welpe ist vielleicht noch nicht gechippt, und ein Schlüssel darf nicht leer sein. Also bleibt der Mikrochip als etwas, unter dem der Hund auch bekannt ist, und der Hund bekommt seine eigene Hunde-ID: eine Nummer, die eine langweilige Aufgabe erfüllt, nämlich einen Hund vom anderen zu unterscheiden.
Das sind dieselben Fragen, die wir jetzt Steve Trucking stellen, und die Gründe, warum Name, Telefonnummer und Mikrochip jeweils nicht genügen, werden zu einer Regel, an der ich seit Jahren festhalte.
Konzeptionell sagt mir, was existiert; logisch sagt mir, was es als Daten bedeutet
Abschnitt betitelt „Konzeptionell sagt mir, was existiert; logisch sagt mir, was es als Daten bedeutet “Nehmen Sie den Lkw. Was muss ich über einen Lkw wissen? Vielleicht seine Fahrzeugnummer, die FIN, Marke, Modell, Baujahr, Kennzeichen, aktuellen Kilometerstand und Status. Das sind Attribute des Lkw.
Nehmen Sie jetzt die Lieferung. Vielleicht die Auftragsnummer des Handelspartners, das Lieferdatum, das zugesagte Zeitfenster, die tatsächliche Ankunftszeit, den Status und ob sie eine Installation oder eine Mitnahme umfasst. Wieder Attribute.
Das konzeptionelle Modell hat uns gesagt, dass es die Lieferung gibt. Das logische Modell beginnt uns zu sagen, was eine Lieferung als Daten bedeutet. Ein einfacher Kasten wie Lkw oder Lieferung kann für eine ganze Reihe von Feldern stehen.
Trotzdem bleiben die Kästen in den meisten unserer Diagramme einfach, aus drei Gründen. Die Zahl der Felder wächst. Felder veralten schnell. Und jedes Feld hat Details, die sich in einem Objektmodell schwer zeigen lassen: API-Name, Beschriftung, Datentyp und Länge. Diese Details werden auf jeden Fall erfasst, nur nicht im ersten Datenmodell. Wenn ein paar wichtige Felder wirklich helfen, die Geschichte zu erzählen, zeichne ich ein detailliertes Datenmodell: einen gezielten Ausschnitt mit nur den Feldern, auf die es ankommt.
Attribute sollen die Entität beschreiben
Abschnitt betitelt „Attribute sollen die Entität beschreiben “Hier ist eine einfache Frage, die ich mir bei einem Attribut stelle: Was beschreibt das? Die Marke des Lkw beschreibt eindeutig den Lkw. Aber was ist mit den Namen der Crewmitglieder auf einer Lieferung? Beschreiben sie die Lieferung? Oder beschreiben sie eine Crew, die eine Crew-Zuweisung hatte, die die Tour abdeckte, zu der dieser Stopp gehörte?
Hier beginnt ein Datenmodell, Dinge offenzulegen, die auf einem Bildschirm völlig vernünftig aussehen. Jemand aus der Disposition sagt: „Ich möchte die Namen der Crew auf der Lieferung sehen.“ Das ist eine berechtigte Anforderung an die Benutzererfahrung. Es ist nicht unbedingt eine Anforderung, die Namen der Crew auf der Lieferung zu speichern. Das sind zwei verschiedene Dinge, und wir kommen bei der Normalisierung darauf zurück. Gewöhnen Sie sich vorerst an die Frage, welches Ding diese Tatsache eigentlich beschreibt. Diese Frage erspart Ihnen viel Ärger.
Dann müssen wir über eindeutige IDs sprechen
Abschnitt betitelt „Dann müssen wir über eindeutige IDs sprechen “Attribute beschreiben Dinge. Aber es gibt noch ein Problem zu lösen: Woher weiß ich, welches Ding welches ist?
Zwei Empfänger heißen John Smith. Sind sie dieselbe Person? Vielleicht; vielleicht nicht. Ein Name reicht nicht. Eine Adresse? Menschen ziehen um. Telefonnummern ändern sich. E-Mail-Adressen ändern sich. Selbst der Name eines Handelspartners kann sich ändern.
Das führt uns zu Schlüsseln: dem, was uns erlaubt, etwas in unserem Modell eindeutig zu identifizieren. Zu diesem Thema habe ich mir über die Jahre eine ziemlich klare Meinung gebildet. Von einer Kennung verlange ich vier Dinge:
Eindeutig. Unveränderlich. Bedeutungslos. Niemals personenbezogen.
Eindeutig. Eine Kennung muss genau ein Ding identifizieren. Wenn zwei Lieferungen denselben Wert haben können, ist es keine verlässliche Lieferkennung. Namen sind meist nicht eindeutig, Adressen nicht unbedingt, und Telefonnummern werden geteilt. Selbst Werte, die heute eindeutig aussehen, sind es vielleicht nicht mehr, wenn Sie genug Daten haben. Fragen Sie also: Können zwei davon jemals denselben Wert haben? Wenn ja, seien Sie sehr vorsichtig, ihn als eindeutige ID des Datensatzes zu verwenden.
Unveränderlich. Dieser Punkt wird oft übersehen. Wenn wir einen Handelspartner über seinen Namen identifizieren und der Partner sich umbenennt, haben wir dann einen neuen Partner? Nein. Die Geschäftseinheit ist dieselbe geblieben; eines ihrer Attribute hat sich geändert. Die eindeutige ID eines Datensatzes sollte Änderungen an dem Ding, das sie identifiziert, überstehen, und das schließt Namen, E-Mail-Adressen, Telefonnummern, Adressen und Benutzernamen aus, so bequem sie auch aussehen, wenn wir ein System zum ersten Mal bauen.
Bedeutungslos. Das klingt beim ersten Hören seltsam. Warum sollte eine Kennung bedeutungslos sein? Weil sich Bedeutung ändert. Stellen Sie sich vor, jemand baut eine Lieferkennung, die das Verteilzentrum, den Handelspartner, das Lieferdatum und eine laufende Nummer enthält: PHX-KEY-20261002-0042. Sieht clever aus. Dann verschiebt der Empfänger auf Freitag. Ändern wir die Kennung? Wenn nicht, lügt sie uns an. Wenn doch, haben wir die eindeutige ID der Lieferung geändert, weil sich eines ihrer Attribute geändert hat, und jedes System, das die alte ID gespeichert hat, hat sie gerade aus den Augen verloren. Die Kennung wollte zwei Aufgaben erfüllen: die Lieferung identifizieren und sie beschreiben. Ich lasse lieber die Attribute beschreiben und die Kennung eine langweilige Aufgabe erledigen: identifizieren. Langweilige Kennungen sind gute Kennungen.
Niemals personenbezogen. Dieser Punkt ist wichtig genug, dass ich ihn getrennt halte. Verwenden Sie keine personenbezogenen Daten als Kennung, nur weil sie eindeutig aussehen. Bei Steve Trucking ist es verlockend, einen Empfänger an seiner Telefonnummer zu erkennen. Aber ein Schlüssel wird überallhin kopiert, wo Systeme Datensätze verbinden müssen: Integrationen, Exporte, Protokolle, Statusdateien an die Handelspartner, das Data Warehouse, Testdaten. Machen Sie eine Telefonnummer zum Schlüssel, und Sie haben die personenbezogenen Daten eines Empfängers in der ganzen Architektur verteilt.
Ein Schlüssel muss außerdem für jeden Datensatz vorhanden sein: niemals null oder leer. Wenn manche Menschen Ihnen einen Wert nicht geben wollen oder nicht geben müssen sollten, kann dieser Wert nicht der Schlüssel sein. Deshalb vergeben Systeme ihre eigenen internen Kennungen, und personenbezogene Daten werden, wenn Sie sie überhaupt brauchen, zu einem geschützten Attribut.
Meine Regel lautet also: eindeutig, unveränderlich, bedeutungslos, niemals personenbezogen.
Natürliche Schlüssel und Surrogatschlüssel
Abschnitt betitelt „Natürliche Schlüssel und Surrogatschlüssel “Datenbankleute haben für manches davon Namen. Ein natürlicher Schlüssel existiert bereits in den Geschäftsdaten: Die FIN eines Lkw ist ein gutes Beispiel. Unsere Anwendung hat sie nicht erfunden, und sie hat schon eine Bedeutung. Ein Surrogatschlüssel wird eigens geschaffen, um den Datensatz zu identifizieren; er beschreibt nichts, er identifiziert nur.
In den meisten Architekturen bevorzuge ich einen Surrogatschlüssel als interne Datensatz-ID und behalte die wichtigen natürlichen Kennungen als Attribute. Das macht natürliche Kennungen nicht schlecht; oft sind sie extrem wichtig. Ich mache sie nur nicht automatisch zur eindeutigen ID des Datensatzes. Fragen Sie, was passiert, wenn der Wert korrigiert, umformatiert, ersetzt, wiederverwendet wird, fehlt oder aus mehr als einem Quellsystem kommt. Dort wird eine einfach aussehende Entscheidung zur Architekturentscheidung.
Ein Ding kann mehrere nützliche Kennungen haben
Abschnitt betitelt „Ein Ding kann mehrere nützliche Kennungen haben “Die interne Datensatz-ID ist nicht unbedingt die Kennung, die jedes andere System verwendet. Steve Trucking identifiziert eine Lieferung intern vielleicht mit einer generierten ID. Jeder Handelspartner kennt dieselbe Lieferung unter seiner eigenen Auftragsnummer: Keystone in seiner CSV-Ladeliste, Redrock in seiner API, Brightwave in seinen EDI-Nachrichten. Und die acht Jahre Historie in RouteDesk, dem alten Dispositionswerkzeug, verwenden die eigenen Liefer-IDs von RouteDesk.
Diese Kennungen zählen. Wir müssen sie behalten und richtig zuordnen, denn eine Statusmeldung muss an jeden Partner unter seiner Nummer zurückgehen. Aber sie müssen nicht alle zur eindeutigen ID der Lieferung werden. „Was ist ihre ID?“ kann mehr als eine Antwort haben, und in der Architektur müssen wir wissen, welche ID in welchem Kontext maßgeblich ist. Wir kommen bei Stammdaten und Integration darauf zurück.
Beziehungen hängen von eindeutigen IDs ab
Abschnitt betitelt „Beziehungen hängen von eindeutigen IDs ab “Gehen Sie zurück zu den Linien, die wir gezeichnet haben. Eine Ladeliste führt Lieferungen auf. Ein Empfänger erhält Lieferungen. Eine Crew hat Crew-Zuweisungen. Diese Beziehungen funktionieren nur, weil wir die Dinge an beiden Enden verlässlich identifizieren können.
Hier wird es bei Steve Trucking ernst. Ein Handelspartner ändert seine Ladeliste noch am selben Tag: ein Auftrag storniert, ein Artikel getauscht, eine neue Adresse. Wenn wir die geänderte Zeile nicht über die Auftragsnummer des Partners der Lieferung zuordnen können, die wir schon haben, legen wir eine zweite Lieferung für denselben Kühlschrank an, und vielleicht steht eine Crew zweimal vor der Tür. Kästen, Attribute, Schlüssel und Beziehungen sind keine getrennten Ideen. Sie sind alle Teile desselben Modells.
Vielleicht denken Sie jetzt: „Salesforce gibt jedem Datensatz eine ID.“ Richtig, und dahin kommen wir. Wenn die Daten in Salesforce liegen, bekommt jeder Datensatz eine von Salesforce erzeugte ID. Sie ist kryptisch und schwer zu lesen, also stellen wir meist zusätzlich ein ID-Feld bereit, das Menschen verwenden können, etwa eine Liefernummer D-000184227, ein Feld vom Typ Automatische Nummer. Oft wird diese Nummer für die ID des Datensatzes gehalten, aber das ist sie nicht: Die Salesforce-ID ist darunter immer noch da. Ein externes System oder eine Datenbank, Oracle oder SQL Server, hat ebenfalls eigene eindeutige IDs. Aber die Architektur umfasst am Ende vielleicht Salesforce, das Finanz-ERP, Snowflake, Data 360, die Systeme der Partner und Systeme, die es noch gar nicht gibt. Das logische Modell beschreibt die Geschäftsdaten, ohne jede Entscheidung von einer Technologie abhängig zu machen. Wie Salesforce es physisch umsetzt, ist ein späterer Schritt.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “Wenn ich ein konzeptionelles Modell in ein logisches verwandle, entscheide ich:
- Welche Attribute jede Entität tatsächlich beschreiben.
- Wie jede Entität eindeutig identifiziert wird und ob diese Kennung stabil genug ist, um ihre eindeutige ID zu sein.
- Welche geschäftlichen Kennungen (Auftragsnummern der Partner, Alt-IDs) behalten und zugeordnet werden müssen.
- Ob sensible Informationen als Schlüssel verwendet werden.
- Ob Beziehungen Entitäten über verlässliche eindeutige IDs verbinden.
Wir haben jetzt Entitäten, Beziehungen, Attribute und eindeutige IDs: die Anfänge eines echten logischen Datenmodells. Aber es gibt noch ein Problem. Es ist sehr leicht, vollkommen gültige Daten an die falsche Stelle zu legen. Hier kommt die Normalisierung ins Spiel.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Custom Field Types (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-09): Automatische Nummer vergibt jedem Datensatz eine eindeutige Nummer mit einem Anzeigeformat, etwa einem Präfix und führenden Nullen; sie ist nicht die Salesforce-ID des Datensatzes. Siehe auch Auto-Number Fields Are Not Always Sequential (opens in a new tab) (auf Englisch, geprüft am 2026-10-09).