Object-Oriented Databases (and Related Technology) by HC11112922927

VIEWS: 9 PAGES: 21

									Object-Oriented Databases
     (and Related Technology)




  CS 95 Advanced Database
          Systems

          Handout 5
                      Introduction
 The relational DB model (RDBM) has some
  limitations, particularly with semantics (meaning)
  and multimedia.
 Semantic limitation: can add functionality but
  depart from mathematical basis of the model.
 Multimedia limitation: large binary files, an historic
  limitation,
      generally addressed with BLOB types (Binary Large
       OBjects)
      BLOBs are basically treated as just a (large) stream of
       bytes
                          Example
 Consider the example of an invoice:




 In the RDBM, we treat the invoice table as the invoice.
 Really the invoice is a much more complex object. To reconstruct
  this object in RDBM requires 5 (or 6) joins.
         Object-Oriented Databases
 A basic aim of OODB is to "raise the level of
  abstraction". That is, to provide access to data via
  methods that hide the complexity of low level access.
 Applications suited to OODB tend to be those that
  require complex SQL queries:
 Computer-aided design and manufacturing
  (CAD/CAM)
 Computer-aided software engineering (CASE)
 Geographic information systems (GIS)
 Document storage and retrieval
Some 'Standard' OODB Concepts
 Object:
     real world entity, has attributes and methods
 Classes:
     for objects which share the same attributes and methods, e.g.
      person
     defines the structure of the object
     basically corresponds to a table in a RDBMS, although Date
      disagrees and refers to this as the First Great Blunder in 7th
      Ed. Section 25.2, pp 865-872. The same argument is given in
      his 6th Ed. Section 25.4, pp 693-702 but with the less
      pressing heading Relations vs. Objects.
 Object instance:
     an actual instance of an object
     e.g., an individual person's data
Some 'Standard' OODB Concepts
 Object identifier (OID):
     system-generated identifier
     not part of the object, somewhat like a key in RDBM
     OID lasts for the lifetime of the object
     in PostgreSQL this is a sequential number that is unique for
      all objects within the system.
     OIDs are used for references from one table into the next.
 Methods:
     the interface to an object
     contains programming code (of some sort)
     similar to a function
Some 'Standard' OODB Concepts
 Complex objects:
     the value of each object can be an object or set of objects
      referred to by OIDs
     eg: attribute of a person may be children, which is a set of
      OIDs of other persons
 Encapsulation:
     an abstraction that forces a separation between the external
      interface and the internal implementation
     hides unnecessary details of implementation
     allows code and data to be packaged together
     each object has methods (allowed functions/procedures)
     methods provide a visible (public) interface and a hidden
      (private) implementation
Some 'Standard' OODB Concepts
 Inheritance:
     classes can be a subclass of another class e.g., car of vehicle,
      the subclass inherits the attributes and methods of its
      superclass. e.g.,: PostgreSQL:
      CREATE TABLE person
         (name varchar(30),
          dob date);-- person has 2 attributes
      CREATE TABLE student
         (course varchar(20))
         INHERITS (person); -- student has 3 attributes
     In PostgreSQL the select statement:
      SELECT * FROM person*;
      will retrieve all matching rows from person and all classes
      under its inheritance hierarchy,
      i.e.,something like: person UNION ALL student
Some 'Standard' OODB Concepts
 Private and Public interface:
      Private instances are only available to methods of the class
      Public instances are available to all users
      Refers to data and methods.
