1. E.Bertino, L.Matino Object-Oriented Database Systems 1 Chapter 2. Object-Oriented Data Model Seoul National University Department. of Computer Engineering OOPSLA Lab

2. 2 CONTENTS 4 Core Concepts 4 Semantic Extensions 4 The GemStone Data Model 4 The O2 Data Model 4 The Iris Data Model 4 Summary

3. OOPSLA Lab 3 Core Concepts 4 Objects and identity 4 Complex objects 4 Encapsulation 4 Classes 4 Inheritance 4 Overloading, overriding, and late binding 4 Comparison OO data model with other models Core Concepts

4. OOPSLA Lab 4 Value vs. Object 4 What’s value? 3 self-identifying 3 primitive entities 3 complex values, which can’t be shared(O2) 4 What’s object? 3 object represents real world entity 3 object = state(or data) + behavior(or operation) values of attributes to represent state methods to define the behavior of object 3 each object is identified by a unique OID Core Concepts

5. OOPSLA Lab 5 Core Concepts Methods 4 With methods, objects are manipulated 4 Definition of a method consists of 3 signature for the specification of the method (method’s name, arguments’ (class, name), result’s class) ORION, Smalltalk don’t require the argument class 3 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

6. OOPSLA Lab 6 Object1 M4 M1 M2 M3 Object2 M3 M2 M1 M4 Object3 M3 M4 M1 M2 message1 message2 message3

7. OOPSLA Lab 7 Core Concepts Encapsulation 4 Object is accessed only by method which is evoked by message to the object 4 Distinction between the specification and implementation => modularity 4 In P/L, object consists of 3 interface which is the specification of the set of operations 3 implementation which contains the structure of the object and the methods

8. OOPSLA Lab 8 Encapsulation (Cont’d) 4 In OODB, object consists of data and operations 4 Whether the structure is part of the interface or not is unclear 4 Logical data independence 3 implementation of objects can be modified, while the applications remain unchanged 4 Valid violation of the encapsulation 3 direct accessing attributes in query processing

9. OOPSLA Lab 9 Core Concepts Violation of Encapsulation Principle 4 Advantages of violating the encapsulation 3 the programmer’s burden is decreased 3 system-provided operations increases the efficiency 4 Handling the violation of encapsulation principle 3 in Vbase/Ontos, system-defined methods for reading and writing the attributes 3 in O2, C++, users can state which attributes and methods are visible(public) 3 in ORION, all attributes and methods are visible while authorization mechanisms to control the access to them

10. OOPSLA Lab 10 Core Concepts Key OID value of one or more attributes independent from state of object modifiable non-modifiable same if both have same values different even if both have same state unique within a relation unique within entire database OID and Key 4 OID vs. Key 4 Advantages of OID over Key 3 implemented not by programmer but by the system 3 better performance due to low level by the system 3 no artificial code which is necessary in longer external keys

11. OOPSLA Lab 11 Core Concepts Identity and Equality 4 Identity equality ‘=’ 3 same OID 3 identical 4 value equality ‘==’ 3 values of all their attributes are recursively equal 3 equal 4 Shallow equality 3 values of all their attributes are equal

12. OOPSLA Lab 12 Core Concepts Approaches to the Construction of the OIDs 4 ORION 3 OID consists of a pair (class ID, instance ID) 3 object migration is difficult 4 Smalltalk, Iris 3 class ID is stored as object information in the object 3 in the case of invalid operation, unnecessary disk access 4 Visibility of OIDs outside the DBMS 3 most systems don’t allow the user’s access to the OID 3 GemStone, O2 allow the user to assign name to object

13. OOPSLA Lab 13 Core Concepts Complex Object 4 Both primitive and non-primitive objects can be values of other object’s attributes 4 Built by applying constructors to simpler objects 4 Minimal set of constructors 3 set for real world collection, multi-valued attributes 3 bag for set with duplicates 3 list or array for ordering on elements of set 3 tuple for properties of an entity

14. OOPSLA Lab 14 이름 : 송용준 생년월일 : 년 : 1969 월 : 12 일 : 8 출신학교 : 이름 : 서울대학교 주소 : 서울 관악구 신림동 산 56-1 총장 : 이름 : … 생년월일 :

15. OOPSLA Lab 15 Core Concepts Approaches to the Constructions of Complex Object 4 When the value of an attributes of an object O is non-primitive object O’ 3 to store the ID of O’ in O => further disk access 3 whole complex value of O’ is stored in O => more complicated data model

