Normalizing the Problem Domain

Before the logical and sometimes physical database is completed, it is desirable to normalize the model. This is a process of decomposing complex data structures into simple relations using a series of dependency rules. Normalization means reducing the amount of redundant data that will exist in the database or, in the case of application integration, in the enterprise. It is a good idea to do this in both the logical and physical database design, or the application integration redesign.

When considered within the context of application integration, the normalization process is very complex and risky. Because there can be no control over most of the databases that are being integrated, normalizing the logical enterprise metadata model often results in a new version of the model that has no chance of being implemented physically. This result violates an essential credo of application integration: Whenever possible, it is best to leave the applications and databases alone. Changes to databases inevitably translate into expense and risk. Furthermore, most enterprises employ a chaotic mosaic of database technology, making it technically unfeasible to accomplish such changes without rehosting the data. This is almost always completely out of the question.

However, the issue remains: Are changes to be made to source and target databases, or not? Generally, it is wise to normalize the logical enterprise metadata model to discover areas within the enterprise that may benefit from changes in their data structures. Changes to databases may allow the enterprise to reduce the amount of redundant data and thus increase the reliability of the integrated data. Remember, the notion of IOAI is to perceive all the information within the enterprise as a single source of information and, in turn, to make that huge amount of enterprise information as efficient as possible through processes such as normalization.