Databases Reference
In-Depth Information
updates to contracts as legislation imposes this form of
traceability.
In an MDM data repository, each object is described in the
form of a header initialized at the time of creation, and a
body of data that is subject to tracking. The data in the
header which are frozen at the time of creation do not need
to be tracked. This header contains in particular the
business object's identifier and its creation date. Other
information can be included, for example, the user's
identifier or system from which the creation originated.
Following this, each update of the business object occurs by
an insertion of data in its body associated with the date of
update. In this case, the MDM system does not allow the
update of data and permits only creations and insertions.
This principle is applied systematically and prevents, for
example, attempts to defraud which could happen with
direct data updates. Data deletion follows the same
principles and is enforced through a logical data deletion
only, not though a physical deletion.
This data history tracking can prove more complex when
associations between data have to be taken into account.
Taking our previous example further, we can see that our
business object “contract” is associated with a list of
“guarantees”. The behavior of the MDM system at the time
of the update of a guarantee that is already attached to
certain contracts has to be decided: should there be an
automatic contracts history or not when modifying its
guarantees? The reply to this question lies in the business
requirements. Specification must be applied with care so as
to adapt the behavior of the MDM system as required.
6.5.2.
Business transaction
This function allows us to link all the updates resulting
from a same user operation. For example, during the set up
