Compiled from Connelly et al. DBMS Text OODBMS vs. ORDBMS Compiled from Connelly et al. DBMS Text 11/17/2018

Advanced Database Applications Computer-Aided Design (CAD) Computer-Aided Manufacturing (CAM) Computer-Aided Software Engineering (CASE) Network Management Systems Office Information Systems (OIS) and Multimedia Systems Digital Publishing Geographic Information Systems (GIS) Interactive and Dynamic Web sites Other applications with complex and interrelated objects and procedural data.

Weaknesses of RDBMSs Poor Representation of “Real World” Entities Normalization leads to relations that do not correspond to entities in “real world”. Semantic Overloading Relational model has only one construct for representing data and data relationships: the relation. Relational model is semantically overloaded.

Weaknesses of RDBMSs Poor Support for Integrity and Enterprise Constraints Homogeneous Data Structure Relational model assumes both horizontal and vertical homogeneity. Many RDBMSs now allow Binary Large Objects (BLOBs).

Weaknesses of RDBMSs Limited Operations RDBMs only have a fixed set of operations which cannot be extended. Difficulty Handling Recursive Queries Extremely difficult to produce recursive queries. Extension proposed to relational algebra to handle this type of query is unary transitive (recursive) closure operation.

Example - Recursive Query (b) is a transitive closure of (a)

Weaknesses of RDBMSs Impedance Mismatch Most DMLs lack computational completeness. To overcome this, SQL can be embedded in a high-level 3GL. This produces an impedance mismatch - mixing different programming paradigms. Estimated that as much as 30% of programming effort and code space is expended on this type of conversion.

Weaknesses of RDBMSs Other Problems with RDBMSs Transactions are generally short-lived and concurrency control protocols not suited for long-lived transactions. Schema changes are difficult. RDBMSs are poor at navigational access.

Storing Objects in Relational Databases One approach to achieving persistence with an OOPL is to use an RDBMS as the underlying storage engine. Requires mapping class instances (i.e. objects) to one or more tuples distributed over one or more relations. To handle class hierarchy, have two basics tasks to perform: (1) design relations to represent class hierarchy; (2) design how objects will be accessed.

Storing Objects in Relational Databases

Mapping Classes to Relations Number of strategies for mapping classes to relations, although each results in a loss of semantic information. (1) Map each class or subclass to a relation: Staff (staffNo, fName, lName, position, sex, DOB, salary) Manager (staffNo, bonus, mgrStartDate) SalesPersonnel (staffNo, salesArea, carAllowance) Secretary (staffNo, typingSpeed)

Mapping Classes to Relations (2) Map each subclass to a relation Manager (staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate) SalesPersonnel (staffNo, fName, lName, position, sex, DOB, salary, salesArea, carAllowance) Secretary (staffNo, fName, lName, position, sex, DOB, salary, typingSpeed) (3) Map the hierarchy to a single relation Staff (staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate, salesArea, carAllowance, typingSpeed, typeFlag)

Two-Level Storage Model for RDBMS

Single-Level Storage Model for OODBMS

Next Generation Database Systems First Generation DBMS: Network and Hierarchical Required complex programs for even simple queries. Minimal data independence. No widely accepted theoretical foundation. Second Generation DBMS: Relational DBMS Helped overcome these problems. Third Generation DBMS: OODBMS and ORDBMS.

OODBMS Manifesto Complex objects must be supported. Object identity must be supported. Encapsulation must be supported. Types or Classes must be supported. Types or Classes must be able to inherit from their ancestors. Dynamic binding must be supported. The DML must be computationally complete.

OODBMS Manifesto The set of data types must be extensible. Data persistence must be provided. The DBMS must be capable of managing very large databases. The DBMS must support concurrent users. DBMS must be able to recover from hardware/software failures. DBMS must provide a simple way of querying data.

OODBMS Manifesto The manifesto proposes the following optional features: Multiple inheritance, type checking and type inferencing, distribution across a network, design transactions and versions. No direct mention of support for security, integrity, views or even a declarative query language.

Object Management Group (OMG) International non profit-making consortium founded in 1989 to address object standards. Several hundred member organizations including many platform and major software vendors. Primary aims of OMG are: Promotion of object-oriented approach. Development of standards in which location, environment, language, and other characteristics of objects are transparent.

Object Management Group (OMG) Not recognized standards group but aims to develop de facto standards. Defines standard object-based facilities for: Concurrent execution. Distributed transactions. Versioning. Event notification. Internationalization.