16. OOPSLA Lab 16 Core Concepts Types and Classes 4 Some make distinction between type and class 3 in Pool, type and class 3 in Emerald, abstract data types and implementation type 3 by Bertino, abstract class and implementation class 3 in GemStone, O2, class and set or bag for extent 3 in ORION, only class 3 in ENCORE, type for interface specification and implementation, and class for extent 4 Concepts of extent of type in OODB model 3 type, the specification of a set of objects 3 class, the structure and implementation of a set of objects 3 collection of objects, the concept of the extent of a type

17. OOPSLA Lab 17 Core Concepts Subtype Definition 4 Ensure the property of substitutability 4 A type C is a subtype of a type P if: 3 the properties of P are subset of those of C 3 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 4 A type can be implemented by several classes as long as each class is the subtype of the type

18. OOPSLA Lab 18 Core Concepts Classes and Mechanisms of Instantiation 4 Same definition to generate objects with the same structure and behavior => reusability 4 Class specifies 3 a structure which is the set of attributes of the instances 3 a set of operations and a set of methods 4 Object is generated by 3 new operation to class-object 3 generating a new object from another existing object, 4 Most OO data models restrict an object to be an instance of a single class

19. OOPSLA Lab 19 Core Concepts Aggregation Hierarchy 4 Domain of attribute specifies the classes of the possible objects as values to that attribute 4 An attribute of a class C has a class C’ as a domain -> aggregation relationship 4 An attribute of a class C’ can have a class C” as a domain -> aggregation hierarchy 4 Classes can be defined recursively

20. OOPSLA Lab 20 Core Concepts Migration of Instances Between Classes 4 Object can modify its own attributes and operations with the same OID => migration 4 Problem concerning semantic integrity 3 the value of an attribute A of an object O is object O’ 3 O' changes class which is no longer compatible with the class domain of A 4 Solutions to this problem 3 inserting flag in O' to indicate the migration 3 codes in application to manage such exceptions

21. OOPSLA Lab 21 Core Concepts Approaches to Persistence of Object 4 Implicit approach 3 the creation of an instance makes it persistent implicitly 4 Explicit approach 3 to associate a user-name to the instance 3 to insert the instance in a persistent set of objects 3 to provide a special operation to make object persistent 4 Intermediate approach 3 both persistent classes and temporary classes

22. OOPSLA Lab 22 Two Ways of Deleting Object 4 Explicit deletion 3 delete operation 3 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 4 implicit deletion 3 a persistent object is cancelled only if all external names and references are removed Core Concepts

23. OOPSLA Lab 23 Core Concepts Meta-class 4 Class is an object in itself - namely class-object - which contains 3 attributes and the methods within the class 3 class attributes and class methods 4 Meta-class in the sense of the class of a class 3 meta-class is also an object, so it is the instance of another meta-class on higher level, and so on. 4 Only some systems provide meta-class in part 4 Purposes of meta-class 3 simplification of the management of classes 3 uniform application of the OO paradigm to classes

24. OOPSLA Lab 24 Core Concepts Inheritance 4 Subclass can be defined on the basis of superclass 3 subclass inherits the attributes, methods and messages of its superclass with its own specific definition 3 explicitly being defined is prior to those of inherited 3 Instances of a class are also members of its superclass 4 Advantages of inheritance 3 reusability 3 precise and concise description of the real world 4 Inheritance hierarchy can’t have cycles

25. OOPSLA Lab 25 Examples of Inheritance Hierarchy Core Concepts

26. OOPSLA Lab 26 Core Concepts Different Concept of Inheritance 4 Specification hierarchy (= subtype hierarchy) 3 consistency between the specification of types 3 subtyping relationships which mean substitutability 4 Implementation hierarchy 3 code sharing between types (or classes) 3 not necessarily coincide with the specification hierarchy 4 Classification hierarchy 3 collections of objects and their inclusion relationships 3 by enumeration or by a set of predicates

27. OOPSLA Lab 27 Set Bag Set_by_List Bag_by_List Set_by_Array Bag_by_Array (a) Specification Hierarchy(b) Implementation Hierarchy 100 150 140 2 3 30 50 70 80 90 Set_A Set_B Set_C Set_D Set_A Set_B Set_C Set_D (c) Classification Hierarchy

