Object-Relational Databases

Document Sample
Object-Relational Databases Powered By Docstoc
					Object-Oriented Databases




                            1
• Limitations to the relational model?
• Examples of applications that will not
  work well with the relational model?




                                           2
Shortcomings of DB models for:
• CAD/CAM - keep track of 1000's of matching
  parts and subassemblies
    – relational inefficient for this
    – object versioning
•    complex market-oriented operations
    (securities)
•    geographical information systems
•    CASE – provide access to component objects
    and the whole
•   multimedia databases
•     WWW
                                                  3
Different because of:
• Requirements and characteristics that differ from
  traditional business applications
  – More complex structures for objects
  – New data types for storing images, text, user defined
    types
  – Longer duration transactions
  – Nonstandard application specific operations




                                                            4
  OODB systems (niche market?)
• Prototypes: ORION, IRIS, ENCORE
• Commercial products:
  – Oracle, SQL-Server, DB2, CA-Ingres, Sybase
    (support SQL:1999)
• Open source object database
  – PostgreSQL (sun – solaris)
  – Perst (McObject) – supports SQL, ACID, etc.,
  – db4o – queries only in Java, C#, VB.NET
  – Magma – Squeak (smalltalk - Gemstone)
                                                   5
Different approaches to
designing OODB (or ODB)
1. Applications written in extension of existing
  OOPL (1st generation OODB)
   – language, compiler, execution environment, etc.
     extended to incorporate
      • store and manage objects created by OOPL
      • DB features such as transactions, concurrency control, etc.
   – Selling point - unified programming and DB language
     but need query optimization, etc.

      •    Gemstone (Smalltalk), Poet (C++)



                                                                      6
Designing cont’d
2. Extend relational DB to include OO features:
 – OID, type hierarchy, inheritance, encapsulation,
   arbitrary data types, nested objects, etc.
 – Query language extended with programming
   capability
 – application communicates with DBMS through
   embedded query language - calls in application
   program
 – Already familiar with DBMS but performance
   decreased

    • Postgres - extended Ingres, Oracle


                                                      7
Designing cont’d
3. Start entire process from scratch (next
  generation?)
• unify relational and OO system




                                             8
Object Data Model
• Bring concepts of OOPL into DB systems
  – Object corresponds to real-world object
  – Object is data and behavior, object has
   attributes and operations
  – Data object has OID - immutable
  – Group data objects into classes - abstract
   mechanism, share same structure and
   behavior


                                                 9
ODM
Class has:
  – instances
  – methods and data - encapsulation for information
    hiding - access only through methods
  – composite classes - composed of multiple types
  – complex objects - set of objects
  – nested objects - contains another object
  – class hierarchy (ISA) – specialization - define new
    classes from existing ones
  – inheritance (multiple) of attributes and methods -
    reuse

                                                          10
 ODM
• Type vs. class – some think there is a difference
• Type
   – predefined types - but user defines new types
     and methods
   – no distinction between user and system
     created types
   – composite types
• Type vs. Class
   – static checking
   – If no dynamic binding the same
• Used interchangeably                              11
ODM
 Encapsulation
• implementation hidden
• define behavior of object using operations
• object accessible through predefined operations
• Difficult for optimization
• If query on attributes?
  – SQL violates encapsulation
     • SQL for visible (OSQL), rest is encapsulated




                                                      12
ODM
Completeness
• DBS needs to be computationally
  complete (Turing)
• SQL not computationally complete -
  unless embedded SQL
  – impedance mismatch, since sets
• connections with DML and OOPL in ODB
  more acceptable
• ODM Manifesto 1989
                                         13
ODM
Add features such as:
  – concurrency
  – recovery
  – schema evolution
  – Versions
  – What about query language?
  – Performance?


                                 14
OID
Object identity OID
• correspondence between real-world and
  database objects
• identity based vs. value-based
• OIDs like RIDs except can point to other OIDs
• used to refer to objects in application programs
  and in references between objects(relationships)
• unique over entire DB even distributed DB


                                                 15
OID
• immutable - values of OID for object should not change
           - OID not assigned to another object
           - not dependent on any attribute values
           - not use physical address
• Not visible to user




                                                           16
OIDs in reality
• in extended ODMSs, query language
  extended to allow access by OID
• in OOPL, allow value based access by
  key
• in Postgres - oid attribute in every tuple
• More efficient for artificially generated
  identifiers
• Performance improved if generate OID to
  speed object lookup                        17
OID Implementation
• 1. physical address - fast
  – rarely used, cannot move or delete - if so, all
    references must be changes also
• 2. structured addresses - popular, 1-2 disk
  accesses
      physical and logical component
    segment and page # and logical slot number
       if change, use forwarding (ONTOS)


                                                      18
OID Implementation cont’d
•    3. surrogates - poorer retrieval
    – purely logical
    – use any algorithm to produce unique IDs
      (e.g. date, time)
    – use hash index to map to physical address
      (Postgres)
    – object pages are hash buckets - single disk
      access



                                                    19
OID Implementation cont’d
• 4. typed surrogate - like surrogate for
  retrieval
  – contains type ID and object ID
  – can obtain type without fetching it - ORION
  – difficult to change type - may be useful to be
   able to segment address space (distributed)




                                                     20
 Swizzling
