OBJECT-ORIENTED DATABASE SYSTEMS

1. OBJECT-ORIENTED DATABASE SYSTEMS ODMG Standard: Object Model Susan D. Urban and Suzanne W. Dietrich Department of Computer Science and Engineering Arizona State University Tempe, AZ 85287-5406

2. OUTLINE • Purpose of ODMG • Components of ODMG • Basic Modeling Concepts

3. CURRENT STATE OF OBJECT MODELS • Unlike the relational model, commercial OODB's were developed before any formal, standard basis was established for object models. • A proliferation of commercial tools with some similarities and also with differences. Makes portability difficult. • Has been difficult to establish a standard approach to query languages for OODB's with formal semantics to support query optimization.

4. STANDARDS OF OBJECT MODELS • Standards for object models are now being developed to promote portability and interoperability between tools. • The Object Data Management Group Standard (ODMG). • The Object Management Group Standard (OMG). • SQL99 Standard (Extended Relational).

5. THE ODMG STANDARDPurpose • Major goal is to establish standards that allow OODB customers to write portable applications that can run on more than one OODB product. • Supported by major OODB vendors and users. • The data schema, programming language binding, and data manipulation and query language must be portable. • Differences will always exist in performance, languages supported, specific functionality (e.g., versioning), programming environments, application construction tools, networking, predefined libraries, etc.

6. THE ODMG STANDARDComponents Major components of the standard include: • An Object Model - Defines the basic components of an object model. • An Object Definition Language - Defines a data definition language, known as ODL (for Object Definition Language). • An Object Query Language - Defines a declarative object query language (OQL) for querying and updating objects. OQL has an extended SQL flavor.

7. THE ODMG STANDARDProgramming Languages Support • A C++ Language Binding - Supports portable C++ code for manipulating objects. The language is called the C++ Object Manipulation Language (OML). • A Smalltalk Language Binding - Have drafted similar bindings to support the development of portable code in Smalltalk. • A Java Language Binding – Java bindings are now available.

8. USING THE ODMG STANDARD

9. BASIC MODELING CONCEPTS • Basic modeling primitives are the object (has a unique object identifier - OID) and the literal (has no identifier). • An OID is immutable (the value of an OID for a particular object cannot change). • Objects are categorized into types. • A type has an interface (properties and operations). • A type has one or more implementations. • An implementation defines data structures (physical representations of objects) and/or methods. • Behavior of objects is defined by a set of operations.

10. OBJECT PROPERTIES • Object states are defined by properties, which are: • attributes (string, integer, etc. as values, including objects), or • relationships (other objects as values with inverse traversal path specified and integrity maintained by the db) • The state of an object is mutable (the value of attributes and relationships can change).

11. TYPES AND EXTENTS Types are objects and thus have properties: • Supertypes and subtypes • The subtypes of a supertype can define additional operations and properties. • Subtypes can refine properties and operations. • Supports multiple inheritance. • Extents • The set of all instances of a type. • Can optionally request that the system maintain the extent automatically.

12. OBJECT CLASSES • A type interface plus an implementation defined for the type is a class. • A class in ODMG is similar to a class in C++. C++ classODMG class a public part • • • attributes and relationships a private part • • • implementation • A class can define keys. • Same as in the relational model. • Single keys or composite keys.

13. Object Atomic Object Collection <T>, Set <T>, Bag <T>, List <T> Array <T>. Structured_literal Date, Time, Timestamp, Interval, Structure <> Literal Atomic_Literal Long, Short, Unsigned long, Unsigned short, Float, Double, Boolean, Char, Octet, String, Enum <> Collection_literal <T> Set <T>, Bag <T>, List<T>, Array <T> Structured_literal Date, Time, Timestamp, Interval, Structure <> THE ODMG BUILT-IN TYPE HIERARCHY

14. NAMING AND LIFETIME • Objects can have names (i.e., meaningful or logical OID's). • Names can also be viewed as handles that allow users to easily reference a specific object. • Objects have lifetimes. • transient (allocated in memory only) • persistent (stored on disk)

15. ODL SYNTAX SUMMARY FOR CLASSES class c_name [extends superclass_name] ( extent extent_name key key_name ) { attribute <attribute_type> attribute_name; … relationship <relation_type> relation_name inverse <inverse_spec>; … method_definitions; }

16. HOLLYWOOD SCHEMA IN ODLclass Person class Person ( extent persons key ssn) { attribute string ssn; attribute string name; attribute string gender; attribute string phone; attribute string address; relationship Person isMarriedTo inverse …; void createPerson(in string ssn, in string name, in string gender, in string phone, in string address); void deletePerson(); . . . }

17. HOLLYWOOD SCHEMA IN ODLclass Celebrity class Celebrity extends Person ( extent celebrities) { attribute date birthDate; relationship Agent agent inverse Agent::celebrities; void createCelebrity(in string ssn, in string name, in string gender, in string phone, in string address, in date birthDate); void deleteCelebrity(); . . . }

18. INHERITANCE OF STATE VS. INHERITANCE OF BEHAVIOR • Classes in ODMG 2.0 are types that can be directly instantiated. • The extends relationship represents inheritance of state and behavior, where the subordinate class inherits all of the properties and behavior of the class that it extends. • Interfaces can be used to define types that cannot be directly instantiated. Interfaces are used to define the inheritance of behavior only. • Interfaces may inherit from other interfaces (is-a relationship). • Classes may inherit from interfaces (is-a relationship). • Classes may inherit from other classes (the extends relationship). • Interfaces may not inherit from classes.

19. SUMMARY OF SYNTAX FOR INTERFACE CLASSES interface i_name { methodDefinitions … } class c_name [extends superClass]: i_name ( …) { … }