CHAPTER ONE

OBJECT ORIENTED DATABASE Concepts

INTRODUCTION:
Database System Applications:
Database Management System (DBMS) contains
information about a particular enterprise:
Collection of interrelated data, Set of programs to
access the data and an environment that is both
convenient and efficient to use
• Database Applications:
– Banking: all transactions
– Airlines: reservations, schedules
– Universities: registration, grades
– Sales: customers, products, purchases
– Online retailers: order tracking, customized
recommendations
– Manufacturing: production, inventory, orders,
supply chain
– Human resources: employee records,
Data: Facts concerning things such as people, object,
events etc. e.g. students, the courses they are taking
and their grades etc.
Information: Data that have been processed and
presented in a form suitable for human
interpretation, often with the purpose of revealing
trends or patterns e.g. percentage enrollment in
various courses, enrollment projections, top rankers
etc.
Steps in transforming Data into Information:
1. Acquisition: Acquiring data from the
environment. This data acquired will be in an
unorganized form.
2. Storage: It is at this level the data starts
transforming into information and stored on a
medium.
3. Manipulation: The stored information is
manipulated according to the requirements.
4. Retrieval: The information is retrieved from the
storage medium.
5. Distribution: The retrieved information is
distributed/presented to the users.
Drawbacks of File System:
Data redundancy and inconsistency - Multiple
file formats, duplication of information in different
files.
Difficulty in accessing data - Need to write a new
program to carry out each new task
Data isolation - multiple files and formats
Integrity problems - Integrity constraints (e.g.
account balance > 0) become ―buried‖ in program
code rather than being stated explicitly; Hard to add
new constraints or change existing ones
Object Database Standards, Languages, and
Design
A standard for a particular type of database system
is very important, because it provides support for
portability of database applications. Portability is
generally defined as the capability to execute a
particular application program on different systems
with minimal modifications to the program itself.
A second potential advantage of having and
adhering to standards is that it helps in
achieving interoperability, which generally
refers to the ability of an application to
access multiple distinct systems. In
database terms, this means that the same
application program may access some data
stored under one ODBMS package, and
other data stored under another package
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. In fact,
this object model provides the data types, type
constructors, and other concepts that can be
utilized in the ODL to specify object database
schemas. Hence, it is meant to provide a standard
data model for object-oriented databases, just as
the SQL report describes a standard data model
for relational databases.
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 only a value but no object identifier.
An object is described by four characteristics:
•identifier,
•name,
•lifetime, and
•structure.
 The object identifier is a unique system-wide
