Databases Reference
In-Depth Information
they correlate data in order to detect certain atypical
behaviors.
For example, it could be highlighting situations such as:
-
the address of a third party which is modified more
than five times during a quarter;
-
a classification key of financial flows created and then
deleted in a period of less than two hours;
-
an employee allocated more than three positions in
less than six months;
-
a product which changes manufacturing units more
than twice in a week.
IT specialists must rapidly implement these rules, as
easily as possible, in order to be able to integrate new ones
without surplus software costs. How can they do this when
the tracked data is dispersed in databases within functional
and technical silos where they are out of reach?
Let us reconsider one of the above examples, that of the
modification of a third party address that we wish to keep an
eye on. How can IT know the number of times this address
has been modified in a period of time, when it is stored in
several databases, in the CRM, in the billing system, in an
Internet database? To make matters more complicated, it is
highly likely that the databases are not all capable of
restoring a full and unified data history of their updates
which can easily be used. The IT practitioner does not have a
choice: s/he suggests a bespoke software development in
order to add surveillance programs for distributed data.
They might perhaps put in place a database of the address
history on which the supervision business rules will be
applied? This is a sort of atrophied MDM, lacking
administration functions for business users, under the sole
control of IT. It takes time and leads to a locked solution.
