The metadata model defines all the data structures existing in the enterprise as well as how those data structures will interact within the application integration solution domain. Once constructed, the enterprise metadata model is the enterprise's database repository of sorts, the master directory for the application integration solution. In many cases, the repository will be hooked on to the application integration technology and used as a reference point for locating not only the data, but also the rules and logic that apply to that data. However, the repository is more than simply the storage of metadata information. It is the heart of the ultimate application integration solution, containing both data and business model information.

The metadata repository will solve the data integration problem as well as provide the basis for other types of application integration (e.g., application service-based). As in the world of client/server and data warehousing, the process builds up from the data to the application, and from the application to the interface, if necessary. This "hierarchical" flow identifies information-oriented application integration as the foundation for the larger application integration solution.

Just as with traditional database design methods, the enterprise metadata model used for data integration can be broken into two components: the logical and the physical. The same techniques apply to both models.

Creating the logical model is the process of creating architecture for all data stores that are independent of a physical database model. A logical model is a sound approach to an application integration project in that it will allow architects and developers the opportunity to make objective data-level application integration decisions, moving from high-level requirements to implementation details. 

The logical data model is an integrated view of business data throughout the application domain, or of data pertinent to the application integration solution under construction. The primary difference between using a logical data model for application integration versus traditional database development is the information source. While traditional development, generally speaking, defines new databases based on business requirements, a logical data model arising from an application integration project is based on existing databases.

Application integration requires that some common physical representation be selected. Only then can the model be transformed as required. The necessity of the physical model is only for those times when it is possible to map the logical to the physical--that is, those times when an enterprise uses a homogeneous database approach, usually all relational. The input for the physical model is both the logical model and the data catalog. When accessing this information, consider the data dictionary, business rules, and other user-processing requirements.

Thus, you need both for a sounds data integration strategy.