Among other surveys,[2] practitioners define a Federated Database as a collection of cooperating component systems which are autonomous and are possibly heterogeneous.
Multiple DBS of which FDBS are a specific type can be characterized along three dimensions: Distribution, Heterogeneity and Autonomy.
The benefits of data distribution help in increased availability and reliability as well as improved access times.
Heterogeneities in databases arise due to factors such as differences in structures, semantics of data, the constraints supported or query language.
The query language supported by one DBMS can also contribute to heterogeneity between other component DBMSs.
Semantic heterogeneities arise when there is a disagreement about meaning, interpretation or intended use of data.
Dealing with incompatible data types or query syntax is not the only obstacle to a concrete implementation of an FDBS.
Two principal approaches depend on the direction of the mapping: Both are examples of data integration, called the schema matching problem.
It was therefore extended to support the three dimensions of the FDBS namely Distribution, Autonomy and Heterogeneity.
Achieving global serializability, the major correctness criterion, under these requirements has been characterized as very difficult and unsolved.
[2] The five level schema architecture includes the following: While accurately representing the state of the art in data integration, the Five Level Schema Architecture above does suffer from a major drawback, namely IT imposed look and feel.