28. OOPSLA Lab 28 Multiple Inheritance 4 A class can have two or more superclasses 4 Pros 3 more reusable 3 more realistic 4 Cons 3 complex to implement 3 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

29. OOPSLA Lab 29 Core Concepts Inheritance and Encapsulation 4 Q : Whether must the structure of a class be encapsulated even to the subclasses? 4 Modification to the structure of any superclass can invalidate a method defined in any subclass 4 Current OODBMS do not yet supply any mechanism for avoiding this type of problems 4 Another encapsulation violation

30. OOPSLA Lab 30 Overriding, Overloading and Late Binding 4 Overriding 3 redefinition of the method for each subclasses 4 Overloading (  polymorphism) 3 same naming of operation for various objects ex) circle display rectangle display 4 Late binding (= dynamic binding) 3 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

31. OOPSLA Lab 31 A Database Schema Example

32. OOPSLA Lab 32 Comparisons with Semantic Data Model 4 E-R data model, DAPLEX(functional model) 4 Aggregation, instance-of relationship 4 More expressive power than OO data model 4 No concept of methods 4 Structural abstraction in this model while behavioral abstraction in core OO data model Core Concepts

33. OOPSLA Lab 33 Core Concepts Comparisons with Network and Hierarchical Data Models 4 Similarity 3 data nesting 3 pointer in these models and OID in OO model Pointer OID physical pointer logical pointer unusable for checking referential integrity lack of reusability 4 Difference 3 expressive power and the simplicity of data manipulation of OO data model are better

34. OOPSLA Lab 34 Comparisons with Extensible Data Models 4 Approaches to extensible data model 3 building a DBMS with the functional extension 3 building a new DBMS with the component library 4 Physical or architectural extensibility in this model while logical extensibility in OO data model Core Concepts

35. OOPSLA Lab 35 Comparisons with Relational Data Models 4 Only atomic value for attributes 4 Separation of operations from data 4 No inheritance 4 Only value identity 4 Nested-relational model as extension of this model Core Concepts

36. OOPSLA Lab 36 Core Concepts Criticisms of the Object-Oriented Data Model 4 Navigational model is a step backwards! 3 navigation is essential in some App. such as CAD, AI 3 nested structure is only one aspect of the OO model 4 No coherent mathematical theory! 3 useful in a very limited number of components 4 Many drawbacks in current OODBMS! 3 due to lack of established technology 4 Using OODBMS is difficult! 3 for model's effective complexity

37. OOPSLA Lab 37 Semantic Extensions 4 Composite Object 4 Associations 4 Integrity Constraints

38. OOPSLA Lab 38 Composite Object 4 Aggregation relationship = is-refer-to relationship 3 ex) a company object in an employer object 4 Part-of semantics onto aggregation relationships 3 ex) an engine object in a car object 4 Set of objects constitutes a logical entity 3 a unit of locking, authorization and physical clustering 4 ORION support this concept Semantic Extensions

39. OOPSLA Lab 39 Semantic Extensions Composite Object Model in ORION 4 Weak reference is a normal one with no semantics 4 Composite references 3 exclusive or shared 3 dependent or independent 4 4 types of composite reference 3 ex) exclusive dependent composite reference,... 4 Specific operations and predicates for composite objects can be defined 3 ex) for a given object O, find component objects of O

40. OOPSLA Lab 40 Semantic Extensions Associations 4 A link between entities in applications 3 ex1) an association between a person and his employer 3 ex2) an association between a product, a supplier, and a customer 4 Characterized by 3 degree which is the number of entities in the association 3 cardinality constraints which is the minimum and the maximum entity number within association 3 own attributes

41. OOPSLA Lab 41 Associations in OO Data Model 4 Represented by means of references, but 3 difficulty of representing ternary associations associations which have their own attributes 3 traversal only in one direction => reverse reference 4 Q : Why association has not implemented? 3 increases the complexity of implementation 3 reduces the performance 3 difficult for user to design the database 3 anyhow represented by means of basic model

42. OOPSLA Lab 42 Person name:STRING surname:STRING employer address:STRING date_of_birth:DATE Employer company_name:STRING soc_security_no:STRING address:STRING (a). Representation of a binary association Order customer supplier product quantity:INTEGER Customer name:STRING address:STRING balance:INTEGER Supplier company_name:STRING address:STRING Product code:STRING description:STRING (b). Representation of a ternary association

