Elmasri kap. 23.1 - 23.2, 17.1-17.31 Databaser Kvalitetsattributter og arkitektur Sikkerhed Transaktioner.

Præsentationer af emnet: "Elmasri kap. 23.1 - 23.2, 17.1-17.31 Databaser Kvalitetsattributter og arkitektur Sikkerhed Transaktioner."— Præsentationens transcript:

1 elmasri kap. 23.1 - 23.2, 17.1-17.31 Databaser Kvalitetsattributter og arkitektur Sikkerhed Transaktioner

2 elmasri kap. 23.1 - 23.2, 17.1-17.32 Definition af software arkitektur The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them [BCK :Software Architecture in practice]

3 elmasri kap. 23.1 - 23.2, 17.1-17.33 Definitionen the externally visible properties: er de antagelser andre elementer kan tage f.eks.hvilke services det stilles til rådighed, hvordan performer det, fejlhåndtering….

4 elmasri kap. 23.1 - 23.2, 17.1-17.34 Andre pointer Alle systemer har en arkitektur –Måske består det kun af en komponent –Arkitekturen er måske ikke kendt! Komponenternes opførsel er en del af arkitekturen Arkitekturen opfylder måske kravene

5 elmasri kap. 23.1 - 23.2, 17.1-17.35 Kvalitetskrav og arkitektur Arkitekturen bestemmes ud fra kvalitetskravene til et system, som kan inddeles i følgende hovedkategorier: sikkerhed tilgængelighed modificerbarhed performance testbarhed usability Fx kan man impl. samme funktionalitet i en 1., 2., eller flere lags arkitektur og systemet virker lige godt overfor brugerne MEN det er flere lags arkitekturen, der bedst opfylder kvalitetskrav vedr. modificerbarhed Man kan udtrykke det således, at kvalitetskravene bestemmer arkitekturen, men det er gennem funktionalitetskravene den gives indhold og kan valideres.

6 elmasri kap. 23.1 - 23.2, 17.1-17.36 Kvalitetskrav og arkitektur Kvalitetskrav kan være modstridende – eller der kan være modstrid til forretningskvaliteter som ’time to marked’, cost and benefits, deadlines osv. Kvalitetskravene gøres målbare ved kvalitetsscenarier fx –systemet skal kunne udvides med en web-gui uden at det berører øvrige dele af systemet i løbet af 3 dage –når en bruger søger efter en vare skal den gennemsnitlige svar tid ved en normal operation være under 2. sek Der er den arkitektur bærende funktionalitet eller de mest komplekse use case, der bestemmer lagene, hovedmoduler og deres interfaces.

7 elmasri kap. 23.1 - 23.2, 17.1-17.37 Modificerbarhed Hvad koster det at ændre systemet –Hvad kan ændres? Hardware-software-middelware- os –Hvad får ændringer indflydelse på? Design, performance…. Slutbruger, system administrator -Hvordan opsamles ønsker om ændringer?

8 elmasri kap. 23.1 - 23.2, 17.1-17.38 Overvejelser i forhold til sikkerhed Prøv at identificer mulige fejlsituationer Hvordan er disse fejlsituationer en sikkerhedsrisiko? Hvad kan der gøres for at sikre systemet? Hvordan kan mulige fejlsituationer minimeres? Kan der være ”ikke tekniske” sikkerhedsproblemer? Hvor meget må det koste?? Hvilke konsekvenser får valgene på: forskellige strukturer (moduler, komponenter)

9 elmasri kap. 23.1 - 23.2, 17.1-17.39 Sikkerhed i forhold til databasen Lovlige og etiske Politik (de forskellige institutioner man er underlagt) Tab af integrititet Tab af tilgængelighed Uautoriserede tilgang

