2.1. Concepts for Object Databases

Transcription

1 UNIT -- 2 UNIT II -- OBJECT AND OBJECT RELATIONAL DATABASES Concepts for Object Databases: Object Identity Object structure Type Constructors Encapsulation of Operations Methods Persistence Type and Class Hierarchies Inheritance Complex Objects Object Database Standards, Languages and Design: ODMG Model ODL OQL Object Relational and Extended Relational Systems: Object Relational features in SQL/Oracle Case Studies. Introduction 2.1. Concepts for Object Databases An object database management system (ODBMS, also referred to as object-oriented database management system or OODBMS), is a database management system (DBMS) that supports the modeling and creation of data as objects. This includes some kind of support for classes of objects and the inheritance of class properties and methods by subclasses and their objects. Several major software companies including IBM, Informix, Microsoft, Oracle, and Sybase have all released object-relational versions of their products. These companies are promoting a new, extended version of relational database technology called objectrelational database management systems also known as ORDBMSs. Object Databases Became commercially popular in mid-1990 s We can store the data in the same format as we use it. No paradigm shift. Did not reach full potential till the classes they store were decoupled from the database schema. Open source implementation available low cost solution now exists. What is Object Oriented Database? (OODB) A database system that incorporates all the important object-oriented concepts 1 PREPARED BY S.PON SANGEETHA

2 Some additional features Unique Object identifiers Persistent object handling Is the coupling of Object Oriented (OOP) Programming principles with Database Management System (DBMS) principles Provides access to persisted objects using the same OO-programming language Advantages of OODBS Designer can specify the structure of objects and their behavior (methods) Better interaction with object-oriented languages such as Java and C++ Definition of complex and user-defined types Encapsulation of operations and user-defined methods Object Database Vendors Matisse Software Inc., Objectivity Inc., Poet's Fast Objects, Computer Associates, excelon Corporation, Db4o. Difference between OODB and Relational DB OODB RDB Uses an OO data Model Uses record-oriented Model - Data is a collection of objects whose - Data is a collection of record types behavior, state and relationships are stored (relations), each having collection of records as a physical entity. or tuples stored in a file Language dependence (OO Language Language independence (via SQL) Specific) No impedance mismatch in application using OODB Impedance mismatch in an OO application. Mapping must be performed. The main differences between relational database design and object oriented database design include: Many-to-many relationships must be removed before entities can be translated into relations. Many-to-many relationships can be implemented directly in an object-oriented database. 2 PREPARED BY S.PON SANGEETHA

3 Operations are not represented in the relational data model. Operations are one of the main components in an object-oriented database. In the relational data model relationships are implemented by primary and foreign keys. In the object model objects communicate through their interfaces. The interface describes the data (attributes) and operations (methods) that are visible to other objects. Object An object is an abstract representation of a real-world entity that has a unique identity, embedded properties, and the ability to interact with itself and other objects. It can also be defined as an entity that has a well-defined role in the application domain, as well as state, behavior, and identity. Objects exhibit behavior. Behavior represents how an object acts and reacts. Behavior is expressed through operations that can be performed on it. Object Identity An OO database system provides a unique identity to each independent object stored in the database. This unique identity is typically implemented via a unique, system-generated object identifier, or OID. The main property required of an OID is that it should be immutable. Specifically, the OID value of a particular object should not change. This preserves the identity of the real-world object being represented. Objects have unique identities that are independent of their attribute values. Attributes Objects are described by their attributes, known as instance variables. Attributes have a domain. The domain logically groups and describes the set of all possible values that an attribute can have. An attribute can be single valued or multivalued. Attributes may reference one or more other objects. 3 PREPARED BY S.PON SANGEETHA

4 Object State The object state is the set of values that the object s attributes have at a given time. If we change the object s state, we must change the values of the object attributes. To change the object s attribute values, we must send a message to the object. This message invokes a method. Messages and Methods Message means by which objects communicate, and it is a request from one object to another to execute one of its methods. For example: Publisher_object.insert ( Rose, 123, ) i.e. request to execute the insert method on a Publisher object ) Method defines the behavior of an object. Methods can be used to change state by modifying its attribute values to query the value of selected attributes. The method that responds to the message example is the method insert defied in the Publisher class. Every operation performed on an object must be implemented by a method. Methods represent real-world actions and are equivalent to procedures in traditional programming languages. Every method is identified by a name and has a body. The body is composed of computer instructions written in some programming language to represent a real-world action. To invoke a method you send a message to the object. A message is sent by specifying a receiver object, the name of the method, and any required parameters. The internal structure of the object cannot be accessed directly by the message sender. The ability to hide the object s internal details (attributes and methods) is known as encapsulation. An object may send messages to change or interrogate another object s state. Classes Objects that share common characteristics are grouped into classes. A class is a collection of similar objects with shared structure (attributes) and behavior (methods). Each object in a class is known as a class instance or object instance Type Constructors In OO databases, the state (current value) of a complex object may be constructed from other objects (or other values) by using certain type constructors. The three most basic constructors are atom, tuple, and set. Other commonly used constructors include list, bag, and array. 4 PREPARED BY S.PON SANGEETHA

