1. Object Relational and Extended Relational Databases
Software Engineering MSc. Student : Suhad Jihad
14/5/2015

3. Introduction
DBMS EVOLUTION

4. Introduction
What Object-Relational Database Management System (ORDBMS) ?
  Is a database management system that is similar to a
relational database, except that it has an object-oriented
database model. This system supports objects, classes and
inheritance in database schemas and query language.

5. Agenda Database design for an ORDBMS.
Nested relations and collections.
Storage and access methods.
Query processing and Optimization.
An overview of SQL3.
Implementation issues for extended type.
Systems comparison of RDBMS,OODBMS, ORDBMS.

6. Overview

7. Overview Why ORDBMS? obstacle facing traditional database such as :
1- Limited type system supported.
2 - The difficulty in accessing
database data from programs
written in programming
languages such as C++ or Java.
3- Differences between the type
system of the database
and the type system of the
programming language make
data storage and retrieval more
complicated, and need to be
minimized.

8. Overview

9. Database design for an ORDBMS Complex Data Types
Normalization of Database (Normalization Form NF) :
Database normalization is a technique of organizing the data in the database.
The Non-1NF Example:

10. Database design for an ORDBMS Complex Data Types
There are many normalization form like 1NF :
which requires that all attributes
have atomic domains.

11. Database design for an ORDBMS Complex Data Types
But if we define a relation for following example, several domains will be non atomic.
The result in the next slide
makes many types of queries easier

12. Database design for an ORDBMS Complex Data Types
title of a book uniquely identifies the book
requires queries to join multiple relations
4NF version of the relation books

13. Database design for an ORDBMS Complex Data Types
For another situation may be better to use first normal form.
If for example a relationship is many-to-many between student and section ,store a set of sections with each student, or a set of students with each section, or both
In both we would have data redundancy.
The ability to use complex data types such as sets and arrays can be
useful in many applications but should be used with care. 13

14. Database design for an ORDBMS Structured Types
Represent composite attributes of E-R designs.
This is called user-defined types
Ex:
create type Name as
(firstname varchar(20),
lastname varchar(20))
final;
*Final and not Final keywords we will them in inheritance topic.

15. Database design for an ORDBMS Structured Types
Ex: create type Address as (street varchar(20), city varchar(20), zipcode varchar(9)) not final;

16. Database design for an ORDBMS Structured Types
Create composite attributes in a relation:
create table person (
name Name,
address Address,
dateOfBirth date);
To access components of a composite attribute we use dot:
name.firstname

17. Database design for an ORDBMS Structured Types
Create a table whose rows are of a user-defined type
Example:
First we create user defined type as:
create type PersonType as (
name Name,
address Address,
dateOfBirth date)
not final

18. Database design for an ORDBMS Structured Types
Second create a table create table person of PersonType; Alternative way of defining composite attributes in SQL is to use unnamed row types The example in the next slide :

19. Database design for an ORDBMS Structured Types
create table person r (
name row (firstname varchar(20),
lastname varchar(20)),
address row (street varchar(20),
city varchar(20),
zipcode varchar(9)),
dateOfBirth date);
Attributes name and address have unnamed types, and the rows of the table also have an unnamed type.

20. Database design for an ORDBMS Structured Types-Query
How to access component attributes of a composite attribute.
select name.lastname, address.city
from person;

21. Database design for an ORDBMS Structured Types-Methods
Declare methods as part of the type definition of a structured type:
create type PersonType as (
name Name,
address Address,
dateOfBirth date)
not final
method ageOnDate(onDate date)
returns interval year;

22. Database design for an ORDBMS Structured Types-Methods
We create the method body separately:
create instance method ageOnDate (onDate date)
returns interval year
for PersonType
begin
return onDate − self.dateOfBirth;
end
Note that the for clause indicates which type this method is for, while the
keyword instance indicates that this method executes on an instance of the
Person type. The variable self refers to the Person instance on which the
method is invoked.

23. Database design for an ORDBMS Structured Types-Methods
Methods can be invoked on instances of a type. If we had created a table person of type PersonType, we could invoke the method ageOnDate() as illustrated below, to find the age of each person.
select name.lastname, ageOnDate(current date)
from person;

