Chapter 2: Object Model Prof. Hyoung-Joo Kim OOPSLA Lab. Dept. of Computer Engineering Seoul National Univ.

SNU OOPSLA Lab.2 Contents 2.1 Introduction 2.2 Types: Specifications and Implementations 2.3 Objects 2.4 The Characteristics of a Type 2.5 Metadata 2.6 Locking and Concurrency Control 2.7 Transaction Model 2.8 Database Operations

SNU OOPSLA Lab Introduction The Object Model specifies the constructs that are supported by an ODBMS and used to construct the application’s object model Object Literal Id attributes relationships operations relationships attributes operations Database Set of types (= Schema) Instances of type +

SNU OOPSLA Lab Types: Specifications and Implementations(1) Type: Specification + Implementation(s) Interface ClassLiteral Abstract state (properties) Abstract behavior (operations) Representation + methods Data structure of abstract state Procedure bodies of abstract behavior class Employee { attribute string name; attribute unsigned salary; relationship Manager boss inverse Manage::subordinates; int totalsalary(in unsigned rate); }; class Employee { char name[SIZE]; unsigned salary; Manager mgr; int totalsalary(unsigned rate) { return salary*(1+rate);} }; C++ binding

SNU OOPSLA Lab Types: Specifications and Implementations(2) A type has two aspects to its definition: –Specification External aspects such as properties, operations, and exceptions A type has only one specification 3 specification definitions: –interface defines only the abstract behavior of a object type –class defines the abstract state and behavior of a object type –literal defines only abstract state of a literal type Examples interface Employee {...}; class Person {...}; struct Complex {float re; float im;};

SNU OOPSLA Lab Types: Specifications and Implementations(3) –Implementation of a object type Internal aspects such as procedure bodies Implementation of the type’s operations and other internal details A type has one or more implementation Components: –representation: a data structure derived from the type’s abstract state by a language binding –methods: procedure bodies derived from the type’s abstract behavior by the language binding –Implementation of a literal type Each language binding defines an implementation mapping for literal types e.g.) struct (of Complex in ODL) structure definition in C++

SNU OOPSLA Lab.7 Separation between specification and implementation –Is the way that the Object Model reflects encapsulation –Is for multilingual access to objects of a single type and sharing of objects accross heterogeneous computing environments 2.2 Types: Specifications and Implementations(4) Implementation by C++ binding Implementation by Java binding Implementation by Smalltalk binding Specifications of types

SNU OOPSLA Lab Types: Specifications and Implementations(5) Subtyping and inheritance of behavior –ISA relationship or generalization-specialization relationship –The supertype is the more general type; the subtype is the more specialized –Objects of subtype can be used wherever those of supertype can –Polymorphic nature of object behavior: run-time invocation dependent on the actual of the instance –Multiple inheritance of object behavior is possible Name conflict by name overloading happens! The ODMG Object Model disallows name overloading

SNU OOPSLA Lab.9 Employee Professor Associate-Professor Type/subtype relationship supertype/ subtype interface Employee {...}; interface Professor: Employee {...}; interface Associate_Professor: Professor {...}; 2.2 Types: Specifications and Implementations(6) Example

SNU OOPSLA Lab Types: Specifications and Implementations(7) Instantiation and inheritance –Class type is instantiable by the programmer, but interface type cannot –Inheritance between types are limited since subtyping pertains to the inheritance of behavior only and due to the inefficiencies and ambiguities of multiple inheritance of state interfaces interface interfaces class classes class classes interface

SNU OOPSLA Lab Types: Specifications and Implementations(8) Inheritance of states –EXTENDS relationship is: For the inheritance of state (cf. ISA relationship) Applicable only to object types A single inheritance relationship between two classes Transitive

SNU OOPSLA Lab Types: Specifications and Implementations(9) Example class Person { attribute string name; attribute Date birthdate; }; class ManagerPerson extends EmployPerson: Manager { relationship set subordinates inverse Employee::boss; }; class EmplyeePerson extends Person: Employee { attribute Date hiredate; attribute Currency payrate; relationship Manager boss inverse Manager::subordinates; }; EXTEDS relationship ISA relationship

SNU OOPSLA Lab Types: Specifications and Implementations(10) Extents –The extents of a type is the set of all instances of the type within a particular database –ISA relationship also applies to the extent –Extent maintenance(i.e. insert and delete an instance) can be automatically done by the ODBMS –An extent can be indexed for access speedup Keys –In some case(i.e. index an extent) the instances of a type can be uniquely identified by the values of properties which are called keys (cf. candidate keys in relational model)

SNU OOPSLA Lab Objects Aspects of objects: –Creation –Identifiers –Names –Lifetimes –Structure

SNU OOPSLA Lab Objects(1): Creation Object creation is made by invoking creation operations on factory interfaces: All objects have the ODL interface, implicitly inherited by the definitions of all user-defined objects –Locking operations: lock(), try_lock() –Identity comparison: same_as() –Copy operation: copy() –Delete operation: delete() Interface ObjectFactory { Object New(); };

SNU OOPSLA Lab Objects(2): Identifiers Object identifiers in database are unique and never change The notion of object identifier differs from that of primary key in the relational model –The value column(s) comprise the primary key in relational table, so the identity also changes if the values do Object is mutable (cf. literal is immutable) Object identifier is generated by the ODBMS, not by application

SNU OOPSLA Lab Objects(3): Names The application can refer at its convenience to an object by name using mapping function The scope of uniqueness of names is a database object name mapping function unmapping function e.g., in SOP OODBMS mapname(const RefAny& obj, const char* name) unmapname(const RefAny& obj) 1:1

