Object Oriented Databases

Software Engineering Department

 Lecture outline
 Object-Oriented concepts
 Objects, Classes
 Attributes, Operations, Associations
 Encapsulation, Inheritance
 Unified Modelling Language
 Object-Oriented Data Modelling
 Identifying
 Classes, attributes, and operations.
 Associations among classes
 Drawing class diagrams
 Normalization
 Introduction to ODMG 3.0 (the standard for Object-Oriented
Databases)

2
Object-oriented databases
Avoid object-relational impedance mismatch

Provide a uniform data model

Combine features and properties of object-oriented

systems and languages
 Object-oriented concepts
Objects
Objects represent real world entities,
concepts, and tangible as well as
intangible things.
For example a person, a drama, a licence
Every object has a unique identifier (OID).
A memory address
System generated
Never changes in the lifetime of the object

5
 Object-oriented concepts
Objects
 An object is made of two things:
 State: attributes (name, address, birthDate of a person)
 Behaviour: operations (age of a person is computed from
birthDate and current date)
 Objects are categorized by their type or class.
 An object is an instance of a type or class.

7
Object-oriented concepts
Sharing of objects through references

Two objects are identical if they have the same OID

Two objects are equal if they have the same state

 Object-oriented concepts …
Classification
 Classification is the process of grouping together objects
which have common features.
 Programming languages have type systems and database
systems have data models to classify object.
 The name used for the classificatory group of values is
usually called class.

Class
 Provides a template for constructing objects.
 Instances of a class have the same kind of data and
identical behaviour.

9
 Object-oriented concepts …
An Example of a class in UML

Person Class Name

name: {firstName: string,

middleName: string, Attributes
lastName: string}
address: string
birthDate: date

age(): Integer
Operations
changeAddress(newAdd: string)

p:Person A Person object

name: {Norman, William, Preston}

address: Stockport
birthDate: 11-JUN-70
10
 Object-oriented concepts …

Encapsulation
Merger of data structure and
operations.
Objects are composed of
attributes (values) and operations
(behaviour).

11
 Object-oriented concepts …
Inheritance
A class can be defined
in terms of another one.
Person is super-class
and Student is sub-class.
Student class inherits
attributes
and operations of Person.
12
Person
name: {firstName: string,
middleName: string,
lastName: string}
address: string
birthDate: date
age(): Integer
changeAddress(newAdd: string)
Student
regNum: string {PK}
major: string
register(C: Course): boolean
 Why ODBs?
 ODBs are inevitable when:
 Data is complex and variable in size
 Complex structural and compositional relationships
 Data is highly inter-related
 Data is evolving rapidly over time
 Richer data types
 complex objects
 inheritance
 user extensibility
 Behaviour with data
 not just a data model but also
 operations can be bundled together with data

13
 Comparison – continued…
 RDBs vs. ODBs.
 Not very easy to compare because of
philosophical differences.
 RDBs have only one construct i.e.
Relation, whereas the type system of
ODBs is much richer and complex.
 RDBs require primary keys and foreign
keys for implementing relationships, ODBs
simply don’t.

14
 Comparison – continued…
 RDBs vs. ODBs.
 ODBs support complex data whereas
RDBs don’t.
 ODBs support wide range of applications.
 ODBs are much faster than RDBs but are
less mature to handle large volumes of
data.
 There is more acceptance and domination
of RDBs in the market than that for ODBs.

15
UML
 Defining Class
A CLASS is a template (specification, blueprint)
for a collection of objects that share a common
set of attributes and operations.

HealthClubMember
attributes
Class operations

Objects
 Relationships
A RELATIONSHIP is what a class or an object
knows about another class or object.

 Generalization (Class-to-Class) (Superclass/Subclass)

• Inheritance
• Ex: Person - FacultyPerson, StudentPerson, Staff...
• Ex: ModesOfTravel - Airplane, Train, Auto, Cycle, Boat...
 [Object] Associations
• FacultyInformation - CourseInformation
• StudentInformation - CourseInformation
 [Object] Aggregations & Composition (Whole-Part)
• Assembly - Parts
• Group - Members
• Container - Contents
UML Class Diagram Notation

Class

