DD1368 Databasteknik Föreläsning 5: Återstart, säkerhet ... · RAID nivå 1: Blocken distribueras över diskarna men med spegling DD1368 Föreläsning 5, 14 februari 2011 RAID

DD1368 Databasteknik Föreläsning 5: Återstart, säkerhet, informationssystem-utveckling Hedvig Kjellström [email protected] www.csc.kth.se/DD1368

Behov av mer hjälp med labbar?

•!Vi har nu haft två datorsalspass för hjälp med labbarna

•!Nu följer två redovisningspass, där ni inte kommer kunna få hjälp -!Redovisningstider bokas i förväg, se hemsidan senare

denna vecka -!Varje handledare tar hand om en redovisningslista

•!Vill ni att vi lägger in en kvällstid med hjälp denna vecka?

DD1368 Föreläsning 5, 14 februari 2011

Repetition Föreläsning 6

•!Bitar vi borde gått igenom grundligare -!Relationsalgebra -!Normalisering

•!Kompenserar för det nu: F7 (utblickar) stryks, F6 (frågeoptimering) flyttas till F7, ny F6

•!Föreläsning 6, 21/2 -!Relationsalgebra kap 6-6.1 -!Normalisering (beroenden, canonical cover, Armstrongs

axiom mm) kap 8-8.5 -!Nåt mer? Maila mig!


Förra veckan: Fysiska nivån


Anställd

namn lön chef avd

Avdelning

avd våning

Leverantör

företag adress

Vara

varunr typ

Lager Försäljning

volym volym

Fortsätter denna vecka

Tittar också på informationssystemutveckling (forts från MDI-F)

Idag

•!Lite mer om transaktioner inför lab 4 -!Läs själv: Transaktioner i PostgreSQL kap 27.4

•!Återstart (kap 16) -!Återstart av databasen -!Reparation av databasen efter fel

•!Säkerhet (kap 4.4, 4.6, 9.7-9.8) -!Säkerhet -!Integritet

•!Informationssystemutveckling (kap 4, 8.8, 9) -!Arbetsgången vid utveckling av informationssystem


Lite mer om transaktioner inför lab 4

Transaktion

•!Serie kommandon som måste utföras i sin helhet eller inte alls -!Konflikter kan uppstå mellan

parallella t., måste hanteras -!Två metoder är låsning, tidsstämpling

•!Transaktion i SQL -!Olika i olika system -!Defaultbeteende i de flesta system: varje SQL-kommando

commitas automatiskt -!Kan också ange transaktioner explicit (syntax gäller för

både PostgreSQL och SQLite) !begin transaction;!

isolation level … ; !

… !

commit transaction; eller rollback transaction;!


Varje kommando en egen transaktion

Insert- och Delete-operationer

•!Hittills bara tittat på Read och Write-operationer i minnet -!Read: delat lås på minnesutrymmet -!Write: exklusivt lås på minnesutrymmet

•!Insert- och Delete-operationer kan leda till fantomfenomenet (phantom phenomenon): -!Transaktion T1 läser en post motsv tupel nr 5 i en viss

relation (har delat lås på den posten) -!Transaktion T2 lägger in en post motsv tupel nr 3 I

samma relation (har exklusivt lås på den posten) -!T2 kan påverka T1 om man inte sköter listuppdateringen

