Concepts

These are the key objects BC4J uses to manage relationships betwen components in an application: Entity Object, Association, View Object, View Link.

Entity Objects represent tables, and an Association defines a relationship between two Entity Objects. 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. Through optional association accessors 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 getAttribute("Employees") or, if you have generated accessor methods, getEmployees() 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 getDepartment() 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.

Similarly, View Objects represent views of tables, and a View Link defines a relationship between two View Objects. A view object is a class that lets you define and work with a set of rows, often in service of a user interface. Typically, a view object contains a SQL query that selects data from a database. It can be associated with underlying entity objects so you can modify data in the database, or not be associated with entity objects at all.

Just as View Objects can be based on Entity Objects, View Links can be based on Associations. In either relationship, one end is the source, the other end is the destination. One difference between associations and links is that associations are bidirectional; links are navigable in one direction only. For example, suppose two tables have a master-detail relationship based on a foreign key. The corresponding Entity Objects are related via an Association, and View Objects based on those Entity Objects are related by using a View Link based on the Association. The master end of the relationship is the source, the detail end is the destination.

A view link defines a relationship between view objects. The relationship can be one-to-one, one-to-many, many-to-one, or many-to-many. The View Link Wizard and Editor lets you specify source and destination view objects, and links them using attributes selected from the view objects. A view link is similar to an association, but is more flexible. It allows more relationships than equality between attributes and supports automatic master-detail synchronization. You need view links to traverse view objects, such as to obtain or modify data, and to add master-detail relationships to a data model in the application module.

An example of a one-to-many relationship could be a DepartmentsOverBudgetView view object linked to a ContractorView view object in a master-detail relationship. With this view link, you could efficiently look at information about contractors in overbudget departments. An example of a more complex one-to-many relationship could be a CustomerView view object linked to an OrderView view object in a master-detail relationship, and the OrderView view object linked to an ItemView view object in a master-detail relationship. So a user could quickly look at the items in a particular customer's order in one form.

One key feature of associations is that the framework generates accessor methods to traverse the association, enabling you to get and set at the destination end of the association.For example, an organization could 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 following figure shows how the association, by default named EmpDeptFkAssoc, would appear in the JDeveloper Structure pane:

The source end, containing the primary key, is the Departments entity object. The destination end, containing the foreign key, is the Employees entity object.

The following figure shows how Business Components represent a master-detail relationship between the DEPT and EMP tables. It also shows how a client might use the objects to display linked data in a form.

Business Components can model more complex relationships involving multiple tables, as well. As the figure below shows, you could use View Links to define a one-many-many relationship between customers and orders, and orders and items.