Chapter 2. Object-Oriented Data Model

1

E.Bertino, L.MatinoObject-Oriented Database Systems

Chapter 2. Object-Oriented Data Model

Seoul National University

Department. of Computer Engineering

OOPSLA Lab

2OOPSLA Lab

CONTENTS

Core Concepts Semantic Extensions The GemStone Data Model The O2 Data Model The Iris Data Model Summary

3OOPSLA Lab

Core Concepts

Objects and identity Complex objects Encapsulation Classes Inheritance Overloading, overriding, and late binding Comparison OO data model with other models

Core Concepts

4OOPSLA Lab

Value vs. Object

What’s value? self-identifying primitive entities complex values, which can’t be shared(O2)

What’s object? object represents real world entity object = state(or data) + behavior(or operation)

• values of attributes to represent state

• methods to define the behavior of object

each object is identified by a unique OID

Core Concepts

5OOPSLA Lab

Core Concepts

Methods

With methods, objects are manipulated Definition of a method consists of

signature for the specification of the method• (method’s name, arguments’ (class, name), result’s class)

• ORION, Smalltalk don’t require the argument class

body for implementation of the method• a set of instructions by any given P/L

• LISP in ORION, Smalltalk extension in GemStone, C in O2

6OOPSLA Lab

Object1

M4

M1

M2

M3

Object2

M3

M2

M1

M4

Object3

M3

M4

M1

M2message1

message2

message3

7OOPSLA Lab

Core Concepts

Encapsulation

Object is accessed only by method which is evoked by message to the object

Distinction between the specification and implementation => modularity

In P/L, object consists of interface which is the specification of the set of

operations implementation which contains the structure of the

object and the methods

8OOPSLA Lab

Encapsulation (Cont’d)

In OODB, object consists of data and operations Whether the structure is part of the interface or not

is unclear Logical data independence

implementation of objects can be modified, while the applications remain unchanged

Valid violation of the encapsulation direct accessing attributes in query processing

9OOPSLA Lab

Core Concepts

Violation of Encapsulation Principle

Advantages of violating the encapsulation the programmer’s burden is decreased system-provided operations increases the efficiency

Handling the violation of encapsulation principle in Vbase/Ontos, system-defined methods for reading and

writing the attributes in O2, C++, users can state which attributes and methods

are visible(public) in ORION, all attributes and methods are visible while

authorization mechanisms to control the access to them

10OOPSLA Lab

Core Concepts

Key OIDvalue of one or more attributes independent from state of object

modifiable non-modifiablesame if both have same values different even if both have same state

unique within a relation unique within entire database

OID and Key

OID vs. Key

Advantages of OID over Key implemented not by programmer but by the system better performance due to low level by the system no artificial code which is necessary in longer external keys

11OOPSLA Lab

Core Concepts

Identity and Equality

Identity equality ‘=’ same OID identical

value equality ‘==’ values of all their attributes are recursively equal equal

Shallow equality values of all their attributes are equal

12OOPSLA Lab

Core Concepts

Approaches to the Construction of the OIDs

ORION OID consists of a pair (class ID, instance ID) object migration is difficult

Smalltalk, Iris class ID is stored as object information in the object in the case of invalid operation, unnecessary disk access

Visibility of OIDs outside the DBMS most systems don’t allow the user’s access to the OID GemStone, O2 allow the user to assign name to object

13OOPSLA Lab

Core Concepts

Complex Object

Both primitive and non-primitive objects can be values of other object’s attributes

Built by applying constructors to simpler objects Minimal set of constructors

set for real world collection, multi-valued attributes bag for set with duplicates list or array for ordering on elements of set tuple for properties of an entity

14OOPSLA Lab

이름 : 송용준

생년월일 : 년 : 1969월 : 12일 : 8

출신학교 :

이름 : 서울대학교주소 : 서울 관악구 신림동 산 56-1총장 :

이름 : …생년월일 :

15OOPSLA Lab

Core Concepts

Approaches to the Constructions of Complex Object

When the value of an attributes of an object O is non-primitive object O’ to store the ID of O’ in O => further disk access whole complex value of O’ is stored in O => more

complicated data model

16OOPSLA Lab

Core Concepts

Types and Classes

