Ddbms Unit 4

MCA 325, Distributed DBMS And Object Oriented Databases
Distributed Database
Management
g
System
y
UNIT-4
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63,By Shivendra Goel.
U4.1
Learning Objective
Heterogeneous databasefederated database, reference architecture,
loosely and tightly coupled,
Alternative architectures, Development tasks,
operation global task management.
Client server databases
SQL server,
Open database connectivity,
Constructing an Application.
U4.2
Heterogeneous Distributed Database

Definition: Composed of heterogeneous
hardware, operating system database
management system and applications.
Provides logically integrated view of existing
heterogeneous distributed databases.
databases
The
three-level
architecture
of
a
Heterogeneous Distributed Database System
(HDDMS)
U4.3
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Shivendra Goel
U4.1
Heterogeneous Distributed Database

User
User
External
Schema 1
User
External
Schema 2
User
External
Schema 3
Conceptual
Schema
Internal
Schema
U4.4
Challenges posed by integrating distributed databases
Data
management
system
(different
vendors)
Data Models (i.e. relational, text indexing,
object)
Query the transaction processing algorithms
Data types (i.e., text graphics, multimedia,
hypermedia)
Format (i.e. Structured, unstructured)
Semantics
U4.5
Challenges posed by integrating distributed databases Cont...
In a heterogeneous database (HDD), the

local database is not managed by the same
distributed database management system.
Federated Database:
A
combination
bi ti
off
autonomous,
t
heterogeneous databases that are
operating together
U4.6
U4.2
Federated Databases
Definition
Why do we need database federation
Problem with federated database
How does database federation work
Reference Architecture
U4.7
Definition
A collection of databases that are treated as
one entity and viewed through a single user
interface.
A federated database system
y
integrates
g
heterogeneous,
autonomous
database
systems, whereby both local applications and
global applications accessing multiple
component database systems are supported.
U4.8
Federated Databases
Such a federated database system is a
complex system of systems which requires a
well designed organization at the software
architecture level.
U4.9
U4.3
Data Federation
Significant productivity gains are to be had if you
can work on all the different databases, including
selects, inserts, updates, and deletes as if all the
tables lived in a single database. Database
federation makes the tables look like they are all
in the same database.
If the
th volume
l
off queries
i is
i nott large,
l
and
d if they
th
can often can be satisfied with summary tables,
there is a huge productivity boost by eliminating
the need for a data mart and the corresponding
need to create a new server, move significant
quantities of data, and so on
U4.10
Problems
Organization of schemas in a schema
architecture Organize the management
and stewardship of the various data sets in
some
way
that
ensures
their
interoperability
interoperability.
U4.11
Federated Databases
The "federator" system operates on the
tables in the remote systems, the
"federatees".
The remote tables appear as virtual tables
in the "Federator" database.
Client application programs can perform
operations on the virtual tables in the
"Federator" database, but the real
persistent storage is in the remote
database.
U4.12
U4.4
Federated Databases Cont

Each "federatee" views the "federator" as just
another database client connection. The
"Federatee" is simply servicing client
requests for database operations.
The "federator"
federator needs client software to
access each remote database
U4.13
Members of federation
FEDERATOR
FEDERATEE 1
FEDERATEE 2
Figure 1
U4.14
Contract Interactions
We wish to consider how contracts written in
our framework can interact with one
another.
Before doing so, let us return to a more
intuitive level to see how contracts,
unconstrained by our framework, might
interact. Two contracts are in conflict when
one requires a certain action and the other
prohibits it.
U4.15
U4.5
The Basic Framework: Granting Rights

The heart of the federated database
problem is to be able to share certain data
between independent organizations without
giving up full control of that data.
Typically, one organization will permit
Typically
another organization certain accesses to its
data provided that the latter organization
agrees to full certain obligations.
U4.16
The Basic Framework: Granting Rights Cont
A problem that needs addressing is that

