A business object can represent application entities that include data from
other entities in one of the ways shown in Table 2..
Table 2. Representing multiple entities.
Structure of business object | Type of data organization | Type of parent/child relationship |
---|---|---|
Parent business object can have one or more child business objects that represent the other entities. | One-to-one
One-to-many | Structural |
Parent business object can have one or more foreign-key attributes that reference other top-level business objects that represent the other entities. | One-to-one
One-to-many Many-to-many Many-to-one | Semantic |
If the application and its interface permit, a flat business object can include attributes that directly reference other entities. | One-to-one | None |
When deciding how to structure business objects that represent multiple entities, consider these guidelines:
The following sections describe each of these representations is described in more detail.
In a structural relationship, the parent business object physically contains the child business object. Such a business object is a hierarchical business object: at least one of its attributes is complex (that is, it contains either a child business object or an array of child business objects). The Relationship attribute property for this attribute is containment, to indicate a containment relationship. The type of this attribute is the type of the child business object (or objects) it represents. For more information, see "Hierarchical business objects".
The following hierarchical business objects represent structural relationships:
In both cases, because the parent business object contains the child or array of children, the relationship is defined structurally.
A structural relationship assumes that the parent business object owns the data within the child object. Thus, when a new employee is created, a new row is inserted into the address table to hold that employee's address. Similarly, when an employee is deleted, the employee's address is also deleted from the address table.
In a semantic relationship, either the parent business object references the child, or the child references the parent. When one business object references another, it stores a value that uniquely identifies the other, but it does not contain the other. In this case, the component that processes the business object derives the relationship semantically.
A semantic relationship is typically defined by a simple attribute that serves as a foreign key. The foreign key attribute is located in one business object and contains the unique identifier (called the primary key) of the other. In other words, both business objects have a primary key attribute that holds its unique identifier. In addition, one of the business objects also has a foreign key attribute that holds the primary key value of the other. The foreign key establishes the link semantically between parent and child.
Semantic relationships are important when there is a many-to-many or many-to-one relationship between entities, in other words, when more than one parent has a relationship to the same child. Relating the entities semantically rather than structurally isolates the child's data, which is important to maintain data consistency.
Because the parent does not contain the child in a semantically defined relationship, the connector that handles requests for the parent and child receives them in separate operations. In other words, the requests are sent separately to the connector, which handles the parent and child in separate operations. For more information, see "Data ownership in relationships" and "Choosing between a semantic and a structural relationship".
Consider the design options in Table 3 for specifying a semantic relationship.
Table 3. Design options for semantic relationships.
Design option | Type of relationship |
---|---|
Storing the foreign key in the parent object | One-to-one
Many-to-one |
Storing the foreign key in the child object | One-to-many |
Storing foreign keys in an array of child objects | One-to-many
Many-to-many |
Storing the foreign key in a business-object tree | One-to-one |
In the simplest use of foreign keys, the foreign key that establishes the relationship is stored in the parent. In this case, a parent can contain a reference to only one child of a given type. The relationship between parent and child is clearly defined in the parent. Therefore, this structure represents a one-to-one relationship. However, multiple parent business objects can reference the same child business object to implement a many-to-one relationship.
In Figure 9, the Customer business object has two attributes (AddressId and CustInfo) each of which contain a reference to a child business object. The foreign key attributes in Customer readily identify the parent's relationship to the two children.
Figure 9. One-to-one: Multiple foreign key attributes stored in the parent.
Figure 11 illustrates an example of a generic business object, named Order. It is a parent business object that stores a foreign key reference to another object. Order contains the CustomerId attribute, which references a top-level generic Customer business object.
Alternatively, the foreign key that establishes the relationship can be stored in the child. This case represents a one-to-many relationship; that is, multiple children can reference the same parent. However, because the relationship between parent and child is defined in the child, the relationship is invisible when you examine only the parent. Therefore, if the parent business object triggers an integration flow, those children cannot be retrieved--there is no reference to them in the parent business object that is traveling through the system.
In Figure 10, the foreign key attribute is stored in each child business object rather than in the parent. This structure allows multiple children to be semantically related to the same parent. In this case, however, because the parent business object has no attributes that contain a reference to a child business object, there is no way to identify the parent's relationship to its children or, given the parent, to retrieve all of its related children.
Figure 10. Many-to-one: Foreign key stored in multiple children.
To represent a one-to-many relationship, the foreign key that actually establishes the relationship is stored in a simple attribute in a child business object. The parent business object structurally contains an array of these children. In other words, the parent contains an array of child business objects, each one of which contains a foreign-key reference to another top-level business object. In addition, multiple parent business objects can reference the same child business object in their child business object arrays to implement a many-to-many relationship.
Figure 11 illustrates a parent object, the Order business object, that stores a foreign key reference to another object. The Order business object contains a reference to one Customer business object and structurally contains an array of ContactRef business objects. Each ContactRef business object contains a reference to one Contact business object.
Figure 11. Parent containing a child that stores foreign keys.
In this design, the foreign key that establishes the relationship is stored in a "child" business object whose parent is another business of the same type as itself. Such a business object contains a ParentId attribute, which can contain a reference to another business object of the same type as the current business object, which is the direct parent of the current business object.
In Figure 12, the ParentId attribute of one SampleA business object contains a reference to the primary key (ObjectId) attribute of its immediate parent SampleA business object. The head of the hierarchy is the business object whose ParentId attribute does not contain a value.
Figure 12. Business object storing a foreign key in its parent of the same type.
If the application interface provides the capability of joining multiple application entities in one business object, you may be able to define a flat business object that contains attributes referring to a primary entity and to related entities. If the relationship between the entities is a one-to-one relationship, where one instance of the primary entity can be associated with one instance of each related entity, attributes from multiple entities can be included in one business object.
When designing an application-specific business object of this type, you may need to use application-specific information to specify the location of attribute data in the application so that the connector can find and process the data correctly.
Figure 13 provides an example of a flat WebSphere business integration system business object that represents data in two entities, one a table containing address data and the other a table containing lookup data for state/province and country abbreviations.
Figure 13. Flat business object that represents two entities.
This example uses application-specific information to establish a foreign key relationship between the entities. In this case, the connector performs a lookup from a value in an attribute that represents one table to provide a value for an attribute that represents another table. To retrieve this data, the connector performs two table reads.
Although flat business objects can encapsulate information from or included in multiple application entities, cross-application integration problems often require more complex integration logic and more complicated data structures than flat business objects can represent. To handle more complexity in application entities and integration requirements, the WebSphere business integration system provides hierarchical business objects.