Database

From Wikipedia, the free encyclopedia

This article is about managing and structuring the collections of data held on computers. For a fuller discussion
of DBMS software, see database management system. For databased content libraries, see  online database.
For other uses, see Database (disambiguation).

It has been suggested that Database administrator be merged into this article or

section. (Discuss)

A database consists of an organized collection of data for one or more uses, typically in digital form. One way
of classifying databases involves the type of their contents, for example: bibliographic, document-text,
statistical. Digital databases are managed using database management systems, which store database
contents, allowing data creation and maintenance, and search and other access.

Contents
 [hide]

1 Architecture

2 Database management systems

o 2.1 Components of DBMS

 2.1.1 RDBMS

components

 2.1.2 ODBMS

components

3 Types

o 3.1 Operational database

o 3.2 Data warehouse

o 3.3 Analytical database

o 3.4 Distributed database

o 3.5 End-user database

o 3.6 External database

o 3.7 Hypermedia databases

4 Models

o 4.1 Post-relational database

models

o 4.2 Object database models

 5 Storage structures

6 Indexing

7 Transactions

o 7.1 The ACID rules

o 7.2 Concurrency control and

locking

 7.2.1 Isolation

 7.2.2 Lock types

 7.2.3 Lock

granularity

 7.2.4 Deadlocks

8 Replication

9 Security

o 9.1 Confidentiality

10 See also

11 References

12 Further reading

13 External links

[edit]Architecture

Database architecture consists of three levels, external, conceptual and internal. Clearly separating the three

levels was a major feature of the relational database model that dominates 21st century databases.[1]

The external level defines how users understand the organization of the data. A single database can have any
number of views at the external level. The internal level defines how the data is physically stored and
processed by the computing system. Internal architecture is concerned with cost, performance, scalability and
other operational matters. The conceptual is a level of indirection between internal and external. It provides a
common view of the database that is uncomplicated by details of how the data is stored or managed, and that
can unify the various external views into a coherent whole.[1]

[edit]Database management systems

Main article:  Database management system

A database management system (DBMS) consists of software that operates databases, providing storage,
access, security, backup and other facilities. Database management systems can be categorized according to
the database model that they support, such as relational or XML, the type(s) of computer they support, such as
a server cluster or a mobile phone, thequery language(s) that access the database, such as SQL or XQuery,
performance trade-offs, such as maximum scale or maximum speed or others. Some DBMS cover more than
one entry in these categories, e.g., supporting multiple query languages.Examples of some commonly used
DBMS are MySQL, PostgreSQL, Microsoft Access, SQL Server, FileMaker,Oracle, RDBMS, dBASE,
Clipper,FoxPro,etc. Almost every database software comes with an Open Database Connectivity (ODBC)
driver that allows the database to integrate with other databases.

[edit]Components of DBMS
Most DBMS as of 2009 implement a relational model.[2] Other DBMS systems, such as Object DBMS, offer
specific features for more specialized requirements. Their components are similar, but not identical.

[edit]RDBMS components

 Sublanguages— Relational DBMS (RDBMS) include Data Definition

Language (DDL) for defining the structure of the database, Data Control
Language (DCL) for defining security/access controls, and Data Manipulation
Language (DML) for querying and updating data.

 Interface drivers—These drivers are code libraries that provide methods to

prepare statements, execute statements, fetch results, etc. Examples
include ODBC, JDBC,MySQL/PHP, FireBird/Python.

 SQL engine—This component interprets and executes the DDL, DCL,

and DML statements. It includes three major components (compiler, optimizer,
and executor).

 Transaction engine—Ensures that multiple SQL statements either succeed

or fail as a group, according to application dictates.

 Relational engine—Relational objects such as Table, Index, and Referential

integrity constraints are implemented in this component.

 Storage engine—This component stores and retrieves data from secondary

storage, as well as managing transaction commit and rollback, backup and
recovery, etc.
[edit]ODBMS components

Object DBMS (ODBMS) has transaction and storage components that are analogous to those in an RDBMS.
Some ODBMS handle DDL, DCL and update tasks differently. Instead of using sublanguages, they provide
APIs for these purposes. They typically include a sublanguage and accompanying engine for processing
queries with interpretive statements analogous to but not the same as SQL. Example object query languages
are OQL, LINQ, JDOQL, JPAQL and others. The query engine returns collections of objects instead of
relational rows.

