Databases Reference
In-Depth Information
For example, the moment that the second data repository
appears (real estate), the same semantic model of the
category “Geography” must be re-used in order to counter
any deviation by silos from the modeling. If semantic
modeling tolerates data duplications then the penalty at the
development software level is immediate and acute: the
company gets MDM by silos, which leads to new problems in
data quality.
To avoid overlap within the semantic models themselves,
it is imperative to dispose of an Enterprise Data Architecture
such as that just presented.
The utilization of this architecture means that we accept
the sharing of semantic models, sharing them, using them in
a LEGO approach (plug and play use of data categories)
during the modeling process.
We should keep in mind two leading principles which
contribute to the success of this approach:
-
we have to organize the work appropriately in order
to anticipate and counteract the risks implicit in
mutualization. These risks are revealed when the data
models evolve, since the changes impact all the actors
involved in the same data representation (we have already
dealt with this subject in Chapter 7 dedicated to
organization);
-
the data categories must be structurally isolated from
each other in the software, in order to allow the LEGO
construction, meaning a plug and play use of data categories.
To fully achieve this, we will see that Logical Data
Architecture introduces a special derivation mechanism of
the data categories of the semantic model into the logical
data model, in order to obtain the necessary separation of
business objects. This mechanism is sufficiently strong
enough to allow a change of data category without
