A relation between different objects in the database has a parent object and a child object.The child contains the foreign key which points to the parent.
Example (for a static FK):
Parent: Person ABC
Child: ADSAccount which UID_Person=ABC
For such a relation one can configure the behavior to keep the consistency. The possibilities are:
DR (delete restrict) -> The deletion of the parent is not possible if there are related childs.
DC (delete cascade) -> When the parent is deleted, existing childs will be deleted automatically.
DS (delete set NULL) -> When the parent is deleted, the FK in the childs will be cleared, so the child remains, but doesn't point to the parent
Generally this means: The trigger to do anything automatically is always on the PARENT.
Now comes the dynamic FK.
Example from the use case:
UNSItemB.CCC_ObjectKeyRelation
In this case UNSItemB is the CHILD object.
The dynamic FK can potentially point to any table in the database.
So any table could contain a PARENT object.
That means, we would have to implement any trigger on EVERY table in the database to handle the entries in UNSItemB. This can impact the performance. However the dynamic FK can only be restricted to point to specific tables only. In this case the above mentioned behaviour can be defined in relation to this as in this case, One Identity Manager has to check for the child objects only for these specific tables.
Do note that the menu Valid for the reference tables will only be visible if the column is marked as dynamic foreign key.