1. 1 Object Oriented Databases Ioan Despi 1. Advanced Database Applications 2. Object-Oriented Concepts 3. OODBMS 4. Common Issues 4. ODMG 2.0

2. 2 1. Advanced Database Applications RDBMS:widespread acceptance for traditional business applications: order processing, inventory control, banking, airline reservations proven inadequate for new technologies: computer-aided design (CAD), computer-aided manufacturing (CAM), computer-aides software engineering (CASE), office information systems and multimedia systems, digital publishing, geographic information systems

3. 3 Disadvantages of Relational DBMS: Poor representation of “real world” entities. Semantic overloading Poor support dor integrity and enterprise constraints. Homogenous data structure. Limited operations. Difficulty handling recursive queries Impedance mismatch. Other problems concerning: concurrency, schema access, navigational access, and so on

4. 4 2. Object- Oriented Concepts Abstraction: the process of identifying the essential aspects of an entity and ignoring the unimportant properties. 1. Encapsulation: an object contains both the data structure and the set of operations that can be used to manipulate it. 2. Information hiding: we separate the external aspects of an object from its internal details, which are hidden from the outside world. The internal details of an object can be changed without affecting the application that use it. Loosely speaking, an object correspond to an entity in the ER model. The object -oriented paradigm is based on encapsulating data and code related to an object into a single unit.

