Objektov é databázy

1. Objektové databázy PDT Genči

2. Obsah • Motivácia • Manifesty • ODMG • SQL3

3. Zdroje [1] The Object-Oriented Database System Manifesto Kyoto, Japan, December 1989 [2] Third-Genreation Database System Manifesto ACM SIGMOD Record 19(3) (September 1990) [3] The Third ManifestoACM SIGMOD Record 24 (1), (March 1995) [4] SQL3 Pozor!!! [5] ODMG 3.0

4. Porovnanie relačnej a objektovo orientovanej databázy Predstavme si, že máme databázu, v ktorej máme tabuľku zamestnancov (Employee Table) a tabuľku oddelení (Department Table). Na určenie obojsmernej príslušnosti zamestnancov a oddelení potrebujeme vytvoriť ďalšiu tabuľku (Dept_Empl Table), ktorá spája cudzí kľúč (foreign key) z tabuľky zamestnancov a tabuľky oddelení.

5. Porovnanie relačnej a objektovo orientovanej databázy

6. Porovnanie relačnej a objektovo orientovanej databázy • V OO databáze sú vzťahy vyjadrené priamo, teda nie je potrebné ich modelovať pomocou ďalšej tabuľky.

7. Stav v 1. polovici 90-tych rokov Generacie DBS • network and hierarchical database systems -CODASYL systems and IMS • Relationaldatabase systems. • New types of application – CAD, CASE, CIM, Office automation (integration of texts, images, animation, audio, video), medical information systems – all this application manipulate with complex data

8. Object-relational impedance mismatch • set of conceptual and technical difficulties which are often encountered when a relational database management system is being used by a program written in an object-oriented programming language or style (Wikipedia)

9. Types of impedance mismatch • Encapsulation • Data type differences (major mismatch) • Structural and integrity differences • Manipulative differences • Transactional differences

10. The Object-Oriented Database System Manifesto(1989) Malcolm Atkinson, University of Glasgow Francois Bancilhon, Altair David DeWitt, University of Wisconsin Klaus Dittrich, University of Zurich David Maier, Oregon Graduate Center Stanley Zdonik, Brown University

11. OODBS • Manifest attempts to define an object-oriented database system • It describes the main features and characteristics that a system must have to qualify as an object-oriented database system.

12. Characteristics • Mandatory - the ones the system must satisfy in order to be termed an object-oriented database system • Optional - the ones that can be added to make the system better, but not mandatory • Open - the points where the designer can make a number of choices

13. Mandatory features • Complex objects • Object identity • Encapsulation • Types and Classes • Class or Type Hierarchies • Overriding, overloading and late binding • Computational completeness • Extensibility

14. Mandatory features (cont.) • Persistence • Secondary storage management • Concurrency • Recovery • Ad Hoc Query Facility

15. Optional • Multiple inheritance • Design transactions • Versions

16. Open • Programming paradigm • Representation system defined by the set of atomic types and the set of constructors • Type system • Uniformity (is a type an object? is a method an object? or should these three notions be treated differently?)

17. Third generation DBS Manifesto (1990) The Committee for Advanced DBMS Function (Michael Stonebraker of the University of California, Berkeley, Lawrence A. Rowe of the University of California, Berkeley, Bruce Lindsay of IBM Research, James Gray of Tandem Computers, Michael Carey of the University of Wisconsin, Michael Brodie of GTE Laboratories, Philip Bernstein of Digital Equipment Corporation, David Beech of Oracle Corporation.)

18. THE TENETS OF THIRD-GENERATION DBMSs • TENET 1: Besides traditional data management services, third generation DBMSs will provide support for richer object structures and rules. • TENET 2: Third generation DBMSs must subsume second generation DBMSs. • TENET 3: Third generation DBMSs must be open to other subsystems.

19. Tenet 1: support for richer object structures and rules • capabilities required to store and manipulate non-traditional data elements such as text and spatial data. • an application designer should be given the capability of specifying a set of rules about data elements, records and collections (Referential integrity in a relational context is one simple example of such a rule; however, there are many more complex ones)

