Advanced Databases Object Oriented Databases - PowerPoint PPT Presentation

Loading...

PPT – Advanced Databases Object Oriented Databases PowerPoint presentation | free to download - id: 4a8c15-YjY5N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Advanced Databases Object Oriented Databases

Description:

Object Oriented Databases School of Informatics Akhtar Ali References Barry Eaglestone, Mick Ridley, Object Databases: An Introduction, McGraw-Hill, 1998 R.G.G ... – PowerPoint PPT presentation

Number of Views:178
Avg rating:3.0/5.0
Slides: 24
Provided by: Carole132
Learn more at: http://computing.unn.ac.uk
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Advanced Databases Object Oriented Databases


1
Advanced DatabasesObject Oriented Databases
  • School of Informatics
  • Akhtar Ali

2
References
  • Barry Eaglestone, Mick Ridley, Object Databases
    An Introduction, McGraw-Hill, 1998
  • R.G.G. Cattell, Douglas K. Barry. Object Database
    Standard ODMG 3.0. Morgan Kaufmann Publishers,
    Inc. 2000
  • Richard Cooper, Object Databases An ODMG
    Approach, ITCP 1997
  • R. Elmasri and S. B. Navate, Fundamental of
    Database Systems 4th Edition, 2003, Chapter 20
    21

3
Object Oriented Concepts
  • Object
  • An object represents a real world entity
    (Person), a concept (Drama), a logical thing
    (Licence), a physical thing (Car)
  • Every object has a unique Object Identifier (OID)
  • An object is made of two things
  • State properties (name, address, birthDate of a
    Person)
  • Behaviour operations (age of a Person is
    computed from birthDate and current date)
  • Object Identifier
  • Unique for every object
  • System generated
  • Never changes in the lifetime of the object
  • Not visible to the user

4
OO Concepts continued
  • Classification
  • Classification is the process of grouping
    together objects which have common features.
  • Programming languages have type systems and
    database systems have data models to classify
    object.
  • The name used for the classificatory group of
    values is usually either class or type.
  • class Person
  • properties
  • name String
  • address String
  • birthDate Date
  • operations
  • age() Integer
  • end Person

5
OO Concepts continued
  • Encapsulation
  • The integration of the description of data
    structure and operation is called encapsulation.
  • Objects are composed of properties (values) and
    operations.
  • It introduces a component of computation into the
    data.
  • This feature is missing in Relational Databases
    (RDBs) and is usually coded into the application.
  • Inheritance
  • A new class is usually described in terms of one
    or more previously defined classes from which the
    new class takes (inherits) properties and
    operations. For instance, the following defines a
    new class Student
  • class Student ISA Person
  • properties
  • major String
  • tutor Lecturer
  • operations
  • register(C Course) Boolean
  • end Student
  • Student is sub-type of Person
  • Person is super-type of Student
  • A Student is also a Person, but not
  • every Person is a Student.
  • A Student has all the properties and
  • operations same as Person

6
OO Concepts continued
  • An object system or object-based system is one
    which supports the modeling of data as abstract
    entities, with object identity.
  • An object-oriented system is an object system in
    which all data is created as instances of classes
    which take part in an inheritance hierarchy.
  • An object-oriented database management system
    (OODBMS) is a DBMS with an object-oriented
    logical data model.
  • An object-oriented database is a database made up
    of objects and managed by an OODBMS.

7
Why Object Oriented Databases?
  • Object Oriented Databases (OODBs) are inevitable
    when
  • Data is complex and variable in size
  • Complex structural and compositional
    relationships
  • Data is highly inter-related
  • Data is evolving rapidly over time
  • Richer data types
  • complex objects
  • inheritance
  • user extensibility
  • Behaviour with data
  • not just a data model but also
  • operations can be bundled together with data

8
Complex Data
9
OODBs are more Natural Direct
10
An Example Conceptual Schema in ER
  • Student and Lecturer are sub-types of Person. d
    means that Student and Lecturer are disjoint.
  • A Student cannot be a Lecturer at the same time
    and vice versa.
  • Attribute names are omitted.

11
The Conceptual Schema in UML
12
OO Representation
class Lecturer ISA Person properties room
Integer tutees set(Student) worksFor
Department teaches set(Unit)
operations teachUnit(U Unit) Boolean end
Lecturer
class Person properties name
String address String birthDate Date
operations age() Integer end Person
class Course properties name
String offeredBy Department hasStudents
set(Student) hasUnits set(Unit) end Course
class Unit properties name String code
String takenBy set(Student) taughtBy
set(Lecturer) partOf set(Course) end Unit
class Student ISA Person properties major
String tutor Lecturer enrolledOn
Course takes set(Unit) operations register(
C Course) Boolean takeUnit(U Unit)
Boolean end Student
class Department properties name
String staff set(Lecturer) offers
set(Course) end Department
13
OO Representation continued
  • No primary keys are required, but keys can be
    used.
  • Relationships are represented in a clear manner,
    no foreign keys used as in case of RDBs. e.g.
  • As in Lecturer class
  • worksFor Department
  • teaches set(Unit)
  • worksFor is not a foreign key but an OID of a
    Department object.
  • teaches is collection valued i.e. a set of OIDs
    of Unit objects.
  • Relationships are bi-directional in the natural
    way.
  • As in Department class
  • staff set(Lecturer)
  • staff is a set of OIDs of Lecturer objects, which
    is inverse to worksFor in Lecturer class.
  • Many-to-many relationships are represented
    directly without introducing a new class or
    relation as in the case of takes, partOf, and
    teaches relationships.

