ObjectOriented DBMSs

1
Chapter 22

• Object-Oriented DBMSs
• Transparencies

2
Chapter - Objectives

• Framework for an OODM.
• Basics of persistent programming languages.
• Main strategies for developing an OODBMS.
• Single-level v. two-level storage models.
• How an OODBMS accesses records.
• Persistent schemes.
• Advantages and disadvantages of orthogonal
  persistence.

2
3
Chapter - Objectives

• Pointer swizzling.
• Issues underlying ODBMSs.
• Advantages and disadvantages.
• OODBMS Manifesto.
• Object-oriented database design.
• Main features of ODMG Object Database Standard.

3
4
Object-Oriented Data Model

• No one agreed object data model. One definition
• Object-Oriented Data Model (OODM)
• Data model that captures semantics of objects
  supported in object-oriented programming.
• Object-Oriented Database (OODB)
• Persistent and sharable collection of objects
  defined by an ODM.
• Object-Oriented DBMS (OODBMS)
• Manager of an ODB.

4
5
Object-Oriented Data Model

• Zdonik and Maier present a threshold model that
  an OODBMS must at a minimum, satisfy
• It must provide database functionality.
• It must support object identity.
• It must provide encapsulation.
• It must support objects with complex state.

5
6
Object-Oriented Data Model

• Khoshafian and Abnous define OODBMS as
• OO ADTs Inheritance Object identity
• OODBMS OO Database capabilities.
• Parsaye et al. gives
• High-level query language with query
  optimization.
• Support for persistence, atomic transactions
  concurrency and recovery control.
• Support for complex object storage, indexes, and
  access methods.
• OODBMS OO system (1), (2), and (3).

6
7
Commercial OODBMSs

• GemStone from Gemstone Systems Inc.,
• Itasca from Itasca Systems Inc.,
• Objectivity/DB from Objectivity Inc.,
• ObjectStore from Object Design Inc.,
• Ontos from Ontos Inc.,
• O2 from O2 Technology,
• Poet from Poet Software Corp.,
• Versant from Versant Object Technology.

7
8
Origins of the Object-Oriented Data Model
8
9
Persistent Programming Languages (PPLs)

• A language that provides users with ability to
  (transparently) preserve data across successive
  executions of a program, and even allows such
  data to be used by many different programs.
• In contrast, database programming language (e.g.
  SQL) differs by its incorporation of features
  beyond persistence, such as transaction
  management, concurrency control, and recovery.

9
10
Persistent Programming Languages (PPLs)

• PPLs eliminate impedance mismatch by extending
  programming language with database capabilities.
• In PPL, languages type system provides data
  model, containing rich structuring mechanisms.
• In some PPLs procedures are first class objects
  and are treated like any other object in
  language.
• Procedures are assignable, may be result of
  expressions, other procedures or blocks, and may
  be elements of constructor types.
• Procedures can be used to implement ADTs.

10
11
Persistent Programming Languages (PPLs)

• PPL also maintains same data representation in
  memory as in persistent store.
• Overcomes difficulty and overhead of mapping
  between the two representations.
• Addition of (transparent) persistence into a PPL
  is important enhancement to IDE, and integration
  of two paradigms provides more functionality and
  semantics.

11
12
Alternative Strategies for Developing an OODBMS

• Extend existing object-oriented programming
  language.
• GemStone extended Smalltalk.
• Provide extensible object-oriented DBMS library.
• Approach taken by Ontos and ObjectStore.
• Embed OODB language constructs in a conventional
  host language.
• Approach taken by O2,which has extensions for C.

12
13
Alternative Strategies for Developing an OODBMS

• Extend existing database language with
  object-oriented capabilities.
• Approach being pursued by RDBMS and OODBMS
  vendors.
• Ontos, Versant and O2 provide a version of OSQL.
• Develop a novel database data model/language.

13
14
Single-Level v. Two-Level Storage Model

