1.
Distributed Database System
A Distributed Database System (DDBS) is a collection of multiple
databases spread across different physical locations, connected via a
network. Unlike a centralized system, where all data is stored in one place,
a distributed system manages data across various sites while making it
appear as a single database to users. It improves data availability,
reliability, and performance by enabling local access, parallel processing,
and fault tolerance.
Distributed Database
Types
Some of the type of distributed database system are:
1. Homogeneous Database:
In a homogeneous database, all different sites store database identically.
The operating system, database management system, and the data
structures used all are the same at all sites. Hence, they're easy to
manage.
Features:
Unified query language and interface.
Low integration complexity.
Efficient synchronization.
Example: A bank with branches in different cities uses Oracle DB at every
location. All databases have the same structure and are synchronized
regularly.
2. Heterogeneous Database
In a heterogeneous distributed database, different sites may use different
DBMSs, schemas, or data models, making query processing and
transactions difficult. Some sites may not even be aware of others, so
translation mechanisms are needed for communication.
Features:
Supports interoperability between diverse systems.
Complex query optimization and transaction management.
Useful in mergers or collaborations between organizations.
Example: A logistics company uses MySQL for inventory, MongoDB for
vehicle tracking, and PostgreSQL for billing. Integration middleware allows
unified querying across these platforms.
3. Client-Server Distributed Database System
In this model, the server stores and manages the database, while clients
send queries over the network. It offers centralized control with
distributed access, making it ideal for enterprise systems and web
applications. Clients can be lightweight while the server handles heavy
processing. Example: Web application interacting with a central
PostgreSQL server.
Features:
Simplifies resource management.
Central servers can be optimized for performance.
Easily scalable with more clients.
Example: An e-commerce website where the frontend (client) is hosted
separately and interacts with a central PostgreSQL server to manage
orders, users, and inventory.
4. Peer-to-Peer Distributed Database System
Here, all nodes are equal, with no fixed client or server roles. Each node
can store data and also process queries, leading to decentralized control.
It supports fault tolerance and high availability. Example: Blockchain
networks like Ethereum, where each node maintains a part of the
distributed ledger.
Features:
No single point of failure.
Useful in decentralized and distributed apps.
High availability and data redundancy.
Example: Blockchain-based databases like Ethereum or BitTorrent-based
systems, where each peer maintains part of the ledger and participates
equally in transactions.
5. Cloud-Based Distributed Database System
These systems are deployed on cloud platforms and span multiple
geographic regions for scalability and reliability. They abstract
infrastructure details and are offered as DBaaS, making them ideal for
dynamic workloads. Example: Google Cloud Spanner and Amazon
DynamoDB used for global applications.
Features:
Automatic scaling and replication.
Pay-as-you-use pricing.
Global availability and disaster recovery.
Example:
Google Cloud Spanner: Global-scale relational database.
Amazon DynamoDB: Key-value and document database with high
performance.
Azure Cosmos DB: Multi-model, globally distributed DBMS.
key components and challenges of a Distributed Database
Now lets view definition of each key concept:
1. Replication
In replication, copies of the same data are stored at two or more sites. If
every site has the full database, it's called full replication. This improves
data availability and allows faster, parallel query processing. However,
updates must be made at all sites, or data may become inconsistent. It
also adds overhead and makes concurrency control more complex.
2. Fragmentation
In this approach, the relations are fragmented (i.e., they're divided into
smaller parts) and each of the fragments is stored in different sites where
they're required. It must be made sure that the fragments are such that
they can be used to reconstruct the original relation (i.e, there isn't any
loss of data).
Fragmentation is advantageous as it doesn't create copies of data,
consistency is not a problem.
Fragmentation of relations can be done in two ways:
Horizontal fragmentation - Splitting by rows
The relation is fragmented into groups of tuples so that each tuple is
assigned to at least one fragment.
Vertical fragmentation - Splitting by columns
The schema of the relation is divided into smaller schemas. Each
fragment must contain a common candidate key so as to ensure a
lossless join.
In certain cases, an approach that is hybrid of fragmentation and
replication is used.
3. Concurrency Control
Concurrency control ensures data remains accurate when multiple
transactions run at the same time. Without it, issues like lost updates or
dirty reads can occur. Its goal is to make parallel transactions behave as if
run one by one. Common methods include locking, timestamps, and
optimistic concurrency.
[Link] Heterogeneity
Semantic heterogeneity happens when different databases use the same
data labels but with different meanings, formats, or units. For example,
one system may store salary in dollars, another in rupees. This can cause
confusion during data integration, so resolving it is important for accurate
results.
Read more about Semantic Heterogenity
Functions of Distributed Database:
It is used in Corporate Management Information System.
It is used in multimedia applications.
Used in Military's control system, Hotel chains etc.
It is also used in manufacturing control system.
Read more about Functions of Distributed Database
Advantages of Distributed Database System :
There is fast data processing as several sites participate in request
processing.
Reliability and availability of this system is high.
It possess reduced operating cost.
It is easier to expand the system by adding more sites.
It has improved sharing ability and local autonomy.
Read more about Advantages of Distributed Database
Disadvantages of Distributed Database System :
The system becomes complex to manage and control.
The security issues must be carefully managed.
The security issues must be carefully managed.
The system require deadlock handling during the transaction
processing otherwise
The entire system may be in inconsistent state.
There is need of some standardization for processing of distributed
database
system.
Read related articles:
1. Federated database management system issues
2. Comparison – Centralized, Decentralized and Distributed
Systems
3. Multimedia Database
4. OODBMS - Definition and Overview
[Link] Type Definition - DTD
Last Updated : 06 Nov, 2020
DTD is a specification file used in XML (and SGML-family markup
languages) to define the structure and legal elements/attributes of
an XML document. It declares valid building blocks, ensuring
documents conform to a defined structure for validation purposes.
DTDs can be declared within the XML document or referenced
externally
A Document Type Definition (DTD) describes the tree structure of a
document and something about its data. It is a set of markup affirmations
that actually define a type of document for the SGML family, like GML,
SGML, HTML, XML.
A DTD can be declared inside an XML document as inline or as an external
recommendation. DTD determines how many times a node should appear,
and how their child nodes are ordered.
There are 2 data types, PCDATA and CDATA
PCDATA is parsed character data.
CDATA is character data, not usually parsed.
Syntax:
<!DOCTYPE element DTD identifier
first declaration
second declaration
nth declaration
]>
Example:
DTD for the above tree is:
XML document with an internal DTD:
<?xml version="1.0"?>
<!DOCTYPE address [
<!ELEMENT address (name, email, phone, birthday)>
<!ELEMENT name (first, last)>
<!ELEMENT first (#PCDATA)>
<!ELEMENT last (#PCDATA)>
<!ELEMENT email (#PCDATA)>
<!ELEMENT phone (#PCDATA)>
<!ELEMENT birthday (year, month, day)>
<!ELEMENT year (#PCDATA)>
<!ELEMENT month (#PCDATA)>
<!ELEMENT day (#PCDATA)>
]>
<address>
<name>
<first>Rohit</first>
<last>Sharma</last>
</name>
<email>sharmarohit@[Link]</email>
<phone>9876543210</phone>
<birthday>
<year>1987</year>
<month>June</month>
<day>23</day>
</birthday>
</address>
The DTD above is interpreted like this:
!DOCTYPE address defines that the root element of this document is
address.
!ELEMENT address defines that the address element must contain
four elements: "name, email, phone, birthday".
!ELEMENT name defines that the name element must contain two
elements: "first, last".
o !ELEMENT first defines the first element to be of type
"#PCDATA".
o !ELEMENT last defines the last element to be of type
"#PCDATA".
!ELEMENT email defines the email element to be of type "#PCDATA".
!ELEMENT phone defines the phone element to be of type
"#PCDATA".
!ELEMENT birthday defines that the birthday element must contain
three elements "year, month, day".
o !ELEMENT year defines the year element to be of type
"#PCDATA".
o !ELEMENT month defines the month element to be of type
"#PCDATA".
o !ELEMENT day defines the day element to be of type
"#PCDATA".
XML document with an external DTD:
<?xml version="1.0"?>
<!DOCTYPE address SYSTEM "[Link]">
<address>
<name>
<first>Rohit</first>
<last>Sharma</last>
</name>
<email>sharmarohit@[Link]</email>
<phone>9876543210</phone>
<birthday>
<year>1987</year>
<month>June</month>
<day>23</day>
</birthday>
</address>
[Link]:
<!ELEMENT address (name, email, phone, birthday)>
<!ELEMENT name (first, last)>
o <!ELEMENT first (#PCDATA)>
o <!ELEMENT last (#PCDATA)>
<!ELEMENT email (#PCDATA)>
<!ELEMENT phone (#PCDATA)>
<!ELEMENT birthday (year, month, day)>
o <!ELEMENT year (#PCDATA)>
o <!ELEMENT month (#PCDATA)>
o <!ELEMENT day (#PCDATA)>
Output:
3. Object Query Language (OQL)
Object Query Language (OQL) allows navigating complex object
relationships efficiently by using path expressions and object references.
Here is an illustrative example based on a database schema with objects
representing departments and employees:
Consider two object types: Department and Employee. An employee has a
reference to their department, and a department holds a list of references
to its employees.
1. Define the object types:
sql
CREATE TYPE dept_t AS OBJECT (
deptno NUMBER,
deptname VARCHAR2(20),
employees REF emp_t MULTISET
);
CREATE TYPE emp_t AS OBJECT (
empno NUMBER,
empname VARCHAR2(20),
deptref REF dept_t
);
2. Suppose we have instantiated these objects, and a department
object contains references to its employees.
3. To retrieve all employees in a specific department, say department
number 100 with employee names starting with 'John', an OQL
query might look like:
sql
SELECT [Link], [Link]
FROM dept d, TABLE([Link]) e
WHERE [Link] = 100 AND [Link] LIKE 'John%';
This query navigates from the dept object to its employees collection
(which is a nested table of references), unnesting it via TABLE() and
filtering based on employee name.
4. To find the department of a specific employee, you can dereference
the employee's deptref:
sql
SELECT [Link], [Link]
FROM emp_t e, dept_t d
WHERE DEREF([Link]).deptno = [Link] AND [Link] = 'John';
This shows direct navigation using references and dereferencing to access
related objects.
In summary, OQL uses path expressions and object references to traverse
and extract related object instances in complex relationships, making it
powerful for querying interconnected object data in object-oriented
[Link]+1
1. [Link]
adobj/[Link]
2. [Link]
OQL_11470/
3. [Link]
data_modeling/object_relationships
4. [Link]
[Link]
5. [Link]
6. [Link]
lectures/[Link]/oql/[Link]
7. [Link]
analysis/
8. [Link]