Object Databases

1. Object Databases Baochuan Lu

2. outline • Concepts for Object Databases • Object Database Standards, Languages, and Design • Object-Relational and Extended-Relational Systems

3. Introduction • Traditional data models (relational, network, and hierarchical) is successful in traditional database applications. • Shortcomings: engineering design, manufacturing, scientific experiments, telecommunications, geographic information systems and multimedia. • New requirements: complex structure for objects, longer-duration transactions, new data-types for storing images or large textual items, and the need to define non standard application-specific operations.

4. Introduction • Key feature of OODB: designer can specify both the structure of complex objects and the operations to them. • ODMG: a consortium of object-oriented DBMS venders and users. • Two component of an object: state(value) and behavior(operations). • Transient objects: exist only during program execution

5. Introduction • Persistent object: persist beyond program termination and can be retrieved later. • Goal of OODB: maintain a direct correspondence between real-world and database objects so that objects do not lose their integrity and identity and can easily be identified and operated upon.

6. Object Identity • Object Identity (OID): unique, system-generated, for each independent object, immutable (it’s common to use long integers)

7. Object Structure • A feature of OODB: objects may have an object structure of arbitrary complexity. • The state of a complex object may be constructed from other objects. • Object triple representation: (i, c, v) i is a unique OID, c is a type constructor, v is the object state.

8. Type Constructors • Basic constructors: atom, tuple, and set. • Others: list, bag, and array. • Represent object as a graph structure: apply the type constructors recursively. • Identical states: Identical graph in every respect (OID at every level) • Equal states(shallow equality): • Same graph structure • Same corresponding atomic values • Internal nodes may have different OIDs

9. Encapsulation of Operation, Methods • Main idea: define the behavior of a type of object based on the operations that can be externally applied to objects of that type. • Method: operation implementation(interface: operation signature) • Complete encapsulation is stringent. • Visible attributes: may be directly accessed for reading by external operators, or by high level query language. • hidden attributes: completely encapsulated, can be accessed only through predefined operators.

10. Persistence • Typical mechanism: naming and reachability • Naming: give an object a unique persistent name (must be unique within a particular database) • Reachability: works by making the object reachable from some persistent object.

11. Class Hierarchies and Inheritance • Attributes and operations are together called functions (attributes resemble functions with zero arguments) • Type: a type name and a listing of the names of its visible (public) functions: • PERSON: Name, Address, Birthdate, Age, SSN • Defining a type: • defining all functions • Implementing them as attributes or as methods

12. extends • Extends: collections of objects of the same type • It’s common in database application that each type or subtype will have an extent associated with it, which holds the collection of all persistent object of that type or subtype. • Persistent collection, transient collection

13. Complex Objects • Two main types: structured and unstructured • Structured: • made up of components • Defined by applying available type constructors recursively • Unstructured: a data type requires a large amount of storage (image or large textual object) • ODBMS can be viewed as having a extensible type system. • DBMS internals provide the underlying storage and retrieval capabilities.

14. Other Concepts • Polymorphism: same name bound to different implementations • Mutiple inheritance • Selective inheritance

15. Object Database Standards, Languages, and Design

16. Introduction • Why a standard is needed? • Portability: execute an application program on different systems with minimal modifications to the program. • Interoperability • ODMG 2.0 standard: object model, object definition language (ODL), object query language (OQL), and bindings to object-oriented programming languages.

17. Object Model of ODMG • The data model upon which ODL and OQL are based. • Provides: data type, type constructors • SQL report describes a standard data model for relational database.

18. Object Model of ODMG • Object and literal: • Literal has only a value but no object identifier • Object has four characteristics: • identifier • Name • life time (persistent or not) • Structure (how to construct)

19. Object Model of ODMG • Atomic object: not a collection, includes structured objects created using the struct constructor • Three types of literals: • Atomic • Collection • Structured

