There are a number of data inaccuracy issues that come out of structure analysis. Some of these are indictments on the data source and should lead to remedies in the source systems. Others are issues that can be handled when moving data.
Structural issues in source systems generally do not cause problems with their applications. They merely invite inaccurate data to be entered without detection. The remedies that are commonly used are to add data checkers for data entry, update, and delete to ensure that rules are not violated by new data. This is
A Common story involving relational systems is where the original application developers specified use of
Most issues that come out of structure analysis violations involve bad original database design. It is very difficult to get an IT department to want to change the structure of a database that is in operation. The cascading effects can be large, creating an expensive project with a high degree of risk. When changes cannot be done, it is doubly important to document the structure of the source systems to help fend off errors in using the data.
You can always add batch checkers to look for rule violations outside transaction processing. Often this is a good compromise between
The most interesting quality issues come up for projects that try to extract the data from source systems and move it to new, different target systems. The
One issue is structural mismatches between source and target regarding primary keys. It may be that the data just cannot make the trip to the other side. It lacks the structural compatibility to find its proper place at the target. When this occurs you have to consider either scrapping the project or changing the target design. Sometimes you have no choice about going ahead with a project, requiring some creative design to fix the problems. Having the profile of the source system's structure in the level of detail described in this chapter is the perfect input for coming up with a solution.
A last area for remedies is to
The last value is in designing proper data movement processes. The logic discussed for data model development is the basis for building a proper series of data transformation and merge steps that will result in a correct target. Trying to build a design for data movement without this road map just invites errors.