Design considerations for multiple entities

This section provides the following considerations when you design business objects for multiple entities:

Data ownership in relationships

The way you design your business objects to represent multiple entities has an effect on the ownership of the data:

This distinction is significant when considering the data consistency of an entity that is shared by multiple business objects.

For example, assume that a customer and a contact share an address. If the Customer and Contact business objects contain a reference to the Address business object (a semantic relationship) instead of containing the business object (a structural relationship), changes to the Address can be made independently of changes to the Customer or Contact.

However, if the Customer and Contact business objects each contain the Address business object, changes to the Address made by Customer might overwrite changes made by Contact. In this case, two different collaboration objects (CustomerSync and ContactSync) might update the same address data at the same time, causing data inconsistency.

If Customer and Contact have a semantic rather than structural relationship to the Address business object, you can limit modification of Address data to a third interface. For instance, you might have one interface for each of the Contact and Customer business objects. Then both of those interfaces could delegate management of Address business objects to a third interface. If your integration broker is InterChange Server this is done by having the CustomerSync and ContactSync collaboration objects call AddressSync through a wrapper collaboration object rather than directly making the changes themselves. For more information on designing business objects to maintain data consistency for InterChange Server integration scenarios, see "Designing for Parallel Execution" in the Collaboration Development Guide.

Figure 14 illustrates the difference between semantically and structurally defining the relationship to a child business object.

Figure 14. Comparing semantic and structural relationships

The figure above illustrates two kinds of relationships to child data:

Choosing between a semantic and a structural relationship

As Table 3 shows, both the one-to-one and one-to-many relationships can be represented by a structural or semantic relationship. Table 5 summarizes these structural and semantic representations.

Table 5. Representations for one-to-one and one-to-many relationships

Type of relationship Structural representation Semantic representation
One-to-one ( single cardinality) An attribute in a parent business object represents one child business object. An attribute in a parent business object is simple and contains the foreign key to reference one child business object.
One-to-many ( multiple-cardinality) An attribute in a parent business object represents an array of child business objects. Multiple child business objects each contain a foreign key attribute that stores the parent's primary key.

Figure 9 and Figure 10 illustrate business objects whose single- and multiple-cardinality relationships are defined semantically. The business objects in the example might represent data stored in a database. Relationships between business objects that represent such data can be defined both semantically and structurally. For such data, the relationship between a parent and child can be defined both semantically and structurally in the same two business objects.

Choosing a semantic relationship

To implement a semantic relationship, the underlying application should be able to support foreign keys. For example, when a business object represents database data, it can establish the relationship between entities both semantically and structurally. Such business objects are designed redundantly. In other words, the component that processes them can locate the child through the parent and the parent through each child.

For example, assume an application has a table that represents purchase orders. This table is related by foreign keys to a table that contains line items for a purchase order. Multiple rows in the line items table reference one row in the purchase orders table. Figure 15 illustrates these tables.

Figure 15. Example application tables with a one-to-many semantic relationship.

Figure 16 illustrates business objects that might correspond to these tables. This figure shows a top-level PurchaseOrder business object and three child LineItem business objects.

Figure 16. Sample business objects with multiple-cardinality semantic and structural relationships

The illustrated PurchaseOrder business object has both a semantic and structural relationship to its LineItem children. The PurchaseOrderId attribute in each child creates the foreign-key semantic link to the parent from the child. The LineItem attribute in the parent, which is defined with cardinality n, creates the structural link to the child from the parent.

Note:
IBM does not deliver any business objects that have the foreign key stored in the child. This document presents the above example only to illustrate different ways to link parent and child data.
Choosing a structural relationship

If the underlying application does not support foreign keys, you probably need to implement a structural relationship. For example, a DTD, which represents one XML document does not support foreign-key information. Therefore, any one-to-one or one-to-many relationships must be defined structurally. The following Order DTD, which contains elements that correspond to an application Order entity, illustrates single- and multiple-cardinality relationships:

<!--Order -->
 <!-- Element Declarations -->
 <!ELEMENT Order (Unit+)>
 <!ELEMENT Unit (PartNumber?, Quantity, Price, Accessory*)>
 <!ELEMENT PartNumber (#PCDATA)>
 <!ELEMENT Quantity (#PCDATA)>
 <!ELEMENT Price (#PCDATA)>
 <!ELEMENT Accessory (Quantity, Type)>
 <!ATTLIST Accessory
 Name CDATA >
 <!ELEMENT Type (#PCDATA)>
 

Figure 17 illustrates a business object that represents the Order DTD. The top-level business object contains the Order business object with one-cardinality relationship, and Order contains the child Unit business objects with a multiple-cardinality relationship. In turn, Unit contains the Accessory business objects with a multiple-cardinality relationship.

Figure 17. Single- and multiple-cardinality structural relationships

The relationship of business objects illustrated in Figure 17 is defined structurally; that is, each parent business object contains an attribute whose type is the same as the child's and whose relationship is specified as containment.

Important:
The XML data handler has specific requirements of the top-level business object that represents a DTD. For information about these requirements, see the Data Handler Guide.

Copyright IBM Corp. 1997, 2004