Download presentation
Presentation is loading. Please wait.
Published byScott Joseph Modified over 9 years ago
1
1 Advanced Databases – Lecture # 11 Object-Oriented Databases Advanced Databases Object Oriented Databases School of Informatics Akhtar Ali
2
2 Advanced Databases – Lecture # 11 Object-Oriented Databases 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 – 3 rd Edition, 2000, Chapter 11 & 12
3
3 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
4 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
5 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
6 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
7 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
8 Advanced Databases – Lecture # 11 Object-Oriented Databases Complex Data
9
9 Advanced Databases – Lecture # 11 Object-Oriented Databases OODBs are more Natural & Direct
10
10 Advanced Databases – Lecture # 11 Object-Oriented Databases An Example Conceptual Schema in ER Person StudentLecturer DepartmentCourseUnit tutor N N1 enrolledOn 1 offers N1 worksFor N 1 partOf NM takes d N M teaches M N 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
11 Advanced Databases – Lecture # 11 Object-Oriented Databases The Conceptual Schema in UML
12
12 Advanced Databases – Lecture # 11 Object-Oriented Databases OO Representation class Course properties name: String offeredBy: Department hasStudents: set(Student) hasUnits: set(Unit) end Course 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 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 Department properties name: String staff: set(Lecturer) offers: set(Course) end Department class Unit properties name: String code: String takenBy: set(Student) taughtBy: set(Lecturer) partOf: set(Course) end Unit
13
13 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
14 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
15 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
16 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
17 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
18 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
19 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
20 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
21 Advanced Databases – Lecture # 11 Object-Oriented Databases OODB Evolution Persistent Programming Languages e.g. Napier88, PJama Extended Relational Systems e.g. UniSQL, Oracle, Illustra OOPL add db facilities e.g. C++, Smalltalk -> ObjectStore, Gemstone,POET Semantic Data Models e.g. ER, UML, FDM -> OpenODB, ODBII OODB Programming LanguagesDatabases RDBMS Model based systems add language facilities to a new data model. e.g O2, ODMG
22
22 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
23 Advanced Databases – Lecture # 11 Object-Oriented Databases 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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.