ECS 165B Systems 1 ECS 165B Database Systems 2

1. Object-Oriented Database Systems, Emerging “New” Database Applications Standards, and Languages Non-standard applications: • On the Web: online product catalogs, ebay, amazon.com, Reading: Chapter 8 (4th ed), Chapter 9 (5th ed) e-business, e-government, . . . • Topics: Office Information Systems and Document Management Systems • Database Applications for OODBMS • Computer-Aided Design Environments (CAD, CAM, CAQ) • Overview of Object-Oriented concepts • Multimedia Applications (incl. images, video, audio) • Overview of the Object-Model of ODMG • Geographic Information Systems (GIS), Information • Basics of Object-Oriented DB design Management in the Lifesciences, Environmental Information Systems, . . .

Conventional Database Systems and Applications Common properties and problems for these types of applications: Features of “traditional” database applications: • Uniformity: Large numbers of similarly structured data items, • all of which having essentially the same size (in ). Need for complex data types and type systems (not just strings • Record Orientation: Basic data items consist of (fixed-length) and numbers) records. • Support of abstract data types (ADTs) and data encapsulation • Small Data Items: Each record (tuple) is short – a tuple rarely • Novel methods for querying (navigational/operational support requires more than a few hundred bytes. instead of just declarative support) and access structures. • Atomic Fields: Fields within a tuple are short, length typically • Sophisticated operations on data structures necessary, much within a specific range, first normal form holds. closer on programming concepts in OO programming languages. Such applications are very well supported by data-processing oriented data models () and concepts (storage & file structures, query processing & optimization, transaction management etc.)

Dr. Michael Gertz 1. Concepts of OODBS Dr. Michael Gertz 1. Concepts of OODBS ECS 165B Database Systems 3 ECS 165B Database Systems 4

Overview of Object-Oriented Concepts and OO Data Model • Object-identity is a stronger notion of identity than in programming languages or data models not based on object- • OODBS concepts have their origin in object-oriented orientation programming languages (abstract data types, encapsulation, (; concept does not apply to tuples of a ) information hiding, methods, class/type hierarchies, • inheritance...) Some OO models require that everything from simple value to complex object has an OID. • Object =ˆ state (value) and behavior (operations) • In OODBs objects are persistent (comp. transient objects in • Object identifiers are used to uniquely identify objects object-oriented programming languages) – stored as a field of an object • From a DB design perspective, the object-oriented model is a logical model (like ER model) – Used to refer to another object, e.g., the spouse field of • Essentially, an object corresponds to an entity in the ER model a person object may be the identifier of another person (but many issues are missing in the ER model, e.g., methods) object – can be system generated (built-in; created by the DBS) or external (user-supplied) Object-Identity Object Structure • OO database systems provide unique identifier (OID) for each object stored in DB; used to manage inter-object references In OODBS, the state (current value) of a complex object may be constructed from other objects (or other values) using type • Object retains identifier even if some or all of the values constructors. of variables or definitions of methods change, i.e., OIDs are immutable. • Basic type constructors are atom, tuple,andset;canalso include list, bag,andarray. • OIDs are not based on physical representation/storage of object (i.e., = ROWID or TID) • Formal representation of an object as a triple (i, c, v),withi being OID, c a type constructor, and v is the object state.

Dr. Michael Gertz 1. Concepts of OODBS Dr. Michael Gertz 1. Concepts of OODBS ECS 165B Database Systems 5 ECS 165B Database Systems 6

• Examples: Type Constructors o0 =(i0, atom, 815) Object Definition Language (ODL) that includes type constructors o1 =(i1, atom, UC Davis ) can be used to define object types for particular DB application. o2 =(i2, atom, ) Type constructors in ODL are used to define data structures for o3 =(i3, atom, Art ) OO database schema. o4 =(i4, , {i1, i2}) o5 =(i5, tuple, University : i1, Major : i2) Example (using a generic notation):