• Traditional programming languages lack built-in
  support for many database features.
• Increasing number of applications now require
  functionality from both database systems and
  programming languages.
• Such applications need to store and retrieve
  large amounts of shared, structured data.

14
15
Single-Level v. Two-Level Storage Model

• With a traditional DBMS, programmer has to
• decide when to read and update objects.
• write code to translate between applications
  object model and the data model of the DBMS.
• perform additional type-checking when object is
  read back from database, to guarantee object will
  conform to its original type.

15
16
Single-Level v. Two-Level Storage Model

• Difficulties occur because conventional DBMSs
  have two-level storage model storage model in
  memory, and database storage model on disk.
• In contrast, OODBMS gives illusion of
  single-level storage model, with similar
  representation in both memory and in database
  stored on disk.
• Requires clever management of representation of
  objects in memory and on disk (called pointer
  swizzling).

16
17
Two-level Storage Model for RDBMS
17
18
Single-level Storage Model for OODBMS
18
19
Accessing an Object with a RDBMS
19
20
Accessing an Object with an OODBMS
20
21
Persistent Schemes

• Consider three persistent schemes
• Checkpointing
• Serialization
• Explicit Paging.
• Note, persistence can also be applied to (object)
  code and to the program execution state.

21
22
Checkpointing

• Copy all or part of programs address space to
  secondary storage.
• If complete address space saved, program can
  restart from checkpoint.
• In other cases, only programs heap saved.
• Two main drawbacks
• Can only be used by program that created it
• May contain large amount of data that is of no
  use in subsequent executions.

22
23
Serialization

• Copy closure of a data structure to disk.
• Write on a data value may involve traversal of
  graph of objects reachable from the value, and
  writing of flattened version of structure to
  disk.
• Reading back flattened data structure produces
  new copy of original data structure.
• Sometimes called serialization, pickling, or in a
  distributed computing context, marshaling.

23
24
Serialization

• Two inherent problems
• Does not preserve object identity.
• Not incremental, so saving small changes to a
  large data structure is not efficient.

24
25
Explicit Paging

• Explicitly page objects between application
  heap and persistent store.
• Usually requires conversion of object pointers
  from disk-based scheme to memory-based scheme.
• Two common methods for creating/updating
  persistent objects
• Reachability-based
• Allocation-based.

25
26
Explicit Paging - Reachability-based persistence

• Object will persist if it is reachable from a
  persistent root object.
• Programmer does not need to decide at object
  creation time whether object should be
  persistent.
• Object can become persistent by adding it to the
  reachability tree.
• Maps well onto language that contains garbage
  collection mechanism (e.g. Smalltalk or Java).

26
27
Explicit Paging - Allocation-based persistence

• Object only made persistent if it is explicitly
  declared as such within the application program.
• Can be achieved in several ways
• By class
• By explicit call .

27
28
Explicit Paging - Allocation-based persistence

• By class
• Class is statically declared to be persistent and
  all instances made persistent when they are
  created.
• Class may be subclass of system-supplied
  persistent class.
• By explicit call
• Object may be specified as persistent when it is
  created or, dynamically at runtime.

28
29
Orthogonal Persistence

• Three fundamental principles
• Persistence independence
• Data type orthogonality
• Transitive persistence (originally referred to as
  persistence identification but ODMG term
  transitive persistence used here).

29
30
Persistence Independence

• Persistence of object independent of how program
  manipulates that object.
• Conversely, code fragment independent of
  persistence of data it manipulates.
• Should be possible to call function with its
  parameters sometimes objects with long term
  persistence and sometimes only transient.
• Programmer does not need to control movement of
  data between long and short term storage.

30
31
Data Type Orthogonality

• All data objects should be allowed full range of
  persistence irrespective of their type.
• No special cases where object is not allowed to
  be long-lived or is not allowed to be transient.
