1.7.

5 Object-Oriented Database Management System

The Object-Oriented Database Management Systems (OODBMS) 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. In an object-oriented database (also called object 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-oriented database management system. An OODBMS makes database
objects appear as programming language objects in one or more object programming
languages. An OODBMS 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. OODBMSs use exactly
the same model as object-oriented programming languages.

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 with
the Object Query Language, OQL. In OODBMS, acccess 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.
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.

The hierarchical and network database systems both represent the first-generation of
DBMSs. The relational database system, proposed by E. Codd represents the second-
generation of DBMSs. It has had a fundamental effect on the DBMS community and
there are now over one hundred relational DBMSs. The third-generation of DBMSs is
represented by the Object-Relational DBMS and the Object-Oriented DBMS.

1.8 The Three-Tier ANSI-SPARC Architecture of DBMS

The three-tier architecture of DBMS proposed by the American National Standards
Institute (ANSI) Standards Planning and Requirements Committee (SPARC) in 1975
provides three different levels of abstraction, that is, three distinct levels at which data

~27~

items can be described. The levels form a three-tier architecture comprising an internal,
a conceptual, and an external tier, as depicted in Figure 1.4. The way the DBMS and the
operating system perceive the data is the internal tier, where the data is actually stored
using the data structures and files organization techniques. The way users perceive the
data is called the external tier. The conceptual tier works like an interface between
internal and external tiers and provides both the mapping and the desired independence
between these tiers. The goal of the three-tier architecture, shown in Figure 1.4, is to
separate the user applications and the physical database. This architecture is proposed
keeping in mind to achieve and visualize the following main characteristics of the
database:

 Insulation of programs and data

 Support of multiple user views, and

 Use of catalog to store the database description (database schema)

The significance of the three-schema architecture, according to ANSI, is that it allows the
three perspectives to be relatively independent of each other. Storage technology can be
changed without affecting either the conceptual or external schema. The conceptual
structure can be changed without affecting the external schema. In each case, of course,
the structures must remain consistent with the other model. The table/column structure
may be different from a direct translation of the entity classes and attributes, but it must
ultimately carry out the objectives of the conceptual entity class structure. Early phases
of many software development projects emphasize the design of a conceptual data
model. Such a design can be detailed into a logical data model. In later stages, this
model may be translated into physical data model. However, it is also possible to
implement a conceptual model directly.

Most DBMSs do not separate the three levels completely, but support the three-schema
architecture to some extent. Some DBMSs may include physical schema in the
conceptual schema. In most DBMSs that support user views, external schemas are
specified in the same data model that describes the conceptual-level information.

~28~

 E N D U S E R S

External Tier View-1 View-2 ... View-N

Conceptual Tier Conceptual Schema

Internal Tier Internal Schema

Physical Data Organization

D A T A B A S E S

Figure 1.4 – The three-tier ANSI-SPARC architecture of DBMS

1.8.1 Internal Tier

The internal tier is concerned with the physical organization of data and describes how
data is stored in the database which includes (i) storage space allocation for data, (ii)
indexing mechanism, (iii) record structuring, (iv) record storage, and (v) data
compression and data encryption techniques. This tier has an internal schema that uses
a physical data model and describes the complete details of data storage and access
paths for the database. The internal level covers the physical implementation of the
database to achieve optimal runtime performance and storage space utilization. It also
provides an interface with the underlying operating system for file management, data
retrieval and so on.

1.8.2 Conceptual Tier

The conceptual tier provides a community view of the database. At this level a
conceptual schema is defined to describe the semantics of a domain. The conceptual
schema contains the logical structure of the entire database to descrive data to be stored
in the database and relationships among them. The conceptual schema hides the details
of physical storage structures and concentrates on describing (a) entities, their attributes
and their relationships, (b) the constraints on the data, (c) semantic information about

~29~

the data, and (d) security and integrity information. Usually, a representational data
model is used to describe the conceptual schema when a database system is
implemented.

1.8.3 External Tier

The exaternal tier provides the user’s view of the database. At the extrernal tier many
external schemas are defined. Each external schema describes the part of the database
that a particular user group is interested in and hides the rest of the database from that
user group. Like conceptual schema, external schemas are typically implemented using a
representational data model. In addition, different views may have different
representations of the same data. For example, one user may view dates in the form
(dd-mm-yyyy), while another may view dates as (mm-dd-yyyy). Some views might
include derived, i.e., data not actually stored in the database as such, but created when
needed. For example, in an employee database, we may wish to view the age of an
employee. However, it is unlikely that ages would be stored, as this data would have to
be updated daily. Instead, the employee’s date of birth would be stored and age would
be calculated by the DBMS when it is referenced.

1.9 Schemas, Mappings, and Instances

The word schema comes from the Greek word skhēma, which means shape, or more
generally, plan. The Greek plural is skhēmata. In English, both schemas and schemata
are used as plural forms. In the database context, the overall description of the database
is called the database schema or simply schema. Influenced by the levels of
abstraction provided by three-tier ANSI-SPARC architecture of DBMS, three different
types of schema in the database are defined. At the lowest level of abstraction an
internal schema is defined, which is a complete description of the internal model,
containing the stored records definitions, representation methods, the storage structure
etc. At the middle level, a conceptual schema is defined to describe all the entities,
their attributes, their relationships, and integrity constraints. At the highest level,
multiple external schemas (also called subschemas) are defined to represent
different views of the data. Each database has single conceptual and internal schemas
but multiple external schemas.

The DBMS adhering the three-tier architecture provides mappings between the three
types of schemas described above. While mapping, the DBMS must ensure consistencies
among the schemas, i.e., the DBMS must check that each external schema is derivable
from the conceptual schema, and it must use the information in the conceptual schema
to map between each external schema and the internal schema. The conceptual schema

~30~

is related to the internal schema through a conceptual/internal mapping. This enables
the DBMS to find the actual record or combination of records in physical storage that
constitute a logical record in the conceptual schema, together with any constraints to be
enforced on the operations for that logical record. It also allows any differences in entity
names, attribute names, attribute order, data types, and so on, to be resolved. Finally,
each external schema is related to the conceptual schema by the external/conceptual
mapping. This enables the DBMS to map names in the user’s view on to the relevant
part of the conceptual schema.

It is important to distinguish between the description of the database and the database
itself. The description of the database is the database schema whereas the schema
along with the stored data is called a database. The schema is specified during the
database design process and is not expected to change frequently. However, the actual
data in the database may change frequently whenever we insert, delete or modify data
in the database. The data in the database at any particular point in time is called a
database instance. Therefore, many database instances can correspond to the same
database schema. The schema is sometimes called the intension of the database, while
an instance is called an extension (or state) of the database.

1.10 Data Independence

The three-tier structure of DBMS, defined in section 1.6, can be used to define the
concept of data independence. Data independence is the type of data transparency that
matters for a centralized DBMS. It can be defined as the capacity to change the schema
at one level of a database system without having to change the schema at the next
higher level. There are two levels of data independence. The data independence defined
at first level is called logical data independence and the one defined at the second level
is called the physical data independence.

1.10.1 Logical Data Independence

The ability to modify the conceptual schema, which is usually done when logical
structure of database is altered, without causing application programs to be rewritten is
called logical data independence. In other words, the ability to change the logical
schema without changing the external schema is called logical data independence. For
example, addition or removal of new entities, attributes, or relationships to the
conceptual schema should be possible without having to change existing external
schemas or having to rewrite existing application programs.In general, logical data
independence is harder to achieve as the application programs are usually heavily
dependent on the logical structure of the data.

~31~

1.10.2 Physical Data Independence

The ability to modify the physical schema, which is done usually to improve the
performance, without causing application programs to be rewritten is called physical data
independence. In other words, the ability to change the physical schema without
changing the conceptual schema is called the physical data independence. For example,
a change to the internal schema, such as using different file organisation or storage
structures, storage devices, or indexing strategy, should be possible without having to
change the conceptual or external schemas.

Whenever we have a multiple-level DBMS, its catelog must be expanded to include

information on how to map requests and data among the various levels. The DBMS uses
additional software to accomplish these mappings by referring to the mapping
information in the catalog. Data independence occurs because when the schema is
changed at some level, the schema at the next higher level remains unchanged; only the
mapping between the two levels is changed. Hence, application programs referring to
the higher-level schema need not be changed. The three-tier architecture can make it
easier to achieve true data independence, both logical and physical. However, the two
levels of mappings create an overhead during compilation and execution of a query or
program, leading to insuffiencies in the DBMS. Because of this few DBMSs have
implemented the full three-tier architecture.

1.11 Database Personnel

Small database is generally defined, constructed and maintained by a single person.
However, many persons are involved in the design, use and maintenance of a large
database; we call them the “database personnel”. We can identify four distinct types of
people that participate in the DBMS environment – (i) database administrators, (ii)
database designers, (iii) application developers, and (iv) the end-users. In the following
subsections we explain the roles of all these persons in detail.

1.11.1 Database Administrators

The database and the DBMS are corporate resources that must be managed like any
other resource. Moreover, in any organization where many persons use the same
resources, there is a need for a chief administrator to oversee and manage these
resources. A database administrator (DBA) is a person who is responsible for the
environmental aspects of a database. The role of a database administrator has changed
according to the technology of database management systems as well as the needs of
the owners of the databases. For example, although logical and physical database design

~32~