Date and Time Functions in DBMS

The date and time functions in DBMS are quite useful to manipulate and store values related to date and time.

The different date and time functions are as follows −

ADDDATE(DATE,DAYS)

The numbers of days in integer form (DAYS) is added to the specified date. This is the value returned by the function. For example

sql> SELECT ADDDATE('2018-08-01', 31);

+---------------------------------------------------------+
| DATE_ADD('2018-08-01', INTERVAL 31 DAY) |
+---------------------------------------------------------+
| 2018-09-01 |
+---------------------------------------------------------+
1 row in set (0.00 sec)
This function adds 31 days to the given date i.e. ‘2018-08-01’ and returns the resultant date i.e. ‘2018-09-01’.

ADDTIME(exp1,exp2)
This function adds the two expressions exp1 and exp2 and displays the result. In this case, exp1 can be a datetime or time
expression and exp2 is a time expression. For example:

sql> SELECT ADDTIME('2018-08-01 23:59:59.999999','1 1:1:1.000002');

+---------------------------------------------------------+
|ADDTIME('2018-08-01 23:59:59.999999','1 1:1:1.000002') |
+---------------------------------------------------------+
| 2018-08-02 01:01:01.000001 |
+---------------------------------------------------------+
1 row in set (0.00 sec)
The time '1 1:1:1.000002' is added to the datetime function '2018-08-01 23:59:59.999999' to give the resultant value ‘2018-08-
02 01:01:01.000001’

CURDATE()
This returns the current date of the system in the YYYY-MM-DD format. For example −

sql> SELECT CURDATE();

+---------------------------------------------------------+
| CURDATE() |
+---------------------------------------------------------+
| 2018-08-01 |
+---------------------------------------------------------+
1 row in set (0.00 sec)
This function returns the current date i.e. ‘2018-08-01’

CURTIME()
This returns the current time of the system from the current time zone in the format HH:MM:SS. For example −

sql> SELECT CURTIME();

+---------------------------------------------------------+
| CURTIME() |
+---------------------------------------------------------+
| 10:56:35 |
+---------------------------------------------------------+
1 row in set (0.00 sec)
This function returns the current time i.e ‘10:56:35’

DAYNAME(date)

For the given date, this function returns the corresponding day of the week. For example −

sql> SELECT DAYNAME('2018-08-01');

+---------------------------------------------------------+
| DAYNAME('2018-08-01') |
+---------------------------------------------------------+
| Wednesday |
+---------------------------------------------------------+
1 row in set (0.00 sec)
For the date '2018-08-01’, this function returns the day of the week i.e. Wednesday.

DAYOFMONTH(date)

For the given date, it returns the day of the month the date is on. The value of day of the month ranges from 1 to 31. For example
−

sql> SELECT DAYOFMONTH('2018-02-15');

+---------------------------------------------------------+
| DAYOFMONTH('2018-02-15') |
+---------------------------------------------------------+
| 15 |
+---------------------------------------------------------+
1 row in set (0.00 sec)
This returns the day of the month '2018-02-15' falls on i.e 15.

DAYOFWEEK(date)
For the given date, it returns the day of the week the date is on. The value of day of the week ranges from 1 to 7 (Sunday is 1 and
Saturday is 7). For example −

sql> SELECT DAYOFWEEK('2018-02-15');

+---------------------------------------------------------+
|DAYOFWEEK('2018-02-15') |
+---------------------------------------------------------+
|5|
+---------------------------------------------------------+
1 row in set (0.00 sec)
This returns the day of the week '2018-02-15' falls on i.e 5.

DAYOFYEAR(date)
For the given date, it returns the day of the year the date is on. The value of day of the year ranges from 1 to 366. For example −

sql> SELECT DAYOFYEAR('2018-02-15');

+---------------------------------------------------------+
| DAYOFYEAR('2018-02-15') |
+---------------------------------------------------------+
| 46 |
+---------------------------------------------------------+
1 row in set (0.00 sec)

