ODB – Object DataBases

FEN 09-09-2007 NOEA/IT - Databases/ODB 1

ODB – Object DataBases

Object-Oriented – Fundamental Concepts

UML and EE/R

OO and Relational Databases

Introduction to ODB

Chap. 20


Object-Orientation

Aims:To develop modifiable software which is robust in relation to:

• Changes in physical data representation (”the Y2K-problem”)

• Changes in functional requirements

Means:– Modularity bases on logical data structure:

• data at some appropriate conceptual level is much more stable over time than functionality.

– Data abstraction:• data are described as classes – that is in term of the logical

behaviour of their operations, and not by their internal representation


• Means (cont…)– Inheritance and polymorphism:

• Classes may be defined as extensions/specialisations of existing classes (reuse)

• New features may be added in the subclass• Inherited features may be redefined in the subclass• Dynamic binding (run-time) determines which specialised

version of a given feature is to be applied (which class does the object actually belongs to)


Example – RecallMiniBank

• The company MiniBank stores information about clients and accounts

• About a client name, address, cprno (unique) and status (A= special clients, B= standard clients or C= problem clients) are stored.

• About accounts accountno (unique), balance and interest rate are stored.

• An account is always associated with exactly one client, a client may be associated with none or more accounts.


MiniBank – the OO-way

Minibank:Find classes:

Problem specific classes ClientAccount

Library classes: AddressCPRClassAccNoClassList<Type>


MiniBank – the OO-wayLibrary classes – designed, implemented and tested once and for all:(In #C/Java++ something)

class CPRClass {private: <<internal representation>>public:

setCpr(-)//checking modulus 11string getCprAsString();int getAge();----//and many more operations on CPR numbers

}

Similar for Address and AccNoClass.List<Type> is a generic Collection from the standard library of the programming language.



Find structure:

Client Account1..1 0..n

As an alternative to the status attribute in Client,it may be specialised using inheritance



Define problem specific classes:

class Account{private:

float balance;float inRate;

public:float getAvailable(){return balance;}void addInterestRate(){balance = balance +

foo();}//other operations

}


MiniBank – the OO-wayclass Client{

private: CPRClass cpr; //other attributtes list<Account> clientAccounts; //clients holds a

//list of his accounts

public: setClient(CPRClass clCpr,,,) {.. cpr.setCpr(clCpr);..} float getEngagement(){ float sum=0; for(int i=0;i<clientAccounts.len();i++) sum=sum+clientAccount[i].getAvailable(); return sum;}//other operations

}



• Now MiniBank wants to offer a new type of account to its clients: A BudgetAccount which as an agreed limit

• This class may be defined as a specialisation of the existing Account using inheritance:– A new attribute lendingRate is added (the interest rate when the

balance is negative)– Also an attribute limit is added (the limit that is agreed)– The operations addInterestRate redefined so interest rates are

added according to the balance of the accaount– The operation getAvailable is redefined so balance+limit is

returned• Polymorphism allows objects of type BudgetAccount to be stored in

the clientAccounts-list of a Client-object



Client Account1..1 0..n

BudgetAccount



class BudgetAccount: Account{private:

float lendIR;float limi;

public:float getAvailable(){return balance +

limit;}void addInterestRate(){

balance= balance + fooNew();}//other operations

}

Note: No changes in Client!!!


MiniBank – the OO-wayclass Client{

private: CPRClass cpr; //other attributtes list<Account> clientAccounts; //clients holds a

//list of his accounts

public: setClient(CPRClass clCpr,,,) {.. cpr.setCpr(clCpr);..} float getEngagement(){ float sum=0; for(int i=0;i<clientAccounts.len();i++) sum=sum+clientAccount[i].getAvailable(); return sum;}//other operations

}

Due to polymorphism

subtypes of Account may

be stored here

Dynamic binding assures that the right version of getAvailable() is called


UML: Unified Modelling Language

• Fig 3-15

ER model:Many

similarities with UML

Class Diagrams


• Fig 3-16

UML Class Diagram:

Many similarities with ER models


Specialisation in EER


• Fig 4-10

Specialisation in UML


Comparing: OO and RDB - a conflict?

• OO:– data is described abstractly and represented as encapsulated

objects– a model of arbitrary complex data structures are created –

structure may be composite and repeating and may change dynamically

– Changes in functional requirements are met by inheritance and polymorphism

– OO-code is a good model of the domain• RDB:

– data is describes as simple atomic values in rows in tables– no encapsulation, data abstraction, inheritance or polymorphism– normalisation leads spreading related data over many different

tables and hence a more poor model of the domain


Transformation is needed when using RDBMS


Or in a picture…


Two trends• Object Databases (“pure ODBs”)

– ObjectStore– O2– FastObjects (Versant FastObjects .NET )

• ORDB: Extensions to SQL and RDBMSs in order to support OO-concepts:– SQL3 (SQL-99)– Oracle8 (and higher)– Informix Universal Server (now IBM)

– IBM DB2 Universal Database


Object-oriented DBMSs

– Extensions or APIs (libraries) to OOPLs– Still immature– Mostly used in applications with relatively few

instances of large complex objects (as CAD/CAM, case tools, IDEs etc.)


Object-oriented DBMSs

• OO systems are characterised by objects interacting in doing the job.• This includes:

– Object identity (every object has a unique identity)

– Object state (attribute values)

– Features (functions/methods that can be applied to the object – the class)

– Structure• Specialisation/Generalisation (inheritance).• Aggregation (objects may be composed of other objects – have attributes that

refer to other objects including collections of other objects)• Association (objects refers to each other dynamically.

OODBMS Must store all above.


OODB – object identity (OID)• OO systems are based upon object references (conceptual

pointers, memory locations)• Object identity (OID):

– OIDs are persistent pointers– OIDs are assigned to objects on creation– OIDs are immutable, that is are never changed and are not reused– OIDs are transparent to the user and managed by the DBMS– OIDs are not primary keys!

• Primary keys may be found in the domain and• Primary keys may have semantics• Primary keys are local to a table (class/relation) – OIDs are global to the

system• OIDs are simple, atomic values, primary keys may be composite


Object Structure

• Any object may be represented by a triple: – (i, c, v), where

• i is the OID of the object

– c is the type constructor of the object– v is the state (or the current value) of the object


Type Constructors• atom

– simple value (primitive data type)• tuple

– <a1:i1, a2:i2,…,an:in>, where each a is an attribute name and each i is an OID

• collection type– Some collection of OIDs– Collections may be:

• set• list• bag• array


Example• Fig 20-2


Features (operations)


Persistent Objects


Inheritance

• In OOPL: type perspective

• In ODB: inheritance are also to be viewed as an constraint on the extension of a class:– Any object belonging to the extension of

subtype must also belong to the extension of the super type

• Multiple and selective inheritance

Extension of class. What is

that?

ODB – Object DataBases

Documents

Transcript of ODB – Object DataBases