ODBMS – Object Database Management Systems
In an object database (also object-oriented database), information is represented in the
form of objects as used in object-oriented programming. When database capabilities are
combined with object programming language capabilities, the result is an object database
management system (ODBMS). An ODBMS makes database objects appear as
programming language objects in one or more object programming languages. An
ODBMS extends the programming language with transparently persistent data,
concurrency control, data recovery, associative queries, and other capabilities.
Some object-oriented databases are designed to work well with object-oriented
programming languages such as Python, Java, C#, Visual Basic .NET, C++, Objective-C
and Smalltalk; others have their own programming languages. ODBMSs use exactly the
same model as object-oriented programming languages.
Object databases are generally recommended when there is a business need for high
performance processing on complex data.
ODBMS comparison with traditional models
In today's world, Client-Server applications that rely on a database on the server as a data
store while servicing requests from multiple clients are quite commonplace. Most of
these applications use a Relational Database Management System (RDBMS) as their data
store while using an object oriented programming language for development. This causes
a certain inefficency as objects must be mapped to tuples in the database and vice versa
instead of the data being stored in a way that is consistent with the programming model.
The "impedance mismatch" caused by having to map objects to tables and vice versa has
long been accepted as a necessary performance penalty. This paper is aimed at seeking
out an alternative that avoids this penalty.
Overview of Object Oriented Database Management Systems
An OODBMS is the result of combining object oriented programming principles with
database management principles. Object oriented programming concepts such as
encapsulation, polymorphism and inheritance are enforced as well as database
management concepts such as the ACID properties (Atomicity, Consistency, Isolation
and Durability) which lead to system integrity, support for an ad hoc query language and
secondary storage management systems which allow for managing very large amounts of
data. The Object Oriented Database Manifesto specifically lists the following features as
mandatory for a system to support before it can be called an OODBMS; Complex
objects, Object identity, Encapsulation , Types and Classes , Class or Type Hierarchies,
Overriding, overloading and late binding, Computational completeness, Extensibility,
Persistence, Secondary storage management, Concurrency, Recovery and an Ad Hoc
From the aforementioned description, an OODBMS should be able to store objects that
are nearly indistinguishable from the kind of objects supported by the target
programming language with as little limitation as possible. Persistent objects should
belong to a class and can have one or more atomic types or other objects as attributes.
The normal rules of inheritance should apply with all their benefits including
polymorphism, overridding inherited methods and dynamic binding. Each object has an
object identifier (OID) which used as a way of uniquely identifying a particuler object.
OIDs are permanent, system generated and not based on any of the member data within
the object. OIDs make storing references to other objects in the database simpler but may
cause referential intergrity problems if an object is deleted while other objects still have
references to its OID. An OODBMS is thus a full scale object oriented development
environment as well as a database management system. Features that are common in the
RDBMS world such as transactions, the ability to handle large amounts of data, indexes,
deadlock detection, backup and restoration features and data recovery mechanisms also
exist in the OODBMS world.
A primary feature of an OODBMS is that accessing objects in the database is done in a
transparent manner such that interaction with persistent objects is no different from
interacting with in-memory objects. This is very different from using an RDBMSs in that
there is no need to interact via a query sub-language like SQL nor is there a reason to use
a Call Level Interface such as ODBC, ADO or JDBC. Database operations typically
involve obtaining a database root from the the OODBMS which is usually a data
structure like a graph, vector, hash table, or set and traversing it to obtain objects to
create, update or delete from the database. When a client requests an object from the
database, the object is transferred from the database into the application's cache where it
can be used either as a transient value that is disconnected from its representation in the
database (updates to the cached object do not affect the object in the database) or it can
be used as a mirror of the version in the database in that updates to the object are
reflected in the database and changes to object in the database require that the object is
refetched from the OODBMS.
Comparisons of OODBMSs to RDBMSs
There are concepts in the relational database model that are similar to those in the object
database model. A relation or table in a relational database can be considered to be
analogous to a class in an object database. A tuple is similar to an instance of a class but
is different in that it has attributes but no behaviors. A column in a tuple is similar to a
class attribute except that a column can hold only primitive data types while a class
attribute can hold data of any type. Finally classes have methods which are
computationally complete (meaning that general purpose control and computational
structures are provided while relational databases typically do not have computationally
complete programming capabilities although some stored procedure languages come
Below is a list of advantages and disadvantages of using an OODBMS over an RDBMS
with an object oriented programming language.
1. Composite Objects and Relationships: Objects in an OODBMS can store an
arbitrary number of atomic types as well as other objects. It is thus possible to
have a large class which holds many medium sized classes which themselves hold
many smaller classes, ad infinitum. In a relational database this has to be done
either by having one huge table with lots of null fields or via a number of smaller,
normalized tables which are linked via foreign keys. Having lots of smaller tables
is still a problem since a join has to be performed every time one wants to query
data based on the "Has-a" relationship between the entities. Also an object is a
better model of the real world entity than the relational tuples with regards to
complex objects. The fact that an OODBMS is better suited to handling complex,
interrelated data than an RDBMS means that an OODBMS can outperform an
RDBMS by ten to a thousand times depending on the complexity of the data
2. Class Hierarchy: Data in the real world is usually has hierarchical characteristics.
The ever popular Employee example used in most RDBMS texts is easier to
describe in an OODBMS than in an RDBMS. An Employee can be a Manager or
not, this is usually done in an RDBMS by having a type identifier field or creating
another table which uses foreign keys to indicate the relationship between
Managers and Employees. In an OODBMS, the Employee class is simply a parent
class of the Manager class.
3. Circumventing the Need for a Query Language: A query language is not
necessary for accessing data from an OODBMS unlike an RDBMS since
interaction with the database is done by transparently accessing objects. It is still
possible to use queries in an OODBMS however.
4. No Impedence Mismatch: In a typical application that uses an object oriented
programming language and an RDBMS, a signifcant amount of time is usually
spent mapping tables to objects and back. There are also various problems that
can occur when the atomic types in the database do not map cleanly to the atomic
types in the programming language and vice versa. This "impedance mismatch" is
completely avoided when using an OODBMS.
5. No Primary Keys: The user of an RDBMS has to worry about uniquely
identifying tuples by their values and making sure that no two tuples have the
same primary key values to avoid error conditions. In an OODBMS, the unique
identification of objects is done behind the scenes via OIDs and is completely
invisible to the user. Thus there is no limitation on the values that can be stored in
6. One Data Model: A data model typically should model entities and their
relationships, constraints and operations that change the states of the data in the
system. With an RDBMS it is not possible to model the dynamic operations or
rules that change the state of the data in the system because this is beyond the
scope of the database. Thus applications that use RDBMS systems usually have
an Entity Relationship diagram to model the static parts of the system and a
seperate model for the operations and behaviors of entities in the application.
With an OODBMS there is no disconnect between the database model and the
application model because the entities are just other objects in the system. An
entire application can thus be comprehensively modelled in one UML diagram.
1. Schema Changes: In an RDBMS modifying the database schema either by
creating, updating or deleting tables is typically independent of the actual
application. In an OODBMS based application modifying the schema by creating,
updating or modifying a persistent class typically means that changes have to be
made to the other classes in the application that interact with instances of that
class. This typically means that all schema changes in an OODBMS will involve a
system wide recompile. Also updating all the instance objects within the database
can take an extended period of time depending on the size of the database.
2. Language Dependence: An OODBMS is typically tied to a specific language via a
specific API. This means that data in an OODBMS is typically only accessible
from a specific language using a specific API, which is typically not the case with
3. Lack of Ad-Hoc Queries: In an RDBMS, the relational nature of the data allows
one to construct ad-hoc queries where new tables are created from joining existing
tables then querying them. Since it is currently not possible to duplicate the
semantics of joining two tables by "joining" two classes then there is a loss of
flexibility with an OODBMS. Thus the queries that can be performed on the data
in an OODBMS is highly dependent on the design of the system.
ONLINE ANALYTICAL PROCESSING (OLAP)
Online Analytical Processing, or OLAP is an approach to quickly provide answers to
analytical queries that are multi-dimensional in nature. OLAP is part of the broader
category business intelligence, which also encompasses relational reporting and data
mining. The typical applications of OLAP are in business reporting for sales,
marketing, management reporting, business process management (BPM), budgeting and
forecasting, financial reporting and similar areas. The term OLAP was created as a slight
modification of the traditional database term OLTP (Online Transaction Processing).
Databases configured for OLAP employ a multidimensional data model, allowing for
complex analytical and ad-hoc queries with a rapid execution time. They borrow aspects
of navigational databases and hierarchical databases that are speedier than their relational
The output of an OLAP query is typically displayed in a matrix (or pivot) format. The
dimensions form the row and column of the matrix; the measures, the values.
A data warehouse is a repository of an organization's electronically stored data. Data
warehouses are designed to facilitate reporting and analysis.
This classic definition of the data warehouse focuses on data storage. However, the
means to retrieve and analyze data, to extract, transform and load data, and to manage the
data dictionary are also considered essential components of a data warehousing system.
Many references to data warehousing use this broader context. Thus, an expanded
definition for data warehousing includes business intelligence tools, tools to extract,
transform, and load data into the repository, and tools to manage and retrieve metadata.
In contrast to data warehouses are operational systems which perform day-to-day
Benefits of data warehousing
Some of the benefits that a data warehouse provides are as follows:
A data warehouse provides a common data model for all data of interest
regardless of the data's source. This makes it easier to report and analyze
information than it would be if multiple data models were used to retrieve
information such as sales invoices, order receipts, general ledger charges, etc.
Prior to loading data into the data warehouse, inconsistencies are identified and
resolved. This greatly simplifies reporting and analysis.
Information in the data warehouse is under the control of data warehouse users so
that, even if the source system data is purged over time, the information in the
warehouse can be stored safely for extended periods of time.
Because they are separate from operational systems, data warehouses provide
retrieval of data without slowing down operational systems.
Data warehouses can work in conjunction with and, hence, enhance the value of
operational business applications, notably customer relationship management
Data warehouses facilitate decision support system applications such as trend
reports (e.g., the items with the most sales in a particular area within the last two
years), exception reports, and reports that show actual performance versus goals.
Data warehouse architecture
Architecture, in the context of an organization's data warehousing efforts, is a
conceptualization of how the data warehouse is built. There is no right or wrong
architecture. The worthiness of the architecture can be judged in how the
conceptualization aids in the building, maintenance, and usage of the data warehouse.
One possible simple conceptualization of a data warehouse architecture consists of the
following interconnected layers:
Operational database layer
The source data for the data warehouse - An organization's ERP systems fall into
Informational access layer
The data accessed for reporting and analyzing and the tools for reporting and
analyzing data - Business intelligence tools fall into this layer. And the Inmon-
Kimball differences about design methodology, discussed later in this article,
have to do with this layer.
Data access layer
The interface between the operational and informational access layer - Tools to
extract, transform, load data into the warehouse fall into this layer.
The data directory - This is often usually more detailed than an operational system
data directory. There are dictionaries for the entire warehouse and sometimes
dictionaries for the data that can be accessed by a particular reporting and analysis
Data warehouses versus operational systems
Operational systems are optimized for preservation of data integrity and speed of
recording of business transactions through use of database normalization and an entity-
relationship model. Operational system designers generally follow the Codd rules of data
normalization in order to ensure data integrity. Codd defined five increasingly stringent
rules of normalization. Fully normalized database designs (that is, those satisfying all five
Codd rules) often result in information from a business transaction being stored in dozens
to hundreds of tables. Relational databases are efficient at managing the relationships
between these tables. The databases have very fast insert/update performance because
only a small amount of data in those tables is affected each time a transaction is
processed. Finally, in order to improve performance, older data are usually periodically
purged from operational systems.
Data warehouses are optimized for speed of data retrieval. Frequently data in data
warehouses are denormalised via a dimension-based model. Also, to speed data retrieval,
data warehouse data are often stored multiple times - in their most granular form and in
summarized forms called aggregates. Data warehouse data are gathered from the
operational systems and held in the data warehouse even after the data has been purged
from the operational systems.