Object Oriented DBMS

The Object Oriented Data Model

 Is directly based upon the object –
oriented paradigm.
 The entity objects used by object
oriented programs are directly analogous
to database entities used by pure object
oriented databases
 Program objects is transient
 Database objects are persistent.
 Use class declarations very similar to
those used by OOP languages.
 Relationships in database
 How relationships are represented in
object oriented databases.
Object Oriented Data Relationships
 An OODB must be able to not only
represent the traditional relationships
(one to many and many to many) but also
the “Is A” relationship implied by
inheritance.
 How OODBMS represent data
relationships of all types.
Object identifiers
 Relational database system represents
relationships by having primary an foreign
key data.
 There are no data structures within the
database that form links between the tables.
The relationships are used as needed by
joining table.
 OODB hard codes its relationships by
including object identifiers within an object
to indicate other objects which it is related.
 An object identifier is an internal database
identifier for each individual objects.
 Object identifiers assigned and used only
by the DBMS
 The meaning of the identifier is unique to
each DBMS. It may be an arbitrary value
or it may include the information
necessary to locate the object in a
database file.
 Relationships in ODB:
◦ relationships are handled by reference
attributes that include OIDs of related objects
◦ single and collection of references are allowed
◦ references for binary relationships can be
expressed in single direction or both
directions via inverse operator
 One to Many relationships
 Many to Many relationships
Is A Relationship
 An object oriented database support
inheritance.
 Can also use the “is a” relationship between
objects.
 Eg. Employee class with generic attributes
such as name, address, social security
number, date of hire and department.
 Hourly and Salaried employees
 Hourly – hourly wage, overtime wage, no of
hour
 Salaried – annual salary
 Create two subclasses of employee, one
for each type of employee.
 Methods can be used by both sub classes
only once, for the Employee class
Extends Relationship
 “is a” relationship is also known as a
generalization – specialization relationship
 Where subclasses are specific types of
their super class.
 With the extends relationship, however, a
subclass expands on its superclass rather
than narrowing it to a more specific type.
 Eg. Employee class, employee working in
specific jobs.
 Database will include a Manage class that
adds an attribute for the employees that
the manager manages
 Manage is not a more specific employee
but an employee with additions
 The manager class therefore extends the
definition of each of the salary type
classes rather than making them more
specific.
Whole Part Relationship
 In which objects of class are related to
objects of other classes that are a part of it.
 In the case of manufacturing database, a
Product class would be related to Part and
subassembly classes using the whole part
relationship
 A whole part relationship is a many to many
relationship with a special meaning.
 A product can be made up of many parts
and sub assemblies .
 The same part or subassembly may be used
in many different products as well.
Relationship Integrity
 The object identifiers on both sides of the
relationship must match.
 Eg. If employees are being related to their
children, then there must be some way to ensure
that when the object identifier of child object is
inserted into an employee object, the object
identifier of the same employee object is inserted
into the child object .
 This type of relationship integrity, which is
somewhat analogous to referential in the
relational data model, is handled by specifying
inverse relationships
ER Diagramming Model for Object
Oriented Relationships
 ER-TO-OO MAPPING

We need to start from an Extended ER (EER) model.
STEP 1: Create an OO class for each EER class.
STEP 2: Add reference attributs for each binary relationship into the OO
classes that participate in that relationship.
STEP 3: Include appropriate methods for each class (not available from
EER).
STEP 4: An OO class that corresponds to a subclass in the EER schema
inherits the types and methods of the superclass in the OO schema.
STEP 5: Weak entity types can be absorbed into composite multivalued
attributes of the owner entity type.
STEP 6: N-ary relationships with N > 2 can be mapped into a separate
object type.
Booch Notation
 Provides yet another variation on using an
ER diagram to represent classes and their
associations.
 Classes are simple round – cornered
rectangles with the typical three sections:
name, attributes and methods
 Associations between classes are
represented by a variety of notation on
the lines that connect the classes
 a line with no terminator represents an
association whose cardinality is specified
by numbers on the line

 A line terminated with a single arrow

indicated inheritance. The arrow points
from the derived class to its base class.
What is Object-Oriented Data
Modeling?
 Centers around objects and classes
 Involves inheritance
 Encapsulates both data and behavior
 Benefits of Object-Oriented Modeling
◦ Ability to tackle challenging problems
◦ Improved communication between users, analysts,
designer, and programmers
◦ Increased consistency in analysis and design
◦ Explicit representation of commonality among system
components
◦ System robustness
◦ Reusability of analysis, design, and programming
results

20
21
 OO vs. EER Data Modeling
 Object Oriented EER
Class Entity type
Object Entity instance
Association Relationship
Inheritance of attributes Inheritance of attributes
Inheritance of behavior No representation of
behavior

Object-oriented modeling is frequently accomplished using the

Unified Modeling Language (UML)

22
Object
 An entity that has a well-defined role in
the application domain, as well as state,
behavior, and identity
◦ Tangible: person, place or thing
◦ Concept or Event: department, performance,
marriage, registration
◦ Artifact of the Design Process: user interface,
controller, scheduler
Objects exhibit BEHAVIOR as well as attributes
 Different from entities

