Databaser & databasdesign. Personuppgiftslagen, säkerhet och transaktioner.

Transkript

1 Databaser & databasdesign Personuppgiftslagen, säkerhet och transaktioner.

2

3

4 Uppgift - Personuppgiftslagen ord exklusive referenser Sammanställning av de du anser viktigast Deadline 2:a december (är inträdesbiljett till diskussion vid nästa föreläsningspass) Mailas till jesper.hakerod@hh.se och texten bifogas i en pdf-fil. Döp er pdf-fil enligt följande: PUL_förnamn_efternam.pdf Rubrik på ert mail ska vara [databaser & databasdesign PUL].

5 5 Databassäkerhet (se kap 20) Data är en värdefull resurs som strikt måste kontrolleras och hanteras, på samma sätt som med vilken företagsresurs som helst. Delar av eller all affärsdata kan vara av strategiskt viktig betydelse och behöver därför lagras på ett säkert sätt.

6 6 Databassäkerhet (2) Följden är mekanismer som skyddar databasen mot avsiktliga och oavsiktlioga hot. Säkerhetsöverväganden är inte bara en fråga om datan som lagras i databasen. Säkerhetsluckor kan påverka andra delar av systemet, som i sin tur påverkar databasen.

7 7 Databassäkerhet (3) Händelser som bör undvikas: Stöld och svindleri (theft and fraud) Förlust av konfidentialitet (secrecy) Förlust av integritet (privacy) Förlust av korrekthet (integrity) Förlust av tillgänglighet (avaliability)

8 8 Hot för ett dator- system

9 9 Säkerhetsmekanismer Berör allt från fysiska kontroller till administrativa procedurer: Auktorisering (authorization) Vyer Backup and återskapande (recovery) Datans korrekthet (integrity) Kryptering RAID teknik

10 10 Säkerhetsmekanismer (2) Auktorisering (authorization) Garantera rättigheter eller previlegier, som möjliggör tillgång till ett system eller systemobjekt. Autentifiering (authentication) En mekanism som kollar om användare är den som användaren utger sig för att vara.

11 11 Säkerhetsmekanismer (3) Vyer Ett dynamisk resultat (i form av en tabell) som genom en fråga skapas utifrån en eller flera bastabeller. En virtuell tabell som inte existerar i databasen, utan genereras vid det tillfället en användare gör en förfrågan.

12 12 Säkerhetsmekanismer (4) Backup En process som vid vissa tillfällen gör en kopia av databasen och logfilen för lagring på annat media. Logfiler En process som tillhandahåller och genererar logfiler över alla ändringar som görs i databasen för att effektivt kunna återskapa databasen i händelse av fel.

13 13 Säkerhetsmekanismer (5) Datans korrekthet (integrity) Hindrar data från att bli felaktig, och därigenom ge felaktiga och missvisande svar. Kryptering Kodning av data med en speciell algoritm som gör datan oläsbar utan en krypteringsnyckel.

14 14 Säkerhetsmekanismer (6) RAID Hårdvara som DBMS körs på måste vara feltolerant, dvs DBMS:et måste fortsätta att fungera även om en hårdvarukomponent felar. RAID föreslår att redundanta komponenter integreras i systemet för att systemet även ska fungera även när någon eller några komponenter felar. De felande komponenterna byts. En lösning är att tillhandahålla en stor diskarray som omfattar hanteringen av flera oberoende diskar som organiserats för att förbättra tillförlitligheten (reliability) och öka prestanda.

15 15 Säkerhetsmekanismer (7) DBMS och Webbsäkerhet Kommunikation över internet sker med hjälp av TCP/IP som underliggande protokoll. Hur som helst blev ej TCP/IP och HTTP designat med tanke på säkerhet. Utan speciella mjukvaror för säkerhet, transporteras all internettrafik i klartext, och en person som övervakar trafiken kan också läsa den.

16 16 Stöd för transaktioner Transaktion En händelse, eller serie av händelser, som utförs av en användare eller applikation, som hämtar eller ändrar innehållet i databasen. Betraktas som en logisk enhet arbete i databasen Applikationsprogrammen utför serier med transaktioner och processer som ej involverar databasen utförs mellan transaktionerna. Omvandlar databasen från ett konsistent läge till ett annat konsistent läge, eftersom konsistens inte existerar medan transaktionen pågår.

17 Exempel på transaktioner 17

