COSC 266

ADVANCED DATABASE MANAGEMENT

SYSTEM

Instructor :Getaneh Tilahun

 Chapter 3

Object Relational and

Relational Database

CoSc 266 : Advanced Database management System

Instructor : Getaneh Tilahun
3.1 Evolution and Current Trends of Database
History of Database

file systems (1950s) • store data after process created it has ceased to
exist
hierarchical/ • concurrency
network (1960s) • recovery
• fast access
• complex structures
relational (1970- • more reliability
80s) • less redundancy
• more flexibility
• multiple views
ODBMS (1990s) • better simulation
• more (and complex) data types more
relationships (e.g. aggregation, specialization)
• single language for database AND programming
• better versioning
• no 'reconstruction' of objects
• other OO advantages (reuse, inheritance etc.)
Relational vs. Object Database
 Relational model (70’s):
 Clean and simple.
 Great for administrative and transactional data.
 Not as good for other kinds of complex data (e.g.,
multimedia, networks, CAD).
 Object-Oriented models (80’s):
 Complicated, but some influential ideas from Object
Oriented.
 Complex data types.
Current Trends of Database Technology
Current business application requires a Database
technology that can address the following points:
1. Meet the challenges of new applications:
 CAD, CAM, CASE, OA, and CAP
 Images

 Audio

 Streamed data

 BLOBs (binary large objects)

2. Programming languages have evolved from Procedural to

Object Oriented.
The Database system also need to incorporate object oriented
features.
Database Technology Debate
 There is debate in database community is that do we
need a new model or relational model is sufficient and
can be extended to support new applications.
 People in favor of relational model argue that
 New versions of SQL (e.g., SQL-92 and SQL3) are designed
to incorporate functionality required by new applications
(UDT, UDF, …)
 Embedded SQL can address almost all the requirements of
the new applications.
 Object people”, however, counter-argue that in the
above mentioned solutions,
 it is the application rather than the inherent capabilities of the
model that provides the required functionality.
 Object people say there is an impedance mismatch between
programming languages (handling one row of data at a time) and
SQL (multiple row handling) which makes conversions inefficient.
RELATIONAL MODEL OF A ‘CAT’
Relational database of a cat:
OBJECT ORIENTED MODEL OF A ‘CAT’
Object-oriented database of a cat:

Since it is an object, at
query time, you can
query the object easily
RELATIONAL MODEL
“Relational people say, instead of defining new models, let’s
introduce set-level functionality into programming languages

 Relations are the key concept, everything else is around

relations.
 In Relational Model, tuple and relations are very important
 Primitive data types, e.g., strings, integer, date, etc.
 Great normalization, query optimization, and theory

 What is missing? (i.e. limitation of RDBMS)

 Handling of complex objects – only handle atomic values
 Handling of complex data types
 Code is not coupled with data
 behaviors are not stored with data
 No inheritance, encapsulation, etc.
TWO APPROACHES
One way the other there are two possible ways to minimize the
problem of relational database:
 Object-Oriented Model (OODBMS)
 Pure OO concepts

 Object-oriented model tries to bring the main

concepts from relational model to the OO domain
 The heart is OO concepts with some extensions

 Object-Relational Model (ORDBMS)

 Extended relational model with OO concepts

 Object-relational model tries to bring the main

concepts from the OO domain to the relational
model
 The heart is the relational model with some
extensions
 Extensions through user-defined types
OBJECT-RELATIONAL DATABASES
 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.
 IT is an extended of relational database
(RDBMS)
OBJECT-RELATIONAL DATABASES
 Object-Relational databases (ORDBSs) seek to:
 Retain the relational model as a subset.
 Retain the strengths of the relational model
and all the technologies that come with it.
 Supports complex data types (BLOBS,
ADTs, Spatial, and Multimedia, …)
 Supports object-oriented design.
 Reduces impedance mismatch (type
system).
.
CONCEPTUAL VIEW OF OBJECT RELATIONAL
MODEL

 Relation is still the fundamental structure .

 Relational model extended with the following features .
 Type system with primitive and structure types (UDT)
 Including set, bag, array, list collection types .
 Including structures like records.
 Methods
 Special operations can be defined over the user-defined types
(UDT).
 Specialized operators for complex types, e.g., images, multimedia,
etc.
 Identifiers for tuples
 Unique identifiers even for identical tuples
 References
 Several ways for references and de-references
OBJECT-RELATIONAL DATABASES
 Advantages of ORDBMS
 Resolves many of known weaknesses of RDBMS.
 Preserves significant body of knowledge and
experience gone into developing relational
applications
 SUPPORT FROM VENDORS
 Several major software companies including IBM,
Informix, Microsoft, Oracle, and Sybase have all
released object-relational versions of their products
RELATIONAL DATA MODELS
 Extend the relational data model by including object
orientation and constructs to deal with added data
types.
 Allow attributes of tuples to have complex types,
including non-atomic values such as nested relations.
 Preserve relational foundations, in particular the
declarative access to data, while extending modeling
power.
 Upward compatibility with existing relational
languages.
3.2 IMPLEMENTATION AND RELATED ISSUE
OF ORDSMS
 Extended SQL standards called SQL-99 or SQL3
 It needs to Add the following features
 User-defined Type(UDTs)
 Nested Relations
 Complex Types
 Inheritance
 Behavior
POWERFUL TYPE SYSTEM
Standard SQL support only
 Primitive types
 Integer, string, date, Boolean, float, etc.