5 The atom constructor is used to represent all basic atomic values, such as integers, real numbers, character strings, Booleans, and any other basic data types that the system supports directly. 1) o1 = (i1, atom, Houston ) 2) o2 = (i2, atom, Bellaire ) 3) o3 = (i3, atom, Sugarland ) 4) o4 = (i4, atom, 5) 5) o5 = (i5, atom, Research ) 6) o6 = (i6, atom, ) The first six objects listed in this example represent atomic values. 7) o7 = (i7, set, {i1, i2, i3}) Object seven is a set-valued object that represents the set of locations for department 5; the set refers to the atomic objects with values { Houston, Bellaire, Sugarland }. 8) o8 = (i8, tuple, <dname:i5, dnumber:i4, mgr:i9, locations:i7, employees:i10, projects:i11>) Object 8 is a tuple-valued object that represents department 5 itself, and has the attributes DNAME, DNUMBER, MGR, LOCATIONS, and so on. 5 PREPARED BY S.PON SANGEETHA

6 Complex object structures can be constructed by recursively applying a set of basic constructors, such as tuple, set, list, and bag Encapsulation of Operations Encapsulation is one of the main characteristics of OO languages and systems. It is related to the concepts of abstract data types and information hiding in programming languages. a) Specifying Object Behavior via Class Operations The main idea is to define the behavior of a type of object based on the operations that can be externally applied to objects of that type. In general, the implementation of an operation can be specified in a generalpurpose programming language that provides flexibility and power in defining the operations. For database applications, the requirement that all objects be completely encapsulated is too stringent. One way of relaxing this requirement is to divide the structure of an object into visible and hidden attributes (instance variables). 6 PREPARED BY S.PON SANGEETHA

7 b) Specifying Object Persistence via Naming and Reachability Naming Mechanism Assign an object a unique persistent name through which it can be retrieved by this and other programs. Reachability Mechanism Make the object reachable from some persistent object. An object B is said to be reachable from an object A if a sequence of references in the object graph lead from object A to object B. In traditional database models such as relational model or EER model, all objects are assumed to be persistent. In OO approach, a class declaration specifies only the type and operations for a class of objects. The user must separately define a persistent object of type set (DepartmentSet) or list (DepartmentList) whose value is the collection of references to all persistent DEPARTMENT objects 7 PREPARED BY S.PON SANGEETHA

8 Persistence Drawbacks of persistent programming languages o Due to power of most programming languages, it is easy to make programming errors that damage the database. o Complexity of languages makes automatic high-level optimization more difficult. Do not support declarative querying as well as relational 8 PREPARED BY S.PON SANGEETHA

9 2.4. Type & Class Hierarchy A type in its simplest form can be defined by giving it a type name and then listing the names of its visible (public) functions. When specifying a type in this section, we use the following format, which does not specify arguments of functions TYPE_NAME: function, function... function Example: PERSON: Name, Address, Birthdate, Age, SSN 9 PREPARED BY S.PON SANGEETHA

10 Subtype: When the designer or user must create a new type that is similar but not identical to an already defined type Super type: It inherits all the functions of the subtype Example : PERSON: Name, Address, Birthdate, Age, SSN EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary, Hire Date, Seniority STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA EMPLOYEE subtype-of PERSON: Salary, Hire Date, Seniority STUDENT subtype-of PERSON: Major, GPA. Extents: In most OO databases, the collection of objects in an extent has the same type or class. However, since the majority of OO databases support types, we assume that extents are collections of objects of the same type for the remainder of this section. All persistent objects of a particular type can be stored in an extent. Extents corresponding to a type hierarchy have set/subset constraints enforced on them. Persistent Collection: This holds a collection of objects that is stored permanently in the database and hence can be accessed and shared by multiple programs. Transient Collection: This exists temporarily during the execution of a program but is not kept when the program terminates. Note: Object types can be specified by using a type hierarchy, which allows the inheritance of both attributes and methods of previously defined types Complex object a) Structured complex object This differs from an unstructured complex object in that the object s structure is defined by repeated application of the type constructors provided by the OODBMS. Hence, the object structure is defined and known to the OODBMS. The OODBMS also defines methods or operations on it. b) Unstructured complex object This is provided by a DBMS and permits the storage and retrieval of large objects that are needed by the database application. Typical examples of such objects are bitmap images and long text strings (such as documents); they are also known as binary large objects, or BLOBs for short. This has been the standard way by which Relational DBMSs have dealt with supporting complex objects, leaving the operations on those objects outside the RDBMS. 10 PREPARED BY S.PON SANGEETHA