43. OOPSLA Lab 43 Semantic Extensions Integrity Constraints 4 Ensure the correctness and consistency of data 3 static constraint related to the states of objects 3 dynamic constraint related to the state transitions of the objects 4 Common types of constraints 3 domain constraints 3 key constraints 3 referential integrity constraints

44. OOPSLA Lab 44 Integrity Constraints in OODBMS 4 Constraints peculiar to the OODBMS 3 constraints on the migration of objects 3 exclusivity constraints between extents of classes 3 constraints on the definitions of subclasses 4 Most OODBMS encodes integrity constraints as part of update methods

45. OOPSLA Lab 45 The GemStone Data Model 4 Overview 4 Object 4 Class Definition 4 Methods 4 Inheritance 4 Persistence

46. OOPSLA Lab 46 The GemStone Data Model GemStone OODBMS Overview 4 In 1987 by Servio Corp (USA) 4 Smalltalk OOPL concepts + functions of a DBMS 4 OPAL derived from Smalltalk is DDL and DML 4 Version 2.0 of GemStone 4 http://www.gemstone.com

47. OOPSLA Lab 47 Object 4 CDO(Class Defining Object) contains the methods and structure common to all instances of a class 4 Each object 3 contains a reference to its CDO as part of OID 3 is the instance of only one class 4 Basic storage formats for object organization 3 atomic 3 named instance variables 3 indexable instance variables (array) 3 anonymous instance variables (set)

48. OOPSLA Lab 48 Class Definition 4 Kernel classes are a number of predefined classes 3 Object class is the root of the inheritance hierarchy each class has to be in inheritance hierarchy 3 class extent is defined as the subclass of Set class 4 Syntax for defining a class in OPAL Superclass_name subclass 'Name-subclass' instVarNames: ListofInstanceVariables classVars: ListofClassVariables poolDictionaries: ListofCommonVaraibles inDictionary: DictionaryName constraints: ListofDomainConstraints intancesInvariant: False/True isModifiable: False/True The GemStone Data Model

49. OOPSLA Lab 49 An Example of Class Definitions(1) 4 Object subclass 'Document' instVarNames: #('acronym_document','name','classification') classVars: #() poolDictionaries: #() inDictionary: UserGlobals constraints: #[ #[ #acronym_document, String], #[ #name, String], #[ #classification, String]] isntanceInvariant: False isModifiable: False. 4 Two types of array 3 literal array #(‘literal’,, ) 3 array constructor #[expression,, ] The GemStone Data Model

50. OOPSLA Lab 50 An Example of Class Definitions(2) 4 Set subclass 'Documents' instVarNames: #() classVars: #() poolDictionaries: #() inDictionary: UserGlobals constraints: Document isntanceInvariant: False isModifiable: False. 4 Document subclass 'Technical_report' instVarNames:#('topics','start_validity','end_validity','amendment_to') classVars: #() poolDictionaries: #() inDictionary: UserGlobals constraints: #[ #[ #topics, String], #[ #start_validity, Date], #[ #end_validity, Date]] isntanceInvariant: False isModifiable: True. The GemStone Data Model

51. OOPSLA Lab 51 Domain Constraint 4 Not necessarily be specified 4 Class used as domain must be defined previously 4 Q : How to define recursive class? 3 define modifiable class as seen in Technical_report 3 send message to the class to add a domain constraint Technical_report instVar: 'amendment_to’ constraintTo:Technical_report. 3 make the class non-modifiable Technical_report immediateInvariant. The GemStone Data Model

52. OOPSLA Lab 52 The GemStone Data Model Message 4 Message consists of 3 an OID or an expression representing the object 3 one or more identifiers for methods, called selectors 3 possibly one or more arguments 4 Message classification 3 unary messages ex) 7 negated 3 binary messages ex) myObject = yourObject 3 keyed messages ex) arrayOfStrings at:(2+1) put:'Curly' 4 Cascade message is a sequence of messages separated by ';' sent to the same object.

53. OOPSLA Lab 53 Method 4 Specification of a method consist of 3 message pattern, which represents the signature of the method 3 body 3 declarations of temporary variables one or more OPAL expressions a return command 4 Attributes can’t be accessed by class methods but only by methods of the object The GemStone Data Model