Object Management Architecture Four areas identified for reference model: Object Model (OM) - Design-portable abstract model for communicating with OMG-compliant object-oriented systems. Object Request Broker (ORB) - Handle distribution of messages between application objects in a highly interoperable manner. Like distributed ‘software bus’ enabling objects to make/receive requests/responses from a provider.

Object Management Architecture Object Services - Provide main functions for realizing basic object functionality. Many of these services are database-oriented. Common Facilities - Comprise a set of tasks that many applications must perform but are traditionally duplicated within each one.

Object Reference Model

Common Object Request Broker Architecture (CORBA) Defines architecture of ORB-based environments. Basis of any OMG component, defining parts that form ORB and associated structures. Some elements of CORBA are: Interface Definition Language (IDL). Type model. Interface Repository. Methods for getting interfaces/specifications of objects. Provides static and dynamic mechanism for clients to issue request to objects.

CORBA ORB Architecture

Object Data Management Group Established by vendors of OODBMSs to define standards. Have produced an Object Model that specifies a standard model for the semantics of database objects. Design of class libraries and applications using these semantics should be portable across various OODBMSs.

Object Data Management Group Major components of ODMG architecture for an OODBMS are: Object Model (OM). Object Definition Language (ODL). Object Query Language (OQL). C++, Smalltalk, and Java Language Binding.

Examples of Object Definition Language (ODL) module DreamHome Class Branch (extent branchOffices key branchNo) { attribute string branchNo; …. relationship Manager ManagedBy inverse Manager::Manages; void takeOnPropertyForRent(in string propertyNo) raises(propertyAlreadyForRent); }

Object Definition Language (ODL) class Person { attribute struct Pname {string fName, string lName} name; } Class Staff extends Person (extent staff key staffNo) { attribute staffNo; attribute date DOB; …. short getAge();

Object Query Language (OQL) Provides declarative access to object database using SQL-like syntax. Does not provide explicit update operators - leaves this to operations defined on object types. Can be used as a standalone language and as a language embedded in another language, for which an ODMG binding is defined (Smalltalk, C++, and Java). OQL can also invoke operations programmed in these languages.

Object Query Language (OQL) OQL can be used for both associative and navigational access: Associative query returns collection of objects. How these objects are located is responsibility of ODMS, rather than the application program. Navigational query accesses individual objects and object relationships used to navigate from one object to another. Responsibility of the application program to specify procedure for accessing the required objects.

Examples of OQL: Extents & Traversal Paths (1) Get set of all staff (with identity): staff (2) Get set of all branch managers (with identity): branchOffices.ManagedBy

OQL: Extents & Traversal Paths (3) Find all branches in London: SELECT b.branchNo FROM b IN branchOffices WHERE b.address.city = “London”; This returns a literal of type bag<string>. Can also say … FROM branchOffices b …

OQL: Extents & Traversal Paths (4) Assume londonBranches is named object (from last query). Find all staff who work at that branch: londonBranches.WorksAt This returns set<SalesStaff>.

OQL: Extents & Traversal Paths Because of ambiguity over return result, cannot access sales staff salaries using: londonBranches.WorksAt.salary Result may be set<float> or bag<float>. Instead use: SELECT [DISTINCT] s.salary FROM s IN londonBranches.WorksAt;

ORDBMSs Vendors of RDBMSs conscious of threat and promise of OODBMS. Agree that RDBMSs not currently suited to advanced database applications, and added functionality is required. Reject claim that extended RDBMSs will not provide sufficient functionality or will be too slow to cope adequately with new complexity. Can remedy shortcomings of relational model by extending model with OO features.

ORDBMSs - Features OO features being added include: user-extensible types, encapsulation, inheritance, polymorphism, dynamic binding of methods, complex objects including non-1NF objects, object identity.

ORDBMSs - Features However, no single extended relational model. All models: share basic relational tables and query language, all have some concept of ‘object’, some can store methods (or procedures or triggers).

ORDBMSs Original term used to describe such systems was Extended Relational DBMS (ERDBMS). Now use Object-Relational DBMS (ORDBMS), and sometimes Universal Server or Universal DBMS (UDBMS). Some analysts predict ORDBMS will have 50% larger share of market than RDBMS.

Stonebraker’s View

Advantages of ORDBMSs Resolves many of known weaknesses of RDBMS. Reuse and sharing: reuse comes from ability to extend server to perform standard functionality centrally; gives rise to increased productivity both for developer and end-user. Preserves significant body of knowledge and experience gone into developing relational applications.

Disadvantages of ORDBMSs Complexity. Increased costs. Proponents of relational approach believe simplicity and purity of relational model are lost. Some believe RDBMS is being extended for what will be a minority of applications. OO purists not attracted by extensions either. SQL now extremely complex.