Presentation is loading. Please wait.

Presentation is loading. Please wait.

Object (and Object-Relational) Database Systems (part two)

Similar presentations


Presentation on theme: "Object (and Object-Relational) Database Systems (part two)"— Presentation transcript:

1 Object (and Object-Relational) Database Systems (part two)
CSS263 Lecture 18

2 OBJECT DATABASE SYSTEMS
LECTURE PLAN OBJECT DATABASE SYSTEMS PART TWO What is an OODBMS? Advantages and Disadvantages of OODBMSs What is an ORDBMS? What is SQL3? Comparison of OODBMSs and ORDBMSs When to use an OODBMS When to use an ORDBMS

3 REMINDER OF THE PROBLEMS ASSOCIATED WITH AN RDBMS

4 RELATIONAL DBMSs Poor representation of ‘real world’ entities.
Semantic overloading. Poor support for integrity and business constraints. Homogeneous data structure. Limited operations. Difficulty handling recursive queries. Impedance mismatch. Difficulty with ‘Long Transactions’. PROBLEMS

5 WHAT IS AN OODBMS?

6 OODBMS

7 OBJECT ORIENTED DATABASE MANAGEMENT SYSTEM
OODBMS WHAT IS AN OODBMS? Object Oriented Database Management Systems (OODBMSs) are an attempt at marrying the power of Object Oriented Programming Languages with the persistence and associated technologies of a DBMS. OBJECT ORIENTED DATABASE MANAGEMENT SYSTEM OOPLs DBMSs Complex Objects Persistence Object Identity Disc Management Methods & Messages Data Sharing Inheritance Reliability Polymorphism Security Extensibility Ad Hoc Querying Computational Completeness

8 THE OO DATABASE MANIFESTO
OODBMS THE OO DATABASE MANIFESTO CHARACTERISTICS THAT ‘MUST BE’ SUPPORTED ·     Complex objects ·     Object Identity ·     Encapsulation ·     Classes ·     Inheritance ·     Overriding and late-binding ·     Extensibility ·     Computational completeness ·     Persistence ·     Concurrency ·     Recovery ·     Ad-hoc querying

9 REQUIREMENTS AND FEATURES
OODBMSs Requirements: Transparently add persistence to OO programming languages Ability to handle complex data - i.e., Multimedia data Ability to handle data complexity - i.e., Interrelated data items Add DBMS Features to OO programming languages Features: The host programming language is also the DML. The in-memory and storage models are merged. No conversion code between models and languages is needed. REQUIREMENTS AND FEATURES

10 TWO-LEVEL STORAGE MODEL FOR A RDBMS
Main or virtual memory Transforming and type checking SQL Secondary storage

11 ACCESSING A RECORD USING AN RDBMS
Page Application memory 3. Access object Record 4. Copy modified fields 2. Copy relevant fields Page Cache DBMS Record 5. Save page 1. Read page Page Secondary Storage Record

12 SINGLE-LEVEL STORAGE MODEL
FOR AN OODBMS Main or virtual memory Secondary storage

13 ACCESSING AN OBJECT USING AN OODBMS
3. Access object Page Application memory 2. Swizzle pointers, etc. 4. Swizzle pointers back, etc. Object 5. Save page 1. Read page Page Secondary Storage Object

14 ADVANTAGES AND DISADVANTAGES OF AN OODBMS?

15 OODBMSs Enriched modelling capabilities Extensibility
Removal of Impedance Mismatch Support for schema evolution. Support for long duration transactions. Applicable for advanced database applications Improved performance. ADVANTAGES

16 OODBMSs Lack of a universal data model Lack of experience
Lack of standards. Ad-hoc querying compromises encapsulation. Locking at object-level impacts performance Complexity Lack of support for views Lack of support for security DISADVANTAGES

17 WHAT IS AN ORDBMS?

18 In essence ORDBMSs are an attempt to add OO to Tables!
Definition: Object-Relational databases extend the Relational Data Model to address those weaknesses identified previously. An Object-Relational database adds features associated with object-oriented systems to the Relational Data Model. WHAT IS AN ORDBMS? In essence ORDBMSs are an attempt to add OO to Tables!

19 MAJOR DIFFERENCE BETWEEN AN ORDBMS AND AN OODBMS
ORDBMSs MAJOR DIFFERENCE BETWEEN AN ORDBMS AND AN OODBMS OODBMSs try to add DBMS functionality to one or more OO programming languages. REVOLUTIONARY IN THAT THEY ABANDON SQL ORDBMSs try to add richer data types and OO features to a relational DBMS. EVOLUTIONARY IN THAT THEY EXTEND SQL

20 SQL3

21 ORDBMSs SQL3 or SQL/99: SQL3 is a superset of SQL/92, in that it supports all of the constructs supported by that standard, as well as adding new ones of its own. Therefore, whatever worked in an implementation of SQL/92 should also work in an implementation of SQL3. WHAT IS SQL3? HOWEVER, IT SHOULD BE NOTED THAT AS YET THERE ARE NO IMPLEMENTATIONS OF SQL3!