• In some PPLs, persistence is quality attributable
  to only subset of language data types.

31
32
Transitive Persistence

• Choice of how to identify and provide persistent
  objects at language level is independent of the
  choice of data types in the language.
• Technique that is now widely used for
  identification is reachability-based.

32
33
Orthogonal Persistence - Advantages

• Improved programmer productivity from simpler
  semantics.
• Improved maintenance.
• Consistent protection mechanisms over whole
  environment.
• Support for incremental evolution.
• Automatic referential integrity.

33
34
Orthogonal Persistence - Disadvantages

• Some runtime expense in a system where every
  pointer reference might be addressing persistent
  object.
• System required to test if object must be loaded
  in from disk-resident database.
• Although orthogonal persistence promotes
  transparency, system with support for sharing
  among concurrent processes cannot be fully
  transparent.

34
35
Pointer Swizzling Techniques

• The action of converting object identifiers
  (OIDs) to main memory pointers.
• Aim is to optimize access to objects.
• Should be able to locate any referenced objects
  on secondary storage using their OIDs.
• Once objects have been read into cache, want to
  record that objects are now in memory to prevent
  them from being retrieved again.

35
36
Pointer Swizzling Techniques

• Could hold lookup table that maps OIDs to memory
  pointers.
• Pointer swizzling attempts to provide a more
  efficient strategy by storing memory pointers in
  the place of referenced OIDs, and vice versa when
  the object is written back to disk.

36
37
No Swizzling

• Easiest implementation is not to do any
  swizzling.
• Objects faulted into memory, and handle passed to
  application containing objects OID.
• OID is used every time the object is accessed.
• System must maintain some type of lookup table so
  that objects virtual memory pointer can be
  located and then used to access object.
• Inefficient if same objects are accessed
  repeatedly.
• Acceptable if objects only accessed once.

37
38
Object Referencing

• Need to distinguish between resident and
  non-resident objects.
• Most techniques variations of edge marking or
  node marking.
• Edge marking marks every object pointer with a
  tag bit.
• If bit set, reference is to memory pointer
• Else, still pointing to OID and needs to be
  swizzled when object it refers to is faulted
  into.

38
39
Object Referencing

• Node marking requires that all object references
  are immediately converted to virtual memory
  pointers when object is faulted into memory.
• First approach is software-based technique but
  second can be implemented using software or
  hardware-based techniques.

39
40
Hardware-based Schemes

• Use virtual memory access protection violations
  to detect accesses of non-resident objects.
• Use standard virtual memory hardware to trigger
  transfer of persistent data from disk to memory.
• Once page has been faulted in, objects are
  accessed via normal virtual memory pointers and
  no further object residency checking is required.
  
• Avoids overhead of residency checks incurred by
  software approaches.

40
41
Pointer Swizzling - Other Issues

• Three other issues that affect swizzling
  techniques
• Copy versus In-Place Swizzling
• Eager versus Lazy Swizzling
• Direct versus Indirect Swizzling.

41
42
Copy versus In-Place Swizzling

• When faulting objects in, data can either be
  copied into applications local object cache or
  accessed in-place within object managers
  database cache .
• Copy swizzling may be more efficient as, in the
  worst case, only modified objects have to be
  swizzled back to their OIDs.
• In-place may have to unswizzle entire page of
  objects if one object on page is modified.

42
43
Eager versus Lazy Swizzling

• Moss defines eager swizzling as swizzling all
  OIDs for persistent objects on all data pages
  used by application, before any object can be
  accessed.
• More relaxed definition restricts swizzling to
  all persistent OIDs within object the application
  wishes to access.
• Lazy swizzling only swizzles pointers as they are
  accessed or discovered.

43
44
Direct versus Indirect Swizzling

• Only an issue when swizzled pointer can refer to
  object that is no longer in virtual memory.
• With direct swizzling, virtual memory pointer of
  referenced object is placed directly in swizzled
  pointer.
