ODMGODL

1
Chapter 4

• ODMG--ODL

2
The need of standard

• The benefits of standardization
• Data sharing
• Supportive context for third-party software
• Relational systems have more extensive standards
  than do object-oriented systems because
• Relational DBMS are more mature.
• As a result there has been a significant effeort
  by a number of organizations to create a usable
  set of standards.
• Relational model is much simpler than an object
  model and has a strong mathematical background.

3
Standardization bodies

• ISO ANSI ?SQL
• OMG (Object Management Group)
• Members DEC, Bull, IBM, O2, Informix, AA..etc
• Propose architecture OMA (Object Model
  Architecture) shared OO interface COBRA (Common
  Object Request Broker Architecture)
• Microsoft de facto standard, eg. ODBC
• ODMG (Object Management Group)

4
OMA (Object Model Architecture)
5
ODBC (Open Database Connectivity)
6
ODMG

• ODMG
• Rick Cattell of Sun Microsystems, who invited the
  most important OODBMS vendors to club together to
  create a standard with which they could all work.
  
• originally five in number but currently
  comprising GemStone Systems, IBEX Computing, O2
  Technology, Object Design, Objectivity, POET
  Software, UniSQL Inc. and Versant Object
  Technology.
• Three criteria apply to voting members
• They must be the manufacturer of an OODBMS
  system.
• They must commit 20 of the time of a leading
  technical expert to the development of the
  standard.
• They must implement the ODMG-93 standard in their
  product.

7
ODMG

• ODMG proposals are expected to comply with OMG
  standards, but to be somewhat more detailed
• an architecture for OODBMS
• a data model which will act as the logical model
  for all OODBMS and thus achieve a similar level
  of inter-operability to that found in relational
  systems
• a data definition language, ODL, which will form
  a concrete specification of the operations
  permitted over schemata defined in the data
  model
• a query language, OQL, which provides an
  interface for posing ad hoc queries (but not for
  doing data definition or data manipulation) and
• a number of bindings to existing object-oriented
  programming languages, such as C, Smalltalk and
  Java.

8
ODMG architecture
9
ODMG architecture

• The principal components of the architecture are
• The object data model
• The object definition language (ODL). ODL allows
  a schema to be described as a set of object type
  interfaces
• The object query language (OQL). This is an
  SQL-like query language which can be used as a
  stand-alone querying language or be embedded in
  one of the OMLs. OQL contains only querying
  commands.
• Object manipulation languages (OMLs). OOPLs are
  not naturally persistent. To enable them to
  interact with stored data, they need to be
  extended. An OML is the integration of a OOPL
  with the ODMG data model for this purpose. The
  system may provide more than one OML in order to
  exploit the differing programming skills of
  users.
• The persistent object store.
• Tools and libraries.

10
ODMG data model

• The ODMG data model describes a database as a
  collection of denotable values of which there are
  two kinds - objects and literals
• An objects type has an interface and one or more
  implementations.
• The interface describes the external appearance
  of the type, including the following components
• A name
• A set of supertypes
• Extent the name of a system-maintained
• Keys for associative access
• A set of attributes (a component object or
  literal value)
• A set of operations
• An implementation consists of the data structures
  which implement the properties and the code
  bodies which implement the operations.

11
(No Transcript)
12
ODMG data model

• Mutability
• If an address is modeled as an object then its
  components (house number, street name, etc.) can
  be updated, while it remains the same object -
  this is therefore a mutable object.
• If an address is a literal structure and one of
  its components is changed, then the whole address
  is considered to become a different value. If it
  is to remain the same value, the components may
  not be changed, i.e. it is an immutable literal.

13
The built-in typeatomic literal type

• Numbers
• Integers
• Longa signed integer with a large range of
  values
• Shorta signed integer with a small range of
  values
• Unsigned Longan integer with a large range of
  positive values
• Unsigned Shortan integer with a small range of
  positive values
• Reals
• Floata single precision real type
• Doublea double precision real type
• Booleans
• Booleantrue or false
• Character
• Charthe type of a single character
• Octet
• Octetthe type of a single byte
• Any
• Anythe type of a location which can hold any
  value

14
The built-in typecollections

• Five kinds of collection
• Sets are unordered collections which do not allow
  duplicates. They support operations to perform
  set union, intersection and difference to copy
  the set to test for subset and superset
  relationships and to (object sets only) insert
  and remove elements.
