del 2

Lagringsstrukturer och åtkomstmetoder
 Hur innehållet i databasen lagras på disk och vilka åtkomstmetoder
som används är väldigt viktigt för systemets prestanda.
 Det viktigaste skälet är att det går mycket långsamt att överföra data
från sekundärminne till primärminne.
 Målet är därför att försöka minimera antalet diskaccesser ( I/Ooperatione)
Exempel på lagringsstrukturer





Sekventiell lagring
Indexering
Hashing
B-träd
Pekarkedjor
Ingen enskild lagringsstruktur är optimal för alla applikationer, utan de
är alla bra för vissa och dåliga för andra applikationer.
1
Lagrad post
Returneras
lagrad sida
returneras
Filhanterare
DBHS
Ber om en
Lagrad post
Data läses
från disken
Diskhanterare
ber om en
lagrad sida
Databas
ber om data från
en fysisk diskadress
1. DBHS bestämmer vilken lagrad post som behöver hämtas och ber
filhanteraren att hämta den posten.
2. Filhanteraren i sin tur bestämmer vilken sida som den önskade posten
finns på och ber diskhanteraren att hämta den sidan
3. Diskhanteraren bestämmer sidans fysiska adress och ber om data från
den adressen.
4. Diskhanteraren läser data från disken.
5. Den lagrade sidan returneras till filhanteraren.
6. Den lagrade posten returneras till DBHS.
2
Clustering
Tekniken att försöka lagra poster som är logiskt relaterade (och därför
ofta används tillsammans ) fysiskt nära varandra på disken kallas
clustering
Clustering är extremt viktigt för att få en bra prestanda i systemet.
Clustering kan tillämpas intra-file, d v s på poster i samma fil, eller interfile, d v s på poster från olika filer.
Ett bra DBHS skall tillåta DBA att specificera olika typer av clustering
för olika filer.
Denna specifikation skall också kunna ändras om systemet får andra
prestandakrav, utan att några applikationer påverkas
( dataoberoende ! )
3
Indexering
Filen City (index)
Filen Suppliers (data)
Athens
S1
Smith
20
London
London
S2
Jones
10
Paris
London
S3
Blake
30
Paris
Paris
S4
Clark
20
London
Paris
S5
Adams
30
Athens
Filen City kallas för ett index till filen Suppliers, och filen Supplier sägs
vara indexerad av filen City.
Fältet City i filen Suppliers kallas det indexerade fältet.
Om det indexerade fältet är en primärnyckel, kallas indexet ibland för ett
primärindex eller ett unikt index.
Fördelar
- Index gör att det går snabbare att hämta data från disk
( speciellt
om det kan ligga i primärminnet ).
- Vissa frågor kan besvaras utan att den indexerade filen behöver
accessas.
Nackdelar
- Mer diskutrymme krävs.
- Uppdateringar blir långsammare.
En given fil kan ha ett eller flera index. En fil med ett index för varje fält
kallas ibland för fullt inverterad.
Indexering (forts)
4
Det är också möjligt att konstruera ett index på kombinationer av fält:
Ex.
Athens/30
S1
Smith
20
London
London/20
S2
Jones
10
Paris
London/20
S3
Blake
30
Paris
Paris/10
S4
Clark
20
London
Paris/30
S5
Adams
30
Athens
5
Dense och Nondense indexering
De index vi har tittat på hittills har varit dense, dvs varje post i filen har
varit indexerad.
Om en fil är lagrad sekventiellt på disken kan det ibland räcka med att ha
ett index på filens olika sidor (pages).
S2
S1 Smith
20 London
Page p-1
S4
S2 Jones
10 Paris
S5
S3 Blake
30 Paris
Page p
S4 Clark
20 London
S5 Adams
30 Athens
Page p+1
Ett sådant index sägs vara nondense (eller ibland sparse).
6
Hashing
Hashing är en teknik som ger snabb direktaccess till en specifik post i en
fil.
Varje post lagras på en adress i databasen som beräknas utifrån någon
funktion (hash-funktionen) av något fält i posten. Den beräknade
adressen kallas hashadressen.
Ex.
Anta att:
(a) S# kan anta värdena S100, …, S900 (10st)
(b) Varje post behöver en egen sida
Hashfunktion
Hashadress = resten efter att ha dividerat den numeriska delen av S# med
13.
Denna funktion kan ge 13 olika adresser. Det är vanligt att ge möjlighet
till fler adresser (ca 20%) än vad som utnyttjas (för framtida utökning).
Nackdelar
- posterna lagras inte i någon logisk sekvens
- det kan finnas "gap" av olika storlek mellan posterna
- två poster kan kollidera (hasha till samma adress). Detta kan lösas
genom att göra hashadressen till en startadress för n poster. De poster
som ändå kolliderar lagras på en overflow page.
En annan nackdel med hashing är att när filstorleken ökar, så kommer
också antalet kollisioner att öka. Det betyder att den genomsnittliga
accesstiden också kommer att öka efter hand. Efter ett tag kanske det blir
nödvändigt att strukturera om hela filen, d v s ladda om filen med en ny
hashfunktion.
7
B-träd
 Ett B-träd är ett speciellt sorts träd-strukturerat index
 De flesta relationsdatabaser använder B-träd som sin huvudsakliga
lagringsstruktur
 B brukar sägas stå för balanserat, d v s alla lövnoderna befinner sig på
samma nivå i trädet
 Detta gör att accesstiderna blir förutsägbara
Ett B-träd består av två delar, sekvensmängden (the sequence set) och
indexmängden (the index set)
Sekvensmängden
Sekvensmängden består av ett enkelt index (på en nivå) till de lagrade
posterna. Sekvensmängden ger en snabb sekventiell access till de
indexerade posterna
Indexmängden
Indexmängden är ett träd-strukturerat index till sekvensmängden. Den
översta nivån i trädet består av en ensam nod, roten. Indexmängden ger
snabb direktaccess till sekvensmängden.
Kombinationen av en indexmängd och en sekvensmängd kallas ofta för
ett B+ -träd.
8
Tumregler för indexering

Indexera alltid primärnyckeln

Inga sekundära index i små relationer

Indexera attribut som ofta används som söknyckel

Indexera främmandenycklar som används ofta

Undvik att indexera attribut och relationer som uppdateras ofta

