Docstoc

Object-Relational Databases

Document Sample
Object-Relational Databases Powered By Docstoc
					• I allowed student\IDs to connect with remote
  desktop. All the users should have a STUDENT domain
  ID.
• Vrbsky-win7-05            130.160.47.147
• vrbsky-win7-01            130.160.68.12
• vrbsky-win7-06            130.160.47.199

•   Oracle user name: firstname_initial and lastname
•   Pw: CWID
•   Host string: XE
•   Use SQL plus to type in info interactively
                                                        1
•   More info
Object-Oriented Databases
       Chapter 11




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




                                           3
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
•   multimedia databases
•    WWW
                                               4
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
• nonstandard application specific operations




                                                      5
   OODB systems
• Prototypes: ORION, IRIS, ENCORE,
• Commercial products: ObjectStore V7.3,
  Versant V8, Objectivity/DB10
  – Discontinued: Itasca based on Orion, POET
• Open source object database
  – PostgreSQL 9.1
  – Perst (McObject) – supports SQL, ACID, etc.
  – Db4o – queries only in Java, C#, VB.NET
    (owned by Versant)
  – Magma 4.2 – Squeak (smalltalk-Gemstone)
                                                  6
Different approaches to
designing OODB
1. Applications written in extension of existing
  OOPL (1st generation OODB) to include:
• DB functionality
   – 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++)



                                                        7
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


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




                                             9
Object Data Model - ODM
• Bring concepts of OOPL into DB systems
  – Object corresponds to mini-world object
  – Object is data and behavior, object has
   attributes and operations (methods)
    • Encapsulation (SQL, optimization?)
  – Data object has OID – immutable
    • Identity vs. value based
    • Generated by system
  – Group data objects into classes (or types) -
   abstract mechanism, share same structure
   and behavior
                                                   10
ODM
Class has:
  – instances
  – methods and data - encapsulation for information
    hiding - access only through methods
  – composite classes - composed of multiple types
  – nested objects - contains another object
  – complex objects - set of objects
  – class hierarchy (ISA) – specialization - define new
    classes from existing ones
  – inheritance of attributes and methods - reuse


                                                          11
ODM
 Encapsulation
• implementation hidden
• define behavior of object using operations
• object accessible through predefined operations
• 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

                                         13
ODM
Add features such as:
  – concurrency
  – recovery
  – schema evolution
  – Versions
  – What about query language?
  – Performance?


                                 14
OODB Manifesto
• OODB Manifesto - 1989
• types vs. classes
  – Superficially types the same as classes
  – types - for variables, statically verify, check for
    correctness, intent
  – class
     • extension of type, collection of objects regardless of type
     • not only for correctness, but create and manipulate objects at
       run time
     • can create new classes at runtime, etc.
     • Hence, >1 class – equivalent in type
  – If no dynamic binding, type always determines object
    class                                               15
OODB Manifesto
• extensibility of types
   – predefined types - but user defines new types and
     methods
   – no distinction between user and system created
     types
   – composite types




                                                         16
OODB Manifesto
• other features:
         OID - distinct, immutable
         computational completeness
         overriding - inheritance
         overloading
         late binding
         concurrency and recovery
         ad hoc query facility - SQL included
• optional:
         versioning
                                                17
OODB Manifesto
• complex objects
  – apply constructors to new objects
  – built arrays or sets of objects
• encapsulation
  – can only access object through method
  – program data independence
  – difficult for query optimization


                                            18
OODB Manifesto
• class or type hierarchies
  – subtype (subclass) inherits data and
   methods, and add some of its own
  – multiple inheritance




                                           19
ODM
Object identity OID
• correspondence between real-world and
  database objects
• 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 and even over distributed
  DB


                                                 20
OID vs. primary key
• identity based vs. value-based
• unique over entire DB and even over distributed DB (if
  primary key changes, still same real-world object)
• 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
• system generated OID
• not visible to user


                                                           21
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




                                               22
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


                                                      23
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



                                                    24
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)




                                                     25