{
Member
memberNumber
firstName Expanded view of a
lastName Class into its three
attributes telephone
address sections:
city
Top: Class Name
etc...

{
Middle: attributes
checkOutVideo
operations checkInVideo Bottom: operations
buyItem
etc...
Generalization Relationships

Person
A generalization connects a subclass
to its superclass. It denotes an
inheritance of attributes and behavior
from the superclass to the subclass and
indicates a specialization in the subclass
of the more general superclass.

Student
Generalization Relationships (Cont’d)
UML permits a class to inherit from multiple superclasses, although
some programming languages (e.g., Java) do not permit multiple
inheritance.

Student Employee

TeachingAssistant
 Generalization (Class-to-Class) 22

(superclass – subclass; supertype – subtype)

 A Generalization follows a “is a” or “is a kind of” heuristic from a

specialization class to the generalization class. (e.g., student “is a”
person, video “is a kind of” inventory).
 Common attributes, operations and relationships are located in the
generalization class and are inherited by the specialization classes
 Unique attributes, operations and relationships are located in the
specialization classes.
 23
Generalization Example
Others:
•Transactions
<<abstract>> •Things
Role • Places
attributes • Etc...
operations

Faculty Student Staff Visitor

attributes attributes attributes attributes

operations operations operations operations

Note: <<abstract>> = no objects

 24
Poor Generalization Example
(violates the “is a” or “is a kind of” heuristic)

Person
attributes
operations

Arm Leg Head

attributes attributes attributes

operations operations operations

Associations
25

 Relationships between instances

(objects) of classes
 Conceptual:
• associations can have two roles (bi-directional):
– source --> target
– target --> source
• roles have multiplicity (e.g., cardinality, constraints)
• To restrict navigation to one direction only, an
arrowhead is used to indicate the navigation direction
 No inheritance as in generalizations
 Multiplicity of Associations
Multiplicity: refers to how many objects of one class can relate
to each object of another class.

Symbols used to indicate multiplicity in associations:

Exactly one
Class 1..* One or more
Class
Class * Zero or more

0..1 Optional (0 or 1)
Class
Association Relationships

If two classes in a model need to

communicate with each other, there must
be link between them.

An association denotes that link.

Student Instructor

Software Design (UML)

Association Relationships (Cont’d)
We can indicate the multiplicity of an association by adding
multiplicity adornments to the line denoting the association.

The example indicates that a Student has one or more Instructors:

Student Instructor
1..*

Software Design (UML)

Association Relationships (Cont’d)

The example indicates that every Instructor has one or more

Students:

Student Instructor
1..*

Software Design (UML)

Association Relationships (Cont’d)
We can also indicate the behavior of an object in an association
(i.e., the role of an object) using rolenames.

teaches learns from

Student Instructor
1..* 1..*

Software Design (UML)

Association Relationships (Cont’d)
We can also name the association.

membership
Student Team
1..* 1..*

Software Design (UML)

Association Relationships (Cont’d)
We can specify dual associations.

member of

1..* 1..*
Student Team

1 president of 1..*
Association Relationships (Cont’d)
We can constrain the association relationship by defining the
navigability of the association. Here, a Router object requests
services from a DNS object by sending messages to (invoking the
operations of) the server. The direction of the association indicates
that the server has no knowledge of the Router.

Router DomainNameServer
Association Relationships (Cont’d)
Associations can also be objects themselves, called link classes or
an association classes.

Registration

modelNumber
serialNumber
warrentyCode

Product Warranty
Association Relationships (Cont’d)

A class can have a self association.

nex
t
LinkedListNode
previou
s

Software Design (UML)

Association Relationships (Cont’d)
We can model objects that contain other objects by way of special
associations called aggregations and compositions.

An aggregation specifies a whole-part relationship between an

aggregate (a whole) and a constituent part, where the part can
exist independently from the aggregate. Aggregations are
denoted by a hollow-diamond adornment on the association.

Engine
Car
Transmission

Software Design (UML)

Association Relationships (Cont’d)
A composition indicates a strong ownership and coincident lifetime
of parts by the whole (i.e., they live and die as a whole).
Compositions are denoted by a filled-diamond adornment on the
association.

Scrollbar
1 1

Window Titlebar
1 1

Menu
1 1 ..
*

Software Design (UML)

 Video Store – UML Class Diagram
38
1 1
Inventory

SaleItem RentalItem

Video Game ConcessionItem VCR

0..*
Transaction 0..* Employee StoreLocation
1 1

SaleTransaction RentalTransaction Suplier

1 0..* 0..* 1 1
0..1 1 0..*
Member PurchaseOrder
1..* 1..* 1
SaleRentalLineItem 1..*
0..* 0..*
PurchaseOrderLineItem