Object Databases

Esteban ZIMANYI´ Department of Computer & Decision Engineering (CoDE) Universite´ Libre de Bruxelles [email protected]

Info-H-415 Advanced Databases Academic Year 2012-2013

Object Databases: Topics

_ Object-Oriented Databases y ODMG • Linq

_ Object-Relational Databases • SQL • Oracle

_ Summary

2 Object Databases

_ ODBMS: DBMS that integrates database (DB) and object programming language (PL) capabilities

_ Make DB objects appear as PL objects in one or more PLs

_ Persistent store for objects in a multiuser environment

_ Combines object properties with traditional DBMS properties: locking, protection, transactions, querying, versioning, concurrency, persistence

_ Objects referenced through persistent identiﬁers

Object Data(base) Management Group

_ Founded in 1991 by OODB constructors

_ Objective: create a standard in OODBs, that applies to • ODBMSs: store objects directly • Object-to-Database Mappings: convert and store objects in, e.g., RDBs

_ Releases: 1.0 in 1993, 1.1 in 1994, 1.2 in 1995, 2.0 in 1997, 3.0 in 2000

_ Proposal available as a book from Morgan Kaufmann Publishers

_ In February 2006, OMG formed the Object Database Technology Working Group (ODBT WG) for creating new speciﬁcations based on the ODMG 3.0 speciﬁcation

_ The work of the ODBT WG was suspended in March 2009

4 ODMG Architecture

ODL or PL ODL Source PL Declaration Application

PL Compiler

Declaration Binary Precompiler Application

ODBMS Linker Runtime

Executable

ODMG Standard

_ Builds upon the existing OMG, SQL-92, INCITS (formerly ANSI) PL standards, JavaSofts Java spec- iﬁcation

_ Deﬁne a framework for application portability between compliant data storage products

_ Functional components • Object Model • Object Deﬁnition Language • Object Query Language • Language Bindings to Java, C++, and Smalltalk

6 ODMG: Object Model

_ OMG’s Common Object Model (COM) • common denominator for ORB, OPL, object storage systems, ... • associated with Interface Deﬁnition Language (IDL)

_ ODMG’s OM • main component of standard, • extends COM with a ODBMS proﬁle to support object storage needs

_ Central features • Dual model: object and literals • Atomic, structured, and collection literals • Object with properties (attributes, relationships), operations, exceptions • Object naming, lifetime identity • Classes with extent and keys, collection classes • Multiple inheritance • Concurrency control, object locking, database operations

ODMG: Object Deﬁnition Language (ODL)

_ Strict superset of OMG’s IDL for DB schema deﬁnition

_ Objects deﬁned in terms of type, attributes, relationships, and operations

_ Abstraction layer: ODL-generated schemas are PL- and DB-independent

_ Allow applications to be • moved between compliant DBs • diﬀerent language implementations • translated into other Data Deﬁnition Languages (DDLs), e.g., SQL3

8 ODMG: Object Query Language (OQL)

_ SQL-like declarative language

_ Allows eﬃcient querying of database objects, including high-level primitives for object sets and structures

_ Based on query portion of SQL-92: superset of SQL-92 SELECT syntax

_ Object extensions for object identity, complex objects, path expressions, operation invocation, inheritance

_ OQLs queries can invoke operations in ODMG language bindings, OQL may be embedded in an ODMG language binding

_ No associated OML: object integrity maintained using operations of objects

ODMG: Language Bindings

_ Deﬁne Object Manipulation Languages (OMLs) extending PL to support persistent objects

_ Deﬁned for Java, C++, and Smalltalk

_ Bindings also include support for OQL, navigation, transactions

_ Enable developers to work inside a single language environment without a separate DB language

_ Example: Java Binding • Adds classes and other constructs to Java environment for supporting ODMG’s OM: e.g., collections, transactions, databases • Instances of classes can be made persistent without changes to source code • Persistence by reachability: at transaction commit, objects reached from root objects in DB automatically made persistent

10 ODMG Object Model: Summary

_ Diﬀerentiates objects (with identity) and literals

_ Literals: atomic, collection, structured

_ Classes with attributes, methods, subtyping, extension (inheritance of state)

_ Binary relationships, referential integrity maintained by DBMS

_ Generic collection classes, structured object classes

_ Names can be given to objects

_ Persistent and transient objects

_ Exception model

_ Metadata stored in a Schema Repository

_ Conventional lock-based approach to concurrency control

_ Transaction model

_ Database operations

ODMG Object Model

_ Basic modeling primitives: objets (with unique identiﬁers) and literals

_ Objects and literals categorized by their types

_ All elements of a type have common state (properties) and behavior (operations)

_ Properties: attributes and relationships

_ Operations: may have a list of input and output parameters, each with a type; may also return a typed result

_ DB stores objects shared by multiple users and applications

_ DB based on a schema deﬁned in ODL, contains instances of types deﬁned by its schema

12 Types: Speciﬁcations and Implementations

_ Type: external speciﬁcation, one or more implementations

_ Speciﬁcation: external characteristics of type, visible to its users • implementation-independent description of operations, exceptions, properties

_ Implementation: internal aspects of type • implementation of operations, other internal details

_ Encapsulation = separating speciﬁcations from implementation, helps • multilingual access to objects of a single type • sharing objects accross heterogeneous computing environments

Type Speciﬁcation

_ Interface: abstract behavior of an object type interface Employee { float salary() void hire(); void fire(); }

_ Class: abstract behavior and state of an object type class Person { attribute string name; relationship Person spouse inverse Person::spouse; void marriage(Person with); }

_ Literal: abstract state of a literal type struct Address { string street; string City; string Phone; }

14 Type Implementation

_ Implementation of a type = a representation and a set of methods

_ Representation: data structure derived from abstract state by PL binding • property in abstract state ⇒ instance variable of appropriate type

_ Methods: procedures derived from abstract behavior by PL binding • operation in abstract behavior ⇒ method deﬁned • read or modify representation of an object state, invoke other operations • also, internal methods without associated operation

_ A type can have more than one implementation, e.g., • in C++ and in Smalltalk • in C++ for diﬀerent machine architectures

Language Bindings

_ Each language binding deﬁnes an implementation mapping for literal types • C++ has constructs to represent literals directly • Smalltalk and Java map them to object classes

_ Example: ﬂoats • represented directly in C++ and Java • instances on class Float in Smalltalk

_ No way to represent abstract behavior on literal type ⇒ language-speciﬁc operations to access their values

_ OPL have language constructs called classes • implementation classes , abstract classes in Object Model • each language binding deﬁnes a mapping between both

16 Subtyping and Inheritance of Behavior

_ Type-subtype (is-a) relationships represented in graphs interface Employee { ... } interface Professor : Employee { ... } interface AssociateProfessor : Professor { ... }

_ An instance of a subtype is also logically an instance of the supertype

_ An object’s most speciﬁc type: type describing all its behavior and properties

_ A subtype’s interface may add characteristics to those deﬁned on its supertypes

_ Can also specialize state and behavior class SalariedEmployee : Employee { ... } class HourlyEmployee : Employee { ... }

Subtyping and Inheritance of Behavior (cont.)

_ Multiple inheritance of object behavior • a type could inherit operations of the same name but diﬀerent parameters • precluded by model: disallows name overloading during inheritance

_ Classes are directly instantiable types, interfaces not

_ Subtyping pertains to inheritance of behavior only: classes and interfaces may inherit from interfaces

_ Ineﬃciencies and ambiguities in multiple inheritance of state ⇒ interfaces and classes may not inherit from classes

18 Inheritance of State: Extends

_ In addition to isa, for inheritance of state

_ Applies only to object types: only classes (not literals) may inherit state

_ Single inheritance relationship between two classes: subordinate class inherits all properties and behavior of the class it extends class Person { attribute string name; attribute Date birthDate; }; class EmployeePerson extends Person : Employee { attribute Date hireDate; attribute Currency payRate; relationship Manager boss inverse Manager::subordinates; }; class ManagerPerson extends EmployeePerson : Manager { relationship set subordinates inverse Employee::boss; };

Extents and Keys

_ Extent of a type: set of all instances of the type in a particular DB

_ If type A is a subtype of type B ⇒ extent of A is a subset of extent of B

_ Maintaining the extent of a type is optional (, RDBMS)

_ Extent maintenance • insert newly created instances, remove instances • create and manage indexes to speed up access

_ Key: instances of a type uniquely identiﬁed by values of some property or set of properties

_ As in relational model: simple vs compound keys

_ A type must have an extent to have a key

20 OMG’s Meta-Object Facility

Object Creation

_ Objects created by invoking creation operations on factory interfaces provided on factory objects supplied by language binding interface ObjectFactory { Object new(); };

