Transactions and Recovery object-relational database (ORD) An object-relational database (ORD), or object-relational database management system (ORDBMS), is a database management system (DBMS) similar to a relational database, but with an object-oriented database model: objects, classes and inheritance are directly supported in database schemas and in the query language. In addition, it supports extension of the data model with custom data-types and methods.database management systemrelational databaseobject-orienteddatabase schemasquery languagedata modeldata-typesmethods
Transactions and Recovery object-relational database (ORD) Definition - What does Object-Relational Database (ORD) mean? An object-relational database (ORD) is a database management system (DBMS) that's composed of both a relational database (RDBMS) and an object-oriented database (OODBMS). ORD supports the basic components of any object- oriented database model in its schemas and the query language used, such as objects, classes and inheritance. An object-relational database may also be known as an object relational database management systems (ORDBMS).
object-relational database (ORD) An object-relational database can be said to provide a middle ground between relational databases and object-oriented databases (OODBMS). In object- relational databases, the approach is essentially that of relational databases: the data resides in the database and is manipulated collectively with queries in a query language; at the other extreme are OODBMSes in which the database is essentially a persistent object store for software written in an object- oriented programming language, with a programming API for storing and retrieving objects, and little or no specific support for queryingOODBMSobject- oriented programming languageAPI
Example CREATE TABLE Customers ( Id Cust_Id NOT NULL PRIMARY KEY, Name PersonName NOT NULL, DOB DATE NOT NULL ); SELECT Formal( C.Id ) FROM Customers C WHERE BirthDay ( C.DOB ) = TODAY;
To extend an existing relational data base management system: keep the basic relational tables & query language add object flavours: user - extensible type system encapsulation inheritance polymorphism dynamic binding of methods complex objects (non-first normal form objects) object identity Obvious & common idea:
Terminology: Extended Relational DBMS ( ERDBMS ) -- original term Object - Relational DBMS ( ORDBMS ) -- more descriptive Universal Server, Universal DBMS ( UDBMS )-- recently Oracle Informixhave all extended their systems to become ORDBMSs IBM SQL3 standardize extensions to the relational model and query language
Advantages: resolves many of the weaknesses of the relational model extends RDBMS with reuse and sharing comes from the ability to extend the database server to perform standard functionality centrally, rather than having it coded in each application preserves the knowledge and experience from relational model Disadvantages: complexity and associated increased costs simplicity and purity of the relational model are lost object-orinted purists: the used terminology is wrong
B. Inheritance Inheritance can be at the level of types or at the level of tables 1. Inheritance of types create type Person (name MyString, social_security_no integer ) create type Student (degree MyString, department MyString) under Person create type Teacher (salary integer, department MyString) under Person
Since name and social_security_no are inherited from a common source, Person, there is no conflict by inheriting them. However, department is defined separately in Student and Teacher and one can rename them to avoid conflict, by using an as clause: 1’. Multiple inheritance of types Definiton of the type TeachingAssistant as a subtype of both Teacher andStudent. create type TeachingAssistant under Student with (department as student_dept), under Teacher with (department as teacher_dept)
2. Inheritance of tables To avoid creation of too many subtypes: one approach is to allow an object to have multiple types without having a most specific type OR databases can model such a feature by using inheritance at the level of tables, rather than types and allowing an entity(object) to exist in more than one table at once. create table people (name MyString, social_security_no integer ) create table students (degree MyString, department MyString) under people create table teachers (salary integer, department MyString) under people
2’. Table inheritance: Roles Table inheritance permits an object to have multiple types, without having a most-specific type (unlike type inheritance) Example : an object can be in the students and teachers subtables simultaneously, without having to be in a subtable student_teachers that is under both students and teachers Object can gain/ lose roles: corresponds to inserting /deleting object from a subtable. 2’’. Table inheritance: Consistency Requirements 1. Each tuple of supertable people can correspond to (i.e. having the same values for all inherited attributes as) at most one tuple in each of the tables studentsand teachers (WHY?) 2. Each tuple in students and teachers must have exactly one corresponding tuple in people. (WHY?)
Subtables can be stored in an efficient manner without replication of all inherited fields: inherited attributes other than the primary key of the supertable need not be stored and can be derived by means of a join with the supertable, based on the primary key As with types, multiple inheritance is possible with tables: a TeachingAssistant can simply belong to the table students as well as to the table teachers. However, if ew want, we can create a table for TeachingAssistant entities. Based on the consistency requirements for subtables, if an entity is present in the teaching_assistants table, it is also present in the teachers and in the students table.
3. Inheritance: Conclusion Inheritance: makes schema definition natural ensures referential and cardinality constraints enables the use of functions defined for supertypes on objects belonging to subtypes allows the orderly extension of a database system to incorporate new types
C. Reference Types Object - oriented languages provide the ability to create and refer to objects. 1.To refer to objects = an attribute of a type can be a reference to an object of a specified type. Example : redefine the author_list field of the type Document as: author_list setof ( ref (Person)) Now author_list is a set of references to Person objects 2. Tuples of a table can also have references to them. Example: ref (people) It can be implemented using the primary key or tuple-id. 3. SQL3 uses identity (for tuples) and oid (for objects).