[PPT] - Object orientation Object orientation is imperative programming with PowerPoint Presentation

SLIDE 1

Object orientation

Object orientation is imperative programming with some additions

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 1 / 24

SLIDE 2

Object orientation

Object orientation is imperative programming with some additions

◮ Abstraction is obtained (also) by

encapsulation, with the purpose to hide and protect data

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 1 / 24

SLIDE 3

Object orientation

Object orientation is imperative programming with some additions

◮ Abstraction is obtained (also) by

encapsulation, with the purpose to hide and protect data

◮ Modularization, which is obtained by a variety of abstraction mechanisms

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 1 / 24

SLIDE 4

Object orientation

Object orientation is imperative programming with some additions

◮ Abstraction is obtained (also) by

encapsulation, with the purpose to hide and protect data

◮ Modularization, which is obtained by a variety of abstraction mechanisms ◮ Data independence, which is obtained from abstraction and modularization.

An abstract data type or a class is in essence an existentially quantified data type, e.g.:

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 1 / 24

SLIDE 5

Object orientation . . .

exception EmptyStack; abstype ’t Stack = S of ’t list with val newStack = S([]) fun empty (S []) = true | empty (S [_]) = false; fun push (S s) x = S(x::s); fun pop (S []) = raise EmptyStack | pop (S (_::xs)) = S(xs); fun top (S []) = raise EmptyStack | top (S (x::_)) = x; end;

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 2 / 24

SLIDE 6

Object orientation . . .

Its type is ∀t.∃S.[unit → S, S → bool, S × t → S, S → S, S → t]

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 3 / 24

SLIDE 7

Object orientation . . .

Its type is ∀t.∃S.[unit → S, S → bool, S × t → S, S → S, S → t] where the existential quantification mainly tells us that there is a need for an internal structure to implement the type

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 3 / 24

SLIDE 8

Object orientation . . .

Its type is ∀t.∃S.[unit → S, S → bool, S × t → S, S → S, S → t] where the existential quantification mainly tells us that there is a need for an internal structure to implement the type Most of the ideas in object oriented programming stem from Simula, a Norwegian programming language developed in the mid 1960-s. The purpose was to implement a base for representing processes when simulating reactions in nuclear reactors.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 3 / 24

SLIDE 9

Object orientation . . .

You did not model activities or processes with functions but by finding a representation for its physical counterpart. This means that an object encapsulate its own data (its internal state) and its behavior

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 4 / 24

SLIDE 10

Object orientation . . .

You did not model activities or processes with functions but by finding a representation for its physical counterpart. This means that an object encapsulate its own data (its internal state) and its behavior Objects are instances of classes and have an identity (in that every object is unique) and in most object oriented systems every object has a unique object identifier (OID) that

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 4 / 24

SLIDE 11

Object orientation . . .

You did not model activities or processes with functions but by finding a representation for its physical counterpart. This means that an object encapsulate its own data (its internal state) and its behavior Objects are instances of classes and have an identity (in that every object is unique) and in most object oriented systems every object has a unique object identifier (OID) that

◮ is automatically generated by the system

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 4 / 24

SLIDE 12

Object orientation . . .

You did not model activities or processes with functions but by finding a representation for its physical counterpart. This means that an object encapsulate its own data (its internal state) and its behavior Objects are instances of classes and have an identity (in that every object is unique) and in most object oriented systems every object has a unique object identifier (OID) that

◮ is automatically generated by the system ◮ is unique for a specific object

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 4 / 24

SLIDE 13

Object orientation . . .

You did not model activities or processes with functions but by finding a representation for its physical counterpart. This means that an object encapsulate its own data (its internal state) and its behavior Objects are instances of classes and have an identity (in that every object is unique) and in most object oriented systems every object has a unique object identifier (OID) that

◮ is automatically generated by the system ◮ is unique for a specific object ◮ is invariant (never changes during the life span of an object)

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 4 / 24

SLIDE 14

Object orientation . . .

You did not model activities or processes with functions but by finding a representation for its physical counterpart. This means that an object encapsulate its own data (its internal state) and its behavior Objects are instances of classes and have an identity (in that every object is unique) and in most object oriented systems every object has a unique object identifier (OID) that

◮ is automatically generated by the system ◮ is unique for a specific object ◮ is invariant (never changes during the life span of an object) ◮ is independent of its internal state (two distinct objects may have identical

inner state but they still have different OID)

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 4 / 24