• With indirect swizzling, virtual memory pointer
  is placed in an intermediate object, which acts
  as a placeholder for the actual object.
• Allows objects to be uncached without requiring
  swizzled pointers to be unswizzled.

44
45
Versions

• Allows changes to properties of objects to be
  managed so that object references always point to
  correct object version.
• Itasca identifies 3 types of versions
• Transient Versions.
• Working Versions.
• Released Versions.

45
46
Versions and Configurations
46
47
Multiversion Timestamp Ordering

• Versioning of data can be used to increase
  concurrency.
• Basic timestamp ordering protocol assumes only
  one version of data item exists, and so only one
  transaction can access data item at a time.
• Can allow multiple transactions to read and write
  different versions of same data item, and ensure
  each transaction sees consistent set of versions
  for all data items it accesses.

47
48
Multiversion Timestamp Ordering

• In multiversion concurrency control, each write
  operation creates new version of data item while
  retaining old version.
• When transaction attempts to read data item,
  system selects one version that ensures
  serializability.
• Versions can be deleted once they are no longer
  required.

48
49
Schema Evolution

• Some applications require considerable
  flexibility in dynamically defining and modifying
  database schema.
• Typical schema changes
• (1) Changes to class definition
• (a) Modifying Attributes
• (b) Modifying Methods.

49
50
Schema Evolution

• (2) Changes to inheritance hierarchy
• (a) Making a class S superclass of a class C.
• (b) Removing S from list of superclasses of C.
• (c) Modifying order of superclasses of C.
• (3) Changes to set of classes, such as creating
  and deleting classes and modifying class names.
• Changes must not leave schema inconsistent.

50
51
Schema Consistency

• 1. Resolution of conflicts caused by multiple
  inheritance and redefinition of attributes and
  methods in a subclass.
• 1.1 Rule of precedence of subclasses over
  superclasses.
• 1.2 Rule of precedence between superclasses of a
  different origin.
• 1.3 Rule of precedence between superclasses of
  the same origin.

51
52
Schema Consistency

• 2. The propagation of modifications to
  subclasses.
• 2.1 Rule for propagation of modifications.
• 2.2 Rule for propagation of modifications in the
  event of conflicts.
• 2.3 Rule for modification of domains.

52
53
Schema Consistency

• 3. The aggregation and deletion of inheritance
  relationships between classes and the creation
  and removal of classes.
• 3.1 Rule for inserting superclasses.
• 3.2 Rule for removing superclasses.
• 3.3 Rule for inserting a class into a schema.
• 3.4 Rule for removing a class from a schema.

53
54
Client-Server Architecture

• Three basic architectures
• Object Server
• Page Server
• Database Server.

54
55
Object Server

• Distribute processing between the two components.
  
• Typically, client is responsible for transaction
  management and interfacing to programming
  language.
• Server responsible for other DBMS functions.
• Best for cooperative, object-to-object processing
  in an open, distributed environment.

55
56
Page and Database Server

• Page Server
• Most database processing is performed by client.
• Server responsible for secondary storage and
  providing pages at client's request.
• Database Server
• Most database processing performed by server.
• Client simply passes requests to server, receives
  results and passes them to application.
• Approach taken by many RDBMSs.

56
57
Client-Server Architecture
57
58
Architecture - Storing and Executing Methods

• Two approaches
• Store methods in external files.
• Store methods in database.
• Benefits of latter approach
• Eliminates redundant code.
• Simplifies modifications.

58
59
Architecture - Storing and Executing Methods

• Methods are more secure.
• Methods can be shared concurrently.
• Improved integrity.
• Obviously, more difficult to implement.

59
60
Architecture - Storing and Executing Methods
60
61
OODBMS Manifesto

• Complex objects must be supported.
• Object identity must be supported.
• Encapsulation must be supported.
• Types or Classes must be supported.
• Types or Classes must be able to inherit from
  their ancestors.
