Distributed database

A distributed database is a database in which storage devices are not

all attached to a common processing unit such as the CPU,[1]
controlled by a distributed database management system (together
sometimes called a distributed database system). It may be stored in
multiple computers or may be dispersed over a network of
interconnected computers. Unlike parallel systems, in which the
processors are tightly coupled and constitute a single database system,
a distributed database system consists of loosely-coupled sites that
share no physical components.

System administrators can distribute collections of data (e.g. in a

database) across multiple physical locations. A distributed database
can reside on network servers on the Internet, on corporate intranets
or extranets, or on other company networks. Because they store data
across multiple computers, distributed databases can improve
performance at end-user worksites by allowing transactions to be
processed on many machines, instead of being limited to one.[2]

Two processes ensures that the distributed databases remain up-to-

date and current: replication and duplication.

1. Replication involves using specialized software that looks for

changes in the distributive database. Once the changes have
been identified, the replication process makes all the databases
look the same. The replication process can be complex and
time-consuming depending on the size and number of the
distributed databases. This process can also require a lot of time
and computer resources.
2. Duplication, on the other hand, has less complexity. It basically
identifies one database as a master and then duplicates that
database. The duplication process is normally done at a set time
after hours. This is to ensure that each distributed location has
the same data. In the duplication process, users may change only
the master database. This ensures that local data will not be
overwritten.

Both replication and duplication can keep the data current in all
distributive locations.[2]
Architecture[edit]

A database user accesses the distributed database through:

Local applications
applications which do not require data from other sites.
Global applications
applications which do require data from other sites.

Important considerations[edit]

Care with a distributed database must be taken to ensure the

following:

 The distribution is transparent — users must be able to interact

with the system as if it were one logical system. This applies to
the system's performance, and methods of access among other
things.
 Transactions are transparent — each transaction must maintain
database integrity across multiple databases. Transactions must
also be divided into sub-transactions, each sub-transaction
affecting one database system.

There are two principal approaches to store a relation r in a distributed

database system:

A) Replication
B) Fragmentation/Partitioning

A) Replication: In replication, the system maintains several identical

replicas of the same relation r in different sites.

 Data is more available in this scheme.

 Parallelism is increased when read request is served.
 Increases overhead on update operations as each site
containing the replica needed to be updated in order to
maintain consistency.
B) Fragmentation: The relation r is fragmented into several relations
r1, r2, r3....rn in such a way that the actual relation could be
reconstructed from the fragments and then the fragments are scattered
to different locations. There are basically two schemes of
fragmentation:

 Horizontal fragmentation - splits the relation by assigning

each tuple of r to one or more fragments.
 Vertical fragmentation - splits the relation by decomposing
the schema R of relation r.

Advantages[edit]

 Management of distributed data with different levels of

transparency like network transparency, fragmentation
transparency, replication transparency, etc.
 Increase reliability and availability
 Easier expansion
 Reflects organizational structure — database fragments
potentially stored within the departments they relate to
 Local autonomy or site autonomy — a department can control
the data about them (as they are the ones familiar with it)
 Protection of valuable data — if there were ever a catastrophic
event such as a fire, all of the data would not be in one place,
but distributed in multiple locations
 Improved performance — data is located near the site of greatest
demand, and the database systems themselves are parallelized,
allowing load on the databases to be balanced among servers. (A
high load on one module of the database won't affect other
modules of the database in a distributed database)
 Economics — it may cost less to create a network of smaller
computers with the power of a single large computer
 Modularity — systems can be modified, added and removed
from the distributed database without affecting other modules
(systems)
 Reliable transactions - due to replication of the database
 Distributed query processing can improve performance
 Single-site failure does not affect performance of system.
Disadvantages[edit]

 Complexity — DBAs may have to do extra work to ensure that

the distributed nature of the system is transparent. Extra work
must also be done to maintain multiple disparate systems,
instead of one big one. Extra database design work must also be
done to account for the disconnected nature of the database —
for example, joins become prohibitively expensive when
performed across multiple systems.
 Economics — increased complexity and a more extensive
infrastructure means extra labour costs
 Security — remote database fragments must be secured, and
they are not centralized so the remote sites must be secured as
well. The infrastructure must also be secured (for example, by
encrypting the network links between remote sites).
 Difficult to maintain integrity — but in a distributed database,
enforcing integrity over a network may require too much of the
network's resources to be feasible
 Inexperience — distributed databases are difficult to work with,
and in such a young field there is not much readily available
experience in "proper" practice
 Lack of standards — there are no tools or methodologies yet to
help users convert a centralized DBMS into a distributed
DBMS[citation needed]
 Database design more complex — In addition to traditional
database design challenges, the design of a distributed database
has to consider fragmentation of data, allocation of fragments to
specific sites and data replication
 Additional software is required
 Operating system should support distributed environment
 Concurrency control poses a major issue. It can be solved by
