Single-cardinality relationships in business objects

This topic describes the single-cardinality relationships that this adapter supports.

Single-cardinality relationships

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 child business object of a given type.

The figure titled "Typical single-cardinality relationship" illustrates a typical single-cardinality relationship. In the example, FKey in the ParentBOName box is the simple attribute that contains the child’s primary key, and Child(1), also in the ParentBOName box, is the attribute that represents the child business object.

This figure has a one-column box on the left with three rows below the column heading, ParentBOName. The three rows are labelled PKey, FKey, and Child(1). An arrow extends from this box to a box on the right with one column. There is one row beneath the column heading, ChildBOName. The row is called ChildPKey.

Typical single-cardinality relationship

A parent business object can have a single-cardinality OWNERSHIP child and a single-cardinality NOOWNERSHIP child.

Single-cardinality relationships and data without ownership

Typically, each parent business object owns the data within the child business object that it contains. For example, if each Customer business object contains one Address business object, when a new customer is created, a new row is inserted into both the customer and 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, situations can occur in which 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 adapter 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 NOOWNERSHIP. When an application server sends the adapter a hierarchical business object with a Create, Delete, or Update request, the adapter ignores single-cardinality children contained without ownership. The adapter performs only retrieve operations on these business objects. If the adapter fails to retrieve such a single-cardinality business object, it returns an error and stops processing.

Denormalized data and data without ownership

In addition to facilitating the use of static lookup tables, containment without ownership provides another capability: synchronizing normalized and denormalized data.

Synchronization of normalized to denormalized data: Specifying a relationship as NOOWNERSHIP enables you to create or change data when you synchronize from a normalized application to a denormalized one. For example, assume that a normalized source application stores data in two tables, A and B. Assume further that the denormalized destination application stores all the data in one table such that each entity A redundantly stores B data.

In this example, to synchronize a change in table B data from the source application to the destination application, you must trigger a table A event whenever table B data changes. In addition, 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.

Note: When making updates to denormalized tables, ensure that each record has a unique key so that multiple rows are not modified as a result of one update. If such a key does not exist, the Adapter for JDBC provides an error stating that multiple records have been updated.

Synchronization of denormalized to normalized data: When synchronizing data from a denormalized source application to a normalized destination application, the adapter does not create, delete, or update data contained without ownership in the normalized application.

When synchronizing data to a normalized application, the adapter ignores all single-cardinality children contained without ownership. To create, remove, or modify such child data, you must process the data manually.


Terms of use |

Last updated: Thu Mar 23 13:24:29 2006

(c) Copyright IBM Corporation 2005.
This information center is powered by Eclipse technology (http://www.eclipse.org)