23
State, Behavior, Identity
 State: attribute types and values
 Behavior: how an object acts and reacts
◦ Behavior is expressed through operations that
can be performed on it
 Identity: every object has a unique identity,
even if all of its attribute values are the
same

24
Class diagram shows the static structure of an object-oriented
model: object classes, internal structure, relationships.

25
Object diagram shows instances that are compatible with a
given class diagram.

26
Operations
 A function or service that is provided by
all instances of a class
 Types of operations:
◦ Constructor: creates a new instance of a class
◦ Query: accesses the state of an object but
does not alter its state
◦ Update: alters the state of an object
◦ Scope: operation applying to the class instead
of an instance
Operations implement the object’s behavior
27
Associations
 Association:
◦ Relationship among object classes
 Association Role:
◦ Role of an object in an association
◦ The end of an association where it connects
to a class
 Multiplicity:
◦ How many objects participate in an
association. Lower-bound..Upper bound
(cardinality)

28
Figure 14-3:
Association relationships of different degrees

Lower-bound – upper-bound

Represented as:
0..1, 0..*, 1..1, 1..*

Similar to
minimum/maximum
cardinality rules in EER

29
 Alternative multiplicity
representation: specifying the
two possible values in a list
instead of a range

30
31
 Figure 14-5:
Object diagram
for customer
order example

32
Association Class
 An association that has attributes or
operations of its own or that participates
in relationships with other classes

 Like an associative entity in ER model

33
 Binary association
class with behavior

Unary association with

only attributes and no
behavior

34
Figure 14-6a: Association class and link object
Object diagram showing link objects

Association class
instances

35
Figure 14-7: Ternary relationship with association class

36
 Figure 14-8: Derived attribute, association, and role

Constraint expression for derived attribute

Derived attribute

Derived relationship (from Registers-for and Scheduled-for)

Derived attributes and relationships shown with / in front of the name

37
Generalization/Specialization
 Subclass, superclass
◦ similar to subtype/supertype in EER
 Common attributes, relationships, AND
operations
 Disjoint vs. Overlapping
 Complete (total specialization) vs.
incomplete (partial specialization)
 Abstract Class: no direct instances possible,
but subclasses may have direct instances
 Concrete Class: direct instances possible

38
Figure 14-9a: Examples of generalization, inheritance, and constraints
Employee superclass with three subclasses

An employee can
only be one of
Shared attributes these subclasses
and operations An employee
may be none
of them.

Specialized attributes and operations

39
Figure 14-9b: Examples of generalization, inheritance, and constraints
Abstract patient class with two concrete subclasses

Abstract indicated by italics

A patient MUST be
EXACTLY one of
the subtypes
Dynamic means a patient can change
from one subclass to another over time

40
Class-Scope Attribute
 Specifies a value common to an entire
class, rather than a specific value for an
instance.

 Represented by underlining

 “=“ is initial, default value.

41
Polymorphism
 Abstract Operation: Defines the form or
protocol of the operation, but not its
implementation
 Method: The implementation of an
operation
 Polymorphism: The same operation may
apply to two or more different classes in
different ways

42
Figure 14-11: Polymorphism, abstract operation, class-
scope attribute, and ordering

This operation is abstract…it has

no method at Student level

Class-scope attributes –
only one value common
to all instances of these
classes
Methods are defined at subclass level

43
Overriding Inheritance
 Overriding: The process of replacing a
method inherited from a superclass by a
more specific implementation of that
method in a subclass
◦ For Extension: add code
◦ For Restriction: limit the method
◦ For Optimization: improve code by exploiting
restrictions imposed by the subclass

44
 Figure 14-12: Overriding inheritance

Subclasses that
do not
override place-
student use the
default
behavior

Restrict job placement

45
Multiple Inheritance
 Multiple Classification: An object is an
instance of more than one class

 Multiple Inheritance: A class inherits

features from more than one superclass

46
 Figure 14-13
Multiple inheritance

47
Aggregation
 Aggregation: A part-of relationship between
a component object and an aggregate object

 Composition: A stronger form of aggregation

in which a part object belongs to only one
whole object and exists only as part of the
whole object

 Recursive Aggregation: Composition where

component object is an instance of the same
class as the aggregate object

48
 Figure 14-14: Example aggregation

A Personal Computer includes CPU, Hard Disk, Monitor, and

Keyboard as parts. But, these parts can exist without being installed
into a computer. The open diamond indicates aggregation, but not
composition

49
Figure 14-15: Aggregation and Composition

(a) Class diagram

Closed diamond indicates
composition. The room cannot
exist without the building

(b) Object diagram

50
Figure 14-16: Recursive aggregation

51
Unified Modeling Language
 A regular class is represented by a
rectangle, divided into the three parts you
have seen before (name, attributes,
methods)
 An aggregate class is represented by a
rectangle containing its name and the
rectangles of the classes whose objects it
aggregates. The product and source
classes are within their aggregate classes,
AllProducts and AllSources respetively
 Associations are shown with lines with
plain ends. The cardinality of a relationship
is expressed as n, n..n, or n..*
 Inheritance is shown by a line with an
open arrow pointing toward the base
class.
 Association classes are connected to the
relationship to which they apply with a
dashed line.
 An at