1 Informationssystem och databasteknik 2I1100 2000-10-31 Elmasri Navathe kapitel 18-22 Relationsdatabashanteringssystem RDBHS.

En presentation över ämnet: "1 Informationssystem och databasteknik 2I1100 2000-10-31 Elmasri Navathe kapitel 18-22 Relationsdatabashanteringssystem RDBHS."— Presentationens avskrift:

1 1 Informationssystem och databasteknik 2I1100 2000-10-31 Elmasri Navathe kapitel 18-22 Relationsdatabashanteringssystem RDBHS

2 2 Relationsdatabashanteringssystem Ett antal program för att möjliggöra lagring, återvinning och uppdatering av data behörighetskontroller kontrollerad hantering av data för datakonsekvens återskapande av data efter fel av olika slag transaktionshantering samtidig bearbetning av data utan att data förvanskas effektivisera den interna hanteringen av data

3 3 Optimization kap 18 Concurrency kap 19-20 Recovery kap 21 Security kap 22 Integrity (kap 7) RDBHS

4 4 OPTIMERING QUERY OPTIMIZATION optimerar utsökning av information ur en databas I de traditionella databasmodellerna, hierarkiska och nätverk, måste detta överlåtas åt applikations- programmeraren. Relationsdatabashanteringssystemet har inbyggda s.k. optimizers!

5 5 Optimeraren väljer väg har tillgång till mer info kan testa fler varianter kan utnyttja kunskap som DBA, system prog. och forskare byggt in väljer väg har tillgång till mer info kan testa fler varianter kan utnyttja kunskap som DBA, system prog. och forskare byggt in Styrka att kunna optimera! (DBMS konkurrensmedel)

6 6 Uppgift för optimeraren Minimera total accesskostnad för SQL-kommandon Bestämmer hur utsökning skall genomföras Bestämmer vilka index som skall användas Undviker eller minimerar sorteringar Bestämmer Join-strategi

7 7 Så vad är en optimerare ? Expertsystem, med kunskaper som forskare byggt in ”Svart låda” (DBMS konkurrensmedel) Optimeraren har tillgång till mer info än användaren Tabellstorlek, lagringsstruktur och index för tabellerna Statistik för tabellinnehållet defaultvärden framställd statistik (update statistics)

8 8 Frågetransformering Syntaxkontroll Översättning Validering Optimering Kodgenerering Strategival SQL-fråga Syntaktisk korrekt SQL-fråga Giltig SQL-fråga Relationsalgebra Optimerad Relationsalgebra Exekveringsplan Kod Scanner resp parser Query tree eller Query graph Interpreterad Kompilerad

9 9 Sökstrategier 1. Sekvensiell genomsökning (scanning) 2. Binärsökning 3. Hashad nyckel eller primärindex (= PK) för enstaka rad 4. Primärindex för flera rader (> PK eller < PK) 5. Klustrat index för flera rader (> attr med klustr index) 6. B*-index som sekundärt index 7. Sökning med sammansatta index 8. Snitt av index ( matchning av postpekare )

10 10 Conjungtive / Disjunctive condition Konjungtivt villkor är flera villkor sammansatta med OCH. Då väljes i första hand det mest selektiva villkoret först Disjunktivt villkor är flera villkor sammansatta med ELLER. Kräver för det mesta genomgång av en tabell flera gånger

11 11 JOIN-strategier! 1. Nested loop 2. Använda index eller hashnyckel 3. Sort-merge join 4. Hash-join

12 12 Nested loop ABCDABCD R1 1 C 3 D 4 C 6 B 7 A 9 A 12 C 14 B R2 Alt 1: Alla rader i R1 jämföres med alla rader i R2: 4 + 4 * 8 = 36 rader läses Alt 2: Alla rader i R2 jämföres med alla rader i R1: 8 + 8 * 4 = 40 rader läses Slutsats: Välj den minsta tabellen som "yttre loop". OBS: I verkligheten är "filerna" förstås blockade

