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. 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.
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.
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 relationship has many objects, you implement the relationship transformation on that object. If both sides have many objects, you can implement the relationship transformation on either object. You can choose which when you model the relationship.
The relationship data is usually stored in a column in the database table that holds the data for the objects or the events, except in the case of a many to many relationship, when there’s a dedicated relationship table.
Objects, events, and relationships are all represented in the object-centric data model - The object-centric data model explains how.