Accredited ‘A’ Grade By NAAC

Subject: Database Management System

UNIT-VI
Advanced Databases
Database System Architectures
Centralized Systems
• Run on a single computer system and do not interact with other
computer systems.
• General-purpose computer system: one to a few CPUs and a
number of device controllers that are connected through a
common bus that provides access to shared memory.
• Single-user system: desk-top unit, single user, usually has only one
CPU and one or two hard disks; the OS may support only one user.
• Multi-user system: more disks, more memory, multiple CPUs, and a
multi-user OS. Serve a large number of users who are connected to
the system vie terminals. Often called server systems.
A Centralized Computer System
 Client-Server Systems
• Server systems satisfy requests generated at m client systems,
whose general structure is shown below:
 Client-Server Systems
• Database functionality can be divided into:
• Back-end: manages access structures, query evaluation and
optimization, concurrency control and recovery.
• Front-end: consists of tools such as forms, report-writers, and
graphical user interface facilities.
• The interface between the front-end and the back-end is through SQL
or through an application program interface.
Client-Server Systems
• Advantages of replacing mainframes with networks of
workstations or personal computers connected to back-end
server machines:
• better functionality for the cost
• flexibility in locating resources and expanding facilities
• better user interfaces
• easier maintenance
Server System Architecture
• Server systems can be broadly categorized into two kinds:
• transaction servers which are widely used in relational
database systems, and
• data servers, used in object-oriented database systems
Transaction Servers
• Also called query server systems or SQL server systems
• Clients send requests to the server
• Transactions are executed at the server
• Results are shipped back to the client.
• Requests are specified in SQL, and communicated to the server
through a remote procedure call (RPC) mechanism.
• Transactional RPC allows many RPC calls to form a transaction.
• Open Database Connectivity (ODBC) is a C language application
program interface standard from Microsoft for connecting to a
server, sending SQL requests, and receiving results.
• JDBC standard is similar to ODBC, for Java
Transaction Server Process Structure
• A typical transaction server consists of multiple processes accessing
data in shared memory.
• Server processes
• These receive user queries (transactions), execute them and
send results back
• Processes may be multithreaded, allowing a single process to
execute several user queries concurrently
• Typically multiple multithreaded server processes
• Lock manager process
• More on this later
• Database writer process
• Output modified buffer blocks to disks continually
Transaction Server Processes
• Log writer process
• Server processes simply add log records to log record buffer
• Log writer process outputs log records to stable storage.
• Checkpoint process
• Performs periodic checkpoints
• Process monitor process
• Monitors other processes, and takes recovery actions if any of
the other processes fail
• E.g., aborting any transactions being executed by a server
process and restarting it
Transaction System Processes
 Transaction System Processes
• Shared memory contains shared data
• Buffer pool
• Lock table
• Log buffer
• Cached query plans (reused if same query submitted again)
• All database processes can access shared memory
• To ensure that no two processes are accessing the same data
structure at the same time, databases systems implement mutual
exclusion using either
• Operating system semaphores
• Atomic instructions such as test-and-set
• To avoid overhead of interprocess communication for lock
request/grant, each database process operates directly on the lock
table
• instead of sending requests to lock manager process
• Lock manager process still used for deadlock detection
Data Servers
• Used in high-speed LANs, in cases where
• The clients are comparable in processing power to the server
• The tasks to be executed are compute intensive.
• Data are shipped to clients where processing is performed, and
then shipped results back to the server.
• This architecture requires full back-end functionality at the
clients.
• Used in many object-oriented database systems
• Issues:
• Page-Shipping versus Item-Shipping
• Locking
• Data Caching
• Lock Caching
Data Servers
• Page-shipping versus item-shipping
• Smaller unit of shipping  more messages
• Worth prefetching related items along with requested item
• Page shipping can be thought of as a form of prefetching
• Locking
• Overhead of requesting and getting locks from server is high due
to message delays
• Can grant locks on requested and prefetched items; with page
shipping, transaction is granted lock on whole page.
• Locks on a prefetched item can be P{called back} by the server,
and returned by client transaction if the prefetched item has not
been used.
• Locks on the page can be deescalated to locks on items in the
page when there are lock conflicts. Locks on unused items can
then be returned to server.
Data Servers
• Data Caching
• Data can be cached at client even in between transactions
• But check that data is up-to-date before it is used (cache
coherency)
• Check can be done when requesting lock on data item
• Lock Caching
• Locks can be retained by client system even in between
transactions
• Transactions can acquire cached locks locally, without
contacting server
• Server calls back locks from clients when it receives conflicting
lock request. Client returns lock once no local transaction is
using it.
• Similar to deescalation, but across transactions.
Parallel Systems
• Parallel database systems consist of multiple processors and
multiple disks connected by a fast interconnection network.
• A coarse-grain parallel machine consists of a small number of
powerful processors
• A massively parallel or fine grain parallel machine utilizes
thousands of smaller processors.
• Two main performance measures:
• throughput --- the number of tasks that can be completed in a
given time interval
• response time --- the amount of time it takes to complete a
single task from the time it is submitted
 Interconnection Network Architectures