[edit]Types

This section does not cite any references or sources.

Please help improve this article by adding citations to reliable sources. Unsourced material may
be challenged and removed. (August 2010)

[edit]Operational database
These databases store detailed data about the operations of an organization. They are typically organized by
subject matter, process relatively high volumes of updates usingtransactions. Essentially every major
organization on earth uses such databases. Examples include customer databases that record contact, credit,
and demographic information about a business' customers, personnel databases that hold information such as
salary, benefits, skills data about employees, manufacturing databases that record details about product
components, parts inventory, and financial databases that keep track of the organization's money, accounting
and financial dealings.

[edit]Data warehouse
Data warehouses archive modern data from operational databases and often from external sources such as
market research firms. Often operational data undergoes transformation on its way into the warehouse, getting
summarized, anonymized, reclassified, etc. The warehouse becomes the central source of data for use by
managers and other end-users who may not have access to operational data. For example, sales data might
be aggregated to weekly totals and converted from internal product codes to use UPC codes so that it can be
compared with ACNielsen data.Some basic and essential components of data warehousing include retrieving
and analyzing data, transforming,loading and managing data so as to make it available for further use.

[edit]Analytical database
Analysts may do their work directly against, a data warehouse, or create a separate analytic database
for Online Analytical Processing. For example, a company might extract sales records for analyzing the
effectiveness of advertising and other sales promotions at an aggregate level.

[edit]Distributed database
These are databases of local work-groups and departments at regional offices, branch offices, manufacturing
plants and other work sites. These databases can include segments of both common operational and common
user databases, as well as data generated and used only at a user’s own site.

[edit]End-user database
These databases consist of data developed by individual end-users. Examples of these are collections of
documents in spreadsheets, word processing and downloaded files, or even managing their personal baseball
card collection.

[edit]External database
These databases contain data collected for use across multiple organizations, either freely or via subscription.
The Internet Movie Database is one example.

[edit]Hypermedia databases
The Worldwide web can be thought of as a database, albeit one spread across millions of independent
computing systems. Web browsers "process" this data one page at a time, whileweb crawlers and other
software provide the equivalent of database indexes to support search and other activities.

[edit]Models

Main article:  Database model

[edit]Post-relational database models

Products offering a more general data model than the relational model are sometimes classified as post-
relational.[3] Alternate terms include "hybrid database", "Object-enhanced RDBMS" and others. The data model
in such products incorporates relations but is not constrained by E.F. Codd's Information Principle, which
requires that

all information in the database must be cast explicitly in terms of values in relations and in no other way [4]

Some of these extensions to the relational model integrate concepts from technologies that pre-date the
relational model. For example, they allow representation of a directed graph withtrees on the nodes.

Some post-relational products extend relational systems with non-relational features. Others arrived in much
the same place by adding relational features to pre-relational systems. Paradoxically, this allows products that
are historically pre-relational, such as PICK and MUMPS, to make a plausible claim to be post-relational.

[edit]Object database models

Main article:  Object database

In recent years, the object-oriented paradigm has been applied in areas such as engineering and spatial
databases, telecommunications and in various scientific domains. The conglomeration of object oriented
programming and database technology led to this new kind of database. These databases attempt to bring the
database world and the application-programming world closer together, in particular by ensuring that the
database uses the same type system as the application program. This aims to avoid the overhead (sometimes
referred to as the impedance mismatch) of converting information between its representation in the database
(for example as rows in tables) and its representation in the application program (typically as objects). At the
same time, object databases attempt to introduce key ideas of object programming, such
as encapsulation and polymorphism, into the world of databases.

A variety of these ways have been tried[by whom?] for storing objects in a database. Some products have
approached the problem from the application-programming side, by making the objects manipulated by the
program persistent. This also typically requires the addition of some kind of query language, since conventional
programming languages do not provide language-level functionality for finding objects based on their
information content. Others[which?] have attacked the problem from the database end, by defining an object-
oriented data model for the database, and defining a database programming language that allows full
programming capabilities as well as traditional query facilities.