This returns the day of the year '2018-02-15' falls on i.e 46.

MONTH(date)
It returns the month value for the corresponding date. The range of the month is from 1 to 12. For example −
sql> SELECT MONTH('2018-08-01');
+---------------------------------------------------------+
| MONTH('2018-08-01') |
+---------------------------------------------------------+
|8|
+---------------------------------------------------------+
1 row in set (0.00 sec)
This returns the month number for '2018-08-01' which is 8.

TIME(expr)
This function displays the time part of a time or date time expression in the form of a string. For example −

sql> SELECT TIME('2018-08-01 11:33:25');

+---------------------------------------------------------+
| TIME('2018-08-01 11:33:25') |
+---------------------------------------------------------+
| 11:33:25 |
+---------------------------------------------------------+
1 row in set (0.00 sec)
This displays the time part of '2018-08-01 11:33:25' in the form of a string.

➢ While most databases tend to model reality at a point in time (at the “current” time), temporal databases model the states
of the real world across time.

➢ Facts in temporal relations have associated times when they are valid, which can be represented as a union of intervals.

➢ The transaction time for a fact is the time interval during which the fact is current within the database system.

➢ In a temporal relation, each tuple has an associated time when it is true; the time may be either valid time or transaction
time.

➢ A bi-temporal relation stores both valid and transaction time.

Spatial Databases
Spatial data is associated with geographic locations such as cities, towns etc. A spatial database is optimized to store and query
data representing objects. These are the objects which are defined in a geometric space.

Characteristics of Spatial Database

A spatial database system has the following characteristics

• It is a database system

• It offers spatial data types (SDTs) in its data model and query language.

• It supports spatial data types in its implementation, providing at least spatial indexing and efficient algorithms

for spatial join.

Example
A road map is a visualization of geographic information. A road map is a 2-dimensional object which contains points, lines, and
polygons that can represent cities, roads, and political boundaries such as states or provinces.

In general, spatial data can be of two types −

• Vector data: This data is represented as discrete points, lines and polygons

• Rastor data: This data is represented as a matrix of square cells.

The spatial data in the form of points, lines, polygons etc. is used by many different databases as shown above.

Geographic data
Geographic data such as road maps, land-usage maps, topographic elevation maps, political maps showing boundaries, land-
ownership maps, and so on. Geographical information system are special purpose databases for storing geographical data.
Geographical data are differ from design data in certain ways. Maps and satellite images are typical examples of geographic
data. Maps may provide not only location information associated with locations such as elevations. Soil type, land type and
annual rainfall.
Types of geographical data :

• Raster data
 • Vector data
1.Raster data: Raster data consist of pixels also known as grid cells in two or more dimensions. For example, image of
Satellites , digital pictures, and scanned maps.
2.Vector data: Vector data consist of triangles, lines, and various geometrical objects in two dimensions and cylinders,
cuboids, and other polyhedrons in three dimensions. For example, building boundaries and roads.
Applications of Spatial databases in DBMS :
• Microsoft SQL server: Since the 2008 version of Microsoft SQL server supported spatial databases.
• CouchDB : This is document-based database in which spatial data is enabled by plugin called GeoCouch.
Neo4j database.

Represented of Geometric Information

n Various geometric constructs can be represented in a database in a normalized fashion.
n Represent a line segment by the coordinates of its endpoints.
n Approximate a curve by partitioning it into a sequence of segments
l Create a list of vertices in order, or
l Represent each segment as a separate tuple that also carries with it the identifier of the curve (2D features
such as roads).
n Closed polygons
l List of vertices in order, starting vertex is the same as the ending vertex, or
l Represent boundary edges as separate tuples, with each containing identifier of the polygon, or
l Use triangulation — divide polygon into triangles
 Note the polygon identifier with each of its triangles.

Multimedia Databases

