# Federated database system

> Mediated Wiki article. Canonical URL: https://mediated.wiki/source/Federated_database_system
> Markdown URL: https://mediated.wiki/source/Federated_database_system.md
> Source: https://en.wikipedia.org/wiki/Federated_database_system
> Source revision: 1296654595
> License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/)

System for managing connected databases

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Federated database system" – news · newspapers · books · scholar · JSTOR (November 2023) (Learn how and when to remove this message)

A **federated database system** (**FDBS**) is a type of [meta-](/source/Meta_(prefix))[database management system](/source/Database_management_system) (DBMS), which transparently maps multiple autonomous [database systems](/source/Database_management_system) into a single **federated database**. The constituent [databases](/source/Database) are interconnected via a [computer network](/source/Computer_network) and may be geographically decentralized. Since the constituent database systems remain autonomous, a federated database system is a contrastable alternative to the (sometimes daunting) task of merging several disparate databases. A federated database, or **virtual database**, is a composite of all constituent databases in a federated database system. There is no actual data integration in the constituent disparate databases as a result of data federation.

Through [data abstraction](/source/Data_abstraction), federated database systems can provide a uniform [user interface](/source/User_interface), enabling [users](/source/User_(computing)) and [clients](/source/Client_(computing)) to store and retrieve [data](/source/Data) from multiple noncontiguous [databases](/source/Database) with a single [query](/source/Information_retrieval)—even if the constituent databases are [heterogeneous](/source/Heterogeneous). To this end, a federated database system must be able to decompose the query into subqueries for submission to the relevant constituent [DBMSs](/source/Database_management_system), after which the system must composite the [result sets](/source/Result_set) of the subqueries. Because various database management systems employ different [query languages](/source/Query_language), federated database systems can apply [wrappers](/source/Wrapper_function) to the subqueries to translate them into the appropriate [query languages](/source/Query_language).

## Definition

McLeod and Heimbigner[1] were among the first to define a federated database system in the mid-1980s.

A FDBS is one which "define[s] the architecture and interconnect[s] databases that minimize central authority yet support partial sharing and coordination among database systems".[1] This description might not accurately reflect the McLeod/Heimbigner[1] definition of a federated database. Rather, this description fits what McLeod/Heimbigner called a *composite* database. McLeod/Heimbigner's federated database is a collection of autonomous components that make their data available to other members of the federation through the publication of an export schema and access operations; there is no unified, central schema that encompasses the information available from the members of the federation.

Among other surveys,[2] practitioners define a Federated Database as a collection of cooperating component systems which are autonomous and are possibly [heterogeneous](/source/Heterogeneous_Database_System).

The three important components of an FDBS are autonomy, [heterogeneity](/source/Heterogeneous_Database_System) and distribution.[2] Another dimension which has also been considered is the Networking Environment [Computer Network](/source/Computer_Network), e.g., many DBSs over a [LAN](/source/Local_area_network) or many DBSs over a [WAN](/source/Wide_area_network) update related functions of participating DBSs (e.g., no updates, nonatomic transitions, [atomic updates](/source/Atomicity_(database_systems))).

## FDBS architecture

A [DBMS](/source/Database_management_system) can be classified as either centralized or distributed. A centralized system manages a single database while distributed manages multiple databases. A component [DBS](/source/Database) in a DBMS may be centralized or distributed. A multiple DBS (MDBS) can be classified into two types depending on the autonomy of the component DBS as federated and non federated. A nonfederated database system is an integration of component [DBMS](/source/Database_management_system) that are not autonomous. A federated database system consists of component [DBS](/source/Database) that are autonomous yet participate in a federation to allow partial and controlled sharing of their data.

Federated architectures differ based on levels of integration with the component database systems and the extent of services offered by the federation. A FDBS can be categorized as loosely or tightly coupled systems.

- Loosely Coupled require component databases to construct their own federated [schema](/source/Database_schema). A user will typically access other component database systems by using a multidatabase language but this removes any levels of location transparency, forcing the user to have direct knowledge of the federated schema. A user imports the data they require from other component databases and integrates it with their own to form a federated schema.

- Tightly coupled system consists of component systems that use independent processes to construct and publicize an integrated federated schema.