• Bags are unordered collections in which
  duplicates are allowed.
• Lists are ordered collections in which duplicates
  are allowed. These support a variety of retrieval
  operations and (object lists only) insertion and
  removal operations.
• Arrays are indexed lists of fixed size. They
  support indexed retrieval and insertion
  operations. Deletion operations on object arrays
  merely replace the value with nil.
• Enumerations are literals which contain an
  explicitly listed group of values. In our
  example, the title of a person is one of Mr.,
  Ms, Mrs, Miss or Dr., i.e. an enumeration
  type of five strings. Enumerations are not
  supported by all ODMG compliant systems.

15
The built-in typecollections

• Examples of describe a collection in ODL
• ListltFloatgt
• Immutable_BagltPersongt
• Arraylt Listlt Setlt Vehicle gt gt gt
• Iterators are objects which keep track of which
  member of a collection., For instance
• for all X in C do Command
• the following sequence of operations would be
  followed
• I C -gt create_iterator() ! Generate an
  iterator for the collection
• X I-gt first() ! Make X the first member of
  the collection
• repeat Command
• while I -gt more?() ! Is this the end of the
  collection?
• do X I -gt next() ! Make X the next
  member of the collection

16
The built-in typeRecords

• A structure has a name and a number of elements
  and each of these is a name, type pair. The
  latter can be any object or literal type, giving
  rise to the possibility of nested records
• Examples
• Struct Address Unsigned Short House String
  street, String city, String postcode
• Such a definition can be used in a schema in one
  of two ways
• attribute Struct Address Unsigned Short House
  String street, String city, String postcode
  address
• typedef Struct Address Unsigned Short House
  String street, String city, String postcode
• attribute Address address

17
User-defined object typeskey ,extent

• Object type interface to specify its name, the
  name(s) of its superclass(es), some type
  properties, the attributes of the class, the
  relationships of the class, and the operation
  interfaces.
• An extent is a collection of all of the instances
  of the type which will be maintained
  automatically by the system. The principal reason
  for defining the extent is to provide a
  persistent root to act as a start point for
  accessing the database - equivalent to the names
  of tables in a relational system.
• Examples
• interface Person(
• extent People
• key socialSecurityNumber ) persistent
• interface Company(
• extent Companies
• keys companyID, companyName ) persistent
• interface Adult Person(
• key ( worksFor, staffNumber ) ) persistent

18
User-defined object typesattributes

• An attribute is a property which is part of the
  object.
• Examples
• interface Person
• attribute String socialSecurityNumber
• attribute String name
• attribute Unsigned short age
• attribute Address address
• interface Company
• attribute Unsigned short companyID
• attribute String companyName
• attribute Adult manager
• attribute Address address
• interface Adult Person
• attribute Unsigned short staffNumber

19
User-defined object types relationship

• A relationship is a binary link between two
  objects, in which traversal in both directions is
  required.
• Relationships in the ODMG data model are always
  binary, but, as in the ER model, there are
• One-to-one pair two single-valued object
  classes.
• One-to-many pair a single-valued object class
  with a collection class.
• Many-to-many pair two collection classes.
• Examples
• interface Person
• relationship SetltAdultgt parents inverse
  Adultchildren
• relationship Company worksFor inverse
  Companyemployees
• interface Company
• relationship SetltPersongt employees inverse
  PersonworksFor
• interface Adult Person
• relationship Adult spouse inverse Adult
  spouse
• relationship ListltPersongt children inverse
  Personparents

20
User-defined object types const,typedef

• Other kinds of exported item
• const Unsigned Short maximumAge 150
• typedef Unsigned Short Smallint
• typedef ListltCompanygt EmploymentRecord
• attribute EmploymentRecord pastEmployers

21
User-defined object typesname

• To identify individual objects and give them
  names, which are independent of any particular
  database, and thus are part of the schema rather
  than the database. In the ODMG model any object
  can be given one or more names, although the same
  name cannot be used for more than one object.
• For instance, if the Person type is intended to
  be used for genealogical purposes, in which each
  database is to house the descendants of a
  particular couple, this could usefully include as
  named objects FirstWoman and FirstMan. This
  looks like
• name Person FirstMan
• name Person FirstWoman
• The most important use of named objects is that
  they are persistent root objects and can be used
  as the start points to database access. In the
  ODMG model, all persistent roots are either named
  objects or extents of object types.

