this is content for dbms

1. Object Relational Database
Management System
ADBMS
By: Dabbal S. Mahara
2018
1

2. RDBMS
 In 1970 an IBM researcher named Edgar Frank Ted Codd wrote a paper
“A Relational Model of Data for Large Shared Data Banks”.
 In his paper Codd identifies two objectives for managing shared data:
 The first of these is data independence, which dictates that applications using a
database be maintained independent of the physical details by which the database
organizes itself.
 Second, he describes a series of rules to ensure that the shared data is consistent
by eliminating any redundancy in the database’s design.
 The Relational Model has three parts: a data model, a means of
expressing operations in a high-level language, and a set of design
principles that ensured the elimination of certain kinds of redundant data
problems. That is, these three parts are: relational structure, SQL, and
Normal Forms.
2

3. Deficiencies of RDBMS
1.SQL-92 supports a restricted set of built-in types that accommodate only
numbers and strings, but many database applications began to include deal
with complex objects such as geographic points, text, and digital signal data.
2.The second deficiency is that the relational model suffers from certain
structural shortcomings. They do not provide good support for nested
structures, such as sets and arrays and Subtyping between the objects is
hard to represent in the model.
3.The third deficiency is that RDBMS technology does not take advantage of
object-oriented (OO) approaches to software engineering. OO techniques
reduce development costs and improve information system quality by
adopting an object-centric view of software development.
3

4. Popularity of RDBMS
 Despite the technical shortcomings RDBMS technology exploded in
popularity because even the earliest products made it cheaper,
quicker, and easier to build information systems.
 SQL-92 databases remain a simple, familiar, and flexible model for
managing most kinds of business data.
 The engineering inside modern relational database systems enables
them to achieve acceptable performance levels in terms of both data
throughput and query response times over very large amounts of
information.
4

5. OODBMS
 OODBMS are an extension of OO programming language techniques into
the field of persistent data management. The chief advantage of OODBMSs
lies in the way they can achieve a tighter integration between OO languages
and the DBMS.
 In order to overcome the deficiencies of RDBMS, OODBMS has evolved.
 In order to solve the finite type system problem that constrains SQL-92, most
OODBMSs feature an extensible type system. Using this technique, an
OODBMS can take the complex objects that are part of the application and
store them directly.
 And finally, many of the structural deficiencies in SQL-92 are overcome by
the use of OO ideas such as inheritance and allowing sets and arrays.
 For many applications, the performance, flexibility, and development cost of
OODBMSs are significantly better than RDBMSs.
5

6. Problems with OODBMS
 First, OODBMS vendors have rediscovered the difficulties of tying
database design too closely to application design. Maintaining and
evolving an OODBMS-based information system is an arduous
undertaking.
 Second, they relearned that declarative languages such as SQL-92
bring such tremendous productivity gains that organizations will pay for
the additional computational resources they require.
 Third, they re-discovered the fact that a lack of a standard data model
leads to design errors and inconsistencies.
6

7. ORDBMS
 In spite of different shortcomings OODBMS technology provides effective solutions to
a range of data management problems.
 Many ideas such as complex object extensibility, encapsulation, inheritance, and
better interfaces to OO languages, pioneered by OODBMSs have proven themselves
to be very useful in many applications.
 The applications dealing with complex objects, BLOBS, in satellite imaging, weather
forecasting, CAD/CAM are better modelled with ODBMS.
 To overcome the shortcomings of OODBMS explicitly, it needs great deal of work to be
done in this field.
 So, an attempt has been done to get the best of relational model and object-oriented
approach by enhancing the capabilities of relational DBMS's with inclusion of object
orientation features OODBMS.
 This emergence of new database innovation is called Object Relational DBMS. It is
also known as Object-Relational or Enhanced Systems.
7

8. ORDBMS
 These systems emerged as a way of enhancing the capabilities of
relational DBMSs (RDBMSs) with some of the features that
appeared in object DBMSs (ODBMSs).
 Object-relational database systems provide a convenient migration
path for users of relational database who wish to use object-
oriented features.
 It is based on the relational data model
• preserve relational foundations, such as declarative access to data
• upward compatibility with existing relational languages
‣ Object-relational systems include features such as complex object
extensibility, encapsulation, inheritance, and better interfaces to
OO languages.
8

9. Examples
 Several major software companies including IBM, Informix,
Microsoft, Oracle, and Sybase have all released object-
relational versions of their products.
 These companies are promoting a new, extended version
of relational database technology called object-relational
database management systems also known as
ORDBMSs.
9

