Sunteți pe pagina 1din 7

Fragmentation

A relation R is divided into fragments r1, r2, …rn, which contain


enough infortmation to allow reconstruction of R

Example:
Practical session 2 We have a relation Sells(pub, address,price,type)
Type is “bitter” or “lager”.
We can split Sells into twp dfferent fragments:
Mon 7/11/05 • SellsBitter= σtype = “bitter”(Sells)
• SellsLager= σtype = “lager”(Sells)

COMP 302 V. Tamma COMP 302 V. Tamma


28

Types of Fragmentation Horizontal Fragmentation

• Four types of fragmentation: • Each fragment consists of a subset of the tuples of a


relation R.
• Horizontal,
• Vertical, • Defined using Selection operation of relational algebra:
• Mixed, • σp(R)
• Derived.
• Example:
• Other possibility is no fragmentation:
• Relation: Sells(pub, address,price,type)
• If relation is small and not updated frequently, may be better not to • Fragments:
fragment relation. – SellsBitter= σtype = “bitter”(Sells)
– SellsLager= σtype = “lager”(Sells)

COMP 302 V. Tamma COMP 302 V. Tamma


43
Vertical Fragmentation Mixed Fragmentation
• Each fragment consists of a subset of attributes of a relation R. • We can also mix horizontal and vertical fragmentation.
• Defined using projection operation of relational algebra:
• Πa1,…an(R) • We obtain a fragment that consist of an horizontal fragment that
• Determined by establishing affinity of one attribute to another. is vertically fragmented, or a vertical fragment that is
horizontally fragmented.
• Example:
• Relation: Bars(name,address,licence,employees,owner)
• Defined using Selection and Projection operations of relational
• Fragments: algebra.
– Πname,address,licence (Bars) σp(∏a1, ... ,an(R))
– Πname,address,employees,owner(Bars) ∏a1, ... ,an(σp(R))

COMP 302 V. Tamma


45 COMP 302 V. Tamma
46

Example - Mixed Fragmentation Derived Horizontal Fragmentation

S1 = ∏staffNo, position, sex, DOB, salary(Staff) • A horizontal fragment that is based on horizontal
S2 = ∏staffNo, fName, lName, branchNo(Staff) fragmentation of a parent relation.
• Ensures that fragments that are frequently joined
together are at same site.
S21 = σ branchNo=‘B003’(S2 )
• Defined using Semijoin operation of relational
S22 = σ branchNo=‘B005’(S2 ) algebra:
S23 = σ branchNo=‘B007’(S2 )
Ri = R F Si, 1≤i≤w

COMP 302 V. Tamma COMP 302 V. Tamma


Example - Derived Horizontal Fragmentation Derived Horizontal Fragmentation

S3 = σ branchNo=‘B003’(Staff) • If relation contains more than one foreign key,


S4 = σ need to select one as parent.
branchNo=‘B005’(Staff)
S5 = σ • Choice can be based on fragmentation used most
branchNo=‘B007’(Staff)
frequently or fragmentation with better join
characteristics.
Could use derived fragmentation for Property:

Pi = PropertyForRent branchNo Si , 3≤i≤5

COMP 302 V. Tamma COMP 302 V. Tamma


© Pearson Education Limited 1995, 2005

How can we define fragments correctly? Correctness of Fragmentation

In defining fragments we have to be very careful.


Completeness: If relation R is decomposed into
Three correctness rules: fragments r1, r2, …rn, each data item that can be found
in R must appear in at least one fragment.
• Completeness
• Reconstruction This ensures no loss of data during fragmentation.
• Disjointness.

COMP 302 V. Tamma


37 COMP 302 V. Tamma
38
Correctness of Fragmentation Correctness of Fragmentation
Recostruction: we must be able to reconstruct the entire R from fragments. Disjointness: if data item x appears in fragment ri, then it should
not appear in any other fragment.
For horizontal fragmentation is union operation.
R = r1 ∪ r2 ∪ … ∪ rn,
Exception: vertical fragmentation, where primary key attributes
must be repeated to allow reconstruction.
For vertical fragmentation is natural join operation.
R = r1 >< r2 >< … >< rn,
To ensure reconstruction we have to include primary key attributes in all
For horizontal fragmentation, data item is a tuple
fragments. For vertical fragmentation, data item is an attribute.

COMP 302 V. Tamma COMP 302 V. Tamma


39

Correctness of Horizontal Fragmentation Correctness of Vertical Fragmentation


