Types of query language

Query languages are computer languages used to make queries into databases and
information systems.

SQL-

Broadly, query languages can be classified according to whether they are database query
languages or information retrieval query languages. Examples include:

• .QL is a proprietary object-oriented query language for querying relational

databases; successor of Datalog;
• Common Query Language (CQL) a formal language for representing queries to
information retrieval systems such as web indexes or bibliographic catalogues.
• CQLF (CODASYL Query Language, Flat) is a query language for CODASYL-
type databases;
• Concept-Oriented Query Language (COQL) is used in the concept-oriented model
(COM). It is based on a novel data modeling construct, concept, and uses such
operations as projection and de-projection for multi-dimensional analysis,
analytical operations and inference;
• D is a query language for truly relational database management systems
(TRDBMS);
• DMX is a query language for Data Mining models;
• Datalog is a query language for deductive databases;
• ERROL is a query language over the Entity-relationship model (ERM) which
mimics major Natural language constructs (of the English language and possibly
other languages). It is especially tailored for relational databases;
• Gellish English is a language that can be used for queries in Gellish English
Databases [1], for dialogues (requests and responses) as well as for information
modeling and knowledge modeling;
• HTSQL is a query language that translates HTTP queries to SQL;
• ISBL is a query language for PRTV, one of the earliest relational database
management systems;
• LDAP is an application protocol for querying and modifying directory services
running over TCP/IP;
• MQL is a cheminformatics query language for a substructure search allowing
beside nominal properties also numerical properties;
• MDX is a query language for OLAP databases;
• OQL is Object Query Language;
• OCL (Object Constraint Language). Despite its name, OCL is also an object
query language and a OMG standard;
• OPath, intended for use in querying WinFS Stores;
• Poliqarp Query Language is a special query language designed to analyze
annotated text. Used in the Poliqarp search engine;
• QUEL is a relational database access language, similar in most ways to SQL;
• RDQL is a RDF query language;
• SeRQL ("Sesame RDF Query Language", pronounced "circle") is a new
RDF/RDFS query language that is currently being developed by Aduna as part of
Sesame.
• SMARTS is the cheminformatics standard for a substructure search;
• SPARQL is a query language for RDF graphs;
 • SQL is a well known query language for relational databases;
• SuprTool is a proprietary query language for SuprTool, a database access program
used for accessing data in Image/SQL (formerly TurboIMAGE) and Oracle
databases;
• TMQL Topic Map Query Language is a query language for Topic Maps;
• XQuery is a query language for XML data sources;
• XPath is a declarative language for navigating XML documents;
• XSQL is a query language combining the power of XML and the power of SQL,
it is currently under development;
• YQL is an SQL-like query language created by Yahoo!

Relational Query Languages

• Two sublanguages:
– DDL – Data Definition Language
• Define and modify schema (at all 3 levels)
– DML – Data Manipulation Language
• Queries can be written intuitively.
• DBMS is responsible for efficient evaluation.
– The key: precise semantics for relational queries.
– Optimizer can re-order operations, without affecting
query answer.
– Choices driven by “cost model
The SQL Query Language
• The most widely used relational query language.
• Standardized
(although most systems add their own “special sauce”
 including PostgreSQL)
Example Database
3 Nancy 8 27
2 Jim 2 39
1 Fred 7 22
sid sname rating age
Sailors
2 102 9/13
1 102 9/12
sid bid day
Reserves
103 Santa Maria red
102 Pinta blue
101 Nina ,SQL DML,DDL

DEDUCTIVE DATABASE
A general deductive database is a finite set of clauses of the form
a – l1,l2......lm
where a is an atom, m greater then equal to 0 and each li is a literal.
A combination of a conventional database containing facts, a knowledge base containing
rules, and an inference engine which allows the derivation of information implied by the
facts and rules.Commonly, the knowledge base is expressed in a subset of first-order
logic and either a SLDNF or Datalog inference engine is used.
A deductive database system is a database system which can make deductions (i.e.:
conclude additional facts) based on rules and facts stored in the (deductive) database.
Datalog is the language typically used to specify facts, rules and queries in deductive
databases. Deductive databases have grown out of the desire to combine logic
programming with relational databases to construct systems that support a powerful
formalism and are still fast and able to deal with very large datasets. Deductive databases
are more expressive than relational databases but less expressive than logic programming
systems. Deductive databases have not found widespread adoptions outside academia, but
some of their concepts are used in today's relational databases to support the advanced
features of more recent SQL standards.
Deductive databases were introduced over 30 years ago as a powerful extension to the relational data model
with recursive views. A deductive database consists of a set of facts that correspond to a relational database
and a set of logical rules