_ All objects have the following interface interface Object { enum Lock_Type { read, write, upgrade }; exception LockNotGranted {}; void lock(in Lock_Type mode) raises (LockNotGranted); // obtain a lock boolean try_lock (in Lock_Type mode); // True if lock obtained boolean same_as (in Object anObject); // identity comparison Object copy(); void delete()}; // remove objects from memory and the DB };

_ Critique: transaction deadlock exception is missing

22 Object Identiﬁers and Names

_ Objects retain same object identiﬁers for its entire lifetime

_ Literals do not have their own identiﬁers

_ Object identiﬁers geneterated the the ODBMS, not applications

_ Bit pattern representing an object identiﬁer ⇒ implementation issue

_ An object may be given name(s) meaningful for users

_ ODBMS provides a function mapping an object name to an object

_ Names used to refer to “root” objects: provide entry points to the DB

Object Lifetime

_ Speciﬁes, at object creation, how memory allocated to the object is managed

_ Transient: allocated in memory managed by the PL run-time system, e.g., • declared in a procedure and allocated on the stack • for a process and allocated on the heap

_ Persistent: allocated in memory managed by the ODBMS run-time system • continue to exists after procedure or process that creates it terminates

_ Object lifetimes independent of types • a type may have transient and persistent instances • persistent and transient objects manipulated using the same operations

_ ⇒ Persistence is orthogonal to type

_ This addresses the “impedance mismatch” of the relational model: • SQL for deﬁning and using persistent data • PL for deﬁning and using transient data

24 Collections

_ Generic type generators for structured values

_ All members of a collection object must be of the same type • Critique: must have a common ancestor type

_ Collections • Set: unordered collection of elements, no duplicate allowed • Bag: unordered collection of elements, may contain duplicates • Array: ordered collection of elements • List: dynamically sized ordered collection of elements that can be located by oposition • Dictionary: unordered sequence of key-value pairs with no duplicate keys

Manipulating Collection Objects interface CollectionFactory : ObjectFactory { Collection new_of_size(in long size); }; interface Collection : Object { exception InvalidCollectionType {}; exception ElementNotFound {any element; }; unsigned long cardinality(); boolean is_empty(); boolean is_ordered(); boolean allows_duplicates(); boolean contains_element(in any element); void insert_element(in any element); void remove_element(in any element) raises(ElementNotFound); Iterator create_iterator(in boolean stable); BidirectionalIterator create_bidirectional_iterator(in boolean stable) raises(InvalidCollectionType); };

26 Manipulating Iterators interface Iterator { exception NoMoreElements {}; exception InvalidCollectionType {}; boolean is_stable(); boolean at_end(); void reset(); any get_element() raises(NoMoreElements); void next_position() raises(NoMoreElements); void replace_element(in any element) raises(InvalidCollectionType); }; interface BidirectionalIterator : Iterator { boolean at_beginning(); void previous_position() raises(NoMoreElements); };

Structured Objects

_ Date

_ Time • internally stored in GMT • time zones : number of hours that must be added/subtracted to local time to get time in Greenwich, England

_ Timestamp: encapsulated Date and Time

_ Interval: duration in time • used to perform some operations on Time and Timestamp objects • created with the substract_time operation in Time

28 Structured Objects: Example interface Date : Object { typedef unsigned short ushort; enum Weekday {Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday}; enum Month {January,February,March,April,May,June,July,August, September,October,November,December }; struct asValue { ushort month, day, year; }; ushort year(); ushort month(); ushort day(); ushort day_of_year(); ushort month_of_year(); ushort day_of_week(); boolean is_leap_year(); boolean is_equal(in Date a_date); boolean is_greater(in Date a_date); boolean is_greater_or_equal(in Date a_date); boolean is_less(in Date a_date); boolean is_less_or_equal(in Date a_date); boolean is_between(in Date a_date,in Date b_date); Date next(in Weekday day); Date previous(in Weekday day); Date add_days(in long days); Date substract_days(in long days); long substract_date(in Date a_date); }

Literals Atomic Literals

_ long, short, unsigned long, unsigned short, float, double, boolean, octet, char (character), string, enum (enumeration)

_ All supported by OMG’s Interface Deﬁnition Language (IDL)

_ An enum is a type generator: named literal type that can take only the values listed in the declaration attribute enum gender { male, female }; attribute enum state_code { AK,AL,AR,AZ,CA,...,WY };

Collection Literals

_ set, bag, array, list, dictionary

_ Analogous to collection objects, but without identiﬁers

_ Their elements can be of literal or object types Table Type

_ Express SQL tables, semantically equivalent to a collection of structs

30 Structured Literals (Structures)

_ Fixed number of elements, each with a variable name and can contain a literal value or an object

_ Predeﬁned structures: date, interval, time, timestamp struct Address { string dorm_name; string room_no; } attribute Address dorm_address

_ May be freely composed • sets of structures, structures of sets, arrays of structures, ... struct Degree { string school_name; string degree_type; unsigned short degree_year; } typedef list Degrees;

Null Literals

_ For every literal type (e.g., float, set<>) ⇒ another literal type supporting null value (e.g., nullable_float, nullable_set<>)

_ Nullable type = literal type augmented by the null value “nill”

_ Semantics of null as deﬁned by SQL-92

32 Modeling State: Attributes class Person { attribute short age; attribute string name; attribute enum gender {male, female}; attribute Address home_address; attribute set phones; attribute Department dept; }

_ An attribute value: a literal or an object identiﬁer

_ Attribute , data structure: • attribute = abstract, data structure = physical representation • attributes may be implemented by data structures or by methods (e.g., age)

_ Attributes are not “ﬁrst class”

Modeling State: Relationships

_ Binary relationships only

_ Between objects only, literals cannot participate in relationships

_ May be one-to-one, one-to-many, many-to-many

_ Relationships are not “ﬁrst class”: not objects, without identiﬁer

_ Deﬁned implicitly by declaration of traversal paths declared in pairs interface Professor { ... relationship set teaches inverse Course::is_taught_by; } interface Course { ... relationship Professor is_taught_by inverse Professor::teaches; }

_ Traversal paths “many” may be unordered or ordered: indicated by type of collection

34 Modeling State: Relationships (cont.)

_ ODBMS responsible for maintaining referential integrity • if object is deleted, any traversal path to that object is also deleted

_ Ensures that applications cannot dereference traversal paths leading to nonexistent objects

_ Relationships vs references attribute Student top_of_class

_ Object-valued attributes reference an object, without inverse traversal path or referential integrity: “unidirectional relationships”

Implementation of Relationships

_ Encapsulated by public operations that • form and drop members of the relationship • provide access and manage referential integrity constraints

_ Possible exception: set already contains reference to the object interface Course { ... attribute Professor is_taught_by; void form_is_taught_by(in Professor aProfessor); void drop_is_taught_by(in Professor aProfessor); } interface Professor { ... readonly attribute set teaches; void form_teaches(in Course aCourse) raises(IntegrityError); void drop_teaches(in Course aCourse); void add_teaches(in Course aCourse) raises(IntegrityError); void remove_teaches(in Course aCourse); }

36 Modeling Behavior: Operations

_ Speciﬁcation identical to OMG CORBA speciﬁcation for operations

_ Operation signatures: name, name and type of each argument, types of values returned, names of any exceptions (error conditions) that may be raised

_ An operation deﬁned on only a single type

_ An operation name need be unique only within a single type deﬁntion • Critique: static polymorphism not supported

_ Overloaded operations can be deﬁned in diﬀerent types

_ Operations name resolution or operation dispatching: based on the most speciﬁc type of the object supplied as ﬁrst argument of the call

_ Single-dispatch model ⇒ consistency with C++, Java, and Smalltalk

_ Object model assumes sequential execution of operations

Metadata

_ Descriptive information about DB objects, deﬁnes the schema of the DB

_ Used by the ODBMS to deﬁne the structure of the DB and at runtime to guide its access to the database

_ Stored in an ODL Schema Repository, accessible to tools and applications

_ Meta-produced, e.g., during ODL source compilation

_ Deﬁnes interfaces for, e.g., MetaObject, Specifier, Operation, Exception, Constant, Property, Attribute, Relationship, Type, Interface, Class, Collection, Literal, Expression, ...

38 Metadata: Examples interface MetaObject { attribute string name; attribute string comment; relationship DefiningScope definedIn inverse DefiningScope::defines; } interface Operation : ScopedMetaObject { relationship list signature inverse Parameter::operation; relationship Type result inverse Type::operations; relationship list exceptions inverse Exception::operations; } interface Property : MetaObject { relationship Type type inverse Type::properties; } interface Attribute : Property { attribute boolean isReadOnly; } enum Cardinality {c1_1, c1_N, cN_1, cN_M}; interface Relationship : Property { exception integrityError {}; relationship Relationship traversal inverse Relationship::traversal; Cardinality getCardinality(); }

Object Speciﬁcation Languages

_ Language independent

_ Used to deﬁne the schema, operations, and state of an object DB

_ Objectives of these languages • facilitate portability of DBs across ODMG-compliant implementations • provide a step toward interoperability of ODBMS’s from multiple vendors

_ Two speciﬁcation languages • Object Deﬁnition Language (ODL) • Object Interchange Format (OIF)

40 Object Deﬁnition Language: Principles

_ Support all semantic constructs of the ODMG object model

_ Not a full PL, rather a deﬁnition language for object speciﬁcations

_ Programing language independent

_ Compatible with the OMG’s Interface Deﬁnition Language

_ Extensible for future functionality and for physical optimizations

_ Practical to application developpers, easily implementable by ODBMS vendors

Object Deﬁnition Language

_ Deﬁnes characteristics of types, including properties and operations

_ Deﬁnes only the signatures of operations, not methods of these operations

_ ODMG does not provide an Object Manipulation Language (as RDBMS do)

_ Deﬁne standard APIs to bind conformant ODBMSs to C++, Java, and Smalltalk

_ Provides a degree of insulation for application against variations in PLs and underlying ODBMS products

42 Class Deﬁnition: Example class Person ( extent people ) { attribute string name; attribute struct Address { unsigned short number, string street, string cityName } address; relationship Person spouse inverse Person::spouse; relationship set children inverse Person::parents; relationship list parents inverse Person::children; void birth (in string name); boolean marriage (in string personName) raises (noSuchPerson); unsigned short ancestors (out set allAncestors) raises (noSuchPerson); void move (in string newAdress); } class City ( extent cities ) { attribute unsigned short cityCode; attribute string name; attribute set population; }

ODMG Schemas: Notations

_ Object-valued attributes (unidirectional relationships) 1: - n: --

_ Relationships 1-1: - 1-n: -- m-n: --

_ Class and interfaces

Employee Student-IF class interface _ Subtyping and extents

subtyping extends

44 ODMG: Example Schema

Salary hasPrerequisites -- Course

66hasSections isPrerequisiteFor 6 Employee

Student-IF TeachAss Professor 6takes 6assists 6teaches 6 isTakenBy ?isSectionOf -- hasTA Student Section isTaughtBy

ODL: Example Schema class Course ( extent courses ) { attribute string name; attribute string number; relationship list

hasSections inverse Section::isSectionOf; relationship set hasPrerequisites inverse Course::isPrerequisiteFor; relationship set isPrerequisiteFor inverse Course::hasPrerequisites; boolean offer (in unsigned short semester) raises (alreadyOffered); boolean drop (in unsigned short semester) raises (notOffered); } class Section ( extent sections ) { attribute string number; relationship Professor isTaughtBy inverse Professor::teaches; relationship TeachAssist hasTA inverse TeachAssist::assists; relationship Course isSectionOf inverse Course::hasSections; relationship set isTakenBy inverse Student::takes; }

46 ODL: Example Schema, cont. class Salary { attribute float base; attribute float overtime; attribute float bonus; } class Employee ( extent employees ) { attribute string name; attribute short id; attribute Salary annualSalary; void hire(); void fire() raises (noSuchEmployee); } class Professor extends Employee ( extent professors ) { attribute enum Rank {full, associate, assistant} rank; relationship set

teaches inverse Section::isTaughtBy; short grantTenure() raises (ineligibleForTenure); }

ODL: Example Schema, cont. interface Student-IF { struct Address { string College, string roomNumber }; attribute string name; attribute string studentId; attribute Address dormAddress; boolean registerForCourse(in unsigned short course, in unsigned short section) raises (unsatisfiedPrerequisites, sectionFull, CourseFull); void dropCourse(in unsigned short Course) raises (notRegisteredForThatCourse); void assignMajor(in unsigned short Department); short transfer (in unsigned short oldSection, in unsigned short newSection) raises (sectionFull,notRegisteredInSection); }

48 ODL: Example Schema, cont. class TeachAssist extends Employee : Student-IF { relationship Section assists inverse Section::hasTA; attribute string name; attribute string studentId; attribute struct Address dormAddress; relationship set

takes inverse Section::isTakenBy; } class Student : Student-IF (extent students) { attribute string name; attribute string studentId; attribute struct Address dormAddress; relationship set

takes inverse Section::isTakenBy; }

Object Interchange Format

_ Speciﬁcation language for dumping and loading an ODB to or from a (set of) ﬁle(s)

_ Can be used to • exchange objects between DBs • seed DBs • provide DB documentation • drive DB test suites

_ Principles • support all ODB states compliant with the ODMG object model and ODL schema definition • not a full programming language, rather a specification language for persistent objects and their states • designed according to the related standards STEP or ANSI • needs no keywords other than the type, attribute, and relationship identifiers provided with the ODL definition of a DB schema

50 Object Interchange Format: Object Database States

_ State of all objects in a DB characterized by • object identiﬁers (with object tag names) • type bindings • attribute values • links to other objects

_ Critiques • Object names as entry points in the database are missing • No correlation beween OIF and the corresponding schema

Object Interchange Format: Object and Attributes Object Deﬁnitions

_ OIDs speciﬁed with object tag names unique to the OIF ﬁles(s)

_ Object deﬁnitions: Jack Person {}

_ Physical clustering: Paul (Jack) Person {}

_ Copy initialization: MacBain (MacPerth) Company(MacPerth) Attribute Initialization

_ Format for dumping Boolean, character, integer, ﬂoat, and string literals is speciﬁed

_ Range overﬂow controlled for integers and ﬂoats

_ Critique • Format for dumping structured literals Date, Time, Timestamp, and Interval, as well as enumeration types not speciﬁed

52 Initializing Attributes: Example struct PhoneNumber { unsigned short CountryCode; unsigned short AreaCode; unsigned short PersonCode; } struct Address { string Street; string City; PhoneNumber Phone; } interface Person { attribute string Name; attribute Address PersonAddress } Sarah Person { Name "Sarah", PersonAdress { Street "Willow Road", City "Palo Alto", Phone { CountryCode 1, AreaCode 415, PersonCode 1234 } } }

Initializing Arrays interface Engineer { attribute unsigned long PhoneNo[3]; }

_ Fields of the array indexed starting from zero, attributes not speciﬁed remain uninitialized Jane Engineer { PhoneNo { [0] 450123, [2] 270456} }

_ Index speciﬁer can be omitted ⇒ continuous sequence starting from zero Marc Engineer { PhoneNo { 12345, 234234 } }

_ Dynamic arrays: if one of the indices used in the object deﬁnition exceeds the current size of the variable size array, the array will be resized struct Point { float X; float Y; } interface Polygon { attribute array RefPoints; } P1 Polygon { RefPoints { [5] { X 7.5, Y 12.0 }, [12] { X 22.5, Y 23.0 } } }

54 Initializing Arrays and Collections Multidimensional arrays interface PolygonSet { attribute array PolygonRefPoints[10]; } P2 PolygonSet { PolygonRefPoints { [0] { [0] 12.5 , [1] 8.98, ...} ... [1] { [0] 23.7 , [1] 3.33 } } }

Collections interface Professor : Person { attribute set Degrees; } Feynman Professor { Degrees { "Masters", "PhD" }

Initializing Links interface Person { relationship Company Employer inverse Company::Employees; relationship Company Property inverse Company::Owner; } interface Company { relationship set Employees inverse Person::Employer; relationship Person Owner inverse Person::Property; }

_ Links for relationships with cardinality 1 treated as attributes Jack Person { Employer McPerth }

_ Links for relationships with cardinality m treated as collections McPerth Company { Employees { Jack, Joe, Jim } }

_ Example of a cyclic link Jack Person { Employer McPerth } McPerth Company { Owner Jack }

_ Critique: not explicitly stated whether both traversal directions of a link have to be dumped of if one suﬃces

56 Command Line Utilities Dump database

_ To create an OIF representation of the speciﬁed database odbdump

_ Object tag names created automatically using implementation-dependent name generation algorithms Load database

_ Populates the database with objects defined in the specified files odbload ..

Object Interchange Format: Example

Eve Person { name "Eve", address { number 25, street "Apple Road", city "Paradise" }, spouse Adam, children { Cain, Abel }, parents { God } } Paradise City { cityCode 6969, name "Paradise", population { Adam, Eve, Cain, Abel }, }

58 Object Query Language: Principles

_ Relies on ODMG’s object model

_ Close to SQL 92

_ Provides high-level primitives to deal with sets of objects, structures, lists, arrays

_ Functional language where operators can freely be composed

_ Not computationally complete

_ Can be invoked from within PL for which a binding is deﬁned, can also invoke operations programmed in these languages

_ Does not provide explicit update operators

_ Provides declarative access to objects

Object Query Language: Example DB

_ Types Person and Employee with extents Persons and Employees

_ One of these persons is the chairman: entry point Chairman

_ Person deﬁnes • attributes: name, birthdate, and salary • operation: age

_ Employee subtype of Person, deﬁnes • attribute: empNo • relationship: subordinates • operation: seniority

60 Query Input and Result

_ Query: function that delivers an object or a literal

_ Type of a query inferred from query expression, schema type declarations, and type of named objects and literals

_ Some objects generated by the QL interpreter, others produced from current DB

_ A query may return • a collection of objects with identity select x from Persons x where x.name="Pat" • an object with identity element(select x from Employees x where x.empNo=123456) • a collection of literals select x.empNo from Employees x where x.name="Pat" • a literal Chairman.salary

Type of Query Result

_ The set of ages of persons named Pat select distinct x.age from Persons x where x.name = "Pat" returns a literal of type set

_ The distinct couples of age and sex for persons named Pat select distinct struct(a:x.age, s:x.sex) from Persons x where x.name = "Pat" returns a literal of type set

62 Orthogonality

_ The name of each employee with the set of his highly paid subordinates select distinct struct(name:x.name, hps: select y from x.subordinates as y where y.salary > 100000)) from Employees x • returns a literal of type set)> • nested query in select clause