24. Database design for an ORDBMS SQL3 (SQL1999) constructor functions.
Constructor functions are used to create values of structured types. A function with the same name as a structured type is a constructor function for the structured type. For instance, we could declare a constructor for the type Name like this:
create function Name (firstname varchar(20), lastname varchar(20))
returns Name
begin
set self.firstname = firstname;
set self.lastname = lastname;
end

25. Database design for an ORDBMS SQL3 (SQL1999) constructor functions.
Use the following statement to create value for type name.
Name(’John’, ’Smith’)
Ex : Create a new tuple in the Person relation.
insert into Person
values
(new Name(’John’, ’Smith’),
new Address(’20 Main St’, ’New York’, ’11001’),
date ’ ’);
By default every structured type has a constructor with no arguments, which sets the attributes to their default values and there can be more than one constructor for the same structured type; although they have the same name, they must be distinguishable by the number of arguments and types of their arguments.

26. (name varchar(20), SuperType of Teacher & Student
Database design for an ORDBMS Type Inheritance (Attributes Inheritance)
Inheritance used when we want to store extra information in the database about an object ex:
Suppose we have an object Person:
create type Person
(name varchar(20), SuperType of Teacher & Student
address varchar(20));
And we have students and teachers are also Person, we can use inheritance to define the student and teacher types in SQL:
create type Student create type Teacher
under Person under Person
( degree varchar(20), (salary integer,
department varchar(20)); department varchar(20));
SubType of Person SubType of Person

27. Database design for an ORDBMS Type Inheritance
Method of a structured type are inherited by its
subtypes, just as attributes are.
Final not not final: SQL standard use these extra fields at the end of type definition.
Final says that subtypes may not be created from the given type.
Not final says that subtypes may be created.

28. Database design for an ORDBMS Multiple Inheritance
multiple inheritance : type is declared as a subtype of multiple types ex:
Suppose we have aTeachingAssistant which is a student and teacher at the same time therefore it inherits all the attributes of Student and Teacher.
create type TeachingAssistant
under Student, Teacher;
Note that the SQL standard does not support multiple inheritance, although future versions of the SQL standard may support it.

29. Database design for an ORDBMS Multiple Inheritance
No conflict :The attributes name and address are actually inherited from a common source Person.
Conflict :The attribute department is defined separately in Student and Teacher. A teaching assistant may be a student of one department and a teacher in another department.
Avoid a conflict :Using an as clause, as in this definition of
the type TeachingAssistant:
create type TeachingAssistant
under Student with (department as student dept),
Teacher with (department as teacher dept);

30. Database design for an ORDBMS Inheritance-most-specific type
Most-specific type : each value must be associated with one specific type, called its most-specific type.
Suppose that an entity has the type Person, as well as the type Student. Then, the most-specific type of the entity is Student, since Student is a subtype of Person.
An entity cannot have the type Student as well as the type Teacher unless it has a type, such as TeachingAssistant, that is a subtype of Teacher, as well as of Student (which is not possible in SQL since multiple inheritance is not supported by SQL).

31. Database design for an ORDBMS Inheritance-Table Inheritance
Create Table as:
create table people of Person;
Define tables students and teachers as subtables of people, as follows :
create table students of Student
under people;
create table teachers of Teacher
When we declare students and teachers as subtables of people, every
tuple present in students or teachers becomes implicitly present in people.

32. Database design for an ORDBMS Inheritance-Table Inheritance
If a query uses the table people, it will find not only tuples directly inserted into that table, but also tuples inserted into its subtables, namely students and teachers.
How SQL prevent this
By only keyword :SQL permits us to find tuples that are in people but not in its subtables by using “only people”
The only keyword can also be used in delete and update statements.
delete from only people where P;

33. Database design for an ORDBMS Inheritance-Table Inheritance
Cont. Tuples that were inserted in subtables are not affected, even if they satisfy the where clause conditions. But without only the statement delete all tuples from the table people, as well as its subtables students and teachers, that satisfy P.

34. Database design for an ORDBMS Consistency Requirements for Subtables
There are two constraint with subtable but before we explain them we must know what is correspond ?
Correspond
We say that tuples in a subtable and parent table correspond if they have the same values for all inherited attributes. Thus, corresponding tuples represent the same entity.

35. Database design for an ORDBMS Consistency Requirements for Subtables
The consistency requirements for subtables are:
1. Each tuple of the supertable can correspond to at most
one tuple in each of its immediate subtables.
2. SQL has an additional constraint that all the tuples
corresponding to each other must be derived from one
tuple (inserted into one table).

36. Database design for an ORDBMS Consistency Requirements for Subtables
Without the first condition, we could have two tuples in
students (or teachers) that correspond to the same person.
Since SQL does not support multiple inheritance, the second
condition actually prevents a person from being both a teacher and a student.
Since SQL does not support multiple inheritance, the second condition actually prevents a person from being both a teacher and a student.

37. Database design for an ORDBMS Consistency Requirements for Subtables
It would be useful to model a situation where
a person can be a teacher and a student, even if a
common subtable teaching assistants is not present.
But how SQL do this
If we have table person, with subtables teachers and students. We can then have a tuple in teachers and a tuple in students corresponding to the same tuple in people. There is no need to have a type TeachingAssistant that is a subtype of both Student and Teacher.

38. Database design for an ORDBMS Consistency Requirements for Subtables
Cont. SQL does not support multiple inheritance, we cannot use inheritance to model a situation where a person can be both a student and a teacher. a student and a teacher. As a result, SQL subtables cannot be used to represent overlapping specializations from the E-R model. We can of course create separate tables to represent the overlapping specializations/generalizations without using inheritance .

39. Database design for an ORDBMS Consistency Requirements for Subtables
We would create tables person, students , and teachers , with the students and teachers tables containing the primary-key attribute of Person and other attributes specific to Student and Teacher, respectively.
person (ID, name, street, city)
teacher(ID, salary,dep.)
student (ID, degree,dep.)

40. Database design for an ORDBMS Array and Multiset Types in SQL
Array : added to SQL 1999 it is a single-dimensional array of ordered elements of the same type.
Multiset : added to SQL 2003 it is an unordered collection, where an element may occur multiple times.
create type Publisher as
(name varchar(20),
branch varchar(20));
create type Book as
(title varchar(20),
author array varchar(20) array [10],
pub date date,
publisher Publisher,
keyword set varchar(20) multiset);
create table books of Book;
SQL EX.

41. Database design for an ORDBMS Creating and Accessing Collection Values
Create an Array :-
array[’Silberschatz’, ’Korth’, ’Sudarshan’]
Create a Multiset :-
multiset[’computer’, ’database’, ’SQL’]
create a Tuple of the type defined by the books relation as:
(’Compilers’, array[’Smith’, ’Jones’], new Publisher(’McGraw-Hill’, ’New York’),
multiset[’parsing’, ’analysis’])
constructor
Function for
Publisher

42. Database design for an ORDBMS Creating and Accessing Collection Values
Insert the tuple into the relation books:
insert into books
values (’Compilers’, array[’Smith’, ’Jones’],
new Publisher(’McGraw-Hill’, ’New York’),
multiset[’parsing’, ’analysis’]);
We can access or update elements of an array by specifying the array index, for example author array[1].

43. Database design for an ORDBMS Querying Collection-Valued Attributes
How to query?
Ex : Find all books that have the word “database”?
select title
from books
where ’database’ in (unnest(keyword set));
Arrays can be converted into table references with the UNNEST keyword.

44. Database design for an ORDBMS Querying Collection-Valued Attributes
Select authors (if many) when the title is :-
select author array[1], author array[2], author array[3]
from books
where title = ’Database System Concepts’;
Query a relation containing pairs of the form “title, author name” for each book and each author of the book.
select B.title, A.author
from books as B, unnest(B.author array) as A(author);
Translate the authors to array A

45. Database design for an ORDBMS Querying Collection-Valued Attributes
SQL AS temporarily assigns a table column a new name.
Query the author with order:
select title, A.author, A.position
from books as B,
unnest(B.author array) with ordinality as A(author, position);
Ordinality clause generates an extra attribute which records the position of the element in the array.
Translate the author with their position to A

46. Database design for an ORDBMS Nesting and Unnesting
Unnesting : transformation of a nested relation into a form with fewer (or no) relation valued attributes.
Convert the following book relation into a single flat relation?
relation book
The answer in the next slide :
collection

47. Database design for an ORDBMS Nesting and Unnesting
By using this query
select title, A.author, publisher.name as pub name, publisher.branch
as pub branch, K.keyword
from books as B, unnest(B.author array) as A(author),
unnest (B.keyword set) as K(keyword);
We get this table
flat books: result of unnesting attributes author array and keyword set of relation
books
relation flat
books is in 1NF, since all its attributes are atomic valued.

48. Database design for an ORDBMS Nesting and Unnesting
Nesting :The reverse process of transforming a 1NF relation into a nested relation.
Done by an extension of grouping in SQL.
Suppose we have the 1NF relation flat books table in
the previous slide by the following Query we get the
nested relation by attribute keyword:
select title, author, Publisher(pub name, pub branch) as publisher,
collect(keyword) as keyword set
from flat books
group by title, author, publisher;
Collect returns the
multiset of values,

49. Database design for an ORDBMS Nesting and Unnesting
Can we make a nest by another way
Yes, by using subqueries in the select clause ex:
select title,
array( select author
from authors as A
where A.title = B.title
order by A.position) as author array,
Publisher(pub name, pub branch) as publisher,
multiset( select keyword
from keywords as K
where K.title = B.title) as keyword set,
from books4 as B;
advantage of the subquery approach is that an order by clause can be
used in the subquery

50. Database design for an ORDBMS Nesting and Unnesting
Operators that SQL 2003 provide on multiset:-
Set(M) function :- That returns a duplicate-free version of a multiset M.
Intersection :-Aggregate operation , which returns the intersection of all the multisets in a group.
Fusion :-Aggregate operation, which returns the union of all multisets in a group.
Submultiset :-Predicate, which checks if a multiset is contained in another multiset.

51. Database design for an ORDBMS Nesting and Unnesting
The SQL standard does not provide any way to update multiset attributes except by assigning a new value. For To delete a value v from a multiset attribute A, we would have to set it to (A except all multiset[v]).

52. Advantage Reuse Code that come from the ability to extend the DBMS.
Was created to handle new data type such as audio, video and image files that relation database not equipped.
Allow organization to continue using their existing system , without having to make major changes.

53. Application Commercial shipping information system
Traffic management and route planning.
Safety – Security .
Life Science
Diagnostic.
Drug Discovery.
Gene Expression and therapy.
etc……

54. Systems comparison of RDBMS, OODBMS, ORDBMS.
Defining Standard
RDBMS
OODBMS
ORDBMS
SQL2
ODMG-v2.0
SQL-3
PostgresSQL

55. Systems comparison of RDBMS, OODBMS, ORDBMS.
Storage
RDBMS
OODBMS
ORDBMS
store only data.
store data and methods.

56. Systems comparison of RDBMS, OODBMS, ORDBMS.
Simplicity of use:
RDBMS
OODBMS
ORDBMS
Table structures easy to understand; many end-user tools available
Ok for programmers; some SQL access for end users
Same as RDBMS, with some confusing extensions

57. Systems comparison of RDBMS, OODBMS, ORDBMS.
Support for integrity
Support for navigation
RDBMS
OODBMS
ORDBMS
Not enough for integrity and business
No support also
Strongly support
RDBMS
OODBMS
ORDBMS
Poor support
Strong support
Support by REF

58. Glossary
Ad hoc is latin for "for this purpose". You might call it an "on the fly" query, or a "just so" query. It's the kind of SQL query you just loosely type out where you need it
var newSqlQuery = "SELECT * FROM table WHERE id = " + myId;
...which is an entirely different query each time that line of code is executed, depending on the value of myId.
Transaction :  a single logical operation on the data is called a transaction. For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction.

59. Summary
When to use RDBMS ?In simple, flexible, and productive Application . Because the tables are simple, data is easier to understand and communicate with others. RDBMS are flexible because users do not have to use predefined keys to input information.
When to use an ODBMS? ƒIn applications that generally retrieve relatively few (generally physically large) highly complex objects and work on them for long periods of time.
When to use an ORDBMS? ƒIn applications that process a large number of short lived (generally ad-hoc query) transactions on data items that can be complex in structure.

60. More Information
Database System Concepts 6e By Abraham Silberschatz, Henry Korth and S Sudarshan
content/uploads/2014/11/P pdf