In most cases, the connector assumes that every individual business object is represented by one database table or view, and that each simple attribute (that is, an attribute that represents a single value, such as a String or Integer or Date) within the object is represented by a column in that table or view. Thus, attributes within the same individual business object cannot be stored in different database tables. However, the following situations are possible:
WebSphere Business Integration Adapter business objects can be flat or hierarchical. All the attributes of a flat business object are simple and represent a single value.
A hierarchical business object has attributes that represent a child business object, an array of child business objects, or a combination of both. In turn, each child business object can contain a child business object or an array of business objects, and so on. A single-cardinality relationship occurs when an attribute in a parent business object represents a single child business object. In this case, the attribute is of the same type as the child business object.
A multiple-cardinality relationship occurs when an attribute in the parent business object represents an array of child business objects. In this case, the attribute is an array of the same type as the child business objects.
The connector supports the following relationships among business objects:
In each type of cardinality, the relationship between the parent and child business objects is described by the application-specific information of the key attribute of the business object storing the relationship.
Typically, a business object that contains a single-cardinality child business object has at least two attributes that represent the relationship. The type of one attribute is the same as the child's type. The other attribute is a simple attribute that contains the child's primary key as a foreign key in the parent. The parent has as many foreign-key attributes as the child has primary-key attributes.
Because the foreign keys that establish the relationship are stored in the parent, each parent can contain only one single-cardinality child of a given type.
Figure 2 illustrates a typical single-cardinality relationship. In the example, fk1 is the simple attribute that contains the child's primary key, and child[1] is the attribute that represents the child business object.
Figure 2. Typical single-cardinality
relationship
Typically, each parent business object owns the data within the child business object that it contains. For example, if each Customer business object contains a single Address business object, when a new customer is created, a new row is inserted into both the customer and the address tables. The new address is unique to the new customer. Likewise, when deleting a customer from the customer table, the customer's address is also deleted from the address table.
However, there are situations where multiple hierarchical business objects contain the same data, which none of them owns. For example, assume that an Address business object has a StateProvince[1] attribute that represents the StateProvince lookup table with single cardinality. Because the lookup table is rarely updated and is maintained independently of the address data, creation or modification of address data does not affect the data in the lookup table. The connector either finds an existing state or province name or fails. It does not add or change values in the lookup table.
When multiple business objects contain the same single-cardinality child business object, the foreign-key attribute in each parent business object must specify the relationship as NO_OWNERSHIP. When a business process sends the connector a hierarchical business object with a Create, Delete, or Update request, the connector ignores single-cardinality children contained without ownership. The connector performs only retrieves on these business objects. If the connector fails to retrieve such a single-cardinality business object, it returns an error and stops processing.
For information on how to specify the relationship without ownership, see Attributes that represent a single-cardinality child business object. For more information on specifying foreign key relationships, see Specifying an Attribute's Foreign Key.
In addition to facilitating use of static lookup tables, containment without ownership provides another capability: synchronizing normalized and denormalized data.
Specifying a relationship as NO_OWNERSHIP allows you to create or change data when you synchronize from a normalized application to a denormalized one. For example, assume that your normalized source application stores data in two tables, A and B. Assume further that your denormalized destination application stores all the data in a single table such that each entity A redundantly stores B data.
In this example, to synchronize a change in table B data from your source application to your destination application, you must trigger a table A event whenever table B data changes. Moreover, because table B data is stored redundantly in table A, you must send a business object for each row in table A that contains the changed data from table B.
When synchronizing data from a denormalized source application to a normalized destination application, the connector does not create, delete, or update data contained without ownership in the normalized application.
When synchronizing data to a normalized application, the connector ignores all single-cardinality children contained without ownership. In order to create, remove, or modify such child data, you must process the data manually.
Typically, a business object that contains an array of child business objects has only one attribute that represents the relationship. The type of the attribute is an array of the same type as the child business objects. In order for a parent to contain more than one child, the foreign keys that establish the relationship are stored in each child.
Therefore, each child has at least one simple attribute that contains the parent's primary key as a foreign key. The child has as many foreign-key attributes as the parent has primary key attributes.
Because the foreign keys that establish the relationship are stored in the child, each parent can have zero or more children.
Figure 3 illustrates a multiple-cardinality relationship. In the example, parentId is the simple attribute that contains the parent's primary key, and child[n] is the attribute that represents the array of child business objects.
Figure 3. Multiple-cardinality business
object relationship
Some applications store a single child entity so that the relationship is stored in the child rather than in the parent. In other words, the child contains a foreign key whose value is identical to the value stored in the parent's primary key.
Figure 4 illustrates this special type of single-cardinality relationship.
Figure 4. Single-cardinality business
object with relationship stored in the child
Applications use this type of single-cardinality relationship when child data does not exist independently of its parent and can be accessed only through its parent. Such child data is never owned by more than one parent, and requires that the parent and its primary-key value exist before the child and its foreign-key value can be created.
To accommodate such applications, the connector also supports hierarchical business objects that contain a child with single cardinality but store the relationship in the child rather than in the parent.
To specify that a parent business object contains a single-cardinality child in this special way, when you specify the application-specific information of the attribute that contains the child, do not include the CONTAINMENT parameter. For more information, see Attributes that represent a single-cardinality child business object.
The wrapper object is a top-level business object that does not correspond to any database table or view. The wrapper object is denoted by the top-level business object property of WRAPPER with a value of true. The wrapper object is a dummy parent that is used as a container for unrelated children. In processing the wrapper object, the connector ignores the top-level business object and processes only the children. The wrapper object may contain N cardinality or N-1 cardinality entities or both.
A N cardinality entity should have at least one unique attribute marked as a primary key and at least one attribute marked as a foreign key. This foreign key will then be added as a primary key in the wrapper object. The entity's foreign key will reference the wrapper object's primary key that was just added.
In the case of a N-1 cardinality entity, the primary key should be marked as both a primary key and a foreign key, referencing the primary key in the wrapper, which is the same as the primary key in the N-1 entity.