Formalizing Reverse Parent-Child Relationships

A notation switchable version of the following technical note can be found here: Technical Note - Formalizing Reverse Parent-Child Relationships.

Parent-child relationships are binary relationships where one participant has some form of ownership over the other. They often appear on information models as defines or contains relationships and on UML models as compositions or aggregations. The parent will normally have a longer lifespan compared to the child and will often be one-to-many but not always. In OOA10, a parent-child relationship can be explicitly formalized by adding an Arbitrary ID Attribute to the child and then using a Parent Allocated ID Type to formalize the attribute. The relationship can be ordered by specifying the type as ordinal. Ordinal ID base attributes are normally called Order in my models while non-ordinal arbitrary ID base attributes are simply called Arbitrary ID. In either case, OOA Tool automatically annotates the attribute with an "A" suffix (short for arbitrary) followed by the relationship ID of the parent-child relationship (see diagram below for examples).

All of the above is fairly straight-forward. However, there is a complication when creating reverse or secondary parent-child relationships where the child needs to reference it's own parent to formalize a second relationship between the parent and child or where the parent needs to reference a specific child for special treatment. For simplicity I will refer to both types of relationship as reverse relationships from now on. Reverse relationships will normally be one-to-one since parent-child relationships are normally one-to-many. This technical note aims to discuss some issues with formalizing such relationships. A simple example involves the relationships between Object and Identifier in the OOA of OOA. There are two obvious relationships here, the parent-child relationship defines and the reverse relationship is preferred by. The diagram below illustrates four different ways of formalizing the reverse relationship. To simplify matters, the four approaches were all defined in the same domain so I have had to use object name qualifiers, e.g. Object A and Identifier A for approach A, etc.

Starting with approach A which is the obvious approach in OOA91. The parent-child relationship R1 is formalized using Identifier A.Object against the preferred identifier of Object A with Object A.Name as the base attribute. In OOA91, we could formalize the reverse relationship R2 using Object A.Name and Object A.Preferred Identifier since we can still manually specify Name as a base attribute. OOA10 takes this option out of the hands of the modeller to greatly tighten the rigor of information models, i.e. attributes are only base attributes when they are not referential or polymorphic attributes. However, OOA Tool still allows this approach to be captured but both Object A.Name and Identifier A.Object are annotated in the OOA Tool browser with the warning "Only circular references" indicating that no base attribute could be found.

Moving onto approach B which replaces Object A.Preferred Identifier with the referential attribute Identifier B.Preferred mapped to Object B.Name. This looks a little weird when you first see it but one must remember that referential attributes are not implementation fields, only a modelling mechanism to formalize relationships. Approach B has the same relationships as approach A but we have moved the formalization from the parent to the child avoiding the problem with base attributes. However, in doing so we have weakened the formalization since Identifier B could potentially be the preferred identifier of another object entirely which we certainly don't want. In OOA10, we can add a loop constraint to the reverse relationship R4 to ensure this doesn't happen. This approach works but may confuse some.

Approach C changes Identifer B.Preferred into the boolean attribute Identifer C.Preferred and makes the the reverse relationship R6 a mathematically dependent relationship (added in OOA10). The main problem with this approach is that we need to stop an object having more than one preferred identifier. We have two choices here with regard to the Action Language code formalizing R6:

1. we can decide which identifier flagged as preferred is actually the preferred identifier (e.g. first flagged) but we can't use the boolean attribute directly as an indicator,
2. or we can determine all preferred identifiers and the modeller can rely on a constraint error being flagged if more than one preferred identifier is set.

Both choices still require careful coding when determining preferred identifiers and setting them.

The final approach D which is the recommended approach since it has none of the drawbacks of the previous approaches yet it can always be used to formalize reverse relationships. It uses the associative object Preferred Identifier to formalize the reverse relationship R8. The only perceived disadvantage here is the addition of the new object. However, this is a modelling mechanism and does not imply any additional implementation code is required. Modellers may try to avoid this approach to reduce clutter but the previous approaches add complexity and additional error possibilities. If an Identifier D.Preferred boolean attribute is still desirable (perhaps to allow changes to be more easily observable in another domain) then a mathematically dependent attribute can still be added to Identifier D which checks whether a Preferred Identifier exists.

As a side note, the OOA of OOA actually uses approach A and is able to do that because Name isn't defined as a base attribute of Object in the Information Model subsystem. Instead Object is a subtype of Entity which defines Name as a base attribute. This indirection performs a similar role as the associative object in approach D. However, adding a subtype-supertype relationship above a parent is not a general solution to the problem which is why it's not given as an approach here.