Object Oriented Database Management System

Table of Contents
Introduction.................................................................................................................................................2
History of OODBMS...................................................................................................................................3
Characteristics of OODBMS.......................................................................................................................4
Data Structure..............................................................................................................................................4
Object Oriented Development.................................................................................................................4
Embedded Applications...........................................................................................................................5
Complex Object Structures and Hierarchies............................................................................................5
Refactoring and Schema Development....................................................................................................5
Agile Development..................................................................................................................................5
Below is a list of advantages and disadvantages of using an OODBMS on RDBMS with an object
oriented programming language..................................................................................................................6
Object relational features.............................................................................................................................8
Object database conceptual design..............................................................................................................9
Object Query Language OQL.....................................................................................................................10
Example Query......................................................................................................................................10
Index-DBMS.............................................................................................................................................11
Codd’s rules...............................................................................................................................................12
Security of OODBMS..................................................................................................................................15
Data structures supported,.........................................................................................................................16
How the index of OODBMS is organized and works,...............................................................................17
References.................................................................................................................................................20

2
 Object Oriented Database Management System
Introduction

The OODBMS is the product of merging object oriented programming ethics with database management ethics.

Object oriented programming concepts such as encapsulation, polymorphism and inheritance are imposed as well as

database management concepts such as the ACID properties (Atomicity, Consistency, Isolation and Durability)

which show the way for system reliability, it also supports an ad hoc query language and secondary storage

management systems which is allocated for managing very large amounts of data. The Object Oriented Database

program specially lists the following features as compulsory for a system to support before it can be called an

OODBMS; Composite objects, Object uniqueness, Encapsulation , Types and Classes , Class or Type Hierarchies,

Overriding, overloading and late binding, Computational fullness , Extensibility, Perseverance , Secondary storage

management, Concurrency, Recuperation and an Ad Hoc Query capacity.

Now from the abovementioned description, an OODBMS should be able to store objects that are nearly impossible

to differentiate from the kind of objects supported by the board programming language with as little limitation as

feasible. Persistent objects should belong to a class and can have one or more infinitesimal types or other objects as

attributes. The normal rules of inheritance should apply with all their settlement including polymorphism, overriding

hereditary methods and dynamic binding. Every object has an object identifier (OID) which used as a method of

uniquely identifying a particular object. OIDs are everlasting, system generated and not based on any of the

associated data within the object. OIDs make storing orientation to other objects in the database simpler but may

cause referential integrity problems if an object is deleted whereas other objects still have references to its OID. An

OODBMS is thus a complete scale object oriented development environment as well as a database management

system. Features that are common in the RDBMS world such as transactions, the capability to hold large amounts of

data, indexes, deadlock detection, backup and re-establishment features and data recovery mechanisms also live in

the OODBMS world. (Using an OODBMS,2013)

3
 Object Oriented Database Management System
History of OODBMS

Object-oriented database management systems (OODBMSs) first used for research work in the 1980s. At that time,

there were a very less Object-Oriented Programming languages, such as Smalltalk and C++. In the later part of the

1980s and early 1990s it was renowned that O-O languages had some very sturdy advantages over non-O-O

languages for many programming applications. Mainly these were

 well-built encapsulation - makes it easier to program large applications

 inheritance - promote code reuse

But programmers also desire to make objects unrelenting, that is, object lifetimes should expand beyond the single

execution of a program.

At the similar time, within the database society, it was renowned that there were more than a few shortcomings with

commercial implementations of relational databases. These included (but were not restricted to) the following.

 No support for new types - e.g., there is no SQL type for jpeg images

 No support for complex data vales - e.g., can't store a relation as an attribute value

Then in the late 90s, Hellerstein proposed that an Object-Oriented Database Management System (OODBMS) can

be seen as trying "to add DBMS facilities to an O-O language", in result making it a persistent O-O language.

Accordingly application programmers who use OODBMSs write typical programs in a inhabitant O-O language

such as Java or C++, and the language has some kind of Persistent class, Database class, Database Interface, or

Database interface that provides DBMS functionality as, efficiently, an addition to the O-O language. There are

numerous OODBMS vendors, but persistent versions of O-O languages currently have partial popularity.(Intro

OODBMS, 2013)

4
 Object Oriented Database Management System
Characteristics of OODBMS:

One of the most important characteristics of object-oriented databases is the assimilation of object oriented

