Object Oriented DBMs - PowerPoint PPT Presentation

1 / 38
About This Presentation
Title:

Object Oriented DBMs

Description:

Don't have to learn a new type of DB system. Works pretty well. Cons ... want to indicate that a capital (like Sacramento) is a kind of a city that's ... – PowerPoint PPT presentation

Number of Views:40
Avg rating:3.0/5.0
Slides: 39
Provided by: csMi4
Category:

less

Transcript and Presenter's Notes

Title: Object Oriented DBMs


1
Object Oriented DBMs
2
Objectives
  • Unsuitability of RDBMSs for advanced database
    applications.
  • Problems of storing objects in relational
    database.
  • Basics of how OODBMS work.
  • Pros and Cons of OODBMS.
  • Object Data Model Standard

3
Computer-Aided Design (CAD)
  • Stores data relating to mechanical and electrical
    design, for example, buildings, airplanes, and
    integrated circuit chips.
  • Designs of this type have some common
    characteristics
  • Data has many types, each with a small number of
    instances.
  • Designs may be very large.

4
Computer-Aided Design (CAD)
  • Design is not static but evolves through time.
  • Updates are far-reaching.
  • Involves version control.

5
Office Information Systems (OIS) and Multimedia
Systems
  • Businesses store many types of information -
    electronic mail, documents, invoices, and so on.
  • Modern systems now handle free-form text,
    photographs, diagrams, audio and video sequences.
  • Documents may have specific structure, perhaps
    described using mark-up language such as SGML,
    HTML, or XML.

6
Geographic Information Systems (GIS)
  • GIS database stores spatial and temporal
    information, such as that used in land management
    and underwater exploration.
  • Searches may involve identifying features based,
    for example, on shape, color, or texture, using
    advanced pattern-recognition techniques.
  • Searches also are hierarchical -
  • give me all the states in which more than 50 of
    the neighborhoods have leash laws
  • give me all the states which might have to worry
    about the snake-head fish

7
Weaknesses of RDBMSs
  • Poor Representation of Real World Entities
  • Normalization leads to relations that do not
    correspond to entities in real world.
  • Part-of relations lead to lots of joins, hard to
    do.
  • There's only one relationship between data the
    join
  • There's no functional difference between
  • Person has friends
  • Monkey eats bananas
  • The relational model is semantically overloaded

8
Weaknesses of RDBMSs
  • Homogeneous Data Structure
  • Horizontal homogeneity every row has the same
    columns
  • Vertical homogeneity all the data in a column
    is of the same type.
  • Again no part-of or complicated internal
    relationships.
  • Recursive queries are hard, if not impossible

9
Recursive Query
StaffNo managerStaffNo S005 S004 S004 S003 S003
S002 S002 S001 S001 NULL Tell me the names of
everyone directly and indirectly managed by
staffer S005. Can't do this with straight SQL if
you don't know how many staffers might be
involved.
10
Weaknesses of RDBMSs
  • RDBMSs are hard to change
  • Once you have a structure in place, reworking the
    tables is tough
  • Doesn't map onto object-oriented programming
  • Impedence mismatch combining two different
    paradigms
  • SQL is row-oriented, has its own data types
  • Java is object-oriented, has different data types
  • Mixing the two just ain't natural

11
Attempts to Overcome Impedence Mismatch
Object oriented persistence layers map objects
onto database tables using standard relational
models They try to Encapsulate the persistence
mechanism you can call load, save, update
and delete on any object that's tagged as
persistent Support inheritence Link part-of
hierachies, so deleting an object deletes the
things that are part of that object Examples
are JDO from Sun http//java.sun.com/products/
jdo/ Castor from Exolab - http//castor.exolab.o
rg/ Player at SourceForge - http//player.sourcef
orge.net
12
Persistance Layer Basics
Usually each object that will persist has a file
which maps the object onto a relation Queries
are typically done in OQL Object Query
Language. If you have a mapping, you can
perform this sort of operation on an
object Product prod new Product() prod.setI
d(1) prod.setName(chair) db.create(prod) /
/ this saves to the db
13
Example Castor Mapping
ltmappinggt ltclass namemyapp.Product
identityidgt ltmap-to tableprod/gt
ltfield nameid typeintegergt ltsql
nameid typeintegergt lt/fieldgt ltfield
namegroup typemyapp.ProductGroupgt
ltsql namegroup_id /gt ltfieldgt
lt/classgt lt/mappinggt
14
Inheritance in Castor
ltmappinggt ltclass namemyapp.Computer extends
myapp.Product identityidgt ltmap-to
tablecomputer/gt ltfield nameid
typeintegergt ltsql nameid
typeintegergt lt/fieldgt ltfield
namecpu typestringgt ltsql namecpu
typechar/gt ltfieldgt lt/classgt lt/mappinggt
15
Storing Objects in Relational Databases
16
Mapping Classes to Relations
  • No really good way to do this
  • (1) Map each class or subclass to a relation
  • Staff (staffNo, fName, lName, position, sex, DOB,
    salary)
  • Manager (staffNo, bonus, mgrStartDate)
  • SalesPersonnel (staffNo, salesArea, carAllowance)
  • Secretary (staffNo, typingSpeed)
  • This represents the data, but which is the
    superclass?