10. OODBMS or ORDBMS ?
OODBMS
 It puts more emphasis on the role
of the client side that can
improve long, process intensive,
transactions.
 It has been optimized to directly
support object-oriented
applications and specific OO
languages.
 OODBMS: Abandon SQL (use an
OO language instead)
ORDBMS
 SQL is still the language for data
definition, manipulation and query.
 They are supported by most of the
‘database vendors’ in the DBMS
market place.
 ORDBMS: Extend SQL (with OO
features)
10

11. OODBMS vs ORDBMS?
 When to use an OODBMS?
 In applications that generally retrieve relatively few
(generally physically large) highly complex objects and
work on them for long periods of time.
 When to use an ORDBMS?
 In applications that process a large number of short lived
(generally ad-hoc query) transactions on data
items that can be complex in structure
11

12. ORDBMS Features
 Although ORDBMSs reuse the relational model as SQL interprets it,
new data types and functions can be implemented using general-
purpose languages such as C++ and Java.
 Several OO structural features such as encapsulation, inheritance and
polymorphism are part of the OR data model.
 ORDBMSs adopt the RDBMS query-centric approach to data
management.
 From a systems architecture point of view, ORDBMSs are
implemented as a central server program rather than as a distributed
data architectures typical in OODBMS products.
12

13. Object-Relational Features
OODBS support noted by RDBMS vendors include
 User-extensible type system
 Encapsulation
 Inheritance
 Polymorphism
 Dynamic binding of methods
13

14. Enhanced Table Structure of ORDBMS 14
RDBMS Create
Table Statement
ORDBMS Create
Table Statement
 The most important distinction between SQL-92 tables and
object-relational database tables is the way that ORDBMS
columns are not limited to a standardized set of data types.

15. Disadvantages of ORDBMS
 Complexity
 Increased costs
 Unclear if the ORDBMS will actually combine
relationships and encapsulated objects to correctly and
completely mirror the ‘real world.
 Provision of a language(s) which will be front end to
SQL and will provide a migration path for existing SQL
users.
15

16. The differences between the three
approaches
16
Criteria RDBMS ODBMS ORDBMS
Product maturity Relatively old and so very
mature
This concept is few years old
and so relatively matur
feature
Still in development stage so
immature
The use of SQL Extensive supports SQL OQL is similar to SQL, but
with additional features like
Complex objects and object-
oriented features
SQL3 is being developed with
OO features incorporated in it
Advantages Its dependence on SQL,
relatively simple query
optimization hence good
performance
It can handle all types of
complex applications,
reusability of code, less
coding
Ability to query complex
applications and ability to
handle large and complex
applications
Disadvantage Inability to handle complex
applications
Low performance due to
complex query optimization,
inability to support large-
scale systems
Low performance in web
application
Support from vendors It is considered to be highly
successful so the market size
is very large but many
vendors are moving towards
ORDBMS
Presently lacking vendor
support due to vast size of
RDBMS market
All major RDBMS vendors are
after this so has very good
future

17. SQL Standard and Its Components
 SQL was first specified in 1974 by Chamberlin and Boyce.
 It underwent enhancements in 1989 and 1992. The language
continued its evolution toward a new standard SQL3, which added
object-oriented and other features.
 A subset of the SQL3 standard, now known as SQL-99 was
approved.
 The SQL standard now includes the following parts:
• SQL/Framework, SQL/Foundation, SQL/Bindings, SQL/Object
• New parts addressing temporal, transaction, and other aspects of SQL
• SQL/CLI (Call Level Interface)
• SQL/PSM (Persistent Stored Module).
17

18.  SQL/Foundation deals with new data types, new predicates, relational
operations, cursors, rules and triggers, user-defined types, transaction
capabilities, and stored routines.
 SQL/CLI (Call Level Interface) provides common interfacing components
(structures and procedures) that can be used to execute SQL statements
from applications.
 SQL/PSM(Persistent Stored Module) specifies facilities for partitioning an
application between a client and a server. Enhances performance by
minimizing network traffic.
 SQL/Bindings includes Embedded SQL and Direct Invocation.
 SQL/Temporal deals with historical data, time series data, and other temporal
extensions,.
 SQL/Transaction specification formalizes the XA interface for use by SQL
implementors.
18SQL Standard and Its Components

19. Object-Relational Support in SQL-99
 The SQL/Object specification extends SQL-92 to include object-oriented
capabilities.
 Some of the features in SQL-99:
• Some type constructors have been added to specify complex objects; these
include the row type, which corresponds to the tuple (or struct) constructor;
an array type for specifying collections; other collection types such as set,
list, bag constructors are not part of SQL-99 specifications; they are
expected to be in future versions.
• A mechanism for specifying object identity through the use of reference type
• Encapsulation of operations through the mechanism of user-defined types
that may include operations as part of their declaration.
• Inheritance mechanisms are provided. I.e. specify specialization and
generalization
19

20. Type Constructors
 Two Type constructors row and array are used to specify complex
types; these are also known as user defined types, or UDTs, since the
user defines them for a particular application.
 The row type: Syntax for a row type
CREATE TYPE row_type_name AS [ROW] (<component declarations>)
 The keyword row is optional.
 For example,
CREATE TYPE Addr_type AS (
street VARCHAR (45),
city VARCHAR (25),
zip CHAR (5));
20

21. Type Constructors
 We can use a previously defined type as a type for an attribute.
 For example,
CREATE TYPE Emp_type AS (
name VARCHAR (35),
addr Addr_type,
age INTEGER);
 An array type may be specified for an attribute whose value will be a
collection.
 For example,
CREATE TYPE Comp_type AS (
comp_name VARCHAR (20),
location VARCHAR(20) ARRAY[10] );
 Dot notation is used to refer to components
 E.g., comp1.comp_name is the comp_name part of comp1 (of type Comp_type)
 Square brackets are used to refer to the elements in array. For example, location[1] refers to
the first location value in a location attribute.
21

22. Object Identifiers Using References
 A user defined type can be used either as type for an attribute, just like
addr attribute of Emp_type in previous example.
 Or, it can also be used to specify the row types of a table.
For example, we can create two tables based on row type declarations
given earlier.
Ex: 1 CREATE TABLE EMPLOYEE OF Emp_type
REF IS emp_id SYSTEM GENERATED;
Ex: 2 CREATE TABLE Company OF Comp_type
(REF IS comp_id SYSTEM GENERATED,
PRIMARY KEY (comp_name));
 The examples also show how the user can specify that system-generated object
identifiers for the individual rows in a table is created.
22

23. Object Identifiers Using References
 Syntax to specify object identifiers:
REF IS <oid_attribute> <value_generation_method>
Here, <oid_attribute> will be used to identify individual tuples in the table.
 Options for <value_generation_method> are:
• SYSTEM GENERATED
• DERIVED
 In the former case, the system will automatically generate a unique
identifier for each tuple. In the later case, user-provided primary key
value to identify tuples is applied.
23

24. Attributes as References 24
 A component attribute of one tuple may be a reference:
CREATE TYPE Employment_type AS (
employee REF (Emp_type) SCOPE (Employee),
company REF (Comp_type) SCOPE (Company));
CREATE TABLE Employment OF Employment_type
 Keyword SCOPE specifies the table whose tuples can be referenced
by a reference attribute via the dereferencing notation ->
 For example, to retrieve employees working in the company named ‘ntc’ by
querying Employment table, we write:
SELECT e.employee->name
FROM Employment AS e
WHERE e.company->comp_name=‘ntc’;

25. Encapsulation of Operations
 A construct similar to class definition is provided
 Users can create a named user-defined type with its own methods
in addition to attributes:
 For example,
CREATE TYPE Addr_type AS (
street VARCHAR (45),
city VARCHAR (25),
zip CHAR (5)
)
METHOD apt_no( ) RETURNS CHAR(8);
25

26. Implementation of Method
 The code for implementing the method still has to be written.
 We can refer to the method implementation by specifying the file
that contains the code for the method as follows:
METHOD
CREATE FUNCTION apt_no() RETURNS CHAR(8)
FOR Adr_type AS
EXTERNAL NAME ‘/x/y/aptno.class’ LANGUAGE ‘java’;
26

27. Inheritance in SQL
 SQL has two types of inheritances.
• Type Inheritance : allowed only for structured types
• Table Inheritance: allowed only for typed tables and is
analogous with specialization/generalization in the E-R model
 SQL has rules for dealing with inheritance via UNDER
keyword.
27

28. Type Inheritance
 subtype inherit structure (attributes) and behavior (methods)
from their supertype
 inheritance is specified via the UNDER keyword in the structured
type definition
 subtype can redefine effect of methods by re-declaration, using
method overriding, in the definition of subtypes, instead METHOD,
OVERRIDING METHOD is used.
 For example,
