A federated database system is a type of meta-database management system, which transparently maps
multiple autonomous database systems into a single federated database. The constituent
databases are interconnected via a computer network and may be geographically decentralized.
Since the constituent database systems remain autonomous, a federated database system is
a contrastable alternative to the 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, federated database
systems can provide a uniform user interface, enabling users and clients to store and retrieve
data from multiple noncontiguous databases with a single query -- even if the constituent
databases are heterogeneous. To this end, a federated database system must be able to
decompose the query into subqueries for submission to the relevant constituent DBMS's, after
which the system must composite the result sets of the subqueries. Because various database
management systems employ different query languages, federated database systems can
apply wrappers to the subqueries to translate them into the appropriate query languages.
Definition McLeod and Heimbigner were among the first
to define a federated database system in the mid 1980's.
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".
This description might not accurately reflect the McLeod/Heimbigner definition of a federated
database. Rather, this description fits what McLeod/Heimbinger 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, practitioners define a Federated Database as a collection of cooperating
component systems which are autonomous and are possibly heterogeneous.
The three important components of an FDBS are autonomy, heterogeneity and distribution.
Another dimension which has also been considered is the Networking Environment Computer Network,
e.g., many DBSs over a LAN or many DBSs over a WAN update related functions of participating
DBSs. FDBS architecture
A DBMS can be classified as either centralized or distributed. A centralized system manages
a single database while distributed manages multiple databases. A component DBS in a DBMS
may be centralized or distributed. A multiple DBS 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 that are not autonomous. A federated database
system consists of component DBS 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. 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 DB 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
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 models provide different primitives such as object oriented models
that support specialization and inheritance and relational models that do not. Differences
due to constraints occur when two models support two different constraints. For example the
set type in CODASYL 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 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. A pairwise mapping between n attributes
would result in mapping rules - 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 solutions can
be realized, depending on the direction of the mapping:
Global as View: the global schema is defined in terms of the underlying schemas
Local as View: the local schemas are defined in terms of the global schema
Both are explained in more detail in the article Data integration. Alternate approaches to
the schema matching problem and a classification of the same are explained in more detail in
the article Schema Matching 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 the DBMS to communicate with other DBMS 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. The ANSISPARC 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 in an FDBS, which is crucial for the correct execution of its concurrent transactions.
Achieving global serializability, the major correctness criterion, under these requirements
has been characterized as very difficult and unsolved. Commitment ordering, introduced
in 1991, has provided a general solution for this issue.
Five Level Schema Architecture for FDBSs The five level schema architecture includes
the following: Local Schema is the conceptual concept [unclear]
expressed in primary data model of component DBMS.
Component Schema is derived by translating local schema into a model called the canonical
data model or common data model. They are useful when semantics missed in local schema
are incorporated in the component. They help in integration of data for tightly coupled
FDBS. Export Schema represents a subset of a component
schema that is available to the FDBS. It may include access control information regarding
its use by specific federation user. The export schema help in managing flow of control of
data. Federated Schema is an integration of multiple
export schema. It includes information on data distribution that is generated when integrating
export schemas. External Schema defines a schema for a user/applications
or a class of users/applications. 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 Data Virtualization
Master data management Schema Matching
Universal relation assumption Linked Data
SPARQL References
^ a b c "McLeod and Heimbigner. "ACM Transactions on Information Systems, Volume 3, Issue 3".
pp. 253–278. ^ a b c "Sheth and Larson. "ACM Computing
Surveys, Vol. 22, No.3". pp. 183–236. External links
Schema coordination in federated database management: a comparison with schema integration
Storage of Behaviour of Object Database DB2 and Federated Databases
Tutorial on Federated Database GaV and LaV explained
Issues of where to perform the join aka "pushdown" and other performance characteristics
Worked example federating Oracle, Informix, DB2, and Excel
Composite Information Server - a commercial federated database product
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.”
IEEE Internet Computing 16: 24–33. IBM Gaian Database: A dynamic Distributed
Federated Database Federated system and methods and mechanisms
of implementing and using such a system