Deductive databases reuse a large number of concepts from logic programming; rules and
facts specified in the deductive database language Datalog look very similar to those in
Prolog. However, there are a number of important differences between deductive
databases and logic programming:

• Order sensitivity and procedurality: in Prolog, program execution depends on the

order of rules in the program and on the order of parts of rules; these properties
are used by programmers to build efficient programs. In database languages (like
SQL or Datalog), however, program execution is independent of the order of rules
and facts.
• Special predicates: In Prolog, programmers can directly influence the procedural
evaluation of the program with special predicates such as the cut, this has no
correspondence in deductive databases.
• Function symbols: Logic Programming languages allow function symbols to build
up complex symbols. This is not allowed in deductive databases.
• Tuple oriented processing: Deductive databases use set-oriented processing while
logic programming languages concentrate on one tuple at a time.

MOBILE DATABASE
A mobile database is a database that can be connected to by a mobile computing
device over a mobile network. The client and server have wireless connections. A cache
is maintained to hold frequent data and transactions so that they are not lost due to
connection failure. A database is a structured way to organize information. This could be
a list of contacts, price information or distance travelled.[1]

A system with the following structural and functional properties

 Distributed system with mobile connectivity

 Full database system capability
 Complete spatial mobility
 Built on PCS/GSM platform
 Wireless and wired communication capability

The use of laptops, mobiles and PDAs is increasing and likely to increase in the
future[citation needed] with more and more applications residing in the mobile systems. While
those same analysts can’t tell us exactly which applications will be the most popular, it is
clear that a large percentage will require the use of a database of some sort. Many
applications such as databases would require the ability to download information from an
information repository and operate on this information even when out of range or
disconnected.

An example of this is a mobile workforce. In this scenario user would require to access
and update information from files in the home directories on a server or customer records
from a database. This type of access and work load generated by such users is different
from the traditional workloads seen in client–server systems of today. With the advent of
mobile databases, now users can load up their smart phones or PDAs with mobile
databases to exchange mission-critical data remotely without worrying about time or
distance. Mobile databases let employees enter data on the fly. Information can be
synchronized with a server database at a later time.

Need for mobile databases

• Mobile users must be able to work without a wireless connection due to poor or
even non-existent connections.
• Applications must provide significant interactivity.
• Applications must be able to access local device/vehicle hardware, such as
printers, bar code scanners, or GPS units (for mapping or Automatic Vehicle
Location systems).
• Bandwidth must be conserved (a common requirement on wireless networks that
charge per megabyte or data transferred).
• Users don't require access to truly live data, only recently modified data.
• Limited life of power supply(battery)
• The changing topology of network

Mobile database system architecture

For any mobile architecture, things to be considered are:

• Users are not attached to a fixed geographical location

• Mobile computing devices: low-power, low-cost, portable
• Wireless networks
• Mobile computing constraints

Three parties

Mobile databases typically involve three parties: fixed hosts, mobile units, and base
stations. Fixed hosts perform the transaction and data management functions with the
help of database servers. Mobile units are portable computers that move around a
geographical region that includes the cellular network (or "cells") that these units use to
communicate to base stations. (Note that these networks need not be cellular telephone
networks.) Base stations are two-way radios, installations in fixed locations, that pass
communications with the mobile units to and from the fixed hosts. They are typically
low-power devices such as mobile phones, portable phones, or wireless routers.
When a mobile unit leaves a cell serviced by a particular base station, that station
transparently transfers the responsibility for the mobile unit's transaction and data support
to whichever base station covers the mobile unit's new location.

MOBILE COMPUTING
Mobile computing is a form of human–computer interaction where a computer is
expected to be transported during normal usage. Mobile computing has three aspects:
mobile communication, mobile hardware and mobile software. The first aspect addresses
communication issues in ad-hoc and infrastructure networks as well as communication
properties, protocols, data formats and concrete technologies. The second aspect focusses
on the hardware, i.e. mobile devices or device components. The third aspect deals with
the characteristics and requirements of mobile applications.
Definitions
Mobile computing is "taking a computer and all necessary files and software out into the
field."

"Mobile computing: being able to use a computing device even when being mobile and
therefore changing location. Portability is one aspect of mobile computing."[

