Database Reference
In-Depth Information
tion relationship is independent. This means that deleting the origin object does
not delete the related objects in the destination. It is also referred to as a simple
peer-to-peer relation; for example, a vehicle and its engine. An engine can exist
without a car, which means you can theoretically install that engine into another
vehicle. A composition relationship is where a destination object cannot exist
without an origin object. I don't really encounter many examples where a destina-
tion object cannot exist without an origin object; even when I do, I usually use an
aggregation relation, just to keep my related records. You wouldn't want to delete
related records in a production environment by deleting a single origin object.
You would like to keep your destination objects so you can refer back to them
anytime for the history.
For our reviews object, although this relationship does seem like a composition
relation, we will use a simple peer-to-peer relation so that we can keep our re-
views in case the diner is removed. In this dialog, select the
Simple (peer-to-
peer) relationship
option and click on
Next
. In the next form, we will discuss the
messages propagated between the origin and destination. Note that we have added
the diner object ID on the reviews record, which is the many side of the relation-
ship. Hence, the
DINER_REVIEWS
table will need to access the
Diners
feature
class. We refer to this kind of messaging as backward messaging because the
messages are propagated from the destination to the origin:
5. As illustrated in the following screenshot, select
Backward (destination to ori-
gin)
and click on
Next
:
