Databases Reference
In-Depth Information
Exhibit 39-1. Atomic data.
The only appropriate systems response here is sensible expectation
management. There are not many options for this one, and most managers
inherently appreciate that if they did not collect the information in the first
place, you cannot subsequently show it to them.
THE SHELL GAME — LOSING DATA BETWEEN THE SUMMARIES
The second sort of change or mismatch stems from what I call “non-
atomic” data. For example, take age (see Exhibit 39-1). There are several
ways to represent age:
•
By capturing the birth date/start date
— an “atomic” representation of
age. It allows the age of the person or thing to be calculated not only
as of the capture date, but for any other date as well. Atomic data pre-
sents no problems for change over time, conversion or integration
since the data is at a fine a level as it can be represented. Note that it
is possible to quibble with even this definition: for items that are very
short-lived, the exact time of start may be critically important — e.g.,
the exact time that a long distance phone call began.
•
By capturing the explicit age in whatever units are appropriate (e.g.,
years, months, days, hours)
— this could be atomic under one set of
business rules and not under another. If, for example, the age were
captured in years in one system, but new rules required age in months,
we have a conversion/integration problem. Also, unless the date at
which the age was captured is known, ages may not be comparable.
•
By capturing a code for the age range (e.g., under 25, 26 to 35, 35 to 50,
over 50)
— definitely not atomic. This concept becomes important
whenever certain types of change rear their ugly head. For example,
Search WWH ::
Custom Search