11 2.6. Object Database standards, Languages & Design Object Database Standards ODMG (Object Data Management Group) proposed a standard for Object databases which is known as ODMG-93 or ODMG 1.0 standard. This was revised into ODMG 2.0 and later to ODMG 3.0. The standard is made up of several parts, including the object model, the object definition language (ODL), the object query language (OQL) and the bindings to object-oriented programming languages Overview of the Object Model of ODMG The ODMG object model is the data model upon which the object definition language (ODL) and object query language (OQL) are based. It is meant to provide a standard data model for databases, just as SQL describes a standard data model for relational database. Object model must include: - Data type, type constructor - Concepts for specifying object database schemas - Statements for manipulating objects and retrieval Objects and Literals: Objects and literals are the basic building blocks of the object model. The main difference between the two is that an object has both an object identifier and a state (or current value). Whereas a literal has a value (state) but no object identifier. The object state can change over time by modifying the object value. A literal is basically a constant value; possible having a complex structure, but it does not change. 1) Objects: An object is described by five characteristics. Those are a) object identifier or Object_Id is a unique system-wide identifier. Every object must have an object_id. b) Name: Some objects may optionally be given a unique name within a particular ODMS. This name can be used to locate the object, and the system should return the object given that name. Name is often used as the entry point. 11 PREPARED BY S.PON SANGEETHA

12 c) Lifetime: The lifetime of an object specifies whether it is a persistent object (a database object) or transient object (an object in an executing program that disappears after the program terminates). d) Structure: The structure of an object specifies how the object is constructed by using the type constructors. The structure specifies whether an object is atomic or collection object. An atomic object refers to a single object that follows a user defined type. Collection object represents a set of objects of other type. e) Creation: Object creation refers to the manner in which an object can be created. This is accomplished via an operation new. 2) Literals: A literal is a value that does not have an object identifier. However, the value may have a simplex or complex structure. There are three types of literals: atomic, structured and collection. a) Atomic Literals: These are correspond to the values of basic data types and are predefined. The basic type of the object model include long, short and unsigned integer numbers, floating point numbers, Boolean values, single character, character strings and enumeration types. b) Structured literals: These are corresponds roughly to values that are constructed using the tuple constructor. The built-in structured literals include Date, Interval, Time, and Timestamp. User-defined type structures are created using the STRUCT keyword. Example: struct Dept_Mgr { Employee manager; Date startdate } c) Collection literal: It specifies a literal value that is a collection of objects or values but the collection itself does not have an Object_Id. The collection in the object model can be defined by the type generators set<t>, bag<t>, list<t> and array<t>, where T is the type of objects or values in the collection. Another collection type is dictionary<k, V>, where each K is a key (a unique search value) 12 PREPARED BY S.PON SANGEETHA

13 associated with a value V; this can be used to create an index on a collection of values V. 3) Inheritance in the Object Model of ODMG In ODMG data model, two types of inheritance relationships exist: Behaviour only inheritance and State plus behaviour inheritance/ EXTENDS Inheritance. a) Behaviour Inheritance: It is also known as ISA or interface inheritance and is specified by the colon notation. Hence, in the ODMG data model, behaviour inheritance requires the super type to be an interface, whereas the subtype could be either a class or another interface. A class inherit behaviour from several interfaces via colon notation. b) EXTENDS Inheritance: It is specified by the keyword extends. It is used to inherit both state and behaviour strictly among classes, so both the super type and subtype must be classes. Multiple inheritance via extends is not permitted. 4). Interface It something likes a type, or class. It contains visible attributes, relationships, operations; noninstantiable; Operations can be inherited by the user-defined objects. Example: interface Object {. Boolean same_as(in Object other_object); Object copy(); Void delete(); }; 5). Difference between Interfaces and classes Interface It specifies the abstract behaviour of an object type. It may have state properties and behaviours. Behaviours can be inherited. State properties cannot be inherited It is noninstantiable. 13 PREPARED BY S.PON SANGEETHA