[edit]Storage structures

Main article:  Database storage structures

Databases may store relational tables/indexes in memory or on hard disk in one of many forms:

 ordered/unordered flat files

 ISAM

 heaps

 hash buckets

 logically-blocked files

 B+ trees

The most commonly used[citation needed] are B+ trees and ISAM.

Object databases use a range of storage mechanisms. Some use virtual memory-mapped files to make the
native language (C++, Java etc.) objects persistent. This can be highly efficient but it can make multi-language
access more difficult. Others disassemble objects into fixed- and varying-length components that are then
clustered in fixed sized blocks on disk and reassembled into the appropriate format on either the client or
server address space. Another popular technique involves storing the objects in tuples (much like a relational
database) which the database server then reassembles into objects for the client. [citation needed]

Other techniques include clustering by category (such as grouping data by month, or location), storing pre-
computed query results, known as materialized views, partitioning data by range (e.g., a data range) or by
hash.

Memory management and storage topology can be important design choices for database designers as well.
Just as normalization is used to reduce storage requirements and improve database designs, conversely
denormalization is often used to reduce join complexity and reduce query execution time. [5]
[edit]Indexing

Main article:  Index (database)

Indexing is a technique for improving database performance. The many types of index share the common
property that they eliminate the need to examine every entry when running a query. In large databases, this
can reduce query time/cost by orders of magnitude. The simplest form of index is a sorted list of values that
can be searched using a binary search with an adjacent reference to the location of the entry, analogous to the
index in the back of a book. The same data can have multiple indexes (an employee database could be
indexed by last name and hire date.)

Indexes affect performance, but not results. Database designers can add or remove indexes without changing
application logic, reducing maintenance costs as the database grows and database usage evolves.

Given a particular query, the DBMS' query optimizer is responsible for devising the most efficient strategy for
finding matching data. The optimizer decides which index or indexes to use, how to combine data from different
parts of the database, how to provide data in the order requested, etc.

Indexes can speed up data access, but they consume space in the database, and must be updated each time
the data is altered. Indexes therefore can speed data access but slow data maintenance. These two properties
determine whether a given index is worth the cost.

[edit]Transactions

Main article:  Database transaction

This section may stray from the topic of the article into the topic of another
article, Database management system. Please helpimprove this section or discuss this
issue on the talk page.

As every software system, a DBMS operates in a faulty computing environment and prone to failures of many
kinds. A failure can corrupt the respective database unless special measures are taken to prevent this. A
DBMS achieves certain levels of fault tolerance by encapsulating in database transactions units of work
(executed programs) performed upon the respective database.

[edit]The ACID rules

Main article:  ACID

Most DBMS provide some form of support for transactions, which allow multiple data items to be updated in a
consistent fashion, such that updates that are part of a transaction succeed or fail in unison. The so-
called ACID rules, summarized here, characterize this behavior:
  Atomicity: Either all the data changes in a transaction must happen, or none of
them. The transaction must be completed, or else it must be undone (rolled
back).

 Consistency: Every transaction must preserve the declared consistency rules

for the database.

 Isolation: Two concurrent transactions cannot interfere with one another.

Intermediate results within one transaction must remain invisible to other
transactions. The most extreme form of isolation is serializability, meaning that
transactions that take place concurrently could instead be performed in some
series, without affecting the ultimate result.

 Durability: Completed transactions cannot be aborted later or their results

discarded. They must persist through (for instance) DBMS restarts.

In practice, many DBMSs allow the selective relaxation of these rules to balance perfect behavior with optimum
performance.

[edit]Concurrency control and locking

Main article:  Concurrency control

Concurrency control is essential for the correctness of transactions executed concurrently in a DBMS, which is
the common execution mode for performance reasons. The main concern and goal of concurrency control
is isolation.

[edit]Isolation

Isolation refers to the ability of one transaction to see the results of other transactions. Greater isolation
typically reduces performance and/or concurrency, leading DBMSs to provide administrative options to reduce
isolation. For example, in a database that analyzes trends rather than looking at low-level detail, increased
performance might justify allowing readers to see uncommitted changes ("dirty reads".)