• Bus. System components send data on and receive data from a single
communication bus;
• Does not scale well with increasing parallelism.
• Mesh. Components are arranged as nodes in a grid, and each
component is connected to all adjacent components
• Communication links grow with growing number of components,
and so scales better.
• Hypercube. Components are numbered in binary; components are
connected to one another if their binary representations differ in
exactly one bit.
Interconnection Architectures
Parallel Database Architectures
• Shared memory -- processors share a common memory
• Shared disk -- processors share a common disk
• Shared nothing -- processors share neither a common memory nor
common disk
• Hierarchical -- hybrid of the above architectures
Parallel Database Architectures
Shared Memory
• Processors and disks have access to a common memory, typically via
a bus or through an interconnection network.
• Extremely efficient communication between processors — data in
shared memory can be accessed by any processor without having to
move it using software.
• Downside – architecture is not scalable beyond 32 or 64 processors
since the bus or the interconnection network becomes a bottleneck
• Widely used for lower degrees of parallelism (4 to 8).
 Shared Disk
• All processors can directly access all disks via an interconnection
network, but the processors have private memories.
• The memory bus is not a bottleneck
• Architecture provides a degree of fault-tolerance — if a processor
fails, the other processors can take over its tasks since the
database is resident on disks that are accessible from all
processors.
• Examples: IBM Sysplex and DEC clusters (now part of Compaq)
running Rdb (now Oracle Rdb) were early commercial users
• Downside: bottleneck now occurs at interconnection to the disk
subsystem.
• Shared-disk systems can scale to a somewhat larger number of
processors, but communication between processors is slower.
Shared Nothing
• Node consists of a processor, memory, and one or more disks.
Processors at one node communicate with another processor at
another node using an interconnection network. A node functions as
the server for the data on the disk or disks the node owns.
• Examples: Teradata, Tandem, Oracle-n CUBE
• Data accessed from local disks (and local memory accesses) do not
pass through interconnection network, thereby minimizing the
interference of resource sharing.
• Shared-nothing multiprocessors can be scaled up to thousands of
processors without interference.
• Main drawback: cost of communication and non-local disk access;
sending data involves software interaction at both ends.
Hierarchical
• Combines characteristics of shared-memory, shared-disk, and
shared-nothing architectures.
• Top level is a shared-nothing architecture – nodes connected by an
interconnection network, and do not share disks or memory with
each other.
• Each node of the system could be a shared-memory system with a
few processors.
• Alternatively, each node could be a shared-disk system, and each of
the systems sharing a set of disks could be a shared-memory system.
• Reduce the complexity of programming such systems by distributed
virtual-memory architectures
• Also called non-uniform memory architecture (NUMA)
Distributed Systems
• Data spread over multiple machines (also referred to as sites or
nodes).
• Network interconnects the machines
• Data shared by users on multiple machines
Distributed Databases
• Homogeneous distributed databases
• Same software/schema on all sites, data may be partitioned
among sites
• Goal: provide a view of a single database, hiding details of
distribution
• Heterogeneous distributed databases
• Different software/schema on different sites
• Goal: integrate existing databases to provide useful functionality
• Differentiate between local and global transactions
• A local transaction accesses data in the single site at which the
transaction was initiated.
• A global transaction either accesses data in a site different from
the one at which the transaction was initiated or accesses data in
several different sites.
Trade-offs in Distributed Systems
• Sharing data – users at one site able to access the data residing at
some other sites.
• Autonomy – each site is able to retain a degree of control over data
stored locally.
• Higher system availability through redundancy — data can be
replicated at remote sites, and system can function even if a site fails.
• Disadvantage: added complexity required to ensure proper
coordination among sites.
• Software development cost.
• Greater potential for bugs.
• Increased processing overhead.
Implementation Issues for Distributed Databases

