Federated Database System Instance
A Federated Database System Instance is a distributed database system that is a heterogeneous database system with a meta-database management system that allows for transparent queries.
- Context:
- It can be based on a Federated DBMS Package.
- …
- Example(s):
- Counter-Example(s):
- See: Loosely-Coupled System, Computer Network, Data Abstraction, Heterogeneous System.
References
2016
- (Wikipedia, 2016) ⇒ https://en.wikipedia.org/wiki/federated_database_system Retrieved:2016-5-31.
- A federated database system is a type of meta-database management system (DBMS), 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 (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, 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 DBMSs, 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.
- A federated database system is a type of meta-database management system (DBMS), 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 (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.
- (Wikipedia, 2016) ⇒ https://en.wikipedia.org/wiki/federated_database_system#Definition Retrieved:2016-5-31.
- 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 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,[2] 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 (e.g., no updates, nonatomic transitions, atomic updates).
- McLeod and Heimbigner[1] were among the first to define a federated database system in the mid 1980s.
- (Wikipedia, 2016) ⇒ https://en.wikipedia.org/wiki/federated_database_system#Heterogeneity Retrieved:2016-5-31.
- 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 (OO) 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.
- 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 (OO) 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.