_ The couples of age and sex for persons having seniority of 10 and named Pat select struct(a:x.age,s:x.sex) from (select y from Employees y where y.seniority=10) as x where x.name = "Pat" • nested query in from clause

Compatibility: Deﬁnition Deﬁned recursively

(1) t is compatible with t

(2) If t is compatible with t’ then _ set(t) is compatible with set(t’) _ bag(t) is compatible with bag(t’) _ list(t) is compatible with list(t’) _ array(t) is compatible with array(t’) (3) If there exist t such that t is a supertype of t1 and t2, then t1 and t2 are compatible

64 Compatibility: Consequences

_ Literal types are not compatible with object types

_ Atomic literals types are compatible only if they are the same

_ Structured literal types are compatible only if they have a common ancestor

_ Collection literal types are compatible if they are of the same collection and the types of their meme- bers are compatible

_ Atomic object types are compatible only if they have a common ancestor

_ Collection object types are compatible if they are of the same collection and the types of their members are compatible

Navigations: Path Expressions

_ “.” or “->” notation to go inside complex objets and follow 1-1 relationships

_ For a person p, give the name of the city where p’s spouse lives p.spouse.address.city.name

_ For m-n relationships: use select from where clause as in SQL

_ The names of the children of person p: result of type bag select c.name from p.children c

_ Result of type set select distinct c.name from p.children c

_ The set of addresses of the children of each Person in the DB select c.address from Person p, p.children c

66 Predicates

_ Restrict previous result to people living on Main Street, having at least two children who do not live in the same city as their parents select c.address from Person p, p.children c where p.address.street = "Main Street" and count(p.children) >= 2 and c.address.city != p.address.city

_ Joins: In the from clause, collections not directly related

_ Example: the people who bear the name of a ﬂower select p from Person p, Flowers c where p.name = f.name

Null Values

_ Access to properties (with . or ->) applied to an Undefined left operand produce Undefined as result

_ Comparison operations with either of both operands being Undefined produce False as result

_ is_undefined(Undefined) returns true is_defined(Undefined) returns false

_ Any other operation with any Undefined operans results in a run-time error

68 Null Values: Examples

_ Three employees: one lives in Paris, another in Milan, third has a nil address select e from Employees e where e.address.city = "Paris" returns a bag containing the employee living in Paris select e.address.city from Employees e generates a run-time error select e.address.city from Employees e where is_defined(e.address.city) returns a bag containing the city names Paris and Milan select e from Employees e where not(e.address.city = Paris) returns a bag containing the employee living in Milan and the one without address

Method Invocation

_ Same notation as accessing an attribute or traversing a relationship

_ Parameters given between parentheses

_ Frees the user from knowing whether a property is stored or computed

_ The age of the oldest child of all persons with name Paul select max(select c.age from p.children c) from Persons p where p.name = "Paul"

_ Method oldestChild returns an object of class Person, livesIn is a method with one parameter

_ The set of street names where the oldest children of Parisian people are living select p.oldestChild.address.street from Persons p where p.livesIn("Paris")

70 Polymorphism

_ Major contribution of object orientation: manipulate polymorphic collections and, with late binding, carry out generic actions on their elements

_ Suppose set Persons contains objects of class Person, Employee, and Student

_ Properties of a subclass cannot be applied to an element of Person except in late binding or explicit class declaration

_ Late binding: give activities of each person select p.activities from Persons p Depending on the kind of person of the current p the right method activities is called

_ Class indication: grades of students (assuming that only students spend their time in following a course of study) select ((Student)p).grade from Persons p where "course of study" in p.activities

Collection Expressions

_ Existential and universal quantiﬁcation: return a Boolean value exists x in Doe.takes: x.taught_by.name = "Turing" for all x in Students: x.student_id > 0

_ Membership testing: return a Boolean value Doe in Students

_ Aggregate operators: min, max, count, sum, avg max( select salary from Professors )

72 Cartesian Product

_ Give the couples of student name and the name of the full professors from which they take classes select couple(student: x.name, professor: z.name) from Students as x, x.takes as y, y.taught_by as z where z.rank = "full professor"

_ Type of result: bag of objects of type couple

_ A diﬀerent query select * from Students as x, x.takes as y, y.taught_by as z where z.rank = "full professor"

_ Type of result: bag of structures, giving for each student object the section object followed by the student and the full professor object teaching in this section bag

Group-by Operator

_ Partition employees according to salary in 3 groups: low, medium, and high select * from Employees e group by low: salary < 1000, medium: salary >= 1000 and salary < 10000, high: salary >= 10000

_ Gives a set of three elements, each with a property partition contaning the bag of employees enter- ing in the category

_ Type of result: set )>

74 Group-by, cont.

_ Give for each department the employees working in this department select department, employees: (select p from partition p) from Employees e group by department: e.deptno

_ Result type: set )>

Group-by and Having Operator