Relation: Sells(pub, address,price,type) type={Bitter, Lager} Relation: Bars(name,address,licence,employees,owner)
Fragments: Fragments:
• SellsBitter= σtype = “bitter”(Sells) • r1 =Πname,address,licence (Bars)
• SellsLager= σtype = “lager”(Sells) • r2 = Πname,address,employees,owner(Bars)

Correctness rules Correctness rules


• Completeness: Each tuple in the relation appears either in SellsBitter, or • Completeness: Each attribute in the Bars relation appears either in r1 or in r2
in SellsLager • Reconstruction: The Bars relation can be reconstructed from the fragments
Bars = r1 >< r2
• Reconstruction: The Sells relation can be reconstructed from the
fragments • Disjointness: The two fragments are disjoint, except for the primary key, name,
Sells = SellsBitter ∪ SellsLager which is necessary for reconstruction
• Disjointness: The two fragments are disjoint, there can be no beer that is
both “Lager” and “Bitter”

COMP 302 V. Tamma


43 COMP 302 V. Tamma
43
Exercise settings Exercise 1
Let us consider the following relation:
• For this exercise you will work in groups of 3 or 4
people Property-for-Rent(property-id, type, address, rent,
• You will have 10 minutes to work out the solution to the owner-id)
problem with your colleagues
• After that, you will have 5 minutes to compare your If we assume that there are only two possible property types, Flat and
solution with the one of your neighbours House, determine the horizontal fragmentation of the relation. Check
the correctness of the fragmentation schema against the three
correctness principles

COMP 302 V. Tamma COMP 302 V. Tamma

Solution ex 1 Multi-level Transaction Model


Assuming that there are only two property types, the horizontal
Closed nested transaction - atomicity enforced at the top-level.
fragmentation of PropertyForRent can be obtained as follows:
Open nested transactions - allow partial results of subtransactions
to be seen outside transaction.

Saga model is example of open nested transaction.


The fragmentation satisfies the correctness rules: So is multi-level transaction model where tree of subtransactions is
– Completeness: Each tuple in the relation appears in either balanced.
fragment F1 or F2; Nodes at same depth of tree correspond to operations of same
– Reconstruction: The PropertyForRent relation can be level of abstraction in DBMS.
reconstructed from the fragments using the union operation, thus:
F1 ∪ F2 = PropertyForRent;
– Disjointness: The fragments are disjoint; there can be no property
type that is both ”House” and ”Flat”;
COMP 302 V. Tamma COMP 302 V. Tamma
Multi-level Transaction Model Example - Multi-level Transaction Model

Edges represent implementation of an operation by


Schedules NON
sequence of operations at next lower level. conflict
serializable
Traditional flat transaction ensures no conflicts at
lowest level (L0).
In multi-level model two operations at level Li may
not conflict even though their implementations at
next lower level Li-1 do.

COMP 302 V. Tamma COMP 302 V. Tamma

Example - Multi-level Transaction Model Exercise 2


Consider the schedule given below. Determine if this schedule is conflict
T7: T71, which increases balx by 5 serializable, and divide the transactions in the schedule into subtransactions
that can be executed concurrently while generating the correct result.
T72, which subtracts 5 from baly
Time Transaction 1 Transaction 2
T8: T81, which increases baly by 10 T1 begin_transaction
T82, which subtracts 2 from balx T2 read(balx)
T3 balx = balx +100
T4 write(balx) begin_transaction
As addition and subtraction commute, can execute T5 read(balx)
these subtransactions in any order, and correct T6 balx = balx *1.1
T7 write(balx)
result will always be generated. T8 read(baly)
T9 baly = baly *1.1
T10 write(baly)
T11 read(baly) commit
T12 baly = baly - 100
T13 write(baly)
COMP 302 V. Tamma COMP 302 V. Tamma
T14 commit
Solution ex 2 Solution ex 2
The precedence graph looks like A possible division into sub transaction is the following
Time Transaction 1 .1 Transaction 2.1
T1 begin_transaction
T2 read(balx)
T3 balx = balx +100
T4 write(balx) begin_transaction
T5 commit read(balx)
T6 balx = balx *1.1
T7 write(balx)
T8 commit
• The schedule is not conflict serialisable
T9
T10 Transaction 2.2
T11 begin_transaction
T12 Transaction 1.2 read(baly)
T13 begin_transaction baly = baly *1.1
T14 read(baly) write(baly)
T15 baly = baly - 100 commit
COMP 302 V. Tamma COMP 302T14 write(baly) V. Tamma
T15 commit

Solution ex 2
Since addition, subtraction and multiplication are commutative, then we can
execute the transactions in any order and the correct result will always be
generated

COMP 302 V. Tamma

S-ar putea să vă placă și