A common way to achieve isolation is by locking. When a transaction modifies a resource, the DBMS stops
other transactions from also modifying it, typically by locking it. Locks also provide one method of ensuring that
data does not change while a transaction is reading it or even that it doesn't change until a transaction that
once read it has completed.

[edit]Lock types

Locks can be shared[6] or exclusive, and can lock out readers and/or writers. Locks can be created implicitly by
the DBMS when a transaction performs an operation, or explicitly at the transaction's request.
Shared locks allow multiple transactions to lock the same resource. The lock persists until all such transactions
complete. Exclusive locks are held by a single transaction and prevent other transactions from locking the
same resource.

Read locks are usually shared, and prevent other transactions from modifying the resource. Write locks are
exclusive, and prevent other transactions from modifying the resource. On some systems, write locks also
prevent other transactions from reading the resource.

The DBMS implicitly locks data when it is updated, and may also do so when it is read. Transactions explicitly
lock data to ensure that they can complete without complications. Explicit locks may be useful for some
administrative tasks.[7][8]

Locking can significantly affect database performance, especially with large and complex transactions in highly
concurrent environments.

[edit]Lock granularity

Locks can be coarse, covering an entire database, fine-grained, covering a single data item, or intermediate
covering a collection of data such as all the rows in a RDBMS table.

[edit]Deadlocks

Deadlocks occur when two transactions each require data that the other has already locked exclusively.
Deadlock detection is performed by the DBMS, which then aborts one of the transactions and allows the other
to complete.

[edit]Replication

Main article:  Database replication

Database replication involves maintaining multiple copies of a database on different computers, to allow more
users to access it, or to allow a secondary site to immediately take over if the primary site stops working. Some
DBMS piggyback replication on top of their transaction logging facility, applying the primary's log to the
secondary in near real-time. Database clustering is a related concept for handling larger databases and user
communities by employing a cluster of multiple computers to host a single database that can use replication as
part of its approach.[9][10]

[edit]Security

Main article:  Database security

Database security denotes the system, processes, and procedures that protect a database from unauthorized
activity.

DBMSs usually enforce security through access control, auditing, and encryption:

  Access control manages who can connect to the database
via authentication and what they can do via authorization.

 Auditing records information about database activity: who, what, when, and
possibly where.

 Encryption protects data at the lowest possible level by storing and possibly
transmitting data in an unreadable form. The DBMS encrypts data when it is
added to the database and decrypts it when returning query results. This
process can occur on the client side of a network connection to prevent
unauthorized access at the point of use.

A relational database management system (RDBMS) is a database management system (DBMS) that

is based on the relational model as introduced by E. F. Codd. Most popular commercial and open source
databases currently in use are based on the relational database model.

A short definition of an RDBMS may be a DBMS in which data is stored in the form of tables and the
relationship among the data is also stored in the form of tables.

E. F. Codd introduced the term in his seminal paper "A Relational Model of Data for Large Shared Data
Banks", published in 1970. In this paper and later papers he defined what he meant by relational. One
well-known definition of what constitutes a relational database system is Codd's 12 rules. However, many
of the early implementations of the relational model did not conform to all of Codd's rules, so the term
gradually came to describe a broader class of database systems. At a minimum, these systems:

 presented the data to the user as relations (a presentation in tabular form, i.e. as
a collection of tables with each table consisting of a set of rows and columns, can satisfy this
property)
 provided relational operators to manipulate the data in tabular form

The first systems that were relatively faithful implementations of the relational model were from the
University of Michigan; Micro DBMS (1969) and from IBM UK Scientific Centre at Peterlee; IS1 (1970–72)
and its followon PRTV (1973–79). The first system sold as an RDBMS was Multics Relational Data Store,
first sold in 1978. Others have been Berkeley Ingres QUEL and IBM BS12.

The most popular definition of an RDBMS is a product that presents a view of data as a collection of rows
and columns, even if it is not based strictly upon relational theory. By this definition, RDBMS products
typically implement some but not all of Codd's 12 rules.

A second, theory-based school of thought argues that if a database does not implement all of Codd's
rules (or the current understanding on the relational model, as expressed byChristopher J Date, Hugh
Darwen and others), it is not relational. This view, shared by many theorists and other strict adherents to
Codd's principles, would disqualify most DBMSs as not relational. For clarification, they often refer to
some RDBMSs as Truly-Relational Database Management Systems (TRDBMS), naming others Pseudo-
Relational Database Management Systems (PRDBMS).

