Business object relationships

The Cardinality property of the attribute that represents the child or array determines the type of relationship between parent and child:

The connector does not process a single-cardinality relationship differently from a multiple-cardinality relationship. However, there is a structural difference in foreign-key relationships when database tables have single-cardinality or multiple-cardinality relationships. This difference is important when Advanced Outbound Wizard generates a business object definition from an SAP Display Transaction:

In each case, the foreign-key relationship between the parent and child business objects is specified by the application-specific information of the key attributes of the child business object. For more information, see "Business object attribute properties" and "Application-specific information for simple attributes".

The next sections describe the following relationships among business objects:

Single-cardinality relationship example

Figure 32 provides an example of a simple WebSphere business object developed to process customer objects in SAP. This example SAP_Customer has a single-cardinality relationship to the example address object that it contains (the addr_data[1] attribute has cardinality 1). The primary key attribute (address_id) in the child business object references a non-primary key (address_id) in the parent business object.

Figure 32. Example customer and address relationship

The following SELECT statements and their output illustrate retrieval of data from the tables represented by the business objects above:

SELECT * FROM KNA1
  
 KUNNR          NAME1          ADRNR
 -----          -------------  ----------
 10254          JOE'S PIZZA          2208
 10255          LARRY'S HARDWARE     2209
  
 SELECT * FROM ADRC
  
 ADDRNUMBER          CITY1          REGION
 ----------          ----           -----
 2208                BURLINGAME     CA
 2209                SAN FRANCISCO  CA
 

In the example above, each customer (Joe's Pizza and Larry's Hardware) has a single address. If the KUNNR and ADDRNUMBER columns are defined as primary key constraints for their respective tables, the above structure ensures that each customer can have only one associated address.

Note:
For the sake of simplicity, the illustrations in this document do not display the application-specific information used by the connector to determine the tables and fields in the SAP application's database.

Multiple-cardinality relationship example

Figure 33 illustrates a multiple-cardinality relationship. In the example, ID=ABC is the simple attribute with the parent's primary key, and child[n] is the attribute that represents the array of child business objects.

Figure 33. Multiple-cardinality business object relationship

Figure 34 provides an example of a different WebSphere business object developed to process customer objects in SAP. This example SAP_Customer has a multiple-cardinality relationship to the example sales view object that it contains (the sales_view_data[n] attribute has cardinality n). The primary key attribute (customer_id) in the child business object references the primary key (customer_id) in the parent business object.

Figure 34. Example customer and sales view relationship

The following SELECT statements and their output illustrate retrieval of data from each of these tables:

SELECT * FROM KNA1
  
 KUNNR          NAME1
 -----          -------------
 10254          JOE'S PIZZA
 10255          LARRY'S HARDWARE
  
 SELECT * FROM KNVV
  
 KUNNR          VKORG          VTWEG          SPART
 ----------     -----          -----          -----
 10254          EURP          01             12
 10255          EURP          01             09
 10255          USA           01             13
 10255          USA           01             14
 

In this example, Joe's Pizza has one associated sales view record, whereas Larry's Hardware has three associated sales view records. The above structure allows each customer to have zero or more associated sales view records.

Copyright IBM Corp. 1997, 2004