obligations imposed by various contracts
may conflict with one another. In the
following we present a framework that
eliminates potential conflicts between
obligations by eliminating the need for
obligations.
U4.17
In fact, we simply do not allow for

obligations in the framework. One might say
that there is only one global obligation,
namely, to abide by the framework. (We
also make the tacit assumption that an inter
organizational access privilege can only be
granted through a contract.) The desired
effect will be achieved partly by the
particulars of the contract and partly by the
general framework itself. We make no
attempt in this framework to address issues
of implementation or assurance.
U4.18
U4.6
Specially, we will not be concerned with

general mechanisms for guaranteeing that
all parties must abide by the contract,
though it will be possible for contracts to be
written so as to impose some checks and
balances toward this end.
U4.19
Reference Architecture
For federated database systems, the
traditional three-level database schema
architecture must be extended to support
the
dimensions
of
distribution
heterogeneity,
g
y and autonomy.
y
It provides the framework in which to
understand, categorize and compare
different architectural options for developing
specific systems.
U4.20
Reference Architecture Cont

Local Schema: A Local Schema is the
conceptual schema of a component database
system which is expressed in the (native) data
model of that component.
Component Schema: A Component Schema
is a Local Schema transformed into the
(canonical) data model of the federation layer.
U4.21
U4.7

Export Schema: An Export Schema is
derived from a Component Schema and
defines an interface to the local data that is
made available to the federation.
U4.22

Federated Schema: When Exported Schemas
are semantically heterogeneous, it is
necessary to integrate them using another
level. A Federated Schema on this higher
level is the result of the integration of multiple
E
Export
t Schemas;
S h
th
thus,
providing
idi an integrated
i t
t d
view.
U4.23

External Schema: An External Schema is a
specific view on a Federated Schema or on a
Local Schema. External Schemas may base
on a specific data model different from the
canonical data model. Basically,
y, External
Schemas serve as specific interfaces for
applications (local or global).
U4.24
U4.8
Points to be covered
Loosely & tightly coupled

Alternative architecture
Development tasks
Operation Global task management
U4.25
Heterogeneous Distributed Databases

Information
systems
that
provide
interoperation and varying degrees of
integration among multiple DBs are called.
Multi database systems or
Federated systems or
More generally, heterogeneous distributed
database systems (HDDBSs)
U4.26
Loosely coupled FDBSs

User creates and maintains federation schema,
Also called Interoperable Database System
Creating schema corresponds to creating a view
against relevant export schemas
Therefore,
Th f
each
h user mustt be
b aware off
information and structure of the export schemas
Hard to support view updates therefore,
assume highly autonomous read-only DBs
U4.27
U4.9
Loosely coupled FDBSs - Advantages

Flexibility of different interpretations possible
for same federated schema
Easier to cope with dynamic changes in
schemas since it is easier to create views.
Detection of changes is however expensive.
U4.28
Loosely coupled FDBSs - Disadvantages

Duplicated effort in creation of similar
federated schemas.
Difficulty in understanding the semantics of
schemas available to the user.
Due to possible multiple view creations,
view updating cannot be supported.
U4.29
Tightly coupled FDBSs

Aim: provide location, replication and
distribution transparency
Federation administrators have full control
over creation and maintenance of federated
schemas and access to other export
schemas
Single federated schema same as global
schema but view updates possible if
administrators understand the mappings.
U4.30
U4.10
Tightly coupled FDBSs Disadvantages

FDBS administrator and component DBSs
negotiate creation of export schemas
during which administrator. has complete
read access to component schema and/or
data Violates autonomy
data.
Change in export/component schemas
imply redoing federated schema creation.
U4.31
More on Federated Databases

System architecture - Core components
combined in different ways to produce
different data management architectures
Data: Data are the basic facts and
information managed by a DBS.
Database: A database is a repository of
data structured according to a data model.
Commands: Commands are requests for
specific actions that are either entered by
a user or generated by a processor.
U4.32
More on Federated Databases Cont

