Object database standards for dbms contents

1. OBJECT DATABASE STANDARDS,
LANGUAGES AND DESIGN
ADBMS
By: Dabbal S. Mahara
2018

2. Why database standards?
• Having a standard for a particular type of database
system is very important because of following
reasons:
1. It provides support for portability of database applications.
Portability is generally defined as the capability to execute a
particular application program on different systems with
minimal modifications to the program itself.
2. It helps to achieve interoperability. It generally refers to the
ability of an application to access multiple distinct systems. In
terms of database systems, this means that same application
program may access some data stored under one ODBMS
package, and other data store under another package.
3. It allow customers to compare commercial products more
easily by determining which parts of the standards are
2

3. ODMG
• ODMG ( Object Data Management Group) is a consortium of
ODBMS vendors.
• It proposed a standard for ODBMS in 1993 as ODMG 1.0, in
1995 ODMG 2.0 and in 2000 ODMG 3.0.
• The ODMG 3.0 standard is made up of several parts:
‣ Object model
‣ Object definition language (ODL)
‣ Object query language (OQL)
‣ Binding to OOP languages
3

4. The Object Model
The Object Model specifies the constructs that are supported by an
ODMS:
• The basic modeling primitives are the object and the literal. Each
object has a unique identifier. A literal has no identifier.
• Objects and literals can be categorized by their types. All elements
of a given type have a common range of states (i.e., the same set of
properties) and common behavior (i.e., the same set of defined
operations).
• An object is sometimes referred to as an instance of its type.
• The state of an object is defined by the values it carries for a set of
properties. These properties can be attributes of the object itself or
relationships between the object and one or more other objects.
4

5. The Object Model
• The behavior of an object is defined by the set of operations
that can be executed on or by the object.
• Operations may have a list of input and output parameters,
each with a specified type. Each operation may also return a
typed result.
• An ODBMS stores objects, enabling them to be shared by
multiple users and applications. These objects are called
persistent objects.
• An ODBMS is based on a schema that is defined in ODL and
contains instances of the types defined by its schema.
5

6. Types: Specifications and
Implementations
• There are two aspects to the definition of a type. A type has an
external specification and one or more implementations.
• The specification defines the aspects that are visible to users of
the type: the operations that can be invoked on its instances,
the properties, or state variables, whose values can be accessed,
and any exceptions that can be raised by its operations.
• A type’s implementation defines the internal aspects of the
objects of the type: the implementation of the type’s operations
and other internal details. The implementation of a type is
determined by a language binding.
6

7. Types: Specifications and
Implementations
• An interface definition is a specification that defines only the
abstract behavior of an object type.
• A class definition is a specification that defines the abstract
behavior and abstract state of an object type.
• A class is an extended interface with information for ODMS
schema definition.
• A literal definition defines only the abstract state of a literal
type.
7

8. Types: Specifications and
Implementations
• For example, interface Employee defines only the abstract
behavior of Employee objects. Class Person defines both the
abstract behavior and the abstract state of Person objects.
• Finally, the struct Complex defines only the abstract state of
Complex number literals.
In addition to the struct definition and the primitive literal
datatypes (boolean, char, short, long, float, double, octet, and
string), ODL defines declarations for user-defined collection,
union, and enumeration literal types.
• interface Employee {...};
class Person {...};
struct Complex {float re; float im; }; 8

9. Types: Specifications and
Implementations
9

10. ODMG Objects and Literals
• The basic building blocks of the object model are
‣ Objects
‣ Literals
• The main difference between the two is that an object
has both an object identifier and a state (current value),
where as a literal has a value but no identifier.
• In either case, value can have a complex structure.
10

11. Literals
• Literals do not have their own identifiers and cannot stand
alone as objects; they are embedded in objects and
cannot be individually referenced.
• The value of a literal cannot change.
• Examples of literal values are the numbers 7 and 3.141596,
the characters A and B, and the strings Fred and April 1.
• The Object Model supports the following three literal
types:
‣ atomic literal
‣ collection literal
‣ structured literal 11

12. Literal Types
• Atomic Literals
Correspond to the values of basic data types. That is, numbers,
characters, Boolean values etc are examples of atomic literal types.
• Structured Literals
Correspond to the values constructed by tuple constructor. They
include: date, time, interval and timestamp as built-in structures and
any other user defined structures.
• Collection Literals
The ODMG Object Model supports collection literals of the following
types: set<t> , bag<t>, list<t>, array<t>, dictionary<t, v>, where t is
a type of objects or values in the collection
12

13. Objects
• An object has four characteristics
1. Identifier: unique system-wide identifier
2. Name: unique within a particular database and/or program; it is
optional
3. Lifetime: persistent vs. transient
4. Structure: specifies how object is constructed by the type
constructor and whether it is an atomic object or collection object.
13

