more manifestos
play

More manifestos In 1990 Stonebraker responded to Atkinsons 1989 - PowerPoint PPT Presentation

Dec 18, 2022 •366 likes •619 views

More manifestos In 1990 Stonebraker responded to Atkinsons 1989 database manifesto with The Third-Generation Database System Manifesto with guidelines concerning future development of relational DBMS to allow them to remain dominant Two

  1. More manifestos In 1990 Stonebraker responded to Atkinsons 1989 database manifesto with ”The Third-Generation Database System Manifesto” with guidelines concerning future development of relational DBMS to allow them to remain dominant Two years later Date and Darwen published “The Third Manifesto” where they attack Stonebraker and reject SQL, calling it a perversion. Object-Relational datbases and SLQ3 follow to a large extent Stonebrakers ideas DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 1 / 24

  2. Object-relational databases Relational DBs were developed to, above all else, cover large organisations need for information in order to • facilitate accounting • manage payrolls • manage orders Functions and activities simple to map onto a (largely) static relational structure. DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 2 / 24

  3. Object relational databases . . . Computer Science successively penetrates new application and problem areas. Areas that demand databases but where the necessary structures are so complex (sometimes of unknown complexity) that relational databases are inadequate. Or must meet demands on managing sequences of events (or versions) Object databases were created. The relation, that formed the basis for the database revolution, was reduced to one of many data types. But . . . • a lot of knowhow had been invested in relational technology • most problems are still better solved with relational systems • and we know little or nothing about tomorrow and . . . DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 3 / 24

  4. Object relational databases . . . after 15 years of quarantine there was no agreements on anything, neither in the research area nor in the business area. No consensus on how to represent an object. No consensus on how to store an object No consensus on how to send or recieve messages and, finally, no consensus on how to execute the messages (the code in the objects) The industrial sector got tired of waiting and wanted also to preserve and make use of their extensive knowhow on relational systems. DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 4 / 24

  5. Object relational databases . . . There are benefits with the relational systems • Simple mathematics • Simple basic data type (the relation) • Efficient indexing • Optimization So, the industry developed an interest to continue with relational systems also for complex/complicated data DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 5 / 24

  6. Object relational databases . . . You have complex data in a number of application areas where people already had acquired good knowledge of RDBMS • multi-media applications for www • medical systems (EKG, X-ray photos, MRI (magnetic ray imaging) • geografical systems (as well as other spatial systems – managing seismic data, satellite images, . . . ) • economical and statistical systems (time series . . . ) DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 6 / 24

  7. Object relational databases . . . Also, the switch to object systems also meant using databases more for persistence in programs than traditional database management There was still a need for systems where you stored information for later use There was a research project that could form the basis for a new model. And . . . it was already commercial They turned things over again and kept the relation as the basic data type and data structure and created extendible type systems instead. This meant higher demands on DBMS manufacturers. There were already stored procedures and BLOBS They had to be extended and made more efficient and indexing had to become extendible too Some architectures for ORDBMS were tested . . . DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 7 / 24

  8. ORDBMS – architectures, wrapper/mapper W M R A A P / P P P E E R R RDBMS Client • Good use of existing systems • Rapid to implement • Rapid to upgrade • Performance problems because of the extra mapping • Performance problems because of transformation OO ↔ Relationer DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 8 / 24

  9. ORDBMS – architectures, merge via gateway G A T RDBMS A E P W I A Y Client ODBMS • Good support for existing RDB • Rapid to upgrade from existing system • Complicated to upgrade • Demands efficient gateways • Still gives performance problems in the merge/split part of the API DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 9 / 24

  10. ORDBMS – architectures, universal server Client OR Server ORDB • Universal server • Good support for existing RDB • Simple upgrade from existing system in terms of knowhow • Has to be as efficient as RDBMS and as flexible as OODBMS • Complicated reengineering/new development • Risk being an inefficient compromise DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 10 / 24

  11. ORDBMS – demands • It must be possible to query, access and manipulate even complex data structures from within SQL without braking traditional RDBMS rules/restrictions. • It is not possible to build completely generalised systems and thus it is important to deliver the tools for extending and adapting data type system, index system and optimiser • Extensions must be pluggable as it isn’t reasonable for DBMS clients to wait until next version or to expect that next version will cover their specific needs. • It is not reasonable to expect the manufacturers to deliver a new version for every newly discovered requirement. DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 11 / 24

  12. ORDBMS . . . Some manufacturers have chosen the universal server approach and deliver a DBMS with pluggable modules that well covers a large variety of different customer needs Third party manufacturers can deliver modules that are specialized for their field of interest. The extendibility must cover more than just data types as it must be possible to use SQL and to index the new data type items DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 12 / 24

  13. ORDBMS – a peek at history The Stonebraker research team were already commercially successful with Ingres (1980) and had visions. They continued with their next product, Postgres, with extendible type system and an embryo for procedures stored in the database and that executed in DB primary memory. The product is nowadays available under GPL and named PostgreSQL as their original query language has been replaced by SQL. Illustra, the first GIS system, was built on Postgres and introduced in 1992 with immediate success. Informix bought Illustra in 1996 and refined the system and merged it with their own RDBMS, The result was the first extendible ORDBMS. DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 13 / 24

  14. ORDBMS – a peek at history . . . The rest of the relational database community went crazy. They understood that this was the future. Everybody wanted to be part of the new development. Research project were started. Soon enough many delivered ORDBMS but none as general and sophisticated as the Informix Universal Server. However, a product is not enough. Informix had enormous management problems and were bought by IBM who continues development of both Informix DBMS and DB2, their own product. Then, what exactly is an ORDBMS? What facilities do they have that traditional RDBMS don’t? Let’s take a look at what the larger of the manufacturers have done to their products. DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 14 / 24

  15. ORDBMS – what is new? Binary Large OBject, BLOB , were already in RDBMS, a new “data type”, a binary string that could be several GB in size. Strings are not as simple to manage as more complex structures. Its size demands that it is mainly treated as a byte stream. The lack of structure made it important to use extra meta data to clarify its real structure. So you cannot formulate queries about BLOBs or their structure. DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 15 / 24

  16. ORDBMS – what’s new . . . ? Operations and algorithms that are necessary to manipulate BLOBs are not possible to implement in a general fashion (for querying) in spite of the fact that we deal with rich, complex and well structured data (images, video, audio, XML, html, . . . documents) Mostly we must rely on external programs and, maybe, just to verify that the content is uninteresting. Besides BLOBs, CLOBs (Character Large OBjects) were introduced. Strings have structure so you can search them. Some systems implement other “LOB” types. DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 16 / 24

  17. ORDBMS – what’s new . . . ? Additions apart from BLOB and CLOB • row types (essentially composite attributes) • user defined types, procedures and functions • polymorphism • inheritance • reference types and object identity • “collections” : ARRAY, SET, LIST, MULTISET • triggers • recursion (mainly convex hull recursion) Let us look at some of it and compare ORDBMS with OODBMS. The examples stem from Postgres DD2471 (Lecture 07) Modern database systems & their applications Spring 2012 17 / 24

More recommend