Object Data Model example
      Object Data Model example
 This model shows:
     A Person can have up to 2 Parents that refers back to the
      Person class
      i.e., parents are also an instance of a person
      The system would store 2 oids in the Parents attribute
     A person can have multiple Children who are also persons
      The system would (somehow) store a set of oids under the
      Children attribute
     The Age() method returns the age of a Person instance,
      probably calculated from the stored DOB
     Classes Student and Professor inherit the attributes and
      methods of Person plus have additional attributes
     So you can obtain the Age() of a Student or Professor
      Object Data Model example
 This model shows:
     The attribute Takes in the Student class would be a set of
      oids from the Course class
     Similarly for the Teaches attribute in the Professor class
     The "Has Students" attribute of the Course class contains a
      set of oids of students enrolled in that course
     This provides efficient two-way access for
      - all courses a student is enrolled in
      - all students enrolled in a course
        Object Data Model example
 A hypothetical syntax for the class definitions of Person
  and Student may be:
   Class Person
     PUBLIC(Name    Text,
             Parents REF ( Person, Person ),
             DOB      Date,
             Children REF ( SET ( REF ( Person ))) )
     METHODS ( Age ( REF Person.DOB ) ... code ... );
   Class Student
     PUBLIC ( Takes     REF ( SET ( REF ( Course ))) )
     INHERITS ( Person ) ;
     Advantages/Disadvantages of
 Advantages:
              OODBMS
     Fast navigation
     Advanced features built into the OODBMS - inheritance,
      methods, user-definable data types etc.
     Integrated database programming language. Unfortunately,
      current DB languages are typically procedural (3GL).
 Disadvantages
     Incomplete theory and standards. Hence OODBMS products
      vary widely.
      This may be overcome as vendors conform to the new ODMG
      (Object Data Management Group) standard.
     Extended initial design issues.
      Classes, including inheritance, encapsulation and mapping issues
      plus all methods applicable to each class.
     No standard Object Manipulation Language. Instead object
      manipulation is performed by the language the DB is bound to.
       Advantages/Disadvantages of
               OODBMS
 Disadvantages (cont’d)
     Lack of system catalog standards.
     Lack of view definitions - will be overcome with newer,
      improved products.
     Poor support for ad-hoc queries. The DB is designed to be
      navigated in a particular way.
     Lack of declarative integrity constraints.
     Foreign key support is built into the methods or procedural code.
      There is no equivalent to ON DELETE RESTRICT or ON
      UPDATE CASCADE, etc.
     Possible database corruption - some OODBMS run is the
      application process space to improve performance. Wild pointers
      from the application program may overwrite and corrupt data.
          Some OODB Approaches
 OOPS Extension
  DB support is added to a programming language. e.g.:
    ONTOS (C++)

    ObjectStore (C++)

    GemStone (Smalltalk, Opal, C++)


 RDBMS Extension
  OO support is added to a relational database, ie. Object-Relational DBMS. e.g.:
    POSTGRES (University INGRES, QUEL)

    Starburst (IBM research)

    IRIS (OSQL, SQL)


 New OODBMS
  Fully OODBMS. Only stores data in the form of objects, so does not support
  tuples. Performance is optimized for fast access of objects from the server and
  transparent access of objects from the client side. e.g.:
     ORION (Common LISP)

     O (C, CO )
        2        2
         Object Database Standards
 Initiatives:
      Object Database Management Group: ODMG-93 1.0, the ODB
       Standard.
      ANSI: X3H7 and X3T5.4 Standards prototypes.
 If and when these groups get together, we may have a true
  standard.
 ODMG-93 1.0 'Standard’
  Specifies:
      object data model (ODM)
      object definition language (ODL)
      Object Interchange format (OIF)
      object query language (OQL)
      bindings to languages, such as C++, Smalltalk and Java
 Future: Common Object Request Broker Architecture
  (CORBA) for DDB
      Object-Relational Databases
 Extended relational and object relational are synonyms for
  database management products that try to unify aspects of
  both the relational and object databases. (Note: There is no
  official definition of what an object relational database
  management system is.) Won Kim, founder of UniSQL,
  recently published a white paper describing a framework
  with which to evaluate the completeness of a product's
  compliance with seven major categories of capabilities of
  object relational databases.
 Read the article “Object Database vs. Object-Relational
  Databases” by Steve McClure for details.
  IDC Bulletin #14821E - August 1997
  (http://www.cai.com/products/jasmine/analyst/idc/14821Eat.htm)
            Nested Relational Model
 A drawback of relational model is that it can represent
  data only in the simple first normal form. There are two
  proposals to improve it.
   1.   Since the concept of dependencies has been proposed to
        eliminate information loss accompanying updating, databases
        without updating such as those used only for searching do not
        have to be in the first normal form.
   2.   Decompositions of relations according to multi-valued
        dependencies are not always necessary in order to prevent errors
        in updating.
         Nested Relational Model
 The first idea was developed in the fields of information
  searching and so on. And the second one was proposed in
  1977.
 Each value in the model can be a set or a hierarchical
  structure. There are two advantages, i.e., the expressions
  of data in the model are natural or efficient and less join
  operations are necessary, which means data processing
  becomes generally faster.
 In the beginning the model was called the non-first-
  normal-form(NF ) relation and so on, but calling it the
  nested relation was agreed upon internationally in 1986.
  However, the insistence that the nested relation and the
  unnormalized relation should be distinguished still exists.
               SQL 3 Standard

 Read “Why We Need SQL3?” by By John E. Seytabla
  (http://www2-iiuf.unifr.ch/ds/courses/db/pdf/whysql3.htm)

								
To top