14
Comparison
  • RDBs vs. ORDBs
  • Very easy to compare because both are based on
    Relational Model.
  • An RDB does not support abstract data types
    (ADT), all attribute values must be atomic and
    relations must be in first normal form (flat
    relation).
  • An ORDB supports ADTs, attributes can be
    multi-valued, and does not require first normal
    form.
  • The underlying basic data structures of RDBs are
    much simpler but less versatile than ORDBs.
  • Optimization of queries is much easier and
    efficient in RDBs compared to ORDBs. But this
    does not mean that RDBs are faster than ORDBs.
  • ORDBs support complex data whereas RDBs dont.
  • ORDBs support wide range of applications.

15
Comparison continued
  • RDBs vs. OODBs.
  • Not very easy to compare because of philosophical
    differences.
  • RDBs have only one construct i.e. Relation,
    whereas the type system of OODBs is much richer
    and complex.
  • RDBs require primary keys and foreign keys for
    implementing relationships, OODBs simply dont.
  • Optimization of queries in OODBs is much complex
    than RDBs, but is mainly inspired from the
    Optimization techniques in RDBs.
  • OODBs support complex data whereas RDBs dont.
  • OODBs support wide range of applications.
  • OODBs are much faster than RDBs but are less
    mature to handle large volumes of data.
  • There is more acceptance and domination of RDBs
    in the market than that for OODBs.

16
Comparison continued
  • OODBs vs. ORDBs.
  • Both support ADTs, collections, OIDs, and
    inheritance, though philosophically quite
    different.
  • ORDBs extended RDBs whereas OODBs add persistence
    and database capabilities to OO languages.
  • Both support query languages for manipulating
    collections and nested and complex data.
  • SQL3 is inspired from OO concepts and is
    converging towards OQL (object query language).
  • ORDBs carries all the benefits of RDBs, whereas
    OODBs are less benefited from the technology of
    RDBs.
  • OODBs are seamlessly integrated with OOPLs with
    less mismatch in the type systems
  • ORDBs (SQL3) have quite different constructs than
    those of OOPLs when used in embedded form.

17
Advantages of OODB
  • Greater semantic expressibility storing and
    manipulating complex objects greatly simplifies
    the model of the application world
  • Object identity is superior unifying concept than
    using surrogates (e.g. primary and foreign keys
    in relational DBMS)
  • The ease of user extensibility
  • Behavioural model programs and data are stored
    together, unifying conceptually connected
    features of database
  • Typing objects provides a more coherent structure
    for the database
  • Code re-use through inheritance, over-riding and
    late binding
  • A possible pre-requisite to active databases and
    interoperability?

18
Disadvantages of OODB
  • No formal semantics, unlike the relational data
    model.
  • Pure OO systems do not include the notion of
    class extents which is of fundamental importance
    in DB management.
  • Design methods must be evolved to include
    behaviour and support for dynamic processes.
  • Loss of the relational data models simplicity.
  • Optimization / tuning(e.g. indexes) not as well
    understood and are difficult the overall
    record-at-a-time flavour of the OO systems means
    that relational-style optimization is unlikely.
  • Transaction management support is not very mature.

19
Current Myths Won Kim 95
  • OODBs are 10 to 100 times faster than RDBs.
  • OODBs eliminate the need for joins (not
    altogether).
  • Object identity eliminates the need for keys.
  • OODBs eliminate the need for a non-procedural
    database language (not in reality).
  • Query processing will violate encapsulation (may
    or may not).
  • OODBs can support versioning and long duration
    transactions.
  • OODBs support multimedia data.

20
OODBMS Features
  • Object data model
  • object identifiers, type inheritance, methods,
    complex objects
  • Integration with an OO programming language
  • transparent or semi-transparent retrieval and
    storage of objects
  • Declarative query language
  • usually an SQL like syntax
  • Advanced data sharing
  • long transactions optimistic concurrency
    multiple versions of data private data check-out
  • Client-server architecture

21
OODB Evolution
Programming Languages
Databases
Persistent Programming Languages e.g. Napier88,
PJama
RDBMS
Extended Relational Systems e.g. UniSQL, Oracle,
Illustra
OODB
OOPL add db facilities e.g. C, Smalltalk -gt
ObjectStore, Gemstone,POET
Semantic Data Models e.g. ER, UML, FDM -gt
OpenODB, ODBII
Model based systems add language facilities to a
new data model. e.g O2, ODMG
22
Strategies for building OODBMS
  • Extend OO programming languages to be persistent
  • popular approach
  • programming viewpoint rather than a database one
  • no standard model one programming language
  • ObjectStore, POET, Gemstone
  • Use an object-oriented data model for the DBMS
  • database management viewpoint
  • need language bindings
  • query languages, transaction management etc
  • O2, lambda-DB
  • Standardization of model and services
  • ODMG 3 Standard OMG (CORBA)

23
Summary
  • Introduction to OO Concepts
  • Motivation of why OODBs are inevitable
  • An Example of OO Schema
  • Comparison with RDBs and ORDBs
  • Advantages and Disadvantages of OODBs
  • Evolution of OODBs
  • Strategies of building an OODBMS
About PowerShow.com