Chapter Outline  1 Overview of O-O Concepts  2 O-O Identity, Object Structure and Type Constructors  3 Encapsulation of Operations, Methods and Persistence  4 Type and Class Hierarchies and Inheritance  5 Complex Objects  6 Other O-O Concepts  7 Summary & Current Status
Background  A database is a an organized collection of related data held in a computer or a data bank, which is designed to be accessible in various ways  The data within a database is structured so as to model a real world structures and hierarchies so as to enable conceptually convenient data storage, processing and retrieval mechanisms  Clients (Services or applications) interact with databases through queries (remote or otherwise) to Create, Retrieve, Update and Delete data within a database. This  process is facilitated through a Database Management System (DBMS)
… Cont’d  Relational models were limiting in the kind of data that could be held, the rigidity of the structure, and the lack of support for new data types such as graphics, xml, 2D and 3D data.  In the 1990s With the advent of Object Oriented methodologies and languages, integration of database capabilities with object oriented programming language provided a unified programming environment.  This led to the development of OODB and OODBMS where objects are stored in databases rather than data such as integers, strings or real numbers.
Introduction  Traditional Data Models:  Hierarchical  Network (since mid-60’s)  Relational (since 1970 and commercially since 1982)  Object Oriented (OO) Data Models since mid-90’s Object Model aims to reduce the overhead of converting information representation in the database to an application specific representation. Unlike a traditional database, an object model allows for data persistence and storage by storing objects in the databases. The relationships between various objects are inherent in the structure of the objects. This is mainly used for complex data structures such as 2D and 3D graphics which must otherwise be flattened before storage in a relational database.  Reasons for creation of Object Oriented Databases  Need for more complex applications  Need for additional data modeling features  Increased use of object-oriented programming languages  Commercial OO Database products –  Several in the 1990’s, but did not make much impact on mainstream data management
OO Database  Object oriented databases or object databases incorporate the object data model to define data structures on which database operations such as creation, retrieve, update and deletion can be performed.  They store objects rather than data such as integers and strings.  The relationship between various data is implicit to the object and manifests as object attributes and methods  Object database management systems extend the object programming language with transparently persistent data, concurrency control, data recovery, associative queries, and other database capabilities.
… Cont’d Object model
… Cont’d The Object-Oriented Database System Manifesto  by Malcolm Atkinson mandates that an object- oriented database system should satisfy two criteria: it should be a DBMS, and it should be an object-oriented system  Thus OODB implements OO concepts such as object identity ,polymorphism, encapsulation and inheritance to provide access to persistent objects using any OO-programming language.  The tight integration between object orientation and databases provides programmers a unified environment when dealing with complex data such as 2D and 3D graphics.  Object oriented databases are designed to work well with object oriented programming languages such as Python, Java, Objective-C.
Overview of Object-Oriented Concepts  Main Claim:  OO databases try to maintain a direct correspondence between real- world and database objects so that objects do not lose their integrity and identity and can easily be identified and operated upon  Object:  Two components:  state (value) and behavior (operations)  Similar to program variable in programming language, except that it will typically have a complex data structure as well as specific operations defined by the programmer  In OO databases, objects may have an object structure of arbitrary complexity in order to contain all of the necessary information that describes the object.  In contrast, in traditional database systems, information about a complex object is often scattered over many relations or records, leading to loss of direct correspondence between a real-world object and its database representation.
… Cont’d  The internal structure of an object in OOPLs includes the specification of instance variables, which hold the values that define the internal state of the object.  An instance variable is similar to the concept of an attribute, except that instance variables may be encapsulated within the object and thus are not necessarily visible to external users  Some OO models insist that all operations a user can apply to an object must be predefined. This forces a complete encapsulation of objects.  To encourage encapsulation, an operation is defined in two parts:  signature or interface of the operation, specifies the operation name and arguments (or parameters).  method or body, specifies the implementation of the operation.
… Cont’d  Operations can be invoked by passing a message to an object, which includes the operation name and the parameters.  The object then executes the method for that operation.  This encapsulation permits modification of the internal structure of an object, as well as the implementation of its operations, without the need to disturb the external programs that invoke these operations.  Some OO systems provide capabilities for dealing with multiple versions of the same object (a feature that is essential in design and engineering applications).  For example, an old version of an object that represents a tested and verified design should be retained until the new version is tested and verified:  very crucial for designs in manufacturing process control, architecture , software systems …..
… Cont’d  Operator polymorphism:  This refers to an operation’s ability to be applied to different types of objects; in such a situation, an operation name may refer to several distinct implementations, depending on the type of objects it is applied to.  This feature is also called operator overloading Object Identity, Object Structure, and Type Constructors  Unique 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 be immutable  Specifically, the OID value of a particular object should not change.  This preserves the identity of the real-world object being represented.
… cont’d  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.  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.
… Cont’d  Example 1  One possible relational database state corresponding to COMPANY schema
… cont’d  Example 1 (contd.):
… Cont’d  Example 1 (contd.)  We use i1, i2, i3, . . . to stand for unique system-generated object identifiers. Consider the following objects:  o1 = (i1, atom, ‘Houston’)  o2 = (i2, atom, ‘Bellaire’)  o3 = (i3, atom, ‘Sugarland’)  o4 = (i4, atom, 5)  o5 = (i5, atom, ‘Research’)  o6 = (i6, atom, ‘1988-05-22’)  o7 = (i7, set, {i1, i2, i3})  Example 1(contd.)  o8 = (i8, tuple, <dname:i5, dnumber:i4, mgr:i9, locations:i7, employees:i10, projects:i11>)  o9 = (i9, tuple, <manager:i12, manager_start_date:i6>)  o10 = (i10, set, {i12, i13, i14})  o11 = (i11, set {i15, i16, i17})  o12 = (i12, tuple, <fname:i18, minit:i19, lname:i20, ssn:i21, . . ., salary:i26, supervisor:i27, dept:i8>)  . . .
… Cont’d  Example 1 (contd.)  The first six objects listed in this example represent atomic values.  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’}.  Object 8 is a tuple-valued object that represents department 5 itself, and has the attributes DNAME, DNUMBER, MGR, LOCATIONS, and so on.  Example 2:  This example illustrates the difference between the two definitions for comparing object states for equality.  o1 = (i1, tuple, <a1:i4, a2:i6>)  o2 = (i2, tuple, <a1:i5, a2:i6>)  o3 = (i3, tuple, <a1:i4, a2:i6>)  o4 = (i4, atom, 10)  o5 = (i5, atom, 10)  o6 = (i6, atom, 20)
… cont’d  Example 2 (contd.):  In this example, The objects o1 and o2 have equal states, since their states at the atomic level are the same but the values are reached through distinct objects o4 and o5.  However, the states of objects o1 and o3 are identical, even though the objects themselves are not because they have distinct OIDs.  Similarly, although the states of o4 and o5 are identical, the actual objects o4 and o5 are equal but not identical, because they have distinct OIDs.
… Cont’d
… Cont’d
… Cont’d  Encapsulation  One of the main characteristics of OO languages and systems  Related to the concepts of abstract data types and information hiding in programming languages  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 general-purpose 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).
… Cont’d
… Cont’d  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
… Cont’d
… cont’d  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, to simplify the discussion:  TYPE_NAME: function, function, . . . , function  Example:  PERSON: Name, Address, Birthdate, Age, SSN  Subtype:  When the designer or user must create a new type that is similar but not identical to an already defined type  Supertype:  It inherits all the functions of the subtype
… cont’d  Example (1):  PERSON: Name, Address, Birthdate, Age, SSN  EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary, HireDate, Seniority  STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA  OR:  EMPLOYEE subtype-of PERSON: Salary, HireDate, Seniority  STUDENT subtype-of PERSON: Major, GPA  Example (2):  Consider a type that describes objects in plane geometry, which may be defined as follows:  GEOMETRY_OBJECT: Shape, Area, ReferencePoint  Now suppose that we want to define a number of subtypes for the GEOMETRY_OBJECT type, as follows:  RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height  TRIANGLE subtype-of GEOMETRY_OBJECT: Side1, Side2, Angle  CIRCLE subtype-of GEOMETRY_OBJECT: Radius
… Cont’d  Example (2) (contd.):  An alternative way of declaring these three subtypes is to specify the value of the Shape attribute as a condition that must be satisfied for objects of each subtype:  RECTANGLE subtype-of GEOMETRY_OBJECT (Shape=‘rectangle’): Width, Height  TRIANGLE subtype-of GEOMETRY_OBJECT (Shape=‘triangle’): Side1, Side2, Angle  CIRCLE subtype-of GEOMETRY_OBJECT (Shape=‘circle’): Radius
… cont’d  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.  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
Complex Objects (1)  Unstructured complex object:  These 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.
Complex Objects (2)  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.
Other Objected-Oriented Concepts (1)  Polymorphism (Operator Overloading):  This concept allows the same operator name or symbol to be bound to two or more different implementations of the operator, depending on the type of objects to which the operator is applied  For example + can be:  Addition in integers  Concatenation in strings (of characters)
Other Objected-Oriented Concepts (2)  Multiple Inheritance and Selective Inheritance  Multiple inheritance in a type hierarchy occurs when a certain subtype T is a subtype of two (or more) types and hence inherits the functions (attributes and methods) of both supertypes.  For example, we may create a subtype ENGINEERING_MANAGER that is a subtype of both MANAGER and ENGINEER.  This leads to the creation of a type lattice rather than a type hierarchy.
Object Query Language  Developed by ODMG, Object Query Language allows SQL-like queries to be performed on a OODB.  Like SQL, it is a declarative language. Based loosely on SQL, OQL includes additional language constructs which allow for object oriented design such as operation invocation and inheritance.  Query Structures look very similar in SQL and OQL but the results returned are different.
… Cont’d  Example: OQL query to obtain Voter names who are from the state of Colorado Select distinct v.name From voters v Where v.state = “Colorado”
Object-oriented vs relational Model  A method in an object model is defined in the class to which the object belongs.  A stored procedure is a sub-routine available to applications and this is external to the database , defined in the data dictionary.  Example: Stored procedures for data validation  OODB is OO language specific whereas Relational DB are language independent via SQL  No impedance mismatch in applications using OODB where as object relational mapping must be performed in relational database for use in OO applications.
Current Status  OODB market growing very slowly these days.  O-O ideas are being used in a large number of applications, without explicitly using the OODB platform to store data.  Growth:  O-O tools for modeling and analysis, O-O Programming Languages like Java and C++  Compromise Solution Proposed:  Object Relational DB Management (Informix Universal Server, Oracle 10i, IBM’s UDB, DB2/II …)

