Transcript Objects - METU Computer Engineering

Object-Oriented Databases
1
Outline
•
•
•
•
Advanced database applications
Shortcomings of Relational DBs
Object-oriented concepts
Object Relational Systems (ORDBMSs)
– SQL:1999 object extensions
• Object-oriented database Systems (OODBMSs)
– ODMG Data Model
– ODL – data definition language
– OQL – query language
2
Advanced Database Applications
•
•
•
•
•
•
•
•
Computer-Aided Design/Manufacturing (CAD/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.
3
Expected features for new
applications
•
•
•
•
Complex objects
Behavioral data
Meta knowledge
Long duration transactions
4
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
5
Weaknesses of RDBMSs
• Limited operations
– only a fixed set of operations which cannot be
extended.
• Difficulty handling recursive queries
• Impedance mismatch
– Most DMLs lack computational completeness.
– To overcome this, SQL can be embedded in a highlevel language.
– 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.
6
Object-Oriented Concepts
•
•
•
•
•
•
•
Abstraction, encapsulation, information hiding.
Objects and attributes.
Object identity.
Methods and messages.
Classes, subclasses, superclasses, and inheritance.
Overloading.
Polymorphism and dynamic binding.
7
Complex Objects
An object that consists of sub-objects but is viewed
as a single object.
• Objects participate in a A-PART-OF relationship.
• Contained object can be encapsulated within
complex object, accessed by complex object’s
methods.
• Or have its own independent existence, and only an
OID is stored in complex object.
8
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.
9
History of Data Models
10
Origins of the Object-Oriented Data Model
11
ORDBMS
12
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.
13
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.
14
Stonebraker’s View
15
Objects in SQL:1999
•
•
•
•
Object-relational extension of SQL-92
Includes the legacy relational model
SQL:1999 database = a finite set of relations
relation = a set of tuples (extends legacy relations)
OR
•
•
•
a set of objects (completely new)
object = (oid, tuple-value)
tuple = tuple-value
tuple-value = [Attr1: v1, …, Attrn: vn]
16
SQL:1999 Tuple Values
• Tuple value: [Attr1: v1, …, Attrn: vn]
– Attri are all distinct attributes
– Each vi is one of these:
• Primitive value: a constant of type CHAR(…),
INTEGER, FLOAT, etc.
• Reference value: an object Id
• Another tuple value
• A collection value
Only the ARRAY construct is – a fixed size array.
SETOF and LISTOF are not supported.
17
Row Types
• The same as the original (legacy) relational tuple type.
However:
– Row types can now be the types of the individual attributes in
a tuple
CREATE TABLE
PERSON (
Name CHAR(20),
Address ROW(Number INTEGER, Street CHAR(20), ZIP CHAR(5))
)
18
Row Types (Contd.)
• Use path expressions to refer to the components of row types:
SELECT P.Name
FROM PERSON P
WHERE P.Address.ZIP = ‘11794’
• Update operations:
INSERT INTO PERSON(Name, Address)
VALUES (‘John Doe’, ROW(666, ‘Hollow Rd.’, ‘66666’))
UPDATE PERSON
SET Address.ZIP = ‘66666’
WHERE Address.ZIP = ‘55555’
UPDATE PERSON
SET Address = ROW(21, ‘Main St’, ‘12345’)
WHERE Address = ROW(123, ‘Maple Dr.’, ‘54321’) AND Name = ‘J. Public’
19
User Defined Types (UDT)
• UDTs allow specification of complex objects/tuples,
methods, and their implementation
• Like ROW types, UDTs can be types of individual
attributes in tuples
• UDTs can be much more complex than ROW types
(even disregarding the methods): the components of
UDTs do not need to be elementary types
20
A UDT Example
CREATE TYPE PersonType AS (
Name CHAR(20),
Address ROW(Number INTEGER, Street CHAR(20), ZIP CHAR(5))
);
CREATE TYPE StudentType UNDER PersonType AS (
Id INTEGER,
Status CHAR(2)
)
METHOD award_degree() RETURNS BOOLEAN;
CREATE METHOD award_degree() FOR StudentType
LANGUAGE C
EXTERNAL NAME ‘file:/home/admin/award_degree’;
File that holds the binary code
21
Using UDTs in CREATE TABLE
• As an attribute type:
CREATE TABLE TRANSCRIPT (
Student StudentType,
CrsCode CHAR(6),
Semester CHAR(6),
Grade CHAR(1)
)
A previously defined UDT
• As a table type:
CREATE TABLE STUDENT OF StudentType;
Such a table is called typed table.
22
Objects
• Only typed tables contain objects (ie, tuples with oids)
• Compare:
CREATE TABLE STUDENT OF StudentType;
and
CREATE TABLE STUDENT1 (
Name CHAR(20),
Address ROW(Number INTEGER, Street CHAR(20), ZIP CHAR(5)),
Id
INTEGER,
Status CHAR(2)
)
• Both contain tuples of exactly the same structure
• Only the tuples in STUDENT – not STUDENT1 – have oids.
• This disparity is motivated by the need to stay backward
compatible with SQL-92.
23
Querying UDTs
• Nothing special – just use path expressions
SELECT T.Student.Name, T.Grade
FROM
TRANSCRIPT T
WHERE T.Student.Address.Street = ‘Main St.’
Note: T.Student has the type StudentType. The attribute Name is
not declared explicitly in StudentType, but is inherited from
PersonType.
24
Updating User-Defined Types
• Inserting a record into TRANSCRIPT:
INSERT INTO TRANSCRIPT(Student,Course,Semester,Grade)
VALUES (????, ‘CS308’, ‘2000’, ‘A’)
–
The type of the Student attribute is StudentType. How
does one insert a value of this type (in place of ????)?
– Further complication: the UDT StudentType is
encapsulated, ie, it is accessible only through public
methods, which we did not define
–
Do it through the observer and mutator methods
provided by the DBMS automatically
25
Observer Methods
• For each attribute A of type T in a UDT, an SQL:1999 DBMS is supposed to
supply an observer method, A: ( )  T, which returns the value of A (the notation
“( )” means that the method takes no arguments)
• Observer methods for StudentType:
• Id: ( )  INTEGER
• Name: ( )  CHAR(20)
• Status: ( )  CHAR(2)
• Address: ( )  ROW(INTEGER, CHAR(20), CHAR(5))
• For example, in
SELECT T.Student.Name, T.Grade
FROM
TRANSCRIPT T
WHERE T.Student.Address.Street = ‘Main St.’
Name and Address are observer methods, since T.Student is of type StudentType
Note: Grade is not an observer, because TRANSCRIPT is not part of a UDT
26
Mutator Methods
• An SQL:1999 DBMS is supposed to supply, for each attribute A
of type T in a UDT U, a mutator method
A: T  U
For any object o of type U, it takes a value t of type T
and replaces the old value of o.A with t; it returns the
new value of the object. Thus, o.A(t) is an object of type U
• Mutators for StudentType:
• Id: INTEGER  StudentType
• Name: CHAR(20)  StudentType
• Address: ROW(INTEGER, CHAR(20), CHAR(5))  StudentType
27
Example: Inserting a UDT Value
INSERT INTO TRANSCRIPT(Student,Course,Semester,Grade)
VALUES (
NEW StudentType( ) .Id(111111111) .Status(‘G5’) .Name(‘Joe Public’)
.Address(ROW(123,’Main St.’, ‘54321’)) ,
‘CS532’,
‘S2002’,
‘A’
)
Add a value
for Id
Create a blank
StudentType object
Add a value for the
Address attribute
Add a value
for Status
‘CS532’, ‘S2002’, ‘A’ are primitive values for the attributes Course, Semester, Grade
28
Example: Changing a UDT Value
UPDATE TRANSCRIPT
SET Student = Student.Address(ROW(21,’Maple St.’,’12345’)).Name(‘John Smith’),
Grade = ‘B’
Change Name
Change Address
WHERE Student.Id = 111111111 AND CrsCode = ‘CS532’ AND Semester = ‘S2002’
• Mutators are used to change the values of the attributes Address
and Name
29
Referencing Objects
• Consider again
CREATE TABLE TRANSCRIPT (
Student StudentType,
CrsCode CHAR(6),
Semester CHAR(6),
Grade CHAR(1)
)
• Problem: TRANSCRIPT records for the same student refer to distinct
values of type StudentType (even though the contents of these
values may be the same) – a maintenance/consistency problem
• Solution: use self-referencing column
– Bad design, which distinguishes objects from their references
– Not truly object-oriented
30
Self-Referencing Column
• Every typed table has a self-referencing column
– Normally invisible
– Contains explicit object Id for each tuple in the table
– Can be given an explicit name – the only way to enable
referencing of objects
CREATE TABLE STUDENT2 OF StudentType
REF IS stud_oid;
Self-referencing column
Self-referencing columns can be used in queries just like regular columns
Their values cannot be changed, however
31
Reference Types and Self-Referencing Columns
• To reference objects, use self-referencing columns + reference
types: REF(some-UDT)
CREATE TABLE TRANSCRIPT1 (
Student REF(StudentType) SCOPE STUDENT2,
CrsCode CHAR(6),
Semester CHAR(6),
Grade CHAR(1)
)
Reference type
Typed table where the
values are drawn from
• Two issues:
• How does one query the attributes of a reference type
• How does one provide values for the attributes of type REF(…)
– Remember: you can’t manufacture these values out of thin air – they are oids!
32
Querying Reference Types
• Recall:
Student REF(StudentType) SCOPE STUDENT2
in
TRANSCRIPT1.
How does one access, for example, student names?
• SQL:1999 has the same misfeature as C/C++ has (and which Java and
OQL do not have): it distinguishes between objects and references to
objects. To pass through a boundary of REF(…) use “” instead of “.”
SELECT T.StudentName, T.Grade
FROM TRANSCRIPT1 T
WHERE
T.StudentAddress.Street = “Main St.”
Not crossing REF(…)
boundary, use “.”
Crossing REF(…)
boundary, use 
33
Inserting REF Values
• How does one give values to REF attributes, like Student in
TRANSCRIPT1?
• Use explicit self-referencing columns, like stud_oid in STUDENT2
• Example: Creating a TRANSCRIPT1 record whose Student attribute has
an object reference to an object in STUDENT2:
INSERT INTO TRANSCRIPT1(Student,Course,Semester,Grade)
SELECT S.stud_oid, ‘HIS666’, ‘F1462’, ‘D’
FROM STUDENT2 S
WHERE S.Id = ‘111111111’
Explicit self-referential
column of STUDENT2
34
Object-Oriented Oracle
An Analysis of the Object-Oriented
Features of Oracle’s
Database Management System
35
Background
• Beginning with Oracle 8 Universal Data Server,
Oracle started implementing object-oriented (OO)
principals within the database management
system.
• Oracle is not a true OO database – objectrelational.
• Oracle’s goals for OO support:
– Allow users to model business objects via types.
– Provide infrastructure to support OO access.
36
OO Features/Advantages of
Objects in Oracle
OO Features:
 Abstraction
 Encapsulation
 Inheritance
Advantages:




Object re-use
Use of methods
Efficiencies
Model real-world business objects
37
Object Type Implementation
Creating Types
Similar to creating a “class” with attributes:
CREATE TYPE addr_ty AS OBJECT
(street
varchar2(60),
cityvar char2(30),
state
char(2),
zip
varchar(9));
38
Object Type Implementation
Imbedding Objects and Nesting
Create a person type with address type nested inside:
CREATE TYPE person_ty AS OBJECT
(name
varchar2(25),
address addr_ty);
Create a student type with person type nested inside:
CREATE TYPE student_ty AS OBJECT
(student_id
varchar2(9),
person
person_ty);
39
Object Type Implementation
Creating an Object Table
Now that the student_ty object type has been
defined it can be used in creating an object
table like the following:
CREATE TABLE STUDENT
(full_student
student_ty);
40
Object Type Implementation
To extract data, the following query can be entered:
SELECT s.full_student.student_id ID,
s.full_student.person.name NAME,
s.full_student.person.address.street
STREET
FROM student s
WHERE s.full_student.student_id = 100
ID
NAME
STREET
--------- ------------------------- ------------100
John Q. Student
1000 Chastain Rd.
41
Object Type Implementation
• Updating and deleting is similar to what one would
do in the relational model:
UPDATE STUDENT s
SET s.full_student.person.name = 'JOHN
NEWNAME'
WHERE s.full_student.student_id = 100;
DELETE FROM STUDENT s
WHERE s.full_student.student_id = 100;
42
Implementing Methods
To define a method in a type object:
create or replace type newperson_ty as object
(firstname
varchar2(25),
lastname
varchar2(25),
birthdate
date,
member function AGE(BirthDate in DATE) return NUMBER;
Then define the method itself:
create or replace type body newperson_ty as
member function AGE(BirthDate in DATE) return NUMBER is
begin
RETURN ROUND(SysDate - BirthDate);
end;
end;
43
Implementing Methods
To test the method first set up a table holding the person_ty object type:
create table NEWPERSON of newperson_ty;
insert into NEWPERSON values
(newperson_ty('JOHN', 'DOE', TO_DATE('03-FEB-1970', 'DDMON-YYYY')));
To call the AGE function we can do the following:
select P.PERSON.AGE(P.PERSON.Birthdate)
from NEWPERSON P;
P.PERSON.AGE(P.PERSON.Birthdate)
---------------------------------------12005
44
Referencing
• Every row object has a unique identifier called the
object identifier (OID).
• OID allows other objects to reference an existing
row object.
• REF function can be used to reference an OID:
create table NEWDEPARTMENT
(DeptName VARCHAR(30),
PersonIn REF NEWPERSON_TY);
• Table NEWDEPARTMENT holds a reference to a
NEWPERSON_TY object, but does not hold any real
values.
45
Referencing
To get a full description of the table just created:
Set describe depth 2
Desc NEWDEPARTMENT
Name
Null?
Type
--------------- -------- ------------------DEPTNAME
VARCHAR2(30)
PERSONIN
REF OF NEWPERSON_TY
FIRSTNAME
VARCHAR2(25)
LASTNAME
VARCHAR2(25)
BIRTHDATE
DATE
46
Referencing
• To insert a record into NEWDEPARTMENT, the REF is
needed to store the NEWPERSON reference in the
PersonIn column:
insert into NEWDEPARTMENT
select 'Research',REF(P)
from NEWPERSON P
where LastName = 'DOE';
• The literal value “Research” is inserted into the
NEWPERSON table.
• The REF function returns the OID from the query on the
selected NEWPERSON object.
• The OID is now stored as a pointer to the row object in
the NEWPERSON object table.
47
Referencing
• The referenced value cannot be seen unless the DREF function is used.
The DREF function takes the OID and evaluates the reference to
return a value.
select DEREF(D.PersonIn)
from NEWDEPARTMENT D
where DEPTNAME = 'Research'
DEREF(D.PERSONIN)(FIRSTNAME, LASTNAME, BIRTHDATE)
---------------------------------------------------NEWPERSON_TY('JOHN', 'DOE', '03-FEB-70')
• This shows that the NEWPERSON record JOHN DOE is referenced by
the Research record in NEWDEPARTMENT.
48
Referencing
• To gather the same structure of the object type of an
object table the VALUE function is required.
select value(p)
from newperson p
where lastname = 'DOE'
VALUE(P)(FIRSTNAME, LASTNAME, BIRTHDATE)
----------------------------------------NEWPERSON_TY('JOHN', 'DOE', '03-FEB-70')
49
Referencing
PL/SQL Sample:
set serveroutput on
declare
v_person
NEWPERSON_TY;
begin
select value(p) into v_person
from NEWPERSON p
where lastname = 'DOE';
DBMS_OUTPUT.PUT_LINE(v_person.firstname);
DBMS_OUTPUT.PUT_LINE(v_person.lastname);
DBMS_OUTPUT.PUT_LINE(v_person.birthdate);
end;
JOHN
DOE
03-FEB-70
50
Inheritance
Create a root type of an object hierarchy:
create type PERSON_TY as object
(name varchar2(25),
birthdate
date,
member function AGE() return number,
member function PRINTME() return varchar2);
To create a subtype the following syntax can be used:
create type EMPLOYEE_TY under PERSON_TY (
salary number,
member function WAGES() return number,
overriding member function PRINTME() return varchar2);
51
OODBMS
52
Object-Oriented Data Model
No one agreed object data model. One definition:
Object-Oriented Data Model (OODM)
– Data model that captures semantics of objects supported in
object-oriented programming.
Object-Oriented Database (OODB)
– Persistent and sharable collection of objects defined by an
ODM.
Object-Oriented DBMS (OODBMS)
– Manager of an ODB.
53
Commercial OODBMSs
•
•
•
•
•
•
•
GemStone from Gemstone Systems Inc.,
Objectivity/DB from Objectivity Inc.,
ObjectStore from Progress Software Corp.,
Ontos from Ontos Inc.,
FastObjects from Poet Software Corp.,
Jasmine from Computer Associates/Fujitsu,
Versant from Versant Corp.
54
Advantages of OODBMSs
•
•
•
•
•
•
Enriched Modeling Capabilities.
Removal of Impedance Mismatch.
More Expressive Query Language.
Support for Schema Evolution.
Support for Long Duration Transactions.
Applicability to Advanced Database Applications.
55
Disadvantages of OODBMSs
•
•
•
•
•
•
Lack of Universal Data Model.
Lack of Experience.
Lack of Standards.
Query Optimization compromises Encapsulation.
Object Level Locking may impact Performance.
Complexity.
56
Alternative Strategies for Developing an
OODBMS
• Extend existing object-oriented programming language.
– GemStone extended Smalltalk.
• Provide extensible OODBMS library.
– Approach taken by Ontos, Versant, and ObjectStore.
• Embed OODB language constructs in a conventional host
language.
– Approach taken by O2,which has extensions for C.
• Extend existing database language with object-oriented
capabilities.
– Approach being pursued by RDBMS and OODBMS vendors.
– Ontos and Versant provide a version of OSQL.
• Develop a novel database data model/language.
57
Single-Level v. Two-Level Storage Model
• With a traditional DBMS, programmer has to:
– Decide when to read and update objects.
– Write code to translate between application’s object model and the
data model of the DBMS.
– Perform additional type-checking when object is read back from
database, to guarantee object will conform to its original type.
• Conventional DBMSs have two-level storage
model: storage model in memory, and database
storage model on disk.
• In contrast, OODBMS gives illusion of single-level
storage model, with similar representation in both
memory and in database stored on disk.
58
Two-Level Storage Model for RDBMS
59
Single-Level Storage Model for OODBMS
60
Object Data Management Group
(ODMG)
• Established by vendors of OODBMSs to define
standards.
• The ODMG Standard includes :
–
–
–
–
Object Data Model (ODM).
Object Definition Language (ODL).
Object Query Language (OQL).
C++, Smalltalk, and Java Language Binding.
61
The Structure of an ODMG Application
62
Main Idea: Host Language = Data Language
• Objects in the host language are mapped directly to
database objects
• Some objects in the host program are persistent. Changing
such objects (through an assignment to an instance variable
or with a method application) directly and transparently
affects the corresponding database object
• Accessing an object using its oid causes an “object fault”
similar to pagefaults in operating systems. This
transparently brings the object into the memory and the
program works with it as if it were a regular object
defined, for example, in the host Java program
63
Architecture of an ODMG DBMS
64
SQL Databases vs. ODMG
• In SQL: Host program accesses the database by
sending SQL queries to it (using JDBC, ODBC,
Embedded SQL, etc.)
• In ODMG: Host program works with database
objects directly
65