Page 55 -

16 Enterprise Data Governance

Whatever the case, it becomes difficult to distinguish
between systems that accept data and those that do not, as
there is no unified data repository, nor any common
validation rules.

These validation rules become complex when referential
integrity constraints that extend over multiple databases
within the IS come into play. For instance (see Figure 1.1): “a
product (Database No. 1) is only created if the factory code
(Database No. 2) which it is affiliated with is under the
management of an organization (Database No. 3) that has an
ongoing production agreement (Database No. 4) with the
company or one of its partners (Database No. 5), that has
been active for the past twelve months, at its disposal”.

In a scattered IT system, under the influence of multiple
databases that have to be synchronized, it is difficult to
decide where these referential integrity constraints should
be set up. Often, in the absence of a better method, they are
found in several places in silos and hard-coded in the
integration layer. With the complexity that arises with the
enforcement of these types of rules, a company is heading for
disaster. It is not the complexity that is at fault, but rather
the way in which these rules are handled.

Database No. 1 Database No. 2 Database No. 3
Product Factory Organization

with the company or one of its partners (Database No. 5), that has been active ?
A product (Database No. 1) is only created if the factory code (Database No. 2)
which it is affiliated with is under the management of an organization
(Database No. 3) that has an ongoing production agreement (Database No. 4)
for the past twelve months, at its disposal

Database No. 4 Database No. 5
Agreement Partner

Figure 1.1. Referential integrity constraints spread over several databases