Granularity of Dependencies

Note that the precedent data items used in the earlier example are deliberately vague - the term "personal details" would in all likelihood cover a great many individual data fields such as dates of birth/death, demographics, etc. The Dependency Manager does not know or care about the meanings of the dependencies that it stores between dependents and precedents - it is up to clients of the Dependency Manager to attach meanings to these and to store dependencies at an appropriate granularity.

The choice of granularity involves finding an acceptable trade-off between the two extremes of:

Very fine granularity
Very accurate dependencies are stored between dependents and individual data fields, enabling an extremely tight identification of dependents affected by precedent changes, but at the cost of very high numbers of dependency records being stored; vs.
Very coarse granularity
Very broad dependencies are stored between dependents and groupings of large numbers of individual data fields into one "data item", leading to low numbers of dependency records being stored, but at risk of spurious recalculations being requested (i.e. recalculations which turn out not to be needed because the calculation is not affected by the particular data field which changed).

It is the responsibility of designers of clients of the Dependency Manager to consider these trade-offs and make sensible choices about the level at which to store dependency information in the Dependency Manager.

For example, let's say that the system records these personal details about a claimant (in a realistic system there might be many more fields regarded as "personal details"):

date of birth (used in entitlement calculations);
number of children (used in entitlement calculations); and
mother's birth surname (the answer to a security question, used only to confirm the claimant's identity - not used in entitlement calculations).

A very fine-grained set of dependencies would show that a case's entitlement depends on the date of birth and number of children, but not on the mother's birth surname (as it was not accessed during calculations):

Table 1. Example Fine-Grained Dependency Matrix
Precedent	Case 127's Entitlement
Frank's date of birth	X
Frank's number of children	X
Frank's mother's birth surname

This fine-grained dependency storage could end up requiring many rows to be stored; but note that only changes to the date of birth and/or number of children will trigger a recalculation of the case's entitlement - if a typo is corrected in the mother's birth surname only, then no case entitlement recalculation will be triggered.

By contrast, a very coarse-grained set of dependencies would show a much simpler record that the case's entitlement depends on the overall personal details:

Table 2. Example Coarse-Grained Dependency Matrix
Precedent	Case 127's Entitlement
Frank's personal details	X

This coarse-grained dependency storage stores fewer dependency records but if a typo is corrected in the mother's birth surname then the overall personal details have changed and a recalculation of the case's entitlement will be triggered, even though the recalculation will show that the calculation result has not changed.