17
Mapping Classes to Relations
  • (2) Map each subclass to a relation
  • Manager (staffNo, fName, lName, position, sex,
    DOB, salary, bonus, mgrStartDate)
  • SalesPersonnel (staffNo, fName, lName, position,
    sex, DOB, salary, salesArea, carAllowance)
  • Secretary (staffNo, fName, lName, position, sex,
    DOB, salary, typingSpeed)
  • This works, but now it's not clear that these are
    subclasses of something

18
Mapping Classes to Relations
(3) Map the hierarchy to a single relation Staff
(staffNo, fName, lName, position, sex, DOB,
salary, bonus, mgrStartDate, salesArea,
carAllowance, typingSpeed, typeFlag) Now the
whole superclass-subclass relation is gone
19
Pros and Cons of Object Oriented Persistence in
an RDBMS
  • Pros
  • Using 30 years of RDBMS know-how
  • Don't have to learn a new type of DB system
  • Works pretty well
  • Cons
  • You still get impedence mismatch
  • The database no longer describes all the data,
    inheritence is in the configuration files

20
Object Oriented Databases
OODBMSs are another way of dealing with the
limitations of RDBMSs Rather than cramming
objects into relations, they store and manipulate
relations directly.
21
The OODBMS Manifesto 1989
http//www-2.cs.cmu.edu/People/clamen/OODBMS/Manif
esto/htManifesto/Manifesto.html Complex objects
must be supported All objects have a unique
identity regardless of their attribute
values Encapsulation must be supported objects
can protect their insides Types must be
supported and they must be extensible Inheritance
must work and be identifiable as
inheritance The system must support basic
database stuff concurrent users, recovery from
failure, and there must be a way to query.
22
Object Oriented DBMS Basics
  • The database stores objects.
  • Objects have methods
  • Constructors and destructors - destroy()
  • Access methods - getSalary()
  • Transformation methods - increaseSalary()
  • Objects have attributes
  • Can be simple types String, int
  • Can be other objects, this is called a reference
    attribute
  • Can be collections of objects or simple types

23
Object Identity
  • IN OODMBSs, each object has its own ID.
  • Used to refer to that object for search, update,
    etc
  • Used to include the object as part of another.
  • In RDBMS, object identity is value-based a
    primary key is used to provide uniqueness.
  • Primary key is only unique within a relation, not
    across entire system
  • key generally chosen from attributes of relation,
    making it dependent on object state.

24
Object Identity
  • Object identifier (OID) assigned to object when
    it is created that is
  • System-generated.
  • Unique to that object.
  • Invariant.
  • Independent of the values of its attributes (that
    is, its state).
  • Invisible to the user (ideally).

25
Standards
In 1991 The Object Data Management Group came up
with standards for defining database objects
(ODL) and for Querying them (OQL). Latest
version (v3) came out in 1999. Some OODBMs use
ODL Orient - www.orientechnologies.com Versant
- www.versant.com Poet - www.poet.com ObjectStor
e - www.objectstore.net Not too many OODBMs use
OQL Poet Jasmine - www.cai.com Computer
Associates) Castor (not an OODBMS)
castor.exolab.org JDO Java Data Objects
www.jdocentral.com used by www.fastobjects.com
and others, not really an OODBMS either
26
ODL Object Definition Language
interface Employee extent employees keys
name attribute string name relationship
Company worksAt inverse Companyemployes void
increaseSalary(in float raise) interface
Company extent companies keys
name attribute string name relationship
ListltEmployeegtemploys inverse
EmployeeworksAt
27
Example OQL queries
Here myCompany is an object which has a set of
employees. select e.name from e in
myCompany.employees where e.salary gt
20000 define salaryGroup(lower, upper) as
select e.name from e in Company.employees
where e.salary gt lower and e.salary lt
upper
28
Using OQL queries (In castor)
OQLQuery oql db.getOQLQuery(select
myCompany.employees) enum oql.execute() Emp
loyee happyCamper while (enum.hasMoreElements())
happyCamper enum.nextElement() happyCampe
r.increaseSalary(2000.00) db.commit()
29
Advantages of OODBMSs
  • Removal of Impedance Mismatch.
  • Superclass/subclass object classes.
  • More Expressive Query Language.
  • Support for Schema Evolution.
  • Versant lets you check in and check out objects
    like in CVS, it versions them too.
  • GemStone lets you modify classes on the fly all
    objects of that class are instantly modified