Chapter 1 - Concepts for Object Databases.ppt

  • 1.
    Chapter Outline  1Overview of O-O Concepts  2 O-O Identity, Object Structure and Type Constructors  3 Encapsulation of Operations, Methods and Persistence  4 Type and Class Hierarchies and Inheritance  5 Complex Objects  6 Other O-O Concepts  7 Summary & Current Status
  • 2.
    Background  A databaseis a an organized collection of related data held in a computer or a data bank, which is designed to be accessible in various ways  The data within a database is structured so as to model a real world structures and hierarchies so as to enable conceptually convenient data storage, processing and retrieval mechanisms  Clients (Services or applications) interact with databases through queries (remote or otherwise) to Create, Retrieve, Update and Delete data within a database. This  process is facilitated through a Database Management System (DBMS)
  • 3.
    … Cont’d  Relationalmodels were limiting in the kind of data that could be held, the rigidity of the structure, and the lack of support for new data types such as graphics, xml, 2D and 3D data.  In the 1990s With the advent of Object Oriented methodologies and languages, integration of database capabilities with object oriented programming language provided a unified programming environment.  This led to the development of OODB and OODBMS where objects are stored in databases rather than data such as integers, strings or real numbers.
  • 4.
    Introduction  Traditional DataModels:  Hierarchical  Network (since mid-60’s)  Relational (since 1970 and commercially since 1982)  Object Oriented (OO) Data Models since mid-90’s Object Model aims to reduce the overhead of converting information representation in the database to an application specific representation. Unlike a traditional database, an object model allows for data persistence and storage by storing objects in the databases. The relationships between various objects are inherent in the structure of the objects. This is mainly used for complex data structures such as 2D and 3D graphics which must otherwise be flattened before storage in a relational database.  Reasons for creation of Object Oriented Databases  Need for more complex applications  Need for additional data modeling features  Increased use of object-oriented programming languages  Commercial OO Database products –  Several in the 1990’s, but did not make much impact on mainstream data management
  • 5.
    OO Database  Objectoriented databases or object databases incorporate the object data model to define data structures on which database operations such as creation, retrieve, update and deletion can be performed.  They store objects rather than data such as integers and strings.  The relationship between various data is implicit to the object and manifests as object attributes and methods  Object database management systems extend the object programming language with transparently persistent data, concurrency control, data recovery, associative queries, and other database capabilities.
  • 6.
  • 7.
    … Cont’d The Object-OrientedDatabase System Manifesto  by Malcolm Atkinson mandates that an object- oriented database system should satisfy two criteria: it should be a DBMS, and it should be an object-oriented system  Thus OODB implements OO concepts such as object identity ,polymorphism, encapsulation and inheritance to provide access to persistent objects using any OO-programming language.  The tight integration between object orientation and databases provides programmers a unified environment when dealing with complex data such as 2D and 3D graphics.  Object oriented databases are designed to work well with object oriented programming languages such as Python, Java, Objective-C.
  • 8.
    Overview of Object-OrientedConcepts  Main Claim:  OO databases try to maintain a direct correspondence between real- world and database objects so that objects do not lose their integrity and identity and can easily be identified and operated upon  Object:  Two components:  state (value) and behavior (operations)  Similar to program variable in programming language, except that it will typically have a complex data structure as well as specific operations defined by the programmer  In OO databases, objects may have an object structure of arbitrary complexity in order to contain all of the necessary information that describes the object.  In contrast, in traditional database systems, information about a complex object is often scattered over many relations or records, leading to loss of direct correspondence between a real-world object and its database representation.
  • 9.
    … Cont’d  Theinternal structure of an object in OOPLs includes the specification of instance variables, which hold the values that define the internal state of the object.  An instance variable is similar to the concept of an attribute, except that instance variables may be encapsulated within the object and thus are not necessarily visible to external users  Some OO models insist that all operations a user can apply to an object must be predefined. This forces a complete encapsulation of objects.  To encourage encapsulation, an operation is defined in two parts:  signature or interface of the operation, specifies the operation name and arguments (or parameters).  method or body, specifies the implementation of the operation.
  • 10.
    … Cont’d  Operationscan be invoked by passing a message to an object, which includes the operation name and the parameters.  The object then executes the method for that operation.  This encapsulation permits modification of the internal structure of an object, as well as the implementation of its operations, without the need to disturb the external programs that invoke these operations.  Some OO systems provide capabilities for dealing with multiple versions of the same object (a feature that is essential in design and engineering applications).  For example, an old version of an object that represents a tested and verified design should be retained until the new version is tested and verified:  very crucial for designs in manufacturing process control, architecture , software systems …..
  • 11.
    … Cont’d  Operatorpolymorphism:  This refers to an operation’s ability to be applied to different types of objects; in such a situation, an operation name may refer to several distinct implementations, depending on the type of objects it is applied to.  This feature is also called operator overloading Object Identity, Object Structure, and Type Constructors  Unique 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 be immutable  Specifically, the OID value of a particular object should not change.  This preserves the identity of the real-world object being represented.
  • 12.
    … cont’d  TypeConstructors:  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.  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.
  • 13.
    … Cont’d  Example1  One possible relational database state corresponding to COMPANY schema
  • 14.
  • 15.
    … Cont’d  Example1 (contd.)  We use i1, i2, i3, . . . to stand for unique system-generated object identifiers. Consider the following objects:  o1 = (i1, atom, ‘Houston’)  o2 = (i2, atom, ‘Bellaire’)  o3 = (i3, atom, ‘Sugarland’)  o4 = (i4, atom, 5)  o5 = (i5, atom, ‘Research’)  o6 = (i6, atom, ‘1988-05-22’)  o7 = (i7, set, {i1, i2, i3})  Example 1(contd.)  o8 = (i8, tuple, <dname:i5, dnumber:i4, mgr:i9, locations:i7, employees:i10, projects:i11>)  o9 = (i9, tuple, <manager:i12, manager_start_date:i6>)  o10 = (i10, set, {i12, i13, i14})  o11 = (i11, set {i15, i16, i17})  o12 = (i12, tuple, <fname:i18, minit:i19, lname:i20, ssn:i21, . . ., salary:i26, supervisor:i27, dept:i8>)  . . .
  • 16.
    … Cont’d  Example1 (contd.)  The first six objects listed in this example represent atomic values.  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’}.  Object 8 is a tuple-valued object that represents department 5 itself, and has the attributes DNAME, DNUMBER, MGR, LOCATIONS, and so on.  Example 2:  This example illustrates the difference between the two definitions for comparing object states for equality.  o1 = (i1, tuple, <a1:i4, a2:i6>)  o2 = (i2, tuple, <a1:i5, a2:i6>)  o3 = (i3, tuple, <a1:i4, a2:i6>)  o4 = (i4, atom, 10)  o5 = (i5, atom, 10)  o6 = (i6, atom, 20)
  • 17.
    … cont’d  Example2 (contd.):  In this example, The objects o1 and o2 have equal states, since their states at the atomic level are the same but the values are reached through distinct objects o4 and o5.  However, the states of objects o1 and o3 are identical, even though the objects themselves are not because they have distinct OIDs.  Similarly, although the states of o4 and o5 are identical, the actual objects o4 and o5 are equal but not identical, because they have distinct OIDs.
  • 18.
  • 19.
  • 20.
    … Cont’d  Encapsulation One of the main characteristics of OO languages and systems  Related to the concepts of abstract data types and information hiding in programming languages  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 general-purpose 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).
  • 21.
  • 22.
    … Cont’d  SpecifyingObject 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
  • 23.
  • 24.
    … cont’d  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, to simplify the discussion:  TYPE_NAME: function, function, . . . , function  Example:  PERSON: Name, Address, Birthdate, Age, SSN  Subtype:  When the designer or user must create a new type that is similar but not identical to an already defined type  Supertype:  It inherits all the functions of the subtype
  • 25.
    … cont’d  Example(1):  PERSON: Name, Address, Birthdate, Age, SSN  EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary, HireDate, Seniority  STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA  OR:  EMPLOYEE subtype-of PERSON: Salary, HireDate, Seniority  STUDENT subtype-of PERSON: Major, GPA  Example (2):  Consider a type that describes objects in plane geometry, which may be defined as follows:  GEOMETRY_OBJECT: Shape, Area, ReferencePoint  Now suppose that we want to define a number of subtypes for the GEOMETRY_OBJECT type, as follows:  RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height  TRIANGLE subtype-of GEOMETRY_OBJECT: Side1, Side2, Angle  CIRCLE subtype-of GEOMETRY_OBJECT: Radius
  • 26.
    … Cont’d  Example(2) (contd.):  An alternative way of declaring these three subtypes is to specify the value of the Shape attribute as a condition that must be satisfied for objects of each subtype:  RECTANGLE subtype-of GEOMETRY_OBJECT (Shape=‘rectangle’): Width, Height  TRIANGLE subtype-of GEOMETRY_OBJECT (Shape=‘triangle’): Side1, Side2, Angle  CIRCLE subtype-of GEOMETRY_OBJECT (Shape=‘circle’): Radius
  • 27.
    … cont’d  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.  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
  • 28.
    Complex Objects (1) Unstructured complex object:  These 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.
  • 29.
    Complex Objects (2) 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.
  • 30.
    Other Objected-Oriented Concepts(1)  Polymorphism (Operator Overloading):  This concept allows the same operator name or symbol to be bound to two or more different implementations of the operator, depending on the type of objects to which the operator is applied  For example + can be:  Addition in integers  Concatenation in strings (of characters)
  • 31.
    Other Objected-Oriented Concepts(2)  Multiple Inheritance and Selective Inheritance  Multiple inheritance in a type hierarchy occurs when a certain subtype T is a subtype of two (or more) types and hence inherits the functions (attributes and methods) of both supertypes.  For example, we may create a subtype ENGINEERING_MANAGER that is a subtype of both MANAGER and ENGINEER.  This leads to the creation of a type lattice rather than a type hierarchy.
  • 32.
    Object Query Language Developed by ODMG, Object Query Language allows SQL-like queries to be performed on a OODB.  Like SQL, it is a declarative language. Based loosely on SQL, OQL includes additional language constructs which allow for object oriented design such as operation invocation and inheritance.  Query Structures look very similar in SQL and OQL but the results returned are different.
  • 33.
    … Cont’d  Example:OQL query to obtain Voter names who are from the state of Colorado Select distinct v.name From voters v Where v.state = “Colorado”
  • 34.
    Object-oriented vs relationalModel  A method in an object model is defined in the class to which the object belongs.  A stored procedure is a sub-routine available to applications and this is external to the database , defined in the data dictionary.  Example: Stored procedures for data validation  OODB is OO language specific whereas Relational DB are language independent via SQL  No impedance mismatch in applications using OODB where as object relational mapping must be performed in relational database for use in OO applications.
  • 35.
    Current Status  OODBmarket growing very slowly these days.  O-O ideas are being used in a large number of applications, without explicitly using the OODB platform to store data.  Growth:  O-O tools for modeling and analysis, O-O Programming Languages like Java and C++  Compromise Solution Proposed:  Object Relational DB Management (Informix Universal Server, Oracle 10i, IBM’s UDB, DB2/II …)