Relationship Owner and Related Object
When you create a relationship between two tables in a relational database, you just create a third relationship table that sits in the middle. In a relational database there is no difference between the table that is on the left side of the relationship and the table that is on the right side of the relationship. However, in Veeva Network this is little different because whenever you create a custom relationship object between two main objects, you need to specify which of the objects owns the relationship and which is the related object.
This concept of a relationship owner might look a little peculiar to you at first, and you probably asked yourself already what is the impact of defining an object as the relationship owner, and how do I make that decision anyway? Let’s explore the answer to those questions in the following.
Selecting the relationship owner drives the following functionality in Network:
Permissions for editing and viewing relationships: On the profile page of the owner, the relationship is editable; that is, this is the place where users can add and modify relationship records. On the profile page of the related object, the relationship is read-only.
The way how the relationship is rendered in the Network Explorer: The relationship owner always shows on the right side and the related object always on the left:
The way how related records are returned in search: Searching for the related object will also return all the owners; whereas, searching for the owner will not include any related objects into the search result. For example, in an investigator relationship where the HCP is the owner and study is the related object, when searching for a specific study the search result will also include all related HCPs, but not vice versa.
In order to make the right decision when defining the owner and related object in a custom relationship, you should answer the following questions:
- Which side of the relationship should be editable via the profile page?
- How do you expect the relationship to render in the Network Explorer?
- How do you expect to search for the entities that are part of the relationship?
- Which side of the relationship has the higher number of records?
This last question is a good indicator of picking the right owner since the best practice is to make the side of the relationship with the higher number of records the owner. For example, one payer has multiple plans, but one plan has only one payer. This means that there are more records on the side of the plan than on the side of the payer. Therefore the plan object should be the owner of this relationship.
Types of Relationships
When it comes to linking main objects through relationship objects there are a lot of variants that one can think of, and in the following I would like to give you an idea of what is possible.
A very common type of relationship is a many-to-many relationship; for example, the relationship between HCPs and studies: One study can have multiple HCPs participating as investigators, and one HCP can participate in multiple studies. In Network, we call that an "unlimited relationship":
In contrast, a many-to-one relationship would be a "limited relationship," because the number of relationships per owner is limited to one. An example of this would be a relationship between payers and plans, where plan is the owner and where the number of payer per plan is limited to one:
The relationships that we looked at so far are rather simple relationships because there is only one object on each side of the relationship. But in Veeva Network, you can also create relationships that involve more than two main objects. This type of relationship we call an arc relationship. In the example below, an employee can have a relationship with an HCP or with an HCO. One thing to note is that this "or" is an "exclusive or" (XOR). This means when you create an individual relationship record, you have to choose whether that relationship points either to an HCP or an HCP. But of course, one employee can have multiple relationship records; this means you can create a first relationship record to an HCP and then a second relationship record to an HCP. The "exclusive or" just means that one single relationship record is always between two entities, not three or more.
Another type of relationship would be a recursive relationship, which means that the owner and the related object are identical. Or in other words, there is just one main object that uses a relationship object to refer back to itself. An example for this would be an employee to employee relationship, where an employee could be a manager and directly report to another employee at the same time.
And to take it even further, you can also combine both the arc idea with the recursiveness. This means you can create a relationship object where one of the main objects is an owner and a related object at the same time, and where you add one or more additional main objects to the relationship. An example of this would be a package content relationship which is shown below. In this example, you can use the relationship object to store a relationship between an inner package and an outer package, or you can use the relationship to store the product that is contained inside the package. Or in other words, a package can contain either another package or a product.
Perspective Labels
Okay, now what the heck are perspective labels? The perspective labels are defined when creating a relationship object and in the data model page they are called the "Owner Object Label" and the "Related Object Label." When you create a profile layout for the related object the "Owner Object Label" is used to refer to the owner object. And the other way round when creating a profile layout for the owner, the "Related Object Label" is used to refer to the related object. I sometimes call these labels "perspective labels," because they take the perspective of looking from the owner to the related object and vice versa.
Actually, when you create a new relationship object, these two labels (the "Owner Object Label" and the "Related Object Label") are usually already defaulted with the labels of the main objects that you selected. But there are some situations where it makes sense to change these labels or where there is no default and you have to set them manually. To explain, that let’s take a look at the examples in the table below:
If you have a simple relationship between product and brand, then the perspective labels are defaulted with the labels for the product and brand object. In that case, you are good and there is no real need to change the labels.
However, in a relationship between HCP and study, you might want to overwrite the default labels because, in this case, "Investigator" is more precise than "Healthcare Professional" and "Clinical Trial" might be a better label than "Study."
If you are dealing with a recursive relationship; for example, an employee to employee relationship, then changing the default labels makes a lot of sense as well because the default label ("Employee" in this example) would be way too unspecified. Better labels in this example would be "Manager" and "Direct Reports."
For any arc relationship, where there is more than one object on either side of the relationship, Network is not setting a default label and you have to set it manually. For example, in a package content relationship where inside a package could be either another package or a product, you have to set the label to a generic term that is suited to describe both objects, like "Package Content" in this example.
One important thing to keep in mind here is that the perspective labels that you define on the relationship object are just the default values that are used when creating the profile layout. This means that the labels that you see on the profile page when looking at the relationships of an entity, are coming from the profile layout and not from the relationship object definition. Keep that in mind when you want to change these labels. Changing the perspective labels on the relationship object does not update all existing profile layouts. If you want to change the relationship labels on a profile page, you need to change them in the profile layout.
Good to know
In conclusion, there is probably a lot to take in from part 1 and part 2 of this blog. And I admit that some of these data modeling concepts are quite specific, which means it will take some time to fully master them. But the good thing is that Veeva Network gives you all the possibilities to play around with custom domains and familiarize yourself with the usage of custom objects. Just log into your sandbox instance and get started. There is nothing that you can break since the Network data model is designed to allow you to play around with custom domains. If you are not satisfied with your results or if you don’t want to keep your data model permanently, you can always delete them and start over again.