30
Disadvantages of OODBMSs
  • Lack of Universal Data Model.
  • Lack of Experience.
  • Lack of Standards.
  • Query Optimization compromises Encapsulation.
  • Object Level Locking may impact Performance.
  • Complexity.
  • Lack of Support for Views.
  • Lack of Support for Security.

31
Object-Relational Databases
  • Most relational database people know their
    systems have limitations
  • ORDBMSs try to extend RDBMSs with OO things.
  • Namely
  • Inheritance
  • Unique identifiers
  • Abstract types
  • More complicated relations between tables

32
Inheritance in Postgres
In standard RDBMS, if you have cities and want to
indicate that a capital (like Sacramento) is a
kind of a city that's part of a state you could
do this CREATE TABLE capitals (name
VARCHAR(80), population INT, state
CHAR(2)) CREATE TABLE non_capitals (name
VARCHAR(80), population INT) CREATE VIEW
cities AS SELECT name, population FROM
capitals UNION SELECT name, population FROM
non_capitals This way you can list all cities,
and list all capitals. But, it's silly. A
capital IS a city, with something special.
33
Inheritance in Postgres
CREATE TABLE cities (name varchar(80), population
int) CREATE TABLE capitals (state char(2))
INHERITS cities Now capitals inherits all the
fields of cities. If you've defined keys in
cities, they're inherited too. To get the names
of all the cities SELECT name FROM cities To
get the names of just the cities which aren't
capitals SELECT name FROM ONLY cities
34
Unique Identifiers In Postgres
  • OID every row in the database gets a 4 byte int
  • This means that in dbs (or tables) with over 4
    million rows, the OID won't be unique
  • tableoid every table has an OID which comes
    from the same pool
  • To make OIDs truly unique for a table
  • create table foo (bar int, unique(OID))
  • Also, can supress OIDs when creating table
  • Create table foo (bar int) without OIDS
  • The stuff in 27.3.4 was zapped from postgres in
    1994.

35
Abstract types in Postgres
  • Represent a set of boxes in the DBMS and a simple
    query- find all the boxes that overlap the unit
    square(0,1,0,1).
  • RDBMS
  • create table box(id int, x1 float, x2 float, y1
    float , y2 float)
  • select
  • from box
  • where ! (box.x2lt0 or box.x1gt1 or box,y2lt0 or
    box.y1gt1)
  • Too hard to understand
  • Too complex to optimize
  • Too many clauses to check

36
Abstract Types in Postgres
Instead, define type box CREATE TYPE box (
INTERNALLENGTH 16, INPUT
my_box_in_function, OUTPUT
my_box_out_function, ) CREATE TABLE myboxes ( id
integer, description box ) insert into myboxes
(1, 10,20,10,20) select from myboxes where
myboxes.box!!9,10,20,10 Have to define the !!
operator, as well as input and output
functions Input takes a string and converts it
into types usable by your operators Output takes
the types from your operators and turns it into a
string Operator, input and output functions
declared in C and placed in a special directory,
or you can use postgres's special procedural
language.
37
Triggers Complex Relations
CREATE TRIGGER lttrigger namegt ltBEFOREAFTERgt
ltINSERTDELETEUPDATEgt ON ltrelation namegt FOR
EACH ltROWSTATEMENTgt EXECUTE PROCEDURE
ltprocedure namegt (ltfunction argsgt)
38
Triggers Example
Here's a foreign key in Postgres, it checks to
see if there's an author in the author table
matching the author you're trying to insert into
titleauthors CREATE CONSTRAINT TRIGGER
"ltunnamedgt" AFTER INSERT OR UPDATE ON
"titleauthors" FROM "authors" NOT DEFERRABLE
INITIALLY IMMEDIATE FOR EACH ROW EXECUTE
PROCEDURE "RI_FKey_check_ins" ('ltunnamedgt',
'titleauthors', 'authors', 'UNSPECIFIED',
'authorid', 'authorid')
Write a Comment
User Comments (0)
About PowerShow.com