14. Object Identifiers
• An object can always be distinguished from all other objects
within its storage domain by using object identifier.
• An object retains the same object identifier for its entire
lifetime. Thus, the value of an object’s identifier will never
change.
• The object remains the same object, even if its attribute
values or relationships change.
• Object identifiers are generated by the ODMS, not by
applications.
14

15. Object Names
• In addition to being assigned an object identifier
by the ODMS, an object may be given one or
more names that are meaningful to the
programmer or end user.
• The application can refer at its convenience to an
object by name; the ODMS applies the mapping
function to determine the object identifier that
locates the desired object.
15

16. Object Lifetime
• The lifetime of an object determines how the memory and storage
allocated to the object are managed.
• Two lifetimes are supported in the Object Model:
‣ transient
‣ persistent
• An object whose lifetime is transient, is allocated memory that is
managed by the programming language runtime system. When the
process terminates, the memory is de-allocated.
• An object whose lifetime is persistent, is allocated memory and
storage managed by the ODMS runtime system. These objects
continue to exist after the procedure or process that creates them
terminates.
16

17. Object Structure
• The structure of object can be either atomic or not, in which
case the object is composed of other objects.
• An atomic object type is user-defined. There are no built-in
atomic object types included in the ODMG Object Model.
• In the ODMG Object Model, instances of collection objects are
composed of distinct elements, each of which can be an
instance of an atomic type, another collection, or a literal type.
17

18. Collection Objects
• An important distinguishing characteristic of a collection is that all the elements of the
collection must be of the same type.
• They are either all the same atomic type, or all the same type of collection, or all the
same type of literal.
• The collections supported by the ODMG Object Model include:
‣ Set<t>: A Set object is an unordered collection of elements, with no duplicates allowed.
‣ Bag<t>: A Bag object is an unordered collection of elements that may contain duplicates.
‣ List<t>: A List object is an ordered collection of elements.
‣ Array<t> : An Array object is a dynamically sized, ordered collection of elements that can be
located by position.
‣ Dictionary<t,v>: A Dictionary object is an unordered sequence of key-value pairs with no
duplicate keys.
• Each of these is a type generator, parameterized by the type shown within the angle
brackets. 18

19. Structured Object
• All structured objects support the Object ODL interface.
• The ODMG Object Model defines the following structured objects:
‣ Date
‣ Interval
‣ Time
‣ Timestamp
‣ User defined structured objects
• Example: user defined structured object
struct Address {
string dorm_name;
string room_no;
};
attribute Address dorm_address; 19

20. ODMG Interface
• An interface is a specification of the abstract behavior of an
object type.
• It is a signature for the persistent object. Interface tells external
world how to interact with an object. That is, an interface
describes the interface of types of objects: their visible attributes,
relationships and operations.
• Interfaces are non-instantiable but they serve to define
operations that can be inherited by the user-defined objects for a
particular application.
• State properties of an interface (i.e., its attributes and
relationships) cannot be inherited.
20

21. Object Inheritance Hierarchy: Built-in
Interfaces of ODMG
21

22. Object Interface
• In the object model, all the objects inherit the basic interface
Object.
• Typical interface of an object of ODMG showing operation
declarations is given below:
interface Object {
...
Boolean same_as(in object obj); // compares the object’s identity to another
object
object copy(); // create a new copy of the object
void delete(); // deletes the object
};
22

23. Collection Interface
• Collection interface: Any collection object inherits the basic
collection interface.
• This interface provides following operations:
• cardinality() // returns no. of objects in the collection
• is_empty() // returns true if collection is empty
• insert_element() // inserts an element from the collection
• remove_element() // removes an element from the collection
• contains_element()// returns true if an element is in the collection
• create_iterator() // creates an iterator object for the collection
object
23

24. Iterator Interface
• The iterator interface defines the operations for iterator object for
the collection object.
• The iterator object iterate over each element in the collection.
• The interface iterator is:
interface Iterator{
exception NoMoreElements();
.....
boolean is_stable();
boolean at_end();
void reset();
any get_element() raises(NoMoreElements);
void next_position() rasises(NoMoreElements);
....};
24

25. Collection Types
• Collection objects are further specialized into types like a set, list, bag,
array, and dictionary.
• All these inherit the Collection Interface.
• Set(t) : This interface is used to allow objects such that value of the object
is a set of elements of type t.
• Bag(t): interface used to have objects with the duplicate elements in the
collection.
• List(t): interface has an ordered collection of elements of type t.
• Array(t): similar to list but has fixed number of elements
• Dictionary(k,v): allows to have objects with collection of association <k,v>
where k is kye and v is value.
25

