Object oriented database concepts

O B J E C T O R I E N T E D D A T A B A S E S
B Y I N S T R U C T O R T E M E S G E N T
Advanced database systems

Introduction
 Database systems that were based on the
object data model were known originally as object-
oriented databases (OODBs).
 but are now referred to as object databases (ODBs).
 Traditional data models have certain shortcomings when
more complex database applications.
 For example, databases for engineering design and
manufacturing (CAD/CAM and CIM1), biological and
other sciences, telecommunications, geographic
information systems, and multimedia.
 These ODBs were developed for applications that have
requirements requiring more complex structures for
stored objects.

Cont’d
 A key feature of object databases is the power they give the designer
to specify both the structure of complex objects and the operations.
 object-oriented databases is the vast increase in the use of object-
oriented programming languages for developing software
applications. For e.g. C++,Java
 Object-oriented databases have adopted many of the concepts that
were developed originally for object-oriented programming
languages. That were later incorporated into object-relational
systems and the SQL standard.
 We will see oo database concepts include object identity, object
structure and type constructors, encapsulation of operations, and
the definition of methods as part of class declarations, mechanisms
for storing objects in a database by making them persistent, and
type and class hierarchies and inheritance.

Overview of Object Database Concepts
 An object typically has two components: state (value)
and behavior (operations).
 It can have a complex data structure as well as specific
operations defined by the programmer.
 Objects in an OOPL exist only during program execution are
called transient objects.
 persistent objects that exist beyond program termination and
can be retrieved later and shared by other programs.
 The internal structure of an object in OOPLs includes the
specification of instance variables.
 Object-oriented systems allow definition of the operations or
functions (behavior) that can be applied to objects of a particular
type.
 In fact, some OO models insist that all operations a user can
apply to an object must be predefined. This forces a complete
encapsulation of objects.

Cont’d
 To encourage encapsulation, an operation is defined in
two parts. The first part,called the signature or
interface of the operation, specifies the operation
name and arguments (or parameters).
 The second part, called the method or body, specifies
the implementation of the operation, usually written
in some general-purpose programming language.
 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.

Cont’d
 Another key concept in OO systems is that of type and
class hierarchies and inheritance.
 This permits specification of new types or classes that
inherit much of their structure and/or operations from
previously defined types or classes.
 This makes it easier to develop the data types of a
system incrementally and to reuse existing type
definitions when creating new types of objects.
 One problem in early OO database systems involved
representing relationships among objects.
 relationships should not be explicitly represented, but
should instead be described by defining appropriate
methods that locate related objects.

Cont’d
 Another OO concept is operator overloading,
which 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 object it is applied to.
 This feature is also called operator polymorphism.
 This may require the use of late binding of the
operation name to the appropriate method at
runtime, when the type of object to which the
operation is applied becomes known.

Object Identity, and Objects versus
Literals
 One goal of an ODB is 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.
 Hence, a unique identity is assigned to each
independent object stored in the database.
 This unique identity is typically implemented via a unique,
system-generated object identifier (OID).
 The value of an OID may not be visible to the external user
but is used internally by the system to identify each object
uniquely and to create and manage interobject references.
 The OID can be assigned to program variables of the
appropriate type when needed.

Cont’d
 The main property required of an OID is that it be
immutable; that is, the OID value of a particular
object should not change.
 It is also desirable that each OID be used only once;
that is, even if an object is removed from the database,
its OID should not be assigned to another object.
 These two properties imply that the OID should not
depend on any attribute values of the object.
 It is also inappropriate to base the OID on the physical
address of the object in storage, since the physical
address can change after a physical reorganization of
the database.

Complex Type Structures for Objects and
Literals
 Another feature of ODBs is that objects and literals
may have a type structure of arbitrary complexity in
order to contain all of the necessary information
that describes the object or literal.
 In ODBs, a complex type may be constructed from
other types by nesting of type constructors.
 The three most basic constructors are atom, struct