Some make distinction between type and class in Pool, type and class in Emerald, abstract data types and implementation type by Bertino, abstract class and implementation class in GemStone, O2, class and set or bag for extent in ORION, only class in ENCORE, type for interface specification and implementation, and

class for extent

Concepts of extent of type in OODB model type, the specification of a set of objects class, the structure and implementation of a set of objects collection of objects, the concept of the extent of a type

17OOPSLA Lab

Core Concepts

Subtype Definition Ensure the property of substitutability A type C is a subtype of a type P if:

the properties of P are subset of those of C for each method mp of P, there is corresponding method mc of C,

such that• mp and mc have the same name• mp and mc have the same number of arguments• the i-th argument type of mp is a subtype of the i-th argument type of mc• Both mp and mc have a result, or neither of the two have a result• the type of result of mc, if any, is a subtype of the type of the result of mp

A type can be implemented by several classes as long as each class is the subtype of the type

18OOPSLA Lab

Core Concepts

Classes and Mechanisms of Instantiation

Same definition to generate objects with the same structure and behavior => reusability

Class specifies a structure which is the set of attributes of the instances a set of operations and a set of methods

Object is generated by new operation to class-object generating a new object from another existing object,

Most OO data models restrict an object to be an instance of a single class

19OOPSLA Lab

Core Concepts

Aggregation Hierarchy

Domain of attribute specifies the classes of the possible objects as values to that attribute

An attribute of a class C has a class C’ as a domain -> aggregation relationship

An attribute of a class C’ can have a class C” as a domain -> aggregation hierarchy

Classes can be defined recursively

20OOPSLA Lab

Core Concepts

Migration of Instances Between Classes

Object can modify its own attributes and operations with the same OID => migration

Problem concerning semantic integrity the value of an attribute A of an object O is object O’ O' changes class which is no longer compatible with

the class domain of A

Solutions to this problem inserting flag in O' to indicate the migration codes in application to manage such exceptions

21OOPSLA Lab

Core Concepts

Approaches to Persistence of Object

Implicit approach the creation of an instance makes it persistent implicitly

Explicit approach to associate a user-name to the instance to insert the instance in a persistent set of objects to provide a special operation to make object persistent

Intermediate approach both persistent classes and temporary classes

22OOPSLA Lab

Two Ways of Deleting Object

Explicit deletion delete operation the problem of integrity of references

• reference count solution => very costly solution

• free deletion with exception handling solution => OID of the deleted object can't be reused

implicit deletion a persistent object is cancelled only if all external

names and references are removed

Core Concepts

23OOPSLA Lab

Core Concepts

Meta-class

Class is an object in itself - namely class-object - which contains attributes and the methods within the class class attributes and class methods

Meta-class in the sense of the class of a class meta-class is also an object, so it is the instance of another

meta-class on higher level, and so on. Only some systems provide meta-class in part Purposes of meta-class

simplification of the management of classes uniform application of the OO paradigm to classes

24OOPSLA Lab

Core Concepts

Inheritance

Subclass can be defined on the basis of superclass subclass inherits the attributes, methods and messages

of its superclass with its own specific definition explicitly being defined is prior to those of inherited Instances of a class are also members of its superclass

Advantages of inheritance reusability precise and concise description of the real world

Inheritance hierarchy can’t have cycles

25OOPSLA Lab

Examples of Inheritance Hierarchy

Core Concepts

26OOPSLA Lab

Core Concepts

Different Concept of Inheritance

Specification hierarchy (= subtype hierarchy) consistency between the specification of types subtyping relationships which mean substitutability

Implementation hierarchy code sharing between types (or classes) not necessarily coincide with the specification hierarchy

Classification hierarchy collections of objects and their inclusion relationships by enumeration or by a set of predicates

27OOPSLA Lab

Set

Bag

Set_by_List

Bag_by_List

Set_by_Array

Bag_by_Array

(a) Specification Hierarchy (b) Implementation Hierarchy

100150

140

2 3

30

50

7080

90

Set_A Set_BSet_C

Set_D

Set_A

Set_B

Set_C

Set_D

(c) Classification Hierarchy

28OOPSLA Lab

Multiple Inheritance

A class can have two or more superclasses Pros

more reusable more realistic

Cons complex to implement conflict problem when some superclasses have an