26. Set Interface
• For example, interface Set provides following
operations:
• create_union() // returns an object of type set(t) by union of two objects
• create_difference()
• is_subset_of() // returns TRUE if subset relation holds
• is_superset_of()
• is_proper_subset_of()
• Note: for Bag, List, Array and Dictionary refer to book ( Elmasri and Navathe)
26

27. Atomic Objects
• Any user defined object that is not a collection object is called an atomic
object.
• Atomic objects are defined via keyword class in ODL.
• Most of such objects will be structured objects.
• An example:
class Employee (extent all_emplyees key ssn) {
attribute string name;
attribute string ssn;
attribute short age;
relationship Dept works_for ;
void reassign(in string new_name); }
27

28. Interfaces and Behavior Inheritance
• In ODMG, two types of inheritance relationships exist.
• An interface is a specification of the abstract behavior of an
object type, which specifies the operation signatures.
• Interfaces are noninstantiable – that is, one cannot create objects
that correspond to an interface definition.
• They are mainly used to specify abstract operations that can be
inherited by classes or by other interfaces.
• Subtyping pertains to the inheritance of behavior only and it is
specified by colon ( : ).
28

29. Classes and EXTENDS inheritance
• A class is a specification of both the abstract behavior and abstract state
of an object type, and is instantiable.
• State of an object has two kinds of properties: attribute and relationship.
• An attribute is of one type.
• A relationship is defined between two types, each of which must have
instances that are referenceable by object identifiers.
• The ODMG Object Model defines an EXTENDS for the inheritance of state
and behavior.
• The EXTENDS relationship is a single inheritance between two classes
whereby the subordinate class inherits all of the properties and all of the
behavior of the class that it extends.
29

30. Example
 class Person {
attribute string name;
attribute Date birthDate;
};
 // in the following, the colon denotes the behavior inheritance
// the extends denotes the EXTENDS inheritance
class EmployeePerson extends Person : Employee {
attribute Date hireDate;
attribute Currency payRate;
relationship Manager boss inverse Manager ::
subordinates;
};
class ManagerPerson extends EmployeePerson : Manager {
relationship set<Employee> subordinates inverse Employee ::
boss;
};
30
Note: inverse indicates bidirectional relationship.

31. Extents
• The extent of a type is the set of all instances of the type within a
particular ODMS.
• If an object is an instance of type A, then it will necessarily be a member
of the extent of A.
• If type A is a subtype of type B, then the extent of A is a subset of the
extent of B.
• The ODMS schema designer can decide whether the system should
automatically maintain the extent of each type.
• In some cases, the individual instances of a type in the extent can be
uniquely identified by the values they carry for some property or set of
properties. These identifying properties are called keys.
• The scope of uniqueness is the extent of the type; thus, a type must have
an extent to have a key.
31

32. Example
class Employee (extent all_emplyees key ssn) {
attribute string name;
attribute string ssn;
attribute short age;
relationship Dept works_for;
void reassign(in string new_name);
};
32

33. ObjectFactory
• A factory object is used to generate individual objects via its operations.
• A factory object basically provides the constructor operations for new
objects.
• An example:
interface ObjectFactory {
Object new ();
};
• new() returns new objects with an object_id
• One can create their own factory interface by inheriting the above
interface
33

34. Object Definition Language
• ODL is a standardized language for specifying the structure of
databases in object-oriented terms.
• It is an extension of IDL (Interface Description Language), a
component of CORBA (Common Object Request Broker
Architecture). The latter is a standard for distributed, object-oriented
computing.
• The Object Definition Language is a specification language ( Design
Language) used to define the specifications of object types that
conform to the ODMG Object Model.
• Can be used like E/R as a preliminary design for a relational DB.
• ODL is independent of any programming language.
• ODL is not used for database manipulation.
34

35. Object Definition Language
35

36. Properties of Objects
• The properties of objects in a class must be the same. When programming
in an object-oriented language, we sometimes think of objects as records,
like that suggested by Figure (a). Objects have fields or slots in which values
are placed. These values may be of general types such as integers, strings,
or arrays, or they may be references to other objects.
• When specifying the design of ODL classes, we explain properties of three
kinds;
• Attributes, which are values associated with the object. We discuss the legal types of ODL
attributes in "Types in ODL".
• Relationships, which are connections between the object at hand and another object or objects.
• Methods, which are functions that may be applied to objects of the class.
• Attributes, relationships, and methods are collectively referred to as 36

37. 37

38. 38

39. 39

40. 40

41. 41

42. 42

