Databases Reference
In-Depth Information
hidden away. The repository people are trying hard to migrate as much of
the semantics as possible into a repository. We are not there yet, and (so
far) there is no obvious “light at the end of the tunnel” suggesting that all
of the semantics of a data store can ever be captured in a broadly re-usable
way. The object-oriented people are trying hard to get us to migrate the
business rule into a hierarchy of objects (Model-View-Controller). Again,
we are not there yet, and again, there is no light at the end of the tunnel. Yet
another way of expressing this is to say that
much of the meaning of the
data is hidden in the programs
.
One way of appreciating this reality is to explore what it means to say
that a program or system is “old,” “obsolete” or “legacy.” A critical piece of
why this can happen, even in the face of all good intentions, good people
and good management is that the business rules are hidden away amongst
millions of lines of PL/1 or COBOL or C code, and no one remembers what
they are. One of the prime motivations to senior management for funding
the replacement of systems is to force staff to re-derive the enterprise's
business rules. With any luck, this time around, a larger proportion of the
business rules will be captured in a more explicit form than the last attempt
— making business change quicker, easier, and less costly. A key reason
why table driven systems such as SAP are achieving such market penetra-
tion is that they promise to capture a large fraction of the business rules in
tables rather than code.
THE WINDS OF CHANGE — WHAT KINDS OF CHANGE/MISMATCH
CAN HAPPEN?
We will explore three categories of change to underlying data in this
chapter: (1) two data sources are merging — one has information about 'X'
and the other does not; (2) one data source groups data codes data values
one way, and another groups them differently; and (3) there are business
rule differences between the data sources. In all cases, by understanding
the kinds of change, it is easier to describe the existing options for dealing
with them. In many cases, some forethought can prevent or mitigate
problems.
The Case of the Missing Attribute
The simplest sort of difference is a missing attribute. For example, an
insurance company decides to start tracking education level of insureds;
while building the data staging process for a data warehouse, you discover
that one division tracks the customers zip code while another does not. In
each case, you are faced with a decision to make or delegate upwards. The
data is missing from part or all of the available information over a period of
time. The problem arises when someone wants to see continuity of data
over time.
Search WWH ::
Custom Search