18 18 Stöd för transaktioner Kan ha anta ett av två resultat: Success - transaktionen slutförs (commit), och databasen når ett konsistent läge. Failure transaktionen avbryts (aborts), och databasen måste återställas till det konsistenta läge som var innan transaktionen påbörjades. En sådan transaktion rullas tillbaka (rollback) En transaktion som erhållit commit kan ej avbrytas En avbruten transaktion som rullats tillbaka kan göras om senare.

19 19 Tillståndsdiagram för en transaktion

20 20 Egenskaper hos en transaktion (Haerder & Reuter, 1983) Fyra grundläggande (ACID) egenskaperna hos en transaktion är: Atomicity: Allt eller inget genomförs. Consistency: Måste omvandla databasen från ett konsistent läge till ett annat konsistent läge. Isolation: Effekter av delsteg i en transaktion ska ej kunna ses av andra transaktioner. Durability: Effekter av en transaktion som genomförts (commited) permanentas i databasen. Den får inte förloras pga senare fel.

21 21 Samtidighet (Concurrency Control) Hantering av samtidiga operationer i databasen utan att de kolliderar med varandra. Förhindrar kollision när två eller fler användare använder databasen samtidigt och åtminstone en av dem ändrar data. Fastän två transaktioner kan vara korrekta var för sig, kan de sammanvävda ge ett felaktigt resultat.

22 22 Behov av Samtidighet (Concurrency Control) Tre exempel på potentiella problem pga samtidighet: Lost update problem. Uncommitted dependency problem. Inconsistent analysis problem.

23 23 Lost Update Problem Förlust av T 2 s uppdatering undviks genom att hindra T 1 från att läsa bal x tills efter uppdateringen.

24 Uncommitted Dependency Problem 24 Problemet undviks genom att hindra T 3 att läsa bal x tills efter T 4 slutförts eller avbrutits.

25 25 Inconsistent Analysis Problem Problemet undviks genom att hindra T 6 från att läsa bal x och bal z tills efter T 5 slutfört uppdateringen. Med andra ord går T6 in och läser det den inte ska förrän T5 är helt klar

26 26 Upprepbarhet (Serializability) Målet med samtidighetsprotokollet (concurrency control protocol) är att planera transaktioner på ett sätt så att kollision undviks. Transaktioner kan köras seriellt, men detta begränsar möjligheten att köra parallella transaktioner Upprepbarhet (serializability) identiferar de exekveringar i transaktioner som garanterat säkerställer konsistensen i databasen.

27 Upprepbarhet (Serializability) (2) Med upprepbarhet (serializability), är hanteringen av läsning/skrivning viktigt: (a) Om två transaktioner enbart läser dataelement, kolliderar de inte och hanteringen är ej viktig. 27 (b) Om två transaktioner endera läser eller skriver helt olika dataelement, kolliderar de inte och hanteringen är ej viktig. (c) Om en transaktion skriver i ett dataelement och ett annat läser eller skriver i samma dataelement, är hanteringen viktig.

28 28 Exempel på upprepbarhet (Serializability)

29 29 Tekniker för samtidighet (Concurrency Control) Två grundläggande tekniker för samtidighet: Låsning (locking), Timestamp. Båda är konservativa angreppssätt: fördröj transaktioner om de kolliderar med andra transaktioner. Optimistiska metoder antar att konflikter är sällsynta och kollar bara efter konflikter vid slutförandet (commit).

30 30 Låsning (Locking) Transaktioner använder lås för att förneka andra transaktioner tillgång och på så sätt förhindra felaktiga ändringar. Är det mest utbredda angreppssättet för att försäkra upprepbarhet (serializability). Generellt, måste en transaktion göra anspråk på ett delat lås (read) eller ett exklusivt lås (write) före läsning eller skrivning. Lås förhindrar att andra transaktioner ändrar element eller till och med läser element vid exklusiva lås (write).

31 31 Låsning Grundläggande regler Om en transaktion har ett delat lås på ett element, kan det läsas men inte ändras. Om en transaktion har ett exklusivt lås (write) på ett element, kan det både läsas och ändras. Läslås kan inte kollidera, därför kan fler än en transaktion ha ett läslås på samma element. Exklusiva lås (skrivlås) ger transaktionen ensamrätt till elementet.

32 32 Two-Phase Locking (2PL) Transaktioner följer 2PL protokollet om alla låsoperationer först föregås av en upplåsningsoperation i transaktionen. Två faser vid transaktioner: Växande fas sätter alla lås men kan ej släppa några lås. Krympande fas släpper lås men kan inte sätta några nya lås.

33 33 Förhindra Lost Update Problem genom att använda 2PL