5. 5 The current state of an object is described by one or more attributes, or instance variable. The value of each variable is itself an object. 1. A simple attribute: can be a primitive type (integer, string, real,… 2. A complex-attribute: can contain collections and/or references 3. A reference attribute: represents a relationship between objects contains a value or collection of values, which are themselves objects (like a Foreign Key or a pointer) Complex object: an object that contains one or more complex attributes Notation: “dot” notation: branch.street, branch.manager, branch.city Object=a uniquely identifiable entity that contains both the attributes that describe the state of the object and the actions that are associated with it, that is its behaviour.(Simula)

6. 6 The behaviour of an object is given by: a set of messages to which the object responds each message may have 0, 1 or more parameters a set of methods, each of which is a body of code to implement a message a method returns a value as the response to the message The physical representation of data is visible only to the implementor of the object. Messages and responses provide the only extenal interface to an object. The term message does not necessarily imply physical message passing. Messages can be implemented as procedures calls.

7. 7 Attributes Method 1 Method 4 Method 3 Method 2 Object showing attributes and methods

8. 8 Methods are programs written in a general-purpose language respecting thee following restrictions: 1. Only variables in the object itself may be referenced directly 2. Data in other objects are referenced only by sending messages They can be used to change the object’s state by modifying its attribute values, or to query the values of selected attributes. A method consists of a name and a body that performs the behavior associated with the method name: method void update_salary (float increment) { salary = salary + increment; }

9. 9 Messages are the means by which objects communicate. A message is simply a request from an object (the sender) to another object (the receiver)asking the second object to execute one of its methods. The sender and receiver may be the same object. The “dot” notation is generally used to access a method. staff_object.update_salary(1000) In a traditional programming language, a message would be written as a function call: update_salary(staff_object, 1000)

10. 10 Object classes Similar objects (have the same attributes, respond to the same messages) are grouped into a class. The attributes and associated methods are defined once for the class. Al objects in a class have the same: variable types message interface methods They may differ in the values assigned to variables Classes are analogous to entity sets in the ER model. Example: all branch objects would be described by a single Branch class.

11. 11 BRANCH Attributes bno street city area … Methods print update_tel_no …. bno=B5 street=12 Deer St city=Sidcup area=London... bno=B7 street=16 Dever St city=Dyce area=Aberden... bno=B3 street=154 Main St city=Partick area=Glasgow...

12. 12 A class is an object ===>has is own class attributes and class methods The class is an instance of a higher-level class called metaclass Class attributes describes the general characteristics of the class, such as totals or averages( ex: total no of branches) Class methods are used to change or query the state of class attributes There are special class methods to create new instances of the class: new --constructor destructor In the following example, employment-length is a derived attribute. For strict encapsulation, methods to read and set other variables are also needed

13. 13 class employee { /*Variables */ string name; stringaddress; datestart-date; intsalary; /* Messages */ intannual-salary; stringget-name; stringget-address; intset-address ( string new-address) intemployment-length; };

14. 14 Inheritance Inheritance allows one class (subclass) to be defined as a special case of a more general class (superclass). The process of forming a superclass is referred to as generalization. The process of forming a subclass is referred to as specialization. By default, a subclass inherits all the properties of its superclass(es) and, additionally, defines its own unique properties. A subclass can redefine inherited methods. All instances of the subclass are also instances of the superclass. Principle of substitutability: we can use an instance of the subclass whenever a method or a construct expects an instance of the superclass..

15. 15 The relation between the subclass and superclass: A KIND OF (AKO) The relation between an instance and its class: IS-A. Examples: Manager is AKO Staff. Susan Deer IS-A Manager. Inheritance: 1. Single inheritance: the subclass inherits from no more than one superclass 2. Multiple inheritance: the subclass inherits from more than one superclass ===> conflicts!

16. 16 Staff Person ManagerSales_Staff Manager Sales_Staff Sales_Manager Single inheritance Multiple inheritance

17. 17 3. Repeated inheritance: a special case of multiple inheritance superclasses inherit from a common superclass The inheritance mechanism must ensure that the subclass does not inherits properties twice. Staff ManagerSales_Staff Sales_Manager 4. Selective inheritance:allows a subclass to inherit a limited number of properties from the superclass.

18. 18 Object Identity Each object is assigned an Object Identifier (OID) when it is created that is: system generated unique to that object invariant independent of the values of its attributes inivisible to the user Other concepts: overriding (+ overloading) polymorphism & dynamic binding complex objects persistence

19. 19 3. OODBMS Hierarchical Data Model Network Data Model Relational Data Model ER Data Model Semantic Data Model Object-Relational Data ModelObject Oriented Data Model 1960 - 1970 First generation DBMS 1970 - 1980 Second generation DBMS E. Codd, 1970 IMS Chen, 1976 Third generation DBMS Hammer, McLeod, 1981 1980-2000

20. 20 OODM:a logical data model that captures the semantics of objects supported in oo programming OODB:a persistent and sharable collection of objects defined by an OODM OODBMS:the manager of an OODB (W. Kim 1991) Zdonik &Maier(1991) ---An OODBMS must (at minimum) satisfy: must provide database functionality must support object identifier must provide encapsulation must support objects with complex state or (Khoshafian &Abnous 1990) object oriented= ADT + Inheritance + OID OODBMS= OO + database capabilities

21. 21 Traditional DBMS persistence sharing transasctions concurrency control recovery control security integrity quering Semantic data models generalization aggregation OO programming object identity encapsulation inheritance types & classes methods complex objects polymorphism extensibility Special requirements versionong schema evolution Object Oriented Data Model

22. 22 Strategies for Developing an OODBMS: 1. Extend an existing object-oriented programming language with database capabilities. Smalltalk, C++, Java --> GemStone 2. Provide extensible object-oriented DBMS libraries. Ontos, Versant, ObjectStore 3. Embed object-oriented database language constructs in a convenient host language. O 2 embeds OODL in C. 4. Extend an existing database language with object-oriented capabilities. Extend SQL--> SQL3, OQL. 5. Develop a novel database data model / data language. SIM (semantic information manager, 1988).

23. 23 OODBMS Perspectives: Modern database systems are characterized by their support of the following features: 1. Data model: a particular way of describing data, relationships between data, and constraints on the data 2. Data persistence: the ability of data to outlive the ecxecution of a program, and possibly thee lifetime of the program itself. 3. Data sharing: the ability of multiple applications to access common data, possibly at the same time 4. Reliability: the assurance that the data in the database is protected from hardware and software failures 5. Security : the protection of the data against unauthorized access

24. 24 7. Integrity: the assurance that the data conforms to specified correctness and consistency rules 8. Distribution: the ability to physically distribute a logically interrelated collection of shared data over a network Traditional programming languages provide: 1. Constructs for procedural control and for data and functional abstraction 2. Lack built-in support for many of the above database features Novel applications require functionality from both perspectives.

25. 25 Issues: 1. Persistence: objects must survive user session or application program that created them has terminated transient objects:only last for the invocation of the program To implement persistence in OODB: 3 schemes A. Checkpointing:copy all or part of a program’s address space to secondary storage a checkpoint can only be used by the program that created it a checkpoint may contain a large amount of data that is of no use in subsequent executions

26. 26 B. Serialization:copy the closure of a data structure to disk. A write operation on a data value involves the traversal of the graph of objects reachable from the value and, then, the writing of a flattened version of the structure to disk. Reading back this flattened structure: serialization, pickling, marshaling. Does not preserve object identity: if two data structures that share a common sunstructure are separately serialized, then on retrieval the substructure will no longer be shared in the new copies. It is not incremental, and so saving small changes to a large data structure is not efficient.

27. 27 C. Explicit paging: paging objects between the application heap and the persistent store. Requires the conversion of object pointers from a disk-based scheme to a memory-based scheme. There are two common methods for creating/updating persistent objects: a. Reachability-based: an object will persist if it is reachable from a persistent root object at any time after creation, an object can become persistent by adding it to the reachability tree. Garbage collection: deletes objects when they are no longer accessible from any other object Smalltalk, Java

28. 28 b. Allocation-based: an object is explicitely declared as being persistent within the application program i) By class:  a class is statically declared to be persistent --> all instances of the class are made persistent when they are created  a clas may be a subclass of a system- supplied persistent class Ontos, Objectivity/DB ii) By explicit call: an object may be specified as persistent when it is created or, in soome cases, dynamically at runtime (added to a persistent collection) ObjectStore