13 13 Använda index eller hashnyckel Effektiv när det gäller att göra join på två tabeller när man söker ett fåtal värden. (Matchning PK - FK) Den ena tabellen läses i sin helhet och joinattributet (ofta Främmande nyckeln) användes för att läsa den andra tabellens rader en i taget med hjälp av index eller hashing. ABCDABCD R1 1 C 3 D 4 C 6 B 7 A 9 A 12 C 14 B R2 R1 läses radvis, och för varje rad användes R2´s primärindex för att läsa motsvarande rad i R2. Resultatet hamnar i en resultat- buffert i primärminnet

14 14 Sort-Merge join Alla ingående tabeller måste vara sorterade på samma attribut En mycket effektiv metod om hög "träffgrad" väntas. Inledande sorteringar + sort-merge realistiskt alternativ

15 15 Hash JOIN Båda tabellernas rader läggs in i samma minnesbuffert med hjälp av en hashalgoritm som appliceras på join-attributen. Tabellernas rader kan vara i godtycklig ordning. Fördel att båda tabellerna bara läses en gång. Om mellanresultatet blir så stort att det inte ryms i PM är metoden ej effektiv.

16 16 Aggregatfunktioner och Index MIN MAX COUNT AVG SUM Om det finns ett index på attributet som skall beräknas så behöver förstås inte några enskilda rader accessas utan det räcker med att läsa index

17 17 Heuristisk optimering optimerad relationsalgebra Tag fram namn och adress för alla kunder som beställt bokhyllan POMPE (artnr 105436-8) kundnamn, kundadress ORDERRAD KUND  |X| ordernr  |X| kundnrnr  artnr = 105436-8 ORDER

18 18 kundnamn, kundadress ORDERRAD KUND ORDER Ordernr, kundnr   |X| ordernr Kundnr, kundnamn, kundadress  |X| kundnrnr  artnr = 105436-8 Optimerat träd Tag fram namn och adress för alla kunder som beställt bokhyllan POMPE (artnr 105436-8) Ordernr 

19 19 Tumregler 1. Gör SELECT så tidigt som möjligt! Utnyttja "lagarna" för att föra selektionen så långt ned i trädet som möjligt 2. Gör PROJECT tidigt! Utnyttja "lagarna" för att föra projektionen så långt ned i trädet som möjligt 3. Minimera mellanresultat! Använd associativa lagen så att den selection som ger minsta mellanresultatet utföres först 4. Gör JOIN först när det är nödvändigt 1. Gör SELECT så tidigt som möjligt! Utnyttja "lagarna" för att föra selektionen så långt ned i trädet som möjligt 2. Gör PROJECT tidigt! Utnyttja "lagarna" för att föra projektionen så långt ned i trädet som möjligt 3. Minimera mellanresultat! Använd associativa lagen så att den selection som ger minsta mellanresultatet utföres först 4. Gör JOIN först när det är nödvändigt

20 20 Relationsalgebraiska lagar 1. Associativa lagen (R * S) * T = R * (S * T) 2. Kommutativa lagen R * S = S * R 3. Distributiva lagen (Cascades) u(R * S) = u(R) * u(S) Läroboken visar de olika lagarna med exempel

21 21 Vad kostar en fråga? Access-kostnad till sekundärminne - typ av access-struktur index klustrade index Lagringskostnad för mellanresultat Bearbetningskostnad sortering, sökning, join, beräkningar Optimeringen görs inte enbart med hänsyn till heuristiska regler. Kostnaden uppskattas för olika alternativ så att den billigaste frågestrategin kan väljas.

22 22 Statistik Optimeraren måste ha statistikuppgifter för att kunna sköta jobbet! Antal rader per tabell (kardinalitet) Radlängd Antal olika värden i en kolumn (selektivitet) Max/Min-värden inom en kolumn DATA DICTIONARY (Systemkatalogen) av avgörande betydelse för optimeraren