smidigt! (Mao, T1 kan råka läsa tupel nr 4 eftersom T2 ändrat datats lagringsplatser utan att T1 vet det


Återstart (kap 16)

Typer av fel

•!Transaktionsfel (transaction failure) -!Logiskt fel (logical error) tex datafel, overflow, resurser

saknas -!Systemfel (system error) tex deadlock

•!Systemkrasch (system crash) -!Bugg, strömavbrott, … -!Förstör inte sekundärminne

•!Diskfel (disc failure) -!förlust av block på sekundärminnet, tex fel vid en

överföring -!Återställs mha tertiärminne


Lagringstyper

•!Flyktigt minne (volatile storage): primärminne, cache -!Överlever oftast inte en systemkrasch -!Snabbt

•!Ickeflyktigt minne (nonvolatile storage): disk, tape -!Långsamt -!Används för lagring och backup av databasen

•!Stabilt minne (stable memory) -!Långsamt -!Basic: Disk med spegling (varje block lagras på två olika

diskar) -!Generell form av spegling: RAID -!Säkrare: RAID + arkivbackup på annan plats


RAID nivå 0: Blocken distribueras över diskarna utan spegling


RAID nivå 1: Blocken distribueras över diskarna men med spegling


RAID nivå 2: Bitar distribueras över diskarna och felkorrigerande koder lagras på extra diskar

•!RAID nivå 3: Som nivå 2 men utnyttjar systemets felkorrigering


RAID nivå 4: Blocken distribueras över diskarna och paritetsblock på separata diskar


RAID nivå 5: Blocken och paritetsblocken distribueras över diskarna (ökar prestanda)

•!Paritetsblock för data och data får inte ligga på samma disk

•!RAID nivå 6: Som nivå 5 men med extra paritetsbitar för att klara multipla diskfel


Dataaccess

•!Block på disk = fysiska block (physical blocks) •!Block i primärminne = buffrade block (buffer blocks)

•!Flytta block B mellan disk och primärminne -!Input(B) disk till primärminne -!Output(B) primärminnne till disk, ersätt nuv fysiska block

•!Transaktioners operationer på element X i B -!Read(X)

–! Om block B inte i primärminne: Input(B) –! För över X från databasbufferten till transaktionens arbetsminne

-!Write(X) –! Om block B inte i primärminne: Input(B) –! För över X från transaktionens arbetsminne till databasbufferten


Dataaccess © Silberschatz et al.


X !

Y !

A!

B!

x1!

y1 !

buffer!

Buffer Block A !

Buffer Block B!

input(A)!

output(B) !

read(X)!

write(Y)!

disk!

work area!

of T1!

work area!

of T2 !

memory!

x2!

Vad händer om systemet kraschar?

•!För logg (log records) över allt som görs!

•!Innan Ti utför Write(X) skrivs i loggen -!<Ti, X, oldValue, newValue> -!Man kan nu uppdatera databasen eller vänta tills

transaktionen är klar -!Vid fördröjd uppdatering används loggen för att

uppdatera databasen -!Loggen måste ligga på stabilt minne

•!Andra loggnoteringar -!<Ti start> -!<Ti commit> -!<Ti abort>


Efter krashen

•!Rollback av alla ”halvfärdiga” transaktioner -!Undo(Ti) går igenom loggen baklänges och återställer alla

värden som satts av Ti

•!Kan också gå åt andra hållet -!Redo(Ti) genomför kommandon i loggen igen

•!Omedelbar/fördröjd uppdatering -!Vid fördröjd uppdatering behöver man inte göra rollback

•!Loggen måste alltid skrivas före det att databasen uppdateras -!Anta att loggen alltid skrivs på stabilt minne (mer snart)


Checkpoint

•!Efter krasch, söka igenom hela loggen – tidskrävande

•!Därför: Checkpoint med jämna mellanrum -!Tvingar ut alla loggposter på stabilt minne -!Tvingar ut alla databasbuffertar till databasen (stabilt

minne) -!Skriver en checkpointpost i loggfilen: <checkpoint L>, L

lista över aktiva transaktioner

•!Efter krash -!L = transaktioner i L + transaktioner efter checkpoint -!Tk ! L som inte har commit eller abort i logg: Undo(Tk) -!Tk ! L som har commit eller abort i logg: Redo(Tk)


Återstart

•!Redo-fasen: Scanna loggen framåt från senaste checkpoint a) Sätt undo-listan till L från senaste checkpoint b) För varje <Ti, X, oldValue, newValue> eller <Ti, X,

newValue> (logg av en Redo), skriv newValue på X c) När <Ti start> hittas, lägg till Ti till L d) När <Ti abort> eller <Ti commit> hittas, ta bort Ti från L

•!Undo-fasen: Scanna loggen bakåt och gör rollback a) För varje transaktion i Ti i L, gör Undo(Ti) b) När <Ti start> hittas, lägg till <Ti abort>, ta bort Ti från L c) Terminerar när L tom (dvs <Ti start> för alla Ti hittats)