29. 29 Alternatively, to provide persistence in a programming language: orthogonal persistence, based on the following principles: 1. Persistence independence: the persistence of a data object is independent of how the program manipulates the data object and conversely, a fragment of the program is expressed independently of the persistence of data it manipulates. 2. Data type orthogonality: all data objects should be allowed the full range of persistence irrespective of their type: Ps-algol, Napier88, Galileo, GemStone Persistence is only a quality attributable to a subset of the language data types: Pascal/R, Amber, E, Avalon/C++ 3. Transitive persistence: the choice of how to identify and provide persistent objects at the language level is independent of the choice of data types in the language. Most used technique: reachability-based.

30. 30 Orthogonal persistence: Advantages: 1. There is no need to define long-term data in a separate schema language 2. No special application code is required to access or update persistent data 3. There is no limit to the complexity of the data structures that can be made persistent 4. Improved programmer productivity from simpler semantics 5. Improved maintenance 6. Consistent protection mechanisms over the whole environment 7. Support for incremental evolution 8. Automatic referential integrity

31. 31 Issues: 2. Pointer Swizzling Techniques: the action of converting object identifiers (OIDs) to main memory pointers, and back again Aim: to optimize access to objects. Obvious approach: to hold a lookup table that maps OIDs to main memory pointers Pointer swizzling: stores the main memory pointers in the place of the referenced OIDs and vice versa, when the object has to be written back to disk

32. 32 A. No swizzling: the OID is used every time the object is accessed the system maintains a lookup table, so that the object’s virtual memory pointer can be located and then used to access the object. Could be inefficient if the same objects are accessed repeatedly Could be acceptable if applications access an object once B. Object referencing: to be able to swizzle a persistent object’s OID to a virtual memory pointer, a mechanism is required to distinguish between resident and non-resident objects. Most techniques are variations of edge marking or node marking: (Hoskings&Moss, 1993):

33. 33 Virtual memory is considered to be a directed graph, with objects as nodes and references as directed edges: 1. Edge marking marks every object pointer with a tag bit. If the bit is set, then the reference is to a virtual memory pointer Otherwise, it is still pointing to an OID and needs to be swizzled when the object it referes to is faulted into the application’s memory space. 2. Node marking requires that all object references are immediately converted to virtual pointers when the object is faulted into memory. 1 is a software-based technique; 2 can be implemented using software or hardware-based techniques.

34. 34 C. Hardware-based schemes: use virtual memory access protection violations to detect accesses of non-resident objects(Lamb91) Use the standard virtual memory hardware to trigger the transfer of persistent data from disk to main memory. Once a page has been faulted in, objects are accessed on that page via normal virtual memory pointers. The hardware approach avoids the overhead of residency checks incurred by software approaches but limits the amount of data that can be accessed during a transaction to the size of virtual memory and complicates other issues, like recovery, fine-grained locking, aso. ObjectStore, Texas

