Escolar Documentos
Profissional Documentos
Cultura Documentos
Topic: OODBMS
The rich variety of data types in an ORDBMS offers a database designer many
opportunities for a more natural or more efficient design.
Collection types and ADTs:
Ex: Several space probes, each of which continuously recors a video.
The information associated with a probe has three parts:
(1) a probe ID that identifies a probe uniquely,
(2) a video stream
(3) a location sequence of <time,location> pairs.
An RDBMS Database Design:
Probes(pid: integer, time: timestamp, lat: real, long:real, camera: string, video: BLOB)
• The key for this table can be represented as a functional dependency: PTLN->CV,
where N stands for longitude.
• P->CV
• We can decompose Probes to obtain a BCNF schema:
• Probes_Loc(pid: integer, time: timestamp, lat: real, long: real)
• Probes_Video(pid: integer, camera: string, video: BLOB)
• Drawbacks:
• We have to write application code in an external language to manipulate a video
object in the database.Each probe has an associated sequence of a location
readings is obscured, and the sequence information associated with a probe is
dispersed across several tuples.
• We are forced to separate the video information from the sequence information
for a probe.
An ORDBMS Database Design:
We can can store the video as an ADT object and write methods. We can store the
location sequence for a probe in a single tuple, along with the video information. This
layout eliminates the need for joins in queries that involve both the sequence and video
information.
Probes_AllInfo(pid: integer, locseq: location_seq, camera: string, video: mpeg_stream)
Mpeg_stream type – 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.
SELECT display(P.video, 1:10 P.M. May 10 2005, 1:12 P.M. May 10 2005)
FROM Probes_AllInfo P
WHERE P.pid = 10
CREATE TYPE location_seq listof(row (time: timestamp, lat: real, long: real))
pid camera
Probes
Pointer Swizzling:
When an object O is brought into memory, they check each oid contained in O and
replace oids of in-memory objects by in-memory pointers to those objects. This technique
is called pointer swizzling, makes references to in-memory objects very fast.
Query Optimization:
New indexes and query processing techniques widen the choices available to a query
optimizer. To handle the new query processing functionality, an optimizer must know
about the new functionality and use it appropriately.
Registering indexes with the optimizer:
• As new index structures are added to a system-either via external interfaces
or built-in template structures like GiSTs-the optimizer must be informed of
their existence and their costs of access.
• For a given index structure, the optimizer must know (1) what WHERE-
clause conditions are matched by that index, and (2) what the cost of
fetching a tuple is for that index.
• Given this information, the optimizer can use any index structure in
constructing a query plan.
Reduction factor and cost estimation for ADT methods:
• For user defined conditions such as is_Herbert(), the optimizer also needs to be
able to estimate reduction factors.
• A user who registers a method can also register an auxiliary function to
estimate the method’s reduction factor.
• To run the method on objects of various sizes and attempt to estimate the
method’s cost automatically.
Expensive selection optimization:
• ORDBMS optimizers must consider carefully how to order selection
conditions.
• The best ordering among selections is a function of their costs and reduction
factors.
OODBMS
OODBMS s support collection types makes it possible to provide a query language
over collections. Indeed, a standard has been developed by the Object Database
Management Group and is called Object Query Language.
• OQL is similar to SQL, with a SELECT-FROM-WHERE-style syntax and many
of the proposed SQL:1999 extensions.
• OQL supports structured types, including sets,bags,arrays,and lists.
• OQL also supports reference types,path expressions,ADTs and inheritance,type
extents, and SQL-style nested queries.
• Object Data Language(ODL) is similar to the DDL subset of SQL but supports
the additional features found in OODBMSs, such as ADT definitions.
ODL definitions:
Interface Movie
(extent Movies key movieName)
{ attribute date start;
attribute date end;
attribute string moviename;
relationship Set<Theatre> shownAt inverse Theatre::nowShowing;
}
Interface Theatre
(extent Theatres key theatreName)
{ attribute string theatreName;date start;
attribute string address;
attribute integer ticketPrice;
relationship Set<Movie> nowshowing inverse Movie::ShownAt;
float numshowing() raises(errorCountingMovies);
}
OQL:
SELECT mname: M.movieName, tname: T.thatreName
FROM Movies M, M.shownAt T
WHERE T.numshowing() > 1
OQL supports for queries that return collections other than set and multiset.
SELECT T.theatreName
FROM Theatres T
ORDER BY T.ticketPrice DESC) [0:4]
OQL also supports DISTINCT, HAVING, explicit nesting of subqueries, view
definitions, and other SQL features.
COMPARING RDBMS, OODBMS, AND ORDBMS
An ORDBMS is a relational DBMS with the extensions. An OODBMS is a
programming language and allows any data object to be persistent.