_ Give a set of couples composed of a department and the average of the salaries of the employees working in that department, when this average is more than 30000 select department, avg_salary: avg(select e.salary from partition) from Employees e group by department: e.deptno having avg(select x.e.salary from partition x) > 30000

_ Result type: bag

76 Indexed Collection Expressions

_ Third prerequisite of course Math 101 element( select x from Courses x where x.name="Math" and x.number="101" ).requires[2]

_ First prerequisite of course Math 101 first ( element( select x from Courses x where x.name="Math" and x.number="101" ).requires )

_ First three prerequisites of course Math 101 element( select x from Courses x where x.name="Math" and x.number="101" ).requires[0:2]

Set Expressions

_ Union, intersection, diﬀerence (except) _ The set of students who are not teaching assistants Students except TechAss

_ Deﬁned for set and for bags • bag(2,2,3,3,3) union bag(2,3,3,3) returns bag(2,2,3,3,3,2,3,3,3) • bag(2,2,3,3,3) intersect bag(2,3,3,3) returns bag(2,3,3,3) • bag(2,2,3,3,3) except bag(2,3,3,3) returns bag(2)

_ Set inclusion: <, =<, >, >=, • set(1,2,3) < set(3,4,2,1) is true

_ Converson expressions • element(e): extracts the element of a singleton • listoset(e): turns a list into a set • distinct(e): removes duplicates • flatten(e) : ﬂattens a collection of collections

78 ODBMSs Today: Summary

_ Provide a more powerful and ﬂexible alternative to relational DBMSs

_ Early commercial products appeared in the 1990s, open source implementations in the 2000s

_ Very few of the original products remain on the market, in particular due to merging and acquisitions

_ OODBMS never get momentum and remained a niche market

_ Current systems diﬀer considerably in the functions provided

_ Their performance and scalability should be assessed

_ Building complex applications requires signiﬁcant expertise

_ Proprietrary application interface and class libraries ⇒ porting an application requires signiﬁcant re- work

Object Databases: Topics

_ Object-Oriented Databases • ODMG y Linq

_ Object-Relational Databases • SQL • Oracle

_ Summary

80 Hollywood Database Example

personSponsor companySponsor Person Company 0..1 0..1 {xor} 0..1 personId companyId isMarriedTo name 0..1 0..1 name gender Sponsor 0..1 phone sponsor sponsor address sponsoredBy 1..1 Project

Movie 0..* projectId Celebrity Professional location agentFor cost company 1..1 birthDate type projectsSponsored {disjoint, mandatory} celebrity (t,e) Agent 0..* Modeling Critic Agent MovieStar Model FilmProject Project popularity agentFee movieType preferences description title actors 1..* 1 modelOfProject paidByProject 1 actsIn 0..* paid modelsIn 0..* Paid 1..* Projects Models salary

Language INtegratedQuery (LINQ)

_ Declarative query language seamlessly integrated into the OOPLs of the .NET Framework, which include C# and Visual Basic

_ As OQL, relies on the well-typed features of the underlying OOPL, e.g., applying aggregate operators to a collection of the appropriate type

_ Can query collections of objects, tuples, or XML elements

_ Here we focus on querying a collection of objects using the C# language

_ Therefore, the ﬁelds of the classes are implemented as properties in C#

_ These are conventionally indicated by a method with an initial uppercase letter that deﬁnes get and set accessors for the private instance ﬁeld that the property is encapsulating

_ The private instance ﬁeld usually has the same name but starts with an initial lowercase letter

82 Queries from specifies collections relevant to answering the query and identifiers to iterate over those collections where specifies conditions for filtering objects select defines the structure of the data to be returned

_ LINQ uses path expressions with dot notation to access properties or methods associated with objects

_ Find the titles of the movies ﬁlmed in Phoenix from f in filmProjects where f.Location == "Phoenix" select f.Title;

_ from and where clauses are not limited to occur once in the expression, and the clauses can be intertwined

_ Find the actors who starred in projects ﬁlmed in Phoenix from f in filmProjects where f.Location == "Phoenix" from a in f.Actors select a.Name;

Alternative Syntax

_ LINQ’s querying capabilities are provided by the underlying .NET framework _ Extension method: static method in a static class that can be invoked as if it were an instance method on the object itself _ The from-where-select syntax is called query comprehension syntax _ This is compiled into an extension method syntax: e.g., Where and Select are extension methods _ Underlying extension method syntax for the previous query: filmProjects.Where(f => f.Location == "Phoenix").Select(f => f.Title);

_ The Where extension method is invoked on the filmProjects extent, taking as an argument an anonymous function that ﬁlters the extent _ The => syntax is read as “goes to” and represents a way to pass an argument into an anonymous function similar to lambda expressions _ The Select method returns the Title of the ﬁltered collection _ Extension methods that perform operations on LINQ query expressions are called query operators _ Linq queries typically use a combination of query comprehension syntax with query operators

84 Query Results (1)

_ Variables are implicitly typed

_ Deﬁning the variable phxFilms as the collection of ﬁlm projects located in Phoenix var phxFilms = from f in filmProjects where f.Location == "Phoenix" select f;

_ In C#, the type of the collection returned is usually an instance of IEnumerable

_ To remove duplicate elements from a collection in LINQ, the Distinct operator is used

_ The set of movie stars that appeared in Phoenix ﬁlm projects ( from f in phxFilms from a in f.Actors select a).Distinct();

Query Results (2)

_ To return a single object, with its type being implicitly deﬁned, the Single operator is used _ Deﬁne a variable daysOfThunder that represents the unique FilmProject object with the title “Days of Thunder” var daysOfThunder = ( from f in filmProjects where f.Title == "Days of Thunder" select f ).Single();

_ An exception is thrown if there is more than one object in the collection _ Query expressions return structured results using anonymous types and object initialization _ The following query returns an anonymous type that contains the names of movie stars in the daysOfThunder ﬁlm along with the name of each movie star’s agent from a in daysOfThunder.Actors select new { movieStarName = a.Name, agentName = a.CelebrityAgent.Name };

_ The new operator in the select clause creates an anonymous type _ The braces enclose the initialization of the anonymous object using names

86 Methods Calls and Embedded Queries

_ Queries can use method calls

_ Finds celebrities who are younger than 30 from c in celebrities where c.Age() < 30 select c.Name;

_ LINQ supports embedded queries in the from or select clauses

_ Find the Phoenix ﬁlm projects with a cost greater than $10 million from phx in ( from f in filmProjects where f.Location == "Phoenix" select f) where phx.Cost > 10,000,000 select new { phx.Title, phx.Cost };

_ Names of the celebrities that an agent manages from a in agents select new { agentName = a.Name, agentForCelebrities = (from c in a.AgentFor select c.Name) };

Set Membership and Quantiﬁcation (1)

_ The Contains operator supports set membership

_ Does the collection phxFilms contain the ﬁlm project daysOfThunder? phxFilms.Contains(daysOfThunder);

_ The Any and All operators supports existential and universal quantiﬁcation, respectively

_ Is there any f in filmProjects having a Location value equal to Phoenix? filmProjects.Any(f => f.Location == "Phoenix");

_ Finds the models who have had at least one modeling project located in Phoenix from m in models where (m.ModelsInProjects).Any(p => p.PaidByProject.Location == "Phoenix") select new {modelname = m.Name};

_ Determine whether all f objects in filmProjects cost more than 10 million filmProjects.All(f => f.Cost > 10000000);

88 Set Membership and Quantiﬁcation (2)

_ Find the names of movie stars for which all of their ﬁlm projects cost more than $20 million from m in movieStars where (m.ActsIn).All(fp => fp.Cost > 20000000) select m.Name;

_ Find the sponsors that are companies for which all of their sponsored modeling projects include at least one male model from s in sponsors where s.CompanySponsor ! = null && (s.ProjectsSponsored).All(mp => (mp.PaidModels). Any(p => p.ModelOfProject.Gender == "M")) select s.CompanySponsor.Name;

Ordering

_ Expressed with the orderby clause, which occurs before the select clause

_ This allows the results to be ordered by data that is not contained in the query result

_ Keywords ascending and descending specify the result order, with ascending as the default

_ List the ﬁlm projects ﬁlmed in Phoenix sorted in descending order by the cost of the project from fp in filmProjects where fp.Location == "Phoenix" orderby fp.Cost descending select new { phxTitle = fp.Title, phxCost = fp.Cost};

_ The orderby clause can also be used in embedded queries

_ List of movie stars in alphabetical order for each ﬁlm project ﬁlmed in Phoenix from fp in filmProjects where fp.Location == "Phoenix" orderby fp.Title ascending select new { phxTitle = fp.Title, phxMovieStars = ( from ms in fp.Actors orderby ms.Name select ms.Name ) };

90 Using Collections

_ Operators such as First, Last, and Take are used for accessing elements in a collection

_ Finds the highest paid Phoenix model ( from m in models from p in m.ModelsInProjects where p.PaidByProject.Location == "Phoenix" orderby p.Salary ascending select new {modelName = m.Name, modelSalary = p.Salary}).Last();

_ Find the top ten models based on the salary received for a modeling project in Phoenix ( from m in models from p in m.ModelsInProjects where p.PaidByProject.Location == "Phoenix" orderby p.Salary descending select new {modelName = m.Name, modelSalary = p.Salary}).Take(10);

_ Query operators for collections include the set operations Union, Intersect, and Except (diﬀer- ence)

Aggregation

_ Determine the number of ﬁlms for movie stars from m in movieStars orderby m.Name select new {name = m.Name, filmCount = m.ActsIn.Count()};

_ Find the total salary for a model from m in models select new { name = m.Name, salaryTotal = ( from p in m.ModelsInProjects select p.Salary ).Sum()};

_ An anonymous function can be used to generate the numeric collection as an argument to the operator _ Find the total cost of Phoenix ﬁlm projects phxFilms.Sum(phx => phx.Cost);

_ A let clause to deﬁne a variable for the scope of a query _ Order the results of the total model salary in descending order from m in models let salaryTotal = m.ModelsInProjects.Sum(p => p.Salary) orderby salaryTotal descending select new { name = m.Name, salaryTotal };

92 Grouping (1)

_ A group clause speciﬁes what to group and what to group by

_ Returns a collection of groups, each group has a Key property consisting of the value on which the group was created

_ Group ﬁlm projects by their location var filmsByLocation = from f in filmProjects group f by f.Location;

_ Give the location, count of the number of ﬁlms associated with that location, and the group of ﬁlms from locFilms in filmsByLocation orderby locFilms.Key select new { location = locFilms.Key, numberOfFilms = locFilms.Count(), films = locFilms };

Grouping (2)

_ Optional into speciﬁcation allows to continue the iteration over the groups in one query expression from f in filmProjects group f by f.Location into locFilms orderby locFilms.Key select new { location = locFilms.Key, numberOfFilms = locFilms.Count(), films = locFilms };