• Dynamic binding must be supported.
• The DML must be computationally complete.

61
62
OODBMS Manifesto

• The set of data types must be extensible.
• Data persistence must be provided.
• The DBMS must be capable of managing very large
  databases.
• The DBMS must support concurrent users.
• DBMS must be able to recovery from
  hardware/software failures.
• The DBMS must provide a simple way of querying
  data.

62
63
OODBMS Manifesto

• The manifesto proposes the following optional
  features
• Multiple inheritance, type checking and type
  inferencing, distribution across a network,
  design transactions and versions.
• No direct mention of support for security,
  integrity, views or even a declarative query
  language.

63
64
Advantages of OODBMSs

• Enriched Modeling Capabilities.
• Extensibility.
• Removal of Impedance Mismatch.
• More Expressive Query Language.
• Support for Schema Evolution.
• Support for Long Duration Transactions.
• Applicability to Advanced Database Applications.
• Improved Performance.

64
65
Disadvantages of OODBMSs

• Lack of Universal Data Model.
• Lack of Experience.
• Lack of Standards.
• Query Optimization compromises Encapsulation.
• Object Level Locking may impact Performance.
• Complexity.
• Lack of Support for Views.
• Lack of Support for Security.

65
66
Object-Oriented Database Design
66
67
Relationships

• Relationships represented using reference
  attributes, typically implemented using OIDs.
• Consider how to represent following binary
  relationships according to their cardinality
• 11
• 1M
• MN.

67
68
11 Relationship Between Objects A and B

• Add reference attribute to A and, to maintain
  referential integrity, reference attribute to B.

68
69
1M Relationship Between Objects A and B

• Add reference attribute to B and attribute
  containing set of references to A.

69
70
MN Relationship Between Objects A and B

• Add attribute containing set of references to
  each object.
• For relational database design, would decompose
  MN into two 1M relationships linked by
  intermediate entity. Can also represent this
  model in an ODBMS.

70
71
MN Relationships
71
72
Alternative Design for MN Relationships
72
73
Referential Integrity

• Several techniques to handle referential
  integrity
• Do not allow user to explicitly delete objects.
• System is responsible for "garbage collection".
• Allow user to delete objects when they are no
  longer required.
• System may detect invalid references
  automatically and set reference to NULL or
  disallow the deletion.

73
74
Referential Integrity

• Allow user to modify and delete objects and
  relationships when they are no longer required.
• System automatically maintains the integrity of
  objects.
• Inverse attributes can be used to maintain
  referential integrity.

74
75
Behavioral Design

• EER approach must be supported with technique
  that identifies behavior of each class.
• Involves identifying
• public methods visible to all users
• private methods internal to class.
• Three types of methods
• constructors and destructors
• access
• transform.

75
76
Behavioral Design - Methods

• Constructor - creates new instance of class.
• Destructor - deletes class instance no longer
  required.
• Access - returns value of one or more attributes
  (Get).
• Transform - changes state of class instance (Put).

76
77
Identifying Methods

• Several methodologies for identifying methods,
  typically combine following approaches
• Identify classes and determine methods that may
  be usefully provided for each class.
• Decompose application in top-down fashion and
  determine methods required to provide required
  functionality.

77
78
Object Management Group (OMG)

• International non profit-making consortium
  founded in 1989 to address object standards.
• Several hundred member organizations including
  many platform and major software vendors.
• Primary aims of OMG are
• Promotion of object-oriented approach.
• Development of standards in which location,
  environment, language, and other characteristics
  of objects are transparent.

78
79
Object Management Group (OMG)

• Not recognized standards group but aims to
  develop de facto standards.
• Defines standard object-based facilities for
• Concurrent execution.
• Distributed transactions.
• Versioning.
• Event notification.
• Internationalization.

79
80
Object Management Architecture