23 23 Transaktionshantering Vad är en transaktion ? Internt: allt 'jobb' som en användares atomära transaktion genererar Exempel Flytta pengar från konto A till konto B DBMS-krav: Allt eller inget! Läs konto A, finns pengar?, subtrahera belopp, skriv A, läs B,addera belopp, skriv B

24 24 Databastransaktion - Logical Unit of Work Före transaktionens start är databasen i ”consistent state” Under transaktionen är databasen i ”inconsistent state” Transaktionen kan avslutas på två sätt: COMMIT eller ABORT COMMIT för databasen till ett nytt konsistent läge ABORT återställer databasen till läget före BEGIN TRANSACTION

25 25 A C I D Krav på DBMS A A tomicity (transaktionen är atomär) C C oncistency (koncistensen skall vidmakthållas) I I solation. Varje transaktion verkar köras isolerad D D uration. Oavsett om olika fel inträffar skall resultatet av en rätt utförd transaktion bestå*. * Kan dock ändras med kompensationstransaktion

26 26 Var finns prestandaproblemen? Design45% - Datamodellering, Tabeller, Lagringsstruktur, Index Applikation40% - Transaktionshantering, SQL, Partitionering Konfiguration10% - Låshantering, Transaktionslogg Operativsystem 5% - Disk-layout, systemparametrar, minneshantering

27 27 Concurrency Parallellitetsstyrning, handlar om att skydda data i databasen från skadlig påverkan av interfolierande (samtidiga) transaktioner. Löses med hjälp av lås. Parallellitetsstyrning, handlar om att skydda data i databasen från skadlig påverkan av interfolierande (samtidiga) transaktioner. Löses med hjälp av lås.

28 28 Den förlorade uppdateringen Trans A tid Trans B Läs Tal = 20 = 20 Läs Tal Add 50 = 70 = 0 Sub 20 Skriv Tal = 70 = 0 Skriv Tal Värdet i databasen för Tal = 0. Korrekt värde skall vara 50! (20 +50 -20)

29 29 Beroende till en backad trans Trans A tid Trans B = 20 Läs Tal = 70 Add 50 Läs Tal = 70 = 20 ROLLBACK Trans A ser data som "aldrig existerat"! (s.k. ”dirty data”)

30 30 Beroende till en backad trans Trans A tid Trans B = 20 Läs Tal = 70 Add 50 Läs Tal = 70 Add 20 = 90 = 20 ROLLBACK Trans A opererar på data som "aldrig existerat"!

31 31 Locking protocol Läslås Shared Lock (PS) Shared lock sättes på ett objekt som skall läsas. Andra transaktioner tillåts att läsa objektet Skrivlås Exclusive Lock (PX) Exclusive lock sättes på ett objekt som skall skrivas. Andra transaktioner får ej tillgång till objektet

32 32 Locking protocol Läslås Shared Lock Shared lock sättes på ett objekt som skall läsas. Andra transaktioner tillåts att läsa objektet Skrivlås Exclusive Lock Exclusive lock sättes på ett objekt som skall skrivas. Andra transaktioner får ej tillgång till objektet

33 33 Scheduler producerar exekveringsplan Scheduler ställer upp en Conflct-graph (konflikt-graf, precedensgraf) T1 T2 T3 T4 Seriell ordning: T1 - T3 - T2 - T4

34 34 Two-Phase Locking (2PL) Alla transaktioner följer följande regler: I. Innan den opererar på något objekt sätter den ett lås på objektet II. Efter att ha släppt ett lås begär den aldrig några nya lås Alla transaktioner följer följande regler: I. Innan den opererar på något objekt sätter den ett lås på objektet II. Efter att ha släppt ett lås begär den aldrig några nya lås Detta medför att alla interfolierade exekveringar av sådana transaktioner är serialiserbara

35 35 Serialiserbarhet Def: En given interfolierad exekvering av ett antal transaktioner är serialiserbara om och endast om den producerar samma resultat som en seriell exekvering av samma transaktioner Korrekthetsvillkor: En given interfolierad exekvering av ett antal transaktioner är korrekt om den är serialiserbar Varje transaktion är korrekt i sig Transaktionerna är logiskt oberoende av varandra Varje transaktion är korrekt i sig Transaktionerna är logiskt oberoende av varandra

