Relationships between objects and events
Each event relates to one or more objects, and objects also relate to each other. For example, when a user creates a purchase order, here's some of the relationships we get:
Between the purchase order (object) and the vendor (object) named in it.
Between the purchase order (object) and the individual items in the purchase order (many objects).
Between the creation of the purchase order (event) and the purchase order (object) and the user (object).
When an event is related to an object, we have an event to object relationship. Event to object relationships are created and recorded in the event type. In this example, there are event to object relationships between the creation of the purchase order (event) and the purchase order (object), and between the creation of the purchase order (event) and the user (object).
When two objects are related, we have an object to object relationship. Object to object relationships are typically created and recorded in both of the object types involved, making a two-way relationship. Two objects may have a one-way relationship, where one object type records a relationship but the other object type involved in it doesn't.
As an example, here are the object to object relationships recorded in the Celonis PurchaseOrder object type:
Object to object relationships can be “has one” or “has many” relationships. This is called the relationship’s cardinality. For example, for the PurchaseOrder object type:
A purchase order can only have one vendor, so there’s a “has one” relationship (called “Vendor”) pointing to the Vendor object type.
There can be many purchase order items in a purchase order, so there’s a “has many” relationship (called “Items”) pointing to the PurchaseOrderItem object type.
Both of the relationships we’ve just looked at are two-way relationships, which means that the target object type also has a relationship defined back to the original object type. The cardinality of the two relationships doesn’t have to be the same.
For example, as we saw, there can be many purchase order items in a purchase order (a “has many” relationship), but a purchase order item can only be in one purchase order. So for the PurchaseOrderItem object type, there’s a “has one” relationship (called “Header”) pointing to the PurchaseOrder object type.
On the other hand, a vendor can be associated with many purchase orders, so the Vendor object type has a “has many” relationship pointing to the PurchaseOrder object type. So in both of these two-way relationships, one side is a "has one" relationship, and the other side is a "has many" relationship.
Objects, events, and relationships are all represented in the object-centric data model - The object-centric data model explains how.