14 Classes It specifies of the abstract behaviour and abstract state of an object type. Both the behaviours and states can be inherited. It is instantiable. 6). Extents In the ODMG model, the database designer can declare an extent for any object type that is defined via a class declaration. The extent is given a name, and it will contain all persistent objects of that class. Hence, the extent behaves as a set object that holds all persistent object of the class class Department (extent all_departments Key dname, dnumber) { } If B is a subclass of A, then the extent of B (i.e., named all_b) must be the extent of A (named all_a): all_b all_a. the subset of 7). Keys A class with an extent can have one or more keys. A key consists of one or more properties whose values are constrained to be unique for each object in the extent. 14 PREPARED BY S.PON SANGEETHA

15 8). Factory Object An interface that can be used to generate or create individual objects via its operations. 9) Built-in Interfaces for Collection Objects Any collection object inherits the basic Collection Interface. interface Collection : Object { exeption ElementNotFound(in any element); unsigned long cardinality(); Boolean is_empty(); Boolean contains_element(in any element); Void insert_element(in any element); Void remove_element(in any element) raises(elementnotfound); Iterator create_iterator();. } interface Iterator { 15 PREPARED BY S.PON SANGEETHA

16 Exeption NoMoreElement();... Boolean at_end(); Void reset(); Any get_element() raises(nomoreelement); Void next_position() raises(nomoreelement); } Given a collection object o, o.cardinality() - number of elements in the collection o.is_empty() - true or false o.insert_element(e) - insert e into o o.remove_element(e) - remove e from o. o.contains(e) - true or false. The operation i = o.create_iterator() creates an iterator object i. i.reset() - sets the iterator at the first element in a collection i.next_position() - sets the iterator to the next element i.get_element() - retrieve the current element. Set Set is a subclass of Collection Interface, interface Set : Collection { Set create_union(in Set other_set); Boolean is_subset_of(in Set other_set); } Set<t> is a subclass of Set interface (e.g., Set<Student>). Given a Set<t> object o (t is a data type), p = o.create_union(s) o.is_subset_of(s) p = o.create_intersection(s) o.is_proper_subset(s) p = o.create_difference(s) o.is_superset(s) BAG: Bag is a subclass of Collection interface. interface Bag : Collection 16 PREPARED BY S.PON SANGEETHA

17 { } unsigned long occurrence_of(in any element); Bag create_union(in Bag other_bag); Bag<t> is a subclass of Bag interface. Given a Bag<t> object o, p = o.create_union(s) p = o.create_intersection(s) p = o.create_difference(s) List List is a subclass of Collection interface. interface List : Collection { exception Invalid_Index(unsigned_long index); void remove_element_at(in unsigned_long position) raised(invalidindex); any retrieve_element_at(in unsigned_long position) raised(invalidindex); void replace_element_at(in any element, in unsigned_long position) raised(invalidindex); void insert_element_at(in any element, in unsigned_long position) raised(invalidindex); void insert_element_first(in any element); } Given a List<t> object o, o.insert_element_first(e) o.insert_element_last(e) o.insert_element_after(e, i) o.insert_element_before(e, i) o.remove_first_element(e) o.remove_last_element(e) o.remove_element_at(i) e = o.retrieve_first_element() e = o.retrieve_last_element() e = o.retrieve_element_at(i) p = o.concat(l) o.append(l) 17 PREPARED BY S.PON SANGEETHA

18 Array Array is a subclass of Collection interface. interface Array : Collection { exception Invalid_Index(unsigned_long index); void remove_element_at(in unsigned_long position) raised(invalidindex); any retrieve_element_at(in any element, in unsigned_long position) raised(invalidindex); void replace_element_at(in any element, in unsigned_long position) raised(invalidindex); void resize(in unsigned long new_size); } Array<t> is a subclass of Array interface. Given an Array<t> object o, o.replace_element_at(i, e) e = o. remove_element_at(i) e = o. retrieve_element_at(i) o.resize(n) Dictionary Dictionary is a subclass of Collection interface. interface Dictionay : Collection { Exception KeyNotFound(any key); Void bind(in any key, in any value) Void unbind(in any key) raised(keynotfound); Any lookup(in any key) raised(keynotfound); Boolean contains_key(in any key); } This allows the creation of a collection of association pairs <k, v>, where all k (key) values are unique. This allows for associative retrieval of a particular pair given its key value (similar to an index). Dictionary<k, v> is a subclass of Dictionary interface. Given a Dictionary<k, v> object o, o.bind(k, v) - binds value v to the key k as an association <k, v> in the collection.o.unbind(k) - removes the association with key k from o v = o.lookup(k) - returns the value v associated with key k in o. 18 PREPARED BY S.PON SANGEETHA