attribute or methods with same name• the most specific domain

• on the basis of an order of precedence

29OOPSLA Lab

Core Concepts

Inheritance and Encapsulation

Q : Whether must the structure of a class be encapsulated even to the subclasses?

Modification to the structure of any superclass can invalidate a method defined in any subclass

Current OODBMS do not yet supply any mechanism for avoiding this type of problems

Another encapsulation violation

30OOPSLA Lab

Overriding, Overloading and Late Binding

Overriding redefinition of the method for each subclasses

Overloading ( polymorphism) same naming of operation for various objects

ex) circle display

rectangle display

Late binding (= dynamic binding) decide the methods to be executed at run time

• ex1) for x in X do x display; // unknown object

• ex2) c1 + c2; // message passing

Core Concepts

31OOPSLA Lab

A Database Schema Example

32OOPSLA Lab

Comparisons with Semantic Data Model

E-R data model, DAPLEX(functional model) Aggregation, instance-of relationship More expressive power than OO data model No concept of methods Structural abstraction in this model while

behavioral abstraction in core OO data model

Core Concepts

33OOPSLA Lab

Core Concepts

Comparisons with Network andHierarchical Data Models

Similarity data nesting pointer in these models and OID in OO model

Pointer OID

physical pointer logical pointer

unusable for checking referential integrity lack of reusability

Difference expressive power and the simplicity of data

manipulation of OO data model are better

34OOPSLA Lab

Comparisons with Extensible Data Models

Approaches to extensible data model building a DBMS with the functional extension building a new DBMS with the component library

Physical or architectural extensibility in this model while logical extensibility in OO data model

Core Concepts

35OOPSLA Lab

Comparisons with Relational Data Models

Only atomic value for attributes Separation of operations from data No inheritance Only value identity Nested-relational model as extension of this model

Core Concepts

36OOPSLA Lab

Core Concepts

Criticisms of the Object-Oriented Data Model

Navigational model is a step backwards! navigation is essential in some App. such as CAD, AI nested structure is only one aspect of the OO model

No coherent mathematical theory! useful in a very limited number of components

Many drawbacks in current OODBMS! due to lack of established technology

Using OODBMS is difficult! for model's effective complexity

37OOPSLA Lab

Semantic Extensions

Composite Object Associations Integrity Constraints

38OOPSLA Lab

Composite Object

Aggregation relationship = is-refer-to relationship ex) a company object in an employer object

Part-of semantics onto aggregation relationships ex) an engine object in a car object

Set of objects constitutes a logical entity a unit of locking, authorization and physical clustering

ORION support this concept

Semantic Extensions

39OOPSLA Lab

Semantic Extensions

Composite Object Model in ORION

Weak reference is a normal one with no semantics Composite references

exclusive or shared dependent or independent

4 types of composite reference ex) exclusive dependent composite reference, ...

Specific operations and predicates for composite objects can be defined ex) for a given object O, find component objects of O

40OOPSLA Lab

Semantic Extensions

Associations

A link between entities in applications ex1) an association between a person and his employer ex2) an association between a product, a supplier, and a

customer

Characterized by degree which is the number of entities in the association cardinality constraints which is the minimum and the

maximum entity number within association own attributes

41OOPSLA Lab

Associations in OO Data Model

Represented by means of references, but difficulty of representing

• ternary associations

• associations which have their own attributes

traversal only in one direction => reverse reference

Q : Why association has not implemented? increases the complexity of implementation reduces the performance difficult for user to design the database anyhow represented by means of basic model

42OOPSLA Lab

Personname:STRING

surname:STRINGemployer

address:STRINGdate_of_birth:DATE

Employercompany_name:STRINGsoc_security_no:STRING

address:STRING

(a). Representation of a binary association

Ordercustomersupplierproduct

quantity:INTEGER

Customername:STRING

address:STRINGbalance:INTEGER

Suppliercompany_name:STRING

address:STRING

Productcode:STRING

description:STRING

(b). Representation of a ternary association

43OOPSLA Lab

Semantic Extensions

Integrity Constraints

Ensure the correctness and consistency of data static constraint related to the states of objects dynamic constraint related to the state transitions of the

objects

Common types of constraints domain constraints key constraints referential integrity constraints

44OOPSLA Lab

