Federated Database Management System Issues
A meta-database management system (DBMS) called a federated database system (FDBS) seamlessly converts numerous independent database systems into a single federated database. The component databases are geographically dispersed and connected by a computer network. A federated database system is preferable to the (often difficult) job of combining many different databases since the component database systems retain their autonomy. A federated database, also known as a virtual database, is made up of all the individual databases that make up the federated database system. As a result of data federation, there is no true data integration in the component independent databases. A system where every server is independent and uses a centralized DBMS with its own local users is called federated database. When there is a global view or schema of the Federation of the database that is essentially shared by the applications, the name Federated Database System, or FDS, is used. These systems combine elements of distributed and centralized architecture.
In the event that a federated database is made up of a heterogeneous group of databases, program can see data more consistently without having to replicate it across databases or run several queries and manually integrate the results. IBM Information Integration could be an excellent place to start if your clients are seeking for this kind of arrangement. Federated databases can assist in distributing the workload of extremely large databases in a homogenous environment (VLDBs). Each component database in this design has the same structure, but just a portion of the total number of records. Even though the constituent databases are diverse, federated database systems can offer a uniform user interface through data abstraction, allowing users and clients to store and retrieve data from several noncontiguous databases with a single query. To do this, a federated database system must be able to split the question into smaller queries that may be sent to the appropriate member DBMSs. The system must then combine the smaller queries' results. Federated database systems can apply wrappers to the sub queries to transform them into the proper query languages because different database management systems utilize different query languages.
Federated Database Component
Rows are allocated to a federated database's components according to a primary key when load distribution is employed. It takes skill to choose this key since it might be the difference between a successful and failed setting. The majority of queries?or all of them?should ultimately only access one component database. It takes skill to choose this key since it might be the difference between a successful and failed setting. The majority of queries?or all of them?should ultimately only access one component database.
An example would be a bank using a federated database where transactions are divided up by year. Users frequently only view transactions from the previous year, and only one or two component databases will need to be accessed by the system. A given set of transactions will entail a random distribution of customer IDs, therefore dividing the databases by customer ID is unlikely to be effective; as a result, the query will be sent to many, or even all, of the component databases. As a result, the federated database's advantages are lost (almost every entry is searched), and the query redirection just make the query's total latency worse.
According to SQL Server professional and Microsoft MVP Hilary Cotter, federated databases offer a number of disadvantages. Each component database is a possible single point of failure, and any one server's latency will cause the entire call to be delayed. In the event that one or more of the component databases times out, your customers will have to configure the federated database or its calling applications to handle potentially partial query results. Also, they'll have to monitor and update each component database, raising maintenance expenses.
Table partitioning in SQL Server 2005 is frequently a preferable option to database federation. Table partitioning solves this by scanning many segments of a single database rather than the totality of multiple databases, which is how partitions manage the splitting of a single big database into smaller portions based on a main key. In contrast to federated databases, which scale out, this one server must manage the whole database, hence updating it is known as "scaling up." Scaling up is frequently a better strategy than scaling out, but it has its limitations (a server can only be strengthened so much) and could need that your clients purchase pricey, high-end hardware rather than off-the-shelf servers.
Problems with DBMS