(or tuple), and collection.

The atom constructor
 One type constructor has been called the atom
constructor.
 This includes the basic built-in data types of the
object model, which are similar to the basic types in
many programming languages: integers, strings,
floating-point numbers, enumerated types,
Booleans, and so on.
 These basic data types are called singlevalued
 or atomic types, since each value of the type is
considered an atomic (indivisible) single value.

The struct (or tuple) constructor
 This can create standard structured types, such as
the tuples (record types) in the basic relational
model.
 A structured type is made up of several components
and is also sometimes referred to as a compound or
composite type.
 More accurately, the struct constructor is not
considered to be a type, but rather a type
generator.

Collection (or multivalued) type
constructors
 include the set(T), list(T), bag(T), array(T), and
dictionary(K,T) type constructors.
 These allow part of an object or literal value to include a
collection of other objects or values when needed.
 These constructors are also considered to be type
generators because many different types can be
created.
 For example, set(string),set(integer), and set(Employee)
are three different types that can be created from the set
type constructor.
 All the elements in a particular collection value must be
of the same type. For example, all values in a collection of
type set(string) must be string values.

Cont’d
 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.
 The tuple constructor can create structured values and
objects of the form <a1:i1, a2:i2, … , an:in>, where each aj
is an attribute name6 andeach ij is a value or an OID.
 The other commonly used constructors are collectively
referred to as collection types but have individual
differences among them.
 The set constructor will create objects or literals that are
a set of distinct elements {i1, i2, … , in}, all of the same type.
 The bag constructor (also called a multiset) is similar
to a set except that the elements in a bag need not be
distinct.

Cont’d
 The list constructor will create an ordered list[i1,
i2, … , in] of OIDs or values of the same type.
 A list is similar to a bag except that the elements in a
list are ordered, and hence we can refer to the first,
second, or jth element.
 The array constructor creates a single-
dimensional array of elements of the same type.
 The main difference between array and list is that a
list can have an arbitrary number of elements
whereas an array typically has a maximum size.

Cont’d
 Finally, the dictionary constructor creates a collection of
key-value pairs (K, V),where the value of a key K can be used
to retrieve the corresponding value V.
 The main characteristic of a collection type is that its objects
or values will be a collection of objects or values of the same
type that may be unordered (such as a set or a bag) or
ordered (such as a list or an array).
 The tuple type constructor is often called a structured
type, since it corresponds to the struct construct in the C and
C++ programming languages.
 An object definition language (ODL) that incorporates
the preceding type constructors can be used to define the
object types for a particular database application.