identifier (or Object_Id). Every object must have an
object identifier. In addition to the Object_Id, some
objects may optionally be given a unique name
within a particular database this name can be used to
refer to the object in a program, and the system
should be able to locate the object given that name.
Obviously, not all individual objects will have
unique names. Typically, a few objects, mainly
those that hold collections of objects of a particular
object type such as extents will have a name.
These names are used as entry points to the
database; that is, by locating these objects by
their unique name, the user can then locate other
objects that are referenced from these objects.
Other important objects in the application may
also have unique names. All such names within a
particular database must be unique. The lifetime
of an object specifies whether it is a persistent
object (that is, a database object) or transient
object (that is, an object in an executing program
that disappears after the program terminates).
In the object model, a literal is a value that does not have
an object identifier. However, the value may have a simple
or complex structure. There are three types of literals:
•atomic, collection, and Structured.
Atomic literals correspond to the values of basic data
types and are predefined. The basic data types of the
object model include long, short, and unsigned integer
numbers (these are specified by the keywords Long, Short,
Unsigned Long, Unsigned Short in ODL), regular and
double precision floating point numbers (Float, Double),
Boolean values (Boolean), single characters (Char),
character strings (String), and enumeration types (Enum),
among others.
Collection literals specify a value that is a
collection of objects or values but the collection
itself does not have an Object_Id. The
collections in the object model are Set<t>,
Bag<t>, List<t>, and Array<t>, where t is the
type of objects or values in the collection
Structured literals correspond roughly to values
that are constructed using the tuple constructor
they include Date, Interval, Time, and
Timestamp as built-in structures, as well as any
additional user-defined type structures as needed
by each application.
Built-in Interfaces for Collection Objects
Any collection object inherits the basic Collection
interface which shows the operations for all collection
objects. Given a collection object O, the O.cardinality ()
operation returns the number of elements in the
collection. The operation O.is_empty () returns true if the
collection O is empty, and false otherwise. The operations
O.insert_element (e) and O.remove_element (e) insert or
remove an element e from the collectionO. Finally, the
operation o.contains_element (e) returns true if the
collection o includes element e, and returns false
otherwise.
Atomic (User-Defined) Objects
In the object model, any user-defined object that is not a
collection object is called an atomic object. For example,
in a UNIVERSITY database application, the user can
specify an object type (class) for Student objects. Most
such objects will be structured objects; for example, a
Student object will have a complex structure, with many
attributes, relationships, and operations, but it is still
considered atomic because it is not a collection. Such a
user-defined atomic object type is defined as a class by
specifying its properties and operations. The properties
define the state of the object and are further distinguished
into attributes and relationships.
Example:
Class Employees
{ Extent all_employees
Key }
{ attribute string name;
Attribute string eno;
Attribute date date of birth;
Attribute enum Gender(M,F) sex;
Attribute short age;
Relationships department works_for
Inverse Department::has_emps;
Void reassign_emp (in string new_dname) raises
(dname_not_valid);
}
An attribute is a property that describes some
aspect of an object. Attributes have values, which
are typically literals having a simple or complex
structure that is stored within the object.
A relationship is a property that specifies that
two objects in the database are related
together. In the object model of ODMG (Object
Data Management Group), only binary
relationships are explicitly represented, and
each binary relationship is represented by a
pair of inverse references specified via the
keyword relationship.
Interfaces, Classes, and Inheritance
An interface is a specification of the abstract
behavior of an object type, which specifies the
operation signatures. Although an interface
may have state properties (attributes and
relationships) as part of its specifications, these
cannot be inherited from the interface. An
interface also is noninstantiable that is; one
cannot create objects that correspond to an
interface definition
A class is a specification of both the abstract behavior and
abstract state of an object type, and is insatiable that is,
one can create individual object instances corresponding
to a class definition. Because interfaces are non insatiable,
they are mainly used to specify abstract operations that
can be inherited by classes or by other interfaces. This is
called behavior inheritance and is specified by the ":"
symbol.
Another inheritance relationship, called EXTENDS and
specified by the extends keyword, is used to inherit both
state and behavior strictly among classes. In an
EXTENDS inheritance, both the super type and the
subtype must be classes. Multiple inheritance via
EXTENDS is not permitted.
Extents, Keys, and Factory Objects:
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 objects of the class. A class with an
extent can have one or more keys. A key consists of one or
more properties (attributes or relationships) whose values
are constrained to be unique for each object in the extent.
For example Employee class has the eno attribute as key
(each Employee object in the extent must have a unique eno
value), and the Department class has two distinct keys:
dname and dnumber (each Department must have a unique
dname and a unique dnumber).
The Object Definition Language
The ODL is designed to support the semantic
constructs of the ODMG 2.0 object model and is
independent of any particular programming
language. Its main use is to create object
specifications—that is, classes and interfaces.
Hence, ODL is not a full programming language.
A user can specify a database schema in ODL
independently of any programming language,
then 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.
Atomicity of updates - Failures may leave
database in an inconsistent state with partial
updates carried out; Example: Transfer of funds
from one account to another should either
complete or not happen at all Concurrent access
by multiple users - Concurrent access needed for
performance; Uncontrolled concurrent accesses
can lead to inconsistencies. Example: Two people
reading a balance and updating it at the same time
Security problems - Hard to provide user access to
some, but not all, data
Database Approach :
Many of the mentioned disadvantages are a result of the
approach which concentrates on the system‘s processes
first (process-driven approach) and treats the data as
inputs and outputs to those processes. The database
approach instead considers the system‘s data first (data-
driven approach) and then identifies the processes that
interact with the data.
Designers have discovered that a combination of the two
approaches is usually the most appropriate. One reason
for this is that there are always new processes in
organizations that require new data and the structure of
such data will be driven by the processes that use it.
DBMS consists of a collection of interrelated data and a
set of programs to access those data. The primary goal of a
DBMS is to provide an environment that makes it both
convenient and efficient to retrieve and store the database
information.
DATA BASE LANGUAGE
Data Manipulation Language (DML)
Language for accessing and manipulating the data
organized by the appropriate data model
DML also known as query language
Two classes of languages
Procedural – user specifies what data is required and how
to get those data
Declarative (nonprocedural) – user specifies what data is
required without specifying how to get those data
SQL (Structured Query Language) is the most widely used query
language
Data Definition Language (DDL) : Specification notation for
defining the database schema
Example: create table account ( account_number char(10),
branch_name char(10), balance integer)
• DDL compiler generates a set of tables stored in a data dictionary
• Data dictionary contains metadata (i.e., data about data)
•Database schema
•Data storage and definition language
•Specifies the storage structure and access methods used
•Integrity constraints
•Domain constraints
•Referential integrity (e.g. branch_name must correspond to a valid
branch in the branch table)
•Authorization
Data Models
A collection of tools for describing - Data , Data relationships, Data
semantics and Data constraints.
•Relational model
•Entity-Relationship data model (mainly for database design)
•Object-based data models (Object-oriented and Object-relational)
•Semi structured data model (XML)
•Other older models: Network model & Hierarchical model
•A data model is a collection of concepts for describing data.
•A schema is a description of a particular collection of data, using a
given data model. The relational model of data is the most widely
used model today. Main concept: relation, basically a table with
rows and columns. Every relation has a schema, which describes the
columns, or fields.
OBJECT ORIENTED DATABASES:
The term object-oriented—abbreviated by OO or O-O—
has its origins in OO programming languages, or
OOPLs. Today OO concepts are applied in the areas of
databases, software engineering, knowledge bases,
artificial intelligence, and computer systems in general.
OOPLs have their roots in the SIMULA language, which
was proposed in the late 1960s. In SIMULA, the
concept of a class groups together the internal data
structure of an object in a class declaration.
Subsequently, researchers proposed the concept of
abstract data type, which hides the internal data
structures and specifies all possible external operations
that can be applied to an object, leading to the concept
of encapsulation.
An object typically has two components: state (value) and
behavior (operations). Hence, it is somewhat similar to a
program variable in a programming language, except that
it will typically have a complex data structure as well as
specific operations defined by the programmer. Objects in
an OOPL exist only during program execution and are
hence called transient objects. An OO database can extend
the existence of objects so that they are stored
permanently, and hence the objects persist beyond
program termination and can be retrieved later and shared
by other programs. In other words, OO databases store
persistent objects permanently on secondary
One goal of OO databases 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, OO
databases provide a unique system-generated
object identifier (OID) for each object.
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. Hence,
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.
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 operations from previously defined
types or classes. Hence, specification of object types can
proceed systematically.
Object Identity, Object Structure, and Type
Constructors
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 value of an OID is
not visible to the external user, but it is used
internally by the system to identify each object
uniquely and to create and manage inter-object
references.
The main property required of an OID is that it be immutable;
that is, the OID value of a particular object should not change. This
preserves the identity of the real-world object being represented.
Hence, an OO database system must have some mechanism for
generating OIDs and preserving the immutability property.
Object Structure
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. One formal way of representing such objects
is to view each object as a triple (i, c, v), where i is a unique object
identifier (the OID), c is a type constructor (that is, an indication of
how the object state is constructed), and v is the object state (or
current value).
The data model will typically include several 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.
The object state v of an object (i, c, v) is interpreted based on the
constructor c. If c = atom, the state (value) v is an atomic value
from the domain of basic values supported by the system. If c =
set, the state v is a set of object identifiers, which are the OIDs
for a set of objects that are typically of the same type. If c = tuple,
the state v is a tuple of the form, where each is an attribute name
and each is an OID. If c = list, the value v is an ordered list of
OIDs of objects of the same type. A list is similar to a set except
that the OIDs in a list are ordered, and hence we can refer to the
first, second, or object in a list. For c = array, the state of the
object is a single-dimensional array of object identifiers. 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.
Type Constructors
An object definition language (ODL) that
incorporates the preceding type constructors can be
used to define the object types for a particular
database application. The type constructors can be
used to define the data structures for an OO
database schema. the Date type is defined as a tuple
rather than an atomic value as in We use the
keywords tuple, set, and list for the type
constructors, and the available standard data types
(integer, string, float, and so on) for atomic types
Encapsulation of Operations, Methods, and Persistence
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, since it is customary to make the
structure of database objects visible to users and external
programs. In these traditional models, a number of standard
database operations are applicable to objects of all types. For
example, in the relational model, the operations for selecting,
inserting, deleting, and modifying tuples are generic and may be
applied to any relation in the database. The relation and its
attributes are visible to users and to external programs that access
the relation by using these operations.
Specifying Object Behavior via Class Operations
The concepts of information hiding and encapsulation can be
applied to database objects. 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. The internal
structure of the object is hidden, and the object is accessible
only through a number of predefined operations. Some
operations may be used to create (insert) or destroy (delete)
objects; other operations may update the object state; and
others may be used to retrieve parts of the object state or to
apply some calculations. Still other operations may perform
a combination of retrieval, calculation, and update. 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.
The external users of the object are only made aware of the
interface of the object type, which defines the name and
arguments (parameters) of each operation. The
implementation is hidden from the external users; it includes
the definition of the internal data structures of the object and
the implementation of the operations that access these
structures. In OO terminology, the interface part of each
operation is called the signature, and the operation
implementation is called a method. Typically, a method is
invoked by sending a message to the object to execute the
corresponding method. Notice that, as part of executing a
method, a subsequent message to another object may be sent
and this mechanism may be used to return values from the
objects to the external environment or to other objects.
Specifying Object Persistence via Naming and
Reachability
An OODBMS is often closely coupled with an OOPL. The
OOPL is used to specify the method implementations as
well as other application code. An object is typically created
by some executing application program, by invoking the
object constructor operation. Not all objects are meant to be
stored permanently in the database. 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.
The naming mechanism involves giving an object a
unique persistent name through which it can be retrieved
by this and other programs. This persistent object name
can be given via a specific statement or operation in the
program. All such names given to objects must be unique
within a particular database. Hence, 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 that includes thousands of
objects, so most objects are made persistent by using the
second mechanism, called reachability.
The reachability mechanism works by making 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. hence, if it is made
persistent, all the other objects also become
persistent.
Type Hierarchies and Inheritance
Another main characteristic of OO database
systems is that they allow type hierarchies and
inheritance. Type hierarchies in databases usually
imply a constraint on the extents corresponding to
the types in the hierarchy.
In most database applications, there are numerous
objects of the same type or class. Hence, OO databases
must provide a capability for classifying objects based
on their type, as do other database systems. But in OO
databases, a further requirement is that the system
permit the definition of new types based on other
predefined types, leading to a type (or class)
hierarchy. Typically, 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.
In some cases, 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 of an object type,
since they are treated similarly in a basic introduction to
inheritance.
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,
For example, a type that describes characteristics of a PERSON
may be defined as follows:
PERSON: Name, Address, Birthdate, Age, SSN
In the PERSON type, the Name, Address, SSN, and Birthdate
functions can be implemented as stored attributes, whereas the
Age function can be implemented as a method that calculates the
Age from the value of the Birthdate attribute and the current
date.
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 we shall call the supertype. For example,
suppose that we want to define two new types EMPLOYEE and
STUDENT as follows:
EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary,
HireDate, Seniority
STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA
Since both STUDENT and EMPLOYEE include all the functions
defined for PERSON plus some additional functions of their own,
we can declare them to be subtypes of PERSON. Each will
inherit the previously defined functions of PERSON—namely,
Name, Address, Birthdate, Age, and SSN.
For STUDENT, it is only necessary to define the new (local)
functions Major and GPA, which are not inherited. Presumably,
Major can be defined as a stored attribute, whereas GPA may be
implemented as a method that calculates the student’s grade
point average by accessing the Grade values that are internally
stored (hidden) within each STUDENT object as private
attributes. For EMPLOYEE, the Salary and HireDate functions
may be stored attributes, whereas Seniority may be a method
that calculates Seniority from the value of HireDate. Another
example, consider a type that describes objects in plane
geometry, which may be defined as follows:
GEOMETRY_OBJECT: Shape, Area, ReferencePoint
For the GEOMETRY_OBJECT type, Shape is implemented as
an attribute (its domain can be an enumerated type with values
‘triangle’, ‘rectangle’, ‘circle’, and so on), and Area is a method
that is applied to calculate the area. 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
Notice that the Area operation may be implemented by a
different method for each subtype, since the procedure for area
calculation is different for rectangles, triangles, and circles.
Similarly, the attribute Reference Point may have a different
meaning for each subtype; it might be the center point for
RECTANGLE and CIRCLE objects, and the vertex point
between the two given sides for a TRIANGLE object. Some OO
database systems allow the renaming of inherited functions in
different subtypes to reflect the meaning more closely. 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
Here, only GEOMETRY_OBJECT objects whose Shape=‘rectangle’ are of the
subtype RECTANGLE, and similarly for the other two subtypes. In this case, all
functions of the GEOMETRY_OBJECT supertype are inherited by each of the
three subtypes, but the value of the Shape attribute is restricted to a specific value
for each.
Complex Objects: A principal motivation that led to the development of OO systems
was the desire to represent complex objects. There are two main types of complex objects:
structured and unstructured. A structured complex object is made up of components and is
defined by applying the available type constructor’s recursively at various levels. An
unstructured complex object typically is a data type that requires a large amount of storage,
such as a data type that represents an image or a large textual object.
Unstructured Complex Objects: An unstructured
complex object facility provided by a DBMS 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. These
objects are unstructured in the sense that the DBMS does not
know what their structure is—only the application that uses
them can interpret their meaning. For example, the application
may have functions to display an image or to search for certain
keywords in a long text string.
The objects are considered complex because they require a large area of
storage and are not part of the standard data types provided by traditional
DBMSs. Because the object size is quite large, a DBMS may retrieve a
portion of the object and provide it to the application program before the
whole object is retrieved. The DBMS may also use buffering and caching
techniques to prefetch portions of the object before the application program
needs to access them.
Structured Complex Objects: A structured complex object 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. As an
example, At the first level, the object has a tuple structure with six attributes
DNAME, DNUMBER, MGR, LOCATIONS,
EMPLOYEES, and PROJECTS. However, only two of
these attributes—namely, DNAME and DNUMBER—have
basic values; the other four have complex values and hence
build the second level of the complex object structure. One
of these four (MGR) has a tuple structure, and the other
three (LOCATIONS, EMPLOYEES, PROJECTS) have set
structures. At the third level, for a MGR tuple value, we
have one basic attribute (MANAGERSTARTDATE) and
one attribute (MANAGER) that refers to an employee
object, which has a tuple structure. For a LOCATIONS set,
we have a set of basic values, but for both the
EMPLOYEES and the PROJECTS sets, we have sets of
tuple-structured objects.
Polymorphism (Operator Overloading): Another
characteristic of OO systems is that they provide for
polymorphism of operations, which is also sometimes referred
to as 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 canillustrate this concept. In some
languages, the operator symbol "+" can mean different things
when applied to operands (objects) of different types. If the
operands of "+" are of type integer, the operation invoked is
integer addition. If the operands of "+" are of type floating point,
the operation invoked is floating point addition. If the operands of
"+" are of type set, the operation invoked is set union.
The compiler can determine which operation to execute
based on the types of operands supplied.
We can use the GEOMETRY_OBJECT to illustrate
polymorphism in OO databases. Suppose that we declare
GEOMETRY_OBJECT and its subtypes as follows:
GEOMETRY_OBJECT: Shape, Area, ReferencePoint
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
Here, the function Area is declared for all objects of type
GEOMETRY_OBJECT. However, the implementation
of the method for Area may differ for each subtype of
GEOMETRY_OBJECT. One possibility is to have a
general implementation for calculating the area of a
generalized GEOMETRY_OBJECT (for example, by
writing a general algorithm to calculate the area of a
polygon) and then to rewrite more efficient algorithms to
calculate the areas of specific types of geometric objects,
such as a circle, a rectangle, a triangle, and so on. In this
case, the Area function is overloaded by different
implementations.
The OODBMS 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.
However, in systems with weak typing or no typing
(such as SMALLTALK and LISP), the type of the object
to which a function is applied may not be known until
run-time. In this case, the function must check the type of
object at run-time and then invoke the appropriate
method. This is often referred to as late (or dynamic)
binding.
Multiple Inheritance and Selective Inheritance:
Multiple inheritances 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. One problem that can occur
with multiple inheritance is that the supertypes from which the
subtype inherits may have distinct functions of the same name,
creating an ambiguity. For example, both MANAGER and
ENGINEER may have a function called Salary.
Selective inheritance occurs when a subtype inherits
only some of the functions of a supertype. Other
functions are not inherited. In this case, an EXCEPT
clause may be used to list the functions in a supertype
that are not to be inherited by the subtype. The
mechanism of selective inheritance is not typically
provided in OO database systems, but it is used more
frequently in artificial intelligence applications.