35. 35 Issues: 3. Transactions in classical DBMSs: short duration transactions in CAD, CASE,…: long duration transactions (hours, days) a need for new protocols: nested transactions, sagas, multi-level transactions. 4. Versions: Ontos, Versant, ObjectStore, Objectivity/DB, Itasca object version = an identifiable state of an object version history = the evolution of an object version management = object references always point to the correct version of an object

36. 36 Types of versions: 1. Transient version: unstable, can be updated and deleted it can be created from new by checking out a released version from a public database or by deriving it from a working or transient version in a private database, when the base transient version is promoted to a working version. Always sored in the creator’s private workspace. 2. Working version: stable and cannot be updated but it can be deleted by its creator. It is stored in the creator’s private workspace. 3. Released version: stable, cannot be updated or deleted. it is stored in a public database by checking in a working version from a private database

37. 37 Issues: 5. Schema evolution: design is an incremental process. To support this process, applications require flexibility in dynamically defining and modifying the database schema. Typical changes to the schema include: changes to the class definition: modifying attributes, modifying methods changes to the inheritance hierarchy: making a class S the superclass of a class C, removing a class S from the list of superclasses of C, modifying the order of superclasses of C changes to the set of classes: creating and deleting classes, modifying class names

38. 38 Client - Server Architectures: 1. Object server: distributes the processing between the two components Server process: responsible for managing storage, locks, commits to secondary storage, logging, recovery, security, query optimization and executing stored procedures Client process: responsible for transaction management and interfacing to the programming languages 2. Page server:most of the database processing is performed by the client. Server process: responsible for secondary storage and for providing pages at the client’s request

39. 39 3. Database server: most of the database processing is performed by the server. Client process: passes requests to the server, receives results and passes them on to the application. Used by relational DBMS In each case, the server resides on the same machine as the physical database. The client may reside on the same or different machine. If the client needs access to databases distributed across multiple machines, then the clients communicates with a server on each machine. There may be a number of clients communicating with one server: for example, one client for each user or application.

40. 40 Advantages od OODBMSs: enriched modeling capabilities extensibility removal of impedance mismatch more expressive query language support for schema evolution support for long duration transactions aplicability to advanced database applications improved performance

41. 41 Disadvantages of OODBMSs: lack of universal data model lack of experience lack of standards query optimization compromises encapsulation locking at object level may impact performance complexity lack of support for views lack of support for security

42. 42 Object Database Standard ODMG 2.0 1997 Object Database Management Group proposed an OODM consisting of: 1. An object model 2. An object definition language (ODL) (like traditional DDL) 3. An object query language, with a SQL-like syntax ODMG object model is a superset of the Object Management Group (OMG) object model. 1990: OMG published its Object Management Architecture (OMA) Guide document. It specified a single terminology for oo languages, systems, databases and applications.

43. 43 Object RequestBroker WPSpreadsheetCADHelpemailbrowser Application objects Common facilities storage Transaction management queriesversioningsecurity Object services OMA

44. 44 1. The Object Model-- OM is a design-portable abstract model for communicating with OMG-compliant object-oriented systems a requester sends a request for object services to the ORB which keeps track of all the objects in the system and the types of services they can provide the ORB then forwards the message to a provider who acts on the message and passes a response back to the requester via the ORB requester ORB provider

45. 45 2. The Object Request Broker -- ORB handles distribution of messages between application objects is a distributed ‘software bus’ that enables objects (requesters) to make and receive requests and responses from a provider on receipt of a response from the provider, the ORB translates the response into a form the original requester can understand --> provides a mechanism by which objects make and receive requests and responses transparently --> interoperability between applications in a heterogeneous distributed environment

46. 46 3. The Object Services --OS provide the main functions for realizing basic object functionality collection: a uniform way to create and manipulate most common collections generically: sets, queues, stacks, lists, binary trees concurrency control: a lock manager that enables multiple clients to coordinate their access to shared rresources event management: allows components to dynamically register or unregister their interest in specific events exeternalization: provides protocols and conventions for externalizing and internalizing objects.