_ Group models by their agent, returning for each agent that represents more than three models, the count and names of the models in the group from m in models group m by m.CelebrityAgent into agentGroup where agentGroup.Count() > 3 select new { agentName = agentGroup.Key.Name, modelCount = agentGroup.Count(), modelNames = (from mg in agentGroup select mg.Name) };

94 Query Execution (1) _ The query comprehension syntax is converted to an underlying extension method syntax, resulting in an expression tree that represents the definition of the query _ Deferred query execution: a query is not executed until it is referenced, decoupling the query con- struction from its execution _ Thus, a query is similar to a database view definition: it is materialized on each reference _ This provides an opportunity for changing the values of parameters between query invocations _ Defining a variable locationOfInterest and a query expression filmsAtLocation that returns the films filmed at the locationOfInterest var locationOfInterest = "Phoenix"; var filmsAtLocation = from f in filmProjects where f.Location == locationOfInterest select f;

_ The first time that filmsAtLocation is referenced it returns the films filmed in Phoenix _ If the value of the variable locationOfInterest is changed to San Diego, then a subsequent reference to filmsAtLocation returns San Diego films

Query Execution (2)

_ Some query operators force the immediate execution of a query, such as the operators that return a scalar value (e.g., Average, Count, Max, Min, Sum) or a single element of a collection (e.g., First, Last, Single)

_ The query developer can also force immediate execution of any query by materializing the query using a conversion operator, such as ToArray or ToList, to cache the results in the designated data structure

_ These materialized results can then be reused for subsequent query references provided that the underlying data on which the materialized query depends has not changed

_ Otherwise, the materialized results would be out of date

96 Linq: Summary _ LINQ provides a declarative object-based query language within the .NET Framework _ Here we illustrated how to use LINQ to query collections of objects _ LINQ can also be used to query collections of relational tuples or collections of XML elements, the syntax is essentially the same _ For relational databases, once the connection to the database is established, the attributes are accessed using familiar dot notation _ For XML, after loading the XML document, the methods Descendants and Elements return a collection of elements for querying _ LINQ also provides a programmer with a declarative language for programming in C# _ LINQ uses a combination of the familiar from-where-select query comprehension syntax in combination with query operators, such as • Set membership and quantiﬁcation: All, Any, Contains • Accessing elements: First, Last, Single, Take • Set operations: Distinct, Except, Intersect, Union • Aggregation: Average, Count, Max, Min, Sum

Object Databases: Topics

_ Object-Oriented Databases • ODMG • Linq

_ Object-Relational Databases y SQL • Oracle

_ Summary

98 School Database Example: Entity Relationship Schema

Person

personId firstName lastName birthDate (t,e)

major (1,1) worksIn Student CampusClub Faculty (1,1) status clubId rank name (0,1) (0,n) memberOf location advisorOf (0,n) chairOf street members building advisor Clubs room Advises (0,n) phone (0,1)

deptChair Department Chair (1,1) code HasMajor name (0,n) getFaculty() getStudents() FacDept (0,n)

Row Types _ In traditional relational tables each column value in each row must be atomic (First Normal Form) _ The row type allows a row to be stored as a column value inside of another row create table campusClub ( clubId varchar(10), name varchar(50) not null, location row (street varchar(30), building varchar(5), room varchar(5)), advisor varchar(11) references faculty(personId), primary key (clubId));

_ Each element of the column is referred to as a field _ The row constructor is used to assign values to the fields of a row _ The types of the values must conform to the field types in the row type definition insert into campusClub values ( ’CC123’, ’Computer Club’, row(’Mill Avenue’, ’Brickyard Building’, ’Rm 222’), ’FA123’);

_ The values of a row type can be retrieved using dot notation to access the individual ﬁelds select c.location.street, c.location.building, c.location.room from campusClub c where c.name = ’Computer Club’;

100 Arrays as Collections (1) _ For collections, the SQL standard only supports the array type (not set, list, or bag) _ Arrays are useful for representing multivalued attributes _ Arrays can also be used to directly model the many side of a 1:N or M:N association _ A column in a table can be specified as an array by following the column type with the array keyword _ The maximum number of elements in an array is enclosed in square brackets _ The first position in an array is accessed with an index value of one _ Example: A members array that stores the identifiers of the club members create table campusClub ( ... members varchar(11) array[50] references student(personId), ... );

_ The array constructor is used to reserve space for an array insert into campusClub values ( ’CC123’, ..., array[]);

_ The identiﬁers of members can be added by using the array constructor in an update statement update campusClub set members = array[’ST111’, ’ST222’, ’ST333’] where name = ’Computer Club’;

101

Arrays as Collections (2)

_ Assignments can also be made to individual positions in an array by using a speciﬁc index value update campusClub set members[4] = ’ST444’ where name = ’Computer Club’;

_ An index is used to access a speciﬁc position of an array select members[2] from campusClub where name = ’Computer Club’;

_ The cardinality function can be used to get the size of an array _ cardinality(c.members) returns the current size of the array for a row c in the campusClub table _ The cardinality function can be used for iterating through array contents within SQL routines _ The cardinality of an array ranges from an empty array to the maximum size specified in the definition _ Given the previous update statements, the current cardinality of the array is four _ If an additional update statement sets position six to the value ’ST666’, the cardinality of the array becomes six, with position five set to null

102 User-Deﬁned Types

_ User-deﬁned type (UDT) is the SQL standard terminology for abstract data type

_ UDTs in the SQL standard are somewhat diﬀerent from the strict deﬁnition of an abstract data type

_ All internal attributes of a UDT and their associated methods are public and cannot be marked as protected or private as in languages such as Java or C++

_ UDTs allows database developers to deﬁne new application-oriented types, beyond built-in atomic and constructed types, that can be used in the deﬁnition of relational tables

_ UDTs also provide the basis for the creation of objects in the relational world

_ There are two basic types of UDT in the SQL standard: the distinct type and the structured type

103

Distinct Types (1)

_ Provides a way of attaching special meaning to an existing atomic type

_ Use of a distinct type cannot be freely mixed with the atomic type on which it is based

_ The distinct type essentially deﬁnes a new form of the atomic type

_ Example: A table person table that maintains the age and weight of persons

_ Columns for personAge and personWeight can be deﬁned of type integer

_ The age and weight of the person can be added even though this is meaningless

_ Distinct types can be deﬁned using the create type to prevent meaningless calculations with values that are of the same type but have diﬀerent semantics

_ Example: age and weight deﬁned as two diﬀerent distinct types, both based on the integer atomic type create type age as integer final; create type weight as integer final;

_ Keyword final (required) means that a subtype of the distinct type cannot be deﬁned

104 Distinct Types (2) _ Use of the above distinct types in table person create table person ( personId varchar(3), personAge age, personWeight weight, primary key (personId));

_ Retrieve the personId of persons younger than the person with personId ’123’ select p1.personId from person p1, person p2 where p2.personId = ’123’ and p1.personAge < p2.personAge;

_ The following query is invalid since it mixes the use of age, weight, and integer values select personId from person where (personAge * 2) < personWeight;

_ The cast function can be used to solve the problem select personId from person where cast (personAge as integer) * 2 < cast (personWeight as integer);

_ Methods can also be deﬁned on distinct types to create specialized operations for manipulating and comparing distinct types

105

Structured Types

_ UDTs composed of several internal components, each component can be of a diﬀerent type

_ An instance of a structured type is a composite value

_ Example: deﬁning a campus club location as a structured type create type locationUdt as ( street varchar(30), building varchar(5), room varchar(5)) not final;

_ The components are the attributes of the structured type, their type can be a built-in atomic or a constructed type as well as any user-deﬁned type

_ The keywords not final (required, a current restriction of the SQL standard) indicates that it is possible to deﬁne subtypes of the type

_ Use of this type in table campusClub create table campusClub ( clubId varchar(10), name varchar(50) not null, location locationUdt, advisor varchar(11) references faculty(personId), members varchar(11) array[50] references student(personId), primary key (clubId));

106 Built-In Methods (1)

_ Methods are associated with structured types, thus supporting encapsulation of structured types

_ In the SQL standard, methods cannot be deﬁned as procedures

_ Some systems (e.g., Oracle) allow methods to be deﬁned as functions or procedures

_ Three types of built-in methods for structured types

_ Constructor function: has the same name as the type and is used for creating instances of the type

_ Must always be invoked using the new expression

_ Observer functions: are used for retrieving the attribute values of a structured type

_ There is an observer function for every attribute of the type, where the function has the same name as the attribute

_ Mutator functions: used to modify the attribute values of a structured type

_ There is a mutator function for every attribute of the type having the same name as the attribute

107

Built-In Methods (2)

_ Observer and mutator functions are invoked using dot notation variable.functionName

_ Functional notation functionName(parameters) is only used for functions that are not methods

_ Routine that uses the constructor and mutator functions to create an instance of locationUdt begin declare loc locationUdt; set loc = new locationUdt(); /* invoking the constructor function */ set loc.street = ’Mill Avenue’; /* invoking the mutator functions */ set loc.building = ’Brickyard Building’; set loc.room = ’RM 222’; insert into campusClub values ( ’CC123’, ’Computer Club’, loc, /* initializing location */ ’FA123’, array[]); end;

108 Built-In Methods (3)

_ The system-defined constructor function has no parameters: the new instance has all of its attribute values set to either null or to a default value specified in the type definition

_ The new instance created above is a value and not an object (see later)

_ The value returned by a mutator function is a new instance of the type with the modiﬁed attribute value

_ The query below uses of observer functions to retrieve the attribute values of the structured type select name, c.location.street, c.location.building, c.location.room from campusClub c where name = ’Computer Club’;

_ Because of potential naming ambiguities, structured types and observer functions can only be accessed through the use of alias names in queries (i.e., c in the previous query)

_ A reference such as location.street or campusClub.location.street is not allowed

109

User-Deﬁned Methods

_ Users can deﬁne their own methods on structured types

_ Method speciﬁcation (the signature) is deﬁned in the create type statement

_ It indicates the name of each method together with the names and types of its parameters

_ The implementation of the method is deﬁned separately using the create method statement

_ Example create type threeNumbers as ( one integer, two integer, three integer) not final method sum() returns integer; create method sum() returns integer for threeNumbers begin return self.one + self.two + self.three; end

_ Every method has one implicit parameter: the instance of the type on which the method is deﬁned

_ The value of the implicit parameter is accessed in the method implementation using the self keyword

110 Method Overriding

_ Users can override the constructor function of a structured type