SLIDE 15

Object orientation . . .

You did not model activities or processes with functions but by finding a representation for its physical counterpart. This means that an object encapsulate its own data (its internal state) and its behavior Objects are instances of classes and have an identity (in that every object is unique) and in most object oriented systems every object has a unique object identifier (OID) that

◮ is automatically generated by the system ◮ is unique for a specific object ◮ is invariant (never changes during the life span of an object) ◮ is independent of its internal state (two distinct objects may have identical

inner state but they still have different OID)

◮ is (ideally) invisible to the user.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 4 / 24

SLIDE 16

Object orientation . . .

OID benefits (and drawbacks)

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 5 / 24

SLIDE 17

Object orientation . . .

OID benefits (and drawbacks)

◮ OIDs are efficient as they use a minimum of space, typically less than text

strings, foreign keys and other semantically based references.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 5 / 24

SLIDE 18

Object orientation . . .

OID benefits (and drawbacks)

◮ OIDs are efficient as they use a minimum of space, typically less than text

strings, foreign keys and other semantically based references.

◮ OIDs are quick as they directly point at the space that the object occupies.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 5 / 24

SLIDE 19

Object orientation . . .

OID benefits (and drawbacks)

◮ OIDs are efficient as they use a minimum of space, typically less than text

strings, foreign keys and other semantically based references.

◮ OIDs are quick as they directly point at the space that the object occupies. ◮ OIDs cannot be modified by the user as they are system generated and

(often) invisible. Thus, they allow for a reference integrity that the user don’t have to manage.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 5 / 24

SLIDE 20

Object orientation . . .

OID benefits (and drawbacks)

◮ OIDs are efficient as they use a minimum of space, typically less than text

strings, foreign keys and other semantically based references.

◮ OIDs are quick as they directly point at the space that the object occupies. ◮ OIDs cannot be modified by the user as they are system generated and

(often) invisible. Thus, they allow for a reference integrity that the user don’t have to manage.

◮ OIDs don’t depend on object content and thus, the content may be changed

without compromising the objects identity.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 5 / 24

SLIDE 21

Object orientation . . .

The last property gives rise to a potential drawback (deficit?). Two objects may have the same content and still be separate objects. How is that managed? And how do you distinguish between the two concepts?

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 6 / 24

SLIDE 22

Object orientation . . .

The last property gives rise to a potential drawback (deficit?). Two objects may have the same content and still be separate objects. How is that managed? And how do you distinguish between the two concepts? Objects are identical if they share OID and equal if they have identical content. Sometimes this is referred to as shallow and deep equality.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 6 / 24

SLIDE 23

Object orientation . . .

The last property gives rise to a potential drawback (deficit?). Two objects may have the same content and still be separate objects. How is that managed? And how do you distinguish between the two concepts? Objects are identical if they share OID and equal if they have identical content. Sometimes this is referred to as shallow and deep equality. Objects inherit properties from other objects if the class they belong to is a subclass to another class.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 6 / 24

SLIDE 24

Object orientation . . .

The last property gives rise to a potential drawback (deficit?). Two objects may have the same content and still be separate objects. How is that managed? And how do you distinguish between the two concepts? Objects are identical if they share OID and equal if they have identical content. Sometimes this is referred to as shallow and deep equality. Objects inherit properties from other objects if the class they belong to is a subclass to another class. Objects may be very complex by containing references to other objects.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 6 / 24

SLIDE 25

How do we store objects in databases?

One way is of course to use traditional relational databases

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 7 / 24

SLIDE 26

How do we store objects in databases?

One way is of course to use traditional relational databases and then either use a BLOB getting all the usual problems with BLOBs

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 7 / 24

SLIDE 27

How do we store objects in databases?

One way is of course to use traditional relational databases and then either use a BLOB getting all the usual problems with BLOBs

r we can decompose the objects and map their inner state on tables.

However, this technique gives raise to problems.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 7 / 24

SLIDE 28

How do we store objects in databases?

One way is of course to use traditional relational databases and then either use a BLOB getting all the usual problems with BLOBs

r we can decompose the objects and map their inner state on tables.

However, this technique gives raise to problems. Suppose we have a simple class hierarchy:

ssn fname lname position sex bonus Exec Seller startdate Admin salary