Devices
Many types of mobile computers have been introduced since the 1990s, including the

• Wearable computer
 • Personal digital assistant/enterprise digital assistant
• Smartphone
• Carputer
• Ultra-Mobile PC

Technical and other limitations of mobile computing

• Insufficient bandwidth

Mobile Internet access is generally slower than direct cable connections, using
technologies such as GPRS and EDGE, and more recently HSDPA and HSUPA 3G
networks. These networks are usually available within range of commercial cell phone
towers. Higher speed wireless LANs are inexpensive, but have very limited range.

• Security standards

When working mobile one is dependent on public networks, requiring careful use of
VPNs.

• Power consumption

When a power outlet or portable generator is not available, mobile computers must rely
entirely on battery power. Combined with the compact size of many mobile devices, this
often means unusually expensive batteries must be used to obtain the necessary battery
life.

• Transmission interferences

Weather, terrain, and the range from the nearest signal point can all interfere with signal
reception. Reception in tunnels, some buildings, and rural areas is often poor.

• Potential health hazards

More car accidents are related to drivers who were talking through a mobile device. Cell
phones may interfere with sensitive medical devices. There are allegations that cell phone
signals may cause health problems.[citation needed]

• Human interface with device

Screens and keyboards tend to be small, which may make them harder to use. Alternate
input methods such as speech or handwriting recognition require training.

Isolation property of concurrent transactions

Isolation refers to the requirement that other operations cannot access data that has been
modified during a transaction that has not yet completed. The question of isolation occurs
in case of concurrent transactions (multiple transactions occurring at the same time).
Each transaction must remain unaware of other concurrently executing transactions,
except that one transaction may be forced to wait for the completion of another
transaction that has modified data that the waiting transaction requires. If the isolation
system does not exist, then the data could be put into an inconsistent state. This could
happen, if one transaction is in the process of modifying data but has not yet completed,
and then a second transaction reads and modifies that uncommitted data from the first
transaction. If the first transaction fails and the second one succeeds, that violation of
transactional isolation will cause data inconsistency. Due to performance and
deadlocking concerns with multiple competing transactions, many modern databases
allow dirty reads, which is a way to bypass some of the restrictions of the isolation
system. A dirty read means that a transaction is allowed to read, but not modify, the
uncommitted data from another transaction.

Time stamp ordering

In computer science, in the field of databases, timestamp-based concurrency control is

a non-lock concurrency control method, used in relational databases to safely handle
transactions, using timestamps.

Each transaction (Ti) is an ordered list of actions (Aix). Before the transaction performs its
first action (Ai1), it is marked with the current timestamp, or any other strictly totally
ordered sequence: TS(Ti) = NOW(). Every transaction is also given an initially empty set
of transactions upon which it depends, DEP(Ti) = [], and an initially empty set of old
objects which it updated, OLD(Ti) = [].

Each object (Oj) in the database is given two timestamp fields which are not used other
than for concurrency control: RTS(Oj) is the time at which the value of object was last
used by a transaction, WTS(Oj) is the time at which the value of the object was last
updated by a transaction.

For all Ti:

For each action Aix:

If Aix wishes to use the value of Oj:
If WTS(Oj) > TS(Ti) then abort (a more recent thread has overwritten the value),
Otherwise update the set of dependencies DEP(Ti).add(WTS(Oj)) and set RTS(Oj)
= max(RTS(Oj),TS(Ti));
If Aix wishes to update the value of Oj:
If RTS(Oj) > TS(Ti) then abort (a more recent thread is already relying on the old
value),
If WTS(Oj) > TS(Ti) then skip (the Thomas Write Rule),
Otherwise store the previous values, OLD(Ti).add(Oj,WTS(Oj)), set WTS(Oj) =
TS(Ti), and update the value of Oj.
While there is a transaction in DEP(Ti) that has not ended: wait
If there is a transaction in DEP(Ti) that aborted then abort
Otherwise: commit.

Whenever a transaction starts, it is given a timestamp. This is so we can tell which order
that the transactions are supposed to be applied in. So given two transactions that affect
the same object, the transaction that has the earlier timestamp is meant to be applied
before the other one. However, if the wrong transaction is actually presented first, it is
aborted and must be restarted.
Every object in the database has a read timestamp, which is updated whenever the
object's data is read, and a write timestamp, which is updated whenever the object's data
is changed.

If a transaction wants to read an object,

