Databases Reference
In-Depth Information
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
?
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
Database No. 4
Database No. 5
Agreement
Partner
Figure 1.1.
Referential integrity constraints spread over several databases
