Let's now review the set of organizational requirements which motivated the need for having distributed databases:
Dispersal and independence of organization units: Global organizations are spread across the continents, countries, and states as different divisions and departments, and each unit of the organization might perform its own business functioning. Hence, it is more certain that individual organization units want to maintain the information and functioning related to the regional organization unit in their local database to have better control and operational capacity within the location. With the trend of mergers and acquisitions, it is more common to integrate and split the database between the units more securely.
Information exchange: More often, the individual organization units need to generate regional information statistics and review specific instance-related information with the global leaders. They should be able to extract such business-critical information from the local organization unit database and share it with the leadership.
Secure information transmission: It is important to transmit the information between the remote databases in a secure and reliable channel through the communication network. It is also important to port the information with minimum costs in less time, and consider different mechanisms to ensure there is no data loss in information exchange. This is why taking regular backups of a database and keeping a copy of information shared for future comparison and records is a part of organizational database maintenance.
Communicating versatile DBMS: When an organization splits into multiple different organizations or when one organization takes over another organization, due to the regional software licensing constraints some organizations tend to maintain different DBMS across different organizational units. Also, applications developed over time tend to start with the latest available DBMS version within the same vendor DBMS. A distributed database should be defined in a way that it can operate based on the reference architecture model and independent of the vendor/application specifics.
Replication and Recovery: Computer systems can collapse anytime due to exceptions and vulnerabilities. It is important to recover the system to the most recent stable version in the minimum time when such an incident happens. Frequent database replication (copy) to another local/remote database is important, as you are able to backup from it during database corruption.
Data mining: It is the process of abstracting the most relevant information related to the criteria to be reviewed from the large set of data. It should be possible to mine both regional and global information as and when needed across the distributed database.
Location Transparency: An organization unit can have the users who need to have access to the information but only specific to a particular location. They should not be able to access/interact with the other location database.
Transaction Management: Some of the global decisions need to be incorporated in each of the organization units, together or in groups. Similarly, the information updated in a specific location can cause a few of the other organization units to get affected. Such kind of information updates should happen together in a single transaction across the distributed database.
Based on the preceding said business requirement, the distributed database can be designed in one of following discussed types.