34 34 Förhindra Uncommitted Dependency Problem genom att använda 2PL

35 Förhindra Inconsistent Analysis Problem genom att använda 2PL 35

36 36 Cascading Rollback Om varje transaktion följer 2PL, är planen upprepbar (serializable). Hur som helst, problem kan uppstå beroende av vid vilket tillfälle lås släpps.

37 Cascading Rollback (2) 37

38 38 Deadlock Ett dödläge som uppstår när två eller fler transaktioner väntar på att den andra transaktionen ska släppa sitt lås och vice versa.

39 39 Deadlock (2) Det finns bara ett sätt att bryta deadlock: genom att avbryta en eller fler transaktioner. Deadlock bör vara transparent för användaren, så att DBMS kan starta om transaktioner(na). Tre huvudsakliga tekniker används för att handskas med deadlock: Timeouts. Deadlock prevention. Deadlock detection and recovery.

40 40 Granularity på dataelement Storleken på dataelementen som valts som enhet för att skyddas med samtidighet (concurrency control protocol). Ordnat från grovt till fint: Hela databasen. En fil. En sida (yta). En post. Ett värde i en post.

41 41 Granularity på dataelement (2) Konsekvenser: grövre, ju lägre grad av samtidighet (concurrency) finare, mer låsinformation behöver lagras. Bästa elementstorlek beror på typen av transaktion.

42 42 Återställande av databas (Recovery) Återställande av en databas till ett korrekt tillstånd i händelse av fel. Behov av kontroll av återställandet Två typer av lagring: volatile (primärminnet) och nonvolatile. Volatile lagring överlever inte en systemkrasch. Fast lagring representerar information som har replikerats i flera nonvolatile lagringsmedia oberoende av typ av fel.

43 43 Typ av fel Systemkrasch, resulterar i förlust av allt i primärminnet. Fel på mediat, resulterar i förlust av delar av hårddisken (sekundär lagringsenhet). Fel i applikationer. Naturkatastrofer. Vårdslöshet eller oavsiktligt förstörande av data. Sabotage.

44 44 Distribuerade DBMS - koncept Distribuerad databas En logisk mängd sammanhängande delad data (och beskrivning av denna data), fysiskt distribuerad över ett datornätverk. Distribuerat DBMS Mjukvarusystem som tillåter hantering av distribuerade databaser och gör distributionen transparent för användarna.

45 45 Distribuerat DBMS Distribuerad hantering: En centraliserad databas som kan nås över ett datornätverk.

46 46 Parallella DBMS Ett DBMS som körs över flera processorer och hårddiskar designade för att exekvera parallella operationer, när detta är möjligt, för att förbättra prestandan. Baserat på premissen att en processor inte längre kan tillgodose för kostnadseffektiv skalbarhet, tillförlitlighet och prestanda. Parallella DBMS länk för att nå samma prestanda som en större dator, med större skalbarhet och tillförlitlighet.

47 47 Parallella DBMS (2) Huvudarkitekturer för parallella DBMS är: Delat minne, Delade diskar, Shared nothing.

48 48 Parallella DBMS (3) (a) delat minne (b) delade diskar (c) shared nothing

49 49 Fördelar med DDBMS Speglar den organisatoriska strukturen Förbättrad shareability and local autonomy Förbättrad tillgänglighet Förbättrad tillförlitlighet Förbättrad prestanda Ekonomiska Modulärt växande

50 50 Nackdelar med DDBMS Komplexitet Kostnader Säkerhet Svårare att hantera av integritet Avsaknad av standard Avsaknad av erfarenhet Databasdesign blir mer komplex

51 51 Distribuerad databasdesign Tre huvudavgöranden: Fragmentering, Allokering, Replikering.

52 52 Distribuerad databasdesign (2) Fragmentering Tabell kan delas i ett antal deltabeller, som sen distribueras. Allokering Varje fragment lagras på plats med optimal distribuering. Replikering En kopia av fragment kan hanteras på flera olika ställen.

53 53 Fragmentering Definiering och allokering av fragment som lyfts ut strategiskt för att uppnå: närhet till referenserna. förbättrad tillförlitlighet and tillgänglighet. förbättrad prestanda. balanserad lagringskapacitet och kostnader. Minimal kostnad för kommunikation. Involverar analys av de viktigaste applikationerna, baserat på kvantitativ/kvalitativ information.