Integrity Constraints in OODBMS

Constraints peculiar to the OODBMS constraints on the migration of objects exclusivity constraints between extents of classes constraints on the definitions of subclasses

Most OODBMS encodes integrity constraints as part of update methods

45OOPSLA Lab

The GemStone Data Model

Overview Object Class Definition Methods Inheritance Persistence

46OOPSLA Lab


GemStone OODBMS Overview

In 1987 by Servio Corp (USA) Smalltalk OOPL concepts + functions of a DBMS OPAL derived from Smalltalk is DDL and DML Version 2.0 of GemStone http://www.gemstone.com

47OOPSLA Lab

Object

CDO(Class Defining Object) contains the methods and structure common to all instances of a class

Each object contains a reference to its CDO as part of OID is the instance of only one class

Basic storage formats for object organization atomic named instance variables indexable instance variables (array) anonymous instance variables (set)

48OOPSLA Lab

Class Definition

Kernel classes are a number of predefined classes Object class is the root of the inheritance hierarchy

• each class has to be in inheritance hierarchy class extent is defined as the subclass of Set class

Syntax for defining a class in OPAL Superclass_name subclass 'Name-subclass'

instVarNames: ListofInstanceVariablesclassVars: ListofClassVariablespoolDictionaries: ListofCommonVaraiblesinDictionary: DictionaryNameconstraints: ListofDomainConstraintsintancesInvariant: False/TrueisModifiable: False/True


49OOPSLA Lab

An Example of Class Definitions(1)

Object subclass 'Document'instVarNames: #('acronym_document','name','classification')classVars: #()poolDictionaries: #()inDictionary: UserGlobalsconstraints: #[ #[ #acronym_document, String], #[ #name, String], #[ #classification, String]]isntanceInvariant: FalseisModifiable: False.

Two types of array literal array #(‘literal’, , ) array constructor #[expression, , ]


50OOPSLA Lab

An Example of Class Definitions(2) Set subclass 'Documents'

instVarNames: #()classVars: #()poolDictionaries: #()inDictionary: UserGlobalsconstraints: DocumentisntanceInvariant: FalseisModifiable: False.

Document subclass 'Technical_report'instVarNames:#('topics','start_validity','end_validity','amendment_to')classVars: #()poolDictionaries: #()inDictionary: UserGlobalsconstraints: #[ #[ #topics, String], #[ #start_validity, Date],

#[ #end_validity, Date]]isntanceInvariant: FalseisModifiable: True.


51OOPSLA Lab

Domain Constraint

Not necessarily be specified Class used as domain must be defined previously Q : How to define recursive class?

define modifiable class as seen in Technical_report send message to the class to add a domain constraint

Technical_report instVar: 'amendment_to’ constraintTo:Technical_report.

make the class non-modifiable Technical_report immediateInvariant.


52OOPSLA Lab


Message

Message consists of an OID or an expression representing the object one or more identifiers for methods, called selectors possibly one or more arguments

Message classification unary messages ex) 7 negated binary messages ex) myObject = yourObject keyed messages ex) arrayOfStrings at:(2+1) put:'Curly'

Cascade message is a sequence of messages separated by ';' sent to the same object.

53OOPSLA Lab

Method

Specification of a method consist of message pattern, which represents the signature of the

method body declarations of temporary variables

• one or more OPAL expressions

• a return command

Attributes can’t be accessed by class methods but only by methods of the object


54OOPSLA Lab

An Example of Method Definitions method: Document 'unary method in Document'

title 'message pattern’^title 'return statement'

% 'end of method' classmethod: Document

newAcronym: anAcronym newTitle: aTitlenewClassif: aClassif

| tempDocument |tempDocument := self new.tempDocument acronym: anAcronym; title: aTitle;

classification: aClassif;^tempDocument%


55OOPSLA Lab


Inheritance

Single inheritance mechanism Modifications to the inherited definitions, which

can be done only more restrictively adding attributes

• not applicable to subclasses of Set class

adding and redefining methods class attributes, global variables

Refining methods via super pseudo-variable

56OOPSLA Lab


Persistence

Making an object persistent associate an external name with the object

ex) UserGlobals at: #MyDocument put: newDoc make a set persistent => all instances of the set are

