The second table group of a connector is the group of entity tables. This group contains tables that define the entities in the connector.
An entity is an object of interest for which you want to see how it behaves through the process.
Below are some examples to explain entities.
In an invoicing process, invoices are entered into the system. Then they are checked. More data may be requested and, finally, invoices are paid.
- In this example, the invoice is the object of interest for which we can identify interesting steps in the process. Therefore, the invoice is an entity.
Before the invoicing process starts, a purchase is made. For this part of the process, a purchase request is entered into the system and the purchase is approved.
- The purchasing document is also an entity in the process.
- The purchasing document relates to the invoice. But it is a separate entity on which steps in the process happen independently of the invoice.
Invoices can be of several types, such as employee declarations or customer invoices. The
invoice typeis a property of the invoice entity, but the
invoice typeis not an entity by itself.
From a technical point of view, each entity needs to be stored in a separate table, where each record in a table describes exactly one instance of that entity. To recognize each of the instances individually, there should be a unique identifier available. This
Entity ID is later used to define for which entity an event happens.
In the first step of the connector, the input tables are created. These input tables are the base of the entity tables.
Depending on the source system, either one input table or multiple input tables combined define the entity.
Make sure that in the entity tables the
Entity ID is always unique. Joining input tables incorrectly may result in duplication. This will give incorrect results in later steps of the transformation, such as duplicate cases and events.
Rename the entities to human-readable names, if needed.
An entity has several properties that describe it and are specific to that entity. An invoice has other properties than, for example, a purchase order. The resulting entity table should contain all the properties that are of interest for analysis. For example, for an invoice these are the
Invoice ID (Entity ID), the
User ID of the user who entered the invoice in the system, and the
Creation date of the invoice.
See the illustration below for an example entity table for an invoice.
Additional information about entity properties can be stored in different tables. For example, information related to the user is stored in a separate user table. If you want to have the name of the user instead of the User ID, you should take this information from the user table.
A user table is an example of Master data.
See the illustration below for an example of a master table that stores additional data on users.
The user information can be made available on the entity table by joining the user table with a left join to the entity table. A left join makes sure that the entity table is enriched with the master data when available, but does not remove records from the entity table itself. Make sure that after this join, the entity ID remains unique on the entity table and no data duplication is caused.
Create separate tables for master data based on the input tables. This helps to easier understand and maintain the connector. It allows you to abstract from the original table name in the source system to a more generic name, while keeping the original name for traceability as well.
The number of entities that are of interest in a process can vary depending on the complexity of the process.
In a relatively simple process, only one entity may be involved. For example, in an invoicing process in which you are only interested in events that take place related to the invoice.
In more complex processes, multiple entities can be of interest. An example is a Purchase-to-Pay process in which the process from requesting a product up to the invoice being paid covers steps related to multiple entities. In a process with multiple entities, always make sure that the relation between these entities is present in the entity tables. For example, if an invoice is created for a certain purchasing document, the purchasing document identifier should be a property on the invoice entity table.
Updated 5 months ago