programming with database technology. The other significant characteristics include:

 Data Encapsulation: that allows programmers to cover the internal state of objects

 Inheritance: it allows the user to develop solutions by defining new objects

 Object Identity: it allows database objects to be self-sufficient of each other

 Polymorphism: it allows developers define an object operation and share the pattern of operation with other

objects.

http://www.articlesbase.com/databases-articles/characteristics-and-advantages-of-oodbms-823514.html

Data Structure

Object Oriented Development

The most important detail that OODBMS technology is the ideal match for using in OO development setting is clear

from the very name. Though RDBMS has a broad support in tools and methods of using in OO environment there

will always be a transparency of the conversion from the object to relational world, usually known as object-

relational impedance disparity.

5
 Object Oriented Database Management System
Embedded Applications

Embedded tool applications require a small-footprint zero-administration database, which makes a ideal match with

an OODBMS. In accumulation, they generally need a rapid response-time, which can be better accomplished by a

indigenous OO technology, when no object-relational adaptation is needed.

Complex Object Structures and Hierarchies

In purpose having to contract with deep entity structures (tree or graph), OODBMS offers a much easier indigenous

way to amass them. Trees or graphs cannot be without doubt translated to RDBMS structure, so that the application

has to pact with frequently complex alteration algorithms, which are hard to maintain and refactor. On the other

hand, OODBMS can amass these structures clearly without any extra coding.

The same is accurate for difficult inter-objects relationships. In RDBMS they are realize with foreign keys. In some

cases, you will need to get object by object until you will arrive at the final relation. In OODBMS all you need is to

identify an activation depth or use transparent activation to attain all the connected objects through the top-object

fields.

From the said above you can terminate that the applications using objects with compilation members (one-to-many

relationships) will also profit from OODBMS technology.

Refactoring and Schema Development

The majority of the applications develop as the time goes. It means that their division and data structure (schema)

can change. In applications using relational databases schema development is quite work-consuming process: the

schema must be distorted, the class arrangement must be changed and the query compilation must be changed too.

In OODBMS applications, only class arrangement is a subject of change and the procedure can be highly

programmed by using modern refactoring techniques accessible from IDEs.

Agile Development

OODBMS makes it achievable to put into practice agile development procedure in your team:
6
 Object Oriented Database Management System

 unremitting refactoring;

 agile representation;

 constant regression testing;

 configuration management;

 Programmer "sandboxes".

(Database Models,2013)

Below is a list of advantages and disadvantages of using an OODBMS on RDBMS with an object oriented

programming language.

Advantages

1. Complex Objects and Relationships: Objects in an OODBMS can store an random number of atomic types

as well as other objects. It is thus making it possible to have a big class which holds many intermediate

sized classes which themselves grasp many smaller classes. In a relational database this has to be done

moreover by having one vast table with lots of null fields or by means of a number of smaller, regularize

tables which are connected via foreign keys. That have lots of lesser tables but there is still a problem since

a link has to be carry out every time one wants to question data based on the "Has-a" relationship between

the body. Also an object is a improved model of the real world body than the relational tuples with regards

to composite objects. The fact that an OODBMS is enhanced to handle complex, unified data than an

RDBMS means that an OODBMS can do better than an RDBMS by ten to a thousand times depending on

the difficulty of the data being handled.

2. Class Hierarchy: Data in the today world is more often than not has hierarchical characteristics. The always

popular Employee example used in most RDBMS is easier to explain in an OODBMS than in an RDBMS.

An Employee can be a Administrator or not, this is generally done in an RDBMS by having a type

7
 Object Oriented Database Management System
identifier field or creating another table which uses foreign keys to point out the relationship between

Managers and Employees. In an OODBMS, the Employee class is merely a parent class of the Manager

class.

3. Circumventing the Need for a Query Language: A query language is not needed for admittance data from

an OODBMS unlike an RDBMS since communication with the database is done by clearly accessing

objects. It is still probable to use queries in an OODBMS however.

4. No Impedance Mismatch: In a distinctive application that uses an object oriented programming language

and an RDBMS, a significant amount of time is more often than not is used up mapping tables to objects

and back. There are also a variety of problems that can happen when the atomic types in the database do

not map minimally to the atomic types in the programming language and vice versa. This "impedance

mismatch" is totally avoided when using an OODBMS.

5. No Primary Keys: The user of an RDBMS has to worry about inimitably identifying tuples by their values