20. Tenet 2: subsume second generation DBMSs • second generation systems made a major contribution in two areas: • non-procedural access • data independence • these advances must not be compromised by third generation systems. • Some argue that there are applications which never wish to run queries (CAD)

21. Tenet 3: open to other subsystems • DBMS which expects broad applicability must have • a fourth generation language (4GL), • various decision support tools, • friendly access from many programming languages, • Friendly access to popular subsystems such as LOTUS 1-2-3, • interfaces to business graphics packages, • the ability to run the application on a different machine from the database, • distributed DBMS.

22. THE PROPOSITIONS • Concerning Object and Rule Management • Concerning Increasing DBMS Function • that Result from the Necessity of an Open System

23. Propositions Concerning Object and Rule Management • A third generation DBMS must have a rich type system. • Inheritance is a good idea. • Functions, including database procedures and methods, and encapsulation are a good idea. • Unique Identifiers (UIDs) for records should be assigned by the DBMS only if a user-defined primary key is not available. • Rules (triggers, constraints) will become a major feature in future systems. They should not be associated with a specific function or collection.

24. Rich type system • All of the following are desirable: • an abstract data type system to construct new base types • an array type constructor • a sequence type constructor • a record type constructor • a set type constructor • functions as a type • a union type constructor • recursive composition of the above constructors

25. Propositions Concerning Increasing DBMS Function • Essentially all programatic access to a database should be through a non-procedural, high-level access language. • There should be at least two ways to specify collections, one using enumeration of members and one using the query language to specify membership. • Updatable views are essential. • Performance indicators have almost nothing to do with data models and must not appear in them.

26. Propositions that Result from the Necessity of an Open System • Third generation DBMSs must be accessible from multiple HLLs. • Persistent X for a variety of Xs is a good idea. They will all be supported on top of a single DBMS by compiler extensions and a (more or less) complex run time system. • For better or worse, SQL is intergalactic dataspeak. • Queries and their resulting answers should be the lowest level of communication between a client and a server.

27. The Third Manifesto(1995) Hugh Darwen and C.J. Date

28. Manifesto regarding the future of data and database management systems. • It was intended to follow and supersede two previous manifestos

29. Main ideas • Importance and significance of Relational Model of Data • Reject SQL unequivocally

30. Mindset • Acknowledge the desirability of supporting certain features of Object Orientation. • They believe that OO features are orthogonal to the Relational Model, and therefore that the Relational Model needs no extension, no correction, no subsumption (zaradenie, včlenenie).

31. Content of Manifesto • The manifesto consists of a series of: • Prescriptions • Relational Model Prescriptions (RM Prescriptions) • Other Orthogonal Prescriptions (OO Prescriptions) • Proscriptions (RM and OO) • “very strong suggestions.” (RM and OO)

32. RM Prescriptions 1. Domains 2. Typed scalars 3. Scalar operators 4. Actual representation 5. Truth values 6. Type constructor TUPLE 7. Type constructor RELATION 8. Equality operator 9. Tuples 10. Relations 11. Scalar variables 12. Tuple variables 13. Relation variables (relvars) 14. Base vs. derived relvars 15. Database variables (dbvars) 16. Transactions and dbvars 17. Create/destroy operations 18. Relational algebra 19. Relvar names and explicit relation values 20. Relational functions 21. Relation and tuple assignment 22. Comparisons 23. Integrity constraints 24. Relation and database predicates 25. Catalog 26. Language design

33. RM Proscriptions 1. No attribute ordering 2. No tuple ordering 3. No duplicate tuples 4. No nulls 5. No nullological mistakes 6. No internal-level constructs 7. No tuple-level operations 8. No composite columns 9. No domain check override 10. Not SQL

34. OO Prescriptions 1. Compile-time type checking 2. Single inheritance (conditional) 3. Multiple inheritance (conditional) 4. Computational completeness 5. Explicit transaction boundaries 6. Nested transactions 7. Aggregates and empty sets

35. OO Proscriptions 1. Relvars are not domains 2. No object IDs 3. No “public instance variables” 4. No “protected instance variables” or “friends”