The multimedia databases are used to store multimedia data such as images, animation, audio, video along with text. This data is
stored in the form of multiple file types like .txt(text), .jpg(images), .swf(videos), .mp3(audio) etc.
Contents of the Multimedia Database
The multimedia database stored the multimedia data and information related to it. This is given in detail as follows −

Media data

This is the multimedia data that is stored in the database such as images, videos, audios, animation etc.

Media format data

The Media format data contains the formatting information related to the media data such as sampling rate, frame rate, encoding
scheme etc.

Media keyword data

This contains the keyword data related to the media in the database. For an image the keyword data can be date and time of the
image, description of the image etc.

Media feature data

Th Media feature data describes the features of the media data. For an image, feature data can be colours of the image, textures in
the image etc.

Challenges of Multimedia Database

There are many challenges to implement a multimedia database. Some of these are:

• Multimedia databases contains data in a large type of formats such as .txt(text), .jpg(images), .swf(videos), .mp3(audio) etc.

It is difficult to convert one type of data format to another.

• The multimedia database requires a large size as the multimedia data is quite large and needs to be stored successfully in the

database.

• It takes a lot of time to process multimedia data so multimedia database is slow.

Mobile Databases
Mobile databases are separate from the main database and can easily be transported to various places. Even though they are not
connected to the main database, they can still communicate with the database to share and exchange data.

The mobile database includes the following components −

• The main system database that stores all the data and is linked to the mobile database.
• The mobile database that allows users to view information even while on the move. It shares information with
the main database.
• The device that uses the mobile database to access data. This device can be a mobile phone, laptop etc.
• A communication link that allows the transfer of data between the mobile database and the main database.

Advantages of Mobile Databases

Some advantages of mobile databases are
 • The data in a database can be accessed from anywhere using a mobile database. It provides wireless database
access.
• The database systems are synchronized using mobile databases and multiple users can access the data with seamless
delivery process.

• Mobile databases require very little support and maintenance.

• The mobile database can be synchronized with multiple devices such as mobiles, computer devices, laptops etc.

Disadvantages of Mobile Databases

Some disadvantages of mobile databases are −

• The mobile data is less secure than data that is stored in a conventional stationary database. This presents a
security hazard.
• The mobile unit that houses a mobile database may frequently lose power because of limited battery. This should
not lead to loss of data in database

➢ A mobile computing environment consists of mobile computers, referred to as mobile

hosts, and a wired network of computers.

➢ Mobile host may be able to communicate with wired network through a wireless digital
communication network

o Wireless local-area networks (within a building)

▪ E.g., Avaya’s Orinico Wireless LAN

o Wide areas networks

▪ Cellular digital packet networks

• 3 G and 2.5 G cellular networks

➢ A model for mobile communication

➢ Mobile hosts communicate to the wired network via computers referred to as mobile
support (or base) stations.

➢ Each mobile support station manages those mobile hosts within its cell.

➢ When mobile hosts move between cells, there is a handoff of control from one mobile
support station to another.

➢ Direct communication, without going through a mobile support station is also possible
between nearby mobile hosts

➢ Supported, for e.g., by the Bluetooth standard (up to 10 meters, atup to 721 kbps)
 Database Issues in Mobile Computing
➢ New issues for query optimization.

o Connection time charges and number of bytes transmitted

o Energy (battery power) is a scarce resource and its usage must be minimized

➢ Mobile user’s locations may be a parameter of the query

o GIS queries

o Techniques to track locations of large numbers of mobile hosts

➢ Broadcast data can enable any number of clients to receive the same data at no extra
cost

o leads to interesting querying and data caching issues.

➢ Users may need to be able to perform database updates even while the mobile
computer is disconnected.

o E.g., mobile salesman records sale of products on (local copy of) database.

o Can result in conflicts detected on reconnection, which may need to be resolved

manually.

Routing and Query Processing

➢ Must consider these competing costs:

o User time.
o Communication cost
▪ Connection time - used to assign monetary charges in some cellular
systems.
▪ Number of bytes, or packets, transferred - used to compute charges in
digital cellular systems
▪ Time-of-day based charges - vary based on peak or off-peak periods
o Energy - optimize use of battery power by minimizing reception and
transmission of data.
▪ Receiving radio signals requires much less energy than transmitting
radio signals.

Mobile Broadcast Data

➢ Mobile support stations can broadcast frequently-requested data

 o Allows mobile hosts to wait for needed data, rather than having to consume
energy transmitting a request

o Supports mobile hosts without transmission capability

➢ A mobile host may optimize energy costs by determining if a query can be answered
using only cached data

o If not then must either;

▪ Wait for the data to be broadcast

▪ Transmit a request for data and must know when the relevant data will
be broadcast.

➢ Broadcast data may be transmitted according to a fixed schedule or a changeable

schedule.

o For changeable schedule: the broadcast schedule must itself be broadcast at a

well-known radio frequency and at well-known time intervals

➢ Data reception may be interrupted by noise

o Use techniques similar to RAID to transmit redundant data (parity)

Personal Databases
Personal database management systems (DBMSs) are tools specifically designed to store, retrieve, and manage large amounts of
data in both numeric and textual formats. DBMSs can be used by end users to manipulate lists of data as well as by other
applications that need to store data for further processing. Virtually all DBMSs found in office productivity suites implement the
so-called “relational” model of DBMS (RDBMS) in which data are stored as tables composed of rows and columns.
Personal RDBMSs, which are distinguished from the more robust “enterprise” RDBMSs, are typically implemented as a file
containing the database that must be read entirely before users can access the tables. Enterprise RDBMSs are implemented as a
set of specialized processes that handle multiple user connections, optimizing the response time and overall performance.
RDBMSs use Structured Query Language (SQL) to create and manage databases through queries. Although SQL is a database
manipulation language in principle intended for end users, it is not a particularly friendly tool for nonprogrammers, especially
when complex queries are involved.

SQL uses a query-by-command approach, in which the user manipulates data in the database using English-like statements such
as SELECT and ORDER BY that are interpreted by the RDBMS. Figure 3 illustrates a simple SQL query that interrogates a
customer database and lists in alphabetical order all the customers in the Boston area with total purchases of more than $500.
Most personal RDBMSs also offer a more user-friendly approach to database manipulation through visual query interfaces. Visual
queries use an approach called query-by-example (QBE), where the user interrogates the database by illustrating the results to be
obtained. The user supplies the example by filling in blanks in one or more screen forms.
Forms correspond to tables in the database that the user has selected for the query, and columns or cells in the form correspond
to columns in a specific table. Specific values and relational operators such as “less than” and “greater than” indicate the data
selection criteria and simple “yes/no” checkboxes indicate whether the corresponding value in a given column is to be displayed.

For example, a form field containing >1000 tells the system that only rows with values greater than 1000 in the corresponding
column are to be retrieved. Figure 4 illustrates how the query above would look using a tool that supports QBE; Fig. 5 illustrates a
hypothetical result. In addition to query manipulation, visual interfaces provide forms to allow users to input and maintain data in
the database. These forms, which are associated with the database tables, also provide basic data validation and formatting.
Advanced personal RDBMSs support both visual and SQL-based queries. Query generators combine the example and command
approaches by generating the appropriate SQL statements behind the scenes from forms that the user visually fills in. Users can
save the queries and then edit the SQL code for minor modifications. These RDBMSs also offer macros to automate repetitive work
and a development environment in which the user can associate queries, forms, and online and printed reports to create database
applications that can be distributed to other users.

Advanced Transaction Processing