persistent Deleting persistent objects

no explicit delete operation only objects with no references can be deleted remove the external name to the object ex) MyDocuments remove: MyDocument. UserGlobal at: #MyDocument put: nil.

57OOPSLA Lab

The O2 Data Model

Overview Objects and Values Types and Classes Inheritance Persistence Exceptional Attributes and Methods

58OOPSLA Lab

O2 OODBMS Overview

By Altair project 5 year project ( 3 for design + 2 for development) to design and implement the next generation DBMS

Data model defined from ‘ex-novo’ CO2

language for implementing methods an extension of the C

O2, Version 1.0

http://www.o2.com

59OOPSLA Lab

The O2 Data Model

Objects and Values

Objects identity independent of the value encapsulation of data and operations

Complex values defined by constructors

• ex) date tuple(day: 1, month: 03, year: 1996) nested arbitrarily

Differences between objects and complex values Object Complex value(ID, value) only valuesmethods system provided operatorssharable non-sharable

60OOPSLA Lab

The O2 Data Model

Types and Classes

Type describes the structure of a set of objects Type forms

atomic types ex) integer, char, boolean, string, float, bitmap structured types defined by tuple, set, and list constructor classes

Class describes a group of objects with similar structure and behavior system unique name of the class specification of the class type a set of methods

61OOPSLA Lab

Class Definition

Syntax : add class Class_name

inherits ListofClassNamestype TypeStructurepublic AccessAttributesSpecificationmethod ListofmethodSignatures

Object class is the root of class hierarchy Class extent can be defined from set type

The O2 Data Model

62OOPSLA Lab

Class Definition (Cont’d)

No class attributes and class methods values with name are similar to global variables

ex) add name average_salary: integer;

specific system procedures for classes such as new

Definition of recursive classes a class can be defined which have as a domain one or

more attributes of classes which have yet to be defined shadow class

• some restrictions including that it can’t be initialized

63OOPSLA Lab

An Example of Class Definitions

add class Documenttype tuple(acronym_document: string, title: string,

classification: string)public write acronym_document, write title;

add class Technical_Reportinherits Documenttype tuple(argument: string, start_validity: Date

end_validity: Date, amendment_to: Technical_Report);

add class Documentstype set(Document);

The O2 Data Model

64OOPSLA Lab

Methods

Definition of a method consists of signature

• method's name ( argument’s name: type, ... ) : result’s type• specified at class definition or added later

body • set of commands by expressed CO2, extensions of BASIC, LISP• always defined separately from the class definition • syntax : body method_signature co2 {

setofCommands return(result) }$;

Invocation of a method [ receiver method_name ] [ receiver method_name (arguments) ]

The O2 Data Model

65OOPSLA Lab

An Example of Method

body init(acronym_doc: string, tit:string, classif: string):Document in class Document co2 { self->acronym_document = acronym_doc; self->title = tit; self->classification = classif; Documents += set(self); return(self); }$; Execution of a sequence of CO2 instructions

execute co2 { o2 Document tmp; tmp = new(Document); [tmp init('C1/27/03/96', 'Databases', 'Draft')]; }$;

The O2 Data Model

66OOPSLA Lab

The O2 Data Model

Inheritance

Multiple inheritance Type compatibility, which T is a subtype of T' if

T = tuple(A,...) : for each T' attribute A, T has same name attribute with same type or subtype type of T’

T = set(E), T’ = set(E') : E=E' or subtype of E' T = list(E), T’ = list(E') : E=E' or subtype of E'

Overriding as long as both types are compatible ‘redefines’ keyword for overriding

ex) add class Employee inherits Person

type tuple ( redefines telephone : tuple ( … ), ... );

67OOPSLA Lab

The O2 Data Model

Method inheritance

Both the signature and the body can be redefined compatibility conditions on signatures

• same number of arguments• each argument type in subclass is subtype of that in superclass• result type in subclass is subtype with that in superclass

no control on the arguments substitutability condition Inherited method can be refined using qualifier @

ex) [self Document @ init(acronym_doc, tit, classif)];

Specify the wanted method using from message to solve conflicts from multiple inheritance to inherit the indirect superclass' method

68OOPSLA Lab

Persistence

Objects are made persistent by inserting them in a persistent set making them as part of persistent object assigning them an external name

