Relationship Concepts
Roles
The first is the view from one side of the relationship, the second is from the other side, and the third is from a global perspective that knows about both sides. The “sides” are called roles. In every relationship there are two entities that are related to one another, and each entity is said to play a role in the relationship.
ex, An employee has a relationship to the department that he or she works in. The Employee entity plays the role of working in the department, while the Department entity plays the role of having an employee working in it.
Directionality
It is often the case that the other entity in turn has an attribute that points back to the original entity.
When each entity points to the other, the relationship is bidirectional. If only one entity has a pointer to the other, the relationship is said to be unidirectional.
A relationship from an Employee to the Project that they work on would be bidirectional. The Employee should know its Project, and the Project should point to the Employee working on it.
An Employee and its Address would likely be modeled as a unidirectional relationship because the Address is not expected to ever need to know its resident
Source and Target
So instead of having a single bidirectional relationship of an Employee working on a Project, we would have one unidirectional “project” relationship where the Employee points to the Project they work on, and another unidirectional “worker” relationship where the Project points to the Employee that works on it.
Each of these relationships has an entity that is the source or referring role, and the side that is the target or referred-to role
Cardinality
It isn’t very often that a project has only a single employee working on it. We would like to be able to capture the aspect of how many entities exist on each side of the same relationship instance.
This is called the cardinality of the relationship. Each role in a relationship will have its own cardinality, which indicates whether there can be only one instance of the entity or many instances.
In our employee and department example, we might first say that one employee works in one department, so the cardinality of both sides would be one. But chances are that more than one employee works in the department. Because of this we would make the relationship have a many cardinality on the Employee or source side, meaning that many Employee instances could each point to the same Department. The target or Department side would keep its cardinality of one.
In our Employee and Project example, we have a bidirectional relationship, or two relationship directions. If an employee can work on multiple projects and a project can have multiple employees working on it, then we would end up with cardinalities of “many” on the sources and targets of both directions
A picture is worth a thousand words, and describing these relationships in text is quite a lot harder than simply showing a picture. In words, though, this picture indicates the following:
Each employee can work on a number of projects
Many employees can work on the same project
Each project can have a number of employees working on it
Many projects can have the same employee working on them
Implicit in this model is the fact that there can be sharing of Employee and Project instances across multiple relationship instances.
Ordinality
A role may be further specified by determining whether or not it may be present at all. This is called the ordinality and serves to show whether the target entity needs to be specified when the source entity is created. Because the ordinality is really just a Boolean value, we also refer to it as the optionality of the relationship