• Model allows arbitrary nesting of constructors (e.g., bag of define type Employee lists of sets of numbers) tuple( fname: string; lname: string; • Objectcanberepresentedasgraphwitheachobjectoi being salary: float; a node labeled with OID ii and type constructor ci.If hiredate: Date; object value is constructed, graph includes arc from object supervisor: Employee; node to node representing constructed value. For each atomic dept: Department ); value, graph includes direct arc from object node to node representing the value. define type Date tuple( year: integer; • Graph representation allows to compare states of two objects month: integer; for equality: day: integer ); – identical states (deep equality): graphs must be identical, including OIDs at every level define type Department – equal states (shallow equality): graph structure must be tuple( dname: string; the same, but some nodes may have different OIDs mgr: tuple ( manager: Employee; Example of shallow equality: startdate: Date); locations: set( string); o1 =(i1, tuple, a1 : i4, a2 : i6) employees: set( Employee) ); o2 =(i2, tuple, a1 : i5, a2 : i6)

Dr. Michael Gertz 1. Concepts of OODBS Dr. Michael Gertz 1. Concepts of OODBS ECS 165B Database Systems 7 ECS 165B Database Systems 8

Specifying Object Behavior via Class Operations • Example of class definition extending type definition Encapsulation and information hiding are core characteristics of define class Department OO programming languages. In contrast, in the relational model, type tuple (fname: string; all structures are visible and modifications are generic. ... • Behavior of a type (class) of object is based on operations ); that can be applied to objects of that type operations (no_of_emps: integer; create_dept: Department; • Internal structure of object is hidden and object is only destroy_dept: boolean; accessible through defined operations; these include object assign_emp(e: Employee): boolean); constructor and destructor, object modifiers, and retrieval operations.

Object Persistence via Naming and Reachability • Part of operation visible to the user is called (or signature); implementation of an operation is called method. • In OO programming languages, objects are transient (i.e., they are destroyed after program termination); persistent objects • Method is invoked by sending a message (including are stored in DB and persist after program termination. parameters) to object to execute corresponding method; In practice, it is reasonable to have both transient and method returns value; methods are typically written in general- persistent objects in application programs purpose programming language. • Mechanisms for making an object persistent: – Naming: persistent object is specified via specific statement • Only the implementor can see physical implementation of or operation in program; persistent objects are used as entry object, i.e., how a method is realized. Formally, all access points into the DB. However, it is not practical to explicitly operations to an object need to be encapsulated (i.e., set and give persistent names to all objects in DB. Thus, a more access methods for each attribute is required). practical mechanism is Practically, complete encapsulation is too stringent – Reachability: object is persistent by reachability if a ; divide structure of object into hidden and visible attributes. sequence of references in the object graph leads to a persistent (named) object.

Dr. Michael Gertz 1. Concepts of OODBS Dr. Michael Gertz 1. Concepts of OODBS ECS 165B Database Systems 9 ECS 165B Database Systems 10

• Example • Subtype inherits all attributes and operations of predefined type. define class DepartmentSet type ( set(Department)); • Example: operations ( add_dept(d: Department): boolean; PERSON: name, address, birthdate, age, ssn remove_dept(d: Department): boolean; Subclasses create_dept_set: DepartmentSet; EMPLOYEE subtype-of PERSON: salary, hiredate, job destroy_dept_set: boolean); STUDENT subtype-of PERSON: major, gpa

persistent name AllDepartments: DepartmentSet; • Substitutability – any method of a superclass can be invoked .... equally with any object belonging to any of its subclasses

d := Department.create_dept; • Multiple Inheritance .... – The class/subclass relationship is represented by a directed acyclic graph (DAG) – in such a graph, a class can have b := AllDepartments.add_dept(d); more than one superclass. – A class inherits attributes and methods from all its superclasses. Type Hierarchies and Inheritance – Potential for ambiguity, e.g., attributes with the same • A major characteristics of OODBMS is to support the name. Different solutions, such as flag and error, rename definition of new types based on other (predefined) types, attribute, or choose one. leading to type (or class) hierarchies. – One can use multiple inheritance to model roles of an • Concept of subtype (subclass) is useful when designer has to object. create a new type (class) that is similar but not identical to an already defined type (class); Recall is-a relationship type and subclass/superclass concepts in ER model ( ECS 165A).