•!Normal transaktionshantering kan fortsätta!


Återstart © Silberschatz et al.


Buffring (Buffer Management)

•!Både databasen och loggen buffras i primärminnet -!Beräkningstungt att skriva till disk ofta

•!Hur garantera att det inte gör något om delar av en logg försvinner?

•!Write-ahead-loggning (WAL) -!Transaktionen är klar då commit skrivits i loggen och

denna skrivits på stabilt minne -!Innan commit-posten i loggen kan skrivas på stabilt

minne måste alla transaktionens loggposter skrivas på stabilt minne

-!Innan ett datablock kan skrivas på stabilt minne måste loggposterna rörande blocket skrivas på stabilt minne


Backup av databasen

•!Gör backup regelbundet på tex magnetband eller hårddisk på annan plats -!Skriv <dump> i logg -!Annars pss som för checkpoints

•!Då data går förlorat på disk -!Loggen finns i primärminne -!Återställ databasen till senaste backuptillstånd -!Gör om alla operationer efter senaste <dump> i loggen


Säkerhet (kap 4.4, 4.6, 9.7-9.8)

Säkerhet och integritet

•!Säkerhet: -!skydd av databasers innehåll mot icke auktoriserad

användning -!specificeras mha behörighetstillstånd

•!Integritet: -!Skydd för att vid en uppdatering hålla databasens

innehåll konsistent map betydelsen och att denna uppdatering propagerar (fortplantar sig) genom systemet på rätt sätt

-!specificeras med hjälp av restriktioner för hur uppdateringar får gå till


Säkerhet

•!Operatören av en databas, superuser, kan ge tillstånd åt andra att använda databasen på olika nivåer -!Olika användare -!Olika roller (roles) -!Olika relationer/attribut

•!Generella regler: 1) Skydda relationer, tupler och attribut genom att göra

dem osynliga – men skydda inte enstaka attributvärden 2) Använd audit trails (loggar över accesser till känsliga

data) – poster med accessat objekt, användar-ID, datum och tid


Säkerhet •!Ge rättigheter/privilegier (privileges) ! grant select on relationsNamn to public!! grant select,update on relationsNamn to

användarNamn/roll with grant option ! grant insert,delete on relationsNamn to

användarNamn1,användarNamn2 ! grant all privileges on relationsNamn to

användarNamn/roll

•!Ta tillbaka rättigheter revoke update,insert,delete on relationsNamn from

användarNamn/roll

•!Ge systemrättigheter grant roll to användarNamn1,användarNamn2 revoke roll from användarNamn1,användarNamn2


Integritet

•!Tidigare: funktionella beroenden