• All references in cached objects replaced
  with object's address
• pointer to other memory resident objects is
  called swizzling (can’t do this in relational)
• saves OID lookup with subsequent
  references



                                               21
Implementation Issues:
• Nested objects - no joins needed
  – path queries instead of joins
  – pointer (OID) to nested object
  – when bring in an object into memory, bring in nested
    objects as well
  – eager and lazy swizzling
  – fast access - memory resident




                                                           22
 OSQL – Object SQL
• ODMG (disbanded) provided standards for
  ODB just like relational databases.
• Result is OSQL (object SQL)




                                        23
    Performance Issues
•   indexes for objects (just like relations)
•   Views
•    Nested objects
•    Clustering of subclass/superclasses
•    cache sizes
•    swizzling
•   replication
•   Versions (replicate common data?)
                                                24
OODB issues
• physical OODB design
  – clustering problems (NP-hard)
  – placing objects onto pages so number of
   page faults is minimal
• user hints for clustering
• where to stores objects, near related
  objects
• how to store objects, near related objects

                                              25
How to Store?
• e.g. Bob is a person, but also an employee
   store all persons
   Bob Sally Joe Bill       Bob Bill   Sally Joe
      person                employee     students

   if store extra attributes, must also retrieve
  information from person class
• store as
       employee student
   retrieve all of them for person
                                                   26
Object-relational - ORDMS
• Informix, IBM, Hewlett-Packard, Unisys,
  Oracle, and UniSQL
• “Extended relational" more appropriate?
• ORDMSs specified by the extensions to
  the SQL standard, SQL3/4




                                            27
ORDMS
• Superset of RDMS
• Definition?
   – Allows user defined types
   – User defined functions
   – Indexing/access methods to support them
• greatest success in managing media objects and
  complex data - geospatial and financial time series data
• frequently used in Web applications and specialized data
  warehouses



                                                        28
     Oracle’s object relational
• Oracle ORDB
  – Relaxes 1NF
  – Has object types
  – Allows users to create
    • Types as objects
    • Object tables
  – OIDs
  – Inheritance

                                  29
Create type
• Create type must be followed by a / in SQL Plus (; optional)
• No objects created, like a struct type
// Create object type
    Create type name_t as object
         ( lname varchar(10),
       fname varchar(10),
        mi        char(1) )
/

// Create relational table
    Create table teachers
         ( tid    int,
           tname name_t,
           room int);

                                                                 30
How to insert?
Can use object_type_name( ) form as an
 object constructor,
Builds objects from value of attributes

Insert into teachers values (1234,
  name_t(‘Sky’, ‘Sue’, ‘V’), 120);



                                          31
Path queries
Select t.tname.lname from teachers t where
 room = 120;

// sometimes aliases are required
// best to always use




                                             32
Create Object table
Create type person_t as object
   (ssn       int,
   Pname      name_t,
   age        int);

Create table people of person_t;

//Can use value ( ) to retrieve values stored in objects
// The following are similar
   Select value(p) from people p where age > 25;
   Select * from people where age > 25;


                                                           33
Inheritance
CREATE TYPE vehicle AS OBJECT
   (VID       VARCHAR2(20),
   COLOR      CHAR(10),
   MAKE       VARCHAR2(10),
   MODEL      VARCHAR2(10) ) NOT FINAL
CREATE TYPE car UNDER vehicle
  ( DOORS NUMBER,
   SPORT    CHAR(1) )




                                         34
           Object Reference

Use REF keyword to point to a row object

 Create type vehicle_reg as OBJECT (
           ( vehicle_id int,
             operator    REF person_t );




                                           35
                    REF
If use var_name and it is an REF
      get: OID

 If use deref (var_name)
     get: object type (value stored)

If use dot notation to follow a REF to
   dereference a REF
      get: actual value stored
                                         36
                  OIDs

If you want to access the OID use:

 Select REF(t) from toys t;




                                     37
Examples

How to insert tuples and query see:
Example of object-relational in Oracle
Results from above in SQL
Example if creating objects with circular
 dependencies
Set (collection of objects) – nested tables or
 VARRAY


                                             38
                Nested tables
create type dependent_t under person_t(
 essn ref employee_t,
 relationship varchar(10))

create type dependent_tbl as table of dependent_t




                                                    39
             Nested tables
Create type employee_t under person_t(
   ssn int,
   address varchar(30),
    …
    dependent dependent_tbl;

• You also need:
Create table employee of employee_t nested table
  dependent store as dependent_table;
                                               40
                Methods
member function getName return name_t as
begin
  return name_t(fname, minit, lname);
end get Dependent;




                                           41
MEMBER FUNCTION getGender return
 varchar is
BEGIN
 IF self.sex=‘M’ then
    return ‘Male’;
 ELSE
    return ‘Female’;
 END IF;
END;                               42
create type employee_t as object (
 ssn int, etc.
 member function getGender return varchar,
 member function getName return name_t);




                                             43
        To invoke methods
• Select e.getName(), e.getGender() from
  employee e;




                                           44

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:8/5/2011
language:English
pages:44