Project Pxxx - Eurescom - European Institute for Research and

Volume 3: Annex 2 - Data manipulation and management issues Deliverable 1

The TS-union makes sure, that each instances of the same relation appearing in both A and B is replicated as two distinct relations in W. This is assured by providing W with an extra attribute, identifying the originating database - either A (DB-A) or B (DB-B).

From W it is now easy to generate the sum of the accounts belonging to each client

(identified by the Name attribute) using TS-SQL (the query language provided with the TS-model - a variant of SQL). The sum of all the accounts is presented as the entity below (F) - which make up our federated database.

F: The federated database - as we want it - summing Hanson accounts correctly!

Name

Peterson

Hanson

Larson

Jonson

Account

175

100

200

200

When designing a federated database, we sometimes need to consider a set of databases (the basis) as one as above. For the same federated database, we might at other times need to consider the basis it is made of - a set of distinct databases.

TS-SQL contains SQL extended instructions, which make it convenient to deal with both cases. Regarding the TS-model it should finally be noted, that the extensions do not violate the fundamental important properties of the traditional model. This for instance means that a system implementing the TS-model can make use of query optimization techniques used in traditional relational systems.

1.2.3

Data Warehouse Used To Implement Federated System

Above we ended up defining our federated database as an entity (view) called F. To define F we used an intermediate entity (view) called W defined from two other entities A and B. We did say define - not generate. The fact the F and W are defined with A and B as basis, do not necessary mean that each relation in F and W are represented physically by the DBMS. It might be feasible just to keep a symbolic logical definition in the DBMS - also in the case where the entities grow to represent any higher number of relations. For instance the size of W might just be on the order of 50 bytes / octets, independent of the number of entities in W. To see why, let us look at a yet another view. Let us define the view H as comprised of ”All accounts regarding Peterson in the union of A and B”. Again this might seem, as we first need the union of A and B (in a physical though small representation) as a first step to generate a representation of H. But possibly the DBMS (which is relational) will choose internaly to rephrase the definition of H (which will have a formal representation in the DBMS), using properties of the relational algebra. Probably the

DBMS can find out that H equally is defined as ”the union of Peterson accounts in A and Peterson accounts in B”. Since there is a small number of Peterson accounts in both A and B the latter expression of H might be much more efficient to calculate, than brute force calculation the first definition of H.

Although it may seem, that a federated database can be implemented mostly using properties of relational algebra on the databases making up the basis, it might anyway be necessary to generate physic representations of the federated database (like F above) or physic representations of views used to define the federated database (like

W above). Let us for instance say, that we actually need frequent access to the data page 46 (120)



1999 EURESCOM Participants in Project P817-PF