1 / 23

Advanced Databases Object Oriented Databases

Advanced Databases Object Oriented Databases. School of Informatics Akhtar Ali. 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

avalazquez
Download Presentation

Advanced Databases Object Oriented Databases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Person d N tutor 1 Student Lecturer N N N enrolledOn takes worksFor 1 M 1 N partOf M N offers 1 Unit Course Department M teaches N 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 Person • properties • name: String • address: String • birthDate: Date • operations • age(): Integer • end Person • class Lecturer ISA Person • properties • room: Integer • tutees: set(Student) • worksFor: Department • teaches: set(Unit) • operations • teachUnit(U: Unit): Boolean • end Lecturer • 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 don’t. • 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 don’t. • 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 don’t. • 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 model’s 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 -> ObjectStore, Gemstone,POET Model based systems add language facilities to a new data model. e.g O2, ODMG Semantic Data Models e.g. ER, UML, FDM -> OpenODB, ODBII

  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

More Related