Processors: Processors are software
modules that manipulate commands and
data.
Schemas: Schemas are descriptions of
data managed by one or more DBMSs. A
schema
h
consists
i t off schema
h
objects
bj t and
d
their interrelationships.
Mappings: Mappings are functions that
correlate the schema objects in one
schema to the schema objects in another
schema.
U4.33
U4.11
Processors in a FDBS
Transforming P: Uses mappings to
transform
commands
from
internal
command language to local query
language etc.
Filtering P: Uses access control specified in
export schema to limit allowable operations
submitted to corresponding component
schemas
Constructing
P:
Performs
query
decomposition and merges data
U4.34
Multi database systems

Multiple databases created for the same
functionality
Different operating systems, data formats,
query languages etc
Typically DBs managed by DBMSs running
on heterogeneous computing platforms
U4.35
Multi database systems Cont
Information sharing across dissimilar

platforms
Interconnect previously isolated
software systems (DBMS)
Not only invoke but also
coordinate interactions
U4.36
U4.12

Multidatabase has been classified according
to the following criteria:
1. Distribution:
* Data can be placed in many distributed
databases.
* Databases can be found in the same or
different computer systems.
U4.37

2. Heterogeneity:
* This is found in the differences in
technology i.e., software, hardware, and
operating system.
* The two types of heterogeneity are those
that are due to:
* differences in various DBMSs
* differences in data semantics
U4.38

3. Autonomy:
A component database can have the following
autonomies:
Design Autonomy :Choice of data
presentation and attributes.
Communication Autonomy : ability to
decide on its own when to communicate with
other components of the federated database
system.
U4.39
U4.13

Execution Autonomy: ability to execute
some of its operations locally without
influence by external operations that are
executed in other component databases
or in the federation database system.
y
U4.40
Architectural Alternatives (1)

Autonomy (A)
A0: Tight integration
A1: Semi-autonomous
A2: Total isolation
Distribution (D)
D0: Non-distributed
D1: Client Server
D2: Peer-to-peer
Heterogeneity (H)
H0: Homogeneous
H1: Heterogeneous
Distribution
(A2. D2, H1)
Autonomy
(A0. D0, H0)
Heterogeneity
U4.41

(A0, D0, H0)
A collection of logically integrated
DBMSs on the same site, also called
Composite Systems
(A0, D0, H1)
Providing
integrated
access
to
heterogeneous systems on a single
machine
U4.42
U4.14

(A0, D1, H0)
Client Server distribution
(A0, D2, H0)
Fully distributed
(A1, D0, H0)
Semi-autonomous systems, also called
Federated Systems. Each DBMS knows
how to participate in the federation
U4.43

(A1, D0, H1)
Heterogeneous Federated DBMSs.
(A1, D1, H1)
Distributed Heterogeneous Federated
DBMSs
(A2, D0, H0)
Multi-database
Systems.
Complete
homogeneity in component systems is
unlikely
U4.44

(A2, D0, H1)
Heterogeneous Multi-databases. Similar
to (A1, D0, H1), but with full autonomy
(A2, D1, H1), (A2, D2, H1)
Distributed Multi-database Systems
U4.45
U4.15
Major DBMS Architectures (6)

(Ax, D1, Hy)
Client Server Architecture
(A0, D2, H0)
Peer-to-peer Architecture
(A2, Dx, Hy)
Multi-database Architecture
U4.46
Challenges posed by integrating HDDBS

Data management system (different
vendors)
Data Models (i.e. relational, text indexing,
object)
Query
the
transaction
processing
algorithms
Data types (i.e., text graphics, multimedia,
hypermedia)
Format (i.e. Structured, unstructured)
Heterogeneity in Semantics
U4.47
Challenges posed by integrating HDDBS Cont...
Typical Heterogeneous databases include:

World Wide Web
Multimedia
Preservation of the databases autonomy is
paramount.
Data access facilities in Heterogeneous
U4.48
U4.16
Challenges posed by integrating HDDBS Cont...
Database Systems can range from:

browsing across component databases
querying a centralised data warehouse
querying multiple databases.
A heterogeneous database system can be
provided with a multi-database query
language.
U4.49
Problems in Integrating Heterogeneous Databases
Semantic Heterogeneity (Different Database

designers represent the same object in different
ways.) e.g.
Synonyms - same entity different names
Homonyms - different entities same
names
U4.50
Problems in Integrating Heterogeneous Databases Cont...
Description Heterogeneity
(Different characteristics are used to describe
the same object)
M
Model
d l Heterogeneity
H t
it
(Use of different models to represent the
same data e.g. SSADM, E-R Diagram, Use
Cases)
U4.51
U4.17
Global Schema Integration

Based on complete integration to provide a
single view
Advantages:
Consistent, uniform view of and access to
d t for
data
f users
Users unaware of existing multiple
existing DBs
U4.52
Global Schema Integration Cont

Disadvantages
Hard to automate creation of a global
schema:
structural,
semantic
or
behavioral conflicts
Autonomy esp.
esp association autonomy
sacrificed: all local data and operations to
be revealed
U4.53
Global Schema Integration Cont

Loss of semantic information depending on
how the schema integration is performed
Correctness of global schema is hard to
prove: hard because of context dependent
meanings
U4.54
U4.18
Acronyms Used
GES : global external schema

GCS : global conceptual schema
LES : local external schema
LCS : local conceptual
p
schema
LIS : local internal schema
U4.55
Client Server Architectures

Distribute the functionality between client and server
to better manage the complexity of the DBMS
Two-level Architecture
User
Typical Scenario
1.Client parses a query, decomposes into
independent site queries, and sends to
appropriate server
2.Each server processes local query and sends
the result relation to client
3.Client combines the results of sub-queries
Client
Response
Request
Server
U4.56
Peer-to-peer Arch.
A type of network in which each workstation
has
equivalent
capabilities
and
responsibilities.
This differs from client/server architectures,
in which some computers
p
are dedicated to
serving the others.
Peer-to-peer networks are generally simpler,
but they usually do not offer the same
performance under heavy loads.
U4.57
U4.19
Open Database Connectivity
Created Late 80s

Uniform interface to write client s/w
for relational dbs
Popular
P
l - accepted
t d as standard
t d d for
f
relational database
Single API for client application to
work with different dbs.
U4.58
ODBC API (The Interface)

Applications using ODBC API can
communicate with any relational db
for which there is an ODBC driver
Compared to other db interfaces it is a low
level
l
l interface
i t f
Enables client application to
configure and
control the relational database at a
relatively low level
U4.59
ODBC - Limitations
Limited to relational dbs
Due to relational nature, difficult to use for
non-relational data sources, such as
Object dbs
non-relational dbs
network directory services
email stores
etc
U4.60
U4.20
ODBC - Provides
ODBC Driver Manager (ODBC32.DLL)
Calls functions in the ODBC drivers (DLLs)
to perform operations on the database
Import Library (ODBC32.LIB)
Client applications link to it to use functions
exposed by the ODBC driver manager
ODBC header files for the ODBC API
U4.61
ODBC Architecture
ODBC Drivers
Client
Application
Code
RDBMS
Database
Server
ODBC
Driver
Manager
Host
System
ODBC32.DLL
ISAM
Files
U4.62
SQL Server
Introduction
Transact Sql
History
Releases
Description
Future Developments
Working
U4.63
U4.21
Microsoft SQL Server

