An association is a business component that defines a relationship between two entity objects based on common attributes. The relationship can be one-to-one, one-to-many, or many-to-many. The association allows entity objects to access the data of other entity objects through a persistent reference.
Business component wizards can automatically create associations based on the database constraints already defined in the database. They can also create database constraints based on the associations you define.
You are not required to have both an association and a database constraint defining the same relationship. An entity object only needs an association to access the data of another entity object, regardless of whether the corresponding constraint exists in the database through a foreign-key relationship or object REF.
For example, you might want to have an association but not a database constraint if you want to be able to insert a child before the parent exists.
In an organization, you might have a one-to-many relationship between departments and employees. The Department entity object could be related to an Employees entity object through DepartmentId attributes (Department.DepartmentId = Employees.DepartmentId).
The source end, containing the primary key, is the Departments entity object. The destination end, containing the foreign key, is the Employees entity object.
You can define and edit associations in the Association Wizard and Editor.
You can also generate default associations, based on foreign key constraints in existing tables, by using the Entity Object Wizard and Editor, Business Components Project Wizard, or Package Wizard.
You can optionally add foreign-key constraints to tables based on the associations you've defined in the Association Wizard and Editor.
If you add database constraints after generating your business components, you can automatically create the corresponding associations in the following ways:
Through optional association accessor methods in the entity objects, you can access data on the other side of the association. Your code can traverse associations in either direction. For example, inside the Department entity object, you could call the getEmployees method and retrieve a row set of Employees entity objects that reflect the employees working in the current department. Similarly, from the Employees entity object, you could call the getDepartment method to get the department that an employee works in. The data is cached, so the first time you call the method a database query is executed, but the next time it returns the cached data, saving time.
An entity object can call accessors in sequence to traverse multiple associations to get the data it needs.
A composition relationship means that the source entity object "owns" the destination entity object: no destination entity object can be created without the owning entity object existing first.
The source entity object (the parent) is a container for one or more destination objects (the children). If a destination entity object is modified, the source entity object is "marked" as needing validation.
A child entity object can't be created without its parent. When a child entity object is created, the framework assigns foreign key values to match the parent primary key values.
For inserts, updates, and deletes, the child entity object is considered to be part of the parent entity object. A parent entity object containing valid child entity objects can't 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 topmost parent entity object must be successfully locked or the change will not be allowed. For example, if you have an order with line items, and a user starts to modify a line item, the entire order is locked so no one else can modify the order or its items.
When you have a composition, in the validateEntity method of the parent class, you can add code that enforces a business rule involving multiple children. When data is changed in a child, the parent is marked for revalidation so that all rules about children can be enforced. For example, you could add code in the validateEntity method of an Order entity object so the total of an order's items can't be above the customer's credit limit.
To determine whether two entity objects have an ownership relationship, there are two questions you can ask.
Can a destination entity object exist independently of a source entity object?
If Yes, the source is associated to the destination.
If No, the source is composed of the destination.
For example, can a line item exist independently of an order? The answer is no, so the relationship is a composition.
When I delete the source, do I also delete the associated destinations?
If Yes, the relationship is a composition.
If No, the relationship is an association.
For example, if you delete an order, should you delete all of its line items? The answer is yes, so the relationship is a composition between orders and line items. If you delete a department, do you delete all of its employees? The answer is no, so the relationship is an association.
During reverse generation, if a referential integrity constraint in the database was defined with the ON DELETE CASCADE option, Business Components for Java automatically creates a composition.