Multiple DBS of which FDBS are a specific type can be characterized along three dimensions: Distribution, Heterogeneity and Autonomy. Another characterization could be based on the dimension of networking, for example single databases or multiple databases in a LAN or WAN.

### 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 article: [Heterogeneous database system](/source/Heterogeneous_database_system)

Heterogeneities in databases arise due to factors such as differences in structures, semantics of data, the constraints supported or [query language](/source/Query_language). Differences in structure occur when two [data models](/source/Data_model) provide different primitives such as [object oriented (OO) models](/source/Object-Oriented_Modeling) that support specialization and inheritance and [relational models](/source/Relational_model) that do not. Differences due to constraints occur when two models support two different constraints. For example, the set type in [CODASYL](/source/CODASYL) [schema](/source/Database_schema) may be partially modeled as a referential integrity constraint in a relationship schema. [CODASYL](/source/CODASYL) supports insertion and retention that are not captured by referential integrity alone. The query language supported by one [DBMS](/source/Database_management_system) can also contribute to [heterogeneity](/source/Heterogeneous_Database_System) between other component [DBMSs](/source/Database_management_system). For example, differences in query languages with the same [data models](/source/Data_model) or different versions of query languages could contribute to [heterogeneity](/source/Heterogeneous_Database_System).

Semantic heterogeneities arise when there is a disagreement about meaning, interpretation or intended use of [data](/source/Data). At the schema and data level, classification of possible heterogeneities include:

- Naming conflicts e.g. [databases](/source/Database) using different names to represent the same concept.

- Domain conflicts or [data](/source/Data) representation conflicts e.g. [databases](/source/Database) using different values to represent same concept.

- Precision conflicts e.g. [databases](/source/Database) using same data values from domains of different [cardinalities](/source/Cardinality) for same [data](/source/Data).

- [Metadata](/source/Metadata) conflicts e.g. same concepts are represented at [schema](/source/Database_schema) level and instance level.

- [Data](/source/Data) conflicts e.g. missing [attributes](/source/Attribute_(computing))

- [Schema](/source/Database_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](/source/Semantic_equivalence), but differently named parts from different [schemas](/source/Logical_schema) (=data models) (tables, attributes). A pairwise mapping between *n* attributes would result in n ( n − 1 ) 2 {\displaystyle n(n-1) \over 2} 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](/source/Database_view). Two principal approaches depend on the direction of the mapping:

1. Global as View (GaV): the global schema is defined in terms of the underlying schemas

1. Local as View (LaV): the local schemas are defined in terms of the global schema

Both are examples of [data integration](/source/Data_integration), called the [schema matching](/source/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](/source/Heterogeneous_Database_System) in an FDBS are primarily due to design autonomy.

- Communication autonomy refers to the general operation of the DBMS to communicate with other [DBMS](/source/Database_management_system) or not.

- Execution autonomy allows a component DBMS to control the operations requested by local and external operations.

- Association autonomy gives a power to component DBS to disassociate itself from a federation which means FDBS can operate independently of any single [DBS](/source/Database).

The ANSI/X3/SPARC Study Group outlined a three level data description architecture, the components of which are the conceptual schema, internal schema and external schema of databases. The three level architecture is however inadequate to describing the architectures of an FDBS. It was therefore extended to support the three dimensions of the FDBS namely Distribution, Autonomy and Heterogeneity. The five level schema architecture is explained below.

### Concurrency control

The *Heterogeneity* and *Autonomy* requirements pose special challenges concerning [concurrency control](/source/Concurrency_control) in an FDBS, which is crucial for the correct execution of its concurrent [transactions](/source/Database_transaction) (see also [Global concurrency control](/source/Global_concurrency_control)). Achieving [global serializability](/source/Global_serializability), the major correctness criterion, under these requirements has been characterized as very difficult and unsolved.[2]

## Five level schema architecture for FDBSs

The five level schema architecture includes the following:

- Local Schema is basically the conceptual model of a component database expressed in a native data model.[3]

- Component schema is the subset of the local schema that the owner organisation is willing to share with other users of the FDBS and it is translated into a [common data model](/source/Common_data_model).[3]

- Export Schema represents a subset of a component schema that is available to a particular federation.[3] It may include access control information regarding its use by a specific federation user. The export schema helps in managing flow of control of data.

