|


|

  

George Klington.A
 |

|

j |
ect
j An o
ect represents a real world entity (Person), a concept
(Drama), a logical thing (Licence), a physical thing (Car)
j Every o
ect has a unique |
ect Identifier (|ID)

j An o
ect is made of two things:

j State: properties (e.g. name, address, irthDate of a Person)

j Behaviour: operations (e.g. age of a Person is computed from

irthDate and current date)
j |
ect Identifier
j Unique for every o
ect

j System generated

j Never changes in the lifetime of the o
ect

j Not usually visi le to the user

 ||


j Classification
j Classification is the process of grouping together objects which have
common features.
j Programming languages have type systems and database systems
have data models to classify object.
j The name used for the classificatory group of values is usually either
class or type
type..
class Person
properties
name: String
address: String
birthDate: Date
operations
age(): Integer
end Person
 ||

j Encapsulation
j The integration of the description of data structure and operation
is called ?
 .
j |
ects are composed of properties (values) and operations.
j This feature is missing in Relational Data ases (RDBs) and is
usually coded into the application.
j Inheritance
j A new class is usually descri ed in terms of one or more
previously defined classes from which the new class takes (
(
?)

?)
properties and operations. For instance, the following defines a
new class  ? ::
¬



  
 Student j Person ¬  

 


 ¬ 

   


ma
or: String  


¬ 


 

tutor: Lecturer

  

register(C: Course): Boolean
 Student
 ]

|

|
   
j |
ect |riented Data ases (||DBs) are inevita le when:
j Data is complex and varia le in size

j Complex structural and compositional relationships

j Data is highly inter-

inter-related
j Data is evolving rapidly over time

j Richer data types

j complex o
ects

j inheritance

j user extensi ility

j Behaviour with data

j not
ust a  model ut also

j operations can e undled together with data

 ||
 
j Standard || characteristics
j E.g. encapsulation, types, classes, polymorphism, etc..

j DBMS characteristics
j Persistence
j Scala le
j Concurrency
j Fault tolerance
j Simple query support
 ||


j An ?
? or ?

?
? ? is one which supports the
modeling of data as a stract entities, with o
ect identity.

j An ?

?
 ? ? ? is an o
ect system in which all data is
created as instances of classes which take part in an inheritance
hierarchy.

j An ?

?
 ? ?  ? ?? ? (||DBMS) is a
DBMS with an o
ect-
ect-oriented logical data model.

j An ?

?
 ? ?  ? is a data ase made up of o
ects and
managed y an ||DBMS.
 Ý

||
  
 
j UML can e used to aid in || Data ase
Design
j Use Case Diagrams
j Class Diagrams

j Sequence Diagrams

j State Diagrams
 



j RDBMSs ² two level storage model
j Application storage model in main & virtual memory
j Data ase storage model on disk

Main Memory

Transformation Secondary Storage

 



j ||DBMS uses single level storage concept

Main Memory

Secondary Storage
 



j Resident |
ect Ta le (R|T)
j Easy implementation, potentially inefficient

j Pointer Swizzling
j More complex, more efficient
|



  



j Advantages
j Reuse
j Sharing

j Disadvantages
j Complexity
j Costs


|| 




 


 


j Student and Lecturer are su -types of


Person. ¶d· means that Student and
Person. „

Lecturer are dis
oint
dis
oint..
j A Student cannot e a Lecturer at the 
same time and vice versa.
versa.
j Attri ute names are omitted.
 
  



 

   
 



 


   
 
 
 
  
 



 
 " 

 

Ý
Person
name: string
address: string
birthDate: date

age(): integer

Student
tutor tutees Lecturer Department
major: string
* 1
room: string worksFor staff deptId: string
register(C: Course): boolean salary: float
enrolledOn * 1 name: string
takeUnit(U: Unit): boolean joinDate: date
*
teachUnit(U: Unit): bollean getCourses(): Set(Course)
takes *

offers 1

takenBy *
students Course
Unit
1
courseCode: string dept
unitCode: string
description: string partOf units name: string
*
* *
getCourses(): Set(Course) getUnits(): Set(Unit)
 ||
 
Vl

„erson Vl

Lecturer j
„erson Vl Course
!r! rti
!r! rti
!r ! rti

name: String room: Integer name: String
address: String tutees: set(Student)
offeredBy: Department
worksFor: Department
birthDate: Date hasStudents: set(Student)
teaches: set(Unit)
! r ti
hasUnits: set(Unit)
! r ti

age(): Integer teachUnit(U: Unit): Boolean  Course
 „erson  Lecturer

Vl

Student j
„erson Vl

Department Vl

Unit

!r ! rti
!r! rti
!r! rti

major: String name: String name: String
tutor: Lecturer staff: set(Lecturer) code: String
enrolledOn: Course takenBy: set(Student)
offers: set(Course)
takes: set(Unit)
 Department taughtBy: set(Lecturer)
! r ti

partOf: set(Course)
register(C: Course): Boolean
 Unit
takeUnit(U: Unit): Boolean
 Student
 —dvantages of OODB
‡ Greater semantic expressibility: storing and manipulating complex
objects greatly simplifies the model of the application world

‡ Object identity is superior unifying concept than using surrogates

(e.g. primary and foreign keys in relational DBMS)

‡ The ease of user extensibility

‡ Behavioural model: programs and data are stored together,

unifying conceptually connected features of database

‡ Typing objects provides a more coherent structure for the

database

‡ Code re-use through inheritance, over-riding and late binding

‡ — possible pre-requisite to active databases and interoperability?

 Disadvantages of OODB

‡ No formal semantics, unlike the relational data model.

‡ Loss of the relational data model¶s simplicity.

‡ Optimization / tuning(e.g. indexes) not as well understood and

are difficult; the overall record-at-a-time flavour of the OO
systems means that relational-style optimization is unlikely.

‡ Transaction management support is not very mature.

‡ Complexity

‡ Cost
" !
"|Ý
###