36. RM Very Strong Suggestions 1. Candidate keys for derived relvars 2. System-generated keys 3. Referential integrity 4. Candidate key inference 5. Quota queries 6. Transitive closure 7. Tuple and relation parameters 8. Default values 9. SQL migration

37. OO Very Strong Suggestions 1. Type inheritance 2. Collection type constructors 3. Conversion to/from relations 4. Single-level store

38. Štandard OODB – ODMG

39. História a vývoj ODMG • Objektovo-orientovaný prístup (koniec 80-tych rokov) - vznik skupiny Object Database Management Group (podskupina OMG) • Ciele: • vytvorenie priemyselného štandardu pre OODBS • preklenutie tzv. „impedance mismatch“

40. Hlavné kroky štandardu ODMG • 1994 – Zverejnenie prvého návrhu štandardu ODMG-93 • Zaviazanie výrobcov pre implementáciu štandardu –mnohí výrobcovia ponúkajú rozhranie ODMG-3.0 • 1994 vychádza opravená verzia pod názvom ODMG-93 Release 1.1 • 1996 - ODMG-93 Release 1.2 • Zmeny zabraňujú plnej spätnej kompatibilite • Aktuálna verzia: ODMG 3.0 vydaná v roku 2000. Odvtedy sa nevyvíja • Vylepšenia: Väzba Java, Objektový model a O-R mapovanie

41. Architektúra ODMG Štandard ODMG sa vzťahuje na tieto veci: • Objektový model (perzistentnosť) • Určuje jazyk špecifikácie objektov – ODL(Object Definition Language) a OIF(Object Interlanguage Format) • Určuje objektový dotazovací jazyk OQL (Object Query Language) • Stanovuje väzby pre rôzne objektovo-orientované jazyky, akými sú Java, C++, Smalltalk • väzba na OMG štandard CORBA a konkrétne na jeho komponentu ORB (Object Request Broker)

42. Prepojenie prvkov architektúry

43. Objektový model ODMG 3.0 • Vzťah objektov a hodnôt (literálov) v OO DB • Zapúzdrenie • Identita objektov • Určovanie tried a vzťahov medzi nimi (asociácie) • Použitie špecializácie tried (alias dedičnosť) • Perzistentnosť

44. objekt - inštancia abstraktného údajového typu (alias trieda) • hodnota - inštancia jednoduchého údajového typu • OID – Object Identification • Stav objektu - hodnota jeho atribútov, vrátane referenčných • Kategorizácia objektov a literálov podľa typov a schém

45. Dátové typy • Atomické : • long, • long long, • short, • unsigned long, • float, • double, • boolean, • octet, • char, • string, • enum <>

46. Dátové typy • Agregované: • set<>, • bag<>, • list<>, • array<>, • dictionary<> • Štruktúrované literály : • date • time • timestamp • interval • structure<>

47. Dátové typy • Agregované dátové typy ako triedy : set<>, bag<>, list<>, array<>, dictionary<> so všetkými iterátormi • Štruktúrovaný dátový typ ako trieda : Date, Time, Timestamp, Interval

48. OID • Prostriedok určovania identity objektov • Generuje sa pri vytváraní objektu • Je to sériové číslo • stabilná a jednoznačná hodnota • Štandard nehovorí o tom, či sú jednotlivé OID opätovne použité pri zrušení objektu • Používateľ (alias aplikácia) OID nevidí, iba databáza (názvy objektov) • Ddomény referenčných údajových typov (alias smerníky) obsahujú práve tieto OID hodnoty

49. Jazyk ODL • Opis objektových štruktúr a ER diagramov • Vzťah tried a rozhraní: • class názov_triedy : názov_rohrania • Perzistentné rozšírenie triedy – extent • Nie je definovaná podpora pre migráciu objektov (presun z jedného OODBS do druhého) ani podmienené výrazy • Podpora kľúčov – keys

50. Príklad trieda Pracovnik ( extent PracovnikRozsirenie key PracovnikCislo) { attribute Long PracovnikCislo; attribute Struct PracovnikMeno { String meno, String priezvisko, String rodneMeno } pracovnikMeno; attribute Date datumNarodenia; attribute Short plat; void zvys_plat (in short nariadenie); ... };