• Atomicity needed even for transactions that update data at multiple

sites
• The two-phase commit protocol (2PC) is used to ensure atomicity
• Basic idea: each site executes transaction until just before
commit, and the leaves final decision to a coordinator
• Each site must follow decision of coordinator, even if there is a
failure while waiting for coordinators decision
• 2PC is not always appropriate: other transaction models based on
persistent messaging, and workflows, are also used
• Distributed concurrency control (and deadlock detection) required
• Data items may be replicated to improve data availability
Network Types
• Local-area networks (LANs) – composed of processors that are
distributed over small geographical areas, such as a single building or
a few adjacent buildings.
• Wide-area networks (WANs) – composed of processors distributed
over a large geographical area.
Local-area Network
 Networks Types
• WANs with continuous connection (e.g., the Internet) are needed for
implementing distributed database systems
• Groupware applications such as Lotus notes can work on WANs with
discontinuous connection:
• Data is replicated.
• Updates are propagated to replicas periodically.
• Copies of data may be updated independently.
• Non-serializable executions can thus result. Resolution is application
dependent.
Emerging Database Technologies
 What is NoSQL?
• Stands for No-SQL or Not Only SQL??
• Class of non-relational data storage systems
• E.g. BigTable, Dynamo, PNUTS/Sherpa, ..
• Usually do not require a fixed table schema nor do they use the
concept of joins
• Distributed data storage systems
• All NoSQL offerings relax one or more of the ACID properties
Typical NoSQL API
• Basic API access:
• get(key) -- Extract the value given a key
• put(key, value) -- Create or update the value given its key
• delete(key) -- Remove the key and its associated value
• execute(key, operation, parameters) -- Invoke an operation
to the value (given its key) which is a special data structure
(e.g. List, Set, Map .... etc).
 Flexible Data Model
ColumnFamily: Rockets
Key Value
1 Name Value
name Rocket-Powered Roller Skates
toon Ready, Set, Zoom
inventoryQty 5
brakes false

2 Name Value
name Little Giant Do-It-Yourself Rocket-Sled Kit
toon Beep Prepared
inventoryQty 4
brakes false

3 Name Value
name Acme Jet Propelled Unicycle
toon Hot Rod and Reel
inventoryQty 1
wheels 1
Column family data model
Some statistics about Facebook Search (using Cassandra)

 MySQL > 50 GB Data

 Writes Average : ~300 ms
 Reads Average : ~350 ms

 Rewritten with Cassandra > 50 GB Data

 Writes Average : 0.12 ms
 Reads Average : 15 ms
SQL vs NOSQL
 NoSQL Data Storage: Classification
• Uninterpreted key/value or ‘the big hash table’.
• Amazon S3 (Dynamo)
• Flexible schema
• BigTable, Cassandra, HBase (ordered keys, semi-structured
data),
• Sherpa/PNuts (unordered keys, JSON)
• MongoDB (based on JSON)
• CouchDB (name/value in text)
PNUTS Data Storage Architecture
Advantages of NoSQL Systems
 Cheap, easy to implement (open source)
 Data are replicated to multiple nodes (therefore identical and
fault-tolerant) and can be partitioned
 When data is written, the latest version is on at least one node