locking and timestamping.
 Distributed access to data
 Analysis of distributed data
Security and Integrity
 Integrity constraints ensure that changes made to the database
by authorized users do not result in loss of data consistency.
Domain Constraints
 A domain of possible values must be associated with every
attribute in the database.
 Declaring an attribute of a particular domain acts as a restraint
on the values it can take.
 They are easily tested by the system
 EX1: cannot set an integer variable to “cat”.

Referential Integrity

 Ensuring that a value that appears in one relation for a given

set of attributes also appears for a certain set of attributes in
another relation.
 EX1: In a banking system, the attribute branch-name in
Account-Schema is a foreign key referencing the primary key of
Branch-Schema.
 Inserting, deleting and updating can cause violations of
referential integrity.
 Therefore, the system must check that referential integrity is
maintained when you perform these operations.
 If referential integrity is violated during these operations, the
default action is to reject the operation.
 However, you can define other actions (more later).
 Foreign Keys are specified as part of the SQL ‘create table’
statement by using the ‘foreign key’ clause.
 By default, a foreign key reference the primary key attributes of
the referenced table.
  When referential integrity is violated during a modification,
instead of just rejecting the modification, you can cascade:
 Delete cascade - In a delete cascade, anything that has
references to the deleted item is also deleted.
 Update cascade - In an update cascade, when the
updated item results in a violation of referential integrity,
the system will update accordingly to fix the problem.
Security
 The information in your database is important. Therefore, you
need a way to protect it against unauthorized access, malicious
destruction or alteration, and accidental introduction of data
inconsistency
 Database Security refers to protection from malicious access.
 Absolute protection is impossible
 Therefore, make the cost to the perpetrator so high it will deter
most attempts.
 Some forms of malicious access:
 Unauthorized reading (theft) of data
 Unauthorized modification of data
 Unauthorized destruction of data
 To protect a database, we must take security measures at
several levels.
Security Levels
 Database System: Since some users may modify data while
some may only query, it is the job of the system to enforce
authorization rules.
 Operating System: No matter how secure the database system
is, the operating system may serve as another means of
unauthorized access.
 Network: Since most databases allow remote access, hardware
and software security is crucial.
 Physical: Sites with computer systems must be physically
secured against entry by intruders or terrorists.
 Human: Users must be authorized carefully to reduce the
chance of a user giving access to an intruder.
Authorization
  For security purposes, we may assign a user several forms of
authorization on parts of the databases which allow:
 Read: read tuples.
 Insert: insert new tuple, not modify existing tuples.
 Update: modification, not deletion, of tuples.
 Delete: deletion of tuples.
 We may assign the user all, none, or a combination of these.
 In addition to the previously mentioned, we may also assign a
user rights to modify the database schema:
 Index: allows creation and modification of indices.
 Resource: allows creation of new relations.
 Alteration: addition or deletion of attributes in a tuple.
 Drop: allows the deletion of relations.
 SQL standard includes the privileges:
 Delete
 Insert
 Select
 Update
 References: permits declaration of foreign keys.
 SQL includes commands to grant and revoke privileges.
 EX1: grant <privilege list> on <relation or view name> to <user>
 EX2: grant update (amount)on loan to U1, U3, U4
 By default, a user granted privileges is not allowed to grant
those privileges to other users.
 To allow this, we append the term “with grant option” clause to
the appropriate grant command.
 EX1: grant select on branch to U1 with grant option

Integrity: Conclusion
 It is essential to ensure that the data in a database is accurate.
 It is also important to protect the database from domain and
referential integrity violations.
 If the data is inaccurate or lacks integrity then the database
loses effectiveness!
Security: Conclusion
  We must also ensure that unauthorized users are prevented
from accessing or modifying our database.
 To do this, we implement authorization rules for users called
privileges.

The Security and Integrity of Data

 The security of data means the protection of data.

 Security involves protecting data and software from being:
 Lost losing disks, badly named
 Destroyed fire or flood, deletion
 Corrupted scratches on disk
 Modified written over, updated by mistake
 Disclosed unauthorised access
 Hacking means obtaining access to a computer system without
authority.
 It is now illegal. There are 3 main offences:
 Gaining unauthorised access
 Altering programs and data
 Gaining access to commit fraud
 A computer virus is a program which copies itself without the user
intending it to.
 They usually affect .exe files, can delete files on a hard disk.
 Macro viruses affect data in programs such as Word
 A backup file is a copy of a file which is kept in case anything
happens to the original file.
 Can be kept on a floppy or a different hard disk
 Can be kept on a backup data tape
 Archive files are kept in long term storage in case they are
required.
 Often from a back up data tape
 Physical safeguards for data include:
 Locking files in a fireproof safe
 To protect files being overwritten use the write protect tab
on disks & tapes
  Keeping unauthorised people from entering secure areas by
using locks and security passes etc.

The integrity of data means its accuracy and completeness.