Data type:
n computer programming, a data type (or datatype) is a classification identifying one of various types of
data, such as floating-point, integer, or Boolean, stating the possible values for that type, the operations
that can be done on that type, and the way the values of that type are stored

oodbms..:
An object database (also object-oriented database) is a database model in which information is
represented in the form of objects as used in object-oriented programming.

Example of an object-oriented model.[1]

Object databases are a niche field within the broader DBMS market dominated by relational database
management systems(RDBMS). Object databases have been considered since the early 1980s and
1990s but they have made little impact on mainstream commercial data processing, though there is some
usage in specialized areas.

Contents
 [hide]

1 Overview

2 History
 3 Adoption of object

databases

4 Technical features

5 Standards

6 Advantages and

disadvantages

7 See also

8 References

9 External links

[edit]Overview

When database capabilities are combined with object-oriented (OO) programming language capabilities,
the result is an object database management system (ODBMS).

Today’s trend in programming languages is to utilize objects, thereby making OODBMS ideal for OO
programmers because they can develop the product, store them as objects, and can replicate or modify
existing objects to make new objects within the OODBMS. Information today includes not only data but
video, audio, graphs, and photos which are considered complex data types. Relational DBMS aren’t
natively capable of supporting these complex data types. [citation needed] By being integrated with the
programming language, the programmer can maintain consistency within one environment because both
the OODBMS and the programming language will use the same model of representation. Relational
DBMS projects using complex data types would have to be divided into two separate tasks: the database
model and the application.

As the usage of web-based technology increases with the implementation of Intranets and extranets,
companies have a vested interest in OODBMS to display their complex data. Using a DBMS that has
been specifically designed to store data as objects gives an advantage to those companies that are
geared towards multimedia presentation or organizations that utilize computer-aided design (CAD) [2].

Some object-oriented databases are designed to work well with object-oriented programming

languages such as Ruby, Python, Perl, Java, C#, Visual Basic .NET, C++, Objective-C andSmalltalk;
others have their own programming languages. ODBMSs use exactly the same model as object-oriented
programming languages.

[edit]History

Object database management systems grew out of research during the early to mid-1970s into having
intrinsic database management support for graph-structured objects. The term "object-oriented database
system" first appeared around 1985.[3] Notable research projects included Encore-Ob/Server (Brown
University), EXODUS (University of Wisconsin–Madison), IRIS (Hewlett-Packard), ODE (Bell Labs),
ORION (Microelectronics and Computer Technology Corporation or MCC), Vodak (GMD-IPSI), and
Zeitgeist (Texas Instruments). The ORION project had more published papers than any of the other
efforts. Won Kim of MCC compiled the best of those papers in a book published by The MIT Press. [4]

Early commercial products included Gemstone (Servio Logic, name changed to GemStone Systems),

Gbase (Graphael), and Vbase (Ontologic). The early to mid-1990s saw additional commercial products
enter the market. These included ITASCA (Itasca Systems), Jasmine (Fujitsu, marketed by Computer
Associates), Matisse (Matisse Software), Objectivity/DB(Objectivity, Inc.), ObjectStore (Progress
Software, acquired from eXcelon which was originally Object Design), ONTOS (Ontos, Inc., name
changed from Ontologic), O2[5] (O2Technology, merged with several companies, acquired by Informix,
which was in turn acquired by IBM), POET (now FastObjects from Versant which acquired Poet
Software), Versant Object Database (Versant Corporation), VOSS (Logic Arts) and JADE (Jade Software
Corporation). Some of these products remain on the market and have been joined by new open source
and commercial products such as InterSystems CACHÉ (see the product listings below).

Object database management systems added the concept of persistence to object programming
languages. The early commercial products were integrated with various languages: GemStone
(Smalltalk), Gbase (LISP), Vbase (COP) and VOSS (Virtual Object Storage System for Smalltalk). For
much of the 1990s, C++ dominated the commercial object database management market. Vendors
added Java in the late 1990s and more recently, C#.