36 36 Two-Phase Locking De två faserna är: - en växande fas, där låsen begäres - en krympande fas, där låsen släpps antal lås transaktionens tid Flera varianter av 2PL finns. De vanligaste är basic 2PL (ovan), Conservative 2PLsom sätter alla sina lås samtidigt och Strict 2PL som släpper alla sina skrivlås samtidigt efter commit.Rigorous 2PL håller samtliga lås tills commit.

37 37 Deadlock Ett system som tillämpar låsning riskerar DEADLOCK. Systemet måste ha en rutin för att upptäcka DEADLOCK. I regel går detta till så att systemet har en väntegraf (Wait-for-graph) WFG som man analyserar för att upptäcka om det finns cykler i grafen. Vanligtvis sker analysen antingen när någon begärt ett lås men satts på väntelista eller annars periodiskt T1T1 T2T2 T4T4 T3T3

38 38 Lösa deadlock En transaktion utses till "offer" och rullas ut för senare återstart. Man väljer t ex den yngsta den som har minst antal lås den som gjort minst antal uppdateringar den som har mest kvar Passa "starvation", dvs att samma trans väljs som offer under lång tid. Tid är vanligast p g a rättvisekrav

39 39 Conflict serializability Två transaktioner är konflikterande om de accessar samma data, och en av dem innehåller en skrivoperation, ocd innehåller de konflikterande operationerna i samma ordning För att upptäcka ”konflikterande serialiserbarhet” så konstrueras precedensgrafer: A C B C B A Conflicting Non- Conflicting

40 40 Recoverable schedule A schedule where, for each pair of transactions T a och T b, if T b reads a data item previosly written by T a, then the commit operation of T a precedes the commit operation of T b Detta beror förstås på att om T b skulle göra COMMIT före T a, och T a därefter avslutas med ABORT så kan ju inte T b rullas tillbaka (D= Duration)

41 41 Låsningsgranularitet Granularitet = storlek på objektet man låser Databas Tabell Tablespace (eller motsvarande) Sida Rad Systemet kan alltid låsa en större enhet än vad som är logiskt nödvändigt Systemet kan alltid hålla låsen längre än vad som är logiskt nödvändigt

42 42 Level of Isolation 1. "Dirty read"Låt denna process se dirty data 2.Committed readLåt inte denna process se dirty data 3.Cursor stabilityLåt ingen annan uppdatera min rad som är "current" 4.Repeatable readLåt ingen annan uppdatera någon av de rader jag sett förrän jag är klar

43 43 Två huvudsakliga metoder Pessimistiska protokoll som antar att konkurrerande uppdateringar sker frekvent. Metod för att hantera konkurrensen innefattar ofta tidsstämpling Optimistiska protokoll som utgår ifrån att konflikter är sällsynta

44 44 Time-stamping varje transaktion stämplas. varje dataelement (sida) har två stämplar, en läs- och en skrivtid. (När sidan senast lästes eller skrevs) konflikt uppstår när en transaktion vill -se en post som en yngre trans uppdaterat -uppdatera en post som redan setts eller uppdaterats av en yngre trans Lösning: Återstarta den begärande transaktionen

45 45 Undvika deadlock wait-die: Om T a är äldre än T b så får T a vänta, annars så backas T a ut och startas om senare med oförändrad tidsstämpel wound-wait: Om T a är äldre än T b så backas T b ut och startas om senare med oförändrad tidsstämpel En transaktion T a försöker låsa X som är låst av T b

46 46 Optimistisk metod En transaktion begär att en datasida läses in i UWA (User Working Area) Uppdaterande data sparas också i UWA. Uppdatering sker i en lokal kopia i UWA Lås begäres på sidan Sidan läses in och kontrolleras mot sidan i UWA Om den ser likadan ut så har ingen ”mellankommande” transaktion uppdaterat sidan och den lokala kopian kan skrivas till databasen Om den är förändrad så gör man om hela proceduren men nu med den uppdaterade sidan som ”original”

