Data Management Strategies for the CIOThis article originally appeared on the BeyeNETWORK.
There is a paradox that is confusing and causes quite a difference of opinion between system developers and technicians. That paradox is the difference between definitions for the operational, transaction system developer and the decision support system developer.
The operational system developer requires a crisp, well defined meaning for his/her development needs. The decision support system developer requires a loose, general, non-specific definition of data for his/her development needs.
In order to make this distinction come alive, consider the following definition. Both types of people – the operational system developer and the decision support system developer – have to define CUSTOMER.
The operational system developer needs a crisp definition of exactly who the CUSTOMER is. The reason a crisp definition is needed is because CUSTOMER will be defined in terms of business rules. In turn, those business rules will be turned into code. There can be no ambiguity as to who the CUSTOMER is and how CUSTOMER is to be treated in code. Any ambiguity results in transactions that don’t function properly or doesn't function at all.
Therefore, because code governing transactions is to be created, there needs to be a very precise, exact definition of CUSTOMER.
Now consider the decision support
Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on the hottest data and information management trends today.
Hannah Smalltree, Editorial Director
system developer. The decision support system developer’s
problem is almost exactly the opposite of the operational system developer’s problem. If the
decision support system developer creates a narrow and strict definition of data, then the
developer limits the future analytical capabilities of the data.
For example, suppose the decision support system developer decides that a CUSTOMER is only an individual, not an institution. At a later point in time, the decision support system analyst will not have access to data relating to corporations and other institutions. Or, suppose the decision support system analyst decides that a CUSTOMER is only a person or organization that is actively engaged with the business. This means that the data relating to old CUSTOMERS cannot be accessed and analyzed.
From a database design standpoint, the decision support system database designer has it easy. The decision support system database designer simply chooses the most general definition of data and the places data elements that allow the decision support system analyst to determine – at the time of analysis – what class of CUSTOMER needs to be analyzed. For example, in the table for CUSTOMER, the decision support system analyst places data elements such as date of last activity, individual or organization, gender, address, and so forth in the table. Then, at the point of analysis, the analyst selects what subclass of CUSTOMER is desired.
The problem becomes acute when the experienced operational designer is asked to design a data
warehouse. It flies in the face of everything that he/she knows for the operational developer to
design an ambiguously defined data warehouse.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation