---
title: "Entity Modelling Best Practices"
url: "https://docs.noreja.com/en/article/entity-modelling-best-practices"
language: "en"
last_updated: "2026-10-23T08:28:06.776Z"
---

# Entity Modelling Best Practices

How to model an entity so that perspectives work well: one object per event, several events from one table, document or item level, star or tree, keys, time stamps, properties, size, and the typical mistakes with what Noreja shows.

How you model an entity decides what process analysts can later see: which activities exist, how cases come together and which figures the Analyzer shows. This page collects what works, with examples from the Purchase-to-Pay entity, and the typical mistakes with what Noreja shows when they happen. The basics are in [Entities Explained](https://docs.noreja.com/en/article/entities-explained).

### 1\. One Object per Event with Its Own Time Stamp

An object should stand for something that happens in the process and has a time stamp of its own: an order is created, an item is added, goods arrive, an invoice is entered, a payment is made. Every row the object reads becomes one execution of an activity.

Tables that describe things rather than events, such as suppliers, materials or contracts, are not objects. Add their columns to the objects that need them, as properties with the **JOIN clause**. In Purchase-to-Pay, "bestellposition angelegt (HW)" joins the tables of materials, orders and suppliers, so each item carries its material and supplier; the tables dbo.lieferant and dbo.material are not objects themselves. See [Use Joined Properties](https://docs.noreja.com/en/article/use-joined-properties).

### 2\. Several Events in One Table: One Object Each

Many tables record more than one event, for example an invoice that is entered and later released. Use the table once per event, each time with the date column of that event as **Start timestamp**, and leave out rows where the event hasn't happened with a **WHERE clause**:

| Object | Table | Start timestamp | WHERE clause |
| --- | --- | --- | --- |
| 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' |

The WHERE clause is also the way to split one kind of event by a property, as for hardware and software items or payments within and outside the discount period. The split then shows as different activities in the process.

### 3\. Choose the Level: Document or Item

Decide for each object whether it works on the level of documents (an order) or of their items (an order item). Use the item level where steps happen per item, such as goods receipts for single items, and the document level where they happen once per document.

Both levels can be combined; connect the items to their document. The level shows in the figures: in Purchase-to-Pay, 5,520 orders have 5,976 executions of "bestellposition angelegt (HW)", and the relationship from the order to its items has the cardinality 1 : 0 .. 3. See [Quantities and Cardinalities](https://docs.noreja.com/en/article/deep-dive-cardinalities).

### 4\. Arrange the Objects as a Star or a Tree

![Three shapes of an entity: a star with Approval, Invoice and Item around Order; a tree with Order, below it Item and Invoice, below those Goods receipt and Payment; a chain Order, Goods receipt, Invoice, Payment](https://cdn-assets.productfruits.com/465a4478-84a3-4e21-8841-77954f2dbbf3)

-   **Star**: all objects are connected to one central object, usually the document the process is about. Simple and robust.
-   **Tree**: each object is connected to the object it belongs to, which can itself belong to another. Purchase-to-Pay is a tree: 24 objects and 23 data connections, with the order in the middle, the items and their goods receipts on one branch and the invoice with its payments on another.
-   **Chain**: each object is connected only to the next one. Avoid it if the objects don't really refer to each other: a case collects the executions it can reach along the data connections, so if an event in the middle is missing for a case, everything behind it can't be reached either.

Connect each object to the object it actually refers to in the data, for example a payment to its invoice through the invoice number, not to whatever comes before it in the process. The order of the process is set later, in the perspective; see [Create a Perspective](https://docs.noreja.com/en/article/crafting-a-dimension-causal-hypothesis). Closed loops of data connections are possible but make the route between objects ambiguous; keep the entity free of them.

### 5\. Identify Every Row

-   Keep the table's primary key as **Unique identifier** where it exists. If a table has no key, select columns that together identify each row, for example the document number and the item number.
-   If the columns don't identify every row, different events get the same identifier and can't be told apart.
-   The case ID is chosen later in the perspective, from the unique identifier of one object. Make sure the object that stands for the case, such as the order, has a clear identifier.

### 6\. Use Real Date and Time Columns

-   Choose a date and time column as **Start timestamp**. Dates stored as text have to be converted first; see [Timestamps: Formats, Preview and Distribution](https://docs.noreja.com/en/article/deep-dive-timestamp-formatting).
-   Prefer columns with the time of day. Events with the same date but no time all start at midnight, so their order within a day is lost.
-   Add a **Change timestamp** only where later changes matter, for example for rework. Noreja uses it only when it lies after the start time stamp.

### 7\. Bring Along the Properties You'll Need

Properties are what analysts filter and compare by later: amounts, product groups, suppliers, statuses. Select the columns that answer business questions and leave out technical ones; every column adds to the data that has to be imported. On the variant and process model, numbers are summed and averaged and texts become lists of values; see [From Events to Process Model: What Is Aggregated Where](https://docs.noreja.com/en/article/from-events-to-process-model-what-is-aggregated-where).

### 8\. Keep It as Small as the Perspectives Need

Every object and every data connection is a step of the import, whether a perspective uses it or not. Start with the objects of the main process and add others when a perspective needs them. One entity can serve several perspectives, each using only some of its activities, so you don't need a separate entity for each question. Several smaller entities on the same data source are possible, too. See [Performance Tips for Large Imports](https://docs.noreja.com/en/article/performance-tips-for-large-imports).

### Typical Mistakes and What You See

| Mistake | What Noreja shows | Fix |
| --- | --- | --- |
| An object or a group of objects isn't connected to the rest | The import stops with *Each entity graph needs to be a connected graph.* | Add a data connection to the rest of the entity. |
| An object or data connection was saved as draft or its test failed | The import stops with *Activity … is not configured* or *Relationship … is not configured*; the object is highlighted on the canvas. | Open it, fix the query and click **Confirm**. |
| Only one object | The import stops. | An entity needs at least two connected objects. |
| Two objects with the same name | The object can't be saved: an activity with this title already exists. | Give each object its own **Activity name**. |
| The unique identifier doesn't identify every row | The number of executions doesn't match the number of rows in the table. | Add columns to the **Unique identifier**. |
| A master-data table as object | An activity whose time stamp doesn't mark anything happening in the process, such as the date a supplier was created. | Remove the object and join its columns as properties. |

### Related

-   [Entities Explained](https://docs.noreja.com/en/article/entities-explained)
-   [Configure Objects and Relationships](https://docs.noreja.com/en/article/configuring-an-entity)
-   [Use Joined Properties](https://docs.noreja.com/en/article/use-joined-properties)
-   [Perspective Modelling Best Practices](https://docs.noreja.com/en/article/perspective-modelling-best-practices)