ex) add name MyDocument : Document;

Deleting persistent objects no explicit delete operation only objects with no references can be deleted remove the external name using delete name instruction

ex) delete name MyDocument;

The O2 Data Model

69OOPSLA Lab

Exceptional Attributes and Methods

In the core OO data model all instances of a class has the same attributes and

methods!

In the case of instances with name can have attributes and methods in addition to those

inherited from actual class can redefine the body of inherited methods

ex) add method count_word() : integer in name MyDocument;

The O2 Data Model

70OOPSLA Lab

The Iris Data Model

Overview Type Function Inheritance Persistence

71OOPSLA Lab

IRIS Extended Functional DBMS

In 1984 by Hewlett-Packard Origins in semantic model Principal concepts

objects : instances, arguments, results types : collections of objects with name functions : attributes, associations, operations

Multiple inheritance Object migration

72OOPSLA Lab

The Iris Data Model

Type Definition

Syntax for the definition of type CREATE TYPE type-name [SUBTYPE OF type-name-commalist]

[PROPERTIES ( function-commalist )]

[AS FORWARD | STORED | CLUSTERED ];

Properties(attributes) are defined by functions syntax

[ KEY | NONKEY ] function-name res-type-name

[ KEY | NONKEY ] [ AS FORWARD | STORED | CLUSTERD ];

73OOPSLA Lab

Type Definition (Cont’d)

An Example CREATE TYPE Person

PROPERTIES ( KEY name Charstring NONKEY,

KEY car Vehicle KEY,

NONKEY activity Work NONKEY);

No class attributes and no class methods

74OOPSLA Lab

The Iris Data Model

Functions

Functions defined in types represent properties of the objects belonging to the type associations between objects

• parent association from the Person type objects

• belongs to association between Person and Vehicle objects

operations to change the objects’ internal state

Methods to define functions in the PROPERTIES clause

• only for property functions with one argument

CREATE FUNCTION instruction

75OOPSLA Lab

The Iris Data Model

Create Function Instruction

Create Function specifies the function signature defines functions with several arguments and/or a result CREATE FUNCTION func-interface [ implementation ]

func-interface ::= function-name arg-spec -> res-specimplementation ::= AS [function-body | FORWARD | STORED]function-body ::= OSQL-body | foreign-bodyOSQL-body ::= select-expression | procedure-bodyforeign-body ::= LINK file-name

Function implementation can be specified in Iris query language - OSQL

• within CREATE FUNCTION instruction• using IMPLEMENT FUNCTION instruction

file which contains codes in P/L using LINK clause

76OOPSLA Lab

The Iris Data Model

Procedures

User-defined functions which can modify objects ADD, REMOVE and SET instructions result type is ‘Boolean’ target objects are passed as argument

ex) CREATE FUNCTION init(document d, string acronym_doc,

string tit, string classif) -> Boolean AS begin set acronym_document(d) = acronym_doc; set title(d) = tit; set classification(d) = classif;

end;

77OOPSLA Lab

Inheritance

Multiple inheritance no automatic conflict solving mechanisms user can’t define the types which result in conflicts

Overriding for functions inherited

Early binding choice of implementation for function not by the object

but by the declaration of the type of the variable

78OOPSLA Lab

The Iris Data Model

Persistence

Each object is automatically persistent A object is deleted explicitly

DELETE OBJECT instruction

Object can belong to several types simultaneously ADD TYPE instruction REMOVE TYPE instruction every objects is an instance of the UserTypeObject

system type

79OOPSLA Lab

Comparisons among GemStone, O2, Iris, ORION

Summary

GemStone O2 Iris OrionClass extent NO NO YES YESPersistence Root Root Auto Auto

Deletion of instances NO NO YES YESDirect access to

attributesNO On

requestYES YES

Obligation to specifyattributes’ domain

Only insome cases

YES YES YES

Composite object NO NO NO YESClass attributes and

class methodsYES NO NO YES

Exceptional instances NO YES NO NOIntegrity constraints NO NO NO NO

Associations NO NO YES NOMultiple inheritance NO YES YES YES

Object migration NO NO YES NO

Chapter 2. Object-Oriented Data Model

Documents

Transcript of Chapter 2. Object-Oriented Data Model