Editing Federated database system (section)

=== Distribution ===

Distribution of data in an FDBS is due to the existence of a multiple DBS before an FDBS is built. Data can be distributed among multiple databases which could be stored in a single computer or multiple computers. These computers could be geographically located in different places but interconnected by a network. The benefits of data distribution help in increased availability and reliability as well as improved access times.

==== Heterogeneity ====
{{main|Heterogeneous database system}}
Heterogeneities in databases arise due to factors such as differences in structures, semantics of data, the constraints supported or [[query language]]. Differences in structure occur when two [[data model]]s provide different primitives such as [[Object-Oriented Modeling|object oriented (OO) models]] that support specialization and inheritance and [[relational model]]s that do not. Differences due to constraints occur when two models support two different constraints. For example, the set type in [[CODASYL]] [[Database schema|schema]] may be partially modeled as a referential integrity constraint in a relationship schema. [[CODASYL]] supports insertion and retention that are not captured by referential integrity alone. The query language supported by one [[Database management system|DBMS]] can also contribute to [[Heterogeneous Database System|heterogeneity]] between other component [[Database management system|DBMSs]]. For example, differences in query languages with the same [[data model]]s or different versions of query languages could contribute to [[Heterogeneous Database System|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. [[database]]s using different names to represent the same concept.
* Domain conflicts or [[data]] representation conflicts e.g. [[database]]s using different values to represent same concept.
* Precision conflicts e.g. [[database]]s using same data values from domains of different [[Cardinality|cardinalities]] for same [[data]].
* [[Metadata]] conflicts e.g. same concepts are represented at [[Database schema|schema]] level and instance level.
* [[Data]] conflicts e.g. missing [[Attribute (computing)|attributes]]
* [[Database schema|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 [[semantic equivalence|semantically equivalent]], but differently named parts from different [[logical schema|schemas]] (=data models) (tables, attributes). A pairwise mapping between ''n'' attributes would result in <math>n (n-1) \over 2</math> 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 view]]s. 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.