Undvik att indexera attribut som består av långa teckensträngar
9
Exempel på B-Träd - (Knuth's variant B+)
B-Träd är index (följaktligen objekt) med vissa egenskaper.
P1
K1 P2
K2
K = key
P = pointer
P3
För ett B-Tree med grad m där m är antalet "pekare" i varje nod d v s
*NB*
varje index set nod är av formen (P1, K1, P2, K2, P3)
som skall tolkas (här) som:
för att finna x:
K1 
K2 
x
x
x
<
<
K1 => följ P1
K2 => följ P2
=> följ P3
För att strukturen skall vara ett B-Träd, så måste det ha följande
egenskaper:
(1) Varje nod har mellan m/2 och m barn (m >= 3) med undantag för
roten.
(för grad 3 => mellan 2 & 3 barn)
(2) Alla löv är på samma nivå.
(balanserat, d v s på samma djup från roten)
(3) Ett barn som inte är ett löv, och som själv har n barn, kommer att ha
(n-1) nycklar
10
För att bygga ett B-Tree:
Värden läggs till lövnoderna vilket kan orsaka värden (nycklar) att
propagera uppåt, vilket i värsta fall kan splittra roten och skapa en ny
rot. I så fall har trädets djup ökat med 1.
*NB*
i det fall vi också använder ett sequence set (som innehåller
nyckelvärden och pekare (referenser) till data pages i
datafilen - är det en speciell variant av ett B-Tree Knuths variant, B+ Träd (uttalas B plus träd)
ex. lägg till nycklar i den här ordningen:
25, 36, 9, 4, 100, 225, 121, 144, 169, 196,
256, 16, 81, 64, 1, 49
från det tomma trädet till det första värdet (träd av graden 3)
11
25
ROOT (& LEAF)
INDEX SET
SEQUENCE SET
25
ref to data
add 36
25
ROOT (& LEAF)
25
INDEX SET
SEQUENCE SET
36
ref to data
add 9
25
ROOT (& LEAF)
36
9
25
ref to data
ref to data
INDEX SET
SEQUENCE SET
12
add 4 (note that 9 is shifted)
25
4
9
ROOT (& LEAF)
25
ref to data
INDEX SET
SEQUENCE SET
36
ref to data
add 100
25
4
9
ref to data
ROOT (& LEAF)
25
36
100
INDEX SET
SEQUENCE SET
ref to data
13
add 225 but where? now we must split and promote a value from the sequence set
25
9
4
ROOT (& LEAF)
25
ref to data
36
INDEX SET
SEQUENCE SET
100
ref to data
"temporary" working node
36
25
100
36
25
100
225
now split this to produce (and NOTE that we promote 100 to the index set)
36
25
100
225
25 100
4
9
ref to data
25
36
ref to data
ROOT (& LEAF)
100
INDEX SET
225
ref to data
SEQUENCE SET
NOTE THAT a new value (100) has been added to the index set and the node is now full
14
to simplify the remainder of the example we can redraw the B-Tree as:
25 100
4
9
25
36
100 225
The lowest level is the SEQUENCE SET (references to the data are assumed)
However the B-Tree proper is really the index set and the rules (1-3) apply
to this structure (check at each stage to ensure these rules apply)
add 121
4
25 100
9
25
36
100 121 225
15
add 144 again note that this will cause a split and promotion (144)
100 121 144 225
144 225
100 121
this in turn will result in a split and promotion in the index set node
and the promotion of a value (100) to the next level above to create a new root
Note that the "middle" value is the one promoted in the INDEX SET after the split
100
temporary node
25 100 144
25
144
100
25
4
9
144
25
36
100 121
144 225
16
Now the B-Tree has become deeper (but is still balanced) and the three rules still apply
CHECK THIS!
(1) Every node has between m/2 and m children (m •3) except the root
(2) All leaves are at the same level (balanced)
(3) A non-leaf child with n children will contain (n-1) keys
ROOT
100
25
9
4
LEAF
NODES
144
25
36
144 225
100 121
SEQUENCE SET
add 169 (remember that the SEQUENCE SET must remain ordered
100
25
144
9
4
25
36
100 121
144 169 225
add 196 (which means promoting a value (196) to the INDEX SET
144 169 196 225
144 169
196 225
100
25
4
9
144 196
25
36
100 121
196 225
17
144 169
add 256 (note NO splits NO promotions)
100
25
4
9
144 196
25
36
100 121
196 225 256
144 169
add 16 (note NO splits NO promotions)
100
25
4
9
16
144 196
25
36
add 81 (note NO splits NO promotions)
100 121
196 225 256
144 169
18
100
25
4
9
144 196
16
25
36
81
100 121
196 225 256
144 169
add 64 (note 64 promoted to index set)
100
25 64
4
9
16
144 196
64
25
100 121
81
36
196 225 256
144 169
add 1 (note split in the SEQUENCE SET with promotion (9) to the INDEX SET
(split and promotion (25) in the INDEX SET new value promoted to the root)
1
4
9
25 64
9
16
1
9
4
9
64
16
promote 25
19
25 100
1
4
25
9
144 196
64
9
36
100 121
16
64
196 225 256
144 169
81
add 49 (note NO splits NO promotions)
25 100
1
4
25
9
16
144 196
64
9
36
49
100 121
64
81
196 225 256
144 169
20
NOTERA: B+Trädet (Knuths variant) är ett specialfall av B-Träd
Förflyttning av värden från SEQUENCE SET skall ses som att de läggs
till INDEX SET. När värden läggs till index set (och B-träd generellt),
om noden är full, delas den och en temporär nod skapas och (vanligtvis)
förflyttas mittenvärdet i den temporära noden (d v s läggs till nivån
ovanför - vilket kan förorsaka fler delningar och förflyttningar, och leda
till att en ny ROT skapas i värsta fall).
1
12
18
1
12 18
37
40
+ 42
1
12 18
37
40 42
ex.
40 42
plus förflyttningen av 37 till nästa nivå. Om den ursprungliga noden var
rot, så skapas en ny rot vilket ger följande:
21
37
1
12
18
40
42
NOTERA att de tre reglerna fortfarande gäller.
(1) Varje nod har mellan m/2 och m barn (m >= 3) med undantag för
roten.
(2) Alla löv är på samma nivå.
(balanserat d v s på samma djup från roten)
(3) Ett barn som inte är ett löv, och som själv har n barn, kommer att ha
(n-1) nycklar
22
Återhämtning (Recovery)
Med återhämtning i ett databassystem menas återställandet av
databasen till ett konsistent tillstånd efter det att något fel (t ex en
krasch)medfört att databasen hamnat i ett (misstänkt) inkonsistent
tillstånd.
För att databasen skall kunna återhämtas krävs att all information den
innehåller kan rekonstrueras från någon annan information, lagrad
någon annanstans i systemet.
Återhämtning kan ske på tre nivåer:
 Transaktionsåterhämtning
 Systemåterhämtning
 Mediaåterhämtning
23
Transaktioner
En transaktion är en mängd operationer, utförda i sekvens, som
tillsammans bildar en logisk enhet.
Ex.
BEGIN TRANSACTION ;
INSERT ( { S#: 'S5', P#: 'P1', QTY:1000 } ) INTO SP ;
IF any error occurred THEN GO TO UNDO ;
UPDATE P WHERE P# = 'P1' TOTQTY := TOTQTY + 1000;
IF any error occurred THEN GO TO UNDO ;
COMMIT TRANSACTION ;
GO TO FINISH ;
UNDO : ROLLBACK TRANSACTION ;
FINISH : RETURN ;
En transaktion förflyttar databasen från ett konsistent tillstånd till ett
annat konsistent tillstånd, men garanterar inte konsistens under tiden
transaktionen utförs.
24
Transaktionshanteraren
Transaktionshanterarens uppgift är att se till att transaktioner antingen
utförs i sin helhet eller inte utförs till någon del.
Två operationer behövs för att klara detta:
 COMMIT TRANSACTION betyder att transaktionen utförts i sin
helhet på ett korrekt sätt och att databasen nu är i ett konsistent
tillstånd. Uppdateringar som gjorts kan nu göras permanenta.
 ROLLBACK TRANSACTION betyder att något har gått fel och att
databasen kan befinna sig i ett inkonsistent tillstånd. Uppdateringar
som gjorts måste "spolas tillbaka".
För att kunna "spola tillbaka" måste systemet ha en logg som bokför
detaljer om alla uppdateringar.
Transaktionsåterhämtning
Vid COMMIT etableras en commit point (ibland kallad syncpoint).
Vid varje commit point:
1. Alla uppdateringar sedan föregående commit point görs permanenta.
Dessa uppdateringar har innan bara varit provisoriska.
2. All databaspositionering försvinner och alla lås som finns på tupler
frigörs.
25
Om en transaktion har slutförts och COMMIT har gjorts, skall systemet
garantera att dess uppdateringar är permanent gjorda i databasen, även
om systemet kraschar i nästa ögonblick.
För att klara detta måste uppdateringar skrivas till loggen innan
COMMIT kan slutföras (the write-ahead log rule.)
Transaktioner har fyra viktiga egenskaper:




Odelbarhet: Transaktioner är atomära (allt eller inget)
Konsistens: Transaktioner bevarar databasens konsistens
Isolering: Transaktioner är isolerade från varandra.
Varaktighet: När en transaktion har gjort commit, så är dess
uppdateringar permanenta, även om systemet senare kraschar.
26
Systemåterhämtning
Ett system måste också kunna återhämta sig från "globala" fel, d v s fel
som påverkar alla pågående transaktioner (t ex ett strömavbrott).
Sådana fel kan delas upp i två kategorier:
 Systemfel: Påverkar alla pågående transaktioner, men skadar inte
databasen fysiskt. Ett systemfel kallas ibland en mjuk krasch.
 Mediafel: Skadar hela eller delar av databasen fysiskt. Ett mediafel
kallas ibland för en hård krasch.
Problemet vid systemfel är att innehållet i primärminnet försvinner. När
systemet startas om måste de transaktioner som inte gjort COMMIT
"spolas tillbaka" och de som gjort COMMIT ( men inte fått sina
uppdateringar skrivna till databasen ) måste göras om.
Med vissa bestämda mellanrum gör systemet en avstämning, en
checkpoint.
En checkpoint innefattar:
(a)
(b)
Att fysiskt skriva innehållet i databas-buffertarna till disk
Att fysiskt skriva en speciell checkpoint record, en lista på alla
pågående transaktioner, till loggen
27
Ex.
Tid
tc
tf
T1
T2
T3
T4
T5
Checkpoint
Systemfel
Vid omstart av systemet
1. Börja med två listor, UNDO-listan och REDO-listan. På UNDO-listan
skall alla transaktioner finnas som pågick vid senaste checkpoint.
REDO-listan är tom.
2. Börja vid senaste checkpoint och sök igenom loggen.
3. Om en BEGIN TRANSACTION hittas för en transaktion T, lägg till
T i UNDO-listan.
4. Om en COMMIT hittas för en transaktion T, flytta T från UNDOlistan till REDO-listan.
5. När slutet på loggen har nåtts finns de transaktioner som skall "spolas
tillbaka" på UNDO-listan och de som skall göras om på REDO-listan
Systemet arbetar sig nu tillbaka genom loggen och spolar tillbaka
transaktionerna på UNDO-listan; sen arbetar den sig framåt igen och gör
om alla transaktioner på REDO-listan.
28
Mediaåterhämtning
Ett mediafel är ett fel där någon del av databasen har blivit skadad
fysiskt.
För att återhämtning från ett sådant fel skall kunna göras måste
databasen laddas om från en backup-kopia (dump).
Efter det måste alla transaktioner som har gjort COMMIT sedan den
senaste backup-kopian togs göras om.
Two-Phase Commit
Two-phase commit används om en given transaktion involverar flera
"resurshanterare", t ex i ett distribuerat databassystem,.
Om en transaktion uppdaterar två olika databaser, får det inte hända att
uppdateringar görs i den ena databasen men inte i den andra.
En komponent i systemet, koordinatorn, har som uppgift att garantera att
båda databaserna utför samma operation (båda gör COMMIT eller båda
gör ROLLBACK), även om systemet kraschar mitt i processen.
29
Om koordinatorn bestämmer att operationen skall vara COMMIT gås
följande två faser igenom:
1. Koordinatorn instruerar alla resurshanterare att göra sig klara för att
avsluta transaktionen. Det betyder att alla deltagare i processen måste
skriva all information de har om transaktionen till loggen. Om detta
gick bra, svarar resurshanteraren "OK", annars "not OK" till
koordinatorn.
2. När koordinatorn har fått svar från alla deltagare, skriver den sitt
beslut till sin egen logg. Om alla svar var "OK" blir beslutet
"commit", annars blir det "rollback". Koordinatorn informerar sedan
alla deltagare om sitt beslut, vilket de alla måste rätta sig efter.
Om systemet kraschar mitt i processen, letar omstartproceduren efter
koordinatorns beslut i loggen. Om den hittar det, kan processen fortsätta
där den slutade. Om inte, så antas beslutet ha varit "rollback".
30
Concurrency
Concurrency existerar i ett system som tillåter flera transaktioner att
operera på samma data samtidigt.
I ett sådant system behövs någon form av kontrollmekanism som ser till
att dessa transaktioner inte blandar sig i varandras operationer, d v s att
konsistensen i databasen bevaras.
Tre huvudsakliga problem finns:
 Problemet med förlorade uppdateringar
 Problemet med beroendet av icke permanenta uppdateringar
 Problemet med inkonsistenta analyser
31
Problemet med förlorade uppdateringar
Transaktion A
HÄMTA P
UPPDATERA P
-
Tid
t1
t2
t3
t4
Transaktion B
HÄMTA P
UPPDATERA P
Vid tiden t4 uppdaterar transaktion B tupeln P utan att ens veta om
transaktion A:s uppdatering. Transaktion A:s uppdatering går här
förlorad.
32
Problemet med beroendet av icke permanenta uppdateringar
Transaktion A
HÄMTA P
-
Tid
t1
t2
t3
Transaktion B
UPPDATERA P
ROLLBACK
Transaktion A ser här en uppdatering på P som ännu inte har gjorts
permanent, d v s transaktion B har inte gjort COMMIT.
Transaktion A
UPPDATERA P
-
Tid
t1
t2
t3
Transaktion B
UPPDATERA P
ROLLBACK
Transaktion A uppdaterar här ett värde som aldrig har existerat!
33
Problemet med inkonsistenta analyser
Konto 1
40
Konto 2
50
Transaktion A
Tid
HÄMTA konto 1
t1
Sum = 40
HÄMTA konto 2
t2
Sum += 90
t3
t4
t5
t6
t7
HÄMTA konto 3
t8
Sum += 110 (fel!!)
Konto 3
30
Transaktion B
HÄMTA konto 3
UPPDATERA konto 3
30 -> 20
HÄMTA konto 1
UPPDATERA konto 1
40 -> 50
COMMIT
Transaktion A ser här ett inkonsistent tillstånd av databasen och gör
därför en inkonsistent analys vid t8.
34
Låsning
Dessa tre problem kan lösas med en teknik som kallas låsning.
När en transaktion vill försäkra sig om att ett objekt (t ex en tuple) inte
ändrar sig så fort den vänder ryggen till, skaffar den sig ett lås på det
objektet.
Exempel på låsning
 Vi antar att det finns två olika sorters lås, exklusiva lås (X-lås), och
delade lås (S-lås).
 Om en transaktion A har ett X-lås på tupeln p, kommer en begäran
från en annan transaktion om ett lås av någon typ på den tupeln att bli
avslagen
 Om en transaktion A har ett S-lås på tupeln p så:
a) En begäran om ett X-lås på p från någon annan transaktion kommer
att bli avslagen.
b) En begäran om ett S-lås på p från någon annan transaktion kommer
att bli beviljad.
X
S
-
X
N
N
Y
S
N
Y
Y
Y
Y
Y
35
Protokoll för data-access
1. En transaktion som vill hämta en tuple måste först skaffa ett S-lås
på den tupeln
2. En transaktion som vill uppdatera en tuple måste först skaffa ett Xlås på den tupeln
3. Om en begäran om ett lås från en transaktion B blir avslagen,
därför att den är i konflikt med ett lås som A redan har, går B in i
vänteläge.
4. Låsen innehas vanligtvis tills slut-på-transaktion (COMMIT eller
ROLLBACK)
Transaktion A
HÄMTA P
(skaffar S-lås på P)
UPPDATERA P
(begär X-lås på P)
vänta
vänta
vänta
vänta
vänta
vänta
Tid
t1
t2
t3
t4
Transaktion B
HÄMTA P
(skaffar S-lås på P)
UPPDATERA P
(begär X-lås på P)
vänta
vänta
vänta
Vi har inga förlorade uppdateringar längre, men har istället fått ett nytt
problem (Vad?)
36
Transaktion A
HÄMTA P
(begär S-lås på p)
vänta
vänta
vänta
HÄMTA p
(skaffa S-lås på p)
-
Tid
t1
t2
t3
Transaktion B
UPPDATERA P
(skaffa X-lås på p)
ROLLBACK
(släpp X-lås på p)
t4
Transaktion A kan nu bara se permanenta värden
37
Konto 1
40
Konto 2
50
Konto 3
30
Transaktion A
Tid
HÄMTA konto 1
t1
(skaffa S-lås på konto1)
Sum = 40
HÄMTA konto 2
t2
(skaffa S-lås på konto2)
Sum += 90
t3
t4
t5
t6
HÄMTA konto 3
t7
(begär S-lås på konto 3)
vänta
Transaktion B
HÄMTA konto 3
(skaffa S-lås på konto3)
UPPDATERA konto 3
(skaffa X-lås på konto3)
HÄMTA konto 1
(skaffa S-lås på konto1)
UPPDATERA konto 1
(begär X-lås på konto1)
vänta
vänta
vänta
vänta
En inkonsistent analys av databasen förhindras, men istället inträffar
deadlock vid tiden t7
38
Deadlock
Deadlock är en situation där två eller flera transaktioner befinner sig i
vänteläge samtidigt, och där varje transaktion måste vänta på att någon
av de andra skall släppa ett lås innan den kan fortsätta.
Två strategier.
Ex 1.
a) Systemet upptäcker cykler i sin Wait-for-Graph (grafen som visar
"vem som väntar på vem")
b) En av transaktionerna i cykeln väljs till offer. Offret måste släppa alla
sina lås och "spolas tillbaka" till början.
c) Offret startas antingen om automatiskt eller så ges bara ett
meddelande till applikationen.
Ex 2.
a) en timeout-mekanism används. Om en transaktion inte har gjort något
vettigt på ett tag, antas det att deadlock har inträffat och transaktionen
startas om.
39
Ekvivalent seriellt schema
En Transaktion består av en mängd operationer utförda i sekvens:
T = (op1, op2,…, opn)
En operation kan antingen vara hämta eller uppdatera.
En transaktion består av ett readset och ett writeset.
Readset: RS(T) = {i1, i2,…, ik}
(Mängden objekt som hämtas från databasen)
Writeset: WS(T) = {i1, i2,…, im}
(mängden objekt som uppdateras i databasen)
En komponent i DBHS, schemaläggaren, bestämmer på vilket sätt
transaktionerna får exekvera.
Hur en mängd transaktioner exekverar under en viss tid kallas för ett
schema.
Ett schema som bevarar databasens konsistens kallas ett giltigt schema.
Ett seriellt schema, d v s ett schema där transaktionerna utförs efter
varandra en i taget, är giltigt.
Ett seriellt ekvivalent schema är ett schema som ger samma resultat som
något seriellt schema skulle ha gjort för samma mängd transaktioner.
Ett schema där flera transaktioner exekverar parallellt är därför giltigt om
det är ekvivalent med något seriellt schema.
40
Ex.
Vi har två transaktioner T1 och T2:
T1 = (Läs S, S := S + 100, Skriv S)
T2 = (Läs P, P := P + 100, Skriv P)
Möjliga scheman
1. ( R1(S), C1(S), W1(S), R2(P), C2(P), W2(P) )
2. ( R2(P), C2(P), W2(P), R1(S), C1(S), W1(S) )
3. ( R1(S), C1(S), R2(P), W1(S), C2(P), W2(P) )
4. ( R2(P), C2(P), R1(S), C1(S), W1(S), W2(P) )
R = Läs; C = ändra; W = skriv
1 och 2 är seriella scheman.
3 och 4 är seriellt ekvivalenta scheman, d v s resultatet blir det samma
som för schemana 1 och 2.
41
Algoritmer för concurrency control CCAs
CCAs måste generera ett schema som är ekvivalent med någon seriell
exekvering av en mängd transaktioner.
seriell exekvering
T1
T2
T3
T4
T5
T6
T7
T8
tid
parallell exekvering
T1 T2
T3
T6 T8
T4 T5 T7
tid
CCAs skall lösa konflikter mellan transaktioner
Två transaktioner sägs vara i konflikt om:
{ RS(T1)  WS(T2) } =  eller
{ WS(T1)  RS(T2) } =  eller
{ WS(T1)  WS(T2) } = 
Konflikter är läs/skriv eller skriv/skriv
42
Ex.
T1 = { Läs S, S := S + 100, Skriv S }
T2 = { Läs S, S := S - 50, Skriv S }
T3 = { Läs P, P := P + 100, Skriv P }
{ RS(T1)  WS(T2) } = S
{ WS(T1)  RS(T2) } = S
{ WS(T1)  WS(T2) } = S
d v s T1 och T2 är i konflikt
{ RS(T1)  WS(T3) } = 
{ WS(T1)  RS(T3) } = 
{ WS(T1)  WS(T3) } = 
T1 och T3 är inte i konflikt (det är inte heller T2 och T3)
Möjligt schema: R2(S), R3(P), C3(P), C2(S), W3(P), W2(S), R1(S),
C1(S), W1(S)
43
Protokollet för two-phase locking ( 2PL )
Teorem: Om alla transaktioner följer protokollet för 2PL, så kommer
alla möjliga scheman vara seriellt ekvivalenta
2PL
1. Innan en transaktion utför en operation på något objekt, måste den
skaffa ett lås på det objektet
2. Efter att ha släppt ett lås, får transaktionen inte försöka skaffa några
nya lås.
växande fasen
krympande fasen
start
commit
slut
Lås skaffas under den växande fasen och släpps under den krympande
fasen (vanligtvis vid COMMIT eller ROLLBACK ).
44
Statisk låsning
Alla lås skaffas innan transaktionen börjar exekvera.
Fördelar: Enkel algoritm, deadlock kan inte inträffa
Nackdelar: Svält kan uppstå, kan vara ineffektiv
Dynamisk låsning
Låsen begärs under exekvering när de behövs
a) Låset beviljat => Trans. fortsätter exekveringen
b) Låset ej beviljat => Trans. får vänta (blockerad)
Om deadlock inträffar blir en transaktion utsedd till offer och startas om
senare.
Två varianter finns:
1.
2.
2PLE - Det finns bara ett sorts lås, exklusiva.
2PLU - Det finns två sorters lås, exklusiva och delade
45
Exempel med 2PLE
Om vi har sex transaktioner:
T1 = ( R(A),
T2 = ( R(D),
T3 = ( R(A),
T4 = ( R(A),
T5 = ( R(C),
T6 = ( R(B),
R(B), W(A), R(C), W(B) )
R(E), W(D), W(E), R(F) )
R(D), W(D), W(A) )
R(B), R(C) )
W(C), R(E), W(E) )
R(F), R(D), W(B), W(D) )
TS = { T1, T2, T3, T4, T5, T6 }
Transaktionsmängd
DB = { A, B, C, D, E, F }
Databas
RS(T1) = {A, B, C }
RS(T2) = {D, E, F }
RS(T3) = {A, D }
RS(T4) = {A, B, C }
RS(T5) = {C, E }
RS(T6) = {B, D, F }
WS(T1) = { A, B }
WS(T2) = { D, E }
WS(T3) = { A, D }
WS(T4) = { }
WS(T5) = { C, E }
WS(T6) = { B, D }
Statisk konfliktanalys
T1
T1
T2
T3
T4
T5
T2
N
T3
Y
Y
T4
Y
N
Y
T5
Y
Y
N
Y
T6
Y
Y
Y
Y
N
46
Möjliga (giltiga) scheman
1. T1, T2, T3, T4, T5, T6 ( i serie)
2. ( T1 // T2 ), ( T3 // T5 ), T4, T6
3. ( T1 // T2 ), T3, T4, ( T5 // T6 )
etc.
Men innan transaktionerna körs, är konflikten bara potentiell.
I dynamiska transaktionshanteringssystem, är det vanligtvis inte känt i
förväg i vilken ordning transaktionerna kommer, så ett schema kan inte
göras upp i förväg.
Transaktionshanteraren måste hålla reda på både de transaktioner och
objekt som finns i systemet, och bevilja och avslå lås på dessa objekt.
Denna information kan finnas i form av en tabell, transaktionstabellen,
plus en wait-for-graph (WFG) för varje resurs.
En transaktion kan befinna sig i tre tillstånd:
r - ready
e - executing
b - blocked
47
Ett möjligt scenario kunde vara:
Låsbegäran
T4 R(A)
T4 R(B)
T6 R(B)
T2 R(D)
T2 R(E)
T4 R(C)
T1 R(A)
T4 COMMIT
Transaktionstabell Wait-for-graph
T4 e
A <- T4
T4 e
A <- T4
B <- T4
T4 e T6 b
A <- T4
B <- T4 <- T6
T4 e T6 b
A <- T4
T2 e
B <- T4 <- T6
D <- T2
T4 e T6 b
A <- T4
T2 e
B <- T4 <- T6
D <- T2
E <- T2
T4 e T6 b
A <- T4
T2 e
B <- T4 <- T6
D <- T2
E <- T2
C <- T4
T4 e T6 b
A <- T4 <- T1
T2 e T1b
B <- T4 <- T6
D <- T2
E <- T2
C <- T4
T6 e
A <- T1
T2 e T1 e
B <- T6
D <- T2
E <- T2
48
T1 R(B)
T5 R(C)
T5 W(C)
T5 R(E)
T6 R(F)
T6 R(D)
T2 W(D)
W(E)
R(F)
T6 e
T2 e
T1 b
T6 e
T2 e
T5 e
T1 b
T6 e
T2 e
T5 b
T1 b
T6 e
T2 e
T5 b
T1 b
T6 b
T2 e
T5 b
T1 b
T6 b
T2 b
T5 b
T1 b
A
B
D
E
A
B
D
E
C
A
B
D
E
C
A
B
D
E
C
F
A
B
D
E
C
F
A
B
D
E
C
F
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<-
T1
T6
T2
T2
T1
T6
T2
T2
T5
T1
T6
T2
T2
T5
T1
T6
T2
T2
T5
T6
T1
T6
T2
T2
T5
T6
T1
T6
T2
T2
T5
T6
<- T1
<- T1
<- T1
<- T5
<- T1
<- T5
<- T1
<- T6
<- T5
<- T1
<- T6
<- T5
<- T2
49
T2 dödas
och startas om
T6 e
T1 b
T5 e
T2 r
T2 R(D)
T6 e
T1 b
T5 e
T2 b
T3 R(A)
T6 e
T1 b
T5 e
T2 b
T3 b
T6 W(B)
W(D)
COMMIT
T1 e
T5 e
T2 e
T3 b
T2 R(E)
T1 e
T5 e
T2 b
T3 b
A
B
D
E
C
F
A
B
D
E
C
F
A
B
D
E
C
F
A
B
D
E
C
<<<<<<<<<<<<<<<<<<<<<<<-
T1
T6
T6
T5
T5
T6
T1
T6
T6
T5
T5
T6
T1
T6
T6
T5
T5
T6
T1
T1
T2
T5
T5
A
B
D
E
C
<<<<<-
T1 <- T3
T1
T2
T5 <- T2
T5
<- T1
<- T1
<- T2
<- T3
<- T1
<- T2
<- T3
50
T1 W(A)
R(C)
T1 b
T5 e
T2 b
T3 b
T5 W(E)
COMMIT
T1 e
T2 e
T3 b
T1 W(B)
COMMIT
T2 e
T3 e
T3 R(D)
T2 e
T3 b
T2 W(D)
W(E)
R(F)
T2 e
T3 b
T2 COMMIT
T3 e
T3 W(D)
W(A)
T3 COMMIT
T3 e
Tom tabell
A <- T1
B <- T1
D <- T2
E <- T5
C <- T5
A <- T1
B <- T1
D <- T2
E <- T2
C <- T1
A <- T3
D <- T2
E <- T2
A <- T3
D <- T2
E <- T2
A <- T3
D <- T2
E <- T2
F <- T2
A <- T3
D <- T3
A <- T3
D <- T3
Tom graf
<- T3
<- T2
<- T1
<- T3
<-T3
<-T3
51
Intentionslås
Hittills har vi utgått ifrån att en enskild tuple är det objekt som vi kan
låsa.
Det är emellertid inget som hindrar att vi kan ha lås för en hel relation,
för hela databasen eller för bara ett enskilt attribut i en specifik tuple.
Storleken på de objekt som går att låsa brukar kallas för granularitet
(kornighet). Ju finkornigare lås, desto fler transaktioner kan exekvera
samtidigt. Ju grovkornigare lås, desto mindre lås behövs och desto
mindre blir overheaden.
Protokollet för intentionslås
Ingen transaktion får skaffa ett lås på en tuple innan den har skaffat sig
ett lås på relationen där den tupeln finns.
För detta ändamål introduceras tre nya lås, ett delat intentionslås (IS), ett
exlusivt intentionslås (IX), och ett delat exlusivt intentionslås (SIX).
52
 IS - Transaktionen T tänker skaffa S-lås på enskilda tupler i R
 IX - Samma som IS, plus att T tänker uppdatera enskilda tupler i R
och därför tänker skaffa X-lås på de tuplerna.
 SIX - T kan tolerera andra läsare, men inte andra som uppdaterar
tupler i R. T tänker uppdatera enskilda tupler i R och därför tänker
skaffa X-lås på de tuplerna.
X
SIX
IX
S
IS
-
X
N
N
N
N
N
Y
SIX
N
N
N
N
Y
Y
IX
N
N
Y
N
Y
Y
S
N
N
N
Y
Y
Y
IS
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
1. Före en given transaktion kan skaffa ett S-lås på en tuple, måste den
först skaffa ett IS-lås eller starkare på relationen som innehåller den
tupeln.
2. Före en given transaktion kan skaffa ett X-lås på en tuple, måste den
först skaffa ett IX-lås eller starkare på relationen som innehåller den
tupeln.
53
Säkerhet
Skillnader mellan säkerhet och integritet:
Säkerhet
Hindra oauktoriserade användare från att läsa, ändra eller radera data.
Integritet
Hindra auktoriserade användare från att lägga till, ändra eller radera data
på ett inkorrekt sätt.
I båda fall måste någon form av restriktioner specificeras(vanligtvis av
DBA) i något språk (DSL) som lagras i katalogen (DD)
Generella Säkerhetsaspekter







lagliga, sociala och etiska aspeker
fysiska kontroller (fysisk åtkomst till maskiner)
policy-frågor - vem skall ha åtkomst till vad
operativa problem
hårdvarukontroller (t ex nycklar, koder, superuser mode)
säkerhet i operativsystemet (vad händer med "använd" data)
säkerhet i databassystemet. Finns "äganderätt" av dataobjekt?
Två metoder för att angripa problemet med datasäkerhet finns;
godtycklig kontroll och obligatorisk kontroll.
54
Godtycklig kontroll
En given användare kan ha olika accessrättigheter på olika objekt. Olika
användare kan också ha olika rättigheter på samma objekt. Godtyckliga
scheman blir därför väldigt flexibla
Obligatorisk kontroll
Varje objekt sätts till en viss klassificeringsnivå och varje användare
tilldelas en viss klareringsnivå. Ett givet objekt kan bara kommas åt av
användare med rätt klareringsnivå. Obligatoriska scheman är därför
jämförelsevis strikta.
DBHS har som uppgift att se till att de säkerhetsbeslut som fattas också
efterlevs.
1. Säkerhetsregler måste definieras i något passande språk och sen
lagras i katalogen.
2. DBHS måste ha metoder för att kontrollera att en viss användare har
tillåtelse att utföra en viss operation på ett visst objekt
3. Systemet måste veta vem användaren är som begär att få utföra en
operation. Detta kan t ex ske med user ID och lösenord.
55
Godtycklig accesskontroll
För att kunna definiera olika säkerhetsregler behövs ett språk som
stödjer sådana regler.
Ex.
CREATE SECURITY RULE SR3
GRANT RETRIEVE (S#, SNAME, CITY ), DELETE
ON S WHERE S.CITY  'London'
TO Jim, Fred, Mary
ON ATTEMPTED VIOLATION REJECT
Säkerhetsregler har oftast fem komponenter:
1. Ett namn (SR3 i det här exemplet) som regeln registreras under i
katalogen
2. En eller flera privilegier (RETRIEVE och DELETE i exemplet), som
specificeras i GRANT-klausulen
3. Regelns räckvidd, specificerad med ON-klausulen
4. En eller flera användare som skall ha de specificerade privilegierna,
specificerat med TO-klausulen
5. En reaktion vid överträdelse.
Vi måste också kunna ta bort existerande säkerhetsregler
DESTROY SECURITY RULE SR3.
56
Exempel
CREATE SECURITY RULE EX1
GRANT RETRIEVE ( S#, SNAME, CITY )
ON S
TO Jacques, Anne, Charley.
Dessa användare kan se en vertikal delmängd av S. Detta är ett exempel
på en värdeoberoende säkerhetsregel.
CREATE SECURITY RULE EX3
GRANT RETRIEVE, INSERT, UPDATE
( SNAME, STATUS ), DELETE
ON S WHERE S.CITY = 'Paris'
TO Dan, Misha.
Dessa användare kan se en horisontell delmängd av S. Detta är ett
exempel på en värdeberoende säkerhetsregel.
CREATE SECURITY RULE EX4
GRANT RETRIEVE ( S#, SNAME )
ON S WHERE S.STATUS > 50
TO Judy, Paul.
Attributet STATUS används här som villkor även fast det inte är synligt
för användarna.
57
Anta att vi har definierat en vy SSQ enligt följande:
CREATE VIEW SSQ AS
SELECT S#, SUM(QTY)
FROM SP
GROUP BY S#
( Varje leverantörs nummer och den totala kvantiteten för varje
leverantör )
CREATE SECURITY RULE EX4
GRANT RETRIEVE
ON SSQ
TO Fidel.
Fidel har bara rättigheter att se viss statistik från basrelationen SP, inte
några detaljer. Detta är ett exempel på hur man kan använda vyer för att
gömma information.
CREATE SECURITY RULE EX5
GRANT RETRIEVE, UPDATE ( STATUS )
ON S
WHERE DAY ( ) IN ( 'mon', 'tue', 'wed', 'thu', 'fri' )
AND TIME ( ) >= '9:00 AM'
AND TIME ( ) <= '5:00 PM'
TO Purchasing.
Detta är ett exempel på en kontextberoende säkerhetsregel.
OBS!!! Allting som inte är uttryckligen tillåtet, är förbjudet.
58
Audit trails
En audit trail är en speciell logg där detaljer om alla operationer som har
utförts registreras.
Information som en audit trail kan innehålla:







Hur operationen såg ut
Från vilken terminal operationen utfördes
Vilken användare som utförde operationen
Datum och tid för operationen
Berörda relationer, tupler och attribut
De gamla värdena
De nya värdena
Obligatorisk accesskontroll
Obligatorisk säkerhetskontroll används i databaser där en strikt
klassificering av data behövs, t ex inom försvaret eller andra statliga
myndigheter.
Varje objekt har en klassificeringsnivå ( topphemligt, hemligt,
konfidentiellt etc ), där nivåerna är strikt ordnade från högre till lägre
nivåer.
Varje användare tilldelas också en av dessa nivåer.
59
Regler
1. Användare i kan se objekt j bara om dess nivå är större eller lika med
klassificeringsnivån på j
2. Användare i kan modifiera objekt j bara om dess nivå är lika med
klassificeringsnivån på j.
DoDs säkerhetsklasser
Det finns fyra säkerhetsklasser: D, C, B och A
Klass D
Systemet erbjuder bara en minimal säkerhet
Klass C
Klass C är uppdelad på två underklasser, C1 och C2.


Klass C1 kräver separation av användare och data,
d v s all data har en eller flera ägare
Klass C2 kräver dessutom att systemet stödjer konton med lösenord,
audit trails och isolering av resurser.
60
Klass B
Klass B är uppdelad på tre underklasser, B1, B2 och B3.



Klass B1 kräver att varje objekt är märkt med dess
klassificeringsnivå. Den kräver också att en säkerhetspolicy finns
informellt definierad
Klass B2 kräver dessutom att en formell säkerhetspolicy finns
definierad. Den kräver också att bakvägar identifieras och
elimineras. En bakväg kan t ex vara möjligheten att sluta sig till ett
svar på en otillåten fråga från svaret på en tillåten.
Klass B3 kräver specifikt stöd för audit trails och återhämtning och
dessutom att en speciell säkerhetsadministratör finns.
Klass A
Klass A, som är den högsta säkerhetsklassen, kräver ett matematiskt
bevis på
a) att säkerhetsmekanismen i systemet är konsistent och
b) att denna säkerhetsmekanism är adekvat för att stödja den
specificerade säkerhetspolicyn.
61
Stöd för säkerhet i SQL
SQL stödjer bara godtycklig säkerhetskontroll. Två oberoende
mekanismer kan användas, vyer och GRANT-uttryck.
Syntax för GRANT
GRANT ALL [ PRIVILEGES ] |
[ SELECT ] [ INSERT ] [ DELETE ]
[ UPDATE [ (kolumnlista) ]
ON tabellnamn
TO namnlista | PUBLIC
[ WITH GRANT OPTION ]
Ex.
GRANT ALL PRIVILEGES
ON cust_table
TO lewis, agganis
WITH GRANT OPTION.
GRANT SELECT, UPDATE (credit_limit)
ON cust_table
TO garcia.
Det går också att dra tillbaka rättigheter med REVOKE.
Ex.
REVOKE DELETE, UPDATE
ON cust_table
FROM jones, brown.
62
Distribuerade System
DB 1
DB 2
DB 3
Communications Network
DB i
DDBHS:
DB j
DB k
ett antal noder där varje nod är ett fristående DB-system
och där noderna är sammankopplade genom ett
kommunikationsnätverk
( homogent / heterogent )
{ DB1, DB2, ..., DBn }
distributionen av data över noderna är "transparent för
användaren"
varje nod:



har en egen databas
lokal DBHS, transaktionshantering (låsning,
logging, återhämtning etc.)
lokal datakommunikations-hanterare(DC man.)
63
Fördelar
 reflekterar den fysiska/geografiska spridningen av
företag/organisationer
 lokal data lagras lokalt, men är tillgänglig globalt (80/20 regeln:
80% av accesserna är lokala/ 20 % globala)
Nackdel
 Distribuerade system är tekniskt komplexa
Den fundamentala principen för distribuerade databaser:
 Ett distribuerat system skall se exakt ut som ett icke-distribuerat
system för användaren
Tolv regler
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
lokal autonomi
inget beroende av en central nod
oavbruten operation
lokalt oberoende
fragmenteringsoberoende
oberoende av kopior
distribuerad behandling av frågor
distribuerad transaktionshantering
hårdvaruoberoende
operativsystemsoberoende
nätverksoberoende
DBHS-oberoende
64
(1)
lokal autonomi




(2)
alla operationer på en given nod kontrolleras av den noden
oberoende av alla andra noder
lokal data ägs och hanteras lokalt
går inte att uppnå till 100%
inget beroende av en central nod
 ingen centraliserad behandling (t ex av frågor eller
transaktionshantering)
 alla noder är jämlika (det finns ingen "master" nod)
 ett system som är beroende av en central nod blir sårbart
 en central nod kan också bli en flaskhals
(3)
oavbruten operation
 inga operationer kräver att systemet tas ner, t ex om noder
kommer till/lämnar DDBHS
En fördel i distribuerade system generellt är att de erbjuder
större pålitlighet och större tillgänglighet.
 Pålitligheten förbättras eftersom systemet kan fortsätta
att fungera även om t ex en enskild nod går ner.
 Tillgängligheten förbättras dels på grund av samma skäl
som ovan och dels på grund av möjligheten att replikera
data.
65
(4)
lokalt oberoende (lokaliseringstransparens)
 användare vet inte på vilken ställe data finns
(det ser ut som om all data är lagrad lokalt (logiskt))
 tillåter data att "migrera" utan att användarna vet om det
(5)
fragmenteringsoberoende
 en (logisk) relation kan delas upp i
(fysiska) "fragment" (horisontellt / vertikalt)
 Det betyder att data kan lagras där det används mest så
att trafiken över nätverket minskas
66
Ex.
FRAGMENT EMP INTO
N_EMP AT SITE 'New York' WHERE DEPT# = 'D1'
OR DEPT# = 'D3',
L_EMP AT SITE 'London' WHERE DEPT# = 'D2' .
Den logiska relationen EMP
EMP#
E1
E2
E3
E4
E5
Fragmentet N_EMP
EMP#
E1
E2
E5
DEPT#
D1
D1
D3
DEPT#
D1
D1
D2
D2
D3
SALARY
40K
42K
30K
35K
48K
Fragmentet L_EMP
SALARY
40K
42K
48K
EMP# DEPT# SALARY
E3
D2
30K
E4
D2
45K
 Detta är ett exempel på horisontell fragmentering, d v s
båda fragmenten är en horisontell delmängd av den
logiska relationen (motsvarar relationsoperationen
SELECT).
 Fragmentering av en relation kan även göras vertikalt
(motsvarar relationsoperationen PROJECT).
 Inga fragment får innehålla samma information.
 PROJECT måste bevara primärnyckeln.
 För att återfå den ursprungliga relationen används
UNION för horisontella fragment och JOIN för
vertikala.
67
 Fragmenteringsoberoende innebär att användare inte ser
att data är fragmenterad, utan arbetar mot de logiska
relationerna.
Ex.
EMP WHERE SALARY > 40K AND DEPT# = 'D1'.
omvandlas till
( N_EMP WHERE SALARY > 40K AND DEPT# = 'D1' )
UNION
( L_EMP WHERE SALARY > 40K AND DEPT# = 'D1' )
optimeraren vet att den andra delen av uttrycket blir en tom
relation och att London därför inte behöver kontaktas.
(6)
oberoende av kopior
 givna relationer (fragment) kan ha en eller flera kopior
på olika ställen (kontrollerad redundans)
 problemet med det här är uppdateringar och spridning av
uppdateringar
 kopiering skall vara transparent för användaren
Ex.
REPLICATE N_EMP
LN_EMP AT SITE 'London' .
REPLICATE L_EMP
NL_EMP AT SITE 'New York' .
London har nu en kopia av fragmentet i New York och vice
versa.
68
(7)
distribuerad behandling av frågor
 kräver datakommunikation för (del)frågor
 kräver optimering över det distribuerade systemet
(problemen liknar de i ett centraliserat system plus
hantering av overheaden från kommunikationen)
(8)
distribuerad transaktionshantering
 "concurrency-kontroll" och återhämtning är mer komplext
i ett distribuerat system
 en transaktion kan medföra att kod från flera noder måste
exekveras - en "transaktionsagent" på varje nod sköter
transaktionshantering lokalt
 "concurrency-kontroll" baseras oftast på låsning
 kommunikations-overhead och fördröjningar är viktigare
(9)
hårdvaruoberoende
*
(10)
DBMS är logiskt oberoende av hårdvaran
operativsystemsoberoende
*
(11)
DBMS är logiskt oberoende av operativsystemet
nätverksoberoende
*
DBMS är logiskt oberoende av nätverket
69
(12)
DBMS-oberoende
*
*
DBMSs kan vara heterogena
DBMS-noder måste stödja samma / ett
gemensamt(standard) interface
Problem i distribuerade system
 huvuduppgiften i ett distribuerat system är
att minimera antalet meddelande och storleken på dem ( i alla
fall i ett WAN)

Detta i sin tur påverkar ett antal områden, bl a
-
behandling av frågor
kataloghantering
spridning av uppdateringar
återhämtning
concurrency-kontroll
Behandling av frågor
 För att minska trafiken över nätverket måste
frågeoptimeringen vara distribuerad. Optimeringen består av
ett globalt optimeringssteg följt av lokala optimeringssteg på
varje nod.
70
Ex.
Databas ( suppliers & parts, förenklad )
S ( S#, CITY )
P ( P#, COLOR )
SP ( S#, P# )
10 000 lagrade tupler på nod A
100 000 lagrade tupler på nod B
1 000 000 lagrade tupler på nod A
Anta att varje lagrad tuple är 200 bits lång
Fråga: Hämta S# för leverantörer i London som levererar
röda delar.
SELECT S.S#
FROM S, P, SP
WHERE S.CITY = 'London'
AND S.S# = SP.S#
AND SP.P# = P.P#
AND P.COLOR = 'Red' .
Uppskattad kardinalitet hos vissa temporära resultat:
Antalet röda delar
=
10
Antalet leveranser av leverantörer i London = 100 000
Antaganden om kommunikationen
Datahastighet
Fördröjning
= 50 000 bits/sekund
= 0.1 sekund
Total kommunikationstid
T[i] = total fördröjning + ( total datavolym / datahastighet )
71
Fyra strategier
1. Flytta relationen P till nod A och exekvera frågan där
T[1] = 0.1 + ( 100 000 * 200 ) / 50 000
 400 sek ( ca 6.67 min )
2. Flytta S och P till nod B och exekvera frågan där
T[2] = 0.2 + ( ( 10 000 + 1 000 000 ) * 200 ) / 50 000
 4040 sek ( ca 1.12 timmar )
3. För varje röd del, kolla om det finns någon leverantör i
London
T[3] = ( 0.1 * 20 ) + ( 200 * 20) / 50 000
 ca 2 sek
4. Flytta röda delar till A
T[4] = 0.1 + ( 10 * 200 ) / 50 000
 ca 0.1 sek
 Datahastighet och fördröjning är båda viktiga faktorer när
man väljer en strategi
 Beräkningar och disk-accesser kanske eller kanske inte är
försumbara i sammanhanget !
72
Kataloghantering

centraliserad

"fullt" kopierad -


partitionerad
centraliserad +
partitionerad
-
-
en version av den globala katalogen
på en central nod
varje nod har en kopia av den
globala katalogen
varje nod har en lokal katalog
kombination av två tekniker
(lokal + en central global kopia)
Spridning av uppdateringar
Problemet med att ha flera kopior av samma data är att
uppdateringar måste spridas till alla kopiorna
Schemat med en primärkopia
 en kopia av ett objekt får vara den primära kopian
(alla andra är sekundära)
 primärkopior av olika objekt finns på olika noder
 en uppdatering är klar så fort som primärkopian har
uppdaterats. Noden som har primärkopian måste senare
sprida uppdateringen till alla noder med sekundära kopior
( helst före COMMIT )
Återhämtning
 baseras på "the two phase commit protocol" (2PC)
 en nod måste få rollen som koordinerande nod
(typiskt den nod som initierar transaktionen )
 2PC kräver mycket overhead på meddelanden
 den lokala autonomin försvinner (till viss del)
73
Concurrency-kontroll
 i ett distribuerat system krävs meddelanden för att skaffa,
släppa och testa lås
 Om en transaktion behöver uppdatera ett objekt som det
finns kopior av på n noder, kan detta faktiskt kräva 5n
meddelanden:- n begäran om lås
- n beviljande av lås
- n uppdateringar
- n ackar
- n begäran om att släppa lås
 en vanlig lösning är "primärkopia-strategin"
 En "global deadlock" kan vara svår att upptäcka
Heterogena system& Gateways
 Gränssnittsprogram krävs ("gateways") mellan två
olika databassystem
 standardprotokoll för nätverk kan användas
DBMS X
=> standardform
=> DBMS Y
 mappningar krävs för objekt som datatyper,
SQL "dialekter", feedbackinformation, DD (data dictionary),
begäran av lås, hantering av återhämtning (!), etc.
 heterogena system kan också innehålla en mix av relationsoch icke-relationssystem (väldigt problematiskt!)
74
Client/Server-system
 Ett client/server-system kan ses som ett enkelt specialfall av ett
distribuerat system.
a)
b)
c)
d)
vissa noder är client-noder och andra är server-noder
all data finns på server-noderna
alla applikationer exekverar på client-noderna
"sömmarna" syns
Standarder för client/server-system
 SQL/92 stödjer operationerna CONNECT och DISCONNECT
för att koppla upp och bryta client/server-förbindelser
 Remote Data Access (RDA) är en standard som definierar format
och protokoll för client/server-kommunikation (finns för
närvarande bara för OSI )
 Distributed Relational Database Architecture (RDBA) är en IBMstandard som liknar RDA i mångt och mycket, men är mer
generell.
75
Inbäddad SQL och SQL API:s
SQL kan, förutom att användas interaktivt, också anropas från något
proceduriellt programspråk. Detta kan göras på två olika sätt:
1. Med hjälp av inbäddade SQL-uttryck. SQL-uttryck blandas med
uttryck i värdspråket direkt i källkoden. En speciell förkompilerare
behövs som byter ut SQL-uttrycken mot anrop till funktioner i DBHS.
2. Med hjälp av ett Application Programming Interface (API).
Programmeraren har tillgång till en mängd funktioner (ett bibliotek)
som används för att anropa databasen. Ett API ger samma
funktionalitet som inbäddade uttryck men ingen förkompilering
behövs.
De flesta databas-tillverkare har någon form av stöd för inbäddad SQL, t
ex INGRES, ORACLE, Informix och DB2. Vissa (t ex ORACLE) har
också ett API.
76
/* program to create the viewing table */
#include <stdio.h>
#include <stdlib.h>
EXEC SQL INCLUDE sqlca;
main()
{
/* Connect to database */
EXEC SQL CONNECT 'estatedb';
if(sqlca.sqlcode < 0) exit(-1);
/* Display message for user and create the table */
EXEC SQL CREATE TABLE viewing
(pno varchar(5) not null,
rno varchar(5) not null,
date date
not null,
comment varchar(40) );
/* Check success */
if(sqlca.sqlcode >= 0 )
printf("Creation successful\n");
else
printf("Creation unsuccessful\n");
/*Commit the transaction */
EXEC SQL COMMIT;
/*Finally, disconnect from the database */
EXEC SQL DISCONNECT;
}
77
The Open Database Connectivity (ODBC) Standard
 Ett problem med de olika databasernas API:n är att de inte är
kompatibla med varandra. Detta betyder att om en applikation skall
kunna köras mot flera olika databaser, så måste en version för varje
databas skrivas.
 För att råda bot på detta utvecklades ODBC (av Microsoft). ODBC
ger ett gemensamt gränssnitt för att accessa heterogena databaser.
Detta betyder att en applikation kan köras mot flera olika databaser
utan att koden behöver ändras.
 ODBC håller på att bli en de facto standard i industrin. Några skäl till
varför ODBC är så populärt är att:
- Applikationer blir inte bundna till en speciell databas-tillverkare
- Applikationer kan ignorera det underliggande kommunikationsprotokollet
- ODBC är designat för att passa ihop med existerande standarder
(X/Open och CLI)
- Det är möjligt att accessa mer än 50 av de mest populära
databaserna m h a ODBC idag
78
ODBC - Arkitekturen
Applikation
Applikation
Driver Manager
Driver Manager
Driver
Driver
Driver
Datakälla
Datakälla
Datakälla
Driver
Datakälla
Datakälla
Datakälla
Arkitekturen har fyra komponenter:
 Applikationen, som styr exekveringen och anropar ODBC-funktioner
för att skicka SQL-uttryck till databasen och för att ta emot resultat
från databasen.
 Driver Manager, som laddar drivers åt applikationen.
 Drivern, som exekverar funktionsanropen åt applikationen. Drivern
modifierar anropen så att de får den syntax som stöds av den
underliggande databasen.
 Datakällan, som består av datan som accessas, databasen,
operativsystemet och nätverket (om det finns något).
79
ODBC-gränssnittet
ODBC-gränssnittet innehåller följande delar:
 Ett bibliotek med funktioner som gör det möjligt för applikationen att
koppla upp en förbindelse till en databas, exekvera SQL-uttryck och
hämta resultat.
 En standard för att koppla upp till och logga in på en databas.
 En standard för att representera datatyper.
 En mängd med standardiserade felkoder.
 SQL-syntax som baserar sig på X/Open och CLI-specifikationerna.
80
The World Wide Web
 Webben består av ett nätverk av datorer som kan agera i två roller:
som klienter (bläddrare) eller som servers.
 Exempel på servers är Apache, NCSA HTTPd, Netscape
Communication Server och Microsoft Internet Information Server.
 Exempel på klienter är NCSA Mosaic, Netscape Navigator och
Microsoft Internet Explorer.
 Informationen lagras i dokument som skrivs med språket HTML
(HyperText Markup Language)
 Protokollet som används för att utbyta information mellan klient och
server kallas HTTP (HyperText Transfer Protocol).
 Dokumenten identifieras med hjälp av en adress, en så kallad URL
(Uniform Resource Locator).
81
HTTP och URLs
HTTP
En HTTP-transaktion består av fyra steg:




Uppkoppling - Klienten etablerar en förbindelse med servern.
Fråga - Klienten sänder en fråga till servern.
Svar - Servern sänder ett svar (ett HTML-dokument) till klienten.
Nedkoppling - Servern kopplar ner förbindelsen.
HTTP är ett tillståndslöst protokoll, vilket gör det svårt att stödja
konceptet med sessioner (viktigt för databas-transaktioner).
URLs
 Syntaxen för en URL består av tre grundläggande delar: protokollet
som används vid förbindelsen, datorns namn och sökvägen till den
resurs som efterfrågas.
 Det är också möjligt att specificera till vilken port i datorn
förbindelsen skall kopplas upp till (default 80) och att specificera en
sträng med argument (ett av standardsätten för att skicka data till
servern).
Syntax för en URL
<protocol>:// <host> [:<port>] / absolute_path [? arguments]
82
Statiska och dynamiska Websidor
 Ett HTML-dokument som lagras i en fil är ett exempel på en statisk
websida. Innehållet i dokumentet ändras inte om inte filen själv ändras
 Innehållet i en dynamisk websida ändras varje gång sidan accessas.
Detta innebär att den kan ha egenskaper som en statisk websida inte
har:
- Websidan kan reagera på operationer från användaren (t ex
returnera data när ett formulär har fyllts i eller returnera resultatet
av en databas-fråga)
- Websidan kan skräddarsys för och av varje enskild användare.
 När dokumenten som skall publiceras är dynamiska måste
hypertexten genereras av servern
 För detta ändamål kan man skriva script som översätter olika
dataformat till HTML "on-the-fly".
 Scripten måste förstå frågorna från klienternas HTML-formulär och
även resultaten som genereras av applikationerna som äger datan (t ex
en databas.)
83
Olika Client/Server - arkitekturer
 Dataintensiva (affärs)applikationer består av fyra huvudkomponenter:
databasen, transaktionslogiken, applikationslogiken och
användargränssnittet.
 I ett client/server - system separerar man dessa komponenter i
applikationen på något sätt.
Two-tier arkitektur
 På klienten (tier 1) finns användargränssnittet och det mesta av
applikationslogiken.
 På servern (tier 2) finns en del applikationslogik, transaktionslogiken
och databasen.
 På mitten av 90-talet, när applikationerna blev mer komplexa och
kunde ha hundratals eller tusentals användare, blev denna lösning ofta
ineffektiv av flera skäl:
- en 'tjock' klient kräver mycket resurser (diskutrymme, RAM och
CPU-kraft) på klientens dator för att exekvera effektivt.
- Administrationen på klient-sidan blir väldigt stor.
84
Three-tier arkitektur
 1995 började en ny arkitektur användas som skulle lösa problemen
med two-tier arkitekturen.
 Den nya arkitekturen består av tre lager (tiers) som vart och ett kan
köras på olika plattformar:
- Klienten (tier 1) Här finns användargränssnittet.
- Applikations-servern (tier2) Här finns det mesta av
applikationslogiken.
- Databas-servern (tier3) Här finns transaktionslogiken och
databasen.
En three-tier arkitektur har många fördelar:
 En 'tunn' klient, vilken inte kräver så dyr hårdvara.
 Många klienter kan använda samma applikations-sever, vilket betyder
att mjukvaran inte behöver distribueras till användarna.
 Den ökade modulariteten gör det lättare att modifiera eller byta ut ett
lager utan att påverka de andra lagren.
 Genom att separera applikationen från databasfunktionerna blir det
lättare att implementera 'load balancing'.
 Den passar ganska naturligt in i Web-miljön: browsern fungerar som
den tunna klienten och Web-servern fungerar som applikationsservern.
85
Fördelar och nackdelar med webben som databas-plattform
Fördelar
 Web-klienter är för det mesta plattformsoberoende, dvs
applikationer behöver inte modifieras för att köras på olika
operativsystem.
 Web-klienter tillhandahåller ett gemensamt grafiskt
användargränssnitt (GUI) som är lätt att använda och som kan
användas till flera saker, inklusive databas-access.
 Webben har inbyggt stöd för nätverks-access. Man slipper dyr
nätverks-mjukvara och komplexiteten med att få olika plattformar att
prata med varandra.
 En databas som är kopplad till webben kan nås från hela världen.
Detta ger stora möjligheter att sprida information och att skaffa nya
kunder.
Nackdelar
 För närvarande är Internet ett ganska opålitligt och långsamt medium.
 Eftersom HTTP är tillståndslöst är det svårt att hantera databasförbindelser och transaktioner.
 Prestandan kan bli lägre än i traditionella system eftersom webklienter ofta använder interpreterande språk (HTML, Java, JavaScript,
VBScript)
 Web-teknologin är ännu ganska omogen.
86