•!Not null -!Värden på namn i tupler kan inte sättas till null: create table Anstalld(!! namn varchar(20), not null, !

! … !

•!Unique -!Kontrollera att inte det inte finns dubletter: ! create table Anstalld(!

! namn varchar(20), unique(namn), !

! … !


Integritet

•!Check -!Se till att vissa villkor uppfyllda för alla tupler: create table Anstalld( !! … !

! lon smallint, check(lon > 15000), !

! … !

•!Nycklar -!främmande nycklar och kandidatnycklar kan specifieras:: create table Anstalld( !! … !

! primary key (namn), !

! foreign key (avd) references Avdelning)


Informationssystem-utveckling (kap 4, 8.8, 9)

Funktionella nivån

Logiska nivån

Fysiska nivån

Projektuppgift, steg 1

1.1 Kravanalys

1.2 Funktionell analys

1.3 Definition av restriktioner -!Steg 2


Funktionella nivån

Logiska nivån

Fysiska nivån

1.1 Kravanalys

•!Syfte: förstå användarens behov av information och funktionalitet

•!Skissa scenarier för olika användarkategorier (serie händelser)

•!Scenarier för dels normala fall, dels speciella fall

•!Presentera i form av t ex dataflödesdiagram


1.2 Funktionell analys

•!Från kravanalysen, dra slutsatser om den funktionalitet som måste finnas i applikationen

•!Beskriv (i naturligt språk) den funktionalitet som skall finnas i applikationen



2.1 Datamodeller för varje användarkategori, global datamodell

2.2 Bestämning av nycklar

2.3 Logisk datamodell

2.4 Normalisering

2.5 Attributdomäner och restriktioner


Funktionella nivån

Logiska nivån

Fysiska nivån

2.1 Datamodeller för varje användarkategori, global datamodell

•!Modeller för olika användare, se MDI-DB-gemensam föreläsning 27/1

•!Gör gemensam modell som är ”unionen” av dessa

•!Slutresultat – ett antal E-R-diagram och relationsscheman


Mer om modellering i föreläsning 1


•!I relationsscheman, notera kandidatnycklar och främmande nycklar -!Ex: Anställd ((namn), lön, chef, avd) Försäljning ((avd, varunr), volym) Lager ((avd, varunr, företag), volym) Leverantör ((företag), adress) Avdelning ((avd), våning) Vara ((varunr), typ)


Anställd

namn lön chef avd

Avdelning

avd våning

Leverantör

företag adress

Vara

varunr typ

Lager Försäljning

volym volym

Mer om nycklar i föreläsning 1


•!Om det finns fler kandidatnycklar välj då primärnyckel enligt följande -!Den mest stabila (håller i framtiden) -!Den med minst antal attribut -!Den kortaste -!Den som med minst sannolikhet ändras -!Den som är naturligast för användaren


2.3 Logisk datamodell

•!Det fullständiga relationsschemat med relationer attribut, nycklar = logisk datamodell -!Säger inget om implementationen -!Definierar vilka relationsalgebraiska operationer som kan

utföras


2.4 Normalisering

•!Överför den logiska modellen till 1NF och 3NF

•!Vinst med normalisering -!En fullt normaliserad struktur innehåller ingen redundans

•!Förlust med normalisering -!Vissa frågor kan ta lång tid (naturlig join över flera

relationer) -!Det kan finnas systembegränsnigar såsom antal tabeller,

antal attribut, antal rader i en tabell, antal öppna filer och om vi har ett distribuerat system


Mer om normalisering i föreläsning 3

2.4 Normalisering

•!Kan lätta lite på normaliseringskravet och slå ihop relationer – kallas denormalisering (denormalization)

•!Var medveten om att: -!Om vi tillåter vissa relationer att inte vara fullt

normaliserade så får vi redundansproblem -!Redundans inte bara dåligt, snabbar upp om härledda

attribut kan lagras i stället för att beräknas –! Extra fält för att hålla reda på t ex senaste ordern från en kund

-!Kan använda sekundära index för att öka hastigheten då vi utför naturlig join

–! Mer om sekundära index snart

•!Kan också behålla normaliserad struktur och använda vyer för att nå samma struktur mot applikationen

–! Mer om vyer snart


2.5 Attributdomäner och restriktioner

•!Attributdomäner -!varchar(n), smallint, numeric(p,d), mm

•!Restriktioner -!Intervall, not null, unique, check, nycklar, default, mm -!Objektintegritet: Ingen del av en nyckel får vara null -!Referensintegritet: Ett refererat attributvärde måste

existera -!Funktionella beroenden


Mer om restriktioner och integritet tidigare i denna föreläsning

Mer om funktionella beroenden i föreläsning 3


3.1 Analys av transaktioner

3.2 Val av filorganisation

3.3 Val av sekundära index

3.4 Design av vyer för olika användare

3.5 Design av accessregler


Funktionella nivån

Logiska nivån

Fysiska nivån


•!Utifrån användarscenarier och den logiska modellen, analysera vilka transaktioner (atomära enheter av kommandon) som äger rum

•!Hur hitta transaktioner?

•!Från användarens perspektiv är det en operation


Mer om transaktioner i föreläsning 4


•!För varje funnen transaktion -!Undersök accesser till varje relation (Insättning, Läsning,

Uppdatering och Borttagning), vilka attribut som används

•!Uppskatta transaktionsintensitet (medel och max)

•!Rita gärna graf med relationer, vägar för transaktioner mellan dem

•!Exempel på transaktioner (i en mäklardatabas) -!Producera en rapport med alla lediga lägenheter -!Lista alla visningar för en viss lägenhet


3.2 Val av filorganisation

•!Dvs val av primärt index -!Indexera inte små relationer

•!För små datamängder, sekvensiellt index -!Hash, B-träd har overhead för struktur

•!För stora datamängder och sällan sorterade listor eller åtkomst i ordning, hashtabell -!Snabbt, men stor overhead att sortera

•!För stora datamängder och ofta åtkomst i ordning, B-träd -!Snabbt även för sorterad åtkomst


3.3 Val av sekundära index

•!Sekundärt index = index över ett annat attribut än primärnyckeln -!Till fält som används ofta som sekundär nyckel -!Till främmande nycklar som ofta används som ingång (vid

join tex)

•!Varje index medför extrajobb – avvägning mellan söktidsvinst och extrajobbtidsförlust -!Addera post till varje index då tupel adderas till relationen -!Uppdatera alla indexposter då en tupel uppdateras -!Undvik index till attribut som ofta uppdateras -!Undvik index på attribut bestående av långa strängar -!Undvik index på attribut där frågan kräver tillgång till

större delen av en tupel



•!Vy (view) = virtuell relation (som bara finns i arbetsminnet, inte i den fysiska databasen) -!Ex (selektion): ! create view csc_teacher as !

! select *!

! from teacher !

! where department = ’CSC’; !

-!Ex (projektion): ! create view lab_for_handledare as !

! select number,grade!

! from lab;!



•!Vyer kan modifieras pss som riktiga relationer om -!Vyn är skapad från en enda relation -!Vyn är sammansatt av ”originalattribut” från denna

relation, alltså inte funktioner eller aggregat -!Alla attribut som inte är listade i vyn kan sättas till null -!Vyn inte har någon group by- eller having-del

•!Isåfall ser DBMS till att den riktiga relationen från vilken vyn skapades uppdateras


3.5 Design av accessregler

•!Ge olika användare olika rättigheter till olika -!Olika relationer och attribut i relationsschemat -!Olika vyer skapade från dessa

•!select,update,insert,delete


Mer om rättigheter och säkerhet tidigare i denna föreläsning

Implementation för användarutvärdering

•!Valfri programmeringsmiljö

•!Implementationen ska följa modellen vi tagit fram -!Funktionell nivå (funktionaliteten för användaren) -!Logisk nivå (relationsschemat) -!Fysisk nivå (filstrukturen, rättigheter mm)


Mer om applikationsprogram-mering i föreläsning 3


•!4.1 Programmera prototyp

•!Gå igenom steg 1-3 och omvärdera designval baserat på dessa resultat från användarstudierna i steg 3

–! 1.1 Kravanalys –! 1.2 Funktionell analys –! 2.1 Datamodeller för varje användarkategori, global datamodell –! 2.2 Bestämning av nycklar –! 2.3 Logisk datamodell –! 2.4 Normalisering –! 2.5 Attributdomäner och restriktioner –! 3.1 Analys av transaktioner –! 3.2 Val av filorganisation –! 3.3 Val av sekundära index –! 3.4 Design av vyer för olika användare –! 3.5 Design av accessregler


Funktionella nivån

Logiska nivån

Fysiska nivån

Härnäst

•!Idag/i morgon: Övning 4 -!Redovisa Hemtal 3 – gå till vilken grupp ni vill -!Se instruktioner på kurshemsidan, Hemtal i menyn

•!21/2: Föreläsning 6 (Repetition av relationsalgebra, normalisering) -!Läs kap 6-6.1, 8-8.5 i boken

•!24,25/2: Redovisning av lab 1, 2, 4 -!Boka ett 15-minuterspass – se hemsidan denna vecka

•!Nu – 28/2,1/3: Gruppuppgift (Diskussion) -!Lämnas på övning 5 -!Grupper i fil Diskussionsgrupper.txt i kurskatalogen


Documents

DD1368 Databasteknik Föreläsning 5: Återstart, säkerhet ... · RAID nivå 1: Blocken distribueras över diskarna men med spegling DD1368 Föreläsning 5, 14 februari 2011 RAID