_ This can be used to set the attribute values at the time an instance of the type is created create type locationUdt as ( ... ) not final overriding constructor method locationUdt (street varchar(30), building varchar(5), room varchar(5)) returns locationUdt; create method locationUdt(st varchar(30), bl varchar(5), rm varchar(5)) returns locationUdt for locationUdt begin set self.street = st; set self.building = bl; set self.room = rm; return self; end;

_ Since the overridden method is a constructor function, the constructor keyword must be speciﬁed

_ The name of the method must be the same as the name of the system-deﬁned constructor function

_ This function can then be used to construct a new instance and to set the values of its attributes declare loc locationUdt; set loc = new locationUdt(’Mill Avenue’, ’Brickyard Building’, ’Rm 222’);

111

Typed Tables (1)

_ To create the notion of an object, a UDT must be used together with a typed table

_ Typed table: a new form of table that is always associated with a structured type

_ It has a column for every attribute of the structured type on which it is based

_ In addition, it has a self-referencing column that contains a unique object identiﬁer, known as a reference, for each row in the table

_ Other than the self-referencing column and the attributes of the structured type, additional columns cannot be added to the table deﬁnition

_ When a structured type is used to deﬁne a typed table, an instance of the type is viewed as an object, with the self-referencing column providing the object identiﬁer

_ Unlike object identifiers in OODBs, an object identifier is only unique within a specific typed table

_ As a result, it is possible to have two typed tables with rows that have identical self-referencing values

112 Typed Tables: Deﬁning the Structured Type

_ Deﬁning the UDT associated to the department table create type departmentUdt as ( code varchar(3), name varchar(40) ) instantiable not final ref is system generated;

_ The instantiable clause indicates that it is possible to directly create instances of the type

_ The use of not instantiable only makes sense in the context of a type that has a subtype

_ A structured type that is used together with a typed table must always be speciﬁed as instantiable

_ There are three ways for generating the value for the object reference

_ System generated: the DBMS generates a unique object reference for instances of the type

_ User deﬁned: the user must provide a unique reference for each instance using a predeﬁned type

_ Derived: the user must specify the attribute(s) from the type used to provide a unique object reference

_ For user-deﬁned and derived references, the user must ensure the uniqueness of the reference

_ System generated references is the most natural approach

113

Deﬁning a Typed Table

_ Once a structured type is deﬁned, a corresponding typed table may be deﬁned create table department of departmentUdt ( primary key (code), ref is departmentID system generated);

_ Typed tables supports the same constraints (e.g., primary key, not null) as those of regular tables

_ Only the attributes with constraints are listed in the typed table deﬁnition

_ A reference generation speciﬁcation that is consistent with that of the structured type must be repeated

_ The ref is speciﬁcation must assign a name to the self referencing column to manipulate it

_ Rows are inserted in the same manner as for any relational table insert into department values (’cse’, ’Computer Science and Engineering’); insert into department values (’ece’, ’Electrical and Computer Engineering’); insert into department values (’mae’, ’Mechanical and Aerospace Engineering’);

_ If the reference is user-deﬁned, the value for the self-referencing column must also be given

_ If the reference is derived, the primary key or the unique and not null constraints can be used in the table deﬁnition to ensure a unique reference value for the appropriate attributes

114 Type and Table Hierarchies (1)

_ Structured types and typed tables can be formed into superclass/subclass hierarchies _ Structured types are formed into a hierarchy using the under clause in the create type statement _ This supports the inheritance of attributes and methods of the supertype to the subtypes _ Typed tables are then created to correspond to the type hierarchy, also using an under clause _ Inheritance is also supported among the object instances of typed tables _ Structured type deﬁnitions for the Person, Student, and Faculty classes create type personUdt as ( personId varchar(11), firstName varchar(20), lastName varchar(20), birthDate date) instantiable not final ref is system generated; create type facultyUdt under personUdt as ( rank varchar(10)) instantiable not final; create type studentUdt under personUdt as ( status varchar(10)) instantiable not final;

_ Recall that structured types must always be deﬁned as not final _ The instantiable clause is required since these types are used with typed tables

115

Type and Table Hierarchies (2)

_ With the type hierarchy deﬁned, the corresponding typed tables can be created

_ Deﬁnition of the person, faculty, and student typed tables create table person of personUdt ( primary key (personId), ref is personID system generated); create table faculty of facultyUdt under person; create table student of studentUdt under person;

_ The under speciﬁcation of the subtables must be consistent with that of the corresponding types

_ Only single inheritance is supported ⇒ every subtype/subtable has one maximal supertype/supertable

_ A primary key can only be deﬁned for a maximal supertable, it is inherited by all of the subtables

_ Subtables can indirectly deﬁne keys through the use of the not null and unique constraints

_ A self-referencing column can only be deﬁned at the supertype/supertable level

_ Constraints can only be deﬁned on originally-deﬁned attributes and not on inherited attributes

_ Originally-deﬁned attributes: attributes introduced in the structured type on which the table is based

116 Type and Table Hierarchies (3)

_ Type hierarchies can be used independently of table hierarchies

_ In this case, use of the type hierarchy supports valued-based rather than object-based inheritance

_ The use of the not instantiable clause can only be used in type hierarchies that are not associated with typed tables

_ For example, a user can deﬁne a supertype A as not instantiable and then deﬁne B and C as instantiable subtypes of A

_ Since A is not instantiable, users cannot directly create instances of A but can directly create instances of B and C that inherit the attributes and methods of A

_ All types associated with a typed table hierarchy must be deﬁned as instantiable

_ As a result, abstract supertables and the total specialization constraint cannot be inherently enforced

117

Inserting Rows in a Table Hierarchy

_ Example: insert statements over the Person hierarchy insert into person values (’PP111’, ’Joe’, ’Smith’, ’2/18/82’); insert into person values (’PP222’, ’Alice’, ’Black’, ’2/15/80’); insert into student values (’ST333’, ’Sue’, ’Jones’, ’8/23/87’, ’freshman’); insert into student values (’ST444’, ’Joe’, ’White’, ’5/16/86’, ’sophomore’); insert into faculty values (’FA555’, ’Alice’, ’Cooper’, ’9/2/51’, ’professor’);

_ Each row has a most specific table that defines the type of the row _ This type corresponds to the type of the table in which the row is directly inserted _ Inserting a row in a table makes the row visible in all supertables of the table _ The row is not visible in any of the subtables of the table _ Once inserted, a row cannot migrate to other tables in the hierarchy _ This can only be achieved by deleting the row and reinserting it into a different table _ If the self-referencing column is system generated, the row will have a different reference value _ The contents of subtables are therefore always disjoint and cannot represent overlapping constraints

118 Querying a Table Hierarchy

_ In subtable/supertable relationships, an instance of a subtable is an instance of its supertable _ The query below over the person table returns the ﬁve names previously introduced select firstName || ’ ’ || lastName from person;

_ The query performs the union of the person table with all of the common attributes from rows of the subtables to return all direct instances of the person table as well as all instances of its subtables

_ The following query over the faculty table returns only one name select firstName || ’ ’ || lastName from faculty;

_ Unless otherwise speciﬁed, a query over a typed table returns the direct instances of the table as well as instances of its subtables and not instances of its supertables

_ The only option can be used in the from clause to retrieve only the direct instances of a table _ The following query returns two names select firstName || ’ ’ || lastName from only (person);

119

Deleting Rows from a Table Hierarchy

_ The following statement over the person table will delete any row from the table hierarchy with the ﬁrst name of Alice, even if the most speciﬁc type of the row is a student or a faculty delete from person where firstName = ’Alice’;

_ Deleting a tuple from a subtable also implicitly deletes the tuple from its supertables _ Once a row is removed from its most speciﬁc type, it is removed from the entire table hierarchy _ In the statement below the deletion of ‘Sue Jones’ from the student table will also result in ‘Sue Jones’ no longer being visible from the person table delete from student where firstName = ’Sue’ and lastName = ’Jones’;

_ It is possible to restrict the rows that are deleted using the only clause _ The following statement will delete rows from the person table only if the person does not have a most speciﬁc type of student or faculty delete from only (person) where firstName = ’Joe’;

_ As a result, the row for ‘Joe Smith’ is the only row deleted, the row for ‘Joe White’ still remains in the table hierarchy

120 Updating Rows in a Table Hierarchy

_ The update statement operates in a manner similar to the delete statement _ Example: change the ﬁrst name of each row in the person table and in any of its subtables update person set firstName = ’Suzy’ where firstName = ’Sue’;

_ As a result, the name of ‘Sue Jones’ in the student table will be changed _ To restrict an update operation to rows that do not appear in any subtables, the only clause is used _ The query below will change the ﬁrst name of Joe Smith in the person table and not the ﬁrst name of Joe White in the student table update only (person) set firstName = ’Joey’ where firstName = ’Joe’;

_ The condition in the where clause of an update statement also applies to all rows that are in supertables of the table identiﬁed in the update statement

_ The set clause is ignored if it refers to attributes that do not appear in the supertable

121

Reference Types

_ The self-referencing column is the internal object identiﬁer, or reference, to a row _ This reference is a data type known as a reference type, or ref _ Reference types can be used to model associations between typed tables that are based on object identity rather than on foreign keys

_ Using reference types for deﬁning relationships of a club with faculty and student objects create type campusClubUdt as ( ... advisor ref(facultyUdt), members ref(studentUdt) array[50]) ... ; create table campusClub of campusClubUdt ( primary key (clubId), ref is campusClubId system generated);

_ The name of the self-referencing column of the faculty table can be used to assign a ref value update campusClub set advisor = ( select personID from person where firstName = ’Alice’ and lastName = ’Cooper’) where name = ’Computer Club’;

_ Arrays of references (e.g., members) are generally manipulated through the use of SQL routines

122 Scopes and Reference Checking

_ A scope clause can be used to restrict reference values to those from a speciﬁc typed table

_ Redeﬁnition of the advisor attribute in campusClubUdt advisor ref(facultyUdt) scope faculty references are checked on delete set null;

_ If the clause is omitted, the reference value can be a row from any table having the speciﬁed type

_ If the clause is speciﬁed, a reference scope check can also be speciﬁed, i.e., dangling references (invalid reference values) are not allowed

_ By default, references are not checked

_ The on delete clause allows the user to specify the same referential actions as used with referential integrity for foreign keys

_ In the example above, the deletion of a referenced faculty object will cause the advisor attribute to be set to null

_ Speciﬁcation of table scopes and reference checks can also be done during the creation of typed tables

123

Querying Reference Types

_ Reference values are typically used to accessing some attribute of the row that is being referenced

_ The dereference operator -> is used to traverse through object references

_ Give the name of the advisor of the Computer Club select advisor -> firstName, advisor -> lastName from campusClub where name = ’Computer Club’;

_ The dereference operator is used to implicitly join the campusClub and faculty tables based on the reference value

_ The deref() function returns the entire structured type that is associated with a reference value