Starting in 2004, object databases have seen a second growth period when open source object
databases emerged that were widely affordable and easy to use, because they are entirely written in
OOP languages like Smalltalk, Java or C#, such as db4o (db4objects), DTS/S1 from Obsidian Dynamics
and Perst (McObject), available under dual open source and commercial licensing.

[edit]Adoption of object databases

Object databases based on persistent programming acquired a niche in application areas such as
engineering and spatial databases, telecommunications, and scientific areas such ashigh energy
physics and molecular biology. They have made little impact on mainstream commercial data processing,
though there is some usage in specialized areas of financial services.[6] It is also worth noting that object
databases held the record for the World's largest database (being the first to hold over 1000 terabytes at
Stanford Linear Accelerator Center)[7] and the highest ingest rate ever recorded for a commercial
database at over one Terabyte per hour.
Another group of object databases focuses on embedded use in devices, packaged software, and real-
time systems.

[edit]Technical features
Most object databases also offer some kind of query language, allowing objects to be found by a
more declarative programming approach. It is in the area of object query languages, and the integration of
the query and navigational interfaces, that the biggest differences between products are found. An
attempt at standardization was made by the ODMG with the Object Query Language, OQL.

Access to data can be faster because joins are often not needed (as in a tabular implementation of
a relational database). This is because an object can be retrieved directly without a search, by following
pointers. (It could, however, be argued that "joining" is a higher-level abstraction of pointer following.)

Another area of variation between products is in the way that the schema of a database is defined. A
general characteristic, however, is that the programming language and the database schema use the
same type definitions.

Multimedia applications are facilitated because the class methods associated with the data are
responsible for its correct interpretation.

Many object databases, for example VOSS, offer support for versioning. An object can be viewed as the
set of all its versions. Also, object versions can be treated as objects in their own right. Some object
databases also provide systematic support for triggers and constraints which are the basis of active
databases.

The efficiency of such a database is also greatly improved in areas which demand massive amounts of
data about one item. For example, a banking institution could get the user's account information and
provide them efficiently with extensive information such as transactions, account information entries etc.
The Big O Notation for such a database paradigm drops from O(n) to O(1), greatly increasing efficiency in
these specific cases.

[edit]Standards

The Object Data Management Group (ODMG) was a consortium of object database and object-relational
mapping vendors, members of the academic community, and interested parties. Its goal was to create a
set of specifications that would allow for portable applications that store objects in database management
systems. It published several versions of its specification. The last release was ODMG 3.0. By 2001, most
of the major object database and object-relational mapping vendors claimed conformance to the ODMG
Java Language Binding. Compliance to the other components of the specification was mixed. In 2001, the
ODMG Java Language Binding was submitted to the Java Community Process as a basis for the Java
Data Objects specification. The ODMG member companies then decided to concentrate their efforts on
the Java Data Objects specification. As a result, the ODMG disbanded in 2001.

Many object database ideas were also absorbed into SQL:1999 and have been implemented in varying
degrees in object-relational database products.

In 2005 Cook, Rai, and Rosenberger proposed to drop all standardization efforts to introduce additional
object-oriented query APIs but rather use the OO programming language itself, i.e., Java and .NET, to
express queries. As a result, Native Queries emerged. Similarly, Microsoft announced Language
Integrated Query (LINQ) and DLINQ, an implementation of LINQ, in September 2005, to provide close,
language-integrated database query capabilities with its programming languages C# and VB.NET 9.

In February 2006, the Object Management Group (OMG) announced that they had been granted the right
to develop new specifications based on the ODMG 3.0 specification and the formation of the Object
Database Technology Working Group (ODBT WG). The ODBT WG plans to create a set of standards that
incorporates advances in object database technology (e.g., replication), data management (e.g., spatial
indexing), and data formats (e.g., XML) and to include new features into these standards that support
domains where object databases are being adopted (e.g., real-time systems).

On January 2007 the World Wide Web Consortium gave final recommendation status to

the XQuery language. XQuery has enabled a new class of applications that managed hierarchical data
built around the XRX web application architecture that also provide many of the advantages of object
databases. In addition XRX applications benefit by transporting XML directly to client applications such
as XForms without changing data structures.

[edit]Advantages and disadvantages