and making sure that no two tuples have the same primary key values to keep away from error conditions.

In an OODBMS, the unique identification of objects is done at the back of the scenes via OIDs and is

completely imperceptible to the user. Therefore there is no limitation on the values that can be stored in an

object.

6. One Data Model: A data model characteristically should model entities and their relationships, constraints

and operations that change the condition of the data in the system. With an RDBMS it is not probable to

model the lively operations or rules that change the state of the data in the system because this is away from

the range of the database. Thus applications that use RDBMS systems generally have an Entity

Relationship diagram to mock-up the static parts of the system and a separate model for the operations and

behaviors of body in the application. With an OODBMS there is no disconnecting between the database

model and the application model because the entities are just other objects in the system. An entire

application can thus be broadly modelled in one UML diagram.

8
 Object Oriented Database Management System
Disadvantages

1. Schema Changes: In an RDBMS adjusting the database schema either by creating, updating or deleting

tables is characteristically independent of the definite application. In an OODBMS based application

adjusting the schema by creating, updating or modifying a constant class typically means that changes have

to be made to the other classes in the application that interrelate with illustration of that class. This typically

means that all schema changes in an OODBMS will engage a system wide recompile. Also updating all the

occurrence objects within the database can take an extensive period of time depending on the size of the

database.

2. Language Reliance: An OODBMS is classically tied to a precise language via a specific API. This means

that data in an OODBMS is typically only reachable from a precise language using a exact API, which is

typically not the case with an RDBMS.

3. Be short of Ad-Hoc Queries: In an RDBMS, the relational tendency of the data allows one to build ad-hoc

queries where new tables are created from joining existing tables then querying them. Since it is presently

not feasible to duplicate the semantics of joining two tables by "joining" two classes then there is a loss of

elasticity with an OODBMS. Therefore the queries that can be carry out on the data in an OODBMS is

highly reliant on the design of the system.( Using an OODBMS, 2013)

Object relational features

Compulsory features for OODBMS include all the characteristic properties of typical Object oriented databases as

well as more general database systems

• Elective features for OODBMS included numerous inheritance, Type checking, Design Transactions, Versions and

distributions

• Open Features for OODBMS included uniformity, programming pattern and representation systems.

More object relational features include:

9
 Object Oriented Database Management System

 Composite objects

 Object Distinctiveness

 Encapsulation

 Classes

 Inheritance

 Overriding and late-binding

 Extensibility

 Computational comprehensiveness

 Perseverance

 Concurrency

 Recovery

 Ad-hoc querying

(Structure, 2012)

Object database conceptual design

Conceptual design of object database is the procedure of developing a semantic explanation of an enterprise that is

to be confined in the design of an application. The Entity Relationship (ER) model has been one of the main well-

known techniques linked with conceptual database design. Since its introduction in 1976 by Peter Chen, the ER

model provides a database-independent advancement to describe the entities implicated in a database application,

together with the relationships and constraints that exist among such entities. The ER model has developed into the

EER model, which augment the original ER model with higher features for theoretical modeling of class hierarchies.

Introduced in the 1990s, software engineering uses UML as a illustration, object-oriented modeling language to

document the structural and energetic aspects of a software system, including many types of diagrams that detain

static and active interactions that are innated in software. From a database viewpoint, UML class diagrams capture

the static arrangement of the classes and the associations between classes that are related to entities and relationships

in EER diagrams. This segment first presents a concise review of the information for EER and UML class diagrams

because language of these models exists throughout the literature. Then the object features supported by the

10
 Object Oriented Database Management System
conceptual modeling diagrams, such as class hierarchies and occupation constraints, are described by database.

( Database features,2013)

Object Query Language OQL

OQL is the method to access data in an O2 database. OQL is a influential and easy-to-use SQL-like query language

with unusual features dealing with complex objects, values and methods.

In order to carry out queries, you'll need to enter query mode. From within the O2 client, then do the command:

 query;

This will set you in a sub-shell for queries. From here, you can go into your queries followed by Ctrl-D. To exit

query form, just hit Ctrl-D without entering a query.

SELECT, FROM, WHERE

SELECT <list of values>

FROM <list of collections and capricious assignments>

WHERE <condition>

The SELECT clause takes out those elements of a collection meeting a precise condition. By using the keyword

DISTINCT duplicated elements in the resulting collection get eradicated. Collections in FROM can be any extents

