DISTRIBUTED DATABASE ANDOBJECT ORIENTED DATABASES UNIT- IV.doc

8/14/2019 DISTRIBUTED DATABASE ANDOBJECT ORIENTED DATABASES UNIT- IV.doc

1/42

1

UNIT- IV

DISTRIBUTED DATABASE ANDOBJECT ORIENTED DATABASES

Concepts of distributed databases and design

DISTRIBUTED DATABASE DESIN

Structure

Ob!ecti"es#

In this unit you will come to know the different design aspects of distributed databases. At the

end of this unit you will be able to describe the topics like

A framework for distributed database design

The objectives of design of data distribution

Top Down and ottom !p design approaches

The design of database fragmentation

"ori#ontal $ragmentation

%ertical $ragmentation

&i'ed $ragmentation

The allocation of fragments

(eneral )riteria for $ragment allocation

Introduction#

The concept of data distribution itself is difficult to design and implement because of various

technical and organi#ational issues. *o we need to have an efficient design methodology. $rom

the technical aspect+ the interconnection of sites and appropriate distribution of the data and

applications to the sites depending upon the re,uirement of applications and for optimi#ing

performances. $rom the organi#ational point+ the issue of decentrali#ation is crucial and

distributing an application has a greater effect on the organi#ation. In recent years+ lot of research

work has taken place in this area and the major outcome of this are-

o Design criteria for effective data distribution


2/42

o &athematical background of the design aids

In the section /. you will learn a framework of the design including the design approaches like

Top Down and ottom !p. The section /.0 e'plains about the design of "ori#ontal and

%ertical $ragmentation. In the section /. we will give principles and concepts in $ragment

allocation.

A $ra%e&or' for Distributed Database Design# The design of a centrali#ed database

concentrates on-

Designing the conceptual schema that describes the complete database

Designing the 2hysical database+ which maps the conceptual schema to the storage areas

and determines the appropriate access methods.

