Upload
alex-lovering
View
215
Download
0
Embed Size (px)
Citation preview
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
The GemStone Data Model
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
The GemStone Data Model
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, , ]
The GemStone Data Model
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.
The GemStone Data Model
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.
The GemStone Data Model
52OOPSLA Lab
The GemStone Data Model
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
The GemStone Data Model
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%
The GemStone Data Model
55OOPSLA Lab
The GemStone Data Model
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
The GemStone Data Model
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