Databases Reference
In-Depth Information
CONCLUSION
Strict adherence to the one-concept-equals-one-data-element rule is not
always recommended. Situations do occur in which it is neither practical
nor cost-effective to collect and store that level of detail because it will
never be needed. These situations, however, are difficult to foresee. In addi-
tion, the data element designer is often not in a position to predict future
users' data requirements. Therefore, the rule is an excellent foundation on
which to build. If all data elements were initially developed to comply with
this rule, changes to the data elements could be made selectively after-
wards to the few that need not comply. This would then be done with full
knowledge of the costs incurred by doing so. The cost is measured by the
loss of flexibility and the subsequent risk that this lack of flexibility can
cause when unforeseen requirements emerge.
Although data element development standards must be independent of
data modeling efforts, they should support and be easily embraced by data
modeling efforts (i.e., the data element standardization rules should be
capable of being used with different modeling techniques). Also, even
when organizations are not involved in full-scale modeling efforts, rudi-
mentary data modeling during data element development often helps
answer important questions. Data element development is often easier
when done as part of a well-planned data modeling effort. The value of stan-
dardizing data elements in legacy systems, however, should not be
ignored. Slow-moving cleanup efforts often provide steady improvements
in data quality while new systems or databases are still in development.
Data element standardization, like data administration itself, will not
yield significant benefits as a separate and disconnected activity. Develop-
ing flexible, long-lasting data elements must be an integral goal of all sys-
tems development activities, whether they are development or mainte-
nance activities. The enforcement of the data element standardization
policy also must be an integral component of the system development pro-
cess. Monitoring data element development can provide necessary train-
ing to the developers in an informal setting and serve as an enforcement
mechanism. The tools used by the developers place limits on the configu-
ration and attributes allowed for data elements that frequently do not coin-
cide with the requirements of the data element standardization policy of
the organization. Therefore, the data administrator trying to monitor the
data element development requires a powerful tool that can overcome
these discrepancies.
Supporting Tools
Repositories to store complex relationships between nonstandard and
standard data elements are needed to support the process of migrating
from legacy data elements to standard data elements. Data element
Search WWH ::
Custom Search