54 54 Fragmentering (2) Kvantitativ information kan inkludera: Frekvens för hur ofta en applikation körs Ställe som en applikationen körs ifrån Prestandakriterier för transaktioner och applikationer. Kvalitativ information kan inkludera transaktioner som exekveras av applikationer, typ av åtkomst (read/write), och egenskaper hos läsoperationer.

55 55 Data allokering Fyra alternativa strategier beträffande placering av data: Centraliserad, Partitionerad (eller fragmenterad), Full Replikering, Delvis Replikering.

56 56 Data allokering (2) Centraliserad Innehåller en databas och DBMS lagrat på ett ställe med användare distribuerade i nätverket. Partitionerad Databasen är partitionerad i sönderdelade fragment, varje dedikerat till ett ställe.

57 57 Data allokering (3) Full replikering Består av hantering av fullständiga kopior av databasen vid varje ställe. Delvis Replikering Kombination av partitionering, replikering och centralisering.

58 58 Jämförelse av strategier för distribution av data

59 59 Varför fragmentering? Användande Applikationer arbetar med vyer istället för hela tabeller. Effektivitet Data lagras där den används mest frekvent. Data som ej behövs av en lokal applikation behöver ej lagras.

60 60 Varför fragmentering? (2) Parallelism Med fragment som enheter vid distribution, kan transaktioner delas i flera delfrågor som opererar på fragmenten. Säkerhet Data som inte behövs av en lokal applikation lagras inte och är därför inte heller tillgänglig för oauktoriserade användare.

61 61 Varför fragmentering? (3) Nackdelar prestandan, integriteten.

62 Prestanda transparens - exempel Property(propNo, city) poster i London Client(clientNo,maxPrice) poster i Glasgow Viewing(propNo, clientno) poster i London SELECT p.propno FROM Property p INNER JOIN (Client c INNER JOIN Viewing v ON c.clientno = v.clientno) ON p.propno = v.propno WHERE p.city= Aberdeen AND c.maxprice > ; 62

63 63 Prestanda transparens exempel (2) Antaganden: Varje tuple i varje tabell är 100 tecken lång. 10 klienter (renters) med maximalt pris större än 200, Visningar (viewings) för fastigheter (properties) i Aberdeen.

64 64 Prestanda transparens exempel (3)

65 65 12 mål enligt den fundamentala principen för distribuerade databassystem (Date): 1. Local autonomy Alla operationer ska kontrolleras av den site som de körs på och inte behöva hjälp från någon annan site t ex om någon site skulle vara nere måste operationer kunna utföras ändå. 2. No reliance on a central site Local autonomy talar om att alla siter ska behandlas som jämlikar, det ska alltså inte finnas något behov av någon central master site. Detta för att undvika flaskhalsar och beroende av någon annan site.

66 66 12 mål forts 3. Continous operation En fördel med distribuerade system är att de ska erbjuda större reliabilitet (att systemet rullar och är tillgängligt alltid) och större tillgänglighet (att systemet rullar då operationer genomförs). Att motverka oplanerade driftstopp. 4. Location independence Användaren behöver inte veta var data fysiskt lagras, det ska fungera som om all data var lagrat lokalt på deras dator.

67 67 12 mål forts 5. Fragmentation independence Att systemet tillåter att en tabell kan delas upp i olika delar vid fysisk lagring (t ex att vissa delar kan finnas lagrade i London och andra i NewYork). 6. Replication independence Att systemet tillåter datareplikering så att data representeras av många kopior (t ex kan NewYork ha kopior av Londons tabell för att snabb access)

68 68 12 mål forts 7. Distributed query processing Att det finns en strategi för optimering av diverse frågor så dessa kan genomföras så billigt som möjligt. Att kunna ställa frågor mot en databas i New York, även om man sitter i London. 8. Distributed transaction management Att operationer/transaktioner genomförs med hjälp av agenter som kontrollerar att hela transaktionen antingen genomförs eller inte genomförs alls om ett fel skulle uppstå.

69 69 12 mål forts 9. Hardware independence Inga fel ska kunna uppstå beroende på valet av hårdvara (IBM, HP, PC, etc) 10. Operating system independence DBMS ska kunna köras oberoende av de olika operativsystem som kan finnas (UNIX, NT, etc). 11. Network independence Olika typer av nätverk ska ej kunna orsaka fel.

70 70 12 mål forts 12. DBMS independence Olika DBMS ska kunna agera tillsammans med hjälp av exempelvis standard-sql. Dock krävs ofta en annan lösning Gateway (gör t ex så att Ingres ser ut som Oracle) De fyra sistnämna punkterna är ideal.