and then replicated to other nodes
 No single point of failure

 Easy to distribute
 Don't require a schema
What does NoSQL Not Provide?
 Joins
 Group by
 But PNUTS provides interesting materialized view approach
to joins/aggregation.
 ACID transactions
 SQL
 Integration with applications that are based on SQL
Internet / Mobile Database
Mobile Database
• Portable devices and wireless technology led to mobile
computing.
• Portable computing devices and wireless
communication allowed the client to access data from
any ware and any time.
• There are some HW and SW problems that must be
solved to make maximum exploitation of mobile
•computing.
i.e. Database recovery.
• •Hardware
Wirelessproblems
coverage.are more difficult.
• Battery.
• Changes in network
topology.
• Wireless Transmission
Speed.
Mobile Database
• Mobile Computing Architecture:
 Mobile Database
• Mobile Ad-Hoc Network (MANET):
• In a MANET, co-located mobile units do not need to
communicate via a fixed network, but instead, form their
own using cost-effective technologies such as Bluetooth.
• In a MANET, mobile units are responsible for routing their
own data, effectively acting as base stations as well as
clients.
• MANET must be robust enough to handle changes in
network topology such as arrival or departure of mobile
unites.
• MANET can fall under P2P architecture.
Characteristics of Mobile Environments
• Communication latency
• Intermittent connectivity
• Limited battery life
• Changing client location

All of these Characteristics impact data management in

mobile computing.
Characteristics of Mobile Environments

• The server may not be able to reach the client or vise

versa.
• We can add proxies to the client and the server to cache
updates into when connection is not available.
• After the connection is available proxy automatically
forward these updates to its distention.
Characteristics of Mobile Environments
• The latency involved in wireless communication makes
scalability a problem.
• Since latency increases the time to service each client
request, so the server can handle fewer clients.
• Servers can use Broadcasting to solve this problem.
• Broadcast well reduces the load on the server, as clients do
not have to maintain active connections to it.
• For example weather broadcasting.
 Characteristics of Mobile Environments
• Client mobility also poses many data management
challenges:
• Servers must keep track of client locations in order to
efficiently route messages to them.
• Client data should be stored in the network location
that minimizes the traffic necessary to access it.
• The act of moving between cells must be transparent
to the client.

• Client mobility also allows new applications that are

location-based.
 Data Management Issues
• Mobile databases can be distributed under two possible
scenarios:
• The entire database is distributed mainly among the
wired components, possibly with full or partial
replication.
• Management is done in fixed hosts, with additional
functionalities.
• The database is distributed among wired and wireless
components.
• Management is done in both fixed hosts and mobile
units.
Data Management Issues
– Data distribution and replication (Cache)
– Transactions models
– Query processing (where data is located?)
– Recovery and fault tolerance
– Mobile database design
– Location-based service
– Division of labor
– Security
 Application: Intermittently Synchronized Databases

• The client has his own application and DBMS in his local
laptop.

• Do some updates locally and connect to the server via

internet to get batch of updates (synchronization).

• The primary characteristic of this scenario is that the clients

are mostly disconnected; the server is not necessarily able
reach them.

• This environment has problems similar to those in

distributed and client- server databases, and some from
mobile databases.
Application: Intermittently Synchronized Databases

Insert\Update Data
Multimedia Database
Multimedia Databases
• In the years ahead multimedia information systems are
expected to dominate our daily lives.
Nature of Multimedia Data and Applications
• DBMSs have been constantly adding to the types of
data they support.
• Today many types of multimedia data are available
in current systems.
• Text.
• Graphics.
• Images.
• Animation.
• Video.
• Audio.
 Nature of Multimedia Applications
