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).
Between the creation of the purchase order (event) and the user who creates it (object).
When an event is related to an object, we have an event to object relationship. 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). An event can involve one instance or many instances of the related object. The event type controls the record of an event to object relationship - the object doesn’t have its own record of the relationship.
When two objects are related, we have an object to object relationship. The cardinality of an object to object relationship shows the number of each event or object that can be involved. For example, one sales order can contain many sales order items, but each sales order item can only be in one sales order. For the object-centric data model, you can define a relationship as one to many (1:m), many to one (m:1), or many to many (m:n). You can’t specify a one to one (1:1) relationship, as the object-centric data model and the underlying database don't enforce uniqueness of a foreign key.
Two objects can have a bidirectional relationship, where each object type has a record of its relationship to the other object. Or they can have a unidirectional relationship, where one object type has a record of the relationship but the other object type involved in it doesn’t. Usually, a bidirectional relationship is appropriate, so when you create an object to object relationship, we'll automatically create the incoming relationship from the other object as well. If you want the relationship to be unidirectional, you can delete the incoming relationship.
For a bidirectional object to object relationship, both sides of the relationship are typically tracking exactly the same data. For example, each quotation item tracks the sales order items that are associated with it, and each sales order item tracks which quotation item it is associated with. To avoid duplicating the data, you implement the data transformation for the relationship on only one of the objects, meaning that the relationship data is kept with the data for that object, and referenced by the other object.
If one side of the object to object relationship has many objects (1:m or m:1), you implement the relationship transformation on the object on the many side. For these relationships, the relationship data is stored in a column in the database table that holds the data for the object on the many side. In the transformation for that object type, you fill the data for this column as part of the attribute script.
If both sides of the object to object relationship have many objects (m:n), you can implement the relationship transformation on either of the objects. For these relationships, the relationship data is stored in a separate join table. The relationship table has its own transformation script (a relationship script), which is kept and run as part of the transformation for the object type you implemented it on. You choose which object holds the relationship table and its transformation when you model the relationship - the source object (the one you're working with) or the target object (the one you're creating the relationship with). If one of the objects is a custom object type and the other is a Celonis catalog object type, choosing the custom object type means you'll have all your custom transformation scripts together in one place.
Objects, events, and relationships are all represented in the object-centric data model - The object-centric data model explains how.