(persistent names - sets) or expressions that assessed to a collection (a set). Strings are within double-quotes in OQL.

We can rename a field by if we prefix the pathway with the preferred name and a colon.

Example Query
Give the names of people who are older than 30 years old:

SELECT SName: p.name

FROM p in People

11
 Object Oriented Database Management System
WHERE p.age > 30

(then hit Ctrl-D)

Dot Notation & Path Expressions

We can also use the dot notation and path expressions to access mechanism of complex values.

Let variables t and ta range over objects in extents (constant names) of Tutors and TAs (i.e., range over objects in

sets Tutors and TAs).

ta.salary -> real

t.students -> set of tuples of type tuple(name: string, Tuition fee: real) representing students

t.salary -> real

Flow of dots can be used if all names represent objects and not a collection. (Building Sql queries,2013)

Index-DBMS

A directory is a small table having only two columns. The first column contains a copy of the main or candidate key

of a table and the second column contains a set of pointers that holds the address of the disk chunk where that

fastidious key value can be found.

The benefit of using index lies in the fact is that index makes explore process perform very fast. Assume a table has

a number of rows of data; each row is 30 bytes wide. If you want to search for the record number 110, the

management system must methodically read each and every row and after reading 109x20 = 2180 bytes it will find

record number 110. However if we have an index, the organization system starts to search for record number 110

not from the table, but from the index. The index, containing only two columns, may be just 4 bytes wide in each of

its rows. After reading only 109x4 = 436 bytes of data from the index the management system finds an access for

record number 100, it reads the address of the disk block where record number 110 is stored and unswervingly

points at the record in the corporeal storage device. The result is a much quicker access to the record (a speed

advantage of 2180:436).

12
 Object Oriented Database Management System
The only slight disadvantage of using index is that it takes up a little more space than the main table. Furthermore,

index needs to be updated periodically for insertion or deletion of records in the main table. On the other hand, the

advantages are so huge that these disadvantages can be considered insignificant.

Primary Index

In primary index, there is a one-to-one relationship between the entries in the index table and the records in the key

table.

Clustering Index

It might happen sometimes that we are asked to create an index on a non-unique key, such as Dept-id. There might

be several employees in each department. Here we use a clustering index, where all employees belonging to the

same Dept-id are measured to be within a single cluster, and the index pointers point to the cluster as a whole.

Secondary Index

At the same time as creating the index, usually the index table is kept in the primary memory (RAM) and the main

table, because of its size it is kept in the secondary memory (Hard Disk). Tentatively, a table may contain millions of

records (like the phone directory of a large city), for which even a thin index becomes so large in size that we cannot

keep it in the primary memory. And if we cannot keep the index in the primary memory, then we lose the advantage

of the speed of access. For very large table, it is better to systematize the index in multiple levels

Multilevel Index

The Multilevel Index is a alteration of the secondary level index system. In this system we may use even more

number of levels in case the table is even bigger.( Database management system, 2013)

Codd’s rules
 Foundation Rule

A relational database management system must handle its stored data using only its relational abilities.

 Information Rule

13
 Object Oriented Database Management System
Every information in the database should be characterized in one and only one way - as values in a table.

 Guaranteed Access Rule

Each and every datum (atomic value) is certain to be logically reachable by resorting to a amalgamation of table

name, primary key value and column name.

 Systematic Treatment of Null Values

Null values (divergent from empty character string or a string of blank characters and separate from zero or any

other number) are supported in the fully relational DBMS for representing misplaced information in a systematic

way, autonomous of data type.

 Dynamic On-line Catalog Based on the Relational Model

The database portrayal is represented at the logical level in the same way as normal data, so certified users can apply

the same relational language to its interrogation as they apply to regular data.

 Comprehensive Data Sublanguage Rule

A relational system may support numerous languages and various modes of incurable use. However, there must be

at least one language whose statements are expressible, per some well-defined syntax, as disposition strings and

whose capability to support all of the following is intelligible:

a. data definition

b. view definition

c. data manipulation (interactive and by program)

d. integrity constraints

e. authorization

f. Transaction boundaries (begin, commit, and rollback).

 View Updating Rule

All views that are hypothetically updateable but are also updateable by the system.

14
 Object Oriented Database Management System
 High-level Insert, Update, and Delete

The ability of handling a base relation or a resulting relation as a single operand applies nor only to the repossession

