Databases Reference
In-Depth Information
the links are managed automatically. The retrieval of
factories linked to a product presents no issues.
However, if the products are stored in a separate database
to that of the factories, for example each in a different
functional silo, a software infrastructure is required to
manage the associations.
When a large number of data elements are duplicated
across many databases, with multiple links, this
infrastructure becomes complex. Sometimes the same data
object can have different identifiers depending on the
database in which it is stored. In the absence of software
offering a unified vision of the links between the objects used
in the different databases, the data integrity rules are
difficult to manage in a reliable manner. For example, when
we modify the attributes of a factory, it is necessary to find
all the attached products so as to check that these
modifications are compliant with existing products
configurations. If the products are spread across several
databases, IT specialists must build bespoke programs to
gather a consolidated and unified view of all products for the
factory. In the same way, queries which require links to
objects stored on different databases can be costly to put in
place; they require bespoke developments which negatively
affect system performance and can be costly (because of
development and maintenance) and negatively affect
response times and integrity.
To overcome these problems, IT practitioners can put in
place a virtual MDM system. This MDM system only
manages the identifier of the objects, their links and their
locations in the databases; it does not contain descriptions of
the data objects; this is why the term “virtual” is used. The
body of the data is not stored on this MDM system. It is also
called a broker, mostly when it supplies data mapping
between the identifiers of the same business object. For
example, a customer has an identifier equal to IdValue#1 in