22
User-defined object types operations

• Consider the following four operations
• an operation, birthday, defined on Person, which
  adds 1 to the age
• an operation, employ, which is defined on Adult,
  and sets the worksFor property
• an operation, addChild, which adds another person
  to the children of an adult and
• an operation, isChild, which tests if one person
  is the child of another.
• The corresponding ODLs
• interface Person
• void birthday()
• interface Company
• void employ( in Adult newEmployee )
• interface Adult Person
• void addChild( in Person newChild )
• boolean isChild( in Person testChild )

23
User-defined object types exceptions

• Each operation is programmed to deal only with
  the normal case. If any other situation is found
  to occur, an exception is signalled to the system
  and some data indicating the reason for the
  exception is passed back. This is called raising
  an exception.
• An exception is therefore made up of three
  components
• an event which causes the exceptional situation
  to occur
• exception data which is a (possibly empty)
  structure holding information about the reason
  for the problem and
• an exception handler - a piece of code which,
  using the exception, deals with the unusual
  situation in some way.

24
User-defined object types exceptions

• To illustrate how the mechanism works, consider
  the following fragment of pseudo-code.
• Implementation of Operation A of type T
• define exception E to be event N which passes
  back a string as the exception data and is
  handled by handler H which just prints the string
  it has been given
• ...
• print 1
• call operation B on object X of type U
• print 2
• ...
• end of operation A
• Implementation of Operation B of type U
• ...
• print 3
• call operation C on object Y of type V
• print 4
• ..
• . end of Operation B

• If N occurs, output 1, 3, 5, 6, 4, 2
• If N not occur, output1, 3, 5, N, 2

25
User-defined object types exceptions

• In the ODMG model, there is a most general
  exception, which is used if no handler is found
  in any of the operations which are in progress.
  This prints out a message to say that the
  exception has happened and then aborts the
  current process.
• Defining a new exception consists of defining a
  new exception type as a subtype of Exception.
  Exceptions can be specified either in modules or
  in type interfaces.
• In the example, the operation birthday could
  encounter a problem if it attempts to increase
  the age beyond the specified maximum. Setting the
  age property outside of the legal range 0 to 150
  is an example of an exceptional event.
• The most sensible place to put the exception
  handler is with the Person type, since it is only
  the operations of person that will be allowed to
  change age. The declaration of this type is
  extended with
• exception ageLimit( Unsigned short wrongAge )
• The exception can be raised in birthday, so the
  specification of that operation is changed to
• void birthday() raises (ageLimit)

26
User-defined object types Transactions

• Pessimistic concurrency control is the standard
  for the ODMG model.
• The following operations are allowed on a
  transaction
• begin initiates a transaction (and specifies the
  concurrency control protocol where this is
  allowed).
• commit completes a transaction, releasing all of
  the locks held by that transaction and making the
  changes accessible to any transactions in which
  this one is nested. If the transaction is a
  top-level transaction, then all other
  transactions can now access the changes.
• abort quits the transaction, releases locks and
  undoes any changes.
• checkpoint makes any changes permanent, but does
  not release any locks or quit the transaction.
• abort-to-top-level quits and undoes not just the
  changes of the current transaction but of all
  transactions in which this one is contained.

27
An example of the ODL syntax

• interface Company
• (extent Companies
• keys companyID, companyName ) persistent
• attribute Unsigned short companyID
• attribute String companyName
• attribute Adult manager
• attribute Address address
• relationship SetltPersongt employees
• inverse PersonworksFor
• void employ( in Adult newEmployee )
• interface Adult Person
• (key ( worksFor, staffNumber ) ) persistent
• typedef ListltCompanygtEmploymentRecord
• attribute Unsigned short staffNumber
• attribute EmploymentRecord pastEmployers
• relationship Adult spouse
• inverse Adult spouse

• module Employment
• typedef Struct Address
• Unsigned Short House String street,
• String city, String postcode address
• interface Person
• (extent People
• key socialSecurityNumber ) persistent
• exception ageLimit( Unsigned short
• wrongAge )
• const Unsigned Short maximumAge 150
• attribute String socialSecurityNumber
• attribute String name
• attribute Unsigned short age
• attribute Address address
• relationship SetltAdultgt parents inverse
• Adultchildren
• relationship Company worksFor inverse
• Companyemployees