20. Object Model of ODMG • Atomic literals: correspond to the values of basic data types, predefined • Collection literals: specify a value that is a collection of objects or values but the collection itself does not have an OID. • Structured literals: values that are constructed using the tuple constructor (Date, Interval, Time, Timestamp), user defined are created uing the struct keyword in ODL.

21. Object Model of ODMG • Dictionary<k, v>: a collection of associations <k, v>, k is a key (a unique search value) associated with a value v. • Factory object: an object that can be used to generate or create individual objects via its operations.

22. Object Definition Language (ODL) • Designed to support the semantic constructs of the ODMG data model. • Independent of any programming language. • Create object specifications: classes and interfaces • Specify a database schema: • In ODL • Use the specific language bindings to specify how ODL constructs can be mapped to constructs in specific programming language.

23. Object Query Language (OQL) • Embedded into one of these programming languages • Return objects that match the type system of that language • Similar to SQL with additional features (object identity, complex objects, operations, inheritance, polymorphism, relationships)

24. Object Query Language (OQL)-Entry Points and Iterator Variables • Entry point: named persistent object (for many queries, it is the name of the extent of a class). • Iterator variable: when a collection is referenced in OQL query. • d in departments • departments d • departments as d

25. Object Query Language (OQL)-Entry Points and Iterator Variables • Example SELECT d.dname FROM d in departments WHERE d.college = ‘Engineering’;

26. Object Query Language (OQL)-Query Results and Path Expressions • Any persistent object is a query, result is a reference to that persistent object. • Path expression: once an entry point is specified, it can be used to specifies a path to related attributes and objects. • E.g. Q1: departments; Q2: csdepartment.chair; Q2a: csdepartment.chair.rank; Q2b: csdepartment.has_faculty;

27. Object Query Language (OQL)-Query Results and Path Expressions select f.rank from f in csdepartment.has_faculty; select distinct f.rank from f in csdepartment.has_faculty;

28. Object Query Language (OQL) • OQL query can return a result with a complex structure specified in the query itself by utilizing the struct keyword. E.g. select struct (name:struct(last_name: s.name.lname, first_name: s.name.fname), degree:(select struct (deg:d.degree, yr: d.year, college:d.college) from d in s.degrees) from s in csdepartment.chair.advises;

29. Object Query Language (OQL)-Specifying Views as Named Queries • define keyword: specify an identifier of the named query, unique among all named objects, class names, method names, or function names in the scheme. • A query definition is persistent until it is redefined or deleted.

30. Object Query Language (OQL)-Specifying Views as Named Queries • A view can have parameters. • Example: define has_minors(deptname) as select s from s in students where s.minors_in.dname = deptname;

31. Object Query Language (OQL)-Extracting Single Elements from Singleton Collections • element operator: guaranteed to return a single element from a singleton collection that contains only one element. • Example: element (select d from d in departments where d.dname = ‘Computer Science’);

32. Object Query Language (OQL)-Collection Operators • Aggregate operators: min, max, count, sum, and avg. • Membership and qualification expressions: returns a boolean type. • Example: count (s in has_minors(‘Computer Science’));

33. Object Query Language (OQL)-Ordered (Indexed) Collection Expressions first (selectstruct(faculty:f.name.lname, salary:f.salary) from f in faculty orderby f.salary desc);

34. Object Query Language (OQL)-Grouping Operator • group by clause: provides explicit reference to the collection of objects within each group or partition. selectstruct (deptname, number_of_majors: count (partition)) from s in students groupby deptname: s.majors_in.dname • A having can be used to filter the partitioned sets (that is select only some of the groups based on group conditions).

35. Object Database Conceptual Design • ODB: relationships are handled by OID references to the related objects. • RDB: relationships among tuples are specified by attributes with matching values (value references).

36. Object-Relational and Extended-Relational Systems • ORDBMS: enhancing the capabilities of RDBMS with some of the features in ODBMS. • Object-oriented features in SQL-99

37. Any Queries? • Hint: use OQL.