of data but also to the insertion, update, and deletion of data.

 Physical Data Independence

Application programs and terminal actions remain logically unimpaired whenever any changes are made in any

storage representation or access methods.

 Logical Data Independence

Application programs and terminal actions remain logically unimpaired when information protecting changes of any

kind that tentatively permit unimpairment are made to the base tables.

 Integrity Independence

Integrity constraints precise to a particular relational database must be definable in the relational data sublanguage

and storable in the directory, not in the application programs.

 Distribution Independence

The data manipulation sublanguage of a relational DBMS must allow application programs and workstation

activities to remain logically unimpaired whether and whenever data are actually centralized or distributed.

 No subversion Rule

However ,if a relational system has or supports a low-level (single-record-at-a-time) language, that low-level

language cannot be used to undermine or avoid the integrity rules or constraints articulated in the higher-level

(multiple-records-at-a-time) relational language.

http://www.cse.ohio-state.edu/~sgomori/570/coddsrules.html

Queries in the SQL

SQL is mostly English; it's made up mainly of English words, put together into strings of words that sound parallel

to English sentences. In broad (fortunately) form, you don't need to understand any mysterious technical language to

write SQL queries that work.

15
 Object Oriented Database Management System
The first word of each query is its name, which is an active word (a verb) that tells MySQL what you want to do.

The query name is followed by words and phrases — some necessary and some not obligatory — that tell MySQL

how to execute the action. For example, you always need to tell MySQL what to create, and you always need to tell

it which table to insert data into or to select data from.

The following is a characteristic SQL query. As you can see, it uses English words:

SELECT lastName FROM Member

This query will retrieve all the last names stored in the table named Member. More complex queries, such as the

following, are less English-like:

SELECT lastName,firstName FROM Member WHERE state="CA" AND

city="Fresno" ORDER BY lastName

Security of OODBMS
A symbiotic amalgamation of security and object-oriented technologies is decisive for the maturing, and pervasive

acceptance, of object-oriented database systems. Security is undoubtedly a vital requirement in large-scale multi-

user information systems. At the same time, the genuine security concerns of a project can be appropriately

addressed only at a semantic level such as offered by object-oriented systems.

Security means different things to diverse people. It has become normally accepted that there are three major

security objectives, as follows.

1. Confidentiality is concerned with indecent revelation of information.

2. Integrity is concerned with inappropriate modification of information or processes.

3. Accessibility is concerned with reprehensible denial of access to information or services from the system. Lately,

it has also become obvious that there is a fourth security objective which is quite distinct from the above.

16
 Object Oriented Database Management System
4. Protection of cerebral property rights is concerned with the improper practice of information assets.

Object-oriented systems offer considerable advantages in all four aspects of security. The most clear benefit is in the

area of integrity. Objects offer a sheltered interface, consisting of the methods appropriate to the particular class of

which the object is an example. In the more complicated models it is possible to ensure that sequences of operations

on an object must satisfy application dependent semantic possessions. In the confidentiality arena, object-oriented

systems suggest a paradigm of calculating information flow by regulating the flow of messages between objects.

The research in this area shows that it is necessary to differentiate between method invocations which can change

the state of an object, and those that cannot. It also becomes essential to introduce asynchronism in calculation

which are otherwise reasonably chronological.

The accessibility and cerebral property areas have not established much study in the object-oriented (or for that

matter, any other) circumstance. The original work that has been done does point out similar benefits in these two

areas as have been established in the integrity and confidentiality arenas. A beyond doubt semantic data model

cannot leave out the increasingly important security requirements of project wide information systems. At the same

time, security services must be made obtainable at the semantic level where individual users see them as a advantage

to their job functions rather than as an hindrance, A symbiosis between safety and object-oriented technologies

therefore is an appealing outlook.( Security features, 2013)

Data structures supported,

Assume you expect that the class structures of your application will change over time. Possibly you distinguish that

there's a good likelihood that new data members will be added, or new object relationships will have to be added.

(Most applications develop as they age; and the data structures they hold up must evolve as well.)

An ODBMS will characteristically weather data structure changes more easily than an RDBMS. If you use an

RDBMS, you'll possibly have to change the plan (to fit the new object structure), then modify the query code to

handle the changes. You may even have to write a one-time alteration application to update the tables to the new set-

up (the sort of throw-away application you only write when you must, and wish you didn't have to waste the time

doing).