However, ORDBMS should support complex objects and a
complex type attributes.
 Structure type
 Attribute can be a record with a schema
 Collection type
 Attribute can be a Set, Bag, List, Array of other types
 Reference type
 Attribute can be a Pointer to another object
 IMPLEMENTATION AND RELATED ISSUE OF
ORDSMS
SQL-99: query language for object relational model
 User-defied types (UDT) replace the concept of
classes
 Create relations on top of the UDTs
 Multiple relations can be created on top of the
same UDT

Create Type <name> AS (attributes and method declarations)

CREATING UDT USING SQL-99/SQL3

create type AddressType

• as (
Creating a type for the
Street varchar(20), address of the star
City varchar(20));

create type starType as ( Hierarchy of type

name varchar(20), (Inheritance )
address AddressType))
Adding a Method
declaration for a type(not
create type Addresstype as ( definition)
Street varchar(20), ( Encapsulation)
City varchar(20))
Mehtod HousNumber () return int Mehtod HousNumber () return int
For AddressType
Begin
……
End
COLLECTIONS AND LARGE OBJECTS USING SQL-
99/SQL3
Book Type contains collections
 Arrays of authors -> capture the order of authors.
 Set of keywords
 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-list set(varchar(20))
):
Note: set declaration of keyword-set is not supported by SQL:1999 :
COLLECTIONS AND LARGE OBJECTS USING SQL-
99/SQL3
Large object types
CLOB: Character large objects
book-review CLOB(10KB)
BLOB: binary large objects
image BLOB(10MB)
movie BLOB(2GB)

Usually provide method inside UDT to manipulate CLOB and BLOB

CREATING RELATION
 Once types are created, we can create relations
 In general, we can create tables without types
 But types provide encapsulation, inheritance, etc.

Create Table TabelName OF TypeName;

 Structured types can be used to create tables

For Example
 create table books OF Book
 Create table Star OF StarType.
CREATING TABLES
 We can create tables without creating an intermediate type
 For example,
create table books (
title varchar(20),
author-array varchar(20) array[10],
pub-date date,
publisher Publisher
keyword-list setof(varchar(20)));

 Methods can be part of the type definition of a structured type:

create type Employee as (
name varchar(20),
salary integer)
method giveraise ( percent integer) ;
 We create the method body separately as follows

create method giveraise ( percent integer) for Employee

begin
set self. salary = self.salary + (self. salary * percent )
End
CREATING INHERITANCE
 RDBMS model is a flat model that has only foreign key
relationship, it doesn’t support other type of
relationship.
ORDBMS extends an RDBMS by providing explicit
support for inheritance
 Suppose that we have the following type definition for
people:
create type Person as (
name varchar(20),
address varchar(20)
);
CREATING INHERITANCE
 Using inheritance to define the student and teacher
types
create type Student
( degree varchar(20),
department varchar(20))
under Person;
create type Teacher
( salary integer,
department varchar(20))
under Person ;
 Subtypes can redefine methods by using overriding method
in place of method in the method declaration
TABLE INHERITANCE
Table inheritance allows an object to have multiple types by
allowing an entity to exist in more than one table at once.
E.g. people table:
create table people of Person
We can then define the students and teachers tables as sub
tables of people
create table students of Student
under people
create table teachers of Teacher
under people
Each tuple in a subtable (e.g. students and teachers) is
implicitly present in its supertables (e.g. people)
CREATING RELATION
 A single primary key can be defined using Primary
Key keyword
 To reference another relation R, R has to be reference
able using REF keyword

create type MoveType as (

title varchar(20),
year Integer
Tupel can be referenced using attribute
inColour boolean)
; movieID (system generated

Create Tabel Move OF MoveType (

Ref IS moviID System Generated
PRIMARY KEY (title, year )
);
CREATING RELATION
 A single primary key can be defined using Primary
Key keyword
 To reference another relation R, R has to be reference
able using REF keyword

create type StarType as (

Name varchar(20),
Address AddressType Tupel can be referenced using attribute
); starID (system generated

Create Tabel MoveStar OF StarType (

Ref IS starID System Generated
);
DEFINING RELATIONSHIPS
 One-to-many or One-to-one
 Plug it inside the existing type

create type StarType as (

Name varchar(20),
Address AddressType
bestMovie REF(MovieType) SCOPE Movie
);

 For each star, keep the best movie (one-to-many)

DEFINING RELATIONSHIPS
 Many-to-many
 Creating a new type or new table referencing existing type

Create Tabel StarsIN (

Star REF(StarType) SCOPE MoveStar,
Movie REF(MoveType) SCOPE move
);

 Table for each star participated in which movies (many-to-many)

QUERYING OBJECT-RELATIONAL DATABASE

 Most relational operators work on the

object relational tables
 E.g., selection, projection, aggregation, set
operations
 Some new operators and new syntax for
some existing operators
SQL-99 (SQL3): Extended SQL to operate
on object relational databases
QUERYING OBJECT-RELATIONAL DATABASE
Example
 Find all books which have the word “database” as one
of their keywords.
select name from books
where “database” IN (keyword-list)

 Find all authors (if many) when the title is

“’Database”
select author array[1], author array[2],
author array[3]
from books
where title = ’Database”;
QUERYING OBJECT-RELATIONAL DATABASE

Example
 Find all keywords form books.
select k.keyword-list
From THE( select Keyword-list FROM books) AS K
ORDER BY k.keywords-list
End of Chapter Three
Thank You!