Microsoft SQL Server is a relational database
management system (RDBMS) produced by
Microsoft.
Its primary query language is Transact-SQL,
an implementation of the ANSI/ISO standard
Structured Query Language (SQL) used by
both Microsoft and Sybase.
SQL Server is commonly used by businesses
for small- to medium-sized databases, but the
past five years have seen greater adoption of
the product for larger enterprise databases.
U4.64
Transact-SQL
Transact-SQL is an extension to the SQL
database programming language.
It is a powerful language offering many
features
A wide variety of data types
Temporary objects
System and extended stored procedures
U4.65
Transact-SQL Cont
Scrollable cursors,
Conditional processing,
Transaction control,
Exception and error handling, and much
more
U4.66
U4.22
History
Microsoft,
Sybase
and
Ashton-Tate
originally teamed up to create and market
the first version named SQL Server 1.0 for
OS/2 (about 1989) which was essentially the
same as Sybase SQL Server 3.0 on Unix,
VMS etc.
VMS,
t
Microsoft SQL Server 4.2 was shipped
around 1992 (available bundled with
Microsoft OS/2 version 1.3). Later Microsoft
SQL Server 4.21 for Windows NT was
released .
U4.67
History Cont
Microsoft SQL Server v6.0 was the first
version of SQL Server that was
architected for NT and did not include
any direction from Sybase.
Later, Sybase changed the name of its
product to Adaptive Server Enterprise
U4.68
History Cont
SQL Server 7.0 was the first true GUI based
database server .
The current version, Microsoft SQL Server
2005, was released in November of 2005.
Advancements have been made in
performance,
the client IDE tools, and
U4.69
U4.23
History Cont
several complementary systems that are
packaged with SQL Server 2005. These include:
an ETL tool (SQL Server Integration
Services or SSIS),
a Reporting Server,
an OLAP and data mining server (Analysis
Services), and
several messaging technologies, specifically
Service Broker and Notification Services.
U4.70
Releases
1993 - SQL Server 4.21 for Windows NT

1995 - SQL Server 6.0, codenamed SQL95
1996 - SQL Server 6.5, codenamed Hydra
1999 - SQL Server 7.0, codenamed Sphinx
1999 - SQL Server 7.0 OLAP, codenamed
Plato
U4.71
Releases Cont
2000 - SQL Server 2000 32-bit, codenamed
Shiloh (version 8.0)
2003 - SQL Server 2000 64-bit, codenamed
Liberty
2005 - SQL Server 2005,
2005 codenamed Yukon
(version 9.0)
U4.72
U4.24
Description
MS SQL Server uses a variant of SQL
called T-SQL, or Transact-SQL, an
implementation of SQL-92 with some
extensions.
T-SQL mainly
y adds additional syntax
y
for use
in stored procedures, and affects the syntax
of transaction support. (Note that SQL
standards require Atomic, Consistent,
Isolated, Durable or "ACID" transactions.)
U4.73
Description Cont
MS SQL Server and Sybase/ASE both
communicate over networks using an
application-level protocol called Tabular Data
Stream (TDS).
The TDS protocol has been implemented in
order to allow more kinds of client
applications to communicate with MS SQL
Server and Sybase databases.
MS SQL Server also supports Open
Database Connectivity (ODBC).
U4.74
Future development
According to Microsoft, future versions of SQL
Server aim to make data management
self-tuning,
self organizing,
self maintaining
with the introduction of SQL Server Always
On technologies, to provide near-zero
downtime.
U4.75
U4.25
Future development Cont

Microsoft also aims to intrinsically support
many digital data formats, including pictures,
audio, video and other multimedia data. In
current versions, such multimedia data can
be stored as BLOBs (binary large objects),
but they are generic bitstreams.
bitstreams Intrinsic
awareness of multimedia data will allow
specialized functions to be performed on
them.
Better support for unstructured and semistructured data is planned as well.
U4.76
What is Object Oriented Database? (OODB)
A database system that incorporates all the

important object-oriented concepts.
Some additional features
Unique Object identifiers
Persistent object handling
U4.77
Advantages of OODBS
Designer can specify the structure of objects and
their behavior (methods)
Better interaction with object-oriented languages
such as Java and C++
Definition of complex and user-defined types
Encapsulation of operations and user-defined
methods
U4.78
U4.26
Object Oriented Databases Disadvantages.
Lack of Industry Standards

