1 / 22

Object Oriented databases

Object Oriented databases. Developing OODBMS - motivation. motivation more and more application areas require systems that offer support (implement) for both traditional language programming and database capabilities. Traditional programming languages. procedural control data abstraction

mura
Télécharger la présentation

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. Object Oriented 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

  3. Traditional programming languages • procedural control • data abstraction • functional abstraction

  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

  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

  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)

  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, whensome 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)

  8. Cause of drawbacks • 2 level storage model persistent memory main or virtual memory conceptual / external physical transformations + type checking application program SQL

  9. Possible solution • single level storage model (pointer swizzling - OID - next slide) main or virtual memory persistent memory application program

  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)

  11. OO DBMS - Khoshafian and Abnous, 1990 • OO DBMS = object orientation + database capabilities

  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

  13. OO DBMS- Zdonic and Maier • definition through features provided • database functionality • support object identity • provide encapsulation • support objects with complex state

  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

  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

  16. Issues in OO DBMSs • transactions • versioning • schema evolution

  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

  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

  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)

  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

  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

  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

More Related