Relationship Guidelines

Follow these guidelines when configuring MBOs and enterprise information systems (EISs) used in relationships.

Relationship guidelines
Guideline	Example
These examples use SQL Anywhere to illustrate how to properly configure the EIS so delete operations behave as expected	Example one consist of two MBOs: Address: addr_id, street, city, country Employee: emp_id, name, addr_id (foreign key references Address.addr_id) The MBOs have a relationship defined, for example, a composite, uni-directional, one-to-one relationship: Employee(Parent) --> Address(Child) At runtime, if you delete Employee, Unwired Server attempts to delete the child Address first, which fails because of the Employee.addr_id-to-Address.addr_id reference. For the delete operation to perform as expected, the addr_id foreign key must be defined in the EIS database as on delete set null to enable deletion. This requirement applies regardless of the type of relationship defined between the MBOs. Example two also uses the Employee and Address MBOs in a relationship that has mutual references: Address: addr_id, street, city, country, emp_id(foreign key references Employee.emp_id) Employee: emp_id, name, addr_id(foreign key references Address.addr_id) You must set both foreign keys in the EIS database as on delete set null or on delete cascade, regardless of the type of relationship you define for Address and Employee, or neither of them can be deleted.
If the foreign key in a relationship points to a `char(n)` column, and it is the only column in the table, use the rtrim(column name) function in the MBOs column definition	This example has a relationship defined as: States(Parent) --> Sales_region(Child) Sales_region contains one column named Region with a data type of char(7). The MBO definition should be: SELECT rtrim(region) as region FROM sampledb.dba.sales_regions
MBOs used in a relationship must belong to the same Synchronization group	MBOs in a relationship need to share the same synchronization characteristics for proper synchronization of all MBOs within the relationship, therefore verify that all MBOs are in the same synchronization group.
By default, all MBOs in a relationship are assigned to the same cache group	You can assign different cache groups to MBOs within a relationship, however, doing so generates a warning message. You may want to, for example, separate cache groups with different cache policies for a `sales` MBO, which changes frequently, that has a relationship with the `catalog` MBO, which changes infrequently.
Unwired WorkSpace does not support Circular relationships	Do not create circular relationships that work from parent-to-child then, eventually, back to the parent. For example: A relationship that includes three MBOs: A, B, and C, where A----->B----->C----->A is not supported.
Composite relationship behavior	If a parent MBO's primary key is auto-incremental and you want to perform multi-level insert operations, then the relationship must be composite. Otherwise the child MBO can only be created on an existing parent MBO. When Composite is selected, all child operations are performed through the parent. Foreign key attributes are updated automatically when setting a related parent/child object. Do not directly update the child's attribute (row) identified by the foreign key. Multi-level insert (MLI) operations require composite relationships. For successful composite deletes, all children MBOs in the composite relationship must have a delete operation, which includes only one parameter that has Fill from Attribute to the primary key attribute and mapped to the primary key argument. A child MBO can have multiple parents (many to one), but only one parent can have a composite relationship to the child. In a composite relationship, when one child MBO does not have a synchronization parameter, and has multiple parents, each of which has a synchronization parameter, the child inherits synchronization behavior from both of the parents. If a composite relationship does not exist, Unwired WorkSpace randomly selects a parent through which the child synchronizes. Sybase recommends that you define one parent MBO as the composite parent to avoid unintended behavior. For example: There are two one-to-many relationships: A<--->>C and B<--->>C. Both MBOs A and B have a synchronization parameter while MBO C has none. In this case, one of the relationships should be a composite.
First/subsequent MBO relationship behavior	Multiple MBOs created from a single operation result: Subsequent MBOs as child entities (if the relationship mapping is based on a subsequent MBO load parameter) are supported, and the relationship is treated the same as a relationship on an attribute, meaning it does not affect MBO loading. Relationships from subsequent to first MBOs where the relationship mapping is based on the load parameter of the first MBO are not supported.
Local business objects	A relationship between two local business objects that does not have a primary key set is invalid. You cannot create relationships between local business objects using a composite primary key.
Multi-level insert operation behavior	Multi-level insert operations do not support unidirectional one to many relationships – newly created rows in the child MBO do not display prior to synchronization in a unidirectional one to many relationship. To view details prior to synchronization from the device application, go to the pending operations screen.
Automatic setting of primary keys	Relationships require all primary keys on the source or target MBO (source or target depends on the relationship type) to be referenced in the relationship. If you design a relationship that does not include all the primary keys, a warning prompt allows you to decide whether to automatically set reference attributes to primary keys, and unset the unreferenced attributes primary keys. If you select Yes, Unwired WorkSpace automatically sets the primary key, if not, Unwired WorkSpace maintains the existing primary key setting, and displays a validation message according to the relationship rules.
Personalization key and default value removed from child parameter.	When creating a relationship from an attribute of a parent MBO to a load parameter of a child MBO, the personalization key and default value cell of the load parameter is disabled, and the personalization key and the default values, if any, are cleared, since those values are not used to load the child's value from the EIS at run-time.