• Multimedia data may be stored, delivered, and utilized in many
different ways.
• Applications may be categorized based on their data
management characteristics.
• Repository applications.
• A large amount of multimedia data as well as metadata is
stored for retrieval purposes.
• Presentation applications.
• Simple multimedia viewing of video or audio data.
• Collaborative work using multimedia information.
• Complex design task by merging drawings, fitting
subjects to design constraints, and generating new
documentation, change notifications etc.
Data Management Issues
• Multimedia applications dealing with thousands of images,
documents, audio and video segments, and free text data
depend critically on:
– Appropriate modeling of the structure and content of
data.
– Designing appropriate database schemas for storing
and retrieving multimedia information.
Data Management Issues
• Multimedia information systems are very complex and
embrace a large set of issues:
• Modeling:
• Complex Objects, dealing with large number of types
of data (Graphics).
• Design:
• Conceptual, logical, and physical design of multimedia
has not been addressed fully, and it remains an area
of active research.
• Storage:
• Multimedia data on standard disk devices presents
problems
•
of representation, compression, mapping to
device hierarchies, archiving, and buffering during the
input/output operation. DBMS has presented the
BLOB type (Binary Large Object).
 Data Management Issues
• Multimedia information systems are very complex and
embrace a large set of issues (cont.):
• Queries and retrieval:
• The database way of retrieving information is based on
query languages and internal index structures.
• Performance :
• Multimedia applications involving only documents and
text, performance constraints are subjectively
determined by the user.
• Applications involving video playback or audio-video
synchronization, physical limitations dominate.
Multimedia Database Applications
• Documents and records management
• Knowledge dissemination
• Education and training
• Marketing, advertising, retailing, entertainment, and
travel
• Real-time control and monitoring
Cloud Database (Dbaas)
What is Cloud Database?

• A cloud database is a database that typically runs on a

cloud computing platform, access to it is provided as a
service such as Amazon EC2 and Rack space.
• The cloud database was conceived for the purpose of
online data management by using a variety of distributed
servers .
Methods to run a database in a cloud:
• There are two primary methods to run a database in a
cloud:
• Virtual machine image
• Database-as-a-service (DBaaS)
Virtual machine image :
• Cloud platforms allow users to purchase virtual-machine
instances for a limited time, and one can run a database
on such virtual machines.
• Users can either upload their own machine image with a
database installed on it, or use ready-made machine
images that already include an optimized installation of a
database
Database-as-a-service (DBaaS) :

• With a database as a service model, application owners

do not have to install and maintain the database
themselves.
• Instead, the database service provider takes responsibility
for installing and maintaining the database, and
application owners are charged according to their usage
of the service.
Architecture and common characteristics
• Most database services offer web-based consoles, which the
end user can use to provision and configure database
instances.
• Database services consist of a database-manager
component, which controls the underlying database
instances using a service API.
• The service API is exposed to the end user, and permits
users to perform maintenance and scaling operations on
their database instances.
• The service provider is responsible for installing, patching
and updating the underlying software stack and ensuring the
overall health and performance of the database.
• There is typically a commitment for a certain level of high
availability (e.g. 99.9% or 99.99%).
Advantages of Cloud Databases :
• The cloud database system makes information sharing simple
and convenient.
• Easy access to files and data is what a cloud database
actually emphasizes. If freak accidents happen, there is no
reason for you to worry since all pieces of information are
safely kept.
• A cloud database is far cheaper than that of maintaining an
actual server, wherein a lot of other applications are
necessary.
• Being a virtual data storage location, you get every single
opportunity of manipulating data wherever you may be.
Security Issue :
• Middleware muddles
• Authentication
• Regulatory compliance issues in the
cloud
SQLite Databases
 SQLite Database
• Android applications can have application databases powered
by SQLite
• Lightweight and file-‐based, ideal for mobile devices
• Databases are private for the application that creates them
• Databases should not be used to store files
• SQLite is a light weight database
• Atomic
• Stable
• Independent
• Enduring
• Only several kilobytes
• Only partly support some SQL commands such as ALTER,
TABLE.
• SQLite is included as part of Android’s software stack
SQLite Databases
• Steps for using SQLite databases:
1. Create a database
2. Open the database
3. Create a table
4. Create and insert interface for datasets
5. Create a query interface for datasets
6. Close the database
• Good practice to create a Database Adapter class to
simplify your database interactions
• We will use the SQLite database defined in the
notebook tutorial as an example
 SQLite Example: Notebook Tutorial