Dr. Michael Gertz 1. Concepts of OODBS Dr. Michael Gertz 1. Concepts of OODBS ECS 165B Database Systems 11 ECS 165B Database Systems 12

Object Database Standard – ODMG 3.0 The • • Object Database Management Group (ODMG, www.odmg.org) Specifies what is meant by objects, literals, types, operations, is a subgroup of the Object Management Group (OMG, properties, attributes, keys, persistence, transactions www.omg.org), formed 1991 management, , and so forth. (; analogous to the definition of the relational model • ODMG’s goal is to provide portability for for relational database systems) – Data schemas • ODMG Object Model is fundamental definition of an – Programming Language Bindings OODBMS’s functionality. – Data Manipulation Languages – Query Languages i.e., application portability and resolving the impedance Object Definition/Specification Language (ODL) mismatch • Supports all semantic constructs of the ODMG Object Model • ODL should not be a full programming language, but rather a ODMG Standard Components definition language for object specifications • • Object Model: types, objects, modeling state/behavior, ODL should be programming language independent metadata, concurrency control, transaction model • ODL should be compatible with OMG’s Interface Definition • Object Definition/Specification Language (ODL) Language (IDL) – developed as part of the Common Object Request Broker Architecture (CORBA) • Object (OQL): object identifiers, methods, • path expressions, polymorphism ODLshouldbepracticalandextensible • C++, , and Java language bindings

Dr. Michael Gertz 1. Concepts of OODBS Dr. Michael Gertz 1. Concepts of OODBS ECS 165B Database Systems 13 ECS 165B Database Systems 14

Example: • OQL provides high level constructs to deal with sets of objects but is not restricted to this collection construct. It also interface Employee provides primitives to deal with structures, list, arrays etc. ( extent EmployeeExtension, keys EmployeeId, (name, DOB) ) • OQL is a functional language where operators can freely be { attribute Long EmployeeId; composed, as long as the operands respect the . attribute Struct Name { • OQL does not provide explicit update operators but rather String FirstName, invokes operations defined on objects for that purpose. String LastName } name; attribute Struct Address { ...} address; Examples: attribute List phones; • Complex result type can be constructed in query: attribute Date DOB; attribute Short Salary; select distinct struct(e.name, projects:( relationship List participates in select p.projectId inverse Project::members; from e.participates in prj as p) ) void raise Salary (in Short amount); from employee as e }; Result type: set>>

Object Query Language (OQL) • Query can include path expressions: • Syntactic and semantic extension of the SQL-92 standard. select m.name Extensions concern object-oriented notions, like complex from ( select p.manager objects, object identity, path expressions, operation invocation from project as p etc. where p.status = ’closed’) as m where m.salary > 5000

Dr. Michael Gertz 1. Concepts of OODBS Dr. Michael Gertz 1. Concepts of OODBS ECS 165B Database Systems 15

Development Strategies for OODBMS

DBMS OOPS + object−oriented + database concepts concepts

structural programming language 1 OODBMS based OODBMS 2

new OODBMS 3

ΠObject-Relational DBMS Oracle8i/9i/10g, DB2 Universal Database (includes portions of former Informix Dynamic Server with Universal Data Option), + : support of important database concepts, evolution instead of revolution, easy migration

 , ObjectStore, ONTOS, POET, Versant + : only one language for database + application programming – : no declarative query language, views, access path support, security, integrity constraints

Ž “Pure” Object-Oriented Database Management Systems: + : Combination of both approaches, new object-oriented data model – : difficult to learn, migration of existing applications, compatibility

Dr. Michael Gertz 1. Concepts of OODBS