1

UNIT- IV
DISTRIBUTED DATABASE ANDOBJECT ORIENTED DATABASES

Concepts of distributed databases and design

DISTRIBUTED DATABASE DESI N

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 areo Design criteria for effective data distribution

. 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 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 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.

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

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

(oba( sc)e%a

*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.

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 are1. 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. 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. ut re,uires

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 typeAttribute ; value A /in-ter% +redicate , for a 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 <here 7pi= ; pi or pi = ;>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

/ predicate pi itself such that the corresponding fragments are referenced in a different way by at least one application. 6et us try to understand the above terminologies by taking an e'ample. 6et us consider the relations D?2T 7D?2T>!&+ >A&?+ A5?A: and @4 7@4 ID+@4 >A&?:. 6et us assume that only two departments are functioning i.e 1 A ..>ow some e'amples for simple predicates areD?2T>!& ;1 or D?2T>!& .+ D?2T>!& ; . or D?2T>!& 1 @4 ; 8programmer9 or @4 8programmer9. The corresponding min3term predicates are D?2T>!& ;1 A>D @4 ; 8programmer9 D?2T>!& ;1 A>D @4 8programmer9 D?2T>!& 1 A>D @4 8programmer9 D?2T>!& 1 A>D @4 ; 8programmer9 >ow let us concentrate on some more supporting terminologies. 6et 2 ; Bp 1+p.+C.p nDbe a set of simple predicates. $or correct and efficient fragmentation 2 must be co%p(ete and %ini%a(* <e say that a set 2 of predicates is co%p(ete if and only if any two tuples belonging to the same fragment are referenced with the same probabilities by any application. The set 2 is %ini%a( if all its predicates are relevant. E4a%p(e# In the above e'ample+ 21 ;BD?2T>!& ; 1D is not co%p(ete since the application is even interested in the employees who are 8programmers9. *o in this case 2. ; BD?2T>!& ;1+@4 ; 8programmer9D is co%p(ete and %ini%a(* The set 20 ; BD?2T>!& ;1+ @4 ; 8programmer9+ *A6 E /FD is complete but not minimal since *A6 E/F is not relevant. y knowing the minimum characteristics that are to be considered now let us generali#e the method to be followed while producing fragments of the given global relation. I. )onsider a predicate pi that partitions the tuples of the global relation ( into two parts+ which are referenced differently at least by one application. 6et 2 ; p1. II. )onsider a new simple predicate pi which partitions at least one fragment of 2 into two parts+ which are referenced in a different way by at least one application. ?liminate non3relevant predicates from 2. 5epeat this step until the set of min3term fragments of 2 is complete.

G E4a%p(e# 6et us take two cities of Harnataka- *himoga and &ysore. The e'ample application considered is the marketing of medical goods. The global schema for this application includes the relations ?&26+ D?2T+ *!226I?5 and *!226I. These relations look as follows?&26 7?&2>!&+ >A&?+ *A6+ TAJ+ &(5>!&+ D?2T>!&: D?2T 7D?2T>!&+ >A&?+ A5?A+ &(5>!&: *!226I?5 7*>!&+ >A&?+ )ITI: *!226I 7*>!&+ 2>!&+ D?2T>!&+ K!A>: <e design the fragmentation of *!226I?5 and D?2T with a 2rimary $ragmentation. >ow let us take a ,uery. $ind t)e na%es of supp(iers &it) a gi"en nu%ber SNU/* As you have already come across a popular ,uery language S56 can be used for representing this ,uery. *elect >A&? $rom *!226I?5 <here *>!& ; LI This ,uery issued at any one of the sites. 6et us assume that we have t)ree sites in our purview. *ite 1 is in *himoga+ *ite . is in &ysore and *ite 0 is in between *himoga and &ysore. *o+ if the ,uery is issued at *ite 1 it references *!226I?5* whose )ITI is 8*himoga9 with almost MFN probabilityO if it is issued at *ite . it references *!226I?5* of 8*himoga9 and 8&ysore9 with e,ual probabilityO if it is issued at *ite0 it references *!226I?5* whose )ITI is 8&ysore9 with almost MFN probability. This is because the obvious fact that department around one city tends to use suppliers+ which are close to them. <e can write the predicates for the above application+ 21- )ITI ; 8*"I&4(A9 2.- )ITI ; 8&I*45?9

*ince the set B21+ 2.D is complete and minimal+ the search is terminated. 6et us now consider the global relation D?2T- DE+T 7DE+TNU/8 NA/E8 AREA8 / RNU/9* *ome e'ample predicates that are suitable for administrative applications are considered. 21- D?2T>!& P ; 1F 2.- 71F P D?2T>!& P ; .F: 20- D?2T>!& E .F 21- A5?A ; 8>45T"9

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 fourI1- D?2T>!& P ; 1F I.- 71F P D?2T>!& P ; .F: A>D 7A5?A ; 8>45T"9 : I0- 71F P D?2T>!& P ; .F: A>D 7A5?A ; 8*4!T"9 : I1- D?2T>!& E .F If we now concentrate about the fragment allocation we can easily allocate fragments corresponding to y1 and y1 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 !oin is 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 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 *!226I 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 *!226I and *!226I?5 in the *>!& attribute. o 5e,uires the information about supplies at a given departmentO then they perform join between *!226I and D?2T on the D?2T>!& attribute. rap)s can efficiently

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 *!226I 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 choice. In possible aggregated to constitute fragments. oth are "euristic approaches as each iteration steps look for best both the cases formulas are used to indicate the best splitting or grouping.

51

*1

51

*
1

5
1

*
1

The different possible join graphs 5. *. 5. * 50 *0 50

1

5
.

*
.

5
0

*
0

5
1

*
1

*
.

51

51

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 madeAdministrative 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 A1 Apply "ori#ontal fragmentation to %ertical fragments Apply %ertical fragmentation to "ori#ontal fragments A. A0 A1 A/

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

%ertical fragmentations followed by hori#ontal fragmentation. A1 A. A0 A1 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

1F allocating fragments. There are two types of allocation methods+ which can be followed. They areNon-redundant A((ocation# It is simple. A method known as 8 est3fit 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+ sinceo 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 motivationsS 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 S makes data accessible by all units S stores data close to where it is most fre,uently used. database system which-

Distributed Database
A logically interrelated collection of shared data 7and a

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 $ragmentsTreplicas 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.

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. 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. ?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. There is no reliance on central site.

+ara((e( DB/S
&ain architectures for parallel D &*s areS *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

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. ?ach site is able to process local transactions+ those transactions that access data only in a single site 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 o

The sites in the system can be connected physically in a variety of ways. The major differences among these configurations involveInstallation 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

11

Availability - The degree to which data can be accessed despite the failure of some links or sites.

T,pes of DDB/S 0o%ogeneous DDB/S

S All sites use same D &* product 7eg.4racle: S $airly easy to design and manage.

0eterogeneous DDB/S
S *ites may run different D &* products 7eg. 4racle and Ingress: S 2ossibly different underlying data models 7eg. relational D and 44 database: S 4ccurs when sites have implemented their own databases and integration is considered later. S <e wonVt consider heterogeneous DD &*s here.

$unctions of a DDB/S
S ?'pect DD &* to have at least the functionality of a D &* Also to have following functionalityS ?'tended communication services. S ?'tended Data Dictionary. S Distributed ,uery processing. S ?'tended concurrency control. S ?'tended recovery services. S ?'tended security control.

Reference Arc)itecture for DDB/S

S Due to diversity+ no accepted architecture e,uivalent to A>*IT*2A5) 03level architecture for D &*s. S A possible reference architecture consists ofS *et of global e'ternal schemas. S (lobal conceptual schema 7()*:.

1/ S $ragmentation schema and allocation schema. S *et of schemas for each local D &* conforming to 03level A>*IT*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 D s.

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 achieveS 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 ,uantitativeT,ualitative information.

$rag%entation
S Kuantitative information may includeS 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 asS 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<e have a relation *ells7pub+ address+price+type: Type is 8bitter9 or 8lager9.

1Q <e can split *ells into twp dfferent fragmentsS *ells itter; type ; 8bitter97*ells: S *ells6ager; type ; 8lager97*ells Data Allocation S $our strategies regarding placement of dataS )entrali#ed S 2artitioned 7or $ragmented: S )omplete 5eplication S *elective 5eplication ; Centra(i1ed- )onsists of single database stored at one site with users distributed across the network. ; +artitioned- Database partitioned into disjoint fragments+ each fragment assigned to one site. ; Co%p(ete Rep(ication- )onsists of maintaining complete copy of database at each site. ; Se(ecti"e Rep(ication- )ombination of partitioning+ replication+ and centrali#ation.

-), $rag%ent:
Usage S Applications work with views rather than entire relations. Efficienc, S Data is stored close to where it is most fre,uently used. S Data that is not needed by local applications is not stored +ara((e(is% S <ith fragments as unit of distribution+ transaction can be divided into several sub3,ueries that operate on fragments. Securit, S Data not re,uired by local applications is not stored and so not available to unauthori#ed users.

T,pes of $rag%entation
S $our types of fragmentationS "ori#ontal+ S %ertical+ S &i'ed+

1R S Derived. S 4ther possibility is no fragmentationS If relation is small and not updated fre,uently+ may be better not to fragment relation.

0ori1onta( and Vertica( $rag%entation

Two types of fragmentationS "ori#ontal S %ertical

/i4ed $rag%entation

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 algebrap75: S ?'ample5elation- *ells7pub+ address+price+type: S $ragmentsY *ells itter; 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 algebraa1+Can75: S Determined by establishing affinity of one attribute to another. S ?'ampleS 5elation- ars7name+address+licence+employees+owner: S $ragments-

.F Y name+address+licence 7 ars: Y name+address+employees+owner7 ars:

/i4ed $rag%entation
S <e can also mi' hori#ontal and vertical fragmentation. S <e obtain a fragment that consist of an hori#ontalfragment that is vertically fragmented+ or a vertical fragment that is hori#ontally fragmented. S Defined using *election and 2rojection operations of relational algebra. Zp7a1+Can75:: a1+Can7Zp75:: ?'ample 3 &i'ed $ragmentation *1 ; staff>o+ position+ se'+ D4 + salary7*taff: *. ; staff>o+ f>ame+ l>ame+ branch>o7*taff: *.1 ; [branch>o;\ FF0V7*.: *.. ; [branch>o;\ FF/V7*.: *.0 ; [branch>o;\ FFQV7*.

Deri"ed 0ori1onta( $rag%entation

S A hori#ontal fragment that is based on hori#ontal fragmentation of a parent relation. S ?nsures that fragments that are fre,uently joined together are at same site. S Defined using *emijoin operation of relational algebra5i ; 5 E$ *i+ 1 ][i ][w ?'ample 3 Derived "ori#ontal $ragmentation *0 ; [branch>o;\ FF0V7*taff: *1 ; [branch>o;\ FF/V7*taff: */ ; [branch>o;\ FFQV7*taff: )ould use derived fragmentation for 2roperty2i ; 2roperty$or5ent Ebranch>o *i+ 0 ][i ][/

Deri"ed 0ori1onta( $rag%entation

S If relation contains more than one foreign key+ need to select one as parent. S )hoice can be based on fragmentation used most fre,uently or fragmentation with better join

.1 characteristics. "ow can we define fragments correctlyW In defining fragments we have to be very careful. Three correctness rulesS )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;B itter+ 6agerD $ragmentsS *ells itter; type ; 8bitter97*ells:

.. S *ells6ager; type ; 8lager97*ells:

Correctness ru(es
; Co%p(eteness- ?ach tuple in the relation appears either in *ells itter+ or in *ells6ager ; Reconstruction- The *ells relation can be reconstructed from the fragments *ells ; *ells itter [*ells6ager ; Dis!ointness- The two fragments are disjoint+ there can be no beer that is both 86ager9 and 8 itter

Correctness of Vertica( $rag%entation

5elation- ars7name+address+licence+employees+owner: $ragmentsS r1 ;name+address+licence 7 ars: S r. ; name+address+employees+owner7 ars: 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,

.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. DisadvantagesS loss of some local autonomyO S central site may become a bottleneckO S low availabilityO if the central site fails+ remaining sites cannot 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,

.1 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 have completed 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 decideS which fragment to accessO S which copy of a fragment to useO

./ 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 includeS IT4 costO S )2! costO S communication cost.

Date<s => 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 1. 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

.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 source community 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. <hat we can see now is that 44 and relational databases are moving toward each other- most vendors of 44D &* provide in their products support of *K63like non3procedural ,uery language while vendors of mainstream 5D &*es incorporate 44 e'tensions in their products 744 version of *K6:. *o+ we can e'pect that at some moment of time it will not be possible to say that some D &* is

.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 packingTunpacking data from one representation to another. It is huge+ error prone work and what is even worse 3 such packingTunpacking 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 basically consist 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. <e don^t consider this here+ to keep the definition simple and to apply it to what an object database is. 4ne other term worth mentioning is classes. )lasses are used in object oriented programming to define the data and methods the object will contain. The class is like a template to the object. The

.R class does not itself contain data or methods but defines the data and methods contained in the object. The class is used to create 7instantiate: the object. )lasses may be used in object databases to recreate parts of the object that may not actually be stored in the database. &ethods may not be stored in the database and may be recreated by using a class.

Co%parison to Re(ationa( Databases

5elational databases store data in tables that are two dimensional. The tables have rows and columns. 5elational database tables are Xnormali#edX so data is not repeated more often than necessary. All table columns depend on a primary key 7a uni,ue value in the column: to identify the column. 4nce the specific column is identified+ data from one or more rows associated with that column may be obtained or changed. To put objects into relational databases+ they must be described in terms of simple string+ integer+ or real number data. $or instance in the case of an airplane. The wing may be placed in one table with rows and columns describing its dimensions and characteristics. The fusalage may be in another table+ the propeller in another table+ tires+ and so on. reaking comple' information out into simple data takes time and is labor intensive. )ode must be written to accomplish this task.

Ob!ect +ersistence
<ith traditional databases+ data manipulated by the application is transient and data in the database is persisted 7*tored on a permanent storage device:. In object databases+ the application can manipulate both transient and persisted data.

-)en to Use Ob!ect Databases

4bject databases should be used when there is comple' data andTor comple' data relationships. This includes a many to many object relationship. 4bject databases should not be used when there would be few join tables and there are large volumes of simple transactional data. 4bject databases work well with-

.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. <orks well for distributed architectures. 6ess code re,uired when applications are object oriented.

Ob!ect Database Disad"antages co%pared to RDB/S

6ower efficiency when data is simple and relationships are simple. 5elational tables are simpler. 6ate binding may slow access speed. &ore user tools e'ist for 5D &*. *tandards for 5D &* are more stable. *upport for 5D &* is more certain and change is less likely to be re,uired.

ODB/S Standards

4bject Data &anagement (roup 4bject Database *tandard 4D&G...F 4bject Kuery 6anguage 4K6 support of *K6M.

0F

0o& Data is Stored

Two basic methods are used to store objects by different database vendors.

?ach object has a uni,ue ID and is defined as a subclass of a base class+ using inheritance to determine attributes. %irtual memory mapping is used for object storage and management.

Data transfers are either done on a per object basis or on a per page 7normally 1H: basis.

BASIC +RINCI+A6S O$ BUI6DIN

OBJECT ORIENTED DATABASES

<hich database can be named Xobject orientedXW There is no precise answer to this ,uestion+ as far as it is not possible to specify all characteristics of object3oriented language. $irst of all there is no single definition of what is it XobjectX. <e will use the following definition- object is set of properties and methods for manipulation with them. All objects with the same set of properties and methods form a class. Although it is not possible to specify complete set of features which can be used to determine if the particular D &* is object oriented or not+ there are certainly a number of features which are common to the most of e'isted object3oriented database systems1. 4bject is the basic notion in object oriented system. It is basic unit of storing data in the database. ?ach object has uni,ue 4ID which is automatically generated by the system. .. Direct representation of references between objects. 0. *upport of inheritance and polymorphism. 1. Tight integration with at least one object oriented programming language /. *upport of traditional D &* features- A)ID transactions+ backups+ import3e'port utilities+ scheme evaluation+... elow these features are e'plained more preciselyOb!ect identifier 7OID9 In relational database systems records are identified only by their content. If all attributes of two records have the same values+ then there is no way to distinguish these two records. ut in object oriented databases objects are uni,uely identified by 4ID. $ormat of 4ID is specific for each system. In some systems just four bytes with object inde' or

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 loadTstore 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 using variable can be used. *o it makes it possible to manipulate with instance of class 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

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

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 object contains 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 objects and their interactions 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

00

Conceptua( %ode( 7must have9# )onceptual model is the result of object3oriented analysis+ it captures concepts in the problem domain. The conceptual model is e'plicitly chosen to be independent of implementation details+ such as concurrency or 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 more scenarios 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%entations 7if applicable:- Document that shows and describes the look and feel of 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 an object database is 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

4bjectT)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 object 7an object is created based on a class:. ?ach object serves a separate function. It is defined by its properties+ what it

01 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 private or protected to the owning class.

Inheritance- The ability for a class to e'tend or override functionality of another class. The so3called subclass has a whole section that is the superclass and 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 functions or methods signatures without implementing them. 2olymorphism- The ability to replace an object with its subobjects. The ability of an object-variable to contain+ not only that object+ but also all of its subobjects.

Designing concepts

Defining objects+ creating class diagram from conceptual diagram- !sually map entity to class. = Identifying attributes.

!se design patterns 7if applicable:- A design pattern is not a finished design+ it is a description of a solution to a common problem+ in a conte't`1a. 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 andTor 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 framework 7if 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 heTshe is saved the task of rewriting large amounts of standard code for each new application that is developed.

0/

Identify persistent objectsTdata 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 !&6 diagram 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 Diagram to 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. `.a $or

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 6anguage 7U/6: is a standardi#ed general3purpose modeling 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 artifacts of an object3oriented software3intensive system under development.`1a !&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 language statements reusable software components.`.a

!&6 combines techni,ues from data modeling 7entity 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.`0a !&6 has synthesi#ed the notations of the ooch method+ the 4bject3modeling techni,ue 74&T: and 4bject3oriented software engineering 744*?: by fusing them into a single+ common and widely usable modeling language.`citation neededa !&6 aims to be a standard modeling language which can model concurrent and distributed systems. !&6 is a de facto

0Q industry standard+`citation neededa and 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 modela

*tatic 7or structural: view- emphasi#es the static structure of the system using objects+ attributes+ operations and relationships. The structural view includes class diagrams and 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 and state machine diagrams.

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

Diagra%s o"er"ie&
!&6 ... has 11 types of diagrams divided into two categories.`11a *even diagram types represent structural information+ 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-

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. !&6 profiles may define additional diagram types or e'tend e'isting diagrams with additional notations. In keeping with the tradition of engineering drawings+`citation neededa a 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 architecture of software systems.

)lass diagram- describes the structure of a system by showing the system^s classes+ their attributes+ and the relationships among the classes.

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

1F )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.

11

!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 &achine diagram

!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+

1. *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. ========================