- Federated Schema is an integration of multiple export schemas. It includes information on data distribution that is generated when integrating export schemas.[3]

- External schema is extracted from a federated schema, and is defined for the users/applications of a particular federation.[3]

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. Modern data users demand control over how data is presented; their needs are somewhat in conflict with such bottom-up approaches to data integration.

## See also

- [Enterprise Information Integration](/source/Enterprise_Information_Integration) (EII)

- [Data virtualization](/source/Data_virtualization)

- [Master data management](/source/Master_data_management) (MDM)

- [Schema matching](/source/Schema_matching)

- [Universal relation assumption](/source/Universal_relation_assumption)

- [Linked data](/source/Linked_data)

- [SPARQL](/source/SPARQL)

## References

1. ^ [***a***](#cite_ref-reftwo_1-0) [***b***](#cite_ref-reftwo_1-1) [***c***](#cite_ref-reftwo_1-2) "McLeod and Heimbigner (1985). ["A Federated Architecture for information management"](http://dl.acm.org/citation.cfm?id=4233). *ACM Transactions on Information Systems, Volume 3, Issue 3*. pp. 253–278.

1. ^ [***a***](#cite_ref-refone_2-0) [***b***](#cite_ref-refone_2-1) [***c***](#cite_ref-refone_2-2) "Sheth and Larson (1990). ["Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases"](http://dl.acm.org/citation.cfm?id=96604). *ACM Computing Surveys, Vol. 22, No.3*. pp. 183–236.

1. ^ [***a***](#cite_ref-:0_3-0) [***b***](#cite_ref-:0_3-1) [***c***](#cite_ref-:0_3-2) [***d***](#cite_ref-:0_3-3) [***e***](#cite_ref-:0_3-4) Masood, Nayyer; Eaglestone, Barry (December 2003). ["Component and Federation Concept Models in a Federated Database System"](https://web.archive.org/web/20160307213657/http://majlis.fsktm.um.edu.my/document.aspx?FileName=268.pdf) (PDF). *Malaysian Journal of Computer Science*. **16** (2): 47–57. Archived from [the original](http://majlis.fsktm.um.edu.my/document.aspx?FileName=268.pdf) (PDF) on 2016-03-07. Retrieved 2016-03-03.

## External links

- [DB2 and Federated Databases](http://www.ibm.com/developerworks/db2/library/techarticle/dm-0504zikopoulos/)

- [Issues of where to perform the join aka "pushdown" and other performance characteristics](http://www.ibm.com/developerworks/db2/library/techarticle/0304lurie/0304lurie.html)

- [Worked example federating Oracle, Informix, DB2, and Excel](http://www.ibm.com/developerworks/db2/library/techarticle/0307lurie/0307lurie.html)

- Freitas, André, Edward Curry, João Gabriel Oliveira, and Sean O’Riain. 2012. [“Querying Heterogeneous Datasets on the Linked Data Web: Challenges, Approaches, and Trends.”](http://www.edwardcurry.org/publications/freitas_IC_12.pdf) IEEE Internet Computing 16 (1): 24–33.

- [IBM Gaian Database: A dynamic Distributed Federated Database](https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=f6ce657b-f385-43b2-8350-458e6e4a344f)

- [Federated system and methods and mechanisms of implementing and using such a system](https://patents.google.com/patent/US7392255)

v t e Database management systems Types Object-oriented comparison Relational list comparison Key–value Column-oriented list Document-oriented Wide-column store Graph NoSQL NewSQL In-memory list Multi-model comparison Cloud Blockchain-based database Concepts Database ACID Armstrong's axioms Codd's 12 rules CAP theorem CRUD Null Candidate key Foreign key PACELC design principle Superkey Surrogate key Unique key Objects Relation table column row View Transaction Transaction log Trigger Index Stored procedure Cursor Partition Components Concurrency control Data dictionary JDBC XQJ ODBC Query language Query optimizer Query rewriting system Query plan Functions Administration Query optimization Replication Sharding Related topics Database models Database normalization Database storage Distributed database Federated database system Referential integrity Relational algebra Relational calculus Relational model Object–relational database Transaction processing List of SQL software and tools Category Outline

---
Adapted from the Wikipedia article [Federated database system](https://en.wikipedia.org/wiki/Federated_database_system) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/Federated_database_system?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.