alone. The query language supported by one DBMS can also contribute to heterogeneity between other component DBMSs. For example, differences in query languages with the same data models or different versions of query languages could contribute to heterogeneity. Semantic heterogeneities arise when there is a disagreement about meaning, interpretation or intended use of data. At the schema and data level, classification of possible heterogeneities include: Naming conflicts e.g. databases using different names to represent the same concept. Domain conflicts or data representation conflicts e.g. databases using different values to represent same concept. Precision conflicts e.g. databases using same data values from domains of different cardinalities for same data. Metadata conflicts e.g. same concepts are represented at schema level and instance level. Data conflicts e.g. missing attributes Schema conflicts e.g. table versus table conflict which includes naming conflicts, data conflicts etc. In creating a federated schema, one has to resolve such heterogeneities before integrating the component DB schemas. Schema matching, schema mapping Dealing with incompatible data types or query syntax is not the only obstacle to a concrete implementation of an FDBS. In systems that are not planned top-down, a generic problem lies in matching semantically equivalent, but differently named parts from different schemas (=data models) (tables, attributes). A pairwise mapping between n attributes would result in mapping rules (given equivalence mappings) - a number that quickly gets too large for practical purposes. A common way out is to provide a global schema that comprises the relevant parts of all member schemas and provide mappings in the form of database views. Two principal approaches depend on the direction of the mapping: Global as View (GaV): the global schema is defined in terms of the underlying schemas Local as View (LaV): the local schemas are defined in terms of the global schema Both are examples of data integration, called the schema matching problem. Autonomy Fundamental to the difference between an MDBS and an FDBS is the concept of autonomy. It is important to understand the aspects of autonomy for component databases and how they can be addressed when a component DBS participates in an FDBS. There are four kinds of autonomies addressed: Design Autonomy which refers to ability to choose its design irrespective of data, query language or conceptualization, functionality of the system implementation. Heterogeneities in an FDBS are primarily due to design autonomy. Communication autonomy refers to the general operation of