22 ORDBMSs Extended Base Types. Row Types. User-Defined Types.
User-Defined Routines. Sub-Types and Super-Types. Sub-Tables and Super-Tables. Reference Types and Object Identity. Collection Types. WHAT IS NEW IN SQL3?

23 SQL3 - EXTENDED BASE TYPES
ORDBMSs SQL3 - EXTENDED BASE TYPES ONE OF THE REASONS FOR THE MOVE AWAY FROM RDBMSs IS THE LIMITED BASE TYPE AVAILABILITY: BASE TYPES AVAILABLE IN SQL/92 INCLUDE: NUMBER, CHAR, DATE, ... BASE TYPES IN SQL3 ARE EXTENSIBLE. THEREFORE THE FOLLOWING MUCH NEEDED TYPES COULD BE ADDED (PROVIDED SOMEBODY CREATES THEM!) VIDEO, IMAGE, AUDIO, TEXT, SPATIAL, TEMPORAL, GEOGRAPHIC, WEB-PAGES, ...

24 ORDBMSs SQL3 - ROW TYPES OXFORD MARSDEN HIGH ST. 30 LONDON LEYTON
CITY AREA STREET ADDRESS OXFORD MARSDEN HIGH ST. 30 LONDON LEYTON HIGH RD. 20 BARKING MAIN ST. 10 BRANCHNO CREATE TABLE branch ( branchno VARCHAR(3), address ROW ( street VARCHAR(25), area VARCHAR(15), city VARCHAR(15)); COLUMN ATTRIBUTES NO LONGER HAVE TO BE ATOMIC!

25 SQL3 - USER-DEFINED TYPES
ORDBMSs SQL3 - USER-DEFINED TYPES CREATE TYPE person_type AS ( PRIVATE date_of_birth DATE CHECK (date_of_birth > DATE ‘ ’), PUBLIC name VARCHAR(15) NOT NULL, address VARCHAR(50) NOT NULL, tel_no VARCHAR(13) NOT NULL, FUNCTION get_age (P person_type) RETURNS INTEGER /* code to calculate age from date_of_birth */ RETURN END) NOT FINAL; An example of a User-Defined Routine (UDR)

26 SQL3 - SUB-TYPES & SUPER-TYPES Multiple Inheritance is allowed!
ORDBMSs SQL3 - SUB-TYPES & SUPER-TYPES PERSON-TYPE date of birth name address tel-no get_age() STAFF-TYPE sno position salary branch is_manager() Sub-Types and Super-Types are used to allow for INHERITANCE in SQL3 A Sub-Type can inherit from more than one Super-Type. Multiple Inheritance is allowed!

27 SQL3 - SUB-TYPES & SUPER-TYPES
ORDBMSs SQL3 - SUB-TYPES & SUPER-TYPES CREATE TYPE staff_type UNDER person_type AS ( sno VARCHAR(5) NOT NULL UNIQUE, position VARCHAR(10) NOT NULL, salary NUMBER(7,2), bno VARCHAR(3) NOT NULL, CREATE FUNCTION is_manager (s STAFF_TYPE) RETURNS BOOLEAN BEGIN IF s.position = ‘Manager’ THEN RETURN TRUE; ELSE RETURN FALSE; END IF END) NOT FINAL; Another example of a User-Defined Routine (UDR)

28 ORDBMSs SQL3 - TYPES & TABLES
In order to remain upwardly compatible with SQL-92, TYPES can ONLY be instantiated through SQL Tables! Therefore, in order to create instances of a type we first have to create a table to store those instances in! CREATE TABLE staff OF STAFF_TYPE ( PRIMARY KEY sno); EXAMPLE: In order to create staff instances we first have to do one of the following: CREATE TABLE staff ( info STAFF_TYPE,

29 ORDBMSs SQL3 - SUB-TABLES & SUPER-TABLES
PROBLEM - What happens if we create two or more tables for the same TYPE? How do we find all TYPE instances? CREATE TABLE lecturer OF STAFF_TYPE ( PRIMARY KEY sno); EXAMPLE: FIND ALL MEMBERS OF STAFF! CREATE TABLE admin OF STAFF_TYPE ( The only way of doing this is to declare the lecturer and admin tables as sub-tables of a staff super-table!

30 SQL3 - SUB-TABLES & SUPER-TABLES
ORDBMSs SQL3 - SUB-TABLES & SUPER-TABLES SUPER-TABLE CREATE TABLE staff OF STAFF_TYPE ( PRIMARY KEY sno); SUB-TABLES CREATE TABLE lecturer OF STAFF_TYPE UNDER staff ( PRIMARY KEY sno); CREATE TABLE admin OF STAFF_TYPE UNDER staff ( PRIMARY KEY sno); SOLUTION TO PROBLEM (FIND ALL STAFF): SQL> SELECT * FROM staff;

31 SQL3 - REFERENCE TYPES AND OIDS
ORDBMSs SQL3 - REFERENCE TYPES AND OIDS A Reference Type is the SQL3 equivalent of an OID in an OODBMS. Reference Types allow a row to be shared among multiple tables, and enable users to replace complex join operations with path expressions! EXAMPLE: CREATE TYPE staff_type UNDER person_type AS ( sno VARCHAR(5) NOT NULL UNIQUE, position VARCHAR(10) NOT NULL, salary NUMBER(7,2), next_of_kin REF(person_type) bno VARCHAR(3) NOT NULL) NOT FINAL; CREATE TABLE person OF person_type ( oid REF(person_type) VALUES ARE SYSTEM GENERATED); Could point to a row in ANY table containing a person_type!

32 SQL3 - REFERENCE TYPES AND OIDS
ORDBMSs SQL3 - REFERENCE TYPES AND OIDS To ensure that a REFERENCE is limited to a single table, a SCOPE has to be added to the table using the REFERENCE! CREATE TYPE staff_type UNDER person_type AS ( sno VARCHAR(5) NOT NULL UNIQUE, position VARCHAR(10) NOT NULL, salary NUMBER(7,2), next_of_kin REF(person_type) bno VARCHAR(3) NOT NULL) NOT FINAL; CREATE TABLE person OF person_type ( oid REF(person_type) VALUES ARE SYSTEM GENERATED); EXAMPLE: CREATE TABLE staff OF staff_type ( PRIMARY KEY sno, SCOPE FOR next_of_kin IS person); staff next_of_kin will point to a row in the person table!)

33 ORDBMSs SQL3 - COLLECTION TYPES
SQL3 COLLECTION TYPES ARE THE EQUIVALENT OF COLLECTION TYPES IN OODBMSs List (base) ordered collection allows duplicates Array (base) one-dimensional array, max no. Set (base) - unordered collection, no duplicates Multiset(base) - unordered collection, allows duplicates KNOWN AS A ‘BAG’ IN AN OODBMS!

34 REPEATING GROUPS ARE ALLOWED!
ORDBMSs SQL3 - COLLECTION TYPES EXAMPLE CREATE TABLE branch ( bno NUMBER(3), address ROW ( street VARCHAR(15), area VARCHAR(15), city VARCHAR(15) staff SET (STAFF_TYPE)); THE USE OF COLLECTION TYPES WITHIN TABLES ENSURE THAT TABLES NO LONGER HAVE TO BE IN 1NF REPEATING GROUPS ARE ALLOWED!

35 ORDBMSs SQL3 - OTHER ADDITIONS
THE MAIN ADDITIONS TO SQL THAT ARE NOT SPECIFICALLY ASSOCIATED WITH ADDING OBJECT-SUPPORT ARE THE FOLLOWING: SQL IS NOW COMPUTATIONALLY COMPLETE PERSISTENT STORED MODULES ARE SUPPORTED TRIGGERS ARE SUPPORTED

36 OODBMS or ORDBMS?

37 OODBMS or ORDBMS CONSIDERATIONS
OODBMS - put more emphasis on the role of the client, i.e., Client side caching! This can radically improve long, process intensive, transactions. ORDBMS - SQL is still the language for data definition, manipulation and query – Still have Impedance Mismatch! OODBMSs have been optimised to directly support object-oriented applications and specific OO languages. ORDBMSs are supported by most of the ‘major players’ in the DBMS market place.

38 OODBMS or ORDBMS CONSIDERATIONS
ORDBMS - Most third-party database tools are written for the relational model (SQL-92), and will therefore be backward-compatible with SQL3. ORDBMS - search, access and manipulate complex data types in the database with standard SQL (SQL3), without breaking the rules of the relational data model. OODBMS – The ODMG standard group’s OQL is now the de-facto query language amongst OODBMS vendors. However, in order to use it, collection objects (known as extents) have to first be created for each class.

39 OODBMS or ORDBMS CONSIDERATIONS
OODBMS - In order to realise the value of an OODBMS you must build your application using methods written in one of several object-oriented language (i.e. C++, Java, Smalltalk).

40 WHEN TO USE AN OODBMS

41 OODBMS or ORDBMS In applications that generally retrieve relatively few (generally physically large) highly complex objects and work on them for fairly long periods of time. This will necessitate the use of client caching, pointer swizzling, and non-locking forms of concurrency control. WHEN TO USE AN OODBMS

42 WHEN TO USE AN ORDBMS

43 OODBMS or ORDBMS In applications that process a large number of short-lived (generally ad-hoc query) transactions on data items that can be arbitrarily complex in structure. Where the main emphasises is on efficient query optimisation to limit disk accesses, and traditional concurrency control is acceptable. WHEN TO USE AN ORDBMS


Download ppt "Object (and Object-Relational) Database Systems (part two)"

Similar presentations


Ads by Google