SQL Server

Distributed Databases with Client Server Architectures Part – 2

Distributed Databases with Client Server Architectures Part – 2

Benefits plus Drawbacks of Distributed Databases

The benefits of distributed database are as follows:-

• Matches distributed organizational prototype

• Upgraded independence as well as local independence

• Upgraded accessibility

• Upgraded trustworthiness

• Upgraded performance

• Economical

• Segmental development

The drawbacks of the distributed database are as follows:- Disadvantages

• Complication

• Value

• Safety

• Shortage of standards

• Truthfulness measures are harder

• Database design are bit more multifaceted

Information Division, Repetition, plus Allocation Methods for Distributed Database Design

In this part the methods which are used to break up the database into logical units are known as fragments and the same will be discussed in this part, which might be allocated for storing at the different sites. The use of data repetition part is also discussed over here, which authorize certain information to be kept in more than one (1) place, as well as the procedure of allotting fragments or replicas of fragments for storing at the different sites. These methods are used in the course of the procedure of distributed database design. The data regarding information division, allocation, and repetition is kept in a global directory which is retrieved by the Distributed Databases (DDB) applications as and when required.

Information Division

In a Distributed Databases (DDB), choices should be completed regarding which site must be castoff to stock which parts of the database. At this instant, an individual can assume that there is no repetition; that is, every single relation / table or a part of a relation / table is to be kept at only one (1) site. Repetition and its effects are discussed later in this part. The terminology of relational databases and alike concepts are used in other information models. An individual should start with a relational database schema as well as should decide on in what way to dispense the relations or tables over the several sites.


Employee

FName

MName

LName

EmpID

DOB

Address

Gender

Salary

ManagerID

DeptID

Department

DeptID

DeptName

ManagerID

StartDate

Department_Location

DeptID

DepLocation

Project

ProjectName

ProjectID

ProjectLocation

DepID

Works_ON

ID

ProjectID

Hours

Dependent

ID

DependentName

Gender

DOB

Relationship

Figure 1 Schema illustration for the COMPANY database schema.

To exemplify the discussion, the use of relational database schema in the above figure 1 can be done. Before an individual can decide on by what means to allocate the data, the individual should regulate the logical units of the database which need to be distributed. The artless logical units are the tables or relations themselves; which is every single full table or relation is to be kept at a specific site. In this instance, an individual should choose on which site to stock every single of the table or relations EMPLOYEE, DEPARTMENT, DEPARTMENT_LOCATION, PROJECT, WORKS_ON, and DEPENDENT of Figure 1. In various circumstances, however, a table or relation can be separated into minor logical units for distribution. For an instance, think through the company database as displayed in Figure 2, as well as assume there are three (3) computer sites one for every single department in the company," an individual may need to stock the database information concerning to every single department at the computer site for that department. A method known as horizontal fragmentation can make use of to partition every single relation or table by means of department.

Horizontal Fragmentation: – A horizontal fragment of a table or relation is a subset of the tuples or rows in that particular table or relation. The rows or tuples which belongs to the horizontal fragment are itemized by means of a condition on one (1) or more (N) columns or attributes of the table or relation. Frequently, a single attribute or columns is involved only. For an instance, an individual may describe multiple (N) horizontal fragments on the EMPLOYEE table or relation with the subsequent conditions: like depending on the primary key column or attribute for example (ManagerID = 4), (ManagerID = 7), (ManagerID = 6) every single fragment comprises the EMPLOYEE rows or tuples operational for a specific manager ID. Likewise, an individual may describe multiple (N) horizontal fragments for the PROJECT table or relation, with the conditions (DeptID = 3), (DeptID = 4), (DeptID = 2) every single fragment has the PROJECT rows or tuples maintained by means of a specific department. Horizontal fragmentation separates a table or relation "horizontally" by means of grouping tuples or rows to produce subsets of rows or tuples, where every single subset has a definite logical meaning. These fragments can then be allocated to dissimilar sites in the dispersed system. Resulting horizontal fragmentation applies the segregating of a primary relation or tables (DEPARTMENT in the example) to additional secondary relations or table (EMPLOYEE and PROJECT in the example), which are connected to the primary key via a foreign key. This way, connected data between the primary as well as the secondary tables or relations gets fragmented in the similar way.

In the upcoming part we will be going through Vertical Fragmentation and Mixed (Hybrid) Fragmentation.

Facebooktwittergoogle_plusredditpinterestlinkedinmail