Heterogeneous database/federated database/Multi database
Heterogeneous Distributed Databases
A system might be considered heterogeneous when it has different operating system at each site, and different DBMS at each site.
A system in which each server is autonomous and centralized DBMS that has its own local users is referred to as HDMS.
The term Federated Database system or in short FDS is basically used when there is some global view or schema of the Federation of the database which is basically shared by the application.
Reference Architecture
Its properties are −
- Different sites use dissimilar schemas and software.
- The system may be composed of a variety of DBMSs like –
- relational,
- network,
- hierarchical
- object oriented
- Query processing is complex due to dissimilar schemas.
- Transaction processing is complex due to dissimilar software.
- A site may not be aware of other sites and so there is limited co-operation in processing user requests.
Types of Heterogeneous Distributed Databases
- Federated − The heterogeneous database systems are independent in nature and integrated together so that they function as a single database system.
- Un-federated − The database systems employ a central coordinating module through which the databases are accessed.
For instance,
a bank may use a federated database in which transactions are split by year. Users will often only look at transactions in the past year and the system will only need to touch one or two component databases.
On the other hand, splitting the databases by customer ID isn’t likely to work well; a given set of transactions will involve a random distribution of customer IDs, meaning that the query will be sent out to many, or potentially all, of the component databases.
This eliminates the benefit of the federated database — nearly all of the rows end up being searched — and will only increase the query’s overall latency because of the query redirects.
Issues in heterogeneous DBMS –
In heterogeneous FDBMS one server may be network DBMS another an object DBMS and a third a relational or hierarchical DBMS in such cases we may need to have canonical language system and which include language translators to translate subqueries from the canonical language to the language of the server.
The type of heterogeneity present in FDBMS may arise basically from several sources.
Following types of Heterogeneity or Issues will occur in FDBMS.
- Differences in data model –
In an organization, we may have different types of the data model for databases such as relational, file, object data model and modeling capabilities of these models vary from one another.
Hence to deal with them uniformly in a single language is too challenging. Hence Difference in the data model is the basic issue in FDBMS.
- Difference in Constraints –
Constraints facilities and its implementation vary from one system to another.
There are basically comparable features that must be reconciled in the basic construction of global schema. And this global schema also has to deal with potential conflicts among constraints.
For example, the relationship from the ER model is represented as referential integrity constraint in the relational model.
- Difference in Query Language –
For the same data model, we have so many languages and their version also varies.
For example, even in SQL, we have so many versions such as SQL-89, SQL-92 and SQL-99 and these versions have their own set of data types, comparison operators, and strings manipulation and so on.
- Difference in Operating System –
In a heterogeneous distributed database, different sites have different operating systems, DBMS products and data models. All these create further challenges while accessing FDMS.
Federated databases have several drawbacks-
( according to Hilary Cotter, a SQL Server consultant and Microsoft MVP)
Each component database is a potential point of failure, and latency from any one server will delay the entire call.
Your clients will have to program either the federated database or its calling applications to handle potentially incomplete query results, in case one or more of the component databases times out.
They’ll also have to manage each component database and keep it up to date, increasing maintenance costs.