ODL
 define type EMPLOYEE
 tuple ( Fname: string;
 Minit : char;
 Lname: string;
 Ssn: string;
 Birth_date: DATE;
 Address: string;
 Sex: char;
 Salary: float;
 Supervisor: EMPLOYEE;
 Dept: DEPARTMENT;
 define type DATE
 tuple ( Year: integer;
 Month: integer;
 Day: integer; );
 define type DEPARTMENT
 tuple ( Dname: string;
 Dnumber: integer;
 Mgr: tuple ( Manager: EMPLOYEE;
 Start_date: DATE; );
 Locations: set(string);
 Employees: set(EMPLOYEE);
 Projects: set(PROJECT); );

Encapsulation of Operation and
Persistence of Objects
 The concept of encapsulation is one of the main
characteristics of OO languages and systems.
 It is also related to the concepts of abstract data types and
information hiding in programming languages.
 In traditional database models and systems this concept was
not applied.
 The concept of encapsulation is applied to database objects in
ODBs by defining 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.

Cont’d
 The external users of the object are only made aware
of the interface of the operations, which defines
the name and arguments (parameters) of each
operation.
 The implementation is hidden from the external
users.
 The interface part of an operation is sometimes
called the signature, and the operation
implementation is sometimes called the method.

Cont’d
 One way to relax this requirement is to divide the
structure of an object into visible and hidden
attributes (instance variables).
 Visible attributes can be seen by and are directly
accessible to the database users an programmers via the
query language.
 The hidden attributes of an object are completely
encapsulated and can be accessed only through
predefined operations.
 The term class is often used to refer to a type
definition, along with the definitions of the operations
for that type.

Cont’d
 A number of operations are declared for each class, and the
signature (interface) of each operation is included in the
class definition.
 A method (implementation) for each operation must be
defined elsewhere using a programming language.
 Typical operations include the object constructor
operation (often called new), which is used to create a new
object.
 The destructor operation, which is used to destroy
(delete) an object.
 A number of object modifier operations can also be
declared to modify the states (values) of various
attributes of an object.
 Additional operations can retrieve information about the
object.

ODL
 define class EMPLOYEE
 type tuple ( Fname: string;
 Minit: char;
 Lname: string;
 Ssn: string;
 Birth_date: DATE;
 Address: string;
 Sex: char;
 Salary: float;
 Supervisor: EMPLOYEE;
 Dept: DEPARTMENT; );
 operations age: integer;
 create_emp: EMPLOYEE;
 destroy_emp: boolean;
 end EMPLOYEE;
 define class DEPARTMENT
 type tuple ( Dname: string;
 Dnumber: integer;
 Mgr: tuple ( Manager: EMPLOYEE;
 Start_date: DATE; );
 Locations: set (string);
 Employees: set (EMPLOYEE);
 Projects set(PROJECT); );
 operations no_of_emps: integer;
 create_dept: DEPARTMENT;
 destroy_dept: boolean;
 assign_emp(e: EMPLOYEE): boolean;
 (* adds an employee to the department *)
 remove_emp(e: EMPLOYEE): boolean;
 (* removes an employee from the department *)
 end DEPARTMENT;

Cont’d
 An operation is typically applied to an object by
using the dot notation.
 For example, if d is a reference to a
DEPARTMENT object, we can invoke an operation
such as no_of_emps by writing d.no_of_emps.

Specifying Object Persistence via Naming
and Reachability
 An ODBS is often closely coupled with an object-
oriented programming language (OOPL).
 The OOPL is used to specify the method (operation)
implementations as well as other application code.
 Transient objects exist in the executing program
and disappear once the program terminates.
 Persistent objects are stored in the database and
persist after program termination.
 The typical mechanisms for making an object
persistent are naming and reachability.

Cont’d
 The naming mechanism involves giving an object a
unique persistent name within a particular database.
 This persistent object name can be given via a specific
statement or operation in the program.
 The named persistent objects are used as entry points
to the database through which users and applications can
start their database access.
 Obviously, it is not practical to give names to all objects
in a large database. so most objects are made persistent
by using the second mechanism, called reachability.

Cont’d
 The reachability mechanism works by making the
object reachable from some other persistent object.
 An object B is said to be reachable from an
object A if a sequence of references in the
database lead from object A to object B.

codes
 define class DEPARTMENT_SET
 type set (DEPARTMENT);
 operations add_dept(d: DEPARTMENT): boolean;
 (* adds a department to the DEPARTMENT_SET object *)
 remove_dept(d: DEPARTMENT): boolean;
 (* removes a department from the DEPARTMENT_SET object *)
 create_dept_set: DEPARTMENT_SET;
 destroy_dept_set: boolean;
 end Department_Set;
 …
 persistent name ALL_DEPARTMENTS: DEPARTMENT_SET;
 (* ALL_DEPARTMENTS is a persistent named object of type DEPARTMENT_SET *)
 …
 d:= create_dept;
 (* create a new DEPARTMENT object in the variable d *)
 …
 b:= ALL_DEPARTMENTS.add_dept(d);
 (* make d persistent by adding it to the persistent set ALL_DEPARTMENTS *).

Type Hierarchies and Inheritance
 Simplified Model for Inheritance. Another
main characteristic of ODBs is that they allow type
hierarchies and inheritance.
 It distinguishes between two types of inheritance.
 Inheritance allows the definition of new types based
on other predefined types, leading to a type (or
class) hierarchy.
 A type is defined by assigning it a type name and
then defining a number of attributes (instance
variables) and operations (methods) for the type.

Cont’d
 In the simplified model we use in this section, the
attributes and operations are together called
functions,
 since attributes resemble functions with zero
arguments.
 A function name can be used to refer to the value of
an attribute or to refer to the resulting value of an
operation (method).
 We use the term function to refer to both attributes
and operations, since they are treated similarly in a
basic introduction to inheritance.

Cont’d
 A type in its simplest form has a type name and a list
of visible (public) functions.
TYPE_NAME: function, function, … , function
 For example, a type that describes characteristics of a
PERSON may be defined as follows:
PERSON: Name, Address, Birth_date, Age, Ssn
 In the PERSON type, the Name, Address, Ssn, and
Birth_date functions can be implemented as stored
attributes, whereas the Age function can be implemented
as an operation that calculates the Age from the value of
the Birth_date attribute and the current date.

Cont’d
 The concept of subtype is useful when the designer
or user must create a new type that is similar but not
identical to an already defined type.
 The subtype then inherits all the functions of the
predefined type, which is referred to as the
supertype.
 EMPLOYEE: Name, Address, Birth_date, Age, Ssn,
Salary, Hire_date, Seniority
 STUDENT: Name, Address, Birth_date, Age, Ssn,
Major, Gpa

Cont’d
 Therefore, we can declare EMPLOYEE and
STUDENT as follows:
 EMPLOYEE subtype-of PERSON: Salary,
Hire_date, Seniority
 STUDENT subtype-of PERSON: Major, Gpa
 In general, a subtype includes all of the functions
that are defined for its supertype plus some
additional functions that are specific only to the
subtype.

Cont’d
 Constraints on Extents Corresponding to a Type
Hierarchy.
 In most ODBs, an extent is defined to store the
collection of persistent objects for each type or subtype.
 All extents for system- and user-defined classes are
subsets of the extent corresponding to the class OBJECT,
directly or indirectly.
 An extent is a named persistent object whose value is a
persistent collection that holds a collection of objects
of the same type that are stored permanently in the
database.
 The objects can be accessed and shared by multiple
programs. It is also possible to create a transient
collection.

Other Object-Oriented Concepts
 Polymorphism of Operations (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.
 A simple example from programming languages can
illustrate this concept.
 In some languages, the operator symbol “+” can mean
different things when applied to operands (objects) of
different types.
 In some languages, the operator symbol “+” can mean
different things when applied to operands (objects) of
different types.

Cont’d
 The ODMS must now select the appropriate method for
the Area function based on the type of geometric object
to which it is applied. In strongly typed systems,
 This can be done at compile time, since the object types
must be known. This is termed early (or static)
binding.
 Multiple Inheritance and Selective Inheritance.
Multiple inheritance 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.

Object Database Extensions to SQL
 The relational model with object database
enhancements is sometimes referred to as the object-
relational model.
 The following are some of the object database features
that have been included in SQL:
 Some type constructors have been added to
specify complex objects. These include the row
type, which corresponds to the tuple (or struct)
constructor.
 An array type for specifying collections is also
provided. Other collection type constructors, such as
set, list, and bag constructors, were not part of the
original SQL/Object specifications in SQL:99 but were
later included in the standard in SQL:2008.

Cont’d
 A mechanism for specifying object identity
through the use of reference type is included.
 Encapsulation of operations is provided through the
mechanism of user-defined types (UDTs) that may
include operations as part of their declaration.
 Inheritance mechanisms are provided using the
keyword UNDER.

User-Defined Types Using CREATE
TYPE and Complex Objects
 a complex structure for objects (tuples) in a table can be created,
much like that achieved by nesting type constructors generator.
 CREATE TYPE STREET_ADDR_TYPE AS (
 NUMBER VARCHAR (5),
 STREET NAME VARCHAR (25),
 APT_NO VARCHAR (5),
 SUITE_NO VARCHAR (5)
 );
 CREATE TYPE USA_ADDR_TYPE AS (
 STREET_ADDR STREET_ADDR_TYPE,
 CITY VARCHAR (25),
 ZIP VARCHAR (10)
 );
 CREATE TYPE USA_PHONE_TYPE AS (
 PHONE_TYPE VARCHAR (5),
 AREA_CODE CHAR (3),
 PHONE_NUM CHAR (7)
 );

Cont’d
 CREATE TYPE PERSON_TYPE AS (
 NAME VARCHAR (35),
 SEX CHAR,
 BIRTH_DATE DATE,
 PHONES USA_PHONE_TYPE ARRAY [4],
 ADDR USA_ADDR_TYPE
 INSTANTIABLE
 NOT FINAL
 REF IS SYSTEM GENERATED
 INSTANCE METHOD AGE() RETURNS INTEGER;
 CREATE INSTANCE METHOD AGE() RETURNS INTEGER
 FOR PERSON_TYPE
 BEGIN
 RETURN /* CODE TO CALCULATE A PERSON’S AGE FROM
 TODAY’S DATE AND SELF.BIRTH_DATE */
 END;
 );

Cont’d
 CREATE TYPE GRADE_TYPE AS (
 COURSENO CHAR (8),
 SEMESTER VARCHAR (8),
 YEAR CHAR (4),
 GRADE CHAR
 );
 CREATE TYPE STUDENT_TYPE UNDER PERSON_TYPE AS (
 MAJOR_CODE CHAR (4),
 STUDENT_ID CHAR (12),
 DEGREE VARCHAR (5),
 TRANSCRIPT GRADE_TYPE ARRAY [100]

Cont’d
 INSTANTIABLE
 NOT FINAL
 INSTANCE METHOD GPA( ) RETURNS FLOAT;
 CREATE INSTANCE METHOD GPA( ) RETURNS FLOAT
 FOR STUDENT_TYPE
 BEGIN
 RETURN /* CODE TO CALCULATE A STUDENT’S GPA FROM
 SELF.TRANSCRIPT */
 END;
 );
 CREATE TYPE EMPLOYEE_TYPE UNDER PERSON_TYPE AS (
 JOB_CODE CHAR (4),
 SALARY FLOAT,
 SSN CHAR (11)
 INSTANTIABLE
 NOT FINAL
 );
 CREATE TYPE MANAGER_TYPE UNDER EMPLOYEE_TYPE AS (
 DEPT_MANAGED CHAR (20)
 INSTANTIABLE
 );

Cont’d
 (d) CREATE TABLE PERSON OF PERSON_TYPE
 REF IS PERSON_ID SYSTEM GENERATED;
 CREATE TABLE EMPLOYEE OF EMPLOYEE_TYPE
 UNDER PERSON;
 CREATE TABLE MANAGER OF MANAGER_TYPE
 UNDER EMPLOYEE;
 CREATE TABLE STUDENT OF STUDENT_TYPE
 UNDER PERSON;
 (e) CREATE TYPE COMPANY_TYPE AS (
 COMP_NAME VARCHAR (20),
 LOCATION VARCHAR (20));
 CREATE TYPE EMPLOYMENT_TYPE AS (
 Employee REF (EMPLOYEE_TYPE) SCOPE (EMPLOYEE),
 Company REF (COMPANY_TYPE) SCOPE (COMPANY) );
 CREATE TABLE COMPANY OF COMPANY_TYPE (
 REF IS COMP_ID SYSTEM GENERATED,
 PRIMARY KEY (COMP_NAME) );
 CREATE TABLE EMPLOYMENT OF EMPLOYMENT_TYPE;

Object Identifiers Using Reference Types
 Unique system-generated object identifiers can be
created via the reference type using the keyword
REF.
REF IS SYSTEM GENERATED
 indicates that whenever a new PERSON_TYPE
object is created, the system will assign it a unique
system-generated identifier.
 In general, the user can specify that system-
generated object identifiers for the individual rows in
a table should be created. By using the syntax:
 REF IS <OID_ATTRIBUTE<VALUE_GENERATION_METHOD> ;

Creating Tables Based on the UDTs
 For each UDT that is specified to be instantiable via
the phrase INSTANTIABLE.
 CREATE TYPE MANAGER_TYPE UNDER EMPLOYEE_TYPE AS (
 DEPT_MANAGED CHAR (20)
 INSTANTIABLE
 );

Encapsulation of Operations
 In SQL, a user-defined type can have its own
behavioral specification by specifying methods (or
operations) in addition to the attributes. The general
form of a UDT specification with methods is as follows:
 CREATE TYPE <TYPE-NAME> (
 <LIST OF COMPONENT ATTRIBUTES AND THEIR TYPES>
 <DECLARATION OF FUNCTIONS (METHODS)>
 );
 SQL provides certain built-in functions for user-
defined types. For a UDT called
 TYPE_T, the constructor function TYPE_T( )
returns a new object of that type.
 In the new UDT object, every attribute is initialized to
its default value.

Cont’d
 An observer function A is implicitly created for
each attribute A to read its value. Hence, A(X) or
X.A returns the value of attribute A of TYPE_T if X
is a variable that refers to an object/row of type
TYPE_T.
 A mutator function for updating an attribute
sets the value of the attribute to a new value.
 SQL allows these functions to be blocked from
public use; an EXECUTE privilege is needed to have
access to these functions.

Cont’d
 In general, a UDT can have a number of user-defined
functions associated with it.
 The syntax is
 INSTANCE METHOD <NAME> (<ARGUMENT_LIST>) RETURNS <RETURN_TYPE>;
 Two types of functions can be defined: internal SQL and
external. Internal functions are written in the extended PSM
language of SQL.
 DECLARE EXTERNAL <FUNCTION_NAME> <SIGNATURE> LANGUAGE
<LANGUAGE_NAME>;
 Attributes and functions in UDTs are divided into three
categories:
 ■ PUBLIC (visible at the UDT interface)
 ■ PRIVATE (not visible at the UDT interface)
 ■ PROTECTED (visible only to subtypes)

Specifying Inheritance and Overloading of
Functions
 SQL has rules for dealing with type inheritance (specified via the UNDER
keyword).
 In general, both attributes and instance methods (operations) are inherited.
The phrase NOT FINAL must be included in a UDT if subtypes are
allowed to be created under that UDT.
 These inheritance rules can be summarized as follows:
 ■ All attributes are inherited.
 ■ The order of supertypes in the UNDER clause determines the inheritance
 hierarchy.
 ■ An instance of a subtype can be used in every context in which a supertype
 instance is used.
 ■ A subtype can redefine any function that is defined in its supertype, with the
 restriction that the signature be the same.
 ■ When a function is called, the best match is selected based on the types of all
 arguments.
 ■ For dynamic linking, the types of the parameters are considered at runtime

Specifying Relationships via Reference
 A component attribute of one tuple may be reference
(specified using the keyword REF) to a tuple of
another (or possibly the same) table.
 The keyword SCOPE specifies the name of the
table whose tuples can be referenced by the
reference attribute. Notice that this is similar to a
foreign key, except that the system-generated OID
value is used rather than the primary key value.
 SQL uses a dot notation to build path expressions
that refer to the component attributes of tuples and
row types.

Cont’d
 SELECT E.Employee–>NAME FROM EMPLOYMENT AS E
 WHERE E.Company–>COMP_NAME = ‘ABCXYZ’;
 In SQL, –> is used for dereferencing and has the same
meaning assigned to it in the C programming language.

Object oriented database concepts

More Related Content

What's hot

Similar to Object oriented database concepts

Recently uploaded

Object oriented database concepts