Objects may be related to one another without necessarily assuming that one is a component part of the other. For example, houses may be located on the right side or left side of a street. The street in question is not considered an intrinsic part of the house, and the house is not considered an intrinsic part of the street. Additionally, we might expect queries to be posed from either direction. On what street is the house located? What houses are located along the street?
In such situations the notion of aggregation as described above may be inappropriate. An alternative is to define a simple association explicitly, and reference the objects which are included in it. SAIF implements simple associations through the Relationship class and its subclasses. Consider the spatial relationship OnSide. As part of the definition of OnSide, two objects, objectA and objectB, may be defined as attributes, with the provision that they are referenced using their object identifiers. An instantiation of OnSide would contain the two object identifiers, and perhaps a third value indicating whether objectB is on the left or right of objectA.
It is a modelling decision whether an aggregation approach or a simple association is most appropriate. With aggregation, an attribute is used to hold the information. For example, as part of the definition of an arc (i.e. a line), the list of points defining the line can be specified for an attribute of the arc called pointList. The points are considered as an intrinsic part of our understanding of the arc, and it is assumed that the association is principally one way. That is, queries or operations are assumed to be from the perspective of the arc.
With explicit relationships the objects are typically considered of equal semantic importance, and it is assumed that queries or operations may be of interest from both directions. This is true whether the relationship is symmetric or asymmetric. Consider the following two cases. (1) If objectA is adjacent to objectB, then objectB is adjacent to objectA. (2) If objectA contains objectB, then objectB is contained by objectA. These relationships are symmetric and asymmetric, respectively. In both cases the relationship need be instantiated only once. In the latter case the order of the objects in the relationship is important.
The cardinality (or multiplicity) of the relationship may be of interest. Cardinality is a characteristic of the relationship in the context of the data under consideration. A number of houses may be on a given street. A given house is located on either one street or two (if it is on a corner of a block). Such cardinality information can be provided in the definition of the relationship type (or class). Consequently, it is considered a class attribute (see Section 2.2.1 and 2.2.3.1).