Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Object-Oriented Databases Chapter 11. 2 Limitations to the relational model? Examples of applications that will not work well with the relational model?

Similar presentations


Presentation on theme: "1 Object-Oriented Databases Chapter 11. 2 Limitations to the relational model? Examples of applications that will not work well with the relational model?"— Presentation transcript:

1 1 Object-Oriented Databases Chapter 11

2 2 Limitations to the relational model? Examples of applications that will not work well with the relational model?

3 3 Shortcomings of DB models for: CAD/CAM - keep track of 1000's of matching parts and subassemblies – relational inefficient for this – object versioning complex market-oriented operations (securities) geographical information systems CASE multimedia databases WWW

4 4 Different because of: requirements and characteristics that differ from traditional business applications more complex structures for objects new data types for storing images, text, user defined types nonstandard application specific operations

5 5 OODB systems Prototypes: ORION, IRIS, ENCORE, Commercial products: –ObjectStore V7.3 (free download, mentions big data) –Versant V8 (free downloads) –Objectivity/DB 10 (mentions big data), also has InfiniteGraph –Discontinued: Itasca based on Orion, POET

6 OODB systems Open source object database –PostgreSQL 9.1 (or is it ORDB?) –Perst (McObject) – supports SQL, ACID, etc. Used by DirectTV –Db4o – queries only in Java, C#, VB.NET (owned by Versant) –Magma 4.2 ?? Still around, old websites – Squeak (smalltalk-Gemstone) 6

7 7 Different approaches to designing OODB 1. Applications written in extension of existing OOPL (1st generation OODB) to include: DB functionality –store and manage objects created by OOPL –DB features such as transactions, concurrency control, etc. Selling point - unified programming and DB language but need query optimization, etc. – Gemstone (Smalltalk), Poet (C++)

8 8 Designing cont’d 2. Extend relational DB to include OO features: –OID, type hierarchy, inheritance, encapsulation, arbitrary data types, nested objects, etc. –Query language extended with programming capability – application communicates with DBMS through embedded query language calls in application program –Already familiar with DBMS but performance decreased Postgres - extended Ingres, Oracle

9 9 Designing cont’d 3.Start entire process from scratch - unify relational and OO system –(next generation?) – NO

10 10 Object Data Model - ODM Bring concepts of OOPL into DB systems – Object corresponds to mini-world object – Object is data and behavior, object has attributes and operations (methods) Encapsulation (SQL, optimization?) – Data object has OID – immutable Identity vs. value based Generated by system – Group data objects into classes (or types) - abstract mechanism, share same structure and behavior

11 11 ODM Class has: –instances –methods and data - encapsulation for information hiding - access only through methods –composite classes - composed of multiple types –nested objects - contains another object –complex objects - set of objects –class hierarchy (ISA) – specialization - define new classes from existing ones –inheritance of attributes and methods - reuse

12 12 ODM Encapsulation implementation hidden define behavior of object using operations object accessible through predefined operations If query on attributes? –SQL violates encapsulation SQL for visible (OSQL), rest is encapsulated

13 13 ODM Completeness DBS needs to be computationally complete (Turing) SQL not computationally complete - unless embedded SQL –impedance mismatch, since sets connections with DML and OOPL in ODB more acceptable

14 14 ODM Add features such as: –concurrency –recovery –schema evolution –Versions – What about query language? – Performance?

15 15 ODM Object identity OID correspondence between real-world and database objects OIDs like RIDs except can point to other OIDs used to refer to objects in application programs and in references between objects(relationships) unique over entire DB and even over distributed DB

16 16 OID vs. primary key identity based vs. value-based unique over entire DB and even over distributed DB (if primary key changes, still same real-world object) immutable - values of OID for object should not change - OID not assigned to another object - not dependent on any attribute values - not use physical address system generated OID not visible to user

17 17 OIDs in reality in extended ODMSs, query language extended to allow access by OID in OOPL, allow value based access by key in Postgres - oid attribute in every tuple

18 18 OID Implementation 1. physical address - fast – rarely used, cannot move or delete - if so, all references must be changes also 2. structured addresses - popular, 1-2 disk accesses physical and logical component segment and page # and logical slot number if change, use forwarding

19 19 OID Implementation cont’d 3. surrogates - poorer retrieval –purely logical – use any algorithm to produce unique IDs (e.g. date, time) – use hash index to map to physical address (Postgres) –object pages are hash buckets - single disk access

20 20 OID Implementation cont’d 4. typed surrogate - like surrogate for retrieval – contains type ID and object ID – can obtain type without fetching it - ORION – difficult to change type - may be useful to be able to segment address space (distributed)

21 21 OID Implementation More efficient for artificially generated identifiers Performance improved if generate OID to speed object lookup

22 22 Swizzling All references in cached objects replaced with object's address pointer to other memory resident objects - swizzling saves OID lookup with subsequent references