SNU OOPSLA Lab Objects(4): Lifetimes Two lifetimes: –Transient objects Managed by the programming language run-time system Non-exist in persistent storage after the process terminates –Persistent objects Managed by the ODBMS run-time system Exist persistently in storage Object lifetimes are independent of types –Persistent & transient objects are manipulated by the same operations(e.g., OOPL) –In relation model, persistent data and transient data are manipulated respectively by SQL and PL

SNU OOPSLA Lab Objects(5): Structure Classification of object types –Atomic objects User-defined There is no built-in atomic object type in the ODMG Object Model –Collection objects Set, Bag, List, Array, Dictionary Element type of collection can be atomic, another collection, or literal All elements must be of the same type –Structured objects Date, Interval, Time, Timestamp

SNU OOPSLA Lab Literals(1) Literals do not have object identifiers(vs. objects) Four literal types: –atomic literal –collection literal –structured literal –null literal

SNU OOPSLA Lab Literals(2) Atomic literals –Programming language binding supports an analog of atomic literal types(e.g., long, float, boolean, char, enum, etc.) Collection literals –set, bag, list, array, dictionary Structured literals –date, interval, time, timestamp –User-defined structures can be defined as need using a built-in type generator struct Null literals

SNU OOPSLA Lab The Characteristics of a Type Type Attributes Relationship Operations Modeling stateModeling behavior How can we model state and behavior of a type?

SNU OOPSLA Lab Modeling State - Properties(1) A type defines a set of properties through which the state of instances of the type is accessible and manipulated Two kinds of properties: –attribute –relationship: defined between two types whose instance must be referenceable by object identifiers

SNU OOPSLA Lab Modeling State - Properties(2): Attributes An attribute: the abstract state of a type –An attribute’s value is either a literal or an object identifier –An attribute is not the same as a data structure, which is a physical representation interface Person { attribute short age; attribute string name; attribute enum gender{male, female}; attribute Department dept; };

SNU OOPSLA Lab.25 interface Professor {... Relationship set teaches inverse Course::is_taught_by; }; interface Course {... Relationship Professor is_taught_by inverse Professor::teaches; }; Travel paths tp_1 Prof tp_4 tp_3 tp_2 tp_1 Course1 Course2 Course3 Course4 set Modeling State - Properties(3):Relationships The ODMG Object Model supports only binary relationships, i.e., relationships between two types e.g., one-to-one, one-to-many, many-to-many

SNU OOPSLA Lab Modeling State - Properties(3):Relationships(con’t) The referential integrity of relationships relationships vs. pointers The implementation of relationships e.g., cadinality “many” relationships relationship set teaches inverse Professor::is_taught_by; attribute set teaches; void form_teaches(in Course aCourse) raise(IntegrityErrror); void drop_teaches(in Course aCourse); void add_teaches(in Course aCourse) raise(IntegrityErrror); void remove_teaches(in Course aCourse);

SNU OOPSLA Lab Modeling Behavior - Operations(1) Behavior is specified as a set of operation signatures, each of which defines: –The name of an operations –The name and type of each of arguments –The types of value(s) returned –The names of any exceptions(error conditions) Object Model specification for operations is identical to that of the OMG CORBA

SNU OOPSLA Lab Modeling Behavior - Operations(2) Characteristics of the operation –An operation is defined on only a single type –An operation name need be unique only within a single type definition(not between types) –Operation names can be overloaded Operation selection problem happens -> operation name resolution or operation dispatching Operation selection is based on the first argument, i.e., the most specific type of the object -> single-dispatch model The major reasons for single-dispatch model was: –Consistency with the C++ and Smalltalk programming languages –To avoid incompatibilities with the OMG CORBA object model

SNU OOPSLA Lab Metadata(1) Metadata is –Descriptive information about database objects that defines the schema of a database –used by the ODBMS to define the structure of the database and at runtime to guide its access to the database –Stored in an ODL Schema Repository Instances of Person, Student, Professor type Instances of type Type (Person, Student, Professor type) Person Student Professor Modeling

SNU OOPSLA Lab Metadata(2) e.g., Scope, MetaObject, Interface, Class, etc. interface Class: Interface { attribute list extents; attribute list keys; relationship Class extender inverse Class::extensions; relationship set extensions inverse Class::extender; };

SNU OOPSLA Lab Locking and Concurrency Control Concurrency control in the ODMG Object Model –Lock-based and pessimistic concurrency control –Lock type: read/write/upgrade lock –Implicit/explicit locking: whether no specific operations need to obtain a specific lock –Lock duration: two-phase locking algorithm

SNU OOPSLA Lab Transaction Model Transaction management in the ODMG –Any access, creation, modification, and deletion of persistent objects must be done within a transaction –A unit of logic which guarantees atomicity, consistency, isolation, durability –Transaction operations: TransactionFactory / Transaction type interface Transaction { void begin() raises(TransactionInProgress); void commit() raises(TransactionNotInProgress); void abort() raises(TransactionNotInProgress); void checkpoint() raises(TransactionNotInProgress); void join(); void leave(); void isOpen(); };

SNU OOPSLA Lab Database Operations Database creation and manipulation –DatabaseFactory/Database type interface Database { void open(in string database_name); void close(); void bind(in any obj, in string name); Object unbind(in string name); Object lookup(in string obj_name); Module schema(); }; interface DatabaseFactory { Database new(); };