• but the transaction started before the object's write timestamp it means that
something changed the object's data after the transaction started. In this case, the
transaction is canceled and must be restarted.
• and the transaction started after the object's write timestamp, it means that it is
safe to read the object. In this case, if the transaction timestamp is after the
object's read timestamp, the read timestamp is set to the transaction timestamp.

If a transaction wants to write to an object,

• but the transaction started before the object's read timestamp it means that
something has had a look at the object, and we assume it took a copy of the
object's data. So we can't write to the object as that would make any copied data
invalid, so the transaction is aborted and must be restarted.
• and the transaction started before the object's write timestamp it means that
something has changed the object since we started our transaction. In this case we
use the Thomas Write Rule and simply skip our write operation and continue as
normal; the transaction does not have to be aborted or restarted
• otherwise, the transaction writes to the object, and the object's write timestamp is
set to the transaction's timestamp.

Timestamp Resolution

This is the minimum time elapsed between two adjacent timestamps. If the resolution of
the timestamp is too large (coarse), the possibility of two or more timestamps being equal
is increased and thus enabling some transactions to commit out of correct order. For
example, assuming that we have a system that can create one hundred unique timestamps
per second, and given two events that occur 2 milliseconds apart, they will probably be
given the same timestamp even though they actually occurred at different times.

Timestamp Locking

Even though this technique is a non-locking one, in as much as the Object is not locked
from concurrent access for the duration of a transaction, the act of recording each
timestamp against the Object requires an extremely short duration lock on the Object or
its proxy.

Timestamp ordering concurrency control mechanisms were considered to be quite

suitable for distributed database systems, since transactions to be rolled badk can be
determined locally at each site. Experiments, however, have shown that timestamp
ordering mechanisms do not seem to be efficient and has a starvation problem for long
transactions.
Recovery Techniques for Database Systems
presents seven techniques commonly used for recovery in database systems.

Overview/Main Points
• Definitions:
o Failure: An event at which the system does not perform according to
specifications. There are three kinds of failures:
1. failure of a program or transaction
2. failure of the total system
3. hardware failure
o Recovery Data: Data required by the recovery system for the recovery of
the primary data. In very high reliability systems, this data might also need
to be covered by a recovery mechanism... Data recovery data is divided
into two categories : 1) data required to keep current values, and 2) data to
make the restoration of previous values possible.
o Transaction: The base unit of locking and recovery (for undo, redo, or
completion), appears atomic to the user.
o Database:A collection of related storage objects together with controlled
redundancy that serves one or more applications. Data is stored in a way
that is independent of programs using it, with a single approach used to
add, modify, or retrieve data.
o Correct State:Information in the database consists of the most recent
copies of data put in the database by users and contains no data deleted by
users.
o Valid State:The database contains part of the information of the correct
state. There is no spurious data, although pieces may be missing.
o Consistent State:In a valid state, with the information contained
satisfying user consistency constraints. Varies depending on the database
and users.
o Crash:A failure of a system that is covered by a recovery technique.
o Catastrophe:A failure of a system not covered by a recovery technique.
• Possible Levels of Recovery:

1. Recovery to the correct state.

2. Recovery to a checkpointed (past) correct state.
3. Recovery to a possible previous state.
4. Recovery to a valid state.
5. Recovery to a consistent state.
6. Crash resistance (prevention).

The bigger the damage, the cruder the recovery technique used.

• Recovery Techniques:
1. Salvation program: Run after a crash to attempt to restore the system to a valid
state. No recovery data used. Used when all other techniques fail or were not used. Good
for cases where buffers were lost in a crash and one wants to reconstruct what was lost...
(4,5)
 2. Incremental dumping: Modified files copied to archive after job
completed or at intervals. (3,4)
3. Audit trail: Sequences of actions on files are recorded. Optimal for
"backing out" of transactions. (Ideal if trail is written out before changes).
(1,2,3)
4. Differential files: Separate file is maintained to keep track of changes,
periodically merged with the main file. (2,3)
5. Backup/current version: Present files form the current version of the
database. Files containing previous values form a consistent backup
version. (2,3)
6. Multiple copies: Multiple active copies of each file are maintained during
normal operation of the database. In cases of failure, comparison between
the versions can be used to find a consistent version. (6)
7. Careful replacement: Nothing is updated in place, with the original only
being deleted after operation is complete. (2,6)

(Parens and numbers are used to indicate which levels from above are supported
by each technique).

Combinations of two techniques can be used to offer similar protection against

