2. ORDBMS
• An object-relational database (ORD),
or object-relational database management
system (ORDBMS), is a database management
System (DBMS) similar to a relational
database, but with an object
oriented database model: objects, classes and
inheritance are directly supported in database
schema and in the query language.
3. …
• An ORDBMS supports an extended form of SQL
called SQL3 that is still in the development stages.
The extensions are needed because ORDBMSs
have to support ADT's.
• The ORDBMS has the relational model in it
because the data is stored in the form of tables
having rows and columns and SQL is used as the
query language and the result of a query is also
table or tuples (rows).
4. An example schema of a student
relation which ORDBMS supports
• STUDENT(fname,lname,ID,major,address,dna
me,location,picture)
• Notice : extra attributes "location" and
"picture" which are not present in the
traditional EMPLOYEE relation of RDBMS. The
datatype of "location" is "geographic point"
and "picture" is "image".
5. A fully relational database must have
the four corner stone characteristies:
• Base type extension
• Complex objects
• Inheritance
• A rule system
6. Base type extension
• The ability to create a new base type is
necessary in many situations, Both simple and
complex ADT is very useful.
• In this way the design of the application will
be smarter and easier.
The base type extension facility must have the
following characteristics:
7. …
• Dynamic linking: It must be possible to adhere
new user defined base types on the fly. Stopping
the database for installing new types, is not
acceptable.
• Client or server activation: A user defined
function for a new base type must have the
ability for being executed on either the server or
the client.
• Security: A user defined function for a new base
type must not be able to corrupt the database.
8. …
• Callback: User defined functions must be able to
use other functions/stored procedures/queries in
the same way as other applications.
• User defined access methods: Adding new access
methods must be allowed for the designer of a
new base type. It must be possible to add
function that Is used by the database engine. Not
all data types is well suited for B-trees.
• Arbitrary length data types: It must be possible
to have user defined data types without length
restrictions.
9. Complex objects
There have to be support of a rich collection of
complex types. At least there must be the
following complex types:
Type constructors
Set of
Record of
Reference
A user defined functions must have support for
use of complex types. Like user defined types,
complex data types must have arbitrary length.
10. Inheritance
1) Data and function inheritance: A major
characteristic of ORDBMS is according to
support for inheritance. Both data and functions
inheritance is necessary. Inheritance of data
only apply to datatypes. The most powerful
inheritance comes from inheritance of
functions.
2) Overloading: it should be possible to specialize
the definition of a function to subtypes.
Overloading must be supported.
11. …
3) Inheritance of types not tables: types and
tables are two different concepts. A table is a
container used to had instances of a type. In this
way there can be multiple tables of a specific
type. Each of tables have the defined
inheritance properties.
4) Multiple inheritance: Multiple inheritances
must be supported. It is needed In many
application. Using a virtual attribute, a user can
reference the placement of a function, where
there is multiple inheritance.
12. A rule system
Rules and triggers must exist in the ORDBMS and
should have the following characteristics according to:
I. Events and actions: rules and triggers are very useful
in most application systems, they are often used to
ensure the consistency of the database. The general
form is : on event do action. Rule system must
include the capability of executing the action just
before or just after the event is processed. On event
do action is a generalized trigger. Triggers normally
only supports update/insert/delete if necessary.
13. …
ii) Integration of rules with inheritance and type
extension. The rules system should be totally
integrated with the other object relational
concepts.
iii) Rich execution semantics for rules. The rule
system must have ability to support different
kinds of actions i.e immediate and same
transactions.
14. An ORDBMS Database Design
• An ORDBMS supports a much better solution.
• First, we can store the video as an ADT object
and write methods that capture any special
manipulation we wish to perform.
• Second, because we are allowed to store
structured types such as lists, we can store the
location sequence for a probe in a single
tuple, along with the video information.
15. …
• This layout eliminates the need for joins in
queries that involve both the sequence and
video information.
• An ORDBMS design for our example consists
of a single relation called Probes_AllInfo:
Probes_AllInfo(pid: integer, locseq:
location_seq, camera: string, video:
mpeg_stream)
16. …
• This definition involves two new types,
location_seq and mpeg_stream.
• The mpeg_stream is defined as an ADT, with a
method display() that takes a start time and
an end time and displays the portion of the
video recorded during that interval.
17. …
Our first query in extended SQL using this
display method follows. We now retrieve only
the required segment of the video rather than
the entire video.
SELECT display(P.video, 1:10P.M. May 10 1996,
1:15 P.M. May 10 1996)
FROM Probes_AllInfo P
WHERE P.pid = 10
18. …
Now consider the location_seq type. We could
define it as a list type, containing a list of ROW
type objects:
CREATE TYPE location_seq listof
(row (time: timestamp, lat: real, long:real))
19. …
Now consider the locseq field in a row for a given
probe. This field contains a list of rows, each of
which has three fields. If the ORDBMS
implements collection types in their full
generality, we should be able to extract the time
column from this list to obtain a list of timestamp
values and apply the MIN aggregate operator to
this list to find the earliest time at which the
given probe recorded. Such support for collection
types would enable us to express our second
query thus:
21. Object identity
• Now we discuss some of the consequences of
using reference types or oids.
• The use of oids is especially significant when
the size of the object is large, either because it
is a structured data type or because it is big
object such as an image.
• Although reference types and structured types
seems similar, they are actually quite
different.
22. For example…
Consider a structured type my.theater tuple(tno
integer, name text, address text, phone text) and
the reference type theater ref(theater_t).
• CREATE TYPE theater_t AS
ROW( tno integer, name text, address text,
phone text)
REF IS SYSTEM GENERATED;
There are important differences in this way that
database updates affect these two types:
23. Deletion
• Objects with references can be affected by the
deletion of objects that they reference, while
reference free structured objects are not affected
by deletion of other objects.
• For example, if the Theaters table were dropped
from the database, an object of type theater
might change value to null, because the theater_t
object it refers to has been deleted, while a
similar object of type my_theater would not
change value.
24. Update
• Objects of reference types change value if the
referenced object is updated.
• Objects of referenced-free structured types
change value only if updated directly.
25. Sharing versus copying
• All identified objects can be referenced by
multiple reference-type items, so that each
update to the object is reflected in many
places.
• To get a similar effect in reference-free types
requires updating all ‘copies’ of an object.
26. Nested Relations
• Motivation:
– Permit non-atomic domains (atomic indivisible)
– Example of non-atomic domain: set of integers or set
of tuples
– Allows more intuitive modeling for applications with
complex data
• Intuitive definition:
– allow relations whenever we allow atomic (scalar)
values — relations within relations
– Retains mathematical foundation of relational model
– Violates first normal form.
27. Example of a Nested Relation
• Example: library information system
• Each book has
– title,
– a set of authors,
– Publisher, and
– a set of keywords
• Non-1NF relation books
30. 4NF Decomposition of Nested
Relation
• Remove awkwardness of flat-books by assuming
that the following multivalued dependencies
hold:
– title author
– title keyword
– title pub-name, pub-branch
• Decompose flat-doc into 4NF using the schemas:
– (title, author)
– (title, keyword)
– (title, pub-name, pub-branch)
32. Collection Types
ARRAY: ordered 1D array with maximum
number of elements without
duplicates.
LIST: ordered collection that allows
duplicates.
SET: unordered collection without
duplicates.
MULTISET: unordered collection that allows
duplicates.
33. Storage and access methods
• Since object relational databases store new
types of data, ORDBMS implementers need to
revisit some of the storage and indexing
issues.
• In particular, the system must efficiently store
ADT objects and structured objects and
provide efficient indexed access to both.
34. Storing Large ADT and Structured
Type Objects
• Large ADT objects and structured objects
complicate the layout of data on disk.
User defined ADTs can be quite large.
• Storage of large ADTs….
• As large ADTs need special storage, it is
possible to store them on different locations
on the disk from the tuples that contain
them. For e.g. BLOBs (Binary Large Object like
images, audio or any multimedia object.)
35. …
Structured objects can also be large, but
unlike ADT objects, they often vary in size
during the lifetime of a database.
36. Query processing
• ADTs and structured types call for new
functionality in processing queries in
ORDBMSs. They also change a number of
assumptions that affect the efficiency of
queries.
• In this section we look at two functionality
issues (user defined aggregates and security)
and two efficiency issues (method caching and
pointer swizzling).
37. User-Defined Aggregation Functions
• Most ORDBMSs allow users to register new
aggregation functions with the system.
• To register an aggregation function, a user must
implement three methods which we call initiaIize,
iterate, and terminate.
• The initialize method initializes the internal state
for the aggregation.
• The iterate method updates that state for every
tuple seen.
• The terminate method computes the aggregation
result based on the final state and then cleans up.
38. …
• As an example, consider an aggregation function
to compute the second-highest value in a field.
• the initialize call would allocate storage for the
top two values, the iterate call would compare
the current tuple's value with the top two and
update the top two as necessary, and the
terminate call would delete the storage for the
top two values returning a copy of the second-
highest value.
39. Method security
• ADTs give users the power to add code to the
DBMS; this power can be abused.
• A buggy or malicious ADT method can bring
down the database server or even corrupt the
database.
• The DBMS must have mechanisms to prevent
buggy or malicious user code from causing
problems.
40. Method caching
• User-defined ADT methods can be very
expensive to execute and can account for the
bulk of the time spent in processing a query.
• During query processing, it may make sense to
cache the results of methods, in case they are
invoked multiple times with the same
argument.
41. …
• An alternative is to maintain a cache of
method inputs and matching outputs as a
table in the database.
• Then, to find the value of a method on
particular inputs, we essentially join the input
tuples with the cache table.
• These two approaches can also be combined.
42. Pointer swizzling
• In some applications, objects are retrieved into
memory and accessed frequently through their oids;
dereferencing must be implemented very efficiently.
Some systems maintain a table of oids of objects that
are (currently) in memory. when an object O is brought
into memory, they check each oid contained in 0 and
replace oids of in-memory objects by in-memory
pointers to those objects. This technique, called
pointer swizzling, makes references to in-memory
objects very fast. The downside is that when an object
is paged out, in memory references to it must
somehow be invalidated and replaced with its oid.
43. Indexing New Types
• One important reason for users to place their
data in a database is to allow for efficient
index via indexes.
• Unfortunatly, the standard RDBMS index
structures support only equality conditions.
• An important issue for ORDBMSs is to provide
efficient indexes for ADT methods and
operators on structured objects.
44. Query Optimization
Challenge: New indexes and query processing
techniques increase the options for query
optimization. But, the challenge is that the
optimizer must know to handle and use the
query processing functionality properly.
Solution: While constructing a query plan, an
optimizer must be familiar to the newly added
index structures.
45. For a given index structure, the
optimizer must know:
1. WHERE-clause conditions matched by that
index.
2. Cost of fetching a tuple for that index.
46. Advantages of ORDBMSs
• Reuse and Sharing: The main advantages of
extending the Relational data model come
from reuse and sharing. Reuse comes from the
ability to extend the DBMS server to perform
standard functionality centrally, rather than
have it coded in each application.
• Increased Productivity: ORDBMS provides
increased productivity both for the developer
and for the, end user.
47. …
• Support powerful query language: An ORDBMS
support an extended form of SQL referred nested
objects, set valued attributed, inclusions of
methods/functions and query involving abstract
data types. For example: SQL 3, SQL/CLI etc.
• Support object views: Object views can be used
to build virtual objects from a relational data
thereby enabling programmers to evolve existing
schemas to support objects. This allows relational
and object applications to co-exist on the same
database.
48. …
• Reduce application development time: In
ORDBMS object type declarations can be
reused via inheritance makes schema
definition more natural.
49. Disadvantages of ORDBMSs
Although the ORDBMS provide support for
complex objects and new data types for many
advanced applications. However, it has many,
disadvantages also.
The following disadvantages are:
• Complexity: ORDBMS design is more complicated
because we have to consider not only the
underlying design consideration of application
semanties and dependencies in the relational
data model but also the object oriented nature.
50. …
• Immature: since ORDBMS concepts is new
and it still needs to be defined so it is not yet
accepted globally. Also it is relative unproven.
• Increased cost: Because of the variety in data
types in ORDBMS and associated operators,
efficient storage and access of the data is
important which increases the cost.