19 o.contains_key(k) - return true if k exists in o; otherwise, return false. Atomic (User-defined) Objects class - a specification of a data unit. An atomic object is an instance of some class. Example: class Employee ( extent all_employees key ssn) { Attribute string name; Attribute string ssn; Attribute date birthdate; Attribute enum Gender{M, F} sex; Attribute short age; Relationship Department works_for inverse Department::has_emps; Void reassign_emp(in string new_dname) raises(dname_not_valid); } 2.7. ODL (Object definition Language) The ODL is designed to support the semantic constructs of the ODMG object model and is independent of any particular programming languages. Its main usage is to create object specifications that is, classes and interfaces. ODL is not full programming language. A user can specify a database schema in ODL independently of any programming language and use the specific language bindings to specify how ODL constructs can be mapped to constructs in specific programming languages, such as C++, Smalltalk and Java. 19 PREPARED BY S.PON SANGEETHA

20 Class Declarations interface < name > {elements = attributes, relationships, methods } Element Declarations attribute < type > < name > ; relationship < rangetype > < name > ; Method Example float gpa(in: Student) raises(nogrades) float = return type. in: indicates Student argument is read-only. Other options: out, inout. nogrades is an exception that can be raised by method gpa. Banking Example 1 20 PREPARED BY S.PON SANGEETHA

21 Banking Example (II) interface Customer { attribute string name; attribute integer ss#; attribute Struct Addr {string street, string city, int zip} address; relationship Set<Loans> borrowed inverse Loans::borrower; relationship Set<Branch> has-account-at inverse Branch:patrons; key(ss#) } Structured types have names and bracketed lists of field-type pairs. Relationships have inverses. An element from another class is indicated by < class > :: Form a set type with Set<type>. ODL Type System Basic types: int, real/ float, string, enumerated types, and classes. Type constructors: Struct for structures and four collection types: Set, Bag, List, and Array OQL (Object Query Language) OQL is declarative (as opposed to procedural) which allows ODBMS seamless operations. OQL can be used interactively. OQL embedded in C++ makes programs simpler. OQL can be seamlessly optimised. OQL guarantees logical/physical independence. OQL supports Complex Objects. OQL supports methods. 1) Example a) Stand alone: select struct(n: p.name, s: p.sex) from People as p where p.age < 18 b) Embedded in C++ d_oql_execute(teenagers, select p from People as p where p.age < 18 ) 21 PREPARED BY S.PON SANGEETHA

22 2) Operands Constants - 1.0; true; A String ; nil Named objects -People; president Variables: P or p.age or p->age (syntax for attributes and methods is identical) I[i] 3)Operators Numerical * / mod abs Comparison- =!= > < Boolean not and or Constructors Object: Employee(name: John, salary: 15000) Collection: Vector(1, 2, 3) Structure: struct(name: p.name, age: p.age) Litteral collection: set(1, 2, 3) 4) Operators on Collections Set ---intersect union except Selection --- select result (x, y, ) from col1 as x, col2 as y, where predicate(x, y, ) Quantificators for all x in collection: predicate(x) exists x in collection: predicate(x) Conversion element(singleton) flatten(collection_of_collections) 5)Aggregation Example select * from Employees as e group by e.department as departments order by avg(select e.salary from partition) The type of the result is: List<struct(department: integer, partition: Bag<struct(e:Employee)> > 6)OQL vs. SQL3 OQL is stable, implemented, and available while SQL3 is still in the design Process. OQL is a simple query language while SQL3 is a full DB PL OQL definition takes 20 pages while SQL3 is currently 1300 pages OQL can match different data models (C++, ODMG, SQL2, and SQL3) 22 PREPARED BY S.PON SANGEETHA