47. 47 externalization: records the state of an object as a stream of data (in memory, on disk, across network) internalization: creates a new object from it in a different process licensing: operations for metering the use of components to ensure fair compensation for their use, and protect intellectual property lifecycle: operations for creating, copying, moving, and deleting groups of related objects naming:facilities to bind a name to an object relative to a naming context persistence:interfaces to mechanisms for storing and managing objects persistently property:operations to associate named values (properties) with any (external) component

48. 48 query:declarative query statements with predicates, the ability to invoke operations and other object services relationship: a way to create dynamic associations between components that know nothing of each other security: services such as identification and authentification, authorization and access control, auditing, security of communication, non-repudiation, administration time:maintains a single notion of time across different machines trader:a matchmaking service for objects. It allows objects to dynamicaly advertise their services, and other objects to register for a service. transactions: a two-phase commit coordination among recoverable components using flat or nested transactions

49. 49 4. The Common Facilities --CF comprise a set of tasks that many applications must perform but are traditionally duplicated within each one. they are made available through OMA-compliant class interfaces in the latest version: CF are split in horizontal common facilities (printing, electronic mail, aso) and vertical domain facilities (finance, helthcare, manufacturing, e-commerce, transportation, telecommunications)

50. 50 The Common Request Broker Architecture -- CORBA defines the architecture of ORB-based environments is the basis of any OMG component, defing the parts that form the ORB and its associated structure 1991: CORBA 1.1 defined: Interface Definiton Language (IDL) Application Programming Interfaces (API) - enable client- server interaction with a specific implementation of an ORB 1994dec: CORBA 2.0 improved interoperability specified how ORBs from different vendors can interoperate 1997: CORBA 2.1

51. 51 Main elements: IDL: permits the description of class interfaces independent of any particualr DBMS or programming language a type model that defines the values that can be passed over the network. an Interface Repository, which provides information on interfaces and types, and is used to constructdynamic runtime requests, by the Dynamic Invocation Interface Methods for getting the interfaces and specifications of objects Methods for transforming OIDs to and from strings From the IDL definitions, CORBA objects can be mapped into particular programming languages, as C, C++, Smalltalk and Java. This produces interface stubs within the application programming language (client) that are used to invoke the requests. The same stubs are used on the object implementation side (server) to create skeletons, which are completed to provide the requested behavior.

52. 52 The ODMG Object Model Vendors: GemStone Systems, Object Design, O 2 Technology, Versant Object Technology, UniSQL, POET Software, Objectivity, IBEX Computing SA, Lockheed Martin formed Object Database Management Group (ODMG) It produced an object model that specifies a standard model for the semantics of database objects. The model is important because it determines the built-in semantics that the OODBMS undestands and can enforce The design of class libraries and applications that use these semantics should be portable across the various OODBMSs that support the object model.

53. 53 The major components of the ODMG for an OODBMS are: 1. Object model--OM 2. Object definition language --ODL 3. Object query language -- OQL 4. C++ language bindings 5. Smalltalk language bindings 6. Java language bindings Initial ODMG standard: 1993 Major version: ODMG 2.0 september 1997

54. 54 1. The Object Model --OM ODMG object model is a superset of th OMG object model enables both designs and implementations to be ported between complian systems Basic modeling primitives: the object and the literal. Objects and literals can be categorized in types: all objects of a given type exihibit common behavior and state. A type is an object. Behavior is defined by a set of operations that can be performed on or by object. State is defined by the values an object carries for a set of properties A property may be either an attribute or a relationship between the object and one or more other objects.

55. 55 Atomic_type long short unsigned long unsigned short float double boolean octet char string enum Collection_literal set bag list array dictionary Structured_literal date time timestamp interval structure Literal_type

56. 56 Structured _object Date Time Timestamp Interval Object_type Atomic_object Collection_object Set Bag List Array Dictionary

57. 57 A database stores objects, enabling them to be shared by multiple users and applications. A database is based on a schema that is defined in ODL. The database contains instances of the types defined by its schema. Objects types are: atomic, collections or structured types. Types shown in italics are abstract types. Types shown in normal are directly instantiable. They are the only base types. Types with indicate type generators. Objects are created using the new() method of the corresponding factory interface provided by the language binding interface. All objects have an ODL interface which is implicitly inherited by the definition of all user-defined objects:

58. 58 Interface Object { enumLock_Type {read, write, upgrade}; exceptionLockNot Granted {}; voidlock(in Lock_Type mode) raises (LockNotGranted); booleantry_lock(in Lock_Type mode); booleansame_as(in Object anObject); Objectcopy(); voiddelete(); } Each object has an unique identity, OID, which does not change and is not reused when the object is deleted. In addition, each object has one or more meaningful user names Objects can be transient or persistent.

59. 59 Literals : atomic, collections, structured, null The values of a literal’s properties may not change. Literals do not have their own OID and cannot stand alone as objects: they are embedded in objects Structured literals contain a fixed number of named heterogenous elements of the form:, where value may be any literal type. Struct Address { string street; string area; string city; string post_code; }; attribute Address branch_address;

60. 60 Collections: contain an arbitrary number of unnammed homogeneous elements, each of which can be an instance of an atomic type, a collection or literal type There are ordered and unordered collections. Ordered collections must be traversed first to last or vice versa; unordered collections have no fixed order of iteration. Set:unordered collections that do not allow duplicates Bag:unordered collections that do allow duplicates List:ordered collections that allow duplicates Array:one-dimensional array of dynamically varying length Dictionary:unordered sequence of key-value pairs with no duplicate ekeys Each subtype has operations to create an instance of the type and insrt an element into the collection. Sets and Bags have usual set operations: , , 