This section may contain original research. Please improve it by verifying the claims
made and adding references. Statements consisting only of original research may be
removed. More details may be available on the talk page. (October 2008)

The main benefit of creating a database with objects as data is speed. OODBMS are faster than relational
DBMS because data isn’t stored in relational rows and columns but as objects [8]. Objects have a many to
many relationship and are accessed by the use of pointers. Pointers are linked to objects to establish
relationships. Another benefit of OODBMS is that it can be programmed with small procedural differences
without affecting the entire system[9]. This is most helpful for those organizations that have data
relationships that aren’t entirely clear or need to change these relations to satisfy the new business
requirements.

Benchmarks between OODBMSs and RDBMSs have shown that an OODBMS can be clearly superior for
certain kinds of tasks. The main reason for this is that many operations are performed
using navigational rather than declarative interfaces, and navigational access to data is usually
implemented very efficiently by following pointers.

Compared to relational databases another major advantage of OODBMSs is that they do not need
any object relational mapping layer and object marshaling to map the application object model to the
database object model. In RDBMS, this mapping is also source of the impedance mismatch, which does
not occur when using OODBMS. Avoiding this layer also improves performance and saves effort for
implementation and maintenance.

Critics of navigational database-based technologies like ODBMS suggest that pointer-based techniques
are optimized for very specific "search routes" or viewpoints; for general-purpose queries on the same
information, pointer-based techniques will tend to be slower and more difficult to formulate than relational.
Thus, navigation appears to simplify specific known uses at the expense of general, unforeseen, and
varied future uses.[citation needed] However, with suitable language support, direct object references may be
maintained in addition to normalised, indexed aggregations, allowing both kinds of access; furthermore, a
persistent language may index aggregations on whatever its content elements return from a call to some
arbitrary object access method, rather than only on attribute value, which allows a query to 'drill down' into
complex data structures.

Other things that work against ODBMS seem to be the lack of interoperability with a great number of
tools/features that are taken for granted in the SQL world, including but not limited to industry
standard connectivity, reporting tools, OLAP tools, and backup and recovery standards.[citation
needed]
 Additionally, object databases lack a formal mathematical foundation, unlike the relational model,
and this in turn leads to weaknesses in their query support. However, this objection is offset by the fact
that some ODBMSs fully support SQL in addition to navigational access, e.g. Objectivity/SQL++, Matisse,
and InterSystems CACHÉ. Effective use may require compromises to keep both paradigms in sync.

In fact there is an intrinsic tension between the notion of encapsulation, which hides data and makes it
available only through a published set of interface methods, and the assumption underlying much
database technology, which is that data should be accessible to queries based on data content rather
than predefined access paths. Database-centric thinking tends to view the world through a declarative
and attribute-driven viewpoint, while OOP tends to view the world through a behavioral viewpoint,
maintaining entity-identity independently of changing attributes. This is one of the many impedance
mismatch issues surrounding OOP and databases.

Although some commentators have written off object database technology as a failure, the essential
arguments in its favor remain valid, and attempts to integrate database functionality more closely into
object programming languages continue in both the research and the industrial communitie
Oodbms:
An object-relational database (ORD), or object-relational database management
system (ORDBMS), is a database management system (DBMS) similar to a relational database, but with
an object-oriented database model: objects, classes and inheritance are directly supported in database
schemas and in the query language. In addition, it supports extension of the data model with
custom data-types and methods.

Example of an Object-Oriented Database Model.[1]

An object-relational database can be said to provide a middle ground between relational databases
and object-oriented databases (OODBMS). In object-relational databases, the approach is essentially that
of relational databases: the data resides in the database and is manipulated collectively with queries in a
query language; at the other extreme are OODBMSes in which the database is essentially a persistent
object store for software written in an object-oriented programming language, with a programming API for
storing and retrieving objects, and little or no specific support for querying.

Contents
 [hide]

1 Overview

2 History

3 Comparison to

RDBMS

4 See also

5 References

6 External links
[edit]Overview

One aim for the Object-relational database is to bridge the gap between conceptual data
modeling techniques such as Entity-relationship diagram (ERD) and object-relational mapping(ORM),
which often use classes and inheritance, and relational databases, which do not directly support them.