RDBMS Popularity
U4.79
Spatial Databases
It had been state that approximately 75% to
80% of all the information contains some
notion of the location.
So
So, Spatial database system give the
concept of database that helps in keeping the
track of objects in multidimensional space.
U4.80
Spatial Databases Cont

A spatial database is also known as a database
that is used to store and querying data related to
the object in space like points, lines and polygons
etc.
While we can see that most of the data layer can
deals with various numeric and character data
types in order to implements spatial databases
some additional functionalities needs to added in
the database to add-on some geometry related
spatial data types.
U4.81
U4.27

A most common example for the spatial data we can see
in the map of road, in which we can see various spatial
objects along the 2-Dimension, some of these spatial
objects are points, line and polygons etc. these objects
some how can represents roads, cities, state boundaries
etc.
A road map is a classic example of spatial information.
The roads, cities, state boundaries reside on the piece of
paper in 2-D format. A GIS is used to retrieve, store and
manage the spatial data.
U4.82

Types of Queries supported by spatial Databases:
1. Spatial Scope-Distance Query.
2. Spatial Nearly Queries
3. Joins Queries.
U4.83
Multimedia Databases
Multimedia Database System(MMDBS) are created
in order to cope up with the growth in the usage of
huge volume of multimedia data that is used by
various applications such as journalism software
applications, e-retailing, entertainment and elibraries etc.
The multimedia data has the influence both directly
as well as indirectly in the development of
multimedia databases.
U4.84
U4.28
Multimedia Databases
Multimedia data bases are design in the various
similar manner that are highlighted by the classical
DDBMSs to give ease of use and understandability
to its user, along with the MMDBS provide some
additional features to its user.
These MMDBs are provide a frame work to store,
process, retrieve, present and transmit variety of
multimedia data-types in lot many formats
multimedia database support more new features as
compared to the traditional DBMSs.
U4.85
Multimedia Databases Cont...

Multimedia data characterize in images, video,
audio and text.
Moreover, MMDBSs are veryy necessaryy for the

efficient as well as effective management of large
amount of multimedia data.
U4.86
Deductive Databases
A deductive database is a database system that
can make deductions, these deductions are based
on some rules and facts that are stored in the
databases (deductive).
Prolog and Datalog are the languages that are
mainly used to specifies rules, facts and queries in
the deductive databases.
U4.87
U4.29
Deductive Databases Cont

Deductive data bases are based on the desire of
combining logic programming with the RDBMS to
made such a system that support powerful
calculation and also system can give very fast
response time and deals with large datasets.
Deductive database systems are far more.
more
U4.88
Deductive Databases Cont

Expensive than a RDBMS system but economical
against logic programming systems.
Now a days, Deductive database systems are
largely used in academics as compare to industries,
but lot many concepts of Deductive database
system are used in today's Relation Database
systems to give support to various new SQL
standards.
U4.89
Temporal Databases
Temporal database are created to store the
temporal data, it means data that is dependent on
time.
Temporal DBMS or TDBMS is created in order to
support the manipulation as well as maintenance of
the temporal data.
TDBMS provide the Temporal data model (TDM)
that comprises of TDDL (Temporal Data Definition
Language) and TDML (Temporal Data Manipulation
Language)
U4.90
U4.30
Temporal Databases Cont