Employee

district field

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 7 / 24

SLIDE 29

How do we store objects . . .

Three methods:

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 8 / 24

SLIDE 30

How do we store objects . . .

Three methods:

1. Map each class and subclass on its own base relation (table).

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 8 / 24

SLIDE 31

How do we store objects . . .

Three methods:

1. Map each class and subclass on its own base relation (table).

Employee (ssn, FName, LName, position, sex, salary) Seller (ssn, district) Exec (ssn, bonus, startDate) Admin (ssn, field)

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 8 / 24

SLIDE 32

How do we store objects . . .

Three methods:

1. Map each class and subclass on its own base relation (table).

Employee (ssn, FName, LName, position, sex, salary) Seller (ssn, district) Exec (ssn, bonus, startDate) Admin (ssn, field) Let’s ignore the fact that we might have to use special tools for some data types and suppose that we can handle all types without problems.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 8 / 24

SLIDE 33

How do we store objects . . .

Three methods:

1. Map each class and subclass on its own base relation (table).

Employee (ssn, FName, LName, position, sex, salary) Seller (ssn, district) Exec (ssn, bonus, startDate) Admin (ssn, field) Let’s ignore the fact that we might have to use special tools for some data types and suppose that we can handle all types without problems. Still we lose in terms of semantics. How do we distinguish between classes and subclasses? The only way is to code it in the software we use to access the database.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 8 / 24

SLIDE 34

How do we store objects . . .

2. Map each subclass on a base relation.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 9 / 24

SLIDE 35

How do we store objects . . .

2. Map each subclass on a base relation.

Seller (ssn, FName, LName, position, sex, salary, district) Exec (ssn, FName, LName, position, sex, salary, bonus, startDate) Admin (ssn, FName, LName, position, sex, salary, field)

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 9 / 24

SLIDE 36

How do we store objects . . .

2. Map each subclass on a base relation.

Seller (ssn, FName, LName, position, sex, salary, district) Exec (ssn, FName, LName, position, sex, salary, bonus, startDate) Admin (ssn, FName, LName, position, sex, salary, field) Again we lose semantics. It is far from clear that these tables represent subclasses to a common superclass and to list all employees we have to collect data from three tables and create the union of the common attributes from the three.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 9 / 24

SLIDE 37

How do we store objects . . .

3. Map the complete class hierarchy onto one single table.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 10 / 24

SLIDE 38

How do we store objects . . .

3. Map the complete class hierarchy onto one single table.

Employee (ssn, FName, LName, position, sex, salary, district, bonus, startDate, field, empType)

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 10 / 24

SLIDE 39

How do we store objects . . .

3. Map the complete class hierarchy onto one single table.

Employee (ssn, FName, LName, position, sex, salary, district, bonus, startDate, field, empType) I added empType to see to which subclass an object belongs. We get the same semantic loss as with the other methods and we still cannot see that we have three subclasses to a common superclass and also we will store a lot of NULL values.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 10 / 24

SLIDE 40

Object oriented databases

Atkinson, et.al. published ”The Object-Oriented Database System Manifesto” in 1989 in which they claimed that object orientation would dominate the future and gave directions as to what had to be included.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 11 / 24

SLIDE 41

Object oriented databases

Atkinson, et.al. published ”The Object-Oriented Database System Manifesto” in 1989 in which they claimed that object orientation would dominate the future and gave directions as to what had to be included. They meant that one must create object oriented database management systems (OODBMS) to meet the need for persistence in object oriented lanuages.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 11 / 24

SLIDE 42

Object oriented databases

Atkinson, et.al. published ”The Object-Oriented Database System Manifesto” in 1989 in which they claimed that object orientation would dominate the future and gave directions as to what had to be included. They meant that one must create object oriented database management systems (OODBMS) to meet the need for persistence in object oriented lanuages. In short they wanted OODBMS to have all properties of object oriented lanuages as well as all properties of traditional DBMS.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 11 / 24

SLIDE 43

Object oriented databases

Atkinson, et.al. published ”The Object-Oriented Database System Manifesto” in 1989 in which they claimed that object orientation would dominate the future and gave directions as to what had to be included. They meant that one must create object oriented database management systems (OODBMS) to meet the need for persistence in object oriented lanuages. In short they wanted OODBMS to have all properties of object oriented lanuages as well as all properties of traditional DBMS. In 1991 Kim defined what he considered to be