• Four areas identified for reference model
• Object Model (OM) - Design-portable abstract
  model for communicating with OMG-compliant
  object-oriented systems.
• Object Request Broker (ORB) - Handle distribution
  of messages between application objects in a
  highly interoperable manner.
• Like distributed 'software bus' enabling objects
  to make/receive requests/ responses from a
  provider.

80
81
Object Management Architecture

• Object Services - Provide main functions for
  realizing basic object functionality. Many of
  these services are database-oriented.
• Common Facilities - Comprise a set of tasks that
  many applications must perform but are
  traditionally duplicated within each one.

81
82
Object Reference Model
82
83
Object Model
83
84
Common Object Request Broker Architecture (CORBA)

• Defines architecture of ORB-based environments.
• Basis of any OMG component, defining parts that
  form ORB and associated structures.
• Some elements of CORBA are
• Interface Definition Language (IDL).
• Type model.
• Interface Repository.
• Methods for getting interfaces/specifications of
  objects.

84
85
Object Database Management Group

• Established by vendors of ODBMSs to define
  standards.
• Have produced an Object Model that specifies a
  standard model for the semantics of database
  objects.
• Design of class libraries and applications using
  these semantics should be portable across various
  ODBMSs.

85
86
Object Database Management Group

• Major components of ODMG architecture for an
  OODBMS are
• Object Model (OM)
• Object Definition Language (ODL)
• Object Query Language (OQL)
• C Language Binding
• Smalltalk Language Binding
• Java Language Binding.

86
87
ODMG Object Model

• Specifies following basic modeling primitives
• Basic modeling primitives are object/literal.
• Objects/literals can be categorized into types.
• All objects of given type exhibit common behavior
  and state. A type is itself an object.
• Behavior defined by set of operations that can be
  performed on or by object.
• State defined by values objects carry for a set
  of properties.

87
88
ODMG Object Model

• Property may be either an attribute of object or
  relationship between object and one or more other
  objects.
• A database stores objects, enabling them to be
  shared by multiple users and applications.
• A database is based on a schema defined in Object
  Definition Language (ODL).

88
89
ODMG Object Model - Objects

• Object types decomposed as atomic, collections,
  or structured types.
• Structured types as defined in ISO SQL standard.
• Objects created using new() of corresponding
  factory interface provided by language binding.
• Each object has a unique identity, the object
  identifier, which does not change and is not
  reused when the object is deleted.
• May be given one or more names by user.

89
90
Set of Built-in Types for ODMG Object Model
90
91
ODMG Object Model - Objects

• Lifetime of an object is orthogonal to its type.
• Means that persistence is independent of type.
• Lifetime specified when object is created may
  be
• Transient objects memory allocated and
  deallocated by programming languages runtime
  system.
• Persistent objects storage managed by OODBMS.

91
92
ODL Interface for Objects
92
93
ODMG Object Model - Literals

• Literal types decomposed as atomic, collections,
  structured, or null.
• Values of a literals properties may not change.
• Do not have their own identifiers and cannot
  stand alone as objects.
• They are embedded in objects and cannot be
  individually referenced.
• Structured literals contain fixed number of named
  heterogeneous elements.

93
94
ODMG Object Model - Collections

• Contains arbitrary number of unnamed homogeneous
  elements each can be instance of atomic type,
  another collection, or a literal type.
• Only collection objects have identity.
• Use iterator to iterate over collection.
• There are ordered and unordered collections
• Ordered collections traversed first to last, or
  vice versa
• Unordered collections have no fixed order of
  iteration.

94
95
ODMG Object Model - Collections

• Five built-in collection subtypes
• Set unordered collections without duplicates.
• Bag unordered collections that do allow
  duplicates.
• List ordered collections that allow duplicates.
• Array 1D array of dynamically varying length.
• Dictionary unordered sequence of key-value pairs
  with no duplicate keys.

95
96
ODL Interface for Collections
96
97
ODMG Object Model - Types and Classes