54. OOPSLA Lab 54 An Example of Method Definitions 4 method: Document 'unary method in Document' title 'message pattern’ ^title 'return statement' % 'end of method' 4 classmethod: Document newAcronym: anAcronym newTitle: aTitle newClassif: aClassif | tempDocument | tempDocument := self new. tempDocument acronym: anAcronym; title: aTitle; classification: aClassif; ^tempDocument % The GemStone Data Model

55. OOPSLA Lab 55 The GemStone Data Model Inheritance 4 Single inheritance mechanism 4 Modifications to the inherited definitions, which can be done only more restrictively 3 adding attributes not applicable to subclasses of Set class 3 adding and redefining methods 3 class attributes, global variables 4 Refining methods via super pseudo-variable

56. OOPSLA Lab 56 The GemStone Data Model Persistence 4 Making an object persistent 3 associate an external name with the object ex) UserGlobals at: #MyDocument put: newDoc 3 make a set persistent => all instances of the set are persistent 4 Deleting persistent objects 3 no explicit delete operation 3 only objects with no references can be deleted 3 remove the external name to the object ex) MyDocuments remove: MyDocument. UserGlobal at: #MyDocument put: nil.

57. OOPSLA Lab 57 The O 2 Data Model 4 Overview 4 Objects and Values 4 Types and Classes 4 Inheritance 4 Persistence 4 Exceptional Attributes and Methods

58. OOPSLA Lab 58 O 2 OODBMS Overview 4 By Altair project 3 5 year project ( 3 for design + 2 for development) 3 to design and implement the next generation DBMS 4 Data model defined from ‘ex-novo’ 4 CO 2 3 language for implementing methods 3 an extension of the C 4 O 2, Version 1.0 4 http://www.o2.com

59. OOPSLA Lab 59 The O2 Data Model Objects and Values 4 Objects 3 identity independent of the value 3 encapsulation of data and operations 4 Complex values 3 defined by constructors ex) date tuple(day: 1, month: 03, year: 1996) 3 nested arbitrarily 4 Differences between objects and complex values Object Complex value (ID, value)only values methodssystem provided operators sharablenon-sharable

60. OOPSLA Lab 60 The O2 Data Model Types and Classes 4 Type describes the structure of a set of objects 4 Type forms 3 atomic types ex) integer, char, boolean, string, float, bitmap 3 structured types defined by tuple, set, and list constructor 3 classes 4 Class describes a group of objects with similar structure and behavior 3 system unique name of the class 3 specification of the class type 3 a set of methods

61. OOPSLA Lab 61 Class Definition 4 Syntax : add class Class_name inherits ListofClassNames type TypeStructure public AccessAttributesSpecification method ListofmethodSignatures 4 Object class is the root of class hierarchy 4 Class extent can be defined from set type The O2 Data Model

62. OOPSLA Lab 62 Class Definition (Cont’d) 4 No class attributes and class methods 3 values with name are similar to global variables ex) add name average_salary: integer; 3 specific system procedures for classes such as new 4 Definition of recursive classes 3 a class can be defined which have as a domain one or more attributes of classes which have yet to be defined 3 shadow class some restrictions including that it can’t be initialized

63. OOPSLA Lab 63 An Example of Class Definitions 4 add class Document type tuple(acronym_document: string, title: string, classification: string) public write acronym_document, write title; 4 add class Technical_Report inherits Document type tuple(argument: string, start_validity: Date end_validity: Date, amendment_to: Technical_Report); 4 add class Documents type set(Document); The O2 Data Model

64. OOPSLA Lab 64 Methods 4 Definition of a method consists of 3 signature method's name ( argument’s name: type,... ) : result’s type specified at class definition or added later 3 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) }$; 4 Invocation of a method 3 [ receiver method_name ] 3 [ receiver method_name (arguments) ] The O2 Data Model

65. OOPSLA Lab 65 An Example of Method 4 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); }$; 4 Execution of a sequence of CO 2 instructions execute co2 { o2 Document tmp; tmp = new(Document); [tmp init('C1/27/03/96', 'Databases', 'Draft')]; }$; The O2 Data Model

66. OOPSLA Lab 66 The O2 Data Model Inheritance 4 Multiple inheritance 4 Type compatibility, which T is a subtype of T' if 3 T = tuple(A,...) : for each T' attribute A, T has same name attribute with same type or subtype type of T’ 3 T = set(E), T’ = set(E') : E=E' or subtype of E' 3 T = list(E), T’ = list(E') : E=E' or subtype of E' 4 Overriding as long as both types are compatible 3 ‘redefines’ keyword for overriding ex) add class Employee inherits Person type tuple ( redefines telephone : tuple ( … ),... );