Temporal database objects are defined using TDDL
while Temporal database are manipulated i.e.,
update, delete and retrieve etc. with the help of
TDML.
Further, it can be seen that some specific queries
related to the temporal data are very difficult to
express in term of simple SQL query, while
temporal DBMS give us a better support to
implements these specific queries, it may also be
possible to use SQL queries for these purpose but
again the performance factor is a big issue.
U4.91
Short Questions
Explain about the federated database give
any example ?
What is Open database connectivity?
Briefly describe the architecture of SQL
server?
Write some difference between
heterogeneous and homogenous DDBMS?
U4.92
Long Questions
Explain any one heterogeneous DDBMS ? What
are the problems that can occur in a
heterogeneous DDBMS.
Write Short notes on the following :
(a) Open Database Connectivity
(b) SQL Server Architecture
Discuss the loosely and tightly coupled
architectures of parallel and distributed systems.
What is federated database system? Explain its
features.
U4.93
U4.31
Long Questions
Difference between homogenous DDBMS
and heterogeneous DDBMS ? Give one
example in each case?
Explain client server
server database and peer to
peer architecture?
Explain reference architecture of federated
database ?
U4.94
References
1. S. Ceri, G. Pelagatti, Distributed Database: Principles
and Systems, McGraw Hill, New York, 1985.
2. M. Tamer Ozsu, Patrick Valduriez, Principles of
Distributed Databases System, Pearson, 2nd Ed.,
2009.
3 Mario Piattini,
3.
Piattini Advanced
Advanced Database Technology and
Design, Artech House, UK, 2000.
4. Shivendra Goel, Divya Goel, Distributed Database
Management System, Sun India Publications, 2009.
5. Chhanda Ray, Distributed Database System,
Pearson, 2009.
U4.95
U4.32

Ddbms Unit 4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ddbms Unit 4

Uploaded by

Copyright:

Available Formats

MCA 325, Distributed DBMS And Object Oriented Databases

Heterogeneous Distributed Database

MCA 325, Distributed DBMS And Object Oriented Databases

Heterogeneous Distributed Database

Challenges posed by integrating distributed databases

Challenges posed by integrating distributed databases Cont...

In a heterogeneous database (HDD), the

MCA 325, Distributed DBMS And Object Oriented Databases

MCA 325, Distributed DBMS And Object Oriented Databases

MCA 325, Distributed DBMS And Object Oriented Databases

Federated Databases Cont

MCA 325, Distributed DBMS And Object Oriented Databases

The Basic Framework: Granting Rights

The Basic Framework: Granting Rights Cont

A problem that needs addressing is that

The Basic Framework: Granting Rights Cont

In fact, we simply do not allow for

MCA 325, Distributed DBMS And Object Oriented Databases

The Basic Framework: Granting Rights Cont

Specially, we will not be concerned with

Reference Architecture Cont

MCA 325, Distributed DBMS And Object Oriented Databases

Reference Architecture Cont

Reference Architecture Cont

Reference Architecture Cont

MCA 325, Distributed DBMS And Object Oriented Databases

Loosely & tightly coupled

Heterogeneous Distributed Databases

Loosely coupled FDBSs

MCA 325, Distributed DBMS And Object Oriented Databases

Loosely coupled FDBSs - Advantages

Loosely coupled FDBSs - Disadvantages

Tightly coupled FDBSs

MCA 325, Distributed DBMS And Object Oriented Databases

Tightly coupled FDBSs Disadvantages

More on Federated Databases

More on Federated Databases Cont

MCA 325, Distributed DBMS And Object Oriented Databases

Multi database systems

Multi database systems Cont

Information sharing across dissimilar

MCA 325, Distributed DBMS And Object Oriented Databases

Multi database systems Cont

Multi database systems Cont

Multi database systems Cont

MCA 325, Distributed DBMS And Object Oriented Databases

Multi database systems Cont

Architectural Alternatives (1)

(A2. D2, H1)

(A0. D0, H0)

Architectural Alternatives (2)

MCA 325, Distributed DBMS And Object Oriented Databases

Architectural Alternatives (3)

Architectural Alternatives (4)

Architectural Alternatives (5)

MCA 325, Distributed DBMS And Object Oriented Databases

Major DBMS Architectures (6)

Challenges posed by integrating HDDBS

Challenges posed by integrating HDDBS Cont...

Typical Heterogeneous databases include:

MCA 325, Distributed DBMS And Object Oriented Databases

Challenges posed by integrating HDDBS Cont...

Database Systems can range from:

Problems in Integrating Heterogeneous Databases