Transaction Processing Monitors are systems designed and developed in the 1970s and 1980s to support
a large number of airline terminals from a single system or computer. It was developed for building complex transaction
processing systems with a large number of clients and servers.
Transaction Processing Monitors acts as middlewares (middleware is software that helps and bridges a variety of
communication/connectivity between two or more applications) its main task is to support and handle interactions between
applications on a variety of computer platforms.
Transaction Processing Monitors is also usually known as TP-monitors which provides functionalities such as managing,
deploying, and developing transactional distributed information systems. It controls programs that monitor or manage a
transaction of data as it passes from one stage in a process to another in an organized transaction-oriented manner.
A transaction monitor can be used in various system components such as communication systems, and operating systems for
transaction-protected applications. It provides an operating system on top of the existing operating system that connects
thousands of computers with a pool of shared server processes in real-time.

One of the oldest forms of middleware is from IBM which was made to provide rich runtime environments for online Transaction
Processing applications. Then newer versions of tp monitors came and made work on client-server based they were best at that
time and they are still relevant in today’s world such as processing of banking transactions.

Features:
• It provides the ease to create user interfaces.
• It unwraps the incoming content/data into data packets.
• It provides a continuous row/queue of client requests and responses from the server.
• It routes the client data to servers.
• It gives secure returns to services.
• It hides inner transmission details from programmers.
• Helps in maintaining the load of the program.
Working:

Working of TPM

• Incoming messages go from the queue manager or input queue as shown in the diagram above.
• The durability of the lineup of outgoing information is crucial thus the application server sends a confirmation
message to the output queue as part of a transaction.
• Once the transaction completes, the TP monitor guarantees message is perfectly delivered.
• Many TP monitors have locking and recovery facilities to let application servers implement ACID properties by
themselves.

Components:
• Monitor: It provides a rendering environment that helps in providing security and fast response time to the
system. It is comprised of different tools for the installation of components.
• Communication services: This includes protocols and mechanisms to the system that helps in continuing
messages and peer-to-peer communication.
• Transactional RPC: Provides a basic relational mechanism.
• Transactional services: It provides support for concurrency control, recovery, and transactional programming.

Functions:
• Message Manager
• Request control
• Application Servers
• Process Management
• Inter-Process Communication
• Queuing communications
 • System Management and Recovery
• TP monitors also can perform system management functions related to accounting and security

Benefits:
• TP-Monitors acts as a development platform for applications that run on multiple computers.
• Its software allows the running of TP programs.
• Lines up as a model of middleware in itself (i.e. Message Oriented Middleware)
• Helps to tackle the cycle of events at once without any interruption
• Helps in providing the interface between the input device and DBMS systems.
• It provides user data security and establishes the transactions in a way that they do not get manipulated.

Transaction Management in DBMS

What is a Database Transaction?
A Database Transaction is a logical unit of processing in a DBMS which entails one or more database access operation. In a nutshell,
database transactions represent real-world events of any enterprise.
All types of database access operation which are held between the beginning and end transaction statements are considered as a single
logical transaction in DBMS. During the transaction the database is inconsistent. Only once the database is committed the state is changed
from one consistent state to another.

Database Transaction

Facts about Database Transactions

• A transaction is a program unit whose execution may or may not change the contents of a database.
• The transaction concept in DBMS is executed as a single unit.
• If the database operations do not update the database but only retrieve data, this type of transaction is called a read-only
transaction.
• A successful transaction can change the database from one CONSISTENT STATE to another
 • DBMS transactions must be atomic, consistent, isolated and durable
• If the database were in an inconsistent state before a transaction, it would remain in the inconsistent state after the transaction.

Why do you need concurrency in Transactions?

A database is a shared resource accessed. It is used by many users and processes concurrently. For example, the banking system, railway,
and air reservations systems, stock market monitoring, supermarket inventory, and checkouts, etc.

Not managing concurrent access may create issues like:

• Hardware failure and system crashes

• Concurrent execution of the same transaction, deadlock, or slow performance

States of Transactions
The various states of a transaction concept in DBMS are listed below:

State Transaction types

