Transcript Course Description - Goldsmiths, University of London

OO databases
Object Oriented databases
1
OO databases
Developing OODBMS - motivation
 motivation
 more and more application areas require systems that offer
support (implement) for both traditional language
programming and database capabilities
2
OO databases
Traditional programming languages
 procedural control
 data abstraction
 functional abstraction
3
OO databases
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
4
OO databases
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
5
OO databases
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)
6
OO databases
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)
7
OO databases
Cause of drawbacks
persistent memory
physical
conceptual /
external
SQL
transformations +
type checking
 2 level storage model
main or virtual memory
application program
8
OO databases
Possible solution
 single level storage model (pointer swizzling - OID - next slide)
main or virtual memory
persistent memory
application program
9
OO databases
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)
10
OO databases
OO DBMS - Khoshafian and Abnous, 1990
 OO DBMS = object orientation + database capabilities
11
OO databases
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
12
OO databases
OO DBMS- Zdonic and Maier
 definition through features provided




database functionality
support object identity
provide encapsulation
support objects with complex state
13
OO databases
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
14
OO databases
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
15
OO databases
Issues in OO DBMSs
 transactions
 versioning
 schema evolution
16
OO databases
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
17
OO databases
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
18
OO databases
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)
19
OO databases
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
20
OO databases
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
21
OO databases
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
22