--- title: "Best Practices für die Modellierung von Entitäten" url: "https://docs.noreja.com/de/article/best-practices-fuer-die-modellierung-von-entitaeten" language: "de" last_updated: "2026-10-23T08:28:12.832Z" --- # Best Practices für die Modellierung von Entitäten Wie du eine Entität so modellierst, dass Perspektiven gut funktionieren: ein Objekt pro Ereignis, mehrere Ereignisse aus einer Tabelle, Beleg- oder Positionsebene, Stern oder Baum, Schlüssel, Zeitstempel, Eigenschaften, Größe und die typischen Fehler mit dem, was Noreja anzeigt. Wie du eine Entität modellierst, entscheidet, was Prozessanalystinnen und -analysten später sehen: welche Aktivitäten es gibt, wie Geschäftsfälle zustande kommen und welche Zahlen der Analyzer zeigt. Diese Seite sammelt, was sich bewährt hat, mit Beispielen aus der Entität Purchase-to-Pay, und die typischen Fehler mit dem, was Noreja dann anzeigt. Die Grundlagen stehen in [Entitäten erklärt](https://docs.noreja.com/de/article/entitaeten-erklaert). ### 1\. Ein Objekt pro Ereignis mit eigenem Zeitstempel Ein Objekt sollte für etwas stehen, das im Prozess passiert und einen eigenen Zeitstempel hat: Eine Bestellung wird erstellt, eine Position wird hinzugefügt, Ware kommt an, eine Rechnung wird erfasst, eine Zahlung wird ausgeführt. Jede Zeile, die das Objekt liest, wird zu einer Ausführung einer Aktivität. Tabellen, die Dinge statt Ereignisse beschreiben, etwa Lieferanten, Materialien oder Verträge, sind keine Objekte. Füge ihre Spalten den Objekten, die sie brauchen, als Eigenschaften über die **JOIN-Klausel** hinzu. In Purchase-to-Pay verbindet „bestellposition angelegt (HW)“ die Tabellen der Materialien, Bestellungen und Lieferanten, sodass jede Position ihr Material und ihren Lieferanten mitbringt; die Tabellen dbo.lieferant und dbo.material sind selbst keine Objekte. Siehe [Eigenschaften aus verbundenen Tabellen nutzen](https://docs.noreja.com/de/article/eigenschaften-aus-verbundenen-tabellen-nutzen). ### 2\. Mehrere Ereignisse in einer Tabelle: je ein Objekt Viele Tabellen halten mehr als ein Ereignis fest, zum Beispiel eine Rechnung, die erfasst und später freigegeben wird. Verwende die Tabelle einmal pro Ereignis, jeweils mit der Datumsspalte dieses Ereignisses als **Startzeitstempel**, und lass Zeilen, in denen das Ereignis nicht stattgefunden hat, mit einer **WHERE-Klausel** weg: | Objekt | Tabelle | Startzeitstempel | WHERE-Klausel | | --- | --- | --- | --- | | rechnung erfassung | dbo.rechnung | rechnung\\\_erfasst\\\_am | – | | rechnung freigegeben\\\_am | dbo.rechnung | rechnung\\\_freigegeben\\\_am | rechnung\\\_freigegeben\\\_am is not null | | bestellposition angelegt (HW) | dbo.bestellposition | position\\\_angelegt\\\_am | produktgruppe != 'SOFTWARE' | | zahlung innerhalb skontofrist | dbo.zahlung | zahlung\\\_ausgefuehrt\\\_am | skonto\\\_genutzt = 'ja' | Mit der WHERE-Klausel teilst du auch eine Art von Ereignis nach einer Eigenschaft auf, wie bei Hardware- und Softwarepositionen oder bei Zahlungen innerhalb und außerhalb der Skontofrist. Die Aufteilung erscheint dann im Prozess als verschiedene Aktivitäten. ### 3\. Die Ebene wählen: Beleg oder Position Entscheide für jedes Objekt, ob es auf der Ebene von Belegen (einer Bestellung) oder ihrer Positionen (einer Bestellposition) arbeitet. Nimm die Positionsebene, wo Schritte pro Position stattfinden, etwa Wareneingänge für einzelne Positionen, und die Belegebene, wo sie einmal pro Beleg stattfinden. Beide Ebenen lassen sich kombinieren; verbinde die Positionen mit ihrem Beleg. Die Ebene zeigt sich in den Zahlen: In Purchase-to-Pay haben 5.520 Bestellungen 5.976 Ausführungen von „bestellposition angelegt (HW)“, und die Beziehung von der Bestellung zu ihren Positionen hat die Kardinalität 1 : 0 .. 3. Siehe [Anzahlen und Kardinalitäten](https://docs.noreja.com/de/article/deep-dive-kardinalitaten). ### 4\. Die Objekte als Stern oder Baum anordnen ![Drei Formen einer Entität: ein Stern mit Freigabe, Rechnung und Position um Bestellung; ein Baum mit Bestellung, darunter Position und Rechnung, darunter Wareneingang und Zahlung; eine Kette Bestellung, Wareneingang, Rechnung, Zahlung](https://cdn-assets.productfruits.com/991a0949-b153-4f6c-b063-1916aa2aa067) - **Stern**: Alle Objekte sind mit einem zentralen Objekt verbunden, meist dem Beleg, um den es im Prozess geht. Einfach und robust. - **Baum**: Jedes Objekt ist mit dem Objekt verbunden, zu dem es gehört, und dieses kann wiederum zu einem anderen gehören. Purchase-to-Pay ist ein Baum: 24 Objekte und 23 Datenbeziehungen, mit der Bestellung in der Mitte, den Positionen und ihren Wareneingängen auf einem Ast und der Rechnung mit ihren Zahlungen auf einem anderen. - **Kette**: Jedes Objekt ist nur mit dem nächsten verbunden. Vermeide sie, wenn sich die Objekte nicht wirklich aufeinander beziehen: Ein Geschäftsfall sammelt die Ausführungen, die er entlang der Datenbeziehungen erreicht. Fehlt bei einem Fall ein Ereignis in der Mitte, ist auch alles dahinter nicht erreichbar. Verbinde jedes Objekt mit dem Objekt, auf das es sich in den Daten tatsächlich bezieht, zum Beispiel eine Zahlung über die Rechnungsnummer mit ihrer Rechnung, und nicht mit dem, was im Prozess davor kommt. Die Reihenfolge des Prozesses legst du später in der Perspektive fest; siehe [Eine Perspektive erstellen](https://docs.noreja.com/de/article/erstellen-einer-dimension-kausale-hypothese). Geschlossene Schleifen aus Datenbeziehungen sind möglich, machen den Weg zwischen Objekten aber mehrdeutig; halte die Entität frei davon. ### 5\. Jede Zeile identifizieren - Behalte unter **Eindeutiger Schlüssel** den Primärschlüssel der Tabelle, wo es einen gibt. Hat eine Tabelle keinen Schlüssel, wähle Spalten, die zusammen jede Zeile identifizieren, zum Beispiel die Belegnummer und die Positionsnummer. - Identifizieren die Spalten nicht jede Zeile, bekommen verschiedene Ereignisse denselben Schlüssel und lassen sich nicht mehr unterscheiden. - Die Geschäftsfall-ID wird später in der Perspektive gewählt, aus dem eindeutigen Schlüssel eines Objekts. Achte darauf, dass das Objekt, das für den Geschäftsfall steht, etwa die Bestellung, einen klaren Schlüssel hat. ### 6\. Echte Datums- und Zeitspalten verwenden - Wähle eine Datums- und Zeitspalte als **Startzeitstempel**. Als Text gespeicherte Datumswerte müssen erst umgewandelt werden; siehe [Zeitstempel: Formate, Vorschau und Verteilung](https://docs.noreja.com/de/article/deep-dive-timestamp-formatierung). - Bevorzuge Spalten mit Uhrzeit. Ereignisse mit demselben Datum, aber ohne Uhrzeit beginnen alle um Mitternacht, sodass ihre Reihenfolge innerhalb eines Tages verloren geht. - Füge einen **Änderungszeitstempel** nur hinzu, wo spätere Änderungen wichtig sind, zum Beispiel für Nachbearbeitung. Noreja verwendet ihn nur, wenn er nach dem Startzeitstempel liegt. ### 7\. Die Eigenschaften mitnehmen, die du brauchst Nach Eigenschaften filtern und vergleichen Analystinnen und Analysten später: Beträge, Produktgruppen, Lieferanten, Status. Wähle die Spalten, die fachliche Fragen beantworten, und lass technische weg; jede Spalte vergrößert die Datenmenge, die importiert werden muss. Auf Variante und Prozessmodell werden Zahlen summiert und gemittelt, und Texte werden zu Wertelisten; siehe [Von Ereignissen zum Prozessmodell: Was wo zusammengefasst wird](https://docs.noreja.com/de/article/von-ereignissen-zum-prozessmodell-was-wo-zusammengefasst-wird). ### 8\. So klein, wie die Perspektiven es brauchen Jedes Objekt und jede Datenbeziehung ist ein Schritt des Imports, ob eine Perspektive es verwendet oder nicht. Fang mit den Objekten des Hauptprozesses an und ergänze weitere, wenn eine Perspektive sie braucht. Eine Entität kann mehreren Perspektiven dienen, die jeweils nur einen Teil ihrer Aktivitäten verwenden; du brauchst also nicht für jede Fragestellung eine eigene Entität. Mehrere kleinere Entitäten auf derselben Datenquelle sind ebenfalls möglich. Siehe [Performance-Tipps für große Importe](https://docs.noreja.com/de/article/performance-tipps-fuer-grosse-importe). ### Typische Fehler und was du siehst | Fehler | Was Noreja anzeigt | Lösung | | --- | --- | --- | | Ein Objekt oder eine Gruppe von Objekten ist nicht mit dem Rest verbunden | Der Import bricht mit *Each entity graph needs to be a connected graph.* ab. | Füge eine Datenbeziehung zum Rest der Entität hinzu. | | Ein Objekt oder eine Datenbeziehung wurde als Entwurf gespeichert oder der Test ist fehlgeschlagen | Der Import bricht mit *Activity … is not configured* oder *Relationship … is not configured* ab; das Objekt ist auf der Arbeitsfläche hervorgehoben. | Öffne es, korrigiere die Abfrage und klicke auf **Bestätigen**. | | Nur ein Objekt | Der Import bricht ab. | Eine Entität braucht mindestens zwei verbundene Objekte. | | Zwei Objekte mit demselben Namen | Das Objekt lässt sich nicht speichern: Es gibt bereits eine Aktivität mit diesem Titel. | Vergib für jedes Objekt einen eigenen Namen bei **Aktivitätsname**. | | Der eindeutige Schlüssel identifiziert nicht jede Zeile | Die Zahl der Ausführungen stimmt nicht mit der Zahl der Zeilen in der Tabelle überein. | Füge unter **Eindeutiger Schlüssel** Spalten hinzu. | | Eine Stammdatentabelle als Objekt | Eine Aktivität, deren Zeitstempel nichts markiert, was im Prozess passiert, etwa das Datum, an dem ein Lieferant angelegt wurde. | Entferne das Objekt und binde seine Spalten als Eigenschaften per JOIN an. | ### Verwandte Artikel - [Entitäten erklärt](https://docs.noreja.com/de/article/entitaeten-erklaert) - [Objekte und Beziehungen konfigurieren](https://docs.noreja.com/de/article/new-article-39) - [Eigenschaften aus verbundenen Tabellen nutzen](https://docs.noreja.com/de/article/eigenschaften-aus-verbundenen-tabellen-nutzen) - [Best Practices für die Modellierung von Perspektiven](https://docs.noreja.com/de/article/best-practices-fuer-die-modellierung-von-perspektiven)