◮ an object oriented data model (OODM), a data model describing the semantics of an

bject as thay are supported in object oriented programming,

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 11 / 24

SLIDE 44

Object oriented databases

Atkinson, et.al. published ”The Object-Oriented Database System Manifesto” in 1989 in which they claimed that object orientation would dominate the future and gave directions as to what had to be included. They meant that one must create object oriented database management systems (OODBMS) to meet the need for persistence in object oriented lanuages. In short they wanted OODBMS to have all properties of object oriented lanuages as well as all properties of traditional DBMS. In 1991 Kim defined what he considered to be

◮ an object oriented data model (OODM), a data model describing the semantics of an

bject as thay are supported in object oriented programming,

◮ an object oriented database (OODB), a place to store persistent sharable objects as

defined in OODM and finally

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 11 / 24

SLIDE 45

Object oriented databases

Atkinson, et.al. published ”The Object-Oriented Database System Manifesto” in 1989 in which they claimed that object orientation would dominate the future and gave directions as to what had to be included. They meant that one must create object oriented database management systems (OODBMS) to meet the need for persistence in object oriented lanuages. In short they wanted OODBMS to have all properties of object oriented lanuages as well as all properties of traditional DBMS. In 1991 Kim defined what he considered to be

◮ an object oriented data model (OODM), a data model describing the semantics of an

bject as thay are supported in object oriented programming,

◮ an object oriented database (OODB), a place to store persistent sharable objects as

defined in OODM and finally

◮ an object oriented database management system (OODBMS), a DBMS made for the

management of an OODB.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 11 / 24

SLIDE 46

Object oriented databases . . .

The definitions are quite “fuzzy” and show, in essence, that there is no uniform and commonly accepted OODM as a fundament for OODBMS as in the world of relational databases where all RDBMS use the common relational model as common fundament

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 12 / 24

SLIDE 47

Object oriented databases . . .

The definitions are quite “fuzzy” and show, in essence, that there is no uniform and commonly accepted OODM as a fundament for OODBMS as in the world of relational databases where all RDBMS use the common relational model as common fundament There is, however, a uniform functional data model, defined by Kerschberg in 1976 that could have served as a basis for object oriented systems It builds on objects and functional relationships.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 12 / 24

SLIDE 48

Functional models . . .

address floor String Integer String String String String Integer Integer Integer Integer name salary is_employed dept employees volume supplier

item

type volume dept company department item_no

manager employee

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 13 / 24

SLIDE 49

OODBMS – GemStone

Researchers saw many strategies to develop OODBMS. One was to extend an OOP language like Smalltalk, C++ or Java. A direct extension of Smalltalk is GemStone, attempting to turn Smalltalk into a full fledged OODBMS

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 14 / 24

SLIDE 50

OODBMS – GemStone

Researchers saw many strategies to develop OODBMS. One was to extend an OOP language like Smalltalk, C++ or Java. A direct extension of Smalltalk is GemStone, attempting to turn Smalltalk into a full fledged OODBMS Application programs amy be written in Opal (the extension of Smalltalk), C(!), C++, Java and Pascal(!).

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 14 / 24

SLIDE 51

OODBMS – GemStone

Researchers saw many strategies to develop OODBMS. One was to extend an OOP language like Smalltalk, C++ or Java. A direct extension of Smalltalk is GemStone, attempting to turn Smalltalk into a full fledged OODBMS Application programs amy be written in Opal (the extension of Smalltalk), C(!), C++, Java and Pascal(!). The system was built on Smalltalk-workstations (PC, Mac, Tektronix, ...) and a server running in VMS on a Vax-machine or on some Unix-machine.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 14 / 24

SLIDE 52

OODBMS – GemStone . . .

workstation Smalltalk running workstation Smalltalk running workstation Smalltalk running

...

Gemstone server Database Database

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 15 / 24

SLIDE 53

OODBMS – GemStone . . .

GemStone builds entirely on the Smalltalk model with classes, metaclasses, objects and messages.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 16 / 24

SLIDE 54

OODBMS – GemStone . . .

GemStone builds entirely on the Smalltalk model with classes, metaclasses, objects and messages. Classes are organized as a hierarchy with simple inheritance. OPAL is used as DDL, DML, programming language and command lagugage. There is an IDE (OPE = OPAL Programming Environment) that contains

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 16 / 24