23 2.9. Object Relational and Extended Relational Systems Object-Relational Support in SQL-99 (Or) SQL3 Type constructors used to specify complex objects. There is a mechanism to specify object-identity. There is a mechanism for encapsulation of operations. And also mechanism to support inheritance I.e., specify specialization and generalization 1) Type Constructors Two types: row and array Known as user-defined types (UDTs) Syntax for a row type CREATE TYPE row_type_name AS [ROW] (<component decln>) An example: CREATE TYPE Addr_type AS (street VARCHAR (45), city VARCHAR (25), zip CHAR (5)); An array type is specified for an attribute whose value will be a collection Example: CREATE TYPE Comp_type AS (comp_name VARCHAR (2). location VARCHAR (20) ARRAY [10] ); Dot notation is used to refer to components E.g., comp1.comp_name is the comp_name part of comp1 (of type Comp_type) 2) Object-Identifiers Using References A user-defined type can also be used to specify the row types of a table: CREATE TABLE Company OF Comp_type(REF IS comp_id SYSTEM GENERATED, PRIMARY KEY (comp_name)); Syntax to specify object identifiers: REF IS <oid_attribute> <value_generation_method> Options: SYSTEM GENERATED or DERIVED 3) Attributes as References A component attribute of one tuple may be a reference: CREATE TYPE Employment_type AS (employee REF (Emp_type) SCOPE 23 PREPARED BY S.PON SANGEETHA

24 (Employee), company REF (Comp_type) SCOPE (Company)); Keyword SCOPE specifies the table whose tuples can be referenced by a reference attribute via the dereferencing notation -> E.g., e.company->comp_name 4) Encapsulation of Operations A construct similar to the class definition Users can create a named user-defined type with its own methods in addition to attributes: CREATE TYPE <type-name> (list of attributes declaration of EQUAL and LESS THAN methods declaration of other methods ); 5) Method Syntax Syntax: METHOD <name> (<arg-list>) RETURNS <type>; An example CREATE TYPE Addr_type AS ( street VARCHAR (45),city VARCHAR (25), zip CHAR (5)) METHOD apt_no ( ) RETURNS CHAR(8); 6) Inheritance in SQL Inheritance is specified via the UNDER keyword Example CREATE TYPE Manager_type UNDER Emp_type AS (dept_managed CHAR (20)); Manager_type inherits all features of Emp_type and it has an additional attribute called dept_managed. 7) Other Operations and New Features WITH RECURSIVE is used to specify recursive queries User accounts may have a role that specifies the level of authorization and privileges; Roles can change Trigger granularity allows row-level and statement-level triggers SQL3 also supports programming languages facilities Current Trends Main force behind development of ORDBMSs: meet the challenges of new applications: 24 PREPARED BY S.PON SANGEETHA

25 Text Images Audio Streamed data BLOBs (binary large objects) The Informix Universal Server It combines relational and object database technologies It consider two dimensions of DBMS applications: Complexity of data (x) Complexity of queries (y) Observe the possible quadrants 1) How Informix Universal Server Extends the Relational Data Model Support for extensible data types Support for user-defined routines Implicit notion of inheritance Support for indexing extensions Database Blade API 2) Informix Universal Server s Extensible Data Types DBMS is treated as razor into which data blade modules can be inserted A number of new data types are provided Two-dimensional geometric objects Images Time series Text Web pages 3) Informix Universal Server s Constructs to Declare Additional Types Opaque type: Encapsulates a type (hidden representation) Distinct type: Extends an existing type thru inheritance Row type: Represents a composite type (like C s struct) Collection type: 25 PREPARED BY S.PON SANGEETHA

26 Lists, sets, multi-sets (bags) 4) Informix Universal Server s Support for User-Defined Routines Informix supports user-defined functions and routines to manipulate userdefined types Functions are implemented Either in Stored Procedure (SPL) Or in a high-level programming language (such as C or Java) Functions can define operations like plus, times, divide, sum, avg, negate 5) Implementation and Related Issues The ORDBMS must dynamically link a user-defined function in its address space Client-server issues: if a server needs to perform a function, it is best to do so in the DBMS (server) address space Queries should be possible to run inside functions Efficient storage and access of data Especially given new types, is very important 6) Other Issues Object-relational design is more complicated Query processing and optimization Interaction of rules with transactions Nested Relational Model It removes the restriction of the first normal form (1NF) No commercial database supports a nested relational model Visual representation: 26 PREPARED BY S.PON SANGEETHA

27 1) Attributes of Nested Relations Simple value attributes Multi-valued simple attributes Multi-valued composite attributes Single-valued composite attributes 2) Manipulating Nested Relations Extension made to Relational algebra Relational calculus SQL Two operations for converting between nested and flat relations: NEST UNNEST 27 PREPARED BY S.PON SANGEETHA