different kinds of failures. The techniques above, when implemented, force
changes to:

The way data is structured

o
The way data is updated and manipulated (7).
o
nothing (available as utilities) (1,2,3).
o
 Examples and bits of wisdom:
o Original Multics system : all disk files updated or created by the user are
copied when the user signs off. All newly created of modified files not
previously dumped are copied to tapes once per hour. High reliability, but
very high overhead. Changed to a system using a mix of incremental
dumping, full checkpointing, and salvage programs.
o Several other systems maintain backup copies of data through the paging
system (keep backups in the swap space).
o Use of buffers is dangerous for consistency.
o Intention lists: specify audit trail before it actually occurs.
o Recovery among interacting processes is hard. You can either prevent the
interaction or synchronize with respect to recovery.
o Error detection is difficult, and can be costly.

Relevance
Recovery from failure is a critical factor in databases. In case of disaster, it is very
important that as much as possible (if not everything) is recovered. This paper surveys
the methods that we in use at the time for data recovery.

SPATIAL DATABASE
A spatial database is a database that is optimized to store and query data that is related
to objects in space, including points, lines and polygons. While typical databases can
understand various numeric and character types of data, additional functionality needs to
be added for databases to process spatial data types. These are typically called geometry
or feature. The Open Geospatial Consortium created the Simple Features specification
and sets standards for adding spatial functionality to database systems.[
1 What is a Spatial Database System?
In various fields there is a need to manage geometric, geographic, or spatial data, which
means datarelated to space. The space of interest can be, for example, the two-
dimensional abstraction of (partsof) the surface of the earth – that is, geographic space,
the most prominent example –, a man-madespace like the layout of a VLSI design, a
volume containing a model of the human brain, or another3d-space representing the
arrangement of chains of protein molecules. At least since the advent ofrelational
database systems there have been attempts to manage such data in database systems.
Characteristic for the technology emerging to address these needs is the capability to deal
with largecollections of relatively simple geometric objects, for example, a set of 100 000
polygons. This issomewhat different from areas like CAD databases (solid modeling etc.)
where geometric entities arecomposed hierarchically into complex structures, although
the issues are certainly related.
Several terms have been used for database systems offering such support like pictorial,
image,geometric, geographic, or spatial database system. The terms “pictorial” and
“image” databasesystem arise from the fact that the data to be managed are often initially
captured in the form of digitalraster images (e.g. remote sensing by satellites, or computer
tomography in medical applications).
The term “spatial database system” is associated with a view of a database as containing
sets objects in space rather than images or pictures of a space. Indeed, the requirements
and techniques for dealing with objects in space that have identity and well-defined
extents, locations, and relationships are rather different from those for dealing with raster
images. It has therefore been suggested to clearly distinguish two classes of systems
called spatial database systems and image database spatial DBMS provide the
underlying database technology for geographic information systems (GIS) and other
applications
.

Features of spatial databases

Database systems use indexes to quickly look up values and the way that most databases
index data is not optimal for spatial queries. Instead, spatial databases use a spatial index
to speed up database operations.

In addition to typical SQL queries such as SELECT statements, spatial databases can
perform a wide variety of spatial operations. The following query types and many more
are supported by the Open Geospatial Consortium:

• Spatial Measurements: Finds the distance between points, polygon area, etc.
• Spatial Functions: Modify existing features to create new ones, for example by
providing a buffer around them, intersecting features, etc.
• Spatial Predicates: Allows true/false queries such as 'is there a residence located
within a mile of the area we are planning to build the landfill?'
• Constructor Functions: Creates new features with an SQL query specifying the
vertices (points of nodes) which can make up lines. If the first and last vertex of a
line are identical the feature can also be of the type polygon (a closed line).
• Observer Functions: Queries which return specific information about a feature
such as the location of the center of a circle
Not all spatial databases support these query types.

Spatial database systems

• All OpenGIS Specifications compliant products[2]
• Open source spatial databases and APIs, some of which are OpenGIS compliant[3]
• Boeing's Spatial Query Server (Official Site) spatially enables Sybase ASE.
• Smallworld VMDS, the native GE Smallworld GIS database
• Spatialite extends Sqlite with spatial datatypes, functions, and utilities.
• IBM DB2 Spatial Extender can be used to enable any edition of DB2, including
the free DB2 Express-C, with support for spatial types
• Oracle Spatial
• Microsoft SQL Server has support for spatial types since version 2008