47 47 Timestamp Ordering Timestamp ordering säkerställer att alla konflikterande läs- och skrivoperationer görs i tidsordning (timestamp order) Antag att T i begär läs(Q) Om TS(T i ) < W-timestamp(Q), så betyder det att T i skulle behöva läsa ett värde på Q som är överskrivet. T gör ROLLBACK! Om TS(T i ) > W-timestamp(Q) så utföres läsningen och R-timestamp får den högsta timstamp av TS(T i ) och R-timestamp(Q) Antag att T i begär skriv(Q) Om TS(T i ) < R-timestamp(Q), så betyder det att Q har lästs av en annan transaktion. T gör ROLLBACK! Om TS(T i ) < W-timestamp(Q) så betyder det att T i vill skriva ett gammalt värde på Q och T i gör ROLLBACK! Annars exekveras skrivoperationen och W-timestamp(Q) får den högsta timstamp av TS(T i ) och W-timestamp(Q) T som gör ROLLBACK får en ny tidssämpel och startas om!

48 48 Intent locking Ett protokoll för INTENT LOCKING medger att sätta INTENT lock på en högre granularitet. IX (intent exclusive) på en tabell betyder att det finns X-lås på t ex en sida eller på rader inom tabeller. Om nödvändigt kommer Intent lock att escalera i granularitet ISIXSSIXX 1 1 1 1 0 1 1 0 0 0 1 0 1 0 0 1 0 0 0 0 0 0 0 0 0 IS IX S SIX X Kompatibilitetsmatris

49 49 Recovery ( Återskapande) Recovery handlar om återskapande av data efter olika slags fel. systemkrasch mediakrasch systemfel programfel ”DBMS-fel” (t ex deadlock, triggers) DBMS förutsätts stödja olika typer av "loggar"

50 50 Logg Back-up Databas Before After Logg 1 2 3 4 5 1 och 2 före bearbetning 3 - 5 efter bearbetning Loggar användes vid rcovery (återskapande) av databasen (UNDO) (REDO)

51 51 Återskapande av vad? Ett koncistent nuläge oavsett störningar (ROLLFORWARD) Total recovery Back-up + after image Selektiv recovery Translogg, buffertar Ett tidigare koncistent läge ROLLBACK before image, translogg, buffert

52 52 Databasen måste återskapas genom att ladda senaste backup-kopian av databasen. Med hjälp av loggen omstartas korrekt avslutade transar. Om "after-image-log" finnes kopieras den in i senaste backup-kopian Utbackning krävs ej! Mediakrasch

53 53 Systemloggen Varje transaktion tilldelas en unik systemgenererad identifikation. Systemloggen finns på disk men kopieras ofta ut till band eller skuggskrivs eller speglas på flera ställen. Systemloggen innehåller t ex följande info: [start_transaction,T]: Start för transaktion T [write_item,T,X,old_value,new_value]: Gammalt och nytt värde för "item" X. Värdet på X ändrat av T. [read_item,T,X]: T har läst värdet på "item" X [commit,T]: T har avslutats felfritt och av T gjorda uppdateringar kan permanentas till disk. [abort,T]:T har avbrutits

54 54 Olika strategier för loggning/dumpning Spegling (dubblering) av data Skuggskrivning (Shadowing) av data Periodisk "dumping" av data - all data - endast data som uppdaterats (inkrementell dump) - endast data som inte uppdaterats ( residual dump) Loggning av transaktioner Loggning av förändringar - före ändring - efter ändring - både före och efter ändring

55 55 Checkpoints (synchpoint, breakpoint) Töm alla buffertar till disk (databasen) Skriv en "check-point"-post på logg-tapen Alla aktiva processers status skrivs i "loggposten" Skriv loggpostens adress (läge) på logg-tapen i en särskild återstartspost på disk