43. Object Query Language
• OQL is DMG’s query language.
• OQL works closely with programming languages such as C++.
• Embedded OQL statements return objects that are compatible
with the type system of the host language.
• OQL’s syntax is similar to SQL with additional features for
objects.
43

44. 44

45. 45

46. 46

47. 47

48. Difference between ODB and RDB Design
1. One of the main difference between ODB and RDB design is how
relationships are handled.
• In RDB relationships among tuples are specified by attributes with
matching values. These can be considered as value references and
specified via foreign key, which are values of primary key attributes in
tuples of the referencing relation. These are limited to being single-
valued in each record.
• In ODB, relationships are typically handled by having relationship
properties or reference attributes that include OID(s) of the related
objects. These can be considered as OID references to the related
objects. Both single references and collections of references are
allowed. 48

49. ODB Vs RDB Design
• Mapping binary relationships that contain attributes is not
straightforward in ODBs, since the designer must choose in which
direction the attributes should be included. If the attributes are
included in both directions, then redundancy in storage will exist
and may lead to inconsistent data.
2. Another major area of difference between ODB and RDB design is
how inheritance is handled.
• In ODB, these structures are built into the model, so the mapping is
achieved by using the inheritance constructs, such as derived (:) and
extends.
• In relational design, there are several options to choose from since
no built-in construct exists for inheritance in the basic relational
49

50. ODB Vs RDB Design
3. The third major difference is that specification of operations,
• In ODB design, it is necessary to specify the operations early on in the
design since they are part of the class specifications.
• Although it is important to specify operations during the design phase
for all types of databases, it may be delayed in RDB design as it is not
strictly required until the implementation phase.
• There is a philosophical difference between the relational model and
the object model of data in terms of behavioral specification. The
relational model does not mandate the database designers to
predefine a set of valid behaviors or operations, whereas this is a tacit
requirement in the object model.
50

51. Mapping an EER Schema to an ODB
Schema
• Mapping EER schemas into ODB schemas is relatively simple
especially since ODB schemas provide support for inheritance
relationships.
• Once mapping has been completed, operations must be added
to ODB schemas since EER schemas do not include an
specification of operations
51

52. Step -1.
• Create an ODL class for each EER entity type or
subclass
‣ Multi-valued attributes are declared by sets, bags or lists
constructors
‣ Composite attributes are mapped into tuple constructors
52
EER to OO Mapping

53. EER to OO Mapping
Step - 2
• Add relationship properties or reference attributes for each binary
relationship into the ODL classes that participate in the relationship.
‣ Relationship cardinality: single-valued for 1:1 and N:1 directions; set-
valued for 1:N and M:N directions
‣ Relationship attributes: create via tuple constructors
53

54. EER to OO mapping
Step - 3
• Include appropriate operations for each class. These are not
available from the EER schema and must be added to the
database design by referring to the original requirements.
• Corresponding constructor and destructor operations
must also be added
54

55. EER to OO Mapping
Step - 4
• Specify inheritance relationships via extends clause:
‣ An ODL class that corresponds to a sub-class in the EER schema
inherits the types and methods of its super-class in the ODL schemas
‣ Its specific (non-inherited) attributes, relationship references, and
operations are specified, as discussed in steps 1, 2, and 3.
55

56. EER to OO Mapping
Step - 5
• Weak entity types can be mapped in the same way as regular entity
types.
• Attributes are mapped as discussed in steps 1 and 2.
• Weak entities that do not participate in any relationships except their
identifying relationship may alternatively be presented as composite
multi-valued attribute of the owner entity type.
• The attributes of the weak entity are included in the struct<... >
construct, which corresponds to a tuple constructor.
56

57. EER to OO Mapping
Step - 6
• Map categories (union types) to ODL
‣ The process is not straightforward.
‣ May follow the same mapping used for EER-to-relational
mapping:
‣ Declare a class to represent the category
‣ Define 1:1 relationships between the category and each of its
super-classes
57

58. EER to OO Mapping
Step - 7
• Map n-ary relationships whose degree is greater than 2
‣ Each relationship is mapped into a separate class with appropriate
reference to each participating class
58

59. EER to ODB : Example
See Chapter 21
of the book.
59

60. Exercise
60
1. What is the difference between an object and a literal in the object oriented
data model (OODM) ?
2. What are the main difference between designing a relational database and an
object database?
3. What are the differences and similarities between objects and literals in the
ODMG object model?
4. Describe the steps of the algorithm for object database design by EER-to-OO
mapping.
5. Differentiate between:
i. Interface and Class
ii. Extents and Extends
iii. Atomic Object and Collection Object
iv. OID and Key
v. Persistent Object and Transient Object

61. Thank You !
61