What Is an Association ?
Updated: Nov 18, 2020
An association defines a relationship between two entity objects based on common attributes. The relationship can be one-to-one or one-to-many; you can use two one-to-many associations to implement a many-to-many relationship. The association allows entity objects to access the data of other entity objects through a persistent reference.
Associations act independently from referential integrity constraints
Although the same type of relationship can also exist at the table level through a foreign-key relationship or object REF, an entity object only needs an association to access the data of another entity object. You can create associations regardless of whether the database has the corresponding referential integrity constraints.
An example of an association
An example of a relationship is a one-to-many association between departments and employees. They might have a relationship where the Dept entity object has a Deptno attribute that is related to the Deptno attribute of the Emp entity object (Dept.Deptno = Emp.Deptno), as shown in the following figure. The DEPT and EMP tables are at the bottom of the figure, and the Dept and Emp entity objects are at the top of the figure. They have a master-detail relationship.
Accessors let you retrieve data across associations
Through optional association accessor methods in the entity objects, you can access data on the other side of the association. For example, inside the Dept entity object, you could call the getEmps method and retrieve a row set of Emp entity objects that reflect the employees working in the current department; the next time you call getEmps, it returns the same row set. Your code can traverse associations in either direction (master to detail, and detail to master). An entity object can traverse multiple associations to get the data it needs.
Compositions are a type of association
An association can be a composition, where the source entity object "owns" the destination entity object: no destination entity object can be created without the owning entity object existing first.
The parent object is a container for one or more child objects. If a child entity object is modified, the child entity object is validated. In addition, this relationship triggers validation of the parent entity object.
For inserts, updates, and deletes, the child entity object is considered part of the parent entity object. A parent entity object containing valid child entity objects cannot be deleted until all of the contained child entity objects are deleted. When attempting to change a child entity object, the business logic tier attempts to lock the parent entity object; the owning parent entity object must be successfully locked or the change will not be allowed. For example, if you make an airline reservation, you cannot reserve a seat on a flight if there already exists a reservation in your name.
A child entity object cannot exist without its parent. When a child entity object is created, the foreign key assignments are made, and the parent entity object must have non-null values for the primary key. At runtime, if a child entity object changes, the parent is marked as needing validation. During a commit, the parent entity object is validated, then the child entity object is validated.
Deciding whether to use an association or composition
First, you need to determine whether two entity objects are related or there is an ownership relationship. There are two questions you can ask.
Can Y exist independently of X?
If Yes, X is associated to Y.
If No, X is composed of Y.
For example, can a line item exist independently of an order? The answer is no, so it is a composition.
When I delete X, do I also delete the associated Y?
If Yes, the relationship is a composition.
If No, the relationship is an association.
For example, if you delete an employee, do you delete the department? If you delete a department, do you delete an employee? Th