10 elmasri kap. 23.1 - 23.2, 17.1-17.310 Sikkerhed indbygget i DBMS Kommandoer for tildeling af privilegier: –Account creation: Oprettelse af nye accounts og PW for brugere som skal kunne tilgå DBMS –Privilige granting: Tildeling af rettigheder til bestemte accounts –Privilige revokation: Fratagelse af rettigheder –Security level assignment: Tildeling af rettigheder til det rigtige sikkerhedsniveau Niveauer for tildeling af privilegier: –Account level: Tildeling af særlige privilegier uafhængig af de enkelte tabeller fx rettighed til at oprette tabeller, læse og skrive –The relation level: Privilegier tildeles de enkelte tupler (select, modify eller reference privilegier) ved grant og revoke kommandoer i sql Ansvarlig: Databaseadministrator (DBA)

11 elmasri kap. 23.1 - 23.2, 17.1-17.311 Grant/Revoke Ejeren af en tabel kan ved kommandoerne grant og revoke tildele og fratage rettigheder til en anden bruger: –Grant on to –Eks: Grant insert, delete on employee, department to hanne –Revoke on from –Eks: Revoke insert, delete on employee, department from hanne Eksempler: (elmasri s. 738-739)

12 elmasri kap. 23.1 - 23.2, 17.1-17.312 Transaktioner Transaktion: –Er en atomisk operation af sql ”statements” –Udføres enten helt eller uden effekt på databasen Er kun relevant ved opdatering af data Problemer hvis en transaktion kan udføres samtidigt på de samme dataelementer –Lost update –Temporary update (dirty read) –Incorrect summary problem

13 elmasri kap. 23.1 - 23.2, 17.1-17.313 Lost update T1T2 Read_item(x) X= x-n read_item(x); x=x+m; Write_item(x) Read_item(y); write_item(x); Y:=Y+N; Write_item (Y); tid X har en forkert værdi

14 elmasri kap. 23.1 - 23.2, 17.1-17.314 Dirty read T1T2 Read_item(x) X= x-n Write_item(x) read_item(x); x=x+m; write_item(x); Read_item(y); … tid T1 fejler og må ændre x tilbage

15 elmasri kap. 23.1 - 23.2, 17.1-17.315 Incorret summary

16 elmasri kap. 23.1 - 23.2, 17.1-17.316 Transactions states

17 elmasri kap. 23.1 - 23.2, 17.1-17.317 Operationer til recovery management Begin transaction Read or write End Transaction Commit transaction Rollback Registreres i systemlog

18 elmasri kap. 23.1 - 23.2, 17.1-17.318 Et DBMS skal understøtte ACID egenskaber –Atomar: Enten udføres hele processen eller intet –Consistent: Constraints i databasen overholdes (consistens før og efter en transaktionen er udført) –Isolation: For den enkelte bruger skal det virke som kun en proces udføres ad gangen (sikring af at samtidige transaktioner isoleres fra hinanden (isolationsniveauer) –Durable: Effekten af en committet proces må ikke gå tabt ved system crash (sikring af at opdateringer gemmes)

19 elmasri kap. 23.1 - 23.2, 17.1-17.319 Atomar Sikres ved sql statementet: roll back Transaktionen logges og hvis den er fejler laver databasen roll back til tilstanden før transaktionen startede Fejl kan være fejl i connection Hvis der ikke benyttes transaktioner laver databasen roll back på det enkelte sql statement, hvis det fejler Fortryder brugeren en opdatering skal roll back styres gennem programmerne Roll back dækker også kravet om durability

20 elmasri kap. 23.1 - 23.2, 17.1-17.320 Transaktioner Er det et fornuftigt valg at indpakke nedenstående sql statements I en transaktion? con.setAutoCommit(false); Statement stmt = con.createStatement(); stmt.executeUpdate( “INSERT INTO BOOKS VALUES(....)”); stmt.executeUpdate( “INSERT INTO AUTHORS VALUES(....)”); stmt.executeUpdate( “INSERT INTO BOOKSAUTHORS VALUES(....)”); con.commit(); con.setAutoCommit(true); start transaktion – ”Begin transaction” findes ikke i java transaktion afslut

21 elmasri kap. 23.1 - 23.2, 17.1-17.321 Analyse af samtidighedsproblemer I hvilke af følgende situationer kan der være samtidighedsproblemer? Illustrer ved et transaktionsscenarie: –Billetreservation til en biograf –Hævning på en konto de ejes af mindst 2 Vurder sandsynlighed samt hvor kritisk problemet er