The above two steps contributes in distributed database towards the design of (oba( sc)e%a

and t)e design of (oca( databases*The added steps are-

Designing t)e $rag%entation- 3 The actual procedure of dividing the e'isting global

relations into hori#ontal+ vertical or mi'ed fragments

Designing t)e a((ocation of frag%ents- 3Allocation of different fragments according to

the site re,uirements

efore designing the Distributed database a thorough knowledge about the application is a must.

In this case we e'pect the following things from the designer.

*ite of 4rigin- The site from which the application is issued.

The fre,uency of invoking the re,uest at each site

The number+ type and the statistical distribution of accesses made by each

application to each re,uired data.

In the coming section let us try to know the actual need of design of data distribution.

Ob!ecti"es of t)e Design of Data Distribution#In the design of data distribution the following objectives should be considered.

+rocessing (oca(it,# 5educing the remote references in turn ma'imi#ing the local

references is the primary aim of the data distribution. This can be achieved by having

redundant fragment allocation meeting the site re,uirements. Co%p(ete (oca(it, is an

e'tended idea+ which simplifies the e'ecution of application.


3/42

0

A"ai(abi(it, and re(iabi(it, of distributed data# Availability is achieved by having

multiple copies of the data for read only applications. 5eliability is achieved by storing

the multiple copies of the information+ as it will be helpful in case of system crashes.

or'(oad distribution#workload distribution is the major goal to have high degree of

parallelism.

Storage costs and +rocessing (oca(it,# )ost criteria and Availability of storage areas

should be intelligently handled for effective data distribution.

!sing the all above criteria may increase the design comple'ity. *o important aspects are taken

as objectives depending upon the re,uirement and others are treated as constraints. In the ne't

section let us design a simple approach for ma'imi#ing the processing locality

Top . Do&n and Botto% . Up Approac) .A c(assica( Design /et)odo(ogies#

There are two classical approaches as far as distributed databases design is concerned. They are-

1. Top . Do&n Approac)#This may be ,uite useful when the system has to be designed

from the scratch. "ere we follow the following steps-

Design of (lobal *chema.

Design of $ragmentation *chema.

Design of Allocation *chema.

Design of 6ocal *chema 7Design of 82hysical Databases9:.

. Botto% - Up Approac)# This can be used for an e'isting system. This approach is

based on the integration of e'isting schemata into a single+ global schema. ut re,uires

that the following aspects have to be fulfilled.

The selection of a common database model for describing the (lobal schema of

the database.

The translation of each local schema into the common data model.

The Integration of common schemata into a common (lobal schema. i.e the

merging of common data definitions and the resolution of conflicts among

different representations given to the same data.

The ottom !p design re,uire solving these three problems. Then of course the design

steps are just reverse of the previous method.


4/42

T)e Design of Database $rag%entation#

"ere we discuss the design of non3overlapping fragments+ which are the logical units of

allocation. That is+ it is important to have an efficient design methodology so that we can

overcome the related problems of allocation. In the following+ we e'plain the design of

"ori#ontal+ %ertical and &i'ed $ragmentations.

0ori1onta( $rag%entation#

"ere we discuss two important methods called 2rimary and Derived. Determining the hori#ontal

fragmentation involves knowing-

The logical properties of the data such as fragmentation predicates.

The statistical properties of the data such as the number of references of applications to

the fragments.

+ri%ar, $rag%entation#

The correctness of 2rimary fragmentation re,uires that each global relation be selected in one

and only one fragment. Thus+ determining the primary hori#ontal fragmentation of a global

relation re,uires determining a set of disjoint and complete selection predicates 7we shall define

this later in this section:. The property we e'pect from each fragment is that the elements of them

must be referenced homogeneously by all applications.

6et ( be the global relation for which we want to produce a hori#ontal

primary fragmentation. 6et us define some terminologies.

A Si%p(e +redicate# is a predicate of the type-

Attribute ; value

A /in-ter% +redicate , fora set 2 of simple predicates is the conjunction of all

predicates appearing in 2+ either taken in natural form or negated. Thus-

, 2 pi 3

pi p

4T pi: and y false

A frag%ent is the set of all tuples for which a min3term predicate holds.

A simple predicate is re(e"ant respect to a set 2 of simple predicates if there

e'ists at least two min3term predicates of 2 whose e'pression differs only in the


5/42


6/42


7/42

Q

2/- A5?A ; 8*4!T"9

If we assume that in the northern area the departments with D?2T>!& E F will never

be there+ then A5?A ; 8>45T"9 implies that D?2T>!& E F is false. Thus the fragments

are reduced to the following four-

1- D?2T>!& P ; 1F

- 71F P D?2T>!& P ; F: A>D 7A5?A ; 8>45T"9 :

0- 71F P D?2T>!& P ; F: A>D 7A5?A ; 8*4!T"9 :

- D?2T>!& E F

If we now concentrate about the fragment allocation we can easily allocate fragments

corresponding to y1 and y at sites 1 and 0.ut depending upon the re,uirement fragments y

and y0 will be allocated to either sites 1 or 0.

Deri"ed 0ori1onta( $rag%entation#

This is not based on the properties of its own attributes+ but it is derived from the hori#ontal

fragmentation of another relation. It is used to make the join between the fragments. A

distributed !oinis a join between hori#ontally fragmented relations. That is when you want to

join the two relations ( and " you have to compare their fragments. Join rap)scan efficiently

represent it. The fig /.1 represents the different possible join graphs.

o Tota(# The join graph is total when it contains all possible edges between

fragments of ( and ".o Reduced#The join graph is reduced when some of the edges between ( and "

are missing. "ere we have two types-

+artitioned#A reduced graph is partitioned if the graph is composed of

two or more sub graphs without edge between them.

Si%p(e#A reduced graph is simple if it is partitioned and each sub graph

has just one edge.

E4a%p(e#)onsider the relation *!226 7*>!&+ 2>!&+ D?2T>!&+ K!A>:. 6et us take

the following case. *ome application

o 5e,uires the information about supplies of given suppliersO thus they join between

*!226 and *!226I?5 in the *>!& attribute.

o 5e,uires the information about supplies at a given departmentO then they perform

join between *!226 and D?2T on the D?2T>!& attribute.


8/42

R

6et us assume that the relation D?2T is hori#ontally fragmented on the attribute D?2T>!& and

that *!226I?5 is hori#ontally fragmented on the attribute *>!&. The derived hori#ontal

fragmentation can be obtained for relation *!226 by either performing a *emi 3 join operation

with *!226I?5 on *>!& or with D?2T on D?2T>!&O both of them are correct.

Vertica( $rag%entation#

This re,uires grouping the attributes into sets+ which are referenced in the similar manner by

applications. This method has been discussed by considering two separate types of problems-

T)e Vertica( +artitioning +rob(e%# "ere set must be disjoint. 4f course one

attribute must be common. $or e'ample assume that a relation * is vertically

fragmented using this concept into *1 and *.This can be useful where an

application can be e'ecuted using either *1 or *.4therwise having the complete

* at a particular site may be a unnecessary burden.

T&o possib(e design approac)es#

1. T)e sp(it approac)# The global relations are progressively split

into fragments

. T)e rouping approac)# The attributes are progressively

aggregated to constitute fragments.

oth are "euristic approaches as each iteration steps look for best choice. In

both the cases formulas are used to indicate the best possible

splitting or grouping.

The different possible join graphs

*

*

*

1

*

*

1

*

1

5

5

0

5

5

1

51

5

50

5

*1

*

*0

51

5

50

5

*

0


9/42

M

T)e Vertica( C(ustering +rob(e%# "ere sets can overlap. "ere depending upon

the re,uirement you may have more than one common attribute in the two

different fragments of a global relation. It introduces Rep(ication within

fragments+ as some common attributes are present in the fragments. E4a%p(e#

)onsider the global relation ?&26 7?&2>!&+ >A&?+ *A6+ TAJ+

&(5>!&+ D?2T>!&:. The following are made-

Administrative applications+ re,uires >A&?+ *A6+ TAJ of employees.

The department+ re,uires >A&?+ &(5>!& and D?2T>!&

"ere %ertical clustering is suggested as the attribute >A&? is re,uired in both the fragments. *o

the fragments may be-

?&261 7?&2>!&+ >A&?+ *A6+ TAJ:

?&26 7?&2>!&+ >A&?+ &(5>!&+ D?2T>!&:

/i4ed $rag%entation#

The simple way for performing this is-

Apply "ori#ontal fragmentation to %ertical fragments

Apply %ertical fragmentation to "ori#ontal fragments

oth these aspects are illustrated using the following diagrams /. and /.0.

A1 A A0 A A/

%ertical fragmentations followed by hori#ontal fragmentation.

A1 A A0 A A/

%ertical fragmentations followed by hori#ontal fragmentation

T)e A((ocation of $rag%ents#

In this section we e'plain the different aspects to be considered when you go for allocating a

particular fragment to site. This section describes some general criteria that can be used for


10/42

1F

allocating fragments. There are two types of allocation methods+ which can be followed. They

are-

Non-redundant A((ocation#It is simple. A method known as 8est3fit approach9 can be usedO

i.e a measure is associated with each possible allocation+ and the site with the bets measure is

selected. It avoids placing a fragment at a given site where already a fragment is present which is

related to this fragment.

Redundant A((ocation# It is comple' design+ since-

o The degree of replication is a variable of the problem.

o The modeling of read applications is complicated as the applications may select

any of the several alternatives.

The following two methods can be used for determining the redundant allocation of

fragments-

Determine the set of all sites where the benefit of allocating one copy of

the fragment is higher than the cost+ and allocate a copy of the fragment to

each element of this siteO this method selects 8all beneficial sites9.

*tart from a non3replicated version. Then progressively introduce

replicated copies from the most beneficialO the process is terminated when

no additional replication is beneficial.

oth the reliability and availability of the system increases if there are two or three copies of the

fragment+ but further copies give a less than proportional increase.

), distributed databases:

*ome initial motivations-

S The development of computer networks promotes decentrali#ation.

S In a company+ the database organi#ation might reflect the organi#ational structure+ which is

distributed into units.

?ach unit maintains its own database.S *haring of data can be achieved by developing a distributed database system which-

S makes data accessible by all units

S stores data close to where it is most fre,uently used.

Distributed Database

A logically interrelated collection of shared data 7and a


11/42

11

description of this data:+ physically distributed over a

computer network.

Distributed DB/S 7DDB/S9

*oftware system that permits the management of the

distributed database and makes the distribution

transparent to users.

An e'ample of DD&*

DDB/S - c)aracteristics

S )ollection of logically3related shared data.

S Data split into fragments.

S $ragments may be replicated.

S $ragmentsreplicas allocated to sites.

S *ites linked by a communications network.

S Data at each site is under control of a D&*.

S D&*s handle local applications autonomously.

S ?ach D&* participates in at least one global

application.

OBJECTIVES O$ DISTRIBUTED DATABASE

o A major objective of distributed databases is to provide ease of access to data

for users at many different locations.


12/42

1

o The distributed database system must provide what is called location

transparency -3 a user 7or user program: using data need not know the location of the data.

o Ideally the user is unaware of the distribution of data+ and all data in the

network appear as single logical database stored at one site. In ideal case+ a single ,uery can

join data from tables in multiple sites as if the data were all in one site.

OBJECTIVE O$ DISTRIBUTED DATABASE

o A second objective of distributed database is local autonomy. This is the

capability to administer a local database and to operate independently when connection to

other nodes have failed.

o ?ach site has the ability to control local data+ administer security+ log

transactions+ recover when local failures occur ad provide full access to local data to local

users when any central or coordinating site cannot operate.

o There is no reliance on central site.

+ara((e( DB/S

&ain architectures for parallel D&*s are-

S *hared memory+

S *hared disk+

S *hared nothing.

Ad"antages of DDB/Ss

S 5eflects 4rgani#ational *tructure

S Improved *haring and 6ocal Autonomy

S Improved Availability

A failure does not make the entire system inoperable

S Improved 5eliability

Data may be replicated

S Improved 2erformance

Data are local to the site of 8greatest demand9

S ?conomics

&any small computers cost less than a big oneU


13/42

10

S &odular (rowth

easy to add new modules

Disad"antages of DDB/Ss

S )omple'ity

S )ost

?specially in system management

S *ecurity

network must be made secure

S Integrity )ontrol &ore Difficult

S 6ack of *tandards

S 6ack of ?'perience

S Database Design &ore )omple'

due to fragmentation+ allocation of fragments to a specific

site+ C..

STRUCTURE O$ DISTRIBUTED DATABASE

o A distributed database system consists of a collection of sites+ each of which

maintain a local database system.

o ?ach site is able to process local transactions+ those transactions that access

data only in a single site

o In addition a site may participate in the e'ecution of global transactions+ those

transaction that access data in several sites. The e'ecution of global transactions re,uires

communication along the sites.

STRUCTURE O$ T0E DISTRIBUTED DATABASES

o The sites in the system can be connected physically in a variety of ways.

o The major differences among these configurations involve-

Installation cost- The cost of physically linking the site

)ommunication )ost - 3 The cost in time and money from sending a

message from site A to site

5eliability - The fre,uency with which a link or site fails


14/42


15/42

1/

S $ragmentation schema and allocation schema.

S *et of schemas for each local D&* conforming to 03level A>*I*2A5) .

S *ome levels may be missing+ depending on levels of transparency supported.

Reference Arc)itecture for DDB/S

Reference Arc)itecture for DDB/S

S (lobal )onceptual *chema is the logical description of the D as if it were not distributed. It

contains definitions of entities+ relationships+ constraints+ security+ and integrity information.

S $ragmentation and Allocation *chemas describe how data are logically partitioned+ and where

they are located+ taking replication into account.

S 6ocal *chemas are the logical descriptions of the local Ds.


16/42

1G

Issues in Distributed Database Design

T)ree 'e, issues &e )a"e to consider#

S Data Allocation- where are data placedW Data should be stored at site with XoptimalX

distribution.

S $ragmentation- relation may be divided into a number of sub3relations 7called

fragments: + which are stored in different sites.

S 5eplication- copy of fragment may be maintained at several sites.

Definition and allocation of fragments carried out strategically to achieve-

S 6ocality of 5eference

S Improved 5eliability and Availability

S Improved 2erformance

S alanced *torage )apacities and )osts

S &inimal )ommunication )osts.

S Involves analysing most important transactions+

based on ,uantitative,ualitative information.

$rag%entation

S Kuantitative information may include-

S fre,uency with which a transaction is runO

S site from which a transaction is runO

S performance criteria for transactions.

S Kualitative information may include transactions that are

e'ecuted such as-

S type of access 7read or write:O

S predicates of read operations.

A relation 5 is divided into fragments r1+ r+ Crn+ which contain enough information to allow

reconstruction of 5

?'ample-


17/42

1Q


18/42

1R

S Derived.

S 4ther possibility is no fragmentation-

S If relation is small and not updated fre,uently+ may

be better not to fragment relation.

0ori1onta( and Vertica( $rag%entation

Two types of fragmentation-

S "ori#ontal

S %ertical

/i4ed $rag%entation


19/42

1M

0ori1onta( $rag%entation

S ?ach fragment consists of a subset of the tuples of a relation 5.

S Defined using *election operation of relational algebra-

p75:

S ?'ample-

5elation- *ells7pub+ address+price+type:

S $ragments-

Y *ellsitter; type ; 8bitter97*ells:

Y *ells6ager; type ; 8lager97*ells:

S This strategy is determined by looking at predicates used by transactions.

S Involves finding set of minimal 7complete and relevant: predicates.

S *et of predicates is complete+ if and only if+ any two tuples in same fragment are referenced

with same probability by any application.

S 2redicate is relevant if there is at least one application that accesses fragments differently.

Vertica( $rag%entation

S ?ach fragment consists of a subset of attributes of a relation 5.

S Defined using projection operation of relational algebra- a1+Can75:

S Determined by establishing affinity of one attribute to another.

S ?'ample-

S 5elation- ars7name+address+licence+employees+owner:

S $ragments-


20/42


21/42

1

characteristics.

"ow can we define fragments correctlyW

In defining fragments we have to be very careful.

Three correctness rules-

S )ompleteness

S 5econstruction

S Disjointness.

Correctness of $rag%entation

Co%p(eteness#If relation 5 is decomposed into fragments r1+ r+ Crn+ each data item that can

be

found in 5 must appear in at least one fragment. This ensures no loss of data during

fragmentation.

Recostruction#we must be able to reconstruct the entire 5

from fragments.

$or hori#ontal fragmentation is union operation.

5 ; r1 [r [C [rn+

$or vertical fragmentation is natural join operation.

5 ; r1 EP r EP C EP rn+To ensure reconstruction we have to include primary key attributes in all fragments.

Dis!ointness#if data item ' appears in fragment ri+ then it should not appear in any other

fragment.

E4ception#vertical fragmentation+ where primary key attributes must be repeated to allow

reconstruction.

$or hori#ontal fragmentation+ data item is a tuple

$or vertical fragmentation+ data item is an attribute.

Correctness of 0ori1onta( $rag%entation

5elation- *ells7pub+ address+price+type: type;Bitter+ 6ager

$ragments-

S *ellsitter; type ; 8bitter97*ells:


22/42

S *ells6ager; type ; 8lager97*ells:

Correctness ru(es

; Co%p(eteness- ?ach tuple in the relation appears either in

*ellsitter+ or in *ells6ager

; Reconstruction- The *ells relation can be reconstructed from

the fragments

*ells ; *ellsitter [*ells6ager

; Dis!ointness- The two fragments are disjoint+ there can be no

beer that is both 86ager9 and 8itter

Correctness of Vertica( $rag%entation

5elation- ars7name+address+licence+employees+owner:

$ragments-

S r1 ; name+address+licence 7ars:

S r ; name+address+employees+owner7ars:

Correctness ru(es

; Co%p(eteness- ?ach attribute in the ars relation appears either in

r1 or in r

; Reconstruction- The ars relation can be reconstructed from the

fragments

ars ; r1 EP r

; Dis!ointness- The two fragments are disjoint+ e'cept for the primary

key+ name+ which is necessary for reconstruction

Transparencies in a DDB/S

S Distribution Transparency

S Transaction Transparency

S 2erformance Transparency

S D&* Transparency

Distribution Transparenc,


23/42

0

The user has to perceive the DD as a single+ logical entity

S $ragmentation Transparency- the user does not need to

know that data is fragmented

S 6ocation Transparency- the user does not need to know

the location of data items

S 5eplication Transparency- the user is unaware of

relication of data.

S >aming transparency- items in a database must have a

uni,ue name+ but users donVt need to worry about it.

Na%ing Transparenc,

S ?ach item in a DD must have a uni,ue name.

S DD&* must ensure that no two sites create a

database object with same name.

*olution 1- create central name server.

Disadvantages-

S loss of some local autonomyO

S central site may become a bottleneckO

S low availabilityO if the central site fails+ remaining sitescannot create any new objects.

Transaction Transparenc,

S ?nsures that all distributed transactions maintain distributed databaseVs integrity and

consistency.

S Distributed transaction accesses data stored at more than one location.

S ?ach transaction is divided into number of subtransactions+ one for each site that has to be

accessed.

S DD&* must ensure the indivisibility of both the global transaction and each sub3transactions.

S &ust ensure both concurrency transparency+ and failure transparency

Concurrenc, Transparenc,


24/42

S All transactions must e'ecute independently and be logically consistent with results obtained if

transactions e'ecuted one at a time+ in some arbitrary serial order.

S *ame fundamental principles as for centralised D&*.

S DD&* must ensure both global and local transactions do not interfere with each other.

S *imilarly+ DD&* must ensure consistency of all subtransactions of global transaction.

S Techni,ues for concurrency control. !sually different from the ones for D&*.

S 5eplication makes concurrency more comple'.

S If a copy of a replicated data item is updated+ update must be propagated to all copies.

S )ould propagate changes as part of original transaction+ making it an atomic operation.

S "owever+ if one site holding copy is not reachable+ then transaction is delayed until site is

reachable.

S )ould limit update propagation to only those sites currently available. 5emaining sites updated

when they become available again.

S )ould allow updates to copies to happen asynchronously+ sometime after the original update.

Delay in regaining consistency may range from a few seconds to several hours.

$ai(ure Transparenc,

S DD&* must ensure atomicity and durability of global transaction.

S &eans ensuring that sub3transactions of global transaction either all commit or all abort.

S Thus+ DD&* must synchroni#e global transaction to ensure that all sub3transactions havecompleted successfully before recording a final )4&&IT for global transaction.

S &ust do this in presence of site and network failures.

+erfor%ance Transparenc,

DD&* must perform as if it were a centrali#ed D&*-

S DD&* should not suffer any performance degradation due to distributed architecture.

S DD&* should determine most cost3effective strategy to e'ecute a re,uest.

S Distributed Kuery 2rocessor 7DK2: maps data re,uest into ordered se,uence of operations on

local databases.

S It must consider fragmentation+ replication+ and allocation schemas.

S DK2 has to decide-

S which fragment to accessO

S which copy of a fragment to useO


25/42

/

S which location to use.

S DK2 produces e'ecution strategy optimi#ed with respect to some cost function.

S Typically+ costs associated with a distributed re,uest include-

S I4 costO

S )2! costO

S communication cost.

Date Ru(es for a DDB/S

$unda%enta( +rincip(e

To the user+ a distributed system should look e'actly like a non3distributed system.

1. 6ocal Autonomy

. >o 5eliance on a )entral *ite

0. )ontinuous 4peration

. 6ocation Independence

/. $ragmentation Independence

G. 5eplication Independence

$unda%enta( +rincip(e

To the user+ a distributed system should look e'actly like a nondistributed

system.

Q. Distributed Kuery 2rocessing

R. Distributed Transaction 2rocessing

M. "ardware Independence

1F. 4perating *ystem Independence

11. >etwork Independence

1. Database Independence

Ob!ect oriented databases

INTRODUCTION TO ODB/S


26/42

G

An object database management system 74D&*+ also referred to as object3oriented

database management system or 44D&*:+ is a database management system 7D&*: that

supports the modelling and creation of data as objects. This includes some kind of support for

classes of objects and the inheritance of class properties and methods by subclasses and their

objects.

Definition

An object database management system 74D&*+ also referred to as object3oriented

database management system or 44D&*:+ is a database management system 7D&*: that

supports the modelling and creation of data as objects. This includes some kind of support for

classes of objects and the inheritance of class properties and methods by subclasses and their

objects.

4D&* were originally thought of to replace 5D&* because of their better fit with

object3oriented programming languages. "owever+ high switching cost+ the inclusion of object3

oriented features in 5D&* to make them 45D&*+ and the emergence of object3relational

mappers 745&s: have made 5D&* successfully defend their dominance in the data center for

server3side persistence.

4bject databases are now established as a complement+ not a replacement for relational

databases. They found their place as embeddable persistence solutions in devices+ on clients+ in

packaged software+ in real3time control systems+ and to power websites. The open sourcecommunity has created a new wave of enthusiasm that^s now fueling the rapid growth of

4D&* installations

Introduction

4bject 4riented database systems could not be named a new technology. As first 44

languages+ 44 databases appeared a lot of time ago. And it was even considered that them will

completely replace relational database systems. It was not happen.


27/42

Q

relational and some is object oriented 7as far as it is difficult to say now if some language is

object oriented or not:.

"ere we should talk a little bit about what is it Xobject oriented databasesX and their main

advantages. &ost of the modern programming languages are object oriented+ while most of the

mainstream databases 3 relational. *o programmer has to seat at two chairs and work with two

data models 3 relational and object. It significantly complicates design of application+ because

system architect has two work with different notions representing the same entities. And

programmer has to implement a lot of code responsible for packingunpacking data from one

representation to another. It is huge+ error prone work and what is even worse 3 such

packingunpacking routines significantly degrade system performance. &odern modeling tools

helps to somehow solve this problem 3 them generate both application classes and database

tables from universal model description. ut them are still far from ideal.

OBJECT ORIENTED CONCE+TS

Ob!ect Oriented Databases

4bject oriented databases are also called 4bject Database &anagement *ystems 74D&*:.

4bject databases store objects rather than data such as integers+ strings or real numbers. 4bjects

are used in object oriented languages such as *malltalk+ )__+ @ava+ and others. 4bjects basicallyconsist of the following-

Attributes 3 Attributes are data which defines the characteristics of an object. This data

may be simple such as integers+ strings+ and real numbers or it may be a reference to a

comple' object.

&ethods 3 &ethods define the behavior of an object and are what was formally called

procedures or functions.

Therefore objects contain both e'ecutable code and data. There are other characteristics of

objects such as whether methods or data can be accessed from outside the object.


28/42


29/42

M

)A* Applications 7)A*?3computer aided software engineering+ )AD3computer aided

design+ )A&3computer aided manufacture:

&ultimedia Applications

4bject projects that change over time.

)ommerce

Ob!ect Database Ad"antages o"er RDB/S

4bjects don^t re,uire assembly and disassembly saving coding time and e'ecution time to

assemble or disassemble objects.

5educed paging

?asier navigation

etter concurrency control 3 A hierarchy of objects may be locked.

Data model is based on the real world.


30/42


31/42

01

object position in the file is enough to identify the object. In other systems object

identifiers are more comple' and preserve uni,ueness even outside the scope of the local

computer.

Ob!ect references

5eferences between objects in 44 databases are represented using 4IDs. *o if field $ of

persistent object A contains reference to persistent object + then this field $ of object A

stores 4ID of object . 4bject oriented database provides efficient way to access object

by it^s 4ID.

Ob!ect c(asses

As it was mentioned above+ 44D&* stores objects inside database. To make it possible

to loadstore objects and perform some other operations with them 7garbage collection for

e'ample:+ 44D&* should know format of the object+ i.e. set of object fields and their

types. It is not efficient to store this information for each object instance. ut because

format of all objects belonging to one class is the same+ then it is possible to store class

and let object reference it^s class. *ome 44D&* treat classes as normal objects+ which

format also has to be defined. In this case the notion of metaclass is introduced.

&etaclass is class of the class.

In)eritance and po(,%orp)is%

All object oriented languages supports inheritance. Inheritance is mechanism allowing

child object to inherit behavior and properties of parent object. 44D&* should

certainly be able to represent inheritance in database. If class A is derived from class +

then class A inherits all methods of class and it can be used everywhere where class

can be used. *o it makes it possible to manipulate with instance of class using variable

with type A. It is called polymorphism and its support is one of the main features of

object oriented languages and databases.

Tig)t integration &it) progra%%ing (anguage

5elational databases provides non3procedural ,uery language. It means that ,uery

e'pressed in this language specifies what should be done+ but doesn^t specify how to do

it. In contradiction to it+ most of the modern programming languages are imperative

languages 3 so the program written in this language specifies at higher or lower level of

abstractions which actions should be performed to produce re,uested result. 4bject3


32/42

0

oriented languages are also imperative languages. And although 44D&* usually

provides non3procedural ,uery language 7some kind of object oriented e'tension of

*K6:+ the main language to access object oriented database is imperative language. *o

the main goal of 44D&* is to provide seamless and efficient integration with this

language7s:.

Traditiona( DB/S features

Database systems were implemented to provide efficient and consistent way of

manipulation with data. *o object oriented database systems also need to support these

features to be able to called Xdatabase systemsX. 4ne of the basic notion is A)ID

7Atomic+ )onsistent+ Isolation+ and Durable: transactions. I do not want to e'plain

principles of supporting transactions in database systems. The only thing I should notice

is that database should be able to provide concurrent access to the data by many clients

and preserve consistency of data.

Ob!ect-oriented design

4bject3oriented design is part of 44 methodology and it forces programmers to think in terms

of objects+ rather than procedures+ when they plan their code. An objectcontains encapsulated

data and procedures grouped together to represent an entity. The ^object interface^+ how the object

can be interacted+ is also defined. An object3oriented program is described by the interaction of

these objects. 4bject3oriented design is the discipline of defining the objectsand theirinteractions to solve a problem that was identified and documented during object3oriented

analysis.

$rom a business perspective+ 4bject 4riented Design refers to the objects that make up that

business. $or e'ample a business object can consist of people+ data files+ e,uipment+ vehicles+

etc. These are the elements which comprise the company and should be taken into consideration

whenever analy#ing the needs of any business.

Ob!ect-oriented design

Input 7sources9 for ob!ect-oriented design
http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Entityhttp://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object-oriented_analysishttp://en.wikipedia.org/wiki/Object-oriented_analysishttp://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Entityhttp://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object-oriented_analysishttp://en.wikipedia.org/wiki/Object-oriented_analysishttp://en.wikipedia.org/wiki/Object_(computer_science)


33/42

00

Conceptua( %ode( 7must have9#)onceptual model is the result of object3oriented

analysis+ it captures concepts in theproblem domain.The conceptual model is e'plicitly

chosen to be independent of implementation details+ such as concurrencyor data storage.

Use case 7must have:- !se case is description of se,uences of events that+ taken together+

lead to a system doing something useful. ?ach use case provides one or morescenarios

that convey how the system should interact with the users called actors to achieve a

specific business goal or function. !se case actors may be end users or other systems. In

many circumstances use cases are further elaborated into use case diagrams. !se case

diagrams are use to identify the actor 7users or other systems: and the processes they

perform.

S,ste% Se?uence Diagra% 7should have:- *ystem *e,uence diagram 7**D: is a picture

that shows+ for a particular scenario of a use case+ the events that e'ternal actors generate+

their order+ and possible inter3system events.

User interface docu%entations7if applicable:- Document that shows and describes the

look and feelof the end product^s user interface. It is not mandatory to have this+ but it

helps to visuali#e the end3product and therefore helps the designer.

Re(ationa( data %ode( 7if applicable:- A data model is an abstract model that describes

how data is represented and used. If anobject databaseis not used+ the relational data

model should usually be created before the design can start. "ow the relational to object

mapping is done is included to the 44 design.

Ob!ect-oriented concepts supported b, an OO (anguage

The five basic concepts of object3oriented design are the implementation level features that are

built into the programming language. These features are often referred to by these common

names-

4bject)lass- A tight coupling or association of data structures with the methods or

functions that act on the data. This is called a class+ or object7an object is created based

on a class:. ?ach object serves a separate function. It is defined by its properties+ what it
http://en.wikipedia.org/wiki/Conceptual_model_(computer_science)http://en.wikipedia.org/wiki/Problem_domainhttp://en.wikipedia.org/wiki/Problem_domainhttp://en.wikipedia.org/wiki/Concurrency_(computer_science)http://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Scenario_(computing)http://en.wikipedia.org/wiki/Scenario_(computing)http://en.wikipedia.org/wiki/Scenario_(computing)http://en.wikipedia.org/wiki/System_Sequence_Diagramhttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/Look_and_feelhttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/Relational_data_modelhttp://en.wikipedia.org/wiki/Object_databasehttp://en.wikipedia.org/wiki/Object_databasehttp://en.wikipedia.org/wiki/Object_databasehttp://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Conceptual_model_(computer_science)http://en.wikipedia.org/wiki/Problem_domainhttp://en.wikipedia.org/wiki/Concurrency_(computer_science)http://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Scenario_(computing)http://en.wikipedia.org/wiki/System_Sequence_Diagramhttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/Look_and_feelhttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/Relational_data_modelhttp://en.wikipedia.org/wiki/Object_databasehttp://en.wikipedia.org/wiki/Object_(computer_science)


34/42

0

is and what it can do. An object can be part of a class+ which is a set of objects that are

similar.

Information hiding- The ability to protect some components of the object from e'ternal

entities. This is reali#ed by language keywords to enable a variable to be declared as

privateorprotectedto the owning class.

Inheritance- The ability for a classto e'tend or override functionality of another class.

The so3calledsubclasshas a whole section that is thesuperclassand then it has its own

set of functions and data.

Interface- The ability to defer the implementation of a method. The ability to define the

functionsor methodssignatures without implementing them.

2olymorphism- The ability to replace an objectwith itssubobjects. The ability of anobject-variableto contain+ not only that object+ but also all of itssubobjects.

Designing concepts

Defining objects+ creating class diagramfrom conceptual diagram- !sually map entity to

class. = Identifying attributes.

!se design patterns7if applicable:- A design pattern is not a finished design+ it is a

description of a solution to a common problem+ in a conte't`1. The main advantage of

using a design pattern is that it can be reused in multiple applications. It can also be

thought of as a template for how to solve a problem that can be used in many different

situations andor applications. 4bject3oriented design patterns typically show

relationships and interactions between classes or objects+ without specifying the final

application classes or objects that are involved.

Define application framework7if applicable:- Application framework is a term usually

used to refer to a set of libraries or classes that are used to implement the standard

structure of an application for a specific operating system. y bundling a large amount of

reusable code into a framework+ much time is saved for the developer+ since heshe is

saved the task of rewriting large amounts of standard code for each new application that

is developed.
http://en.wikipedia.org/wiki/Information_hidinghttp://en.wikipedia.org/wiki/Inheritance_(computer_science)http://en.wikipedia.org/wiki/Interface_(computer_science)http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programminghttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Conceptual_model_(computer_science)http://en.wikipedia.org/wiki/Attribute_(computing)http://en.wikipedia.org/wiki/Design_pattern_(computer_science)http://en.wikipedia.org/wiki/#cite_note-gof-0http://en.wikipedia.org/wiki/Application_frameworkhttp://en.wikipedia.org/wiki/Information_hidinghttp://en.wikipedia.org/wiki/Inheritance_(computer_science)http://en.wikipedia.org/wiki/Interface_(computer_science)http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programminghttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Conceptual_model_(computer_science)http://en.wikipedia.org/wiki/Attribute_(computing)http://en.wikipedia.org/wiki/Design_pattern_(computer_science)http://en.wikipedia.org/wiki/#cite_note-gof-0http://en.wikipedia.org/wiki/Application_framework


35/42

0/

Identify persistent objectsdata 7if applicable:- Identify objects that have to last longer

than a single runtime of the application. If a relational database is used+ design the object

relation mapping.

Identify and define remote objects 7if applicable:

Output 7de(i"erab(es9 of ob!ect-oriented design

)lass diagram- A class diagram is a type of static structure !&6diagram that describes

the structure of a system by showing the system^s classes+ their attributes+ and the

relationships between the classes.

*e,uence Diagram- ?'tends the*ystem *e,uence Diagramto add specific objects that

handle the system events. These are usually created for important and comple' system

events+ not for simple or trivial ones.

A se,uence diagram shows+ as parallel vertical lines+ different processes or objects that

live simultaneously+ and+ as hori#ontal arrows+ the messages e'changed between them+ in

the order in which they occur.

+rogra%%ing concepts

Aspect3oriented programming- 4ne view of aspect3oriented programming 7A42: is that

every major feature of the program+ core concern 7business logic:+ or cross3cutting

concern 7additional features:+ is an aspect+ and by weaving them together 7also called

composition:+ you finally produce a whole out of the separate aspects.

Dependency injection- The basic idea is that if an object depends upon having an instance

of some other object then the needed object is XinjectedX into the dependent objectO for

e'ample+ being passed a database connection as an argument to the constructor instead of

creating one internally.

Acyclic dependencies principle- The dependency graph of packages or components

should have no cycles. This is also referred to as having a directed acyclic graph.`$or
http://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/w/index.php?title=Sequence_Diagram&action=edit&redlink=1http://en.wikipedia.org/wiki/System_Sequence_Diagramhttp://en.wikipedia.org/wiki/Aspect_(computer_science)http://en.wikipedia.org/wiki/Dependency_injectionhttp://en.wikipedia.org/w/index.php?title=Acyclic_dependencies_principle&action=edit&redlink=1http://en.wikipedia.org/wiki/Directed_acyclic_graphhttp://en.wikipedia.org/wiki/Directed_acyclic_graphhttp://en.wikipedia.org/wiki/#cite_note-objectMentor-1http://en.wikipedia.org/wiki/#cite_note-objectMentor-1http://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/w/index.php?title=Sequence_Diagram&action=edit&redlink=1http://en.wikipedia.org/wiki/System_Sequence_Diagramhttp://en.wikipedia.org/wiki/Aspect_(computer_science)http://en.wikipedia.org/wiki/Dependency_injectionhttp://en.wikipedia.org/w/index.php?title=Acyclic_dependencies_principle&action=edit&redlink=1http://en.wikipedia.org/wiki/Directed_acyclic_graphhttp://en.wikipedia.org/wiki/#cite_note-objectMentor-1


36/42

0G

e'ample+ package ) depends on package + which depends on package A. If package A

also depended on package )+ then you would have a cycle.

)omposite reuse principle- $avor polymorphic composition of objects over inheritance.

U/6

Unified /ode(ing 6anguage7U/6: is a standardi#ed general3purposemodeling language in

the field of object3oriented software engineering.The standard is managed+ and was created by+

the 4bject &anagement (roup.

!&6 includes a set of graphic notation techni,ues to create visual models of object3oriented

software3intensive systems.

The !nified &odeling 6anguage 7!&6: is used to specify+ visuali#e+ modify+ construct and

document the artifactsof an object3orientedsoftware3intensive system under development.`1

!&6 offers a standard way to visuali#e a system^s architectural blueprints+ including elements

such as-

activities

actors

business processes

database schemas

7logical: components

programming languagestatements

reusable software components.`

!&6 combines techni,ues from data modeling7entity relationship diagrams:+business modeling

7work flows:+ object modeling+ and component modeling. It can be used with all processes+throughout the software development life cycle+ and across different implementation

technologies.`0!&6 has synthesi#ed the notations of the ooch method+ the 4bject3modeling

techni,ue74&T: and 4bject3oriented software engineering744*?: by fusing them into a

single+ common and widely usable modeling language.`citation needed!&6 aims to be a standard

modeling language which can model concurrent and distributed systems. !&6 is a de facto
http://en.wikipedia.org/w/index.php?title=Composite_reuse_principle&action=edit&redlink=1http://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Object-orientedhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Object_Management_Grouphttp://en.wikipedia.org/wiki/Visual_modelinghttp://en.wikipedia.org/wiki/Object-orientedhttp://en.wikipedia.org/wiki/Artifact_(software_development)http://en.wikipedia.org/wiki/Object-orientedhttp://en.wikipedia.org/wiki/Unified_Modeling_Language#cite_note-Foldoc01-0http://en.wikipedia.org/wiki/Activity_(UML)http://en.wikipedia.org/wiki/Actor_(UML)http://en.wikipedia.org/wiki/Business_processhttp://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/Component_(UML)http://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/Component-based_software_engineeringhttp://en.wikipedia.org/wiki/Unified_Modeling_Language#cite_note-OMG00-1http://en.wikipedia.org/wiki/Data_modelinghttp://en.wikipedia.org/wiki/Entity_relationship_diagramhttp://en.wikipedia.org/wiki/Business_modelinghttp://en.wikipedia.org/wiki/Object_modelinghttp://en.wikipedia.org/wiki/Software_development_life_cyclehttp://en.wikipedia.org/wiki/Unified_Modeling_Language#cite_note-2http://en.wikipedia.org/wiki/Booch_methodhttp://en.wikipedia.org/wiki/Object-modeling_techniquehttp://en.wikipedia.org/wiki/Object-modeling_techniquehttp://en.wikipedia.org/wiki/Object-oriented_software_engineeringhttp://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Distributed_systemshttp://en.wikipedia.org/w/index.php?title=Composite_reuse_principle&action=edit&redlink=1http://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Object-orientedhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Object_Management_Grouphttp://en.wikipedia.org/wiki/Visual_modelinghttp://en.wikipedia.org/wiki/Object-orientedhttp://en.wikipedia.org/wiki/Artifact_(software_development)http://en.wikipedia.org/wiki/Object-orientedhttp://en.wikipedia.org/wiki/Unified_Modeling_Language#cite_note-Foldoc01-0http://en.wikipedia.org/wiki/Activity_(UML)http://en.wikipedia.org/wiki/Actor_(UML)http://en.wikipedia.org/wiki/Business_processhttp://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/Component_(UML)http://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/Component-based_software_engineeringhttp://en.wikipedia.org/wiki/Unified_Modeling_Language#cite_note-OMG00-1http://en.wikipedia.org/wiki/Data_modelinghttp://en.wikipedia.org/wiki/Entity_relationship_diagramhttp://en.wikipedia.org/wiki/Business_modelinghttp://en.wikipedia.org/wiki/Object_modelinghttp://en.wikipedia.org/wiki/Software_development_life_cyclehttp://en.wikipedia.org/wiki/Unified_Modeling_Language#cite_note-2http://en.wikipedia.org/wiki/Booch_methodhttp://en.wikipedia.org/wiki/Object-modeling_techniquehttp://en.wikipedia.org/wiki/Object-modeling_techniquehttp://en.wikipedia.org/wiki/Object-oriented_software_engineeringhttp://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Distributed_systems


37/42

0Q

industrystandard+`citation neededand is evolving under the auspices of the 4bject &anagement (roup

74&(:.

/ode(ing

It is important to distinguish between the !&6 model and the set of diagrams of a system. A

diagram is a partial graphic representation of a system^s model. The model also contains

documentation that drive the model elements and diagrams 7such as written use cases:.

!&6 diagrams represent two different views of a system model

*tatic 7orstructural: view- emphasi#es the static structure of the system using objects+

attributes+ operations and relationships. The structural view includesclass diagramsand

composite structure diagrams.

Dynamic 7or behavioral: view- emphasi#es the dynamic behavior of the system by

showing collaborations among objects and changes to the internal states of objects. This

view includes se,uence diagrams+activity diagrams andstate machine diagrams.

!&6 models can be e'changed among !&6 toolsby using the J&I interchange format.

Diagra%s o"er"ie&

!&6 . has 1 types of diagramsdivided into two categories.`11*even diagram types represent

structuralinformation+ and the other seven represent general types of behavior+ including four

that represent different aspects of interactions. These diagrams can be categori#ed hierarchically

as shown in the following class diagram-
http://en.wikipedia.org/wiki/Industryhttp://en.wikipedia.org/wiki/Technical_standardhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Object_Management_Grouphttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Composite_structure_diagramhttp://en.wikipedia.org/wiki/Sequence_diagramhttp://en.wikipedia.org/wiki/Activity_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/UML_toolhttp://en.wikipedia.org/wiki/XMIhttp://en.wikipedia.org/wiki/Category:UML_diagramshttp://en.wikipedia.org/wiki/Unified_Modeling_Language#cite_note-10http://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Industryhttp://en.wikipedia.org/wiki/Technical_standardhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Object_Management_Grouphttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Composite_structure_diagramhttp://en.wikipedia.org/wiki/Sequence_diagramhttp://en.wikipedia.org/wiki/Activity_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/UML_toolhttp://en.wikipedia.org/wiki/XMIhttp://en.wikipedia.org/wiki/Category:UML_diagramshttp://en.wikipedia.org/wiki/Unified_Modeling_Language#cite_note-10http://en.wikipedia.org/wiki/Class_diagram


38/42

0R

!&6 does not restrict !&6 element types to a certain diagram type. In general+ every !&6

element may appear on almost all types of diagramsO this fle'ibility has been partially restricted

in !&6 .F. !&6profiles may define additional diagram types or e'tend e'isting diagrams with

additional notations.

In keeping with the tradition of engineering drawings+`citation neededa comment or note e'plaining

usage+ constraint+ or intent is allowed in a !&6 diagram.

Structure diagra%s

*tructure diagrams emphasi#e the things that must be present in the system being modeled. *ince

structure diagrams represent the structure+ they are used e'tensively in documenting the software

architectureof software systems.

)lass diagram- describes the structure of a system by showing the system^s classes+ their

attributes+ and the relationships among the classes.
http://en.wikipedia.org/wiki/Profile_(UML)http://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Class_diagramhttp://upload.wikimedia.org/wikipedia/commons/d/d6/Uml_diagram2.pnghttp://en.wikipedia.org/wiki/Profile_(UML)http://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Class_diagram


39/42

0M

)omponent diagram- describes how a software system is split up into components and

shows the dependencies among these components.

)omposite structure diagram- describes the internal structure of a class and the

collaborations that this structure makes possible.

Deployment diagram- describes the hardware used in system implementations and the

e'ecution environments and artifacts deployed on the hardware.

4bject diagram- shows a complete or partial view of the structure of a modeled system at

a specific time.

2ackage diagram- describes how a system is split up into logical groupings by showing

the dependencies among these groupings.

2rofile diagram- operates at the metamodel level to show stereotypes as classes with the

PPstereotypeEE stereotype+ and profiles as packages with the PPprofileEE stereotype.

The e'tension relation 7solid line with closed+ filled arrowhead: indicates what

metamodel element a given stereotype is e'tending.

)lass diagram

)omponent diagram
http://en.wikipedia.org/wiki/Component_diagramhttp://en.wikipedia.org/wiki/Composite_structure_diagramhttp://en.wikipedia.org/wiki/Deployment_diagramhttp://en.wikipedia.org/wiki/Object_diagramhttp://en.wikipedia.org/wiki/Package_diagramhttp://en.wikipedia.org/w/index.php?title=Profile_diagram&action=edit&redlink=1http://en.wikipedia.org/wiki/File:Component-4.pnghttp://en.wikipedia.org/wiki/File:BankAccount.pnghttp://en.wikipedia.org/wiki/Component_diagramhttp://en.wikipedia.org/wiki/Composite_structure_diagramhttp://en.wikipedia.org/wiki/Deployment_diagramhttp://en.wikipedia.org/wiki/Object_diagramhttp://en.wikipedia.org/wiki/Package_diagramhttp://en.wikipedia.org/w/index.php?title=Profile_diagram&action=edit&redlink=1


40/42

F

)omposite structure diagrams

Deployment diagram

4bject diagram

2ackage diagram

Be)a"ior diagra%s

ehavior diagrams emphasi#e what must happen in the system being modeled. *ince behavior

diagrams illustrate the behavior of a system+ they are used e'tensively to describe the

functionality of software systems.

Activity diagram- describes the business and operational step3by3step workflows of

components in a system. An activity diagram shows the overall flow of control.

!&6 state machine diagram- describes the states and state transitions of the system.
http://en.wikipedia.org/wiki/Activity_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/File:Package_import-1.pnghttp://upload.wikimedia.org/wikipedia/commons/8/89/Instance_specification_3.pnghttp://en.wikipedia.org/wiki/File:UML_Diagramme_Deploiement.gifhttp://en.wikipedia.org/wiki/Activity_diagramhttp://en.wikipedia.org/wiki/UML_state_machine


41/42

1

!se case diagram- describes the functionality provided by a system in terms of actors+

their goals represented as use cases+ and any dependencies among those use cases.

!&6 Activity Diagram

*tate &achinediagram

!se case diagram

Interaction diagra%s

Interaction diagrams+ a subset of behaviour diagrams+ emphasi#e the flow of control and data

among the things in the system being modeled-

)ommunication diagram- shows the interactions between objects or parts in terms of

se,uenced messages. They represent a combination of information taken from )lass+
http://en.wikipedia.org/wiki/Use_case_diagramhttp://en.wikipedia.org/wiki/Activity_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/Use_case_diagramhttp://en.wikipedia.org/wiki/Communication_diagramhttp://en.wikipedia.org/wiki/File:UML_Use_Case_diagram.svghttp://en.wikipedia.org/wiki/File:UML_state_diagram.pnghttp://en.wikipedia.org/wiki/File:Activity_Diagram_1.jpghttp://en.wikipedia.org/wiki/Use_case_diagramhttp://en.wikipedia.org/wiki/Activity_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/Use_case_diagramhttp://en.wikipedia.org/wiki/Communication_diagram


42/42

*e,uence+ and !se )ase Diagrams describing both the static structure and dynamic

behavior of a system.

Interaction overview diagram- provides an overview in which the nodes represent

communication diagrams.

*e,uence diagram- shows how objects communicate with each other in terms of a

se,uence of messages. Also indicates the lifespans of objects relative to those messages.

Timing diagrams- a specific type of interaction diagram where the focus is on timing

constraints.

)ommunication diagram

Interaction overview diagram

*e,uence diagram

The 2rotocol *tate &achine is a sub3variant of the *tate &achine.It may be used to model

network communication protocols.

========================
http://en.wikipedia.org/wiki/Interaction_overview_diagramhttp://en.wikipedia.org/wiki/Sequence_diagramhttp://en.wikipedia.org/wiki/Timing_diagram_(Unified_Modeling_Language)http://en.wikipedia.org/wiki/Communication_diagramhttp://en.wikipedia.org/wiki/Interaction_overview_diagramhttp://en.wikipedia.org/wiki/Sequence_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/Interaction_overview_diagramhttp://en.wikipedia.org/wiki/Sequence_diagramhttp://en.wikipedia.org/wiki/Timing_diagram_(Unified_Modeling_Language)http://en.wikipedia.org/wiki/Communication_diagramhttp://en.wikipedia.org/wiki/Interaction_overview_diagramhttp://en.wikipedia.org/wiki/Sequence_diagramhttp://en.wikipedia.org/wiki/UML_state_machine

DISTRIBUTED DATABASE ANDOBJECT ORIENTED DATABASES UNIT- IV.doc

Documents

Transcript of DISTRIBUTED DATABASE ANDOBJECT ORIENTED DATABASES UNIT- IV.doc