SLIDE 55

OODBMS – GemStone . . .

GemStone builds entirely on the Smalltalk model with classes, metaclasses, objects and messages. Classes are organized as a hierarchy with simple inheritance. OPAL is used as DDL, DML, programming language and command lagugage. There is an IDE (OPE = OPAL Programming Environment) that contains

◮ a class browser that allows for adding, deleting, inspecting and modifying GemStone

classes (in the usual Smalltalk manner),

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 16 / 24

SLIDE 56

OODBMS – GemStone . . .

GemStone builds entirely on the Smalltalk model with classes, metaclasses, objects and messages. Classes are organized as a hierarchy with simple inheritance. OPAL is used as DDL, DML, programming language and command lagugage. There is an IDE (OPE = OPAL Programming Environment) that contains

◮ a class browser that allows for adding, deleting, inspecting and modifying GemStone

classes (in the usual Smalltalk manner),

◮ a file management module (Bulk Loader/Dumper)

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 16 / 24

SLIDE 57

OODBMS – GemStone . . .

GemStone builds entirely on the Smalltalk model with classes, metaclasses, objects and messages. Classes are organized as a hierarchy with simple inheritance. OPAL is used as DDL, DML, programming language and command lagugage. There is an IDE (OPE = OPAL Programming Environment) that contains

◮ a class browser that allows for adding, deleting, inspecting and modifying GemStone

classes (in the usual Smalltalk manner),

◮ a file management module (Bulk Loader/Dumper) ◮ an editor (Workspace editor) that allwos you to write and run OPAL programs.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 16 / 24

SLIDE 58

OODBMS – GemStone . . .

GemStone builds entirely on the Smalltalk model with classes, metaclasses, objects and messages. Classes are organized as a hierarchy with simple inheritance. OPAL is used as DDL, DML, programming language and command lagugage. There is an IDE (OPE = OPAL Programming Environment) that contains

◮ a class browser that allows for adding, deleting, inspecting and modifying GemStone

classes (in the usual Smalltalk manner),

◮ a file management module (Bulk Loader/Dumper) ◮ an editor (Workspace editor) that allwos you to write and run OPAL programs. ◮ PIM (Procedural Interface Modules) that makes it possible to connect to C and Pascal

progams via remote procedure calls.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 16 / 24

SLIDE 59

OODBMS – GemStone . . .

Workstation Workspace editor Loader/Dumper Class browser PIM C/Pascal Application programs network module Window manager Network

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 17 / 24

SLIDE 60

OODBMS – GemStone . . .

The server is divided into two parts:

Network application Gem process Gem process . . . Stone process File system Database Database

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 18 / 24

SLIDE 61

OODBMS – GemStone . . .

The server is divided into two parts:

◮ Gem-processes,

implementing the virtual machine (standard Smalltalk) and the object memory

Network application Gem process Gem process . . . Stone process File system Database Database

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 18 / 24

SLIDE 62

OODBMS – GemStone . . .

The server is divided into two parts:

◮ Gem-processes,

implementing the virtual machine (standard Smalltalk) and the object memory Gem compiles and runs OPAL methods and manages authentication and session control

Network application Gem process Gem process . . . Stone process File system Database Database

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 18 / 24

SLIDE 63

OODBMS – GemStone . . .

The server is divided into two parts:

◮ Gem-processes,

implementing the virtual machine (standard Smalltalk) and the object memory Gem compiles and runs OPAL methods and manages authentication and session control

◮ Stone-process, managing

secondary memory, concurrency control, access rights, transactions, recovery and workspace for active sessions.

Network application Gem process Gem process . . . Stone process File system Database Database

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 18 / 24

SLIDE 64

OODBMS – ObjectStore

Another strategy is to provide extendible OO database libraries as in ObjectStore.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 19 / 24

SLIDE 65

OODBMS – ObjectStore

Another strategy is to provide extendible OO database libraries as in ObjectStore. ObjectStore is a multi-client/multi-server system where each server manages an

bject store and also manages concurrency control and acces control.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 19 / 24

SLIDE 66

OODBMS – ObjectStore

Another strategy is to provide extendible OO database libraries as in ObjectStore. ObjectStore is a multi-client/multi-server system where each server manages an