OID Implementation
• More efficient for artificially generated
  identifiers
• Performance improved if generate OID to
  speed object lookup




                                              26
 Swizzling
• All references in cached objects replaced
  with object's address
• pointer to other memory resident objects -
  swizzling
• saves OID lookup with subsequent
  references



                                           27
Implementation Issues:
• pointer (OID) to nested object
• nested - no joins needed
  – path queries instead of joins
• when bring in an object into memory, bring in
  nested objects as well
• replace OID with memory address (can't do this
  in relational)
  –   eager and lazy swizzling
• fast access - memory resident

                                                   28
      OSQL – Object SQL

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




                                       29
Object-relational - ORDMS
• Informix, IBM, Hewlett-Packard, Unisys,
  Oracle, and UniSQL
• “Extended relational" is probably the more
  appropriate term
• ORDMSs specified by the extensions to
  the SQL standard, SQL3/4



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


                                                        31
     Oracle’s object relational
• Oracle ORDB
  – Relaxes 1NF
  – Has object types, so users can create tables
    and objects
  – Allows users to create
    • Types as objects
    • Object tables
  – OIDs
  – Inheritance
                                                   32
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) /


                                                                 33
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);

NOTE: data in name_t is never an OID, it is just
 the data or a copy of the data if stored
 elsewhere
                                                   34
Path queries
Select t.tname.lname from teachers t where
 room = 120;

// sometimes aliases are required
// in my examples always use them




                                             35
Create Object table
Create type person_t as object
   (ssn  int,
   Pname name_t,
   age   int)
   /

Create table people of person_t;

To query people:
// You can use the usual SQL
   Select * from people where age > 25;
//Or you can use:     value ( )
   Select value(p) from people p where age > 25;
                                                   36
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) )

   /

                                         37
Ref Object reference
//Use REF keyword to point to a row object

Create type car_reg as object (
    license int,
    drives ref car)

Create table registrations of car_reg;

//Use dot notation to follow a REF to derefence a REF:
   Select r.drives.vid from registrations r;

// or can use DEREF to dereference
    Select DEREF(drives) from registrations;

//If you want to display the OIDs of the objects in a table use:
     Select REF(p) from people p;
                                                                   38
                  Examples
Notice the difference between a REF and the
 object_type_name( ) form

How to insert tuples and query :

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
                                                 39
                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




                                                    40
             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;
                                               41
                 Methods
member function getName return name_t is
begin
  return name_t(fname, minit, lname);
end get Dependent;




                                           42
                  Methods
MEMBER FUNCTION getGender return varchar is
BEGIN
  IF self.sex=‘M’ then
      return ‘Male’;
  ELSE
      return ‘Female’;
  END IF;
END;



                                              43
               Methods
create type employee_t as object (
 ssn int, etc.
 member function getGender return varchar,
 member function getName return name_t);




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




                                           45
Performance
• Performance of OODB affected by:
  – cache sizes
  – clustering (all of same class together versus
    subclass follows superclass)
  – Nested objects
  – Indexes (just like relations)
  – views
  – swizzling
  – Replication
  – Versions (replicate common data?)               46
Versions
• Shared version (not updatable)
  – Check out and update
  – Deleted only by owner
• Working version
  – Update/delete by owner
  – New transient derived from existing one
  – Existing promoted to working


                                              47
Versions
• Version hierarchy - timestamps
      user: specify versioned object
      trace version history
      delete version (delete all versions created from it
                    or just most recent)
      merge
• Class if versionable
   – Generic object
   – Default version#
   – Next version#
   – Version description
   – Working or transient                                   48
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

                                              49
Example
• 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
                                                   50
Schema evolution
• Schema evolution
  – dynamically define and modify DB schema
  – invariant - set of properties of the schema
  – rules for preserving invariance
• 2 types of schema changes:
  – 1. definition of a class (contents
   (attribute/method) of node)
  – 2. to structure (edges and nodes)


                                                  51

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:6/23/2012
language:English
pages:51