17
 Object Oriented Database Management System
Few ODBMSes permit you to change the arrangement of objects "on the fly". You can blend "old" and "new"

objects in the same database. If the new object structure has supplementary fields, interpretation of an old object into

the new application simply loads the additional fields with evasion (e.g., null or zero) values. If the new object

structure has fewer fields, interpretation of an old object into the new application skips the now non-existent fields.

(The ODBMS db4o, for instance, even provides a method whereby "old" objects can be "upgraded" to new objects

imperceptibly as they are accessed from the database.).( Introduction OODBMS,2013)

How the index of OODBMS is organized and works,

The essential need for composite structure is to competently select from a collection whose members meeting a

selection principle. All the objects that also contain given object, or contain an entity equal to a given object have to

be found.

Planned consideration

Since the nested and hierarchical arrangement of objects, it is more complex to apply indexing on OOBDS.

Numerous questions have to be answered to carry on the design. In this segment, some vital issues will be discussed

due to the features of objects

Index on classes

Permission problems occur if indexing on classes is done without any authorization. For example, a user may have

access to a Student object but is forbidden to the instance variable course History. That allows a user to build an

index on Students that might allow him to access some unauthorized data. On the other hand, if a user is barred to

access one or some of the instances of a class, how should indexes be built in this class? For example, a lecturer

might have access to Students that attend his lectures, but not other Students. To approve access to convinced

student objects is difficult if indexing is applied on the Student class. An option is to apply index on collections, and

only add preferred members to a collection; but then each entity must be able to mention a number of indexes to

hold up update, as an object might be restricted in several collections

Indexing over type hierarchy

The permission issue is also raised here when all objects of indexed objects subclasses are also indexed. The

assessment of a query over super class objects will retrieve also objects of its subclass. For example, the supervisor

18
 Object Oriented Database Management System
class is a subclass of the Employee class. By applying index on Employee including supervisor, a user who is

forbidden to access the supervisor instances can get the attribute of a supervisor through querying on the Employee.

Nevertheless, if indexing on super class and its subclasses independently, the assessment of a query over the class

hierarchy involves a lookup in several index structures and a union of the results.

Uni-directional or bi-directional index

Uni-directional index is a one-way orientation from one object to another, as bi-directional index does two-way

links. Two-way links have the benefit of supporting both forward and backward queries, whereas one-way link

supports only one of them. Two-way link is on the other hand problematic, as an object may be the value of an

occurrence unpredictable in several objects. For example, the same Publisher instance can fill the published By

variable of many Book objects.

Here is an example of frontward and back ward queries: book.price is a path,

1. Find Books whose price are less than 200 (backward query)

2. Find the price of the Book id5 (forward query)

www.csd.uoc.gr/~hy562/Papers/OODBMS.pdf

What is the basis of the QOL(algebra, calculus or a combination)

The relational model is well-suited for use in conventional, administrative environments with large amounts of data

having comparatively little structure. Set-oriented query dispensation is the best way to handle large amounts of data

that have comparable structure. Object-Oriented DBMSs (OODBMSs) are being designed and built to support new

application domains like GIS and CAD/CAM. In original applications, the uniqueness of data collections may

be very diverse from those present in the customary managerial environment. For example, in a CAD/CAM

application, classes may contain comparatively few objects, but with a moderately deep structure.

Object-oriented features

Some important features of object-orientedmodels not present in extended relational models are inheritance, object

identity, the use of classes as attribute domains, and the presence of methods.

Inheritance

Inheritance is a main idea of object-oriented data models. In , four of the possible forms of inheritance are

illustrated: substitution, addition, constraint, and specialization inheritance. The completion of specialization

19
 Object Oriented Database Management System
(attribute) inheritance, and hence of substitution (method) and constraint inheritance is mostly a matter of physical

database design. In a number of options for mapping the EER concept of generalization/specialization (i.e., attribute

inheritance) to the relational model are explained. Attribute inheritance may be put into practice by means of oid

equality, by means of clustering of sub- and super type attributes, or by using flags jointly with clustering of

(possibly NULL-valued) sub- and super type attributes. Every way of implementing attribute inheritance has its own

presentation penalties for query and constraint assessment.

Implicit joins

In object-oriented data models, classes may be used as characteristic domains. In the follow-up, these kinds of

domains are called class orientation types. Implementation of class orientation types is also an subject of physical