Active State A transaction enters into an active state when the execution process begins. During this state read or write operations can be perfor

Partially
A transaction goes into the partially committed state after the end of a transaction.
Committed

When the transaction is committed to state, it has already completed its execution successfully. Moreover, all of its changes are rec
Committed State
database permanently.

Failed State A transaction considers failed when any one of the checks fails or if the transaction is aborted while it is in the active state.

Terminated State State of transaction reaches terminated state when certain transactions which are leaving the system can’t be restarted.

State
Transition Diagram for a Database Transaction
Let’s study a state transition diagram that highlights how a transaction moves between these various states.

1. Once a transaction states execution, it becomes active. It can issue READ or WRITE operation.
2. Once the READ and WRITE operations complete, the transactions becomes partially committed state.
3. Next, some recovery protocols need to ensure that a system failure will not result in an inability to record changes in the
transaction permanently. If this check is a success, the transaction commits and enters into the committed state.
4. If the check is a fail, the transaction goes to the Failed state.
5. If the transaction is aborted while it’s in the active state, it goes to the failed state. The transaction should be rolled back to undo
the effect of its write operations on the database.
 6. The terminated state refers to the transaction leaving the system.

What are ACID Properties?

ACID Properties are used for maintaining the integrity of database during transaction processing. ACID in DBMS stands
for Atomicity, Consistency, Isolation, and Durability.

• Atomicity: A transaction is a single unit of operation. You either execute it entirely or do not execute it at all. There cannot be
partial execution.
• Consistency: Once the transaction is executed, it should move from one consistent state to another.
• Isolation: Transaction should be executed in isolation from other transactions (no Locks). During concurrent transaction
execution, intermediate transaction results from simultaneously executed transactions should not be made available to each
other. (Level 0,1,2,3)
• Durability: · After successful completion of a transaction, the changes in the database should persist. Even in the case of system
failures.

ACID Property in DBMS with example:

Below is an example of ACID property in DBMS:

Transaction 1: Begin X=X+50, Y = Y-50 END

Transaction 2: Begin X=1.1*X, Y=1.1*Y END
Transaction 1 is transferring $50 from account X to account Y.

Transaction 2 is crediting each account with a 10% interest payment.

If both transactions are submitted together, there is no guarantee that the Transaction 1 will execute before Transaction 2 or vice
versa. Irrespective of the order, the result must be as if the transactions take place serially one after the other.

Types of Transactions
Based on Application areas

• Non-distributed vs. distributed

• Compensating transactions
• Transactions Timing
• On-line vs. batch

Based on Actions

• Two-step
• Restricted
• Action model

Based on Structure

• Flat or simple transactions: It consists of a sequence of primitive operations executed between a begin and end
operations.
• Nested transactions: A transaction that contains other transactions.
 • Workflow

What is a Schedule?
A Schedule is a process creating a single group of the multiple parallel transactions and executing them one by one. It should preserve the
order in which the instructions appear in each transaction. If two transactions are executed at the same time, the result of one transaction
may affect the output of other.

Example
Initial Product Quantity is 10
Transaction 1: Update Product Quantity to 50
Transaction 2: Read Product Quantity
If Transaction 2 is executed before Transaction 1, outdated information about the product quantity will be read. Hence, schedules
are required.

Parallel execution in a database is inevitable. But, Parallel execution is permitted when there is an equivalence relation amongst
the simultaneously executing transactions. This equivalence is of 3 Types.

RESULT EQUIVALENCE:
If two schedules display the same result after execution, it is called result equivalent schedule. They may offer the same result for some value
and different results for another set of values. For example, one transaction updates the product quantity, while other updates customer
details.

View Equivalence
View Equivalence occurs when the transaction in both the schedule performs a similar action. Example, one transaction inserts product
details in the product table, while another transaction inserts product details in the archive table. The transaction is the same, but the tables
are different.

CONFLICT Equivalence
In this case, two transactions update/view the same set of data. There is a conflict amongst transaction as the order of execution will affect
the output.