bject store and also manages concurrency control and acces control.

A client connects to any server

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 19 / 24

SLIDE 67

OODBMS – ObjectStore

Another strategy is to provide extendible OO database libraries as in ObjectStore. ObjectStore is a multi-client/multi-server system where each server manages an

bject store and also manages concurrency control and acces control.

A client connects to any server There is one server and any number of clients on each computer in the network.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 19 / 24

SLIDE 68

OODBMS – ObjectStore

Another strategy is to provide extendible OO database libraries as in ObjectStore. ObjectStore is a multi-client/multi-server system where each server manages an

bject store and also manages concurrency control and acces control.

A client connects to any server There is one server and any number of clients on each computer in the network. On every computer hosting at least one ObjectStore client the is also a cache manager and each application has its own client cache where objects are kept when activated (automatically fetched from secondary memory when accessed) and are waiting to be rewritten to persistent memory.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 19 / 24

SLIDE 69

OODBMS – ObjectStore . . .

application Cache manager Client Server Server Cache manager Client application Cache manager Client application

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 20 / 24

SLIDE 70

OODBMS – ObjectStore . . .

ObjectStore is written entirely in C++ and manages object in binary format without mapping and remapping pointers (swizzling).

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 21 / 24

SLIDE 71

OODBMS – ObjectStore . . .

ObjectStore is written entirely in C++ and manages object in binary format without mapping and remapping pointers (swizzling). An object is directly accessed if already in some client cache and if not an error is generated.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 21 / 24

SLIDE 72

OODBMS – ObjectStore . . .

ObjectStore is written entirely in C++ and manages object in binary format without mapping and remapping pointers (swizzling). An object is directly accessed if already in some client cache and if not an error is generated. Errors are generated if the object is in a cache but never accessed or accessed with different access rights than at previous access.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 21 / 24

SLIDE 73

OODBMS – ObjectStore . . .

ObjectStore is written entirely in C++ and manages object in binary format without mapping and remapping pointers (swizzling). An object is directly accessed if already in some client cache and if not an error is generated. Errors are generated if the object is in a cache but never accessed or accessed with different access rights than at previous access. Errors of this kind will reactivate the object (reread it from DB) possibly after synchronizing it.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 21 / 24

SLIDE 74

OODBMS – ObjectStore . . .

ObjectStore is written entirely in C++ and manages object in binary format without mapping and remapping pointers (swizzling). An object is directly accessed if already in some client cache and if not an error is generated. Errors are generated if the object is in a cache but never accessed or accessed with different access rights than at previous access. Errors of this kind will reactivate the object (reread it from DB) possibly after synchronizing it. Objects are accessed with a query language (an extension to C++) and standard C++ templates are used to define which objects shall be persistent.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 21 / 24

SLIDE 75

What has been decided?

In spite of the apparent lack of cooperation and lack of standards some things have been agreed upon mainly by consortiums of enterprises.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 22 / 24

SLIDE 76

What has been decided?

In spite of the apparent lack of cooperation and lack of standards some things have been agreed upon mainly by consortiums of enterprises. The Object Management Group (OMG) has definied a standard for object communication named CORBA (Common Object Request Broker Architecture) with certain interesting properties.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 22 / 24

SLIDE 77

CORBA – Common Object Request Broker Architecture

emphasis on “common” and “broker”.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 23 / 24

SLIDE 78

CORBA – Common Object Request Broker Architecture

emphasis on “common” and “broker”. CORBA does not standardise object representation or implementation but only how to handle objects.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 23 / 24

SLIDE 79

CORBA – Common Object Request Broker Architecture

emphasis on “common” and “broker”. CORBA does not standardise object representation or implementation but only how to handle objects. CORBA provides an enabling technology as a kind of infrastructure for incorporating component into ditributed application programs.

DD2471 (Lecture 06) Modern database systems & their applications Spring 2011 23 / 24

SLIDE 80

CORBA – Common Object Request Broker Architecture

emphasis on “common” and “broker”. CORBA does not standardise object representation or implementation but only how to handle objects. CORBA provides an enabling technology as a kind of infrastructure for incorporating component into ditributed application programs. One objective was to make the building of large distributed systems as simple as building centralised systems.

DD2471 (Lecture 06)

Modern database systems & their applications Spring 2011 23 / 24

SLIDE 81