_ Give the advisors of campus clubs that are located in the Brickyard Building select deref (advisor) from campusClub c where c.location.building = ’Brickyard Building’;

_ The result of the query is a table with one column of type facultyUdt

124 School Database Example: SQL Object-Relational Schema (1) create type personUdt as ( personId varchar(11), firstName varchar(20), lastName varchar(20), birthDate date) instantiable not final ref is system generated; create type facultyUdt under personUdt as ( rank varchar(10), advisorOf ref(campusClubUdt) scope campusClub array[5] references are checked on delete set null, worksIn ref(departmentUdt) scope department references are checked on delete no action, chairOf ref(departmentUdt) scope department references are checked on delete set null) instantiable not final; create type studentUdt under personUdt as ( status varchar(10), memberOf ref(campusClubUdt) scope campusClub array[5] references are checked on delete set null, major ref(departmentUdt) scope department references are checked on delete no action) instantiable not final;

125

School Database Example: SQL Object-Relational Schema (2) create table person of personUdt ( primary key(personId), ref is personID system generated); create table faculty of facultyUdt under person; create table student of studentUdt under person; create type departmentUdt as ( code varchar(3), name varchar(40), deptChair ref(facultyUdt) scope faculty references are checked on delete no action) instantiable not final ref is system generated method getStudents() returns studentUdt array[1000], method getFaculty() returns facultyUdt array[50]; create table department of departmentUdt ( primary key (code), deptChair with options not null, ref is departmentID system generated);

126 School Database Example: SQL Object-Relational Schema (3) create type locationUdt as ( street varchar(30), building varchar(5), room varchar(5)) not final; create type campusClubUdt as ( clubId varchar(10), name varchar(50), location locationUdt, phone varchar(12), advisor ref(facultyUdt) scope faculty references are checked on delete cascade, members ref(studentUdt) scope student array[50] references are checked on delete set null) instantiable not final ref is system generated; create table campusClub of campusClubUdt ( primary key(clubIdd), ref is campusClubID system generated);

127

Object Databases: Topics

_ Object-Oriented Databases • ODMG • Linq

_ Object-Relational Databases • SQL y Oracle

_ Summary

128 School Database Example: Entity Relationship Schema

Person

personId firstName lastName birthDate (t,e)

major (1,1) worksIn Student CampusClub Faculty (1,1) status clubId rank name (0,1) (0,n) memberOf location advisorOf (0,n) chairOf street members building advisor Clubs room Advises (0,n) phone (0,1)

deptChair Department Chair (1,1) code HasMajor name (0,n) getFaculty() getStudents() FacDept (0,n)

129

Object Types

_ Object type: a composite structure that can have a set of attributes and methods create or replace type person_t as object ( personId varchar2(9), firstName varchar2(20), lastName varchar2(20), birthDate date);

_ Oracle deﬁnition of an object type does not require the instantiation, ﬁnality, and reference generation clauses as in the SQL standard

_ To assign values to an object type, a variable can be created having the type of the object type declare p person_t; begin p.personId := ’PR123456789’; p.firstName := ’Terrence’; p.lastName := ’Grand’; p.birthDate := ’10-NOV-1975’; end;

130 Embedded Objects

_ Oracle does not support row types from the SQL standard

_ When an object type is used as the attribute value of another object type, the attribute value is referred to as an embedded object

_ Embedded objects do not have object identiﬁers, but provide a way to deﬁne an attribute as containing a composite value

_ Example: the location attribute of the campusClub_t object type is used as an embedded object create or replace type location_t as object ( street varchar2(30), building varchar2(5), room varchar2(5)); create or replace type campusClub_t as object ( clubId number, name varchar2(50), phone varchar2(25), location location_t, ... );

131

Column Objects

_ When an object type is used as the type of a column in a traditional relational table, the value is referred to as a column object

_ Embedded and column objects are accessed and manipulated in the same way as structured types

_ Example: A table deﬁnition with a column object loc create table courseOffering(code int, loc location_t);

_ Data can be inserted into the table using the type constructor for location_t insert into courseOffering values (123, location_t(’Orange Mall’, ’CPCOM’, ’207’));

132 Methods

_ The methods of an object type are functions or procedures that model the behavior of objects

_ Methods in the SQL standard are limited to functions only

_ The self parameter is an instance of the object type on which a method is invoked

_ Example: Deﬁnition of a function that determines whether a faculty member is an advisor of a club create or replace type body campusClub_t is ... member function isAssociatedAdvisor (candidate_advisor in ref faculty_t) return boolean is begin return (self.advisor = candidate_advisor); end isAssociatedAdvisor; end;

_ Methods are implemented in the object type body deﬁnition for campusClub_t

133

Method Pragmas

_ The declaration of functions are accompanied by a pragma declaration create or replace type campusClub_t as object ( ... member function isAssociatedAdvisor (candidate_advisor in ref faculty_t) return boolean, pragma restrict_references(default, wnds, wnps));

_ Pragmas are compiler directives, they do not affect the meaning of a program _ Pragma restrict_references is used to control side effects in a function, asserting that a function does not read/write any database tables and/or package variables _ Syntax: pragma restrict_references (function_name, option [, option]) _ default can be used to specify that the pragma applies to all functions in the type definition _ The pragma options are the following • wnds: Writes no database state (does not modify database tables) • rnds: Reads no database state (does not query database tables) • wnps: Writes no package state (does not change the values of package variables) • rnps: Reads no package state (does not reference the values of package variables)

134 Constructor Methods

_ Every object type has a system-deﬁned constructor method

_ It is a method that creates a new instance of an object type and sets up the values of its attributes

_ The name of the constructor method is the name of the object type

_ Its parameters have the names and types of the object type’s attributes

_ It is a function that returns an instance of an object type as its value

_ Example: invocation of a constructor method that returns an instance of the person_t object type person_t(’PR123456789’, ’Terrence’, ’Grand’, ’10-NOV-1975’)

_ Unlike the deﬁnition of constructor methods in the SQL standard, the built-in constructor for an object type in Oracle accepts parameter values for the attributes of the type

135

Type Inheritance

_ A type hierarchy is speciﬁed by creating an object type as a supertype and by deﬁning one or more subtypes of the supertype

_ Example: student_t deﬁned as subtype under person_t create or replace type student_t under person_t ( status varchar2(10), major ref department_t, --relation major memberOf campusClub_array, --relation memberOf member function getClubs return string_array, pragma restrict_references (default, wnds, wnps)) final;

_ Objects of type student_t inherit the attributes of person_t and also deﬁne additional attributes and methods

_ As a supertype, person_t must be defined as not final so that subtypes can be defined

_ Unlike the SQL standard, a type at the bottom of the type hierarchy can be speciﬁed as ﬁnal

136 Object Tables

_ Tables in which each row represents an object, each object has a unique object identiﬁer (OID) _ Objects that occupy complete rows in object tables are called row objects _ Row objects can be referenced in other row objects or relational rows using its OID _ The unique OID value speciﬁed as either system-generated (default) or based on the primary key _ Example: creation of an object table person based on the object type person_t create table person of person_t ( personId primary key, firstName not null, lastName not null, birthDate not null) object id system generated;

_ The ref is clause of the SQL standard is replaced by the object id clause _ Table and column constraints can be deﬁned in the speciﬁcation of the object table _ As a deviation from the SQL standard, object tables in Oracle cannot be formed into table hierarchies _ Instead, Oracle supports the concept of substitutable tables

137

Substitutable Tables

_ Substitable tables are capable of storing multiple object types from a type hierarchy _ They have the polymorphic capability to store an object of a supertype and any subtype that can be substituted for the supertype