56 56 System-krasch Time tc tf T1 T2 T3 T4 T5 checkpoint time failure time

57 57 Återstart med hjälp av check-point 1. Lägg alla aktiva transaktioner vid CP i en UNDO-lista. Skapa en tom REDO-lista. 2. Sök framåt i loggen från CP 3. Om en BEGIN TRANSACTION påträffas läggs den i UNDO-listan 4. Om COMMIT påträffas flyttas transen från UNDO till REDO-listan 5. När recovery-processen nått slutet på loggen söker den bakåt i loggen och backar ut transarna på UNDO-listan 6. När checkpoint-postens början nåtts så går CP-processen framåt igen och gör om transarna på REDO-listan

58 58 Deferred update Deferred update (fördröjd uppdatering) innebär att den fysiska databasen aldrig uppdateras förrän man nått COMMIT. All uppdatering mot databasen sker i en minnes-buffert. När COMMIT gjorts skrivs de gjorda uppdateringarna först på logfilen Därefter permanentas uppdateringarna i databasen. I detta läge finns det inget behov av UNDO

59 59 Immediate update Immediate update (omedelbar uppdatering ) innebär att uppdatering av databasen sker utan att invänta COMMIT. De gjorda uppdateringarna skrivs alltid på logfilen före uppdatering i databasen För att möjliggöra recovery behövs både UNDO och REDO

60 60 Nästlade transaktioner Nästlade transaktioner kan användas när en transaktion kan delas upp i oberoende subtransaktioner. Subtransaktionerna ordnas i ett transaktionsträd. T1 T4T3 T2 T5T6 (Exemplet från läroboken) Subtransaktionerna T2, T5 och T6 kan köras oberoende av varandra. Om t ex T5 misslyckas kan ändå T2 och T5 committas och T2 kan få en alternativ lösning. Subtransaktionerna kan få konflikterande lås om den konflikterande transaktionen är ”föräldern” T1 är en bokning av flygbiljett (T2), hotell (T5) och hyrbil (T6)

61 61 Saga En form av ”Open Nested Transaction”. För varje utförd transaktion skapas en kompenserande transaktion. Om trasaktionen fallerar eller hamnar i konflikt så körs den kompenserande transaktionen. Meningen med Saga (liksom med alla nestade transaktioner) är att transaktionerna inte skall behöva hålla strict på Isolation level

62 62 Security Säkerhet : Att endast behöriga kommer åt data i databasen! Koncistens : Att vad som görs är rätt d v s att data alltid är korrekta!

63 63 Säkerhet Fysiskt: Lås, kortläsare, behörighetsområde Policy: Vem skall ha behörighet till access av data Password: Underhåll av lösen Hårdvarusäkerhet: Underhållsavtal SPECIELLT FÖR DATABASER: VEM SKALL FÅ GÖRA VAD ? SPECIELLT FÖR DATABASER: VEM SKALL FÅ GÖRA VAD ?

64 64 Behörighetskontroll VEM? Lösenord, auktorisation, användar- definierade procedurer VAD? Views*, auktorisation, kryptering HUR? Behörighetsmatris, klassificering, statistiska databaser * views motsvaras i ACCESS av frågeresultat

65 65 Datorbaserade kontroller Identifikation (Autenticitet) Aktorisation Vyer Kryptering

66 66 Authentification En mekanism som avgör om en användare är den han/hon utger sig för lösenord röstanalys fingeravtryck ögonbottenanalys (användes ej p g a risk för ögonskador) mönstermatchning kort med PIN-kod

67 67 Behörighet Det finns två behörighetsnivåer: Account levelBestämmer vad en användare får göra oberoende av tabeller. T ex skapa en ny databas, skapa vyer, ändra tabeller m m Relation levelBestämmer vilka tabeller och/eller vyer en användare har tillgång till och vad användaren får göra