67. OOPSLA Lab 67 The O2 Data Model Method inheritance 4 Both the signature and the body can be redefined 3 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 3 no control on the arguments substitutability condition 4 Inherited method can be refined using qualifier @ ex) [self Document @ init(acronym_doc, tit, classif)]; 4 Specify the wanted method using from message 3 to solve conflicts from multiple inheritance 3 to inherit the indirect superclass' method

68. OOPSLA Lab 68 Persistence 4 Objects are made persistent by 3 inserting them in a persistent set 3 making them as part of persistent object 3 assigning them an external name ex) add name MyDocument : Document; 4 Deleting persistent objects 3 no explicit delete operation 3 only objects with no references can be deleted 3 remove the external name using delete name instruction ex) delete name MyDocument; The O2 Data Model

69. OOPSLA Lab 69 Exceptional Attributes and Methods 4 In the core OO data model 3 all instances of a class has the same attributes and methods! 4 In the case of instances with name 3 can have attributes and methods in addition to those inherited from actual class 3 can redefine the body of inherited methods ex) add method count_word() : integer in name MyDocument; The O2 Data Model

70. OOPSLA Lab 70 The Iris Data Model 4 Overview 4 Type 4 Function 4 Inheritance 4 Persistence

71. OOPSLA Lab 71 IRIS Extended Functional DBMS 4 In 1984 by Hewlett-Packard 4 Origins in semantic model 4 Principal concepts 3 objects : instances, arguments, results 3 types : collections of objects with name 3 functions : attributes, associations, operations 4 Multiple inheritance 4 Object migration

72. OOPSLA Lab 72 The Iris Data Model Type Definition 4 Syntax for the definition of type CREATE TYPE type-name [SUBTYPE OF type-name-commalist] [PROPERTIES ( function-commalist )] [AS FORWARD | STORED | CLUSTERED ]; 4 Properties(attributes) are defined by functions 3 syntax [ KEY | NONKEY ] function-name res-type-name [ KEY | NONKEY ] [ AS FORWARD | STORED | CLUSTERD ];

73. OOPSLA Lab 73 Type Definition (Cont’d) 4 An Example CREATE TYPE Person PROPERTIES ( KEY name Charstring NONKEY, KEY car Vehicle KEY, NONKEY activity Work NONKEY); 4 No class attributes and no class methods

74. OOPSLA Lab 74 The Iris Data Model Functions 4 Functions defined in types represent 3 properties of the objects belonging to the type 3 associations between objects parent association from the Person type objects belongs to association between Person and Vehicle objects 3 operations to change the objects’ internal state 4 Methods to define functions 3 in the PROPERTIES clause only for property functions with one argument 3 CREATE FUNCTION instruction

75. OOPSLA Lab 75 The Iris Data Model Create Function Instruction 4 Create Function specifies the function signature 3 defines functions with several arguments and/or a result 3 CREATE FUNCTION func-interface [ implementation ] func-interface ::= function-name arg-spec -> res-spec implementation ::= AS [function-body | FORWARD | STORED] function-body ::= OSQL-body | foreign-body OSQL-body ::= select-expression | procedure-body foreign-body ::= LINK file-name 4 Function implementation can be specified in 3 Iris query language - OSQL within CREATE FUNCTION instruction using IMPLEMENT FUNCTION instruction 3 file which contains codes in P/L using LINK clause

76. OOPSLA Lab 76 The Iris Data Model Procedures 4 User-defined functions which can modify objects 3 ADD, REMOVE and SET instructions 3 result type is ‘Boolean’ 3 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;

77. OOPSLA Lab 77 Inheritance 4 Multiple inheritance 3 no automatic conflict solving mechanisms 3 user can’t define the types which result in conflicts 4 Overriding 3 for functions inherited 4 Early binding 3 choice of implementation for function not by the object but by the declaration of the type of the variable

78. OOPSLA Lab 78 The Iris Data Model Persistence 4 Each object is automatically persistent 4 A object is deleted explicitly 3 DELETE OBJECT instruction 4 Object can belong to several types simultaneously 3 ADD TYPE instruction 3 REMOVE TYPE instruction 3 every objects is an instance of the UserTypeObject system type

79. OOPSLA Lab 79 Comparisons among GemStone, O 2, Iris, ORION Summary