1 / 79

Chapter 2. Object-Oriented Data Model

Chapter 2. Object-Oriented Data Model. Seoul National University Department. of Computer Engineering OOPSLA Lab. CONTENTS. Core Concepts Semantic Extensions The GemStone Data Model The O2 Data Model The Iris Data Model Summary. Core Concepts. Core Concepts. Objects and identity

royal
Download Presentation

Chapter 2. Object-Oriented Data Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 2. Object-Oriented Data Model Seoul National University Department. of Computer Engineering OOPSLA Lab

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

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

  4. Core Concepts 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

  5. 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

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

  7. 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

  8. 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

  9. 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

  10. Core Concepts 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 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

  11. 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

  12. 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

  13. 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

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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. Core Concepts 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

  23. 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

  24. 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 havecycles

  25. Core Concepts Examples of Inheritance Hierarchy

  26. 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

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

  28. 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

  29. 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

  30. Core Concepts Overriding, Overloading and Late Binding • Overriding • redefinition of the method for each subclasses • Overloading ( polymorphism) • same naming of operation for various objects ex) circledisplay rectangledisplay • Late binding (= dynamic binding) • decide the methods to be executed at run time • ex1) forxin X dox display; // unknown object • ex2) c1 + c2; // message passing

  31. A Database Schema Example

  32. Core Concepts 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

  33. 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

  34. Core Concepts 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

  35. Core Concepts 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

  36. 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

  37. Semantic Extensions • Composite Object • Associations • Integrity Constraints

  38. Semantic Extensions 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

  39. 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

  40. 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 • cardinalityconstraints which is the minimum and the maximum entity number within association • own attributes

  41. 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

  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 Customer name:STRING address:STRING balance:INTEGER Order customer supplier product quantity:INTEGER Supplier company_name:STRING address:STRING Product code:STRING description:STRING (b). Representation of a ternary association

  43. 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

  44. 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

  45. The GemStone Data Model • Overview • Object • Class Definition • Methods • Inheritance • Persistence

  46. 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

  47. 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)

  48. The GemStone Data Model 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: ListofInstanceVariables classVars: ListofClassVariables poolDictionaries: ListofCommonVaraibles inDictionary: DictionaryName constraints: ListofDomainConstraints intancesInvariant: False/True isModifiable: False/True

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

  50. The GemStone Data Model An Example of Class Definitions(2) • Set subclass 'Documents' instVarNames: #() classVars: #() poolDictionaries: #() inDictionary: UserGlobals constraints: Document isntanceInvariant: False isModifiable: False. • 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.

More Related