68 68 Aktorisation Bestämmer vad ett SUBJEKT får göra med ett OBJEKT GRANT privilege_list ON object … TO subject … [WITH GRANT OPTION] SUBJECT kan vara användare, grupper och roller OBJECT kan vara databas, tabeller, vyer, procedurer, applikationer

69 69 GRANT, priveleges GRANT privilege_list ON object … TO subject … All Select Delete Insert [ (column [, column] … ) ] Update [ (column [, column] … ) ] References [ (column [, column] … ) ]

70 70 Grant GRANT Select On ANSTÄLLD TO Bosse GRANT Update (Saldo) ON KUND TO Sonja, Stig GRANT All ON ARTIKEL TO PUBLIC GRANT Insert ON KUND TO Ada, Beda, Osborn WITH GRANT OPTION GRANT Reference (Säljarnr) ON KUND TO Oscar

71 71 REVOKE REVOKE privilege_list ON object … FROM authorization_id_list [RESTRICT | CASCADES] Revoke tar tillbaka given behörighet CASCADES medför att även underliggande vyer tas bort RESTRICTED innebär att behörigheten inte kan tas tillbaka om det finns underliggande vyer. REVOKE tar bort behörigheten även för dem som fått den m h a WITH GRANT OPTION.

72 72 VIEW med CHECK OPTION CREATE VIEW artikel AS SELECT * FROM PRODUCT WHERE färg IN (’Gul’, ’Röd’, ’Grön’) AND pris > 500 AND pris < 1000; All uppdatering sker mot vyn som då inte kommer att acceptera rader som inte har godkända värden i färg resp pris.

73 73 Mandatory Access Control Både subject och object delas in i säkerhetsklasser: Ex: TSTop Secret SSecret CConfidential UUnclassified

74 74 Mandatory Access Control Regler: 1)Ett subjekt får bara läsa objekt med lägre eller samma säkerhetsklass 2)Ett subjekt får bara skriva (uppdatera) objekt med högre eller samma säkerhetsklass, för att förhindra att klassade data ”läcker” till lägre objekt.

75 75 Audit Audit - dels loggning, dels systemgenererade kontroller - garantera korrekta indata - garantera korrekta körningar - Upptäcka och förebygga programfel - Dokumentera programunderhåll och exekvering - Förhindra icke-aktoriserade programändringar - Logga åtkomst och begäran om åtkomst till data -Garantera att dokumentationen uppdateras

76 76 DBMSs and Web Security Proxy servers Firewalls Digital signatures Message digest algoritms and sigital signatures Kerberos SSL Secure socket layer and SHTTP Secure HTTP

77 77 Kontrollerad hantering av data för datakoncistens Integrity Domän Entity integrity Referential integrity (+ foreign key business rules) Olika bearbetningar kan förses med regler (triggers) Data i databasen liksom hanteringen av den måste följa givna regler

78 78 Integrity Enhancement Feature ISO 1992 Required Data Domain constraint Entity integrity Referential integrity Enterprise constraint

79 79 Domän CREATE DOMAIN domain-name [AS] data-type [DEFAULT default-option] [CHECK (search-condition)] Ex)CREATE DOMAIN kön AS CHAR(1) CHECK (VALUE IN (’M’, ’K’)); Ex) CREATE DOMAIN ktyp AS VARCHAR(5) CHECK (VALUE IN (SELECT kundtyp FROM kategori));

80 80 TRIGGERS CREATE TRIGGER Trigger_name BEFORE | AFTER ON >table_name> [REFERENCING ] [FOR EACH ROW | STATEMENT ] [WHEN (trigger_condition) ] E VENT - C ONDITION - A CTION

81 81 Triggers medför dock... Komplexitet: När funktionalitet flyttas från applikationen till databasen blir DBA mer komplext Dold funktionalitet: Om funktionaliteten flyttas till en eller flera triggers döljs funktionaliteten från användaren. Det är mestadels positivt, men kan ha motsatt effekt, eftersom användaren inte längre har kontroll över vad som sker. Overhead:Triggers i ”högfrekventa” transaktioner kan förorsaka problem under högtrafik.