What is Serializability?
Serializability is the process of search for a concurrent schedule who output is equal to a serial schedule where transaction are
execute one after the other. Depending on the type of schedules, there are two types of serializability:

• Conflict
• View
Database Management in E-Commerce Firms
It is no secret that the e-commerce industry is changing every year. Earlier, before the invention of the internet, the “brick-and-
mortar” business model was used where customers needed to visit a physical outlet to purchase goods, but this is not the scenario
nowadays. People now have the luxury of buying items from the convenience of their own homes online, and they are now taking
advantage of it. In this 21st century with the ever-increasing number of people participating in electronic commerce, it is necessary
to have advanced information technology to handle this e-commerce ecosystem. In 2018 alone, mobile conversions have
increased by 55% and are expected to reach $175.4 billion in USD sales. Any business, store, or person who actively sells
products online is considered part of this e-commerce system. To serve the customer with a better experience and streamline their
various processes, e-commerce retailers often implement a database to strategically capture vital information. A database is a
collection of data that stores organized information.

The retail business completely depends on databases 24 × 7 for order processing, transactions, inventory, order shipping, etc.
With the existence of a database management system, each organization can attempt to be a lot competitive to skyrocket the
decision-making process, increasing organizational performance in achieving targeted goals.

In an e-commerce application, the main purpose of a database is to store information for retrieving the product details, customer
information, track transactions, and further, maintain the inventory. One of the biggest benefits of using a database for e-
commerce is structuring vast amounts of shop data. When the data is organized in a proper format, it can be accessed more
efficiently by e-commerce applications.

Database plays a very critical and important role in the e-commerce industry, in today’s scenario the reason behind the success of
an e-commerce firm is how much it has optimized its database. Because today’s consumers rely heavily on technology, e-
commerce firms must use it to their advantage.

Main Memory database:

Recent progress in communication and database technologies has changed the user data processing environment. The present
data processing situation is characterized Yuri Breitbart, Ph.D., is Professor, Department of Computer Science, University of
Kentucky, Lexington, KY 40506. Hector Garda-Molina, Ph.D., is Professor, Department of Computer Science, Stanford University,
Stanford, CA 94305. Avi Silberschatz, Ph.D., is Endowed Professor, Department of Computer Sciences, University of Texas, Austin,
TX 78712. (Reprint requests to Dr. Y. Breitbart, Dept. of Computer Science, 915 Patter~n Office Tower, Lexington, ICY 40506.-
00227, USA.) 182 by a growing number of applications that require access to various pre-existing local data sources located in
heterogeneous hardware and software environments distributed among the nodes of a network. Each local data source is a
collection of data and applications that are run under a particular database management system (DBMS) and are
administered/operated under a particular policy or local rules. The data sources are pre-existing in the sense that they were
created independently, in an uncoordinated way and without considering that one day they may need to be integrated. The
DBMSs involved are heterogeneous in the sense that they operate in different environments and may use different underlying data
models, data definition and data manipulation facilities, transaction management and concurrency control mechanisms, and
physical data structures.

A multidatabase is composed of local data sources. Systems that facilitate the logical integration of local data sources are called
multidatabase systems. Logical data integration creates an illusion of a single database system and hides from users the
intricacies of different DBMSs and different access methods. It provides users with uniform access to data contained in various
databases, without migrating the data to a new database, and without requiring the users to know either the location or the
characteristics of different databases and their corresponding DBMSs. Using the multidatabase approach, pre-existing applications
remain operational and new applications may access data in various distributed data sources. A multidatabase system (MDBS) is
built on top of a number of local DBMSs that manage different local data sources. Access to data located in a local data source is
accomplished through transactions. A transaction results from the execution of a user program written in a high level
programming language (e.g., C, or PASCAL).

In this article, we assume that each local DBMS ensures the following properties (called ACID properties) of transactions executed
at its site:

• Atomicity: Either all operations of the transaction are properly reflected in the database or none are.

• Consistency: Execution of a transaction in isolation preserves the consistency of the database. Isolation: Each transaction
assumes that it is executed alone in the system and the local DBMS guarantees that intermediate transaction results are hidden
from other concurrently executed transactions.
• Durability: The values changed by the transaction must persist after the transaction successfully completes. 183 To ensure the
consistency and isolation properties, each local DBMS generates a conflict serializable schedule consisting of operations of local
and global transactions that were executed at its site. To ensure the atomicity and durability properties, each local DBMS uses
some form of recovery scheme (e.g., write-ahead log scheme; Bernstein et al., 1987). The MDBS considers each local DBMS as a
black box that operates autonomously, without the knowledge of either other local DBMSs or the MDBS system. Local autonomy
is the main feature that distinguishes the multidatabase systems from conventional distributed database systems. There are three
main types of autonomy: Design autonomy: No changes can be made to the local DBMS software to accommodate the MDBS
system. Making changes to the existing software of the DBMS is expensive, may result in performance degradation and, further,
may render pre-existing applications inoperative. Execution autonomy: Each local DBMS should retain complete control over the
execution of transactions at its site. An implication of this constraint is that a local DBMS may abort a transaction executing at its
site at any time during its execution, including the time when a global transaction is in the process of being committed by the
MDBS. Communication autonomy: Local DBMSs integrated by the MDBS are not able to coordinate the actions of global
transactions executing at several sites. This constraint implies that local DBMSs do not share their control information with each
other or with the MDBS system. Participating DBMSs may have different autonomy levels. For example, some sites may be willing
to participate in the coordination of a global transaction (low communication autonomy) while others may not (high communication
autonomy). One way to characterize the autonomy levels of sites is to define the interface that each local data source offers to user
transactions. For example, no airline, bank, or car agency would allow external users' transactions to access their data using SQL
statements. On the other hand, internal users' transactions will be allowed to do so. The interfaces can be categorized by the
operations they accept from the MDBS. Here, we illustrate some of the operations that may be available at a site (black box). We
partition these operations into two sets. The first one deals with transaction operations, while the second one deals with status
information.

• Transaction operations: - Begin transaction. The MDBS requests that a new local transaction be initiated. The DBMS typically
returns a transaction identification to be used in later commands. - End transaction. The identified transaction has completed and
may be committed. - Read or Write. Perform indicated action. The action may be low level (e.g., read a record or write a record) or
high level (e.g., withdraw money from an account). Begin and end transaction operations may be implicit in action. - Abort.
Terminate and abort a transaction. Undo all transaction's effects in the database. - Commit. Make all changes that a transaction
made permanent in the database and purge the transaction from the system - Prepare to Commit. The identified transaction has
finished its actions and is ready to commit. DBMS guarantees that transaction will not be unilaterally aborted and waits for commit
or abort decision from the MDBS. - Service Request. The execution of a procedure is requested (e.g., "reserve a seat on a given
flight"). A service request is equivalent to submitting all the actions of a local transaction, from begin transaction to commit, at
once.

• Status information operations: - Get-wait-for-graph. Retrieve the local-wait-for-graph (if one is used) to be used in global
deadlock detection. (A local-wait-for-graph consists of a set of vertices corresponding to transaction names, and a set of edges
specifying a waiting relation between transactions. A cycle in the graph indicates a deadlock situation.) - Get-serialization-order.
Retrieve information regarding the commit order of transactions. (Such an order can be represented by a serialization graph, where
the sets of vertices correspond to transaction names, and the set of edges specify serialization order. A cycle in the serialization
graph indicates a non-serializable schedule.) - Inquire. Find out status (e.g., commit, abort) of a transaction. 185 - Disable
transaction class. Certain types of transactions (e.g., identified by semantic type, or by read or write access sets) are not allowed to
commit at this box.