OO databases
1
Object Oriented databases
OO databases
2
Developing OODBMS - motivation
motivation more and more application areas require systems that offer
support (implement) for both traditional language programming and database capabilities
OO databases
3
Traditional programming languages
procedural control data abstraction functional abstraction
OO databases
4
Persistent programming languages
definition: a language that provides the ability to preserve data across successive executions of a program (or even by many different programs)
• the user can make volatile data permanent in a transparent manner (no translations are required, such as transforming data structures in file structures)
• impedance mismatch - disappears; however, if some data is available, then it is only available for a specific language
no other features beyond persistence are available• such as transaction management, concurrency control and
recovery
OO databases
5
Database systems
support a data model provide data persistence provide data sharing (includes concurrent access) provide a higher degree of reliability (includes
recovery control) support scalability support security and integrity suitable for distribution
OO databases
6
Database programming languages
incorporate features beyond persistence• transaction management, concurrency control, data recovery
database programming DB language (e.g. SQL) - computationally incomplete therefore, a DB language is usually embedded into a high
level programming language• SQL92 can be embedded in C, Pascal, Fortran, Ada ...
• communication: set of variables in the host language + call to DBMS routines (a pre-processor translates SQL statements into calls)
OO databases
7
Drawbacks of existing approaches to database programming
impedance mismatch• the programmer has to write code to translate between the host
language’s data model and the DB’s language data model
additional type-checking• while manipulated in the host language the data objects are strongly
typed; they are then stored in a traditional DBMS; they can be accessed from another language, not strongly typed! when retrieved in the host language type checks must be performed
read and write data on persistent storage• it is always the programmer’s responsibility to decide WHEN to read
and write on secondary space (for instance, when some data is required the programmer should not have to specify whether this data is to come from secondary space or from the main memory - this should be transparent at the level of the language)
OO databases
8
Cause of drawbacks
2 level storage model
persistent memory
conceptual / external
SQL
tra
nsf
orm
ati
on
s +
ty
pe
ch
eck
ing
application program
main or virtual memory
physical
OO databases
9
Possible solution
single level storage model (pointer swizzling - OID - next slide)
persistent memory
application program
main or virtual memory
OO databases
10
OO concepts
classes and instances object identity; object identifier OID
• not a pointer, but a logical identifier (an object can exist at different addresses, but the OID remains the same through the life time of the object)
hierarchies attributes methods and messages abstraction encapsulation information hiding polymorphism and dynamic binding (overloading)
OO databases
11
OO DBMS - Khoshafian and Abnous, 1990
OO DBMS = object orientation + database capabilities
OO databases
12
OO DBMS - Kim 1991
OODM (data model)• a logical data model that captures the semantics of objects
supported in OO programming languages
• NO UNIQUE DATA MODEL
OODB (database)• a persistent and sharable collection of objects defined by an
OODM
OODBMS• the manager of an OODB
OO databases
13
OO DBMS- Zdonic and Maier
definition through features provided database functionality support object identity provide encapsulation support objects with complex state
OO databases
14
OO DBMS - Parsaye, 1989
definition through features provided high level query language + optimisation capabilities support for persistent and atomic transactions support for complex object storage + mechanisms of
efficient access OODBMS = OO system + the above characteristics
OO databases
15
Strategies for developing OO DBMS (languages)
extend an existing OO language with DB capabilities provide OO DBMS libraries
• in the first approach the language is extended, whereas in the second approach a set of libraries is provided
embed OO DB constructs into a conventional language extend an existing DB language with OO capabilities
• SQL3 (Object SQL) - supported by both camps
develop a novel data model / database language
OO databases
16
Issues in OO DBMSs
transactions versioning schema evolution
OO databases
17
Transactions
support for long (duration) transaction required locking for long term - unsatisfactory
in OO DBMSs - unit of transaction = object coarser granularity may be required for efficiency
solutions versions advanced transaction models
• e.g. nested transactions
OO databases
18
Versioning
solutions to long term transactions also, required “per se” versioning
get a copy of current version in the private work space - check out
establish a given object as the current version - check in• merge distinct versions
delete / archive obsolete versions interrogate about version history of an object
OO databases
19
Schema evolution
database schema must be easily modifiable e.g. for design applications
changes needed changes to class definition (modify definitions of attributes or
methods) changes to the inheritance hierarchy changes to the set of classes (adding / deleting classes)
schema invariant rules e.g. resolution of conflicts
• e.g. precedence of subclasses over superclasses (definitions in subclass take precedence)
OO databases
20
Advantages
enriched modelling capabilities extensibility removal of impedance mismatch more expressive query language support for schema evolution support for long duration transactions applicability to advanced database applications improved performance
OO databases
21
Disadvantages
lack of a universal data model lack of experience lack of standards query optimisation compromises encapsulation locking at object level may have repercussions on
performance high complexity lack of support for views lack of support for security
OO databases
22
Towards standardisation
Object Oriented Datanase Systems Manifesto (1989) 13 mandatory features proposed
the Object Model proposed by the Object Database Management Group ODMG 2.0 adopted in September 1997 “de facto” standard