61. 61 Interface Collection: Object { exception InvalidCollection{}; exceptionElementNotFound{any element}; unsigned longcardinality(); booleanis_empty(); booleanis_ordered(); booleanallows_duplicates(); booleancontains_element(in any_element); voidinsert _element(in any_element); voidremove _element(in any_element); raises (ElementNotFound); Iteratorcreate_iterator(in boolean stable); `Bidirectionaliterator create_bidirectional_iterator(in boolean stable); Raises(InvalidCollectionType); }; ODL interface for collections

62. 62 A type has a specification and one or more implementations. The (external)specification defines the properties and operations that can be invoked on instances of the type. An implementation defines data structures, exceptions and methods that operates on the data structures to support the required state and behavior. Class: The combiantion of a type specification and an implementation. An interface definition is a specification that defines only the abstract behavior of an object type: supertypes, extend and keys. A literal definition defines only the abstract state of a literal type.

63. 63 Properties: in ODMG object model: attributes and relationships Attributes: is defined on a single object type is not a “first class” object (is not an object)--> no OID its value is a literal or an OID Relationships: only binary and are defined between types cardinality: 1:1, 1:M, M:N is not a “first class” object, does not have a name traversal paths are defined in the interface for each direction of traversal on the many side: objects can be unordered (set, bag) or ordered (list). OODBMS maintains referential integrity.

64. 64 Example: a Branch Has a set of Staff and a member of Staff WorksAt a Branch: interface Branch { relationship set Has inverse Staff:: WorksAt } interface Staff { relationship Branch WorksAt inverse Branch:: Has} The model has built-in operations to form and to drop members from relationships and to manage the required referential integrity constraints attribute BranchWorksAt; voidform_WorksAt(in Branch aBranch); voiddrop_WorkAt(in Branch aBranch);

65. 65 2. The Object Definition Language --ODL is a specification language for defining the specifications of object types for OMG-complian systems. facilitates portability of schemes between compliant systems defines the attributes and relationships of types specifies (but not addresses the implementation of) the signature of the operations the syntax of ODL extends the IDL (Interface Definition Language) of the CORBA will be the basis for integrating schemas from multiple sources and applications

66. 66 3. The Object Query Language --OQL provides declarative access to the object database using an SQL-like syntax. does not provide explicit update operators, but leaves this to the operations defined on object types. can be used as a standalone or as an embedded language in another language (now: C++, Smalltalk, Java). can invoke operations programmed in these languages An OQL query is a function that delivers an object whose type may be infered from the operator contributing to the query expression.

67. 67 Query definition expression: DEFINE Q AS e /* defines a query with name Q given a query /* expression e 1. Elementary expressions: an atomic literal: 10, 17.5, ‘c’, “qwerty”, false, nill a named object: an iterator variable from the FROM clause of the SELECT-FROM-WHERE: e as x ore x orx in e where e is of type collection(T), then x is of type T a query definition expression (Q above)

68. 68 2. Construction expression: If T is a type name with properties p 1, p 2, …,p n and e 1, e 2, …, e n are expressions then T(p 1 : e 1, p 2 : e 2, …,p n : e n ) is an expression of type T. Example: Branch(bno : ”B22”, manager : ”Susan Brand”) Similarly, we can construct expressions using struct, set, list, bag and array: struct (bno : “B22”, street : “166 Main ST”) is an expression which dynamically creates an instance of this type

69. 69 3. Atomic Type Expressions Expressions can be formed using the standard unary and binary operations on expressions. If S is a string, expressions can be formed using: the string concatenation operation ( || or + ) a string offset S i, meaning the i + l th character of the string S[low : up], meaning the substring of S from low + l th to up+l th character c in S (where c is a char) returning a bolean expression S like pattern. Pattern contains the characters ? or _, meaning any char, or the wildcard characters * or %, mening any substring. Returns a boolean expression

70. 70 4. Object Expressions Expressions can be formed using the equlity and inequality operations ( = and != ) returning a boolean. If e is an expression of a type having an attribute or a relationship P of the type T, then e.P and e -->P are expressions of type T. In a same way, methods can be invoked to return an expression If a method has no parameteers, the brackets in the method call can be omitted

71. 71 5. Collections expressions Expressions can be formed using universal quantification for all existential quantification exists membership testingin select clause select from where sort-by operator sort unary set operators min, max, count, sum, avg group-by operator group The format of the SELECT clause is similar to the standdard SQL SELECT clause:

72. 72 SELECT [DISTINCT] FROM [WHERE ] [GROUP BY [HAVING ] [ORDER BY ] Where: ::= IN | IN, | AS | AS, | The result of a SELECT DISTINCT query is a set The result of a SELECT query is a bag

73. 73 6. Indexed Collections Expressions If e 1 and e 2 are lists or arrays and e 3 and e 4 are integers, then e 1 [e 3 ], e 1 [e 3 :e 4 ], first(e 1 ), last(e 1 ) and (e 1 + e 2 ) are expressions 7. Binary Set Expressions If e 1 and e 2 are sets or bags, then the set operators union, except and intersect of e 1 and e 2 are expressions. 8. Structure Expression If e is a expression and p is a property name, then e.p and e-->p are expressions, which extract the property p of an object e.

74. 74 9. Conversion Expressions If e is an expression, then element(e) is an expression that checks e is a singleton, raising an exception if it is not. If e is a list expression, then listtoset(e) is an expression that converts the list into a set. If e is a collection-valued expression, then flatten(e) is an expression that converts a collection of collections into a collection, that is, it flattens the structure. If e is an expression and c is a type name, then c(e) is an expression that asserts e is an object of type c, raising an exception if it is not. 10. Object Expressions If e is an expression and f is an operation, then e.f and e-->f are expressions that apply an operation to an object. The operation can optionally take a number of expressions as parameters.

75. 75 A query consists of a (possibly empty) set of query definition expressions followed by an expression. The result of a query is an object with or without identity. Examples: A. get the set of all staff (with identity) staff B. get the set of all branch managers (with identity): branch_offices.ManagedBy

76. 76 C. get the set of all staf who live in London (without identity): define Londoners as select x from x in staff where x.address.city = “London” select x.name.lname from x in Londoners returns a literal of type set D. get the structured set (without identity) containing name, sex, and age for all staf who live in London: select struct (lname:x.name.lname, sex:x.sex, age:x.age) from x in staff where x.address.city = “London” returns a literal of type set

77. 77 E. get the structured set (with identity) containing name, sex, and age for all deputy managers over 60: type deputies {attribute lname : string; sex: string; age : integer;} deputies (select struct ( lname:x.name.lname, sex:x.sex, age:x.age) from x in (select y from staff where position = “Deputy”) where x.age > 60)

78. 78 F. get a structured set (without identity) containing branch number and the set of all Assistants at the branches in London: select struct (bno:x.bno, assistants: (select y from y in x.WorksAt where y.position=“Assistant”)) from x in (select z from branch_offices where z.address.city= “London”) Object without identity are created using struct, (see D, F).