database design.

Characteristically, class references will be put into practice by means of object identifiers (instead of fully showing

up the attribute domain instance). In the completion, the object oriented schema is mapped to a schema in which

class reference types are substituted by the object identifier type. In the object-oriented query language, attribute

values of domains

Query optimization

There are classes which are reachable by means of attribute selection; in the writing this is often called an inherent

join. In our view, inherent joins will often be mapped to explicit joins; depending on the completion of the type

object identifier type, these joins may be pointer-based or value-based. (In the writing sometimes explicit joins are

defined as value-based joins).

In numerous object-oriented algebras, attribute assortment is supported as an algebraic prehistoric.

Object identity

Object identity is a property that can be useful in quite a lot of ways. Theoretically, an object identifier is just a sole

system-generated identifier. In real implementations, object identifiers are used as (typed) pointers. Using object

identifiers as pointers allows for recursive schema definitions, that enables sharing, smooth the progress of to check

referential integrity, and may offer special advantages with respect to query optimization.

Object identifiers may be put into practice as physical pointers, in some way or the other reflecting the object

location on disk, or as rational pointers. Put into operation object identifiers as physical pointers means that the

relationships between objects put down in the schema by class references that can be used as (user-defined) fast

20
 Object Oriented Database Management System
access paths. Join execution methods making use of these predefined fast way in paths are called pointer-based join

methods. In a presentation comparison is made between some of the conventional value-based join methods and

their pointer-based matching part

The contrast has been made for full joins and joins with a selection on the join operand referencing the other join

operand (forward traversal). To speed up backward traversal, backward references (that also may to a great extent

facilitate checking referential integrity) can be uphold. Pointer-based join methods following the predefined access

paths (forward traversal) are usually faster than the traditional relational join methods.

On the other hand, the pointer-based nested loop method (adolescent pointer traversal or pointer chasing) was shown

to perform poorly in approximately all cases. For small joins, though, the pointer based nested loop technique

proved to be the best. Implementing object identifiers as logical pointers means that no particular advantage can be

gained; in that case object-oriented joins are normal value-based joins.

In the writing, it is occasionally stated that in object-oriented database systems value based joins are no longer

essential. Nevertheless, we consider that there exists meaningful join queries that communicate objects in other ways

than by means of the user-defined relationships laid down in the schema.

Methods

Optimization of methods is often measured a problem, mostly due to the fact that in many existing object-oriented

DBMSs methods for the most part are written in a third generation all-purpose programming language like C++,

Java. Optimization of such a all-purpose programming language in the context of database applications seems a hard

problem undeniably. Writing methods in a language more willing to optimization, for example the (declarative)

query language, will partly solve the problem. For example, in the object oriented data model TM, methods are

written in a high-level, declarative language of expressions. Method calls in a query can then be textually substituted

by their definition, which allows for optimization. TM retrieval methods can purely be looked upon as

parameterized view definitions. As with view definitions, technical code may be optimized locally, or the code may

be replace with the expression containing the method call.( Working OODBMS,2013)

21
 Object Oriented Database Management System

References

1. Using an OODBMS, 2013, http://www.25hoursaday.com/WhyArentYouUsingAnOODBMS.html

2. Intro OODBMS, 2013 http://www.csd.uoc.gr/~hy562/Papers/introOODBMS.html

3. Database Models,2013 http://community.versant.com/documentation/reference/db4o-7.13-

flare/java/Content/Basic_Concepts/database_models/object_and_relational_model_comparison/rdbms_and

_oodbms_application.htm

4. Structure,2012, odbms.org/download/DietrichUrban1-15.pdf

5. Database features,2013,ecomputernotes.com/database-system/adv-database/features-for-any-dbms-to-

qualify-as-oodbms

6. Examples,2013, http://cseweb.ucsd.edu/classes/wi00/cse132a/oql.htm

7. Building Sql queries,2013, http://www.dummies.com/how-to/content/building-sql-queries.html

8. Database management system, 2013,http://www.eazynotes.com/pages/database-management-

system/indexing.html

9. Security features, 2013, profsandhu.com/misc_pubs/sigplan93.pdf

10. Introduction OODBMS,2013,http://odbms.org/Introduction/whenODBMS.aspx

11. Working OODBMS,2013, eprints.eemcs.utwente.nl/6361/01/steenhagen.thesis95.pdf

22