What are the differences between centralized and distributed DBMS?

Sudipto Chattopadhyay

Discuss the distinction between centralized and decentralized conceptual database design:.

Centralized and decentralized design constitute variations on the bottom‑up and top‑down approaches we discussed in the third question presented in the discussion focus. Basically, the centralized approach is best suited to relatively small and simple databases that lend themselves well to a bird's‑eye view of the entire database. Such databases may be designed by a single person or by a small and informally constituted design team. The company operations and the scope of its problems are sufficiently limited to enable the designer(s) to perform all of the necessary database design tasks:

1. Define the problem(s).

2. Create the conceptual design.

3. Verify the conceptual design with all user views.

4. Define all system processes and data constraints.

5. Assure that the database design will comply with all achievable end user requirements.

The centralized design procedure thus yields the design summary shown in Figure Q6.6A.

Figure Q6.6A The Centralized Design Procedure

Note that the centralized design approach requires the completion and validation of a single conceptual design.

Note: Figures 6.15 and 6.16 contrast the two design approaches, Figure 6.6 shows the procedure flows; demonstrate that such procedure flows are independent of the degree of centralization.

In contrast, when company operations are spread across multiple operational sites or when the database has multiple entities that are subject to complex relations, the best approach is often based on the decentralized design.

Typically, a decentralized design requires that the design task be divided into multiple modules, each one of which is assigned to a design team. The design team activities are coordinated by the lead designer, who must aggregate the design teams' efforts.

Since each team focuses on modeling a subset of the system, the definition of boundaries and the interrelation between data subsets must be very precise. Each team creates a conceptual data model corresponding to the subset being modeled. Each conceptual model is then verified individually against the user views, processes, and constraints for each of the modules. After the verification process has been completed, all modules are integrated in one conceptual model.

Since the data dictionary describes the characteristics of all the objects within the conceptual data model, it plays a vital role in the integration process. Naturally, after the subsets have been aggregated into a larger conceptual model, the lead designer must verify that the combined conceptual model is still able to support all the required transactions. Thus the decentralized design activities may be summarized as shown in Figure Q6.6B.

Figure Q6.6B The Decentralized Design Procedure

Keep in mind that the aggregation process requires the lead designer to assemble a single model in which various aggregation problems must be addressed:

¨ synonyms and homonyms. Different departments may know the same object by differentnames (synonyms), or they may use the samename to address differentobjects(homonyms.) The object may be an entity, an attribute, or a relationship.

¨ entity and entity subclasses. An entity subset may be viewed as a separate entity by one or more departments. The designer must integrate such subclasses into a higher‑level entity.

¨ Conflicting object definitions. Attributes may be recorded as different types (character, numeric), or different domains may be defined for the same attribute. Constraint definitions, too, may vary. The designer must remove such conflicts from the model.