_ The person table above is a substitutable table: it is associated with the supertype of a type hierarchy _ It is capable of storing objects of type person_t as well as objects of its subtypes _ Inserting row objects in substitutable tables insert into person_table values (person_t(’101’,’Sue’,’Jones’,’05/16/1955’)); insert into person_table values (student_t(’102’,’Jim’,’Duncan’,’03/12/1989’, ’senior’,get _dref(’CSE’),null); insert into person_table values (faculty_t(’103’,’Joe’, ’Smith’,’10/21/1960’, ’Professor’,null,get_dref(’CSE’),null);

_ Each insert statement indicates the speciﬁc type of the object and includes values for attributes of person_t as well as values for the attributes of the subtype

_ The insert statements invoke the get_dref function, which is passed the name of a department and returns a reference to the associated department object (see later)

138 Reference Types (1)

_ Reference types (refs) can be used to deﬁne object-to-object relationships

_ A ref is a logical pointer to a row object

_ Example: a ref type is used to model the chair relationship between department_t and faculty_t create or replace type department_t as object ( ... deptChair ref faculty_t, ...);

_ A ref column or attribute can be constrained using a scope clause or a referential constraint clause

_ When a ref column is unconstrained, it may store object references to row objects contained in any object table of the corresponding object type

_ Unconstrained references may also lead to dangling references

_ Currently, Oracle does not permit storing object references that contain a primary-key based object identiﬁer in unconstrained ref columns

139

Reference Types (2)

_ A ref column may be constrained with a referential constraint similar to foreign keys _ Example: Specifying a column referential constraint on the deptChair column create table department of department_t ( ... foreign key(deptChair) references person on delete set null ... )

_ A ref stored in a deptChair column must point to a valid row object in the person object table _ This also implicitly restricts the scope of deptChair to the person object table _ A scope clause can be used for constraining a ref column by being scoped to a speciﬁc object table _ The scope constraint , referential constraint: the scope constraint has no implications on the referenced object (i.e., deleting a referenced object can still cause a dangling reference)

_ Alternatively, the scope clause can be used to constrain the deptChair column to refer to objects in the person table alter table department add (scope for (deptChair) is person);

_ The unique and primary key constraints cannot be speciﬁed for ref columns _ A unique index may be created on a scoped ref column to ensure uniqueness of the ref values

140 Using Reference Types (1)

_ Queries involving objects make a distinction between row objects, refs, and object types

_ Oracle provides three functions to support queries involving objects • ref(): takes a row object as its argument and returns the ref to that object • value(): takes a row object as its argument and returns the instance of the object type • deref(): takes a ref to an object as its argument and returns the instance of the object type

_ The only diﬀerence between value and deref is the input to each function

_ In both cases, the output is the instance of the object type (i.e., a tuple of attribute values) associated with the object

141

Using Reference Types (2)

_ Example code declare club_ref ref campusClub_t; club campusClub_t; club_adv faculty_t; begin select value(c), ref(c), deref(c.advisor) into club, club_ref, club_adv from campusClub c where c.name=’The Hiking Club’; end;

_ The table alias c contains a row object _ value(c) used to see the values of the attributes of the row object as deﬁned in the object type _ ref(c) used to get the ref to the row object _ deref() used to get values of the attributes of the object type associated with a ref _ In the above query, club will contain a campusClub_t object type instance, club_ref will contain the ref of the object, and club_adv will contain an instance of the faculty_t object type _ Since c.advisor is a ref to faculty_t, the deref function is applied to return the object type

142 Using Reference Types (3)

_ The get_dref function was used previously to retrieve the ref to a speciﬁc department object create or replace function get_dref(d_code in varchar2) return ref department_t is d_ref ref department_t; cursor cr is select ref(d) from department d where d.code = d_code; begin open cr; fetch cr into d_ref; close cr; return d_ref; end get_dref;

_ The select statement retrieves a department object using the code attribute and returns the reference to the object for assignment to an attribute that is deﬁned to be of type ref department_t

_ The query below returns the name of the department in which the advisor of the Computer Club works select c.advisor.worksIn.name from campusClub c where c.name = ’Computer Club’;

_ The expression c.advisor.worksIn.name is a path expression, representing implicit joins between the object tables involved

143

Querying Substitutable Tables (1)

_ A substitutable table contains a heterogeneous collection of objects from a type hierarchy

_ Queries over the table may need to indicate the speciﬁc types of objects to be returned

_ The following select statement will return information about all objects in the person table select value(p) from person_table p;

_ The is of clause used to retrieve details only about objects that are subtypes of the type of the table

_ The query below will only return objects of type student_t from the person table select value(p) from person_table p where value(p) is of (student_t);

144 Querying Substitutable Tables (2)

_ The treat function can be used to treat a supertype instance as a subtype instance

_ This is useful for assigning a variable to a more specialized type in a hierarchy and accessing attributes or methods of a subtype

_ The following query creates a view of student objects create or replace view student(personId, firstName, lastName, birthDate, status, major, memberOf) as select personId, firstName, lastName, birthDate, treat(value(p) as student_t).status, treat(value(p) as student_t).major, treat(value(p) as student_t).memberOf from person p where value(p) is of (student_t);

_ The is of clause is used to indicate that the view should include objects of type student_t

_ The treat function is used to access the attributes that are speciﬁc to the student_t object type

145

Varrays and Nested Tables as Collections (1)

_ Variable-sized arrays (varrays) and nested tables can be used to represent the many side of 1:N and M:N relationships

_ Whereas a varray is an indexed collection of data elements of the same type, a nested table is an unordered set of data elements of the same data type

_ Maximum size must be specified when an attribute of type varray is defined, it can be changed later _ To define an attribute as a varray, a varray type definition must first be created _ Creating a varray type does not allocate space, simply defines a data type that can be used elsewhere _ Example: varray type definition used to model the many side of the Clubs relationship create or replace type campusClub_array as varray(50) of ref campusClub_t; create or replace type student_t under person_t ( ... memberOf campusClub_array, ...)

_ Example: varray deﬁnitions for student_array, used as output in the getStudents function create or replace type student_array as varray(50) of ref student_t; create or replace type department_t as object ( ... member function getStudents return student_array, ...)

146 Varrays and Nested Tables as Collections (2)

_ A nested table has a single column, where the type of the column is a built-in type or an object type

_ If the column in a nested table is an object type, the table can also be viewed as a multi-column table, with a column for each attribute of the object type

_ DML statements on nested tables such as select, insert, and delete are the same as with regular relational tables

_ In a nested table, the order of the elements is not deﬁned

_ Nested tables are stored in a storage table with every element mapping to a row in the storage table

_ Example: a nested table type deﬁnition for the student_ntable nested table create or replace type student_ntable as table of ref student_t; create or replace type campusClub_t as object ( ... members student_ntable, ... );

_ The contents of the nested table are of type ref student_t

_ The type deﬁnition is used to deﬁne the members attribute in campusClub_t

147

Varrays and Nested Tables as Collections (3)

_ Example: Specifying the storage table of the club_members nested table create table campusClub of campusClub_t ( ... ) object id system generated nested table members store as club_members; alter table club_members add(scope of (column_value) is person); create unique index club_members_idx on club_members(nested_table_id, column_value);

_ The programmer accesses the nested table using the name members _ The name club_members is used internally by Oracle to access and manipulate the nested table _ The scope constraint indicates that the values stored in the ref column must be references to row objects in the person table

_ Unique index restrict the uniqueness of the ref values _ nested_table_id: pseudocolumn that holds the row identiﬁer of the storage table _ column_value: pseudocolumn that holds the contents of the nested table, in this case, a ref of type student_t

148 Comparison of Varrays and Nested Tables (1) Varrays

_ A varray cannot be indexed

_ A varray declaration must specify the maximum number of objects to hold

_ A varray is dense in that all positions from the ﬁrst to the lastmust be ﬁlled. Individual elements cannot be deleted from a varray to leave a null value in an array position

_ The elements of a varray are ordered

_ If the size of the varray is smaller than 4000 bytes, Oracle stores the varray in line; if it is greater than 4000 bytes, Oracle stores it in a Binary Large Object (BLOB)

149

Comparison of Varrays and Nested Tables (2) Nested Tables _ A nested table is an unordered set of data elements, all of the same data type having a single column _ The type of the column in the nested table is either a built-in type or an object type _ If an object type is used as the type of the column, the table can be viewed as a multi-column table, with a column for each attribute of the object _ Nested tables are stored in a separate storage table and can be indexed for eﬃcient access _ Nested tables are sparse (i.e., individual elements can be deleted from a nested table) In Summary _ The choice depends on the nature of the values or objects stored in the collection _ Nested table used when the number of objects in a multivalued attribute or relationship is large _ Varray used when the number of objects contained in a multivalued attribute is small and does not change _ Consult Oracle 11g documentation for further details about accessing and modifying varrays and nested tables

150 School Database Example: Oracle Object-Relational Schema (1) create or replace type campusClub_t; create or replace type campusClub_array as varray(50) of ref campusClub_t; create or replace type string_array as varray(50) of varchar2(50); create or replace type location_t as object ( street varchar2(30), building varchar2(5), room varchar2(5)); create or replace type person_t as object ( personld varchar2(9), firstName varchar2(20), lastName varchar2(20), birthDate date) not final; create or replace type department_t; create or replace type student_t under person_t ( status varchar2(10), major ref department_t, --relation major memberOf campusClub_array, --relation memberOf member function getClubs return string_array, pragma restrict_references (default, wnds, wnps)) final;

151

School Database Example: Oracle Object-Relational Schema (2) create or replace type faculty_t under person_t ( rank varchar2(25), advisorOf campusClub_array, --relation advisorOf worksIn ref department_t, --relation worksIn chairOf ref department_t, member function getClubsAdvised return string_array, pragma restrict_references(default, wnds, wnps)) final; create table person of person_t ( personId primary key, firstName not null, lastName not null, birthDate not null) object id system generated;

152 School Database Example: Oracle Object-Relational Schema (3) create or replace type student_array as varray(50) of ref student_t; create or replace type faculty_array as varray(50) of ref faculty_t; create or replace type department_t as object ( code varchar2(3), name varchar2(40), deptChair ref faculty_t, member function getStudents return student_array, member function getFaculty return faculty_array, pragma restrict_references(default, wnds, wnps)); create table department of department_t ( code primary key, name not null, constraint department_chair foreign key(deptChair) references person on delete set null) object id system generated; create or replace type student_ntable as table of ref student_t;

153

School Database Example: Oracle Object-Relational Schema (4) create or replace type campusClub_t as object ( clubId number, name varchar2(50), phone varchar2(25), location location_t, advisor ref faculty_t, --relation advised by members student_ntable, --relation member of constraint club_advisor foreign key (advisor) references person on delete set null, member function isAssociatedMember (candidate_member in ref student_t) return boolean, member function isAssociatedAdvisor (candidate_advisor in ref faculty_t) return boolean, pragma restrict_references(default, wnds, wnps)); create table campusClub of campusClub_t ( clubId primary key, name not null) object id system generated nested table members store as club_members; alter table club_members add(scope of (column_value) is person); create unique index club_members_idx on club_members(nested_table_id, column_value);

154 Object-Relational Features: Summary

_ Extension of the standard relational model with object features

_ This includes row types for representing composite values, arrays for representing collections, and user-deﬁned types

_ User-defined types can be distinct types for defining domains, and structured types for defining the equivalent of classes in OPL

_ Structured types allow to deﬁne inheritance hierarchies

_ Structured types together with typed tables allow to deﬁne object-based inheritance hierarchies

_ Reference types allow to store the identiﬁer (or reference) of object rows

_ Reference types can be restricted in a similar way as for referential integrity

_ Nevertheless, the resulting model is hybrid, it aims at converging two paradigms

_ The implementations of the object-relational features varies across systems

155

Bibliographic References

_ The Object-Oriented Database System Manifesto was prepared by researchers of OODB technology [Atkinson et al., 1990]

_ In response, researchers in relational database technology prepared the Third Generation Database System Manifesto [Stonebraker et al., 1990] which outlined the manner in which relational technology could be extended to support object-oriented features

_ The feasibility of object-relational technology was demonstrated with the development of Postgres [Rowe and Stonebraker, 1987], an object-relational version of Ingres (an early relational database prototype and research tool)

_ Additional sources of information about object-relational technology can be found in [Brown, 2001, Date and Darwen, 1998, Stonebraker, 1995]

_ Object-relational features of the SQL standard are described in [Melton, 2002] with additional information about arrays and row types in [Gulutzan and Pelzer, 1999, Melton and Simon, 2001]

_ A description of the object-relational features of Oracle 11g can be found in Oracle’s documentation

156 References _ M. Atkinson et al. The object-oriented database system manifesto. In Proc. of the 1st Int. Conf. on Deductive and Object-Oriented Databases, Kyoto, Japan. Elsevier, 1990 _ P. Brown. Object-Relational Database Development: a Plumber’s Guide, Prentice Hall, 2001. _ C.J. Date and H. Darwen. Foundations for Object/Relational Databases: The Third Manifesto, Addison- Wesley, 1998. _ P. Gulutzan and T. Pelzer. SQL-99 Complete Really!, Miller Freeman, 1999. _ J. Melton. Advanced SQL:1999 Understanding Object-Relational and Other Advance Features, Mor- gan Kaufmann, 2002. _ J. Melton and A. Simon. SQL:1999 Understanding Relational Language Components, Morgan Kauf- mann, 2001. _ L. Rowe and M. Stonebraker. The Postgres Data Model. In Proc. of the 13th Int. Conf. on Very Large Data Bases, pages 83-96, 1987. _ M. Stonebraker, Object-Relational DBMSs: The Next Great Wave, Morgan Kaufmann, 1995. _ M. Stonebraker et al. Third Generation Database System Manifesto. In SIGMOD Record, vol. 19, no. 3, pages 31-44, 1990.

157