Another, related, aim is to bridge the gap between relational databases and the object-oriented modeling
techniques used in programming languages such as Java, C++, Visual Basic .NET or C#. However, a
more popular alternative for achieving such a bridge is to use a standard relational database systems with
some form of ORM software.

Whereas traditional RDBMS or SQL-DBMS products focused on the efficient management of data drawn
from a limited set of data-types (defined by the relevant language standards), an object-relational DBMS
allows software-developers to integrate their own types and the methods that apply to them into the
DBMS. ORDBMS technology aims to allow developers to raise the level of abstraction at which they view
the problem domain.[clarification needed] This goal is not universally shared; proponents of relational databases
often argue that object-oriented specification lowers the abstraction level.

Many SQL ORDBMSs on the market today are extensible with user-defined types (UDT) and custom-
written functions (e.g. stored procedures). Some (e.g. Microsoft SQL Server) allow such functions to be
written in object-oriented programming languages, but this by itself doesn't make them object-oriented
databases; in an object-oriented database, object orientation is a feature of the data model.

[edit]History

Object-relational database management systems grew out of research that occurred in the early 1990s.
That research extended existing relational database concepts by adding objectconcepts. The researchers
aimed to retain a declarative query-language based on predicate calculus as a central component of the
architecture. Probably the most notable research project, Postgres (UC Berkeley), spawned two products
tracing their lineage to that research: Illustra and PostgreSQL.

In the mid-1990s, early commercial products appeared. These included Illustra [2] (Illustra Information
Systems, acquired by Informix Software which was in turn acquired by IBM),Omniscience (Omniscience
Corporation, acquired by Oracle Corporation and became the original Oracle Lite), and UniSQL (UniSQL,
Inc., acquired by KCOMS). Ukrainian developer Ruslan Zasukhin, founder of Paradigma Software, Inc.,
developed and shipped the first version of Valentina database in the mid-1990s as a C++ SDK. By the
next decade, PostgreSQL had become a commercially viable database and is the basis for several
products today which maintain its ORDBMS features.

Computer scientists came to refer to these products as "object-relational database management systems"
or ORDBMSs.[3]
Many of the ideas of early object-relational database efforts have largely become incorporated
into SQL:1999. In fact, any product that adheres to the object-oriented aspects of SQL:1999 could be
described as an object-relational database management product. For example, IBM's DB2, Oracle
database, and Microsoft SQL Server, make claims to support this technology and do so with varying
degrees of success.

[edit]Comparison to RDBMS
An RDBMS might commonly involve SQL statements such as these:
CREATE TABLE Customers (
Id CHAR(12) NOT NULL PRIMARY KEY,
Surname VARCHAR(32) NOT NULL,
FirstName VARCHAR(32) NOT NULL,
DOB DATE NOT NULL
);
SELECT InitCap(Surname) || ', ' || InitCap(FirstName)
FROM Customers
WHERE Month(DOB) = Month(getdate())
AND Day(DOB) = Day(getdate())

Most current SQL databases allow the crafting of custom functions, which would allow the query to
appear as:
SELECT Formal(Id)
FROM Customers
WHERE Birthday(Id) = Today()

In an object-relational database, one might see something like this, with user-defined data-types and
expressions such as BirthDay():
CREATE TABLE Customers (
Id Cust_Id NOT NULL PRIMARY KEY,
Name PersonName NOT NULL,
DOB DATE NOT NULL
);
SELECT Formal( C.Id )
FROM Customers C
WHERE BirthDay ( C.DOB ) = TODAY;

The object-relational model can offer another advantage in that the database can make use of the
relationships between data to easily collect related records. In an address bookapplication, an additional
table would be added to the ones above to hold zero or more addresses for each user. Using a traditional
RDBMS, collecting information for both the user and their address requires a "join":
SELECT InitCap(C.Surname) || ', ' || InitCap(C.FirstName), A.city
 FROM Customers C JOIN Addresses A ON A.Cust_Id=C.Id -- the join
WHERE A.city="New York"

The same query in an object-relational database appears more simply:

SELECT Formal( C.Name )
FROM Customers C
WHERE C address.city="New York" -- the linkage is 'understood' by the
ORDB