• Type has one specification and one or more
  implementations.
• Specification defines properties and operations
  that can be invoked on instances of the type.
• An implementation defines data structures,
  exceptions, and methods to support required state
  and behavior.
• Combination of type specification and one
  implementation is a class.

97
98
ODMG Object Model - Types and Classes

• Interface definition specifies its supertype(s),
  its extent, and its keys
• Extents - set of all instances of given type.
  May request OODBMS maintain index to members of
  this set.
• Keys - uniquely identifies the instances of a
  type (similar to the concept of a candidate key).

98
99
ODMG Object Model - Relationships

• Traversal paths are defined in interface for each
  direction of traversal.
• interface Branch
• relationship set ltStaffgtHas
• inverse Staff WorksAt
• interface Staff
• relationship Branch WorksAt
• inverse Branch Has

99
100
ODMG Object Model

• Object model also specifies
• Exceptions
• Metadata
• Transactions
• Databases.

100
101
Object Definition Language (ODL)

• interface Branch
• (extent branch_offices
• key bno)
• attribute string bno
• relationship Manager ManagedBy
• inverse ManagerManages
• void take_on_property_for_rent(in PFR)
• raises(property_already_for_rent)

101
102
Object Query Language (OQL)

• Provides declarative access to object database
  using SQL-like syntax.
• Does not provide explicit update operators -
  leaves this to operations defined on object
  types.
• Can be used as a standalone language and as a
  language embedded in another language, for which
  an ODMG binding is defined (Smalltalk, C, and
  Java).
• OQL can also invoke operations programmed in
  these languages.

102
103
Object Query Language (OQL)

• An OQL query is a function that delivers an
  object whose type may be inferred from operator
  contributing to query expression.
• Query definition expressions is of form
• DEFINE Q as e
• Defines query with name Q given query expression
  e .

103
104
Object Query Language (OQL)

• Expression can take several forms
• Elementary - Construction
• Atomic type - Object
• Collection - Indexed collections
• Binary set - Structure
• Conversion
• Query consists of a (possibly empty) set of query
  definition expressions followed by an expression.
• Result is object with or without identity.

104
105
Object Query Language (OQL) - Examples

• (a) Get set of all staff (with identity)
• staff
• (b) Get set of all branch managers (with
  identity)
• branch_offices.ManagedBy

105
106
Object Query Language (OQL) - Examples

• (c) Get set of all staff who live in London
  (without identity)
• define Londoners as
• select x
• from x in staff
• where x.address.city "London"
• select x.name.lname from x in Londoners
• This returns a literal of type setltstringgt.

106
107
Object Query Language (OQL) - Examples

• (d) Get structured set (without identity)
  containing name, sex and age for all staff who
  live in London
• select struct (lnamex.name.lname, sexx.sex,
• agex.age)
• from x in staff
• where x.address.city "London
• This returns a literal of type setltstructgt.

107
108
Object Query Language (OQL) - Examples

• (e) Get structured set (with identity) containing
  name and age for all deputy managers over 60
• type deputies attribute lname string age
  integer
• deputies (select struct (lnamex.name.lname,
• agex.age)
• from x in (select y from staff
• where position "Deputy")
• where x.age gt 60)
• This returns a mutable object of type deputies.

108
109
Object Query Language (OQL) - Examples

• (f) Get structured set (without identity)
  containing branch number and set of all
  Assistants at branches in London
• select struct (bnox.bno, assistants
• (select y from y in x.WorksAt
• where y.position "Assistant"))
• from x in (select z from branch_offices
• where z.address.city "London")
• This returns a literal of type setltstructgt.

109
110
OQL - Creating Objects

• A type name constructor is used to create an
  object with identity
• Person(fnameJohn, lnameWhite,
• address19 Taylor St, Cranford, London,
• tel_no01718845112,
• sexM, date_of_birth1-Oct-45)

110