23 23 Implementation Issues: pointer (OID) to nested object nested - no joins needed –path queries instead of joins when bring in an object into memory, bring in nested objects as well replace OID with memory address (can't do this in relational) – eager and lazy swizzling fast access - memory resident

24 OSQL – Object SQL 24 ODMG (disbanded) provided standards for ODB just like relational databases. Result is OSQL (object SQL)OSQL

25 25 Object-relational - ORDMS Informix, IBM, Hewlett-Packard, Unisys, Oracle, and UniSQL “Extended relational" is probably the more appropriate term ORDMSs specified by the extensions to the SQL standard, SQL3/4 http://en.wikipedia.org/wiki/Comparison_of_object- relational_database_management_systemshttp://en.wikipedia.org/wiki/Comparison_of_object- relational_database_management_systems

26 26 ORDMS Superset of RDMS Definition? –Allows user defined types –User defined functions –Indexing/access methods to support them ORDBMSs have had their greatest success in managing media objects and complex data such as geospatial and financial time series data frequently used in Web applications and specialized data warehouses

27 27 Oracle’s object relational Oracle ORDB –Relaxes 1NF –Has object types, so users can create tables and objects –Allows users to create Types as objects Object tables –OIDs –Inheritance

28 28 Create type Create type must be followed by a / in SQL Plus (; optional) No objects created, like a struct type // Create object type Create type name_t as object ( lname varchar(10), fname varchar(10), mi char(1) ) / // Create relational table Create table teachers ( tid int, tname name_t, room int) /

29 29 How to insert? Can use object_type_name( ) form as an object constructor, Builds objects from value of attributes Insert into teachers values (1234, name_t(‘Sky’, ‘Sue’, ‘V’), 120); NOTE: data in name_t is never an OID, it is just the data or a copy of the data if stored elsewhere

30 30 Path queries Select t.tname.lname from teachers t where room = 120; // sometimes aliases are required // in my examples always use them

31 31 Create Object table Create type person_t as object (ssn int, Pname name_t, age int) / Create table people of person_t; To query people: // You can use the usual SQL Select * from people where age > 25; //Or you can use: value ( ) Select value(p) from people p where age > 25;

32 32 Inheritance CREATE TYPE vehicle AS OBJECT (VID VARCHAR2(20), COLOR CHAR(10), MAKE VARCHAR2(10), MODEL VARCHAR2(10) ) NOT FINAL / CREATE TYPE car UNDER vehicle ( DOORSNUMBER, SPORTCHAR(1) ) /

33 33 Ref Object reference //Use REF keyword to point to a row object Create type car_reg as object ( license int, drives ref car) Create table registrations of car_reg; //Use dot notation to follow a REF to derefence a REF: Select r.drives.vid from registrations r; // or can use DEREF to dereference Select DEREF(drives) from registrations; //If you want to display the OIDs of the objects in a table use: Select REF(p) from people p;

34 Examples Notice the difference between a REF and the object_type_name( ) form How to insert tuples and query : ExampleExample of object-relational in Oracle ResultsResults from above in SQL Example Example if creating objects with circular dependencies Set (collection of objects) – nested tables or VARRAY 34

35 Nested tables create type dependent_t under person_t( essn ref employee_t, relationship varchar(10)) create type dependent_tbl as table of dependent_t 35

36 Nested tables Create type employee_t under person_t( ssn int, address varchar(30), … dependent dependent_tbl; You also need: Create table employee of employee_t nested table dependent store as dependent_table; 36

37 Methods member function getName return name_t is begin return name_t(fname, minit, lname); end get Dependent; 37

38 Methods MEMBER FUNCTION getGender return varchar is BEGIN IF self.sex=‘M’ then return ‘Male’; ELSE return ‘Female’; END IF; END; 38

39 Methods create type employee_t as object ( ssn int, etc. member function getGender return varchar, member function getName return name_t); 39

40 To invoke methods Select e.getName(), e.getGender() from employee e; 40

41 41 Performance Performance of OODB affected by: –cache sizes –clustering (all of same class together versus subclass follows superclass) –Nested objects –Indexes (just like relations) –views –swizzling –Replication –Versions (replicate common data?)

42 Versions Shared version (not updatable) –Check out and update –Deleted only by owner Working version –Update/delete by owner –New transient derived from existing one –Existing promoted to working 42

43 Versions Version hierarchy - timestamps user: specify versioned object trace version history delete version (delete all versions created from it or just most recent) merge Class if versionable –Generic object –Default version# –Next version# –Version description –Working or transient 43

44 44 OODB issues physical OODB design – clustering problems (NP-hard) – placing objects onto pages so number of page faults is minimal user hints for clustering where to stores objects, near related objects how to store objects, near related objects

45 45 Example e.g. Bob is a person, but also an employee store all persons Bob Sally Joe Bill Bob Bill Sally Joe person employee students if store extra attributes, must also retrieve information from person class store as employee student retrieve all of them for person

46 46 Schema evolution – dynamically define and modify DB schema – invariant - set of properties of the schema – rules for preserving invariance 2 types of schema changes: – 1. definition of a class (contents (attribute/method) of node) – 2. to structure (edges and nodes)


Download ppt "1 Object-Oriented Databases Chapter 11. 2 Limitations to the relational model? Examples of applications that will not work well with the relational model?"

Similar presentations


Ads by Google