CREATE TYPE Manager_type UNDER Emp_type AS (dept_managed
CHAR (20));
 Here, Manager_type inherits all features of Emp_type and it has an additional
attribute called dept_managed
28

29.  Allowed only for typed tables.
 Subtable inherits the columns of its parent tables.
 Every row in a subtable is also a row in each of its parent tables.
 Every row in a subtable is also a row in each of its parent tables.
• Tuples in a subtable corresponds to tuples in a parent table if they
have the same values for all inherited attributes.
• Corresponding tuples represent the same entity.
29Table Inheritance

30. Unstructured Complex Objects in SQL
30
 SQL has new data types for large objects (LOBs).
 Two variations exist for binary large objects (BLOBs)
and character large objects(CLOBs).

31. Implementation and Related Issues for
ORDBMS
 There are various implementation issues regarding the support of an
extended type systems with associated functions (operations)
 Dynamic linking: The ORDBMS must dynamically link a user-defined function in
its address space only when it is required. As numerous functions are required
to operate on three-dimensional spatial data, images, text and so on and with a
static linking of all function libraries, the DBMS address space may increase by
an order of magnitude.
 Client-server system: Client-server issues deal with the placement and
activation of functions. If a server needs to perform a function, it is best to do so
in the DBMS (server) address space rather than remotely, due to the large
amount of overhead. If a function demands computation that is too intensive or
if a server is attending to a very large number of clients, the server may ship the
function to a separate client machine.
31

32. Implementation and Related Issues
for ORDBMS
 Function execution:
It should be possible to run queries inside functions. A function must operate the
same way whether it is used from an API or it is invoked by DBMS as a part of
executing SQL with the function embedded in an SQL statement.
 Storage and access methods:
• Because of the variety in the data types in an ORDBMS and associated operations,
efficient storage and access of the data is important.
• The RDBMS must allow new types to be defined with new access structures. Dealing
with large text strings or binary files also opens up a number of storage and search
options. It should be possible to explore such new options by defining new data
types within the ORDBMS.
32

33. • Large ADT objects and structured objects complicate the layout of data on
disk.
• User defined ADTs can be quite large. In particular, they can be bigger
than a single disk page. Large ADTs, like BLOBs, require special storage,
typically in a different location on disk from the tuples that contain them.
Disk-based pointers are maintained from the tuples to the objects they
contain.
• Structured objects can also be large, but unlike ADT objects, they often
vary in size during the lifetime of a database.
• An important issue for ORDBMS is to provide efficient indexes for ADT
methods and operators on structured objects.
33Implementation and Related Issues
for ORDBMS

34.  Object-relational database design:
 Object-relational design is more complicated because we have to consider not only the
underlying design considerations of application semantics and dependencies in the
relational model but also the object-oriented nature of the extended features.
 Query processing and optimization:
 ADTs and structured types call for new functionality in processing queries in ORDBMS.
 They also change the number of assumptions that affect the efficiency of queries.
 Users of ORDBMS can define new aggregate functions for their ADTs.
 By extending SQL with functions and rules, the problem of query processing and query
optimization is further compounded beyond the relational model.
34Implementation and Related Issues
for ORDBMS

35.  Interaction of rules with transactions:
• Rule processing as implied in SQL covers rules, which are
implemented in RDBMS as triggers.
• Moreover, RDBMSs implement only immediate execution of
triggers.
• A differed execution of triggers in ORDBMSs involves additional
processing.
35Implementation and Related Issues
for ORDBMS

36. Comparing RDBMS, OODBMS, and
ORDBMS
36
 Similarities:
• Both ORDBMS and OODBMS support user-defined ADTs,
structured types, object identity and reference types, and
inheritance.
• Both support a query language for manipulating collection
types. ORDBMS support an extended form of SQL and
OODBMS support ODL/OQL.
• ORDBMS try to add OODBMS features to RDBMS.
• Both OODBMS and ORDBMS provide DBMS functionality
such as concurrency control and recovery.

37. 37Comparing RDBMS, OODBMS, and
ORDBMS
 Differences:
• OODBMS try to add DBMS functionality to a programming
language, whereas ORDBMS try to add richer data types to a
relational DBMS.
• OODBMS aim to achieve seamless integration with a
programming language such as C++, Java, or Smalltalk. Such
integration is not an important goal for an ORDBMS.

38. Exercise
1. Describe different implementation issues with object
relational database system.
2. Distinguish object oriented database and object relational
databases.
3. What are the advantages and disadvantages of extending
the relational data model by means of ORDBMS?
38

39. THANK YOU !
39