public class NotesDbAdapter {

public static final String KEY_TITLE = "title"; public static final String KEY_BODY = "body"; public static
final String KEY_ROWID = "_id";

private static final String TAG = "NotesDbAdapter";

private DatabaseHelper mDbHelper; private SQLiteDatabase mDb;

/**
* Database creation sql statement
*/
private static final String DATABASE_CREATE =
"create table notes (_id integer primary key autoincrement, "
+ "title text not null, body text not null);";

private static final String DATABASE_NAME = "data"; private static final String DATABASE_TABLE =
"notes"; private static final int DATABASE_VERSION = 2;

private final Context mCtx;

 SQLiteOpenHelper Class
• Abstract class for implementing a best practice pattern for
creating, opening and upgrading databases
• To create a SQLite database, the recommended approach is to
create a subclass of SQLiteOpenHelper class
• Then override its onCreate() method
– Then execute a SQLite command to create tables in the
database
• Use the onUpgrade() method to handle upgrade of the database
– A simple way would be to drop an existing table and replace
with a new defenition
– Better to migrate existing data into a new table
• Then use an instance of the helper class to manage opening or
upgrading the database
– If the database doesn’t exist, the helper will create one by
calling its onCreate() handler
– If the database version has changed, it will upgrade by calling
the onUpgrade() handler
 SQLite Example: Notebook Tutorial
private static class DatabaseHelper extends SQLiteOpenHelper {

DatabaseHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
@Override
public void onCreate(SQLiteDatabase db) {

db.execSQL(DATABASE_CREATE);
}

@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
Log.w(TAG, "Upgrading database from version " + oldVersion + " to "
+ newVersion + ", which will destroy all old data");
db.execSQL("DROP TABLE IF EXISTS notes");
onCreate(db);
}
}
SQLite Databases
• Database queries are returned as Cursor objects
– Pointers to the resulting sets within the underlying
data
• Cursor class provides several methods:
– moveToFirst, moveToNext, moveToPrevious,
moveToPosition used to move to a row
– getCount to get the number of rows in the cursor
– getPosition to get the current row position
– getColumnName, getColumnNames,
getColumnIndexorThrow to get info on columns
– startManagingCursor and stopManagingCursor
methods used to integrate cursor lifetime into the
activity’s lifetime
 Content Providers
• Store and retrieve data and make it available to all
applications
– Only way to share data across applications
• Standard content providers part of Android:
– Common data types (audio, video, images, personal
contact information)
• Applications can create their own content providers to make
their data public
– Alternatively add the data to an existing provider
• Implement a common interface for querying the provider,
adding, altering and deleting data
• Actual storage of data is up to the designer
• Provides a clean separation between the application layer and
data layer
 Accessing Content
• Applications access the content through a ContentResolver instance
– ContentResolver allows querying, inserting, deleting and updating data
from the content provider
ContentResolver cr = getContentResolver();

cr.query(People.CONTENT_URI, null, null, null, null); //querying contacts

ContentValues newvalues = new ContentValues();

cr.insert(People.CONTENT_URI, newvalues);

cr.delete(People.CONTENT_URI, null, null); //delete all contacts

Content Providers
• Content providers expose their data as a simple table
on a database model
– Each row is a record and each column is data of a particular
type and meaning
• Queries return cursor objects
• Each content provider exposes a public URI that
uniquely identifies its data set
– Separate URI for each data set under the control of the
provider
– URIs start with content://…
– Typical format:
Content://<package name>.provider.<custom provider name>/<DataPath>
Content Providers: Modifying Data
• Data kept by a content provider can be modified by:
– Adding new records
– Adding new values to existing records
– Batch updating existing records
– Deleting records
• All accomplished using ContentResolver methods
• Use ContentValues() to add or update data
Content Providers: Adding Data
• Adding new records:
import android.provider.Contacts.People; import
android.content.ContentResolver; import
android.content.ContentValues;

ContentValues values = new ContentValues();

// Add Abraham Lincoln to contacts and make him a favorite.

values.put(People.NAME, "Abraham Lincoln");
// 1 = the new contact is added to favorites
// 0 = the new contact is not added to favorites
values.put(People.STARRED, 1);

Uri uri = getContentResolver().insert(People.CONTENT_URI, values);

Content Providers
• Use ContentResolver.update() to batch update fields
• Use ContentResolver.delete() to delete:
– A specific row
– Multiple rows, by calling the method with the URI of the type
of record to delete and an SQL WHERE clause defining
which rows to delete
Creating Content Providers
• To create a content provider, you must:
– Set up a system for storing the data. Most content providers store
their data using Android's file storage methods or SQLite databases,
but you can store your data any way you want.
– Extend the ContentProvider class to provide access to your data
– Declare the content provider in the manifest file for your application
(AndroidManifest.xml)
Creating Content Providers
• Extending the ContentProvider class will require:
– Implementing the following methods: query(), insert(), update(),
delete(), getType(), onCreate()
– Make sure that these implementations are thread-‐safe as they may
be called from several ContentResolver objects in several different
processes and threads
• In addition, you need to:
– Declare a public static final URI named CONTENT_URI
– Define the column names that the content provider will return to
clients
– Carefully document the data type of each column
XML Databases
XML

●Extensible Markup Language is a meta-language that describes

the contents of the document (Self-describing data)
●JAVA=Portable Code XML=Portable Data
Applications of XML

●Configuration Files used extensively in J2EE architectures

●Media for data interchange A better alternative to proprietary

data formats

●B2B Transactions on the Web Electronic Business orders

(ebXML) Financial Exchange Message Exchange (SOAP)
Four tasks of data management
The basic tasks of data management do not change simply
because the data are stored in XML
●Store
●Search
●Retrieve
●Display
XML a Database ?
●Only in the strictest sense of the term
●It is self-describing
●It is portable
●It can describe data in tree or graph structures
XML a “ Sort of ” Database ?
●Storage -- XML documents

●Schemas -- DTDs, XML Schemas, and so on

●Query languages -- XQuery, XQL, etc.

●Programming interfaces -- SAX, DOM

Limitation of XML
●Efficient storage
●Indexes
●Security
●Transactions and data integrity
●Multi-user access
●Triggers
●Queries across multiple documents
XML Databases

• RDBMSs that support XML e.g. Oracle , DB2

• Native XML Database e.g. Apache Xindice, Stanford XMLDB
Relational Databases Vs XML Databases
Relational database XML database

A relational database contains An XML database contains

tables. collections.
A relational table contains A collection contains XML
records with the same schema. documents with the same
schema.
A relational record is an An XML document is a tree of
unordered list of named values. nodes.
A SQL query returns an An XQuery returns an ordered
unordered sequence of nodes.
set of records.
Technologies

●Java - Servlets, JAXP

●Apache Tomcat web server
●Apache Xindice XML DB
●RDBMS - MS-Access, MY-SQL or ORACLE
●IDE - Eclipse
Modules

●Parse XML Insert into Database

●Convert Database table into XML

●Reflect changes in Database to XML and Vice versa

Parse XML Insert into Database
Database Table to XML
Java ResultsetMetadata

●An object that can be used to get information about the types
and properties of the columns in a Resultset object
Modules- to be Implemented

●Convert Text files to XML

●Convert HTML to XML

●Implementing Searching

●Implementing Indexing
Searching XML
●Search process begins in the root node
●Search proceeds comparing characters in the search key to edge
labels
●Entering a wrong block may lead to backtracking
 Indexing XML

●The goal of indexing is to optimize the speed and performance of

finding relevant documents

●Without an index, the search engine would scan every document

●It will take a considerable amount of time and computing power

Accredited ‘A’ Grade By NAAC

Thank You