Understand the role of relationships in MBOs.
 |
Relationships provide navigation and subscription inheritance. See Relationship Modeling. |
|
Composite relationships provide navigation, subscription inheritance, and cascading create, update, and delete capabilities. See Relationships and Primary Keys. |
 |
Relationships should not span multiple synchronization groups. |
|
Relationships should not span multiple cache groups. |
 |
Map relationships using all primary key attributes of the source in one-to-many and one-to-one relationships. |
|
Map relationships using all primary key attributes of the target in many-to-one and one-to-one relationships. |
|
One-to-many relationships when "many" is large may be expensive to navigate on the device. |
Relationship Modeling
- In a noncomposite relationship, targets are automatically subscribed to. That is, all instances related to the source are downloaded, for example, all products referred to by sales order items. In the same way, when the source is no longer part of the device data set, all instances of the target no longer referred to are removed. For many-to-one relationships like sales order items to product, only those products that have no referring sales order items are removed.
- In modeling terminology, composite means a whole-part relationship. Composite relationships offer cascading create, update, and delete capabilities. For delete operations, if the parent is deleted, all the target/child instances are deleted as well. For update and create operations, when the submitPending API is invoked by the mobile application, all modified/new instances are sent with the parent as part of the operation replay.
Both types of relationships provide bidirectional or unidirectional navigation through generated code with lazy loading, which means children/targets are not loaded unless they are referenced. However, due to instantiation costs, navigating to a large number of children can be expensive, especially on devices with limited resources. If the instantiated object hierarchy is very wide, the mobile application should consider other means to access the children.
Relationships and Primary Keys
A relationship is implemented on the device database and the CDB through foreign keys. In Unwired Server, the foreign key contains a surrogate key instead of an EIS business key or primary key. In a one-to-many